- From: Harshvardhan J. Pandit <me@harshp.com>
- Date: Mon, 24 Jan 2022 10:36:56 +0000
- 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