Primary obligations include obtaining explicit consent from the data subject for the processing of personal data and providing full transparency with respect to processing and sharing. With the coming into effect of the GDPR in May 2018, several tools [11, 16, 19] have recently been developed that can be used to assist companies to assess the compliance of their systems and processes with respect to obligations set forth in the GDPR. However, such tools are targeted at self assessment (i.e. companies complete standard questionnaires in the form of a privacy impact assessment) and cannot be used to automatically check compliance with usage constraints. Such, automated transparency and compliance mechanisms would require not only machine-readable representations of the users consent, but also machine-readable representations of data processing and sharing. SPECIAL 1 is an EU H2020 research and innovation action, which addresses these challenges by demonstrating how Semantic Web technologies can be used for both consent and personal data processing representation and compliance checking. In particular we devise a suite of ontologies and vocabularies that can be used to: (i) model data usage policies, conforming the SPECIAL's Usage Policy Language, (ii) represent data processing and sharing events in a semantic log. Both of which have been developed in close collaboration with legal experts, thus ensuring that our automated compliance checking is tightly coupled with the legal assessment process.1 https://www.specialprivacy.eu/ 1 arXiv:2001.09461v1

Ea ch process description is shaped like a formalized business policy consisting of the following set of features: - the file(s) to be processed; - the software that carries out the processing; - the purpose of the processing; - the entities that can access the results of the processing; - the details of where the results are stored and for how long; - the obligations that are fulfilled while (or before) carrying out the processing; - the legal basis of the processing. It is not hard to see that the first five elements in the above list match SPECIAL's usage policy language (UPL) introduced in Section 3. As far as the above elements are concerned, the only difference between UPL expressions and a business policy is the granularity of attribute values. Fo r example, the involved data (specified in the first element of the above list) are not expressed as a general, content-oriented category, but rather as a concrete set of data sourc es or data items. Such objects can be modeled as instances or subclasses of the general data categories illustrated in Section 3, thereby creating a link between digital artifacts and usage policies. Similar considerations hold for the other a t-tributes: - processing is not necessarily described in the abstract terms adopted by the processing vocabulary introduced in Section 3; in a business policy, this can be specified by naming concrete software procedures; - the purpose of data processing may be directly related to the data controller's mission and products; - recipients may consist of a concrete list of legal and/or physical persons, as opposed to general categories such as Ours or ThirdParty; - storage may be specified by a list of specific data repositories, at the level of files and hosts. With this level of granularity, specific authorizations can be derived from the business policy, for example: The indicated software procedure can read the indicated data sources. The results can be written in the specified repositories. The specified recipients can read the repositories...

Emerging ontology authoring methods to add knowledge to an ontology focus on ameliorating the validation bottleneck. The verification of the newly added axiom is still one of trying and seeing what the reasoner says, because a systematic testbed for ontology authoring is missing. We sought to address this by introducing the approach of test-driven development for ontology authoring. We specify 36 generic tests, as TBox queries and TBox axioms tested through individuals, and structure their inner workings in an `open box'-way, which cover the OWL 2 DL language features. This is implemented as a Protege plugin so that one can perform a TDD test as a black box test. We evaluated the two test approaches on their performance. The TBox queries were faster, and that effect is more pronounced the larger the ontology is. We provide a general sequence of a TDD process for ontology engineering as a foundation for a TDD methodology.