DCAT 1 PID URI incorrect

[davebrowning]

As noted at #1177 (comment),

"The PID URI for DCAT, https://www.w3.org/TR/vocab-dcat/, now redirects to DCAT 2. It means it's now no-longer possible to find DCAT 1 online. "

As should be clear from the subsequent discussion in that thread (where its a bit off-topic) the WG view is that this isn't what we planned - as summarised at #1177 (comment) :

"Yes - the /TR/ URI for DCAT 2 is https://www.w3.org/TR/vocab-dcat-2/
I think the URI for DCAT 2014 is https://www.w3.org/TR/vocab-dcat/"

Is it possible to get this modified ? the document links all look correct, it seems like a webserver config that's needed (speculating here)..

@plehegar, @pwin please advise on how to progress this

[akuckartz]

I dislike https://www.w3.org/TR/vocab-dcat/ pointing to DCAT1 after releasing DCAT2. Why not use https://www.w3.org/TR/vocab-dcat-1/ ?

[makxdekkers]

Changing the URI breaks persistence. If people have referred to /vocab-dcat/, for example linking their profile to DCAT 2014, their link will be broken.

[plehegar]

Due to the TR versioning mechanisms, it's not possible to constraint https://www.w3.org/TR/vocab-dcat/ to DCAT 1 (see also TPAC 2017 plenary day slides). https://www.w3.org/TR/vocab-dcat/ refers to the latest of DCAT, independently of its versions (CR or above). https://www.w3.org/TR/vocab-dcat-1/ refers to the latest of DCAT 1, We can certainly update the DCAT 1 and DCAT 2 documents to make this clearer btw. One can find all of the versions of DCAT as well.

[pwin]

@davebrowning @makxdekkers @dr-shorthair @andrea-perego @riccardoAlbertoni @plehegar @agbeltran @agreiner Do we need a meeting to resolve this? It looks like the TR versioning mechanism will not allow what we were originally thinking. Please vote and I'll set one up if there is interest.

[agbeltran]

happy to participate in a meeting about this

[davebrowning]

Also happy to participate, if we can find a convenient time.

Having read the slides linked to above as well as the info that the slide links to, it seems to me that what's happening here nearly fits quite well with what we want - users can choose to reference the 'sequenced' standards such as https://www.w3.org/TR/vocab-dcat-1/ to refer to the latest of DCAT 1, or https://www.w3.org/TR/vocab-dcat-2/ to refer to the latest of DCAT 2 etc, while if users are happy trusting our story about backward compatibility then they can use https://www.w3.org/TR/vocab-dcat/. We should definitely explain that in the docs though.

My concern is that https://www.w3.org/TR/vocab-dcat/ doesn't point at a REC today/at this point in the process, but rather at PR (and presumably did at CR too). If that was deemed appropriate behaviour by the plenary/AC (or at least they did not disagree) then ....okay... 😐

[plehegar]

Links like https://www.w3.org/TR/vocab-dcat/ aren't reliable enough nowadays if one wants to link to a Recommendation. Different groups have different interpretations of those links and external parties add their own interpretation on top of that. It has been proposed to use https://www.w3.org/TR/vocab-dcat/rec instead and I'm trying to find out what happened to that proposal. At the end, one can always reference a dated version of a document if they want the guarantee of the stability of the link.

[pwin]

I think that we need to look forward rather than backward and recognise that many of the users of v1 are likely to be those within Europe dealing with open data etc, and that they will be being encouraged on a migration to DCAT-AP v2 ( https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe/release/200 ) .  I'm not sure what Zenodo's policy is, though I can't imagine it would stick around with v1 if it had the opportunity of registering APIs as well as storing files.

[makxdekkers]

To me there are three elements here:

1. The URI policy. As we are under the umbrella of W3C, we have no choice in the matter. If URIs like https://www.w3.org/TR/vocab-dcat/ must point to the latest version, that's what it will do. The only thing we can do is make sure that the Previous version link points to the previous recommendation at https://www.w3.org/TR/2014/REC-vocab-dcat-20140116/.

2. What URI is used by external parties to link to a particular (version of the) document. I have always argued that people should never link to the generic URI, unless they are very sure they really want to link to the 'latest version'. Fortunately, the specification of the EU DCAT-AP refers to https://www.w3.org/TR/2014/REC-vocab-dcat-20140116/, so that link will remain to be valid.

3. Whether we should 'deprecate' older versions. My opinion is that there is no real need to do that, as DCAT2014 remains entirely valid. I don't think it is up to us to tell people what to do, especially if they don't have a need for the new bits in DCAT2. I would prefer a note with forward link in DCAT1 to make people aware that there is a newer version, and a backward link from DCAT2 to DCAT1. What I could agree with is to give DCAT1 an explicit 'superseded' status. Please not 'deprecated' because that, to me, carries the opinion that it is somehow 'wrong' to have a DCAT1 implementation.

