W3C home > Mailing lists > Public > public-dpvcg@w3.org > January 2022

Re: Mixing classes and instances

From: Harshvardhan J. Pandit <me@harshp.com>
Date: Mon, 24 Jan 2022 10:36:56 +0000
Message-ID: <fa689333-a4b9-75be-f8ba-1acaa4826b3a@harshp.com>
To: "Hoekstra, Rinke (ELS-AMS)" <r.hoekstra@elsevier.com>, "public-dpvcg@w3.org" <public-dpvcg@w3.org>
Hi Rinke. Thanks for your reply. My comments are inline.

On 24/01/2022 08:57, Hoekstra, Rinke (ELS-AMS) wrote:
> 
> “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:
> 
> Note, also, that under OWL Full, this behavior is essentially the same: 
> there is no inheritance between axioms on classes and their instances.

Okay, I'm aware punning is permitted, but we're going to have a lot of 
punning everywhere in that case. Your example only dealt with OWL, not 
the SKOS parts, which is important because what that results in is 
equivalence between skos:Concept and all classes and instances. If 
someone is okay with this kind of OWL2 punning, then maybe this is fine, 
but I would think its a lot of complexity for no real benefit when there 
is a better way (e.g. the SKOS proposal).

Otherwise what you're suggesting is how the DPV is kind of stuctured 
right now (i.e. only OWL). I tried finding an answer regarding 
compatibility of OWL and SKOS (semantically), but there's nothing 
definitive other than "use at your own peril" type statements.

For DPV, I think we should prefer something that is consistent and known 
(i.e. how it works), and which won't require a lot of effort to pick up 
and use in different kinds of use-cases.

> 
> 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.

> 
> 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.

Ah yes, this was because I had written about skos:SemanticRelation which 
is the parent property of all relations between concepts, but decided 
its not relevant to DPV discussion and removed it. Thanks for the 
pointing this out, I've edited the text to make it clearer.

Regards,
-- 
---
Harshvardhan J. Pandit, Ph.D
Research Fellow
ADAPT Centre, Trinity College Dublin
https://harshp.com/
Received on Monday, 24 January 2022 10:37:12 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:28:01 UTC