- From: Harshvardhan J. Pandit <me@harshp.com>
- Date: Tue, 22 Sep 2020 22:58:39 +0100
- To: public-dpvcg@w3.org
Hello All. Some additional thoughts on this. I ran DPV against the OWL Profile checker [1] and found some violations regarding OWL2-DL profiles, particularly in the use of property range assertions e.g. xsd:boolean and owl:unionOf. Removing these seems to resolve the issues. On similar lines, the issue we have arises because we *assert* using rdfs:range that objects in a triple *must* be individuals of a class. To me, this is not accurate in what we want to represent. E.g. `X collects EmailAddress` when asserted as a triple should mean exactly that, and should not mean `X collects something whose type is EmailAddress`. OWL2 Punning allows this, and is conformant to OWL2-DL AFAIK: :X dpv:hasProcessing dpv:Collect . :X dpv:hasPersonalDataCategory dpv:EmailAddress . Here, even though EmailAddress is declared as a class in DPV, its use as an individual is OK under OWL2-Punning. The larger issue is the assertion that range of dpv:hasPersonalDataCategory is dpv:PersonalDataCategory, which gives the inference: dpv:EmailAddress a dpv:PersonalDataCategory . dpv:EmailAddress rdfs:subClassOf dpv:PersonalDataCategory . And these are still valid in OWL2-DL AFAIK, since use of punning where class = individual is allowed. Even though this may seem like nonsense, it is valid semantics, though not to be used in practice. Similar to rdfs:Class being a subclass and instance of rdfs:Resource. What is not-allowed in punning is this: :X dpv:hasPersonalDataCategory "Email Address" . Since it is equating Object and Datatype properties in punning, which is not valid in OWL2-DL. So I would propose removing range assertions from properties, thus preventing inferences where something is an individual and subclass of the same class, or removing the subclass assertions in the taxonomy and switching to SKOS. Of course, removing range assertion would be the preferred and less destructive choice. This approach has the added advantage that some of the properties associated in technical and organisation measure as well as consent can be applied elsewhere as required. For example, location or duration have a much broader scope than data - also applicable to processing for example. Lastly, I feel writing triples directly relating classes as in the examples above is much more intuitive and closer to natural language than other options. [1] https://github.com/stain/profilechecker/ On 03/09/2020 07:46, Víctor Rodríguez Doncel wrote: > Dear Harsh, > > 1) I believe making a taxonomy is an interesting enterprise /per se/, > but it entails some additional work and it is a very important change > over the previous work. > If you want to better define the ontology as a data model... why dont > you define some RDF Shapes instead? This would be far more practical. > Also, we may want to specify a cookbook with the most common patterns of > use. > > 2) Not important and I am totally out of context but in the example > below... doesn't make sense simply declaring this? > :x a :Email . > > Víctor > > El 02/09/2020 a las 19:43, Harshvardhan J. Pandit escribió: >> 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, >> > > > -- > Víctor Rodríguez-Doncel > D3205 - Ontology Engineering Group (OEG) > Departamento de Inteligencia Artificial > ETS de Ingenieros Informáticos > Universidad Politécnica de Madrid > > Campus de Montegancedo s/n > Boadilla del Monte-28660 Madrid, Spain > Tel. (+34) 910672914 > Skype: vroddon3 > http://cosasbuenas.es > -- --- Harshvardhan Pandit, Ph.D Researcher at ADAPT Centre, Trinity College Dublin https://harshp.com/research/
Received on Tuesday, 22 September 2020 21:58:55 UTC