- From: Harshvardhan J. Pandit <me@harshp.com>
- Date: Tue, 25 Jan 2022 16:20:14 +0000
- To: "Hoekstra, Rinke (ELS-AMS)" <r.hoekstra@elsevier.com>, "public-dpvcg@w3.org" <public-dpvcg@w3.org>
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. Regards, Harsh 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 https://harshp.com/
Received on Tuesday, 25 January 2022 16:20:31 UTC