DPV as a family of languages

Hi All. Some (important) updates.

# DPV family of languages

https://harshp.com/dpv-x/primer/ is a work-in-progress reporting of the 
below. You can read Sections 2 and 3 for relevance.

Upon extensive (and exhaustive) discussions about the serialisations of 
DPV, its usefulness and impacts on use-cases, and considering 
practicality and feasibility, we're reached upon the following decision.

1) DPV is to be an 'abstract model' (similar to ODRL or PROV)
2) DPV-SKOS is to be provided as a serialisation using SKOS (+ RDFS)
3) DPV-OWL is to be provided as a serialisation using OWL

DPV makes no assumptions or assertions, and just provides the concepts 
(including relationships). Its serialised using SKOS.

DPV-SKOS is preferable where DPV is needed as a lightweight schema or 
ontology without the full flexibility / power of OWL2. This includes use 
in annotations, records, simpler inference (parent-child, property 
range) etc.

DPV-OWL is preferable where DPV is needed to express policies or with 
logical assertions related to verifiability, correctness, reasoning, etc.

If someone needs to use DPV in another form than SKOS or OWL iteration, 
or want to craft their own separate model, they can use the DPV 
specification to implement it in their language / technology of choice.

# Documentation

In the longer term, IMHO this is a good decision to keep take DPV 
towards a standardisation track, which I ambitiously hope to do. It 
makes addition of concepts much much simpler because these are directly 
added to DPV (main spec), and from there interpreted in some semantics 
(i.e. SKOS or OWL). Given that a lot of contributors are not 
semantic-web experts, this also helps with capturing decisions and 
discussions of concepts within the group.

This separation also helps create 'profiles' or 'applications' of DPV 
towards specific use-cases or applications by using the main DPV 
specification, since it doesn't have any restrictions in terms of how 
concepts and properties are used. These can be then be 'correctly' 
serialised into something (e.g. OWL).

It increases the work to produce the documentation, but only for the 
manual writing of guidelines / best-practice type stuff. The actual 
generation of RDF and turning it into HTML documentation is pretty much 
automated at this point 
(https://github.com/w3c/dpv/tree/master/documentation-generator) - which 
makes it easier.

# Namespaces

For obvious reasons, each serialisation is expected to have a separate 
namespace to avoid mixing semantics or introducing confusion. Requesting 
w3 namespaces and keeping them updated seems to be a lot of time. We can 
use w3id.org to get a namespace for DPV, which are community maintained 
and have fast updates (~1 day).

# Expected Delivery

Given that there were very few comments on this issue (serialisation of 
DPV) and on the Primer, I think I've addressed them. I was waiting on 
issuance of namespaces, but if using w3id seems a valid option, I'm 
expecting to have the DPV v0.4 produced by this week. I'll discuss this 
in the meeting call on (this) WED.

If you want to help/contribute towards some of this stuff, let me know.

Regards,
-- 
---
Harshvardhan J. Pandit, Ph.D
Research Fellow
ADAPT Centre, Trinity College Dublin
https://harshp.com/

Received on Monday, 7 February 2022 19:42:26 UTC