- From: Harshvardhan J. Pandit <me@harshp.com>
- Date: Wed, 2 Sep 2020 18:43:31 +0100
- To: Piero Bonatti <pieroandrea.bonatti@unina.it>, Data Privacy Vocabularies and Controls Community Group <public-dpvcg@w3.org>
Hello. Some persisting thoughts on this issue and a proposal for solution. tldr; redefine taxonomy using SKOS, keep data model in OWL-DL current problems are illustrated by the below example @prefix : <http://example.com/problem#> . :PersonalDataCategory a owl:Class . :hasPersonalDataCategory a owl:ObjectProperty ; rdfs:range :PersonalDataCategory . :Email rdfs:subClassOf :PersonalDataCategory . :x :hasPersonalDataCategory :Email . the above infers <:Email a :PersonalDataCategory> which takes the data graph into OWL2-Full since :Email is both an instance and a class We should not say that someone should not declare this triple - since someone may want to point to Email as a concept e.g. we collect/use email We also should say only use OWL since it may not be what is feasible or preferable for someone additional problems: 1) a tool populating the value of :hasPersonalDataCategory will not show :Email as an option 2) OWL2-Full means reasoners can be complex in decisions and expensive to run 3) an adopter will do :x :hasPersonalDataCategory [ a :Email ] to get away from this which apart from being ugly also suffers from issues regarding blank-nodes Therefore, a potential solution is to define taxonomies using SKOS and the model using OWL This allows DPV to: 1) permit hierarchy between personal data categories why: broader category of personal data should contain narrower categories by definition i.e. capture the semantics as understood in natural language 2) permit separation of taxonomy and data model why: someone can reuse the taxonomy if they want without bringing in the data model why: someone can easily extend or extract only the taxonomy or only the data model 3) permit range of property to be :PersonalData why: tooling support e.g. automatically populate range why: inferences do not go into OWL-Full e.g. <x> a PersonalData is always asserted rather than inferred 4) this keeps DPV in OWL-DL why: complexity in polynomial time, efficient, computable why: someone importing entirety of DPV doesn't mess up their A and T boxes what breaks due to this change: 1) sub-class inferences are not automatically inferred e.g. in below, EmailID as a sub-set of PersonalData is not inferred without additional rules however, importing SKOS-core and running a reasoner will provide the required triples as: EmailID broader Email ; EmailID broader Communication; 2) instantiation of categories is not preferred e.g. <x> a :EmailID will make EmailID a class which will be 'punning' and take the ontology into OWL2-Full one possible solution is to scope local classes and tie them to skos:Concepts MyEmail a owl:Class , :PersonalData ; skos:broader Email . 3) the ontology is backwards incompatible - but I believe the newer design is better for the future ; plus the ontology can be used in both RDFS and OWL style classes This is what the DPV with SKOS will look like: @prefix : <http://example.com/solution#> . :PersonalDataHandling a owl:Class . :hasPersonalDataCategory a owl:ObjectProperty ; rdfs:domain :PersonalDataHandling ; rdfs:range :PersonalDataCategory . :PersonalDataCategory a owl:Class ; rdfs:subClassOf skos:Concept . :Communication a :PersonalDataCategory . :Email a :PersonalDataCategory ; skos:broader :Communication . :EmailID a :PersonalDataCategory ; skos:broader :Email . what someone wishing to extend the taxonomy can do :MyEmail a owl:Class ; a :PersonalDataCategory ; skos:broader :Email . what somone wishing to adopt SPECIAL's (basis of DPV) vocabularies can do (I think) :PersonalDataHandling a owl:Class ; owl:equivalentClass [ a owl:Restriction ; owl:onProperty :hasPersonalDataCategory ; owl:someValuesFrom :PersonalDataCategory ; ] . Having gone through the bio ontologies, I found that this issue (keeping hierarchies and using them as instances) rarely arises in reflections of the real world because most of the ontologies are based on upper ontologies and have specific instances that need to be referred to. In cases where an ontology does cross over into OWL-Full (e.g. some in OBO), the subset can be extracted to keep the rest of the ontology in OWL-DL. This isn't an option for us since we consider associating a subject with a PersonalDataCategory as 'core' to the ontology. So this is my best guess. Regards, -- --- Harshvardhan Pandit, Ph.D Researcher at ADAPT Centre, Trinity College Dublin https://harshp.com/research/
Received on Wednesday, 2 September 2020 17:43:48 UTC