Links across DCAT rec, rdf files and namespace pages

[davebrowning]

The draft DCAT-rev (FPWD, editors draft, second PWD) use links in the same way as the 2014 DCAT recommendation does. In general this means that

1. Most links in textual sections (especially if without a namespace prefix such as dct: or dcat:) use intra-document fragment links to the appropriate section in the Recommendation document.
2. Within the vocabulary specification in the Definition, Domain and Range fields, the entries link either to an rdf file (e.g rdfs:literal) or to a textual spec (e.g. foaf:homepage - though this particular link isn't quite precise) or to the namespace document for DCAT (e.g.dcat:Catalog). This last then requires the user to choose from either an Turtle or RDF/XML rendering of the ontology.

In addition, our namespace document at http://www.w3.org/ns/dcat# barely passes muster against the policy https://www.w3.org/2005/07/13-nsuri. More compliant human-readable documents can be found at https://www.w3.org/2009/08/skos-reference/skos.html, https://www.w3.org/XML/1998/namespace, https://www.w3.org/2001/XMLSchema amongst others. [Machine readable versions seem more difficult to find]

As part of moving DCAT-rev forward, I think it would be useful to readers of the recommendation if

• we had a consistent approach to where the links in the document take you - either to a rdf files or to more explanatory documents targeted at humans across all of the references. [Assuming suitable targets can be found, of course]

• We expand the namespace document to make it more useful to users/align with current standards and policies, and to save the extra 'click' needed to get anywhere useful.

I'm looking for a steer here from interested parties on what approach would be helpful, especially where tooling/machine readability may play a role - so suggestions on what we should provide would be extremely useful, as well as any input from the profile guidance work etc.

[davebrowning]

Looking for discussion and opinion on this:

As preparation for any new WD (or candidate rec etc), we should ensure that we are happy that any link use is consistent and useful. This approach in the existing ED is in part as discussed in #671

Within chapter 6 - the Vocabulary Definition, - the linked text in the slot next to RDF Class: or RDF Property heading in each table should point to the W3C /ns/ or to the external reference (FOAF and DC). All other cross-references within the document, including within chapter 6, should point to the relevant section/fragment within Chapter 6

Currently, the links http://www.w3.org/ns/dcat# resolve to the 2014 namespace document. Unless we change the namespace we are using (which I think we have already implicitly ruled out) we will need to replace this with a new one that includes 2014 info, but also adds what we need for DCAT-rev. The simplest approach would be to follow the XML examples here and here - provide some notes on the namespace and links to useful documents such as the REC and the dcat.ttl file. We could go further and follow the skos example which is perhaps more user friendly (essentially it would provide a copy of Chapter 6, plus links back to the REC and any other files) but more work and somewhat circular in its referencing.

I suggest we go for the simple approach and go for something akin to the XML level of information. If anyone has knowledge of what other Working Groups have done that they think would be useful for DXWG to follow then please make the suggestion.

[davebrowning]

The second link-based question is what to do with example ttl files such as csiro-dap-examples.ttl. From the ED, these link to our github repository. For our second public working draft, they link to a locked branch. We need to decide what our approach is for any future PWD and more particularly for the more formal candidate rec/published rec etc. A potential disadvantage of using this approach for REC is that it creates a long term/permanent dependancy on github for the recommendation on the W3C website. [Though many W3C assets/tools do link to github for documentation etc e.g. links from the editors guidebook to respec].

Is it okay to have live links from a (hopefully) published REC to a (locked branch in a) github repo?

@draggett - is there any guidance here? What are our choices?

[davebrowning]

As per discussion in DCAT sub-group meeting, (minuted a little after this) we will continue to use github for example files. To simplify matters further, I'll put together a minimalist namespace page for CR which - if required - we can expand to something more useful in parallel with other future editorial work.

[andrea-perego]

About the namespace URI for DCAT, the new version should indeed replace the existing one, but I think we should keep online the previous version as well.

I would ask the W3C team if they have a way to do this. A possible option is to follow an approach similar to the ones use for TR documents: the namespace returns the latest version, whereas each version has a specific URI - e.g.:

Latest version: http://www.w3.org/ns/dcat#

DCAT 2014: http://www.w3.org/ns/dcat/2014-01-16#

DCAT 2: http://www.w3.org/ns/dcat/2019-XX-XX#

[davebrowning]

Finally got some time to look at this a bit more.

Before I check with W3, I think it might be useful to think through how we expect this to work in the future. What happens if there is a future breaking change to the ontology? In that case, where people have used the latest version URI http://www.w3.org/ns/dcat#, then their use of the vocabulary will be invalid (since it will pick up the new version). That means that any future breaking change would introduce a new namespace - I think this is what happened with ODRL in POE, who use the namespace https://www.w3.org/ns/odrl/2/ for their latest work.)

We plan to just use a version number for the vocabulary (i.e. "2" for now, and then "3", "4" etc,) but the versioning of the namespace would be different to that - it would only clock up when a breaking change was needed for some reason.

In our case, our new ontology for DCAT2 aims to be backwardly compatible with the 2014 vocabulary so we don't need to introduce that namespace versioning - we can and should keep it as is.

@andrea-perego @dr-shorthair @riccardoAlbertoni @pwin @agbeltran - does this sound right to you?

[BTW, its been a while since I checked that we haven't introduced a breaking change by accident......especially with the modularisation, but I'll need a clearer head to do that]

[davebrowning]

See also #881 (comment)

[davebrowning]

Now incorporated - any further new needs/requirements or defects can have there own issue