Re: Mixing classes and instances

Hi. On further thinking about Rinke's comment regarding not declaring 
the top-level concept as skos:Concept, I think its the correct approach 
to avoid mixing skos:Concept and owl:Class as the suggestions seem to be 
to keep them separate (even if OWL2 permits punning, avoiding it keeps 
DPV simpler).

Based on that, a proposal is to declare the top-level concept as 
owl:Class as well as skos:ConceptScheme which is a disjoint class from 
skos:Concept. This helps make sense of DPV as either OWL or SKOS vocab.

It also makes it possible to have properties point to a concept as 
domain/range with no funny inferences (from punning), and when writing 
examples to 'recommend' how to use DPV in a much simpler and easier 
manner. Example below.

dpv:hasPersonalData a owl:ObjectProperty ;
     rdfs:range dpv:PersonalData .
dpv:PersonalData a owl:Class, skos:ConceptScheme ;
     skos:hasTopConcept dpv:EmailAddress .  # for convenience here
dpv:EmailAddress a dpv:PersonalData, skos:Concept ;
     skos:inScheme dpv:PersonalData .
ex:MyEmailAddress a dpv:Personal Data, skos:Concept ;
     skos:broader dpv:EmailAddress .
ex:PDH dpv:hasPersonalData dpv:EmailAddress .  # as "class"
ex:PDH dpv:hasPersonalData ex:MyEmailAddress . # as "instance"

I tried this model for the following use-case, and the resulting model 
does seem to be easy to explain, doesn't have gotachas, and works as 
expected: Atlantis is a Country. Atlantis City is the capital of 
Atlantis. Data of Atlantians is permitted to be stored only in Atlantis. 
If the data is stored within Atlantis City, we need to demonstrate how 
this is permitted to be stored because Atlantis City is within Atlantis.

dpv:Location a owl:Class, skos:ConceptScheme .
dpv:Country a dpv:Location, skos:Concept ;
     skos:inScheme dpv:Location .
dpv:City a dpv:Location, skos:Concept ;
     skos:inScheme dpv:Location ;
     skos:broader dpv:Country .
# use-case
ex:Atlantis a dpv:Location, skos:Concept ;
     skos:broader dpv:Country .
ex:AtlantisCity a dpv:Location, skos:Concept ;
     skos:broader ex:Atlantis .

Get a list of countries in graph:
query path [ a skos:Concept ; skos:broader dpv:Country ]

To identify whether something occurs within a country, such as to check 
whether data storage is permitted; one can use the transitive path:
query path: [ a skos:Concept ; skos:broaderTransitive ex:Atlantis ]

This maps nicely into database queries and works for both classes and 
instances in the same way. Is also compatible with SPECIAL/TRAPEZE 
reasoners I think (replacing broader with subclass).

To keep existing work functioning (e.g. SPECIAL, TRAPEZE), I suggest 
having a separate namespace for OWL (dpv-owl) where pure-OWL vocabs are 
provided (e.g. dpv-owl/dpv and dpv-owl/pd). This way if both styles are 
mixed, there's no issue of semantic contamination from one to another, 
unless explicitly made by someone.

As to why the 'SKOS' version should be 'primary', I think this is 
because most of the use-cases of DPV are as simpler vocabularies rather 
than as OWL ones.


On 24/01/2022 10:36, Harshvardhan J. Pandit wrote:
>> Second comment:
>> The notion of high level “types” that are instances of owl:Class and 
>> skos:Concept, while others are only instance of skos:Concept to seems 
>> to indicate that these top level types are not meant to be used 
>> directly. Why not then keep those as instance of owl:Class, and have 
>> their instances be skos:Concept?
> Do you mean to say a top-level concept (e.g. PersonalData) should be 
> *only* declared as an owl:Class and its instances should be 
> skos:Concept? If so, then it is desirable to have the top-level concept 
> be an instance of both owl:Class and skos:Concept so as to: (1) include 
> it in the SKOS hierarchy (if someone is using DPV as a SKOS vocab); and 
> (2) include the concept in skos ConceptSchemes and Collections.

Harshvardhan J. Pandit, Ph.D
Research Fellow
ADAPT Centre, Trinity College Dublin

Received on Tuesday, 25 January 2022 16:20:31 UTC