Keep alt serialisations in the same folder

[coolharsh55]

Currently, the repo has a separate folder for each serialisation, leading to severe duplication (and difficulty in maintaining). I did this early on to have each different serialisation be available in its own folder and with appropriate formats, e.g. DPV-SKOS with ttl, xml and also DPV-OWL with ttl, xml - which were then served from their respective folders. E.g., for DPV-PD, the following exists:

./root
  |-- dpv-pd # default serialisation
  |    |-- dpv-pd.ttl
  |-- dpv-skos/dpv-pd # RDFS+SKOS serialisation
  |    |-- dpv-pd.ttl
  |-- dpv-owl/dpv-pd # OWL serialisation
  |    |-- dpv-pd.ttl

The proposed new structure should be a single folder per work item, e.g.:

./root
  |-- dpv-pd # only ONE folder
  |    |-- dpv-pd.ttl # default serialisation
  |    |-- dpv-pd-SUFFIX.ttl # SUFFIX is an alt serialisation e.g. OWL

Related issues:

• Make RDFS+SKOS the default serialisation, remove 'DPV/SKOS' concepts #113 which dictates what the SUFFIX should be in above example
• Restructure repo layout #107 where this work can be implemented in the same MAJOR change to repo

[TallTed]

I suggest that —

  |    |-- dpv-pd-SUFFIX.ttl # SUFFIX is an alt serialisation e.g. OWL

— be modified to —

  |    |-- dpv-pd.ttl.SUFFIX # SUFFIX is an alt serialisation, e.g., OWL

— or —

  |    |-- dpv-pd.SUFFIX # SUFFIX is an alt serialisation, e.g., OWL

Both maintain the standard filename practice, instead of confusing people who expect to be able to treat any resource which name ends with .ttl as Turtle, its declared media type (if any) notwithstanding.

The former (.ttl.SUFFIX) uses the filename to suggest that this resource is a translation of the .ttl resource.

The latter (.SUFFIX without preceding .ttl) does not use the filename to suggest any relationship between the .ttl and the .SUFFIX via the filename, but hopefully the HTTP headers and/or the resource content will indicate such relationship(s).

[coolharsh55]

Hi. Maybe there is a confusion/miscommunication here? All files ending in .ttl will be in Turtle. Their contents will be reflecting different semantics - which the filename indicates using SUFFIX.

• dpv-pd.ttl is the DPV-PD taxonomy with default serialisation (RDFS+SKOS) expressed using Turtle, and
• dpv-pd-OWL.ttl is the same taxonomy with OWL serialisation expressed using Turtle.

We should not do dpv-pd.owl because .owl is the recommended extension for OWL using XML which would be inconsistent with its Turtle content.

• An option is to have .SUFFIX.ttl but I prefer not to have multiple dots and to keep the convention of filename.ext.
• A more convenient option is to have OWL serialisations only be in XML using the .owl extension - but I think there is also value in having Turtle as an easier human-readable format unless the OWL folks are okay with only having XML.

[TallTed]

Ah.

"Serialization", in my experience, describes the expression of RDF data in one of the materialized RDF media types a/k/a document formats — Turtle, RDF/XML JSON-LD, TriG, etc.

If I understand your last correctly, you meant "serialization" to describe the choice of vocabulary/ontology/taxonomy to be used for the expression of relations -- i.e., RDFS+SKOS (e.g., rdf:type, skos:prefLabel, skos:broader, etc.) vs OWL (e.g., rdfs:subClassOf, owl:equivalentClass, owl:disjointWith) within the taxonomy/ontology/instance-data being expressed in a given document.

Using OWL and SKOS may be helpful in these considerations (though it does not appear to have ever been formally published, not even as a WG NOTE).

I might suggest —