[plehegar]

Previous version will need to go to the Proposed Recommendation of DCAT 2. Instead, I suggest replacing the "Latest Recommendation" with a "Previous Recommendation" entry that would go to DCAT 1..

[riccardoAlbertoni]

+1 to supersede DCAT 1 and replace "Latest Recommendation" with a "Previous Recommendation"

[dr-shorthair]

+1

[riccardoAlbertoni]

@plehegar wrote:

Previous version will need to go to the Proposed Recommendation of DCAT 2. Instead, I suggest replacing the "Latest Recommendation" with a "Previous Recommendation" entry that would go to DCAT 1..

I haven't found a proper configuration property in https://github.com/w3c/respec/wiki to express the Previous Recommendation via config.js.

Any suggestion?

[agbeltran]

perhaps @plehegar can help with that?

[riccardoAlbertoni]

After some testing, it seems that "Latest Recommendation" can be switched in "Previous Recommendation" changing the specStatus: "ED", into specStatus: "REC",
see the result at https://raw.githack.com/w3c/dxwg/dcat-issue1182-ric/dcat/index.html

However, doing so, recspec returns a new error "Recommendations must have an errata link."
Only small progress, tonight ... ;)

[agbeltran]

@riccardoAlbertoni I added an errata link as per https://github.com/w3c/respec/wiki/errata and now the error has been resolved. I guess we need to create an empty errata document for now? (the link I added gives 404 for now)

[agbeltran]

Checking this recent REC https://www.w3.org/TR/2019/REC-css-writing-modes-3-20191210/, the errata is empty with some basic info (https://www.w3.org/Style/2019/REC-css-writing-modes-3-20191210-errata.html).

[andrea-perego]

I wonder whether there's a template also for errata docs.

@plehegar , could you help here?

[agbeltran]

I found this: https://github.com/w3c/display_errata

[riccardoAlbertoni]

@agbeltran:

I found this: https://github.com/w3c/display_errata

I like this, I am in favor of using it.

[andrea-perego]

Thanks for the hint, @agbeltran .

I've just created a draft PR (#1209) following the instructions in https://github.com/w3c/display_errata, and by creating an errata/ folder in the DXWG repo.

Preview here:

https://raw.githack.com/w3c/dxwg/andrea-perego-dxwg-errata/errata/index.html

[andrea-perego]

BTW, as the errata document is going to cover all DXWG Recommendations, although for the moment the only one is DCAT I think going ahead requires endorsement from the whole WG.

/cc @pwin , @kcoyle , @cburle

[riccardoAlbertoni]

I see advantages in promoting a uniform strategy for collecting the errata between the distinct RECs the group is producing, as proposed in the document prepared by @andrea-perego.

Note that different working groups have already adopted the same strategy for their RECs, including the Web Annotation Working Group, see https://github.com/w3c/display_errata#examples for a list

I think we do not want any delay with publishing DCAT V2, so it would be important to know asap if there is anyone objecting or feeling particularly unsure about such adoption.

[agbeltran]

@andrea-perego I haven't tested it, but it seems to me that it should be possible to include an errata document per spec (and thus per folder) and then use two labels to tag the issues (for DCAT, 'Errata' and 'dcat', associating the errata document with https://github.com/w3c/dxwg/issues?utf8=%E2%9C%93&q=label%3AErrata+label%3Adcat)

If that doesn't work, we should split the repo, which I understand we'll be doing anyway

[andrea-perego]

@agbeltran , in such a case, it should be enough having a folder for each spec on rec track. The only issue is that the errata template includes a section about errata not associated specifically with any spec - which I think it should be useful to have.

In any case, I won't go for the option of splitting the repo - at least, not only for this reason.

Said all that, I think it would be better to stick to the solution of having 1 errata document shared for all DXWG specs on rec track, also because the errata documents should be consistent across specs - and in such a case having multiple errata documents does not add much value, IMO.

[agreiner]

I don't care whether we treat the errata as for all our docs or just one at a time, as long as it's easy for people reading a specific doc to find errata for it. The suggested approach seems fine to me.

[agbeltran]

I agree that it would be better that it is clear what errata corresponds to each spec - a solution may be using a combination of labels (as I mentioned before)

[riccardoAlbertoni]

I would suggest closing this git issue and include any future discussion about the errata documents (especially for the other recommendations) under #545, which is specifically about the management of errata docs.

Short Summary:
-The group has prepared an errata page for DCAT 2; the discussions about errata we've had here have been linked to #545 for future reference.
-The "previous rec" link will become visible as soon as the document status is changed to REC.

[andrea-perego]

+1 from me.