Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DCAT 1.1 URL in W3C space #184

Closed
andrea-perego opened this issue Mar 29, 2018 · 26 comments

Comments

@andrea-perego
Copy link
Contributor

commented Mar 29, 2018

The URL currently in the ED is: https://www.w3.org/TR/dcat-1-1/

I wonder whether, according to W3C naming conventions for vocabulary TRs, it should instead be:

https://www.w3.org/TR/vocab-dcat-1-1/

It would important to check this before we go for FPWD.

@akuckartz

This comment has been minimized.

Copy link

commented Mar 30, 2018

Is that naming convention documented anywhere?

@andrea-perego

This comment has been minimized.

Copy link
Contributor Author

commented Mar 30, 2018

Is that naming convention documented anywhere?

I don't know if it is documented somewhere. Just noted a consistent pattern (although there are exceptions):

@philarcher

This comment has been minimized.

Copy link

commented Mar 30, 2018

No, it's not documented (IIRC) and not a hard and fast rule but it is the convention for this kind of thing as Andrea points out. Short URLs in /TR space need Director approval (see @draggett for details). Mind you, there's also https://www.w3.org/TR/odrl-vocab/ and others that way round.

One thing I found surprising is that the RDF 1.1 specs have URls like https://www.w3.org/TR/rdf11-primer/ i.e. with 1.1 represented as 11. I take this as an indication that RDF 11.0 is unlikely to happen before the heat death of the universe.

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2018

I've altered the config.js to match, but I'm not sure if the rec URI should change or not. Also, I just took a punt on 1.1 being the version - I think that is our intention, but if things got really wild it could go to 2.0 ...

Clearly we will need some guidance from @draggett on these details prior to publication.

@andrea-perego

This comment has been minimized.

Copy link
Contributor Author

commented Mar 30, 2018

@dr-shorthair said:

I've altered the config.js to match, but I'm not sure if the rec URI should change or not. Also, I just took a punt on 1.1 being the version - I think that is our intention, but if things got really wild it could go to 2.0 ...

Considering the discussion around broadening the scope of dcat:Catalog (if not of DCAT itself), probably we should seriously consider going for 2.0 (vocab-dcat-2).

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2018

Yeah - you have a point. And dotty version signifiers are very prone to (mis-)interpretation as well.
There are W3C precedents in several directions.

HTML is at v5 - I think this was due to the progressive addition of features.
OWL went to v2 - I think this was because of incompatible changes.
XML, XML Namespaces, XSD and almost all the RDF recs are just at v1.1 - I think this was mostly clarifications and tweaks rather significant change in scope or extra features, but there may have been a bit of the latter.

I guess if we extend the scope of DCAT then that means there is an incompatibility between new DCAT instances and the old DCAT schema. So if that is the criterion, then v2 is required.

@akuckartz

This comment has been minimized.

Copy link

commented Apr 2, 2018

HTML is at v5

HTML almost silently progressed to 5.2: https://www.w3.org/TR/html52/

@makxdekkers

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2018

I think we need to have an in-depth discussion about the versioning of the specification. For the time being, until we have decided on the approach, I'd suggest not to use numbers at all, but to call the FPWD a 'revision of DCAT' and use a URI like https://www.w3.org/TR/dcat-rev/.

There are three possibilities:

  1. No version numbering at all. Just call it DCAT and provide a date of last modification in the document metadata.
  2. Call it version 1.1, which seems to imply minor semantic changes.
  3. Call it version 2.0, which seems to say that it is incompatible with the existing specification.

Option 1 is the approach at DCMI. This of course implies that there is complete backward compatibility between specifications. Any implementation that uses any version of the specification is fully compatible, although newer versions might use things (e.g. new properties, updated external standards for controlled vocabularies) that weren't in previous versions but it really doesn't affect interoperability.

