Re: DPV semantics: how to specify values?

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