DSAP: Data Sharing Agreement Privacy Ontology Mingyuan Li and Reza Samavi Computing & Software, McMaster University, Hamilton, Ontario, Canada {lim107,samavir}@mcmaster.ca Abstract. In this paper we propose a flexible and extensible ontology for expressing and enforcing privacy policies described in medical re- search data sharing agreements (DSA). We demonstrate that our ontol- ogy is capable of supporting the DSA in a collaborative health research data sharing scenario through providing the appropriate vocabulary and structure to log privacy events in a linked data based audit log. Fur- thermore, through querying the audit log, we can answer privacy queries relevant to the data sharing agreements. Keywords: Privacy · Data Sharing · Semantic Web · Ontology 1 Introduction A data sharing agreement (DSA) is a written document composed of static text expressing the constraints that researchers must follow when sharing data con- taining personal information [20]. The composition of the expressed constraints, or privacy policies, is guided by the goal to foster data sharing but also to pro- tect research subjects’ personal information. The most common form to express DSA policies is using natural language. However, inherent ambiguity in natu- ral languages is a source of problem. While a number of policy languages are proposed to express DSA policies in unambiguous manner (e.g., [2,3,15]), their lack of flexibility, extensibility, and ease of use made their applications limited in collaborative medical research environments [15]. In addition, there are as- pects of privacy constraints (e.g., purpose definition [2], data transfer [15] and retention [3] policies) that the proposed languages are not able to express. The objective of this work is to design a semantic model with necessary concepts and properties that allows DSA privacy policies to be expressed unambiguously. The model also supports transparency and auditibility of actions of researchers on private data and consequently making the responsible participants accountable. We motivate the need for such a semantic model using a typical collaborative medical research scenario as depicted in Fig. 1. Bob is a researcher at a public university (PU-A) and conducts only publicly-funded research. His colleague, Charlie, is also a researcher at PU-A but he also holds an appointment at a private pharmaceutical company (PP-A). The collaborative research involves a genetics dataset bound by a DSA privacy constraint that limits the genetics data to be only shared with publicly funded research studies. Charlie appears 2 Li and Samavi Fig. 1: Motivating Scenario to be in a legitimate position to receive data in his capacity as a researcher at PU-A, but his private appointment at PP-A raises an issue. The confusion of responsibilities is necessary to be resolved as mishandling of patient data can harm the patients and can be a liability for the researchers [17]. Bob and Charlie expect to have an unambiguous and efficient way of answering their questions regarding their data protection responsibilities. In this paper, we propose the DSAP (Data Sharing Agreement Privacy) ontology, as a semantic model consisting of explicitly defined concepts and re- lations [12], to provide medical researchers with a language to express privacy policies of DSAs. To design the ontology we adapted the methodology described by [13] and utilized concepts and relations derived from surveyed privacy policies of a diverse number of DSAs and guidelines. We designed the ontology with a hierarchical structure, lightweight expressiveness, and with capability of reusing other ontologies. These characteristics make our ontology flexible and extensi- ble to be used by different medical disciplines. We demonstrate that using our ontology we can create a Linked Data [14] based privacy log [19,18] to answer privacy queries. The full DSAP ontology is available on http://l2tap.org/dsap. The paper structure is as follows. In Section 2, we discuss the ontology re- quirements and provide an overview of the DSAP ontology. In Section 3, we demonstrate how DSAP can be used for logging events related to data shar- ing. In Section 4, we report the evaluation of our ontology. The related work is discussed in Section 5, and we conclude in Section 6. 2 DSAP Ontology Design The key objective in designing the DSAP ontology is to support transparency and accountability with respect to the treatment of personal data when multiple stakeholders (participants) are collaborating in a health research context. The ontology should provide necessary structure to support encoding: 1) the static semantic: i.e. the privacy terms and conditions and what participants must per- form in order to comply with these terms, and 2) the dynamic semantic: i.e. what participants have performed and the actual occurrences of data usage access ac- tivities with respect to the DSA privacy constraints. Although the focus of our DSAP ontology is only on the static semantics of DSAs, we are interested to design the ontology such that it supports the dynamic semantics through exten- sion. Therefore extensibility of the DSAP ontology to capture dynamic semantics by using other ontologies is a core design requirement. 2.1 Ontology Users and Requirements The main participants in a medical research are data contributors, medical re- searchers (and their associated hospitals or research centers) and privacy audi- DSAP: Data Sharing Agreement Privacy Ontology 3 tors [9]. Data contributors are usually patients and while they contribute data to the studies, their main concern is the preservation of their privacy throughout the medical research lifecycle (i.e., collection, use and process, and disclosure). Privacy auditors are concerned with the compliance of medical researchers with privacy policies governing the use of personal data. Patients can also be an au- ditor when they are enabled to audit the process of data sharing. Meanwhile, in addition to sharing data among themselves, medical researchers need to commu- nicate privacy policies regarding the treatment of data with their collaborators. The researchers are also concerned with their own compliance with privacy poli- cies specified by their collaborators. To achieve compliance, the researchers first need to understand their own privileges and obligations w.r.t. the health data. Flexibility in expressing privacy policies. Different medical research disci- plines may need different types of privacy policies to be expressed. For instance, with respect to data retention policies, public health researchers may only work with aggregated and anonymized data. Therefore, public health research DSAs may simply require the researcher to dispose the data after a year. On the other hand, genetics researchers work with more sensitive personal data. As a result, genetics research DSAs may specify more strict policies to include an encryption requirement in addition to disposal requirement. Therefore, the ontology will need to be flexible to be able to express different types of privacy policies. Extensibility to work with other ontologies. With an extensible ontology, medical researchers will have the freedom to utilize other ontologies with more or less expressive power. By extending, more vocabulary can be utilized to express diverse privacy policies as well as allowing the enforcement of privacy policies to be achieved. Ontology reuse has many benefits and is encouraged in the ontology design literature [16]. Saving the labour involved in creating an ontology from scratch, improving the quality of ontology, and reducing ontology maintenance overhead [16] are among these advantages. We design our ontology with reuse of other ontologies in mind where appropriate. Lightweight expressivity. An important requirement of the DSAP ontology is decidability. Our ontology is organized into a hierarchical structure with the key advantage of supporting inheritance for complex concepts. The transitive closure of inheritance supports decidable reasoning. In addition, when reading a hierarchy, the medical researcher can intuitively organize the concepts and relations based on parent-child relationships. The simple and self-explanatory organization of concepts in a hierarchy simplifies the complexities of DSAs. The hierarchy structure also promotes extensibility as the concepts within the hi- erarchy can be extended without the need to disrupt the rest of the ontology. Another distinct advantage of a lightweight ontology is its extensibility and flex- ibility. For example in our ontology, if we use a hierarchy to express different roles, using the rdfs:subClassOf allows a more complex role hierarchy from another ontology to be directly plugged into our ontology. Semantic Technology support Our ontology makes use of a limited num- ber of concept and properties in RDFS [4], and RDF [1], e.g., rdfs:domain, rdfs:range, rdfs:subClassOf and rdfs:subPropertyOf. Using these ontology 4 Li and Samavi languages, with limited expressive power, has multiple advantages over highly expressive ontology languages such as first order logic (FOL). First, there are scalable off the shelf semantic technology support (e.g., IBM DB2) for RDF data model. Second, compared to FOL, our ontology is decidable as we rely on the limited reasoning power of the transitive closure of rdfs:subClassOf and rdfs:subPropertyOf. In addition, RDF type ontology is relatively easier to un- derstand by a non-technical person such as a medical researcher and is typically used for description or classification purposes [11]. 2.2 DSAP Core Structure We adapted the ontology design methodology described by [13] with the follow- ing four steps: 1) Describe Motivating Scenario as described in the Introduction section. 2) Determine Competency Questions. Competency questions are ques- tions that our ontology is required to answer. 3) Derive Concepts and Relations. Concepts and relations are derived from vocabulary gathered from a survey of DSA templates and guidelines. 4) Evaluate the Ontology. We evaluated our on- tology to support the static semantics of DSA (by directly using DSAP concepts) and dynamic semantics of DSAs (through the extension described in Section 4). Competency Questions Competency questions define the queries to be an- swered by the DSAP ontology. These questions can be prohibitive or prescriptive. Prohibitive questions are questions asked by a researcher or an auditor to ensure a certain task is permitted to perform on private data. Examples are: Is Bob allowed to share the dataset D1 with Charlie? Should I perform task T1 (e.g., sending a notification) at the point in time t1 ?. This type of questions usually demands a simple yes or no answer. Prescriptive questions in contrast are ques- tions that demand a certain piece of instruction from the DSA. Examples of prescriptive questions are: What are my obligations if I access the dataset D1 ? For what purposes can I disclose the dataset D1 ? DSAP Ontology Concept Derivation For deriving the main concepts of the ontology in addition to using the usage scenario recommended in the methodol- ogy, we used DSA templates and guidelines. We surveyed 9 data sharing agree- ments and 10 data sharing guidelines. The obtained documents included from both Europe and North America representing a range of medical research topics such as cancer and genetics research. First, a word pool was created by pars- ing the data sharing guidelines and data sharing agreements through a word counter [10]. A total of 48,241 words were parsed. Next, after synonyms and du- plicates were removed, 72 unique words were identified and were used to create a preliminary vocabulary list from which our ontology was constructed. Nouns were used as candidate concepts while verbs were used as candidate relations. Following word analysis, we conducted a whole-document analysis of five data sharing agreements from Canada and Europe. The policy clauses covering in- tellectual property rights and authorships were excluded and privacy-related clauses were analyzed for required concepts and relations to be expressed. Overview of DSAP Ontology We use UML class diagram to represent the core concepts of DSAP Ontology: Agent, Role, Action, Dataset, and Policy as depicted in Figure 2 and described below: DSAP: Data Sharing Agreement Privacy Ontology 5 Fig. 2: DSAP Ontology Core Concepts Fig. 3: Events in L2TAP Log [18] Agent: An agent is a person or a thing that is responsible for the occurrence of an action. In our scenario, Bob and Charlie are examples of agents. Role: The role identifies the expected actions of an agent. Bob and Charlie both assume the role of a researcher. As researchers, they are expected to do something with data, such as access data, share data, and analyze data. Bob also takes on the role of data sender while Charlie takes the role of data requestor. Action: An action is something that is performed by an agent on an item (e.g., a dataset). Destroying a dataset is an example of an action. In our scenario, Charlie is required to destroy the dataset at the end of agreement. Dataset: The dataset captures any collection of private data, such as data con- taining personal health information or any personal identifiable information. The genetics data in our scenario is an example of dataset. Policy: Policy refers to each individual clause in the DSA expressing a privacy constraint. "Bob is only allowed to share the genetics dataset with publicly funded research" is an example of a policy. Several relations are important in our core ontology. The hasRole relation captures the Role that an Agent assumes. In our scenario, Charlie hasRole re- searcher. With aboutRole, we can also associate a Policy with Role. The pro- hibitedAction, requiredAction, and authorizedAction relations capture the prohibition, requirement, and authorization of a Role to perform a certain Ac- tion respectively. For instance, the requiredAction can capture that Charlie as a researcher is required to destroy data (an Action) at the end of agree- ment. Finally, the aboutDataset relation mints the Dataset to a Policy. For example, our genetics data can be associated with DSA privacy policies through the aboutDataset relation. There are additional concepts and relations such as dsap:Purpose, dsap:eligiblePurpose, dsap:Consent, etc. The full ontology and potential mapping of some DSAP concepts (e.g., Role, Agent, Consent) to the concepts in other ontologies is available at http://l2tap.org/dsap. In Table 1, we demonstrate our ontology’s ability to express privacy poli- cies in DSAs by translating a DSA excerpt into RDF format serialized in the Turtle syntax [7]. The policy has three components: 1) An obligation clause stating that the receiver of the data must destroy data captured using the dsap:requiredAction property (lines 1-2); 2) The clause indicating that the specific dataset to be destroyed captured using the dsap:aboutDataset prop- erty (line 3-4); and 3) A temporal clause stating the date at which dataset must be destroyed encoded using the tl:atDate property from the Timeline Ontology 6 Li and Samavi (line 5). In the example shown in Table 1, ambiguity resulting from the vague expression: "tangible materials" is eliminated when the DSA author is forced to declare specific datasets using the dsap:aboutDataset relation in our ontology. Table 1: Expressing Data Retention Privacy Policy in RDF Triples DSA Excerpt RDF Triples Upon termination of this Agreement, receiv- 1 :receiver a dsap:DataReceiver; ing party shall promptly destroy all docu- 2 dsap:requiredAction :deleteData. ments, files and other tangible materials rep- 3 :deleteData a dsap:DestroyAction; resenting disclosing party’s information. 4 dsap:aboutDataset :healthData; 5 tl:atDate "2018-08-01"^^xsd:date. 3 DSAP Ontology and Dynamic Semantics of DSAs In this section, we describe how the DSAP ontology can be extended to capture dynamic semantics of DSAs using other Linked Data based ontologies such as L2TAP model [18,19]. For our motivating scenario (Fig. 1) we show that privacy events can be recorded in a linked data based audit log [19]. The audit log can be then published and queried using SPARQL queries to answer privacy questions. We use a UML sequence diagram (Fig. 3) adapted from [19] to describe the participants and the order of privacy events that occur in a collaborative data sharing environment. The main participants of the privacy audit logging process are DSA Logger, Data Requestor (Charlie), the L2TAP Audit Log, the Data Sender (Bob), and the Auditor. Similar to the scenario described in [19], for each event generated by the participants in our data sharing scenario (Fig. 1), we can generate an L2TAP log event. The order of events is also similar to the L2TAP log in general as the logger needs to initialize log and register all participants (including data senders, requestors, auditors and even patients as the auditors). Then privacy policies and terms and conditions of a DSA (static semantics of the DSA) will be registered by the logger using the DSAP ontology. After these three events are logged the log can be used to record all different actions that occur during the lifecycle of a DSA. To show how DSAP can be used with the extended semantics of L2TAP, below we describe the event of a privacy policy registration for our motivating scenario. A complete list of all events are available at our ontology website (http://l2tap.org/dsap). Each privacy event in the L2TAP log contains a log header and a log body. The log header encodes assertions about the provenance of an event (who, when and what). For the log header we plugin the L2TAP-core module (with the l2tap namespace) as described in [19]. For example, in the privacy policy reg- istration event (Listing 1.1), the header is shown in lines 1-12. In our header, exlog:logevent3 is an instance of l2tap:PrivacyEvent (line 1) and a member of exlog:log1 (line 2). exlog:log1 is the URI for the group of log events that together captures all events in our data sharing scenario. Line 3 captures that the logger for this event is exlog:dsapLogger. lines 4-5 capture the timestamps for the log using two subproperties of l2tap:timeStamp and utilizing the Time- line Ontology and xsd:dateTime in lines 7-12. Until now we captured the who and when assertions of the log event. The what of a log event (in this example, DSAP: Data Sharing Agreement Privacy Ontology 7 the privacy policy) is the payload of the event and captured in line 6 using the l2tap:eventData property. Note that the URI that this property is pointing to, is a named graph [6]. The L2TAP core ontology only captures that the body of the event is a graph without speaking about the detail semantics of the triples inside the graph. This L2TAP feature allows the DSAP ontology to be extended to use the L2TAP ontology to capture dynamic semantics of a DSA. We use concepts and relations in the DSAP ontology to describe the log body which is enclosed within a named graph (lines 15-28). Each DSA privacy policy is encoded by the dsap:Policy concept. For simplicity, our data sharing scenario will have two DSA privacy policies. The first registered policy (lines 15- 22) specifies that Bob as a researcher from PU-A is permitted to share genetics data using the dsap:aboutRole and dsap:aboutDataset property. The permis- sion to share data is captured using the dsap:authorizedAction property to a dsap:ShareAction concept (line 18). Lines 21-22 assert that the sharing of genetics data can only happen to publicly funded research captured using the dsap:permittedFunding property. The second DSA policy (lines 24-26) identi- fies that the policy is about Charlie and genetics data which is captured using the dsap:aboutRole and dsap:aboutDataset properties, respectively. The pol- icy further specifies that Charlie is required to destroy the data in line 27 using the dsap:requiredAction property. Line 28 uses dsap:hasDate to indicate that the data must be destroyed at the agreement end date. 1 exlog:logevent3 a l2tap:ParticipantRegistrationEvent; 2 l2tap:memberOf exlog:log1; 3 l2tap:eventParticipant exlog:dsapLogger; 4 l2tap:receivingTimestamp exlog:logevent3-time1; 5 l2tap:publicationTimestamp exlog:logevent3-time2; 6 l2tap:eventData exlog:log-namedgraph3. 7 exlog:logevent3-time1 a tl:Instant; 8 tl:atDateTime "2018-07-01T12:00:02Z"^^xsd:dateTime; 9 tl:OnTimeLine exlog:tlphysical. 10 exlog:logevent3-time2 a tl:Instant; 11 tl:atDateTime "2018-07-01T12:00:03Z"^^xsd:dateTime; 12 tl:OnTimeline exlog:tlphysical. 13 exlog:log-namedgraph3 a rdfg:Graph. 14 exlog:log-namedgraph3 { 15 exlog:policy1 a dsap:Policy; 16 dsap:aboutRole exAgreement:univAResearcher1; 17 dsap:aboutDataset exAgreement:geneticsData. 18 exAgreement:univAResearcher1 dsap:authorizedAction exAgreement:shareData. 19 exAgreement:shareData a dsap:ShareAction; 20 dsap:aboutDataset exAgreement:geneticsData; 21 dsap:permittedFunding dsap:publicFunding. 22 exStudy:publicFunding a dsap:publicFunding. 23 exlog:policy2 a dsap:Policy; 24 dsap:aboutRole exAgreement:univAResearcher2; 25 dsap:aboutDataset exAgreement:geneticsData. 26 exAgreement:univAResearcher2 dsap:requiredAction exAgreement:destroyData. 27 exAgreement:destroyData a dsap:DestroyAction; 28 dsap:hasDate exAgreement:endDate.} Listing 1.1: DSA Privacy Policy Registration Event After the initialization of the log and the registration of participants and privacy policies into an L2TAP log, the researchers can start to share the data. Privacy events that occur during the sharing of data are captured in three steps: 1) Action Request (request for sharing by a data requestor, 2) Action Response 8 Li and Samavi (response to the sharing request by a data sender), and 3) Actual Action (receipt of data by the data requestor). For a complete listings of all events, please see our ontology website (http://l2tap.org/dsap). 4 DSAP Ontology Evaluation We evaluate three aspects of the DSAP ontology: 1) static aspect: its ability to express privacy policies in DSAs, 2) dynamic aspect: its ability to log privacy events during the data sharing process, and 3) application aspect: its ability to answer privacy competency questions. The static aspect of our ontology was evaluated by translating DSA privacy policies into RDF triples. The example shown in Section 3 demonstrates the ability of our ontology to unambiguously capture the static aspect of DSAs. The dynamic aspect of our ontology was evaluated by generating a linked data based privacy audit log for our motivating scenario as described in Section 3. Finally, to evaluate the application aspect of our ontology, a testing environment was set up on Virtuoso 06.01.3127 server1 with quad store installed on 64-bit Ubuntu 14.04 LTS virtual machine with 1GB of memory and one Intel-i5 CPU core. A total of 10,000 RDF triples were generated in the log to mock the amount of activity in a real data sharing scenario. SPARQL queries were run against the populated log to answer privacy competency questions. 1 ASK 2 WHERE{ exlog:accessRequest1 scip:dataSender ?bobRole. 3 ?bobRole dsap:authorizedAction ?bobAuthorizedAction. 4 ?bobAuthorizedAction a dsap:ShareAction. 5 ?bobAuthorizedAction dsap:aboutDataset exAgreement:geneticsData. 6 exlog:accessRequest1 scip:dataRequestor ?requestorRole. 7 ?requestorRole dsap:partOfStudy ?study. 8 ?study dsap:hasFunding ?funding. 9 ?funding a dsap:PublicFunding.} Listing 1.2: SPARQL Query to Answer a Prohibitive Competency Question Listing 1.2 shows the SPARQL ASK statement (line 1) used to answer the pro- hibitive competency question: Is Bob allowed to share the genetics dataset with Charlie?. The statement tests for the existence of RDF triple patterns registered within the L2TAP log returning TRUE or FALSE. Lines 2-3 check for actions that Bob is authorized to perform per DSA. Line 4 checks if any of the authorized action is a ShareAction. Should Bob be authorized to share data, line 5 checks if Bob is authorized to share the genetics dataset that Charlie requested. Since the DSA specifies that the genetics dataset can only be shared with publicly funded research, a check is added to ensure that Charlie is working on a publicly funded research project (lines 6-9). The execution of Listing 1.2 returns TRUE, meaning Bob is permitted to share the genetics dataset with Charlie. Due to limited space in this paper, we present other SPARQL queries on http://l2tap.org/dsap. 5 Related Work Work to translate natural language privacy policies into unambiguous machine language exist [5]. Brodie et al. [5] proposed SPARCLE Policy Workbench as a 1 https://virtuoso.openlinksw.com DSAP: Data Sharing Agreement Privacy Ontology 9 means to parse natural languages into a machine-readable XML expression of policy elements. While the accuracy of this system in parsing healthcare pri- vacy constraints in DSAa is high (≥ 91%) [5], the accuracy is not perfect, so manual intervention and verification is required. Event-B specification language has been adapted by Arenas et al. [2] to express DSA constraints. They rep- resent temporal, protection, and sharing constraints in obligation clauses with linear temporal logic (LTL), a linear sequence of events defined by time. Im- plementation support for this model is available through the Rodin platform (www.event-b.org/platform.html), which utilizes the ProB animator and model checker to analyze the DSA for conflicts and to validate a principal’s actions with obligations outlined in the DSA. Although Event-B can be used for unam- biguously interpretation of DSA conditions, some privacy specific clauses such as purpose definition, could not be expressed with this model. In contrast to the LTL modelling of DSAs, Swarup et al. [20] modelled obligation clauses in DSAs using distributed temporal logic predicates over data resources, data stores and data flows, which allows reasoning about properties of several components of the system for past and future events. Swarup et al.’s DSA framework is also able to express penalties if an obligation is not complied with. Electronic implemen- tation of this framework is underway [20]. One drawback of policy languages is their domain dependency [2,3,15]. The lack of flexibility makes policy languages unable to adapt for data sharing sce- narios across various medical research domains. Moreover, the machine-oriented syntax of policy languages force policy languages to be highly structured and difficult to extend. 6 Conclusion In this paper, we proposed an ontology to address the gap to express privacy constraints in DSAs unambiguously while also allowing flexibility. Our ontology was designed using RDF and RDFS with hierarchical structure to take advantage of transitive closure under inheritance. With the reuse of other ontologies, we showed both the static and dynamic semantics of DSA privacy policies can be captured using the DSAP ontology. Our ontology design suffers from a number of limitations motiviating fu- ture research. The concepts derived in our ontology was limited to only the surveyed DSAs. The confined focus may limit the vocabulary used for our DSAP Ontology’s concepts and relations. The OWL:sameAs property [8] can be used to capture equivalent classes in different research domains that may use different terminologies for DSAs. Moreover, to cover legal terms governing health data sharing within different jurisdictions, the dsap:Jurisdiction con- cept may be extended and the dsap:requiredJurisdictionCompliance prop- erty can be used to capture specific jurisdictional requirements. To make our ontology usable to the medical researcher, an interface shell needs to be devel- oped. The shell can be designed similar to other medical ontology viewers such as the Systematized Nomenclature of Medicine Clinical Terms Ontology Browser (http://browser.ihtsdotools.org/?). 10 Li and Samavi Acknowledgments Financial support from NSERC and help from Andrew Sutton are acknowledged. References 1. Resource Description Framework (RDF). Online (02 2014), https://w3.org/RDF/ 2. Arenas, A.E., Aziz, B., Bicarregui, J., Wilson, M.D.: An event-B approach to data sharing agreements. In: International Conference on Integrated Formal Methods. pp. 28–42. Springer (2010) 3. Aziz, B., Arenas, A., Wilson, M.: SecPAL4DSA: a policy language for specifying data sharing agreements. In: FTRA International Conference on Secure and Trust Computing, Data Management, and Application. pp. 29–36. Springer (2011) 4. Brickley, D., Guha, R.: RDF Schema 1.1. Online (02 2014), https://www.w3.org/ TR/rdf-schema/ 5. Brodie, C.A., Karat, C.M., Karat, J.: An empirical study of natural language pars- ing of privacy policy rules using the SPARCLE policy workbench. In: Proceedings of the second symposium on Usable privacy and security. pp. 8–19. ACM (2006) 6. Carroll, J.J., Bizer, C., Hayes, P., Stickler, P.: Named graphs, provenance and trust. In: Proceedings of the 14th international conference on World Wide Web. pp. 613–622. ACM (2005) 7. David Beckett, T.B.L.: Turtle - Terse RDF Triple Language (03 2011), https: //www.w3.org/TeamSubmission/turtle/ 8. Dean, M., Schreiber, G.: OWL Lite. Online (Feb 2004), https://www.w3.org/TR/ owl-ref/#OWLLite 9. Denny, S.G., Silaigwana, B., Wassenaar, D., Bull, S., Parker, M.: Developing ethical practices for public health research data sharing in South Africa: The views and experiences from a diverse sample of research stakeholders. Journal of Empirical Research on Human Research Ethics 10(3), 290–301 (2015) 10. FreeOnlineWordCounter: Online (Apr 2018), http://countwordsfree.com/ 11. Giunchiglia, F., Zaihrayeu, I.: Lightweight ontologies. In: Encyclopedia of Database Systems, pp. 1613–1619. Springer (2009) 12. Gruber, T.R.: A translation approach to portable ontology specifications. Knowl- edge acquisition 5(2), 199–220 (1993) 13. Grüninger, M., Fox, M.S.: Methodology for the design and evaluation of ontologies. Workshop on Basic Ontological Issues in Knowledge Sharing (1995) 14. Heath, T., Bizer, C.: Linked data: Evolving the web into a global data space. Synthesis Lectures on the Semantic Web: Theory and Tech. 1(1), 1–136 (2011) 15. Kagal, L., Finin, T., Joshi, A.: A policy language for a pervasive computing en- vironment. In: Policies for Distributed Systems and Networks, 2003. Proceedings. POLICY 2003. IEEE 4th International Workshop on. pp. 63–74. IEEE (2003) 16. Lonsdale, D., Embley, D.W., Ding, Y., Xu, L., Hepp, M.: Reusing ontologies and language components for ontology generation. Data & Knowledge Engineering 69(4), 318–330 (2010) 17. O’herrin, J.K., Fost, N., Kudsk, K.A.: Health Insurance Portability Accountability Act (HIPAA) regulations: effect on medical record research. Annals of surgery 239(6), 772 (2004) 18. Samavi, R., Consens, M.P.: Publishing L2TAP Logs to Facilitate Transparency and Accountability. In: LDOW (2014) 19. Samavi, R., Consens, M.P.: Publishing privacy logs to facilitate transparency and accountability. Journal of Web Semantics 50, 1–20 (2018) 20. Swarup, V., Seligman, L., Rosenthal, A.: A data sharing agreement framework. In: International Conference on Information Systems Security. pp. 22–36 (2006)