Re: Mixing classes and instances

Hi Harsh,

Thank you very much for this investigation!

Three comments:

First, there’s one thing that I’d like to correct you on. In [1] state:

“Note that mixing SKOS and OWL for both classes and instances would turn this into OWL-Full and cause issues when using a reasoner, like this:”

This is not correct. OWL2 DL supports “punning”, which means that the semantics of a resource depends on the context in which it is used. So, if I have the axioms:


  1.  ex:A rdf:type owl:Class
  2.  ex:B rdf:type owl:Class
  3.  ex:A ex:relatedTo ex:B

In axioms 1) and 2), ex:A and ex:B are interpreted as part of the T-Box.
In axiom 3), ex:A and ex:B are interpreted as part of the A-Box.

Given that A-Box and T-Box are stratified in OWL DL, the semantics of 1) and 2) vs. 3) do not interact at all.

This means that, when translated to DPV, e.g.:


  1.  dpv:PersonalDataHandling rdf:type owl:Class
  2.  dpv:PersonalDataCategory rdf:type owl:Class
  3.  dpv:PersonalDataHandling dpv:hasPersonalDataCategory dpv:PersonalDataCategory

Axiom 3) does not pertain to the dpv:PersonalDataHandling and dpv:PersonalDataCategory *as classes*, only *as individuals*. Axiom 3) also does not pertain to any of the subclasses of the two.

Note, also, that under OWL Full, this behavior is essentially the same: there is no inheritance between axioms on classes and their instances.

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?

Third comment:

You are right in pointing out the intransitivity of skos:broader/skos:narrower (and I’m also always confused about their direction!). However, these are not super properties of skos:broaderTransitive/skos:narrowerTransitive, they are sub-properties. The code at the bottom of [1] is correct, but the bullet point where you discuss this is not.

Thanks again, this is a great start!

Best,

Rinke


--
Rinke Hoekstra
Lead Architect – Knowledge
ELSEVIER - Amsterdam
r.hoekstra@elsevier.com<mailto:r.hoekstra@elsevier.com>

Emails can arrive at all hours, but at Elsevier we respect your personal time. Feel free to respond to this email during your normal working hours.

From: Harshvardhan J. Pandit <me@harshp.com>
Date: Saturday, 22 January 2022 at 15:59
To: public-dpvcg@w3.org <public-dpvcg@w3.org>
Subject: Re: Mixing classes and instances
*** External email: use caution ***



Hello. I've put down a proposal for expressing DPV as a SKOS vocabulary.
You can find the entire analysis and thought process on my blog [1].
I've put the summary from it here for convenience.

Admittedly, I'm by no means an expert on semantics of SKOS and OWL
mixing together. So I may have missed some obvious implication or
forgotten some crucial piece. If so, please be kind so as to point out
to have us move forward with this discussion.

- `DPV' as an ontology also becomes a `skos:ConceptScheme'
- Core and other top-level classes become `skos:Concept' with
   `skos:inScheme <DPV>'
- Core and other top-level classes are instances of `owl:Class'
- Taxonomies are created using instances of `skos:Concept' and using
   `skos:broader' and `skos:narrower' relationships.
- Properties are declared with domain or range as the appropriate
   top-level class, for example `dpv:hasPersonalData rdfs:range
   dpv:PersonalData'
- What used to be /instances/ of specific concepts are now represented
   as instances of `skos:Concept' and whatever top-level concept they
   represent. For example, as: `ex:MyEmail a dpv:PersonalData,
   skos:Concept' ; To declare what is their closest concept within DPV
   taxonomy, SKOS properties are used thus: `ex:MyEmail skos:broader
   dpv:EmailAddress, dpv:Identifier' .
- T-Box and A-box are kept strictly separate thus making this OWL-DL
   compatible. However, SPECIAL and TRAPEZE's reasoners won't work any
   longer because there are no sub-class relationships. To remedy this, a
   /separate/ serialisation using OWL and using a separate IRI is
   provided.
- For other general uses, SKOS and OWL mixed like this provide a better
   possibility for using as needed, whether requiring property domains
   and ranges, or for further extending concepts and creating instances
   at arbitrary levels of abstractions.
- SKOS provides a lot of useful organisational tools, like
   /ConceptScheme/ which can be further used to group concepts without
   declaring hierarchies. For example, in `LegalEntity', concept schemes
   can be created to separate what is essentially a /legal role/ such as
   a controller from what is a /type/ of organisation such as
   SME. Through this, the actual legal entity taxonomy would be clean and
   not include these categorisation, since /ConceptScheme/ is disjoint
   from /Concept/ within SKOS.

[1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fharshp.com%2Fdev%2Fdpv%2Fdpv-skos-analysis.html&amp;data=04%7C01%7Cr.hoekstra%40elsevier.com%7Ceafa0d222e30401af47708d9ddb7c566%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C637784603646278996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ZeaWBBEI3ZLCQ1od9wezMy4d7YQ26P7o%2FQ1pNUmfNo8%3D&amp;reserved=0

Regards,
Harsh

On 18/01/2022 15:59, Harshvardhan J. Pandit wrote:
>
> So to conclude, there's a proposal on the table to move to SKOS, I
> support/lead it, and we will also provide RDFS and OWL separately as
> alternatives to keep existing adopters/users happy.

--
---
Harshvardhan J. Pandit, Ph.D
Research Fellow
ADAPT Centre, Trinity College Dublin
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fharshp.com%2F&amp;data=04%7C01%7Cr.hoekstra%40elsevier.com%7Ceafa0d222e30401af47708d9ddb7c566%7C9274ee3f94254109a27f9fb15c10675d%7C0%7C0%7C637784603646278996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=R0lPnCgos2R37USgPpbISktWJY5qS%2FjlLz9K44jH%2BVA%3D&amp;reserved=0

________________________________

Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33158992, Registered in The Netherlands.