Option 2 (version 1.1) might mean that applications compliant with version 1.0 are still fully compliant with version 1.1, although applications that implement version 1.1 may use things that were not in version 1.0. If an application of version 1.0 receives data from a version 1.1 application, it may get things (e.g. new property) it does not understand, but it is perfectly OK to ignore those. On the other hand, anything that was defined in version 1.0, should behave exactly the same in version 1.1. An application implementing version 1.1 should be able to fully understand data that is based on version 1.0.

Option 3 (version 2.0) might be an indication that an implementation of version 1.0, will not be able to interoperate with an application based on version 2.0.

For each of the changes we are working on, we need to determine how they relate to these three options and then decide what we want to do.

In is important to note that option 3 will lead to a split between the universe of version 1.0 implementations and the universe of version 2.0 implementations. The question is whether implementers will see sufficient reasons to upgrade from version 1.0 to 2.0 to justify the additional investment.

If at all possible, I would suggest we try to stay within the boundaries of options 1 or 2, and only go for option 3 if it is absolutely necessary. If option 3, we may need to get feedback from current implementers to see if they would plan to upgrade.

@makxdekkers

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2018

Concerning namespaces, I think that in options 1 and 2 the namespace could still be http://www.w3.org/ns/dcat, whereas version 2.0 might require a new namespace like http://www.w3.org/ns/dcat2.

@andrea-perego

This comment has been minimized.

Copy link
Contributor Author

commented Apr 2, 2018

Thanks, @makxdekkers .

Backward compatibility is indeed crucial. The new DCAT can have new things - and a wider scope -, relax domain and/or range restrictions, deprecated terms, but this must not affect backward compatibility. And I think this is also in line with the (unwritten?) W3C rules for vocabularies.

If using "version 2" may give the wrong message that the new DCAT is not compatible with the original one, I'm happy with "version 1.1".

I'm also happy with the idea of using the "rev" string (or another keyword). In this case we should probably add a revision number, e.g.:

https://www.w3.org/TR/vocab-dcat-rev1/

But the vocabulary namespace must be the same:

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

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2018

It looks like this will need a bigger discussion.

In order to have a FPWD that is consistent and does not prejudice the final decision, in PR #187 I've changed all references to the original DCAT to 'DCAT 2014' and all references to the revisions to 'DCAT revision' or 'DCAT Revised edition'.

@andrea-perego

This comment has been minimized.

Copy link
Contributor Author

commented Apr 3, 2018

@dr-shorthair , I wonder whether we should ask @kcoyle & @pwin to add a specific item on this topic in the agenda for today's plenary call, maybe before the FPWD one (it is more general than the item on the DCAT FPWD, and it may affect the relevant resolution).

@akuckartz

This comment has been minimized.

Copy link

commented Apr 3, 2018

There is also the questions of what happens when a URL is accessed/dereferenced: What about content negotiation? Do there need to be different URLs for human / machine readable specifications? Why?

@makxdekkers

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2018

As far as I understand, W3C specifications are in /TR/ space, while namespace documents are in /ns/ space. Both these spaces are separately mentioned in the W3C Persistence Policy at https://www.w3.org/Consortium/Persistence. I think this means that human and machine-readable specifications will have different URIs. However, it would be nice if http://www.w3.org/ns/dcat would internally redirect to the latest DCAT spec if accessed by a browser.

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2018

Added to Apr 3 agenda.

@agbeltran

This comment has been minimized.

Copy link
Member

commented Apr 3, 2018

I agree that this needs further discussion in today's meeting. The original DCAT version was not numbered (https://www.w3.org/TR/vocab-dcat/) and we need to consider the implications of changes, as pointed by @makxdekkers. We will need a broader scope in several classes (including dcat:Catalog as mentioned by @andrea-perego but I think also dcat:Dataset). Until those issues are defined, I agree it might be best not to include a version number (and we need to remove references to 1.1. in https://w3c.github.io/dxwg/dcat/).

@akuckartz

This comment has been minimized.

Copy link

commented Apr 3, 2018

My input as a user: abolish version numbers.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2018

