Re: DPV semantics: how to specify values?

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