• dpv-pd-SKOS.ttl is the DPV-PD taxonomy described using RDFS+SKOS (default) relations serialized as Turtle
• dpv-pd.ttl is a symlink or HTTP 3xx Redirect to the above
• dpv-pd-OWL.ttl is the DPV-PD taxonomy described using OWL relations serialized as Turtle
• dpv-pd-OWL-SKOS.ttl is the DPV-PD taxonomy described using OWL overlaid with SKOS serialized as Turtle
• dpv-pd-SKOS-OWL.ttl is the DPV-PD taxonomy described using SKOS overlaid with OWL serialized as Turtle

This does potentially represent a fair amount of work on the content, so it might be better to stick with your two documents (plus my symlink), until and unless someone needs the other(s) or just wants to invest the time and effort.... Still, it's worth understanding the above! :-)

[coolharsh55]

Hi - yes (about serialisation, sorry for the confusion). I'll use the suggested naming as -SKOS.ttl and -OWL.ttl with the redirects in w3id config. We haven't done any 'mixing' of SKOS and OWL so far, so the last two won't be generated with the current code.

So far, the only standard I have seen use SKOS and OWL together is ODRL, and it defines a 'flat list' of instances i.e. no hierarchy between them. This isn't feasible for DPV - we rely on the hierarchy. Still, I/We are always open to solutions to address this - so while I'm focusing on the code generation at the moment, people are welcome to propose SKOS/OWL mixing that works with the DPV taxonomies. The links from Ted are a good resource to understand the process (and complexities).

[riannella]

It is feasible to add SKOS Schemes to the ODRL turtle file?

[coolharsh55]

It is feasible to add SKOS Schemes to the ODRL turtle file?

I'm sorry, I don't understand the question. Is it about a DPV file or the ODRL vocab serialisation? If latter, I think it should be okay as ODRL declares SKOS concepts?

[riannella]

Sorry, I was referring to your comment:
So far, the only standard I have seen use SKOS and OWL together is ODRL, and it defines a 'flat list' of instances i.e. no hierarchy between them. This isn't feasible for DPV - we rely on the hierarchy.

ODRL uses "flat" SKOS Collections mostly.
The Actions could be put under "use" and "transfer" as skos narrower terms.
Some temporal/spatial actions use skos broader.

What changes would you recommend to make ODRL more DPV friendly?

[coolharsh55]

What changes would you recommend to make ODRL more DPV friendly?

That's a good (and welcome) question. I think the best answer to this would be through a mapping between ODRL and DPV terms to see if there are gaps and frictions between the concepts (from DPV side as ODRL is an existing standard). We've been trying to slowly word towards having some sort of ODRL compatibility (e.g. by adding Rule in DPV), so mapping is also needed for a gap analysis.

@besteves4 do you want to chime in here as you've worked with both vocabs?

[besteves4]

Hi @riannella :)

One of the first things that comes to my mind is something that we already discussed in a couple of ODRL meetings on the Usage of odrl:eq and odrl:isA operators and missing operator for subclasses and that could be added when we work on an ODRL 3.0.

When it comes to the usage of ODRL with hierarchical-based vocabs, such as DPV, it would be important to have a subclass operator that would allow us to express things such as the "the purpose for doing this action can be any subclass of purpose X".
I understand that odrl:isPartOf could be a solution but it seems like this operator is more suitable to point out that can be any purpose from a provided list of purposes, however, if a certain purpose has 20 subclasses, it is not really computationally effective to list all of them when you could just have an operator that will let you say that it can be any subclass of purpose X.

Additionally, the usage of different operators should be well established in ODRL so that it is easy to understand how new left operands, e.g., coming from DPV, can be easily integrated (in addition to the previously mentioned issue, I also raised this one on negation).

In terms of 1-to-1 alignments of ODRL concepts and DPV's taxonomies, I don't see anything difficult that needs to be changed in DPV to facilitate this -- OAC already does a big part of this mapping and I would be more than happy to integrate any alignments that might be useful and are missing.

[riannella]

Hi @besteves4
Lets discuss this at the Nov 6th ODRL meeting...