Having two URIs for "the same thing" is probablematic for citation - and particularly machine processing - if these are different URLs for different representations, fine, but what is the URI? In the case of redirecting the /ns to the /TR when HTML is asked for, the /ns is the URI, the text rendering of the specification is a URL at /TR. What if the spec has more constraints in the text than the namespace doc has? (IMHO this is a content negotiation by profile issue - different profiles of the same data have different expressivity as a given). Good to work the logic of this through from the perspective of a universe of DCAT instances and use cases of discovery, advertising profile conformance - say during harvesting, and validation using machine readable resources.

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

commented Apr 4, 2018

For now the key requirement is a URI for the HTML for the draft revision which is different to the 2014 Recommendation. That's what we were resolving this morning. As noted by @philarcher, when we get closer to completion we will have a clearer idea about whether it is (a) a replacement in-place, or (b) a new thing in a new place.

URIs for the RDF representation will also come into play of course.
At the moment there is conneg at https://www.w3.org/ns/dcat which only go to the 2014 version.
Each profile will need its own URI of course.

FWIW I've also updated and renamed the RDF file that has the dropped axioms here:
https://github.com/w3c/dxwg/blob/dcat-dcatversion-simon/dcat/rdf/dcat2014.ttl
Only in GitHub for now @rob-metalinkage - a decision where/how to publish formally not yet determined.

@draggett

This comment has been minimized.

Copy link
Member

commented Apr 5, 2018

My understanding is that we want to replace the existing DCAT Recommendation, and as such it seems not unreasonable to publish the First Public Working Draft under the same specification short name that serves to link to the latest published specification. This URL is:

The Status of This Document for the new draft would explain our intent and link to the existing Recommendation. How we handle versioning can be treated as a separate issue, and something we can address within the new specification.

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2018

https://www.w3.org/TR/vocab-dcat/ is currently the URL for the 2014 document. What happens with it?

@draggett

This comment has been minimized.

Copy link
Member

commented Apr 5, 2018

The https://www.w3.org/TR/vocab-dcat/ points to the latest spec, so as we're updating DCAT it would point to the latest version of our spec. We would include a pointer to the 2014 REC along with an explanation.

@andrea-perego

This comment has been minimized.

Copy link
Contributor Author

commented Apr 5, 2018

@draggett , is there a precedent for this? In the examples I'm aware of, usually the new version is published at a different URL, and an alert is added to the previous version - see, e.g.:

RDF Concepts and Abstract Syntax: https://www.w3.org/TR/rdf-concepts/

RDF 1.1 Concepts and Abstract Syntax: https://www.w3.org/TR/rdf11-concepts/

Moreover, considering the wide use of DCAT 2014 (which is usually referred to with the unversioned URL), this seems to me the safest option.

@draggett

This comment has been minimized.

Copy link
Member

commented Apr 8, 2018

The idea of the undated URL is that it points to the latest version which in this case would be the Working Draft for the specification we want to replace the 2014 DCAT Recommendation. If I am wrong and we envisage the new and old Recommendations to live on side by side, rather than the new one superseding the older, then a new URL short name is needed.

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2018

Hmm. I think we are comfortable with the expectation that, when completed, the revised DCAT Rec would replace the 2014 version in place. However, it's a very drafty draft at present! What will the headers look like? Will it be obvious that
(i) while the doc they are looking at is FPWD (which explains its drafty look)
(ii) the predecessor document is the 2014 Recommendation (which should continue to be consulted until the revision is completed)

And what would happen if the revision, for some reason, did not make it to Rec? Would the document that temporarily appeared at the /TR/ location be removed, and the 2014 version re-installed at the /TR/ URL?

@dr-shorthair dr-shorthair added this to In progress in DCAT revision Apr 26, 2018

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

commented May 30, 2018

I think this was resolved OK for the time being in the edits done for the FPWD.
No doubt the namespaces and 'current version' issues will be revisited later, but lets do that under a new issue when it comes up.

DCAT revision automation moved this from In progress to Done May 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.