Make RDFS+SKOS the default serialisation, remove 'DPV/SKOS' concepts

[coolharsh55]

To provide a uniform/consistent application of DPV, to reduce the barriers to understand DPV in terms of serialisations and semantics, to avoid issues such as those in the #112 discussion, and also reduce the amount of maintenance required for each update, the proposal is:

1. RDFS+SKOS, which is currently a separate serialisation of concepts, be made the default and de-facto serialisation of DPV.
2. The existing default serialisation (DPV concepts extended from SKOS) be removed entirely
3. OWL serialisation be provided as an additional file next to RDFS+SKOS rather than as an entirely new specification

This will result in DPV being a single consistent vocabulary expressed using RDFS (classes + properties) and SKOS (hierarchical taxonomy of instances), with an additional variation defined using OWL (classes + properties).

The RDFS+SKOS is suitable as a "drop-in" vocabulary for all sem-web and non-sem-web applications given its intuitive expression. The OWL iteration is suitable for OWL reasoning oriented use-cases, and will still enable interested volunteers to expand it via additional axioms in that specific iteration/file.

Practically, this will require a rewrite of the entire documentation generation stack, which is OKAY as it will reduce work required in the long-term based on the likely acceptance of other major changes in #99 and #107.

An email was sent to the mailing list about this on 19-SEP-2023.

[pmcb55]

I love this - so I 100% agree.

But just out of curiosity, why split out the OWL-specific stuff into a separate thing? I mean, I never use OWL myself or anything (so far anyway), but I've no problem seeing OWL terms, or axioms, or restrictions, or unions, etc., all jumbled in with the pure-RDF(S) vocab stuff.
I guess splitting the OWL stuff out means people who do use OWL can choose to not include DPV's OWL stuff if you do split it out (e.g., maybe if they included it it might screw up other reasoning/inference they want to do), but that's about the only justification I'd see (but not being a strong OWL user, I don't know if that's a real justification or not).

(And I suppose the 'visual clutter' that the OWL stuff adds if your not an OWL person might be a reason too - but as I say above, I don't find OWL stuff in RDF vocabs overly distracting or cluttering - not enough to justify factoring it all out into a separate file anyways.)

I'm just interested in your thoughts - this isn't a big issue at all....

[coolharsh55]

Hi. The reason is a difference in the semantics. tldr; DPV concepts have use both as 'class' and 'instance' - and doing this in OWL is apparently not easy (atleast for me).

# RDFS+SKOS
dpv:Marketing, dpv:DirectMarketing a dpv:Purpose, rdfs:Class, skos:Concept ;
dpv:DirectMarketing skos:broader dpv:Marketing .
dpv:hasPurpose a rdf:Property ; rdfs:range dpv:Purpose .

# OWL
dpv:Marketing, dpv:DirectMarketing a owl:Class .
dpv:Marketing rdfs:subClassOf dpv:Purpose .
dpv:DirectMarketing rdfs:subClassOf dpv:Marketing .
dpv:hasPurpose a owl:ObjectProperty ; rdfs:range dpv:Purpose .

# This is okay in RDFS+SKOS, but not okay with OWL.
# ISSUE - DirectMarketing is a class, not an instance
ex:PDH dpv:hasPurpose dpv:DirectMarketing . 
# This leads people to use 'hacks' like blind nodes - which also are problematic
ex:PDH dpv:hasPurpose [ a dpv:Marketing ] . 
# Or requires OWL-only solutions, such as with this syntax
ex:PDH (dpv:hasPurpose some dpv:DirectMarketing) . # I don't remember the syntax correctly, sorry

# to create custom purposes in RDFS+SKOS
# MyMarketing can be trivially extended e.g. for MySeasonalMarketing 
ex:PDH dpv:hasPurpose ex:MyMarketing .
ex:MyMarketing a dpv:Purpose ;
   skos:broader dpv:DirectMarketing ; skos:prefLabel "This is my marketing"@en .
# to create custom purposes in OWL
# MyMarketing cannot be extended as it is an instance.
ex:PDH dpv:hasPurpose ex:MyMarketing .
ex:MyMarketing a dpv:DirectMarketing ; skos:prefLabel "This is my marketing"@en .

See for more info:

• SKOS vs OWL SKOS version of DPV taxonomy #8 (comment)
• SKOS being easier to handle for alignments Question: Why doesn't DPV reference existing W3C ontologies? #55 (comment)
  1271807183
• thread on mailing list "Mixing Classes and Instances" https://lists.w3.org/Archives/Public/public-dpvcg/2022Jan/0006.html

[coolharsh55]

Further comments from my blog:

• https://harshp.com/dev/dpv/dpv-skos-analysis
• https://harshp.com/dev/dpv/dpv-skos-analysis-2

[coolharsh55]

Discussed in meeting 11 OCT - this will be implemented along with #99 include non-personal data and #107 restructure repo layout.