search

w3c / dxwg

Data Catalog Vocabulary (DCAT)
https://w3c.github.io/dxwg/dcat/
Other
150 stars 47 forks source link

Are we superseding DCAT 1 or not once DCAT 2 is a REC? #1177

Closed pwin closed 4 years ago

pwin commented 4 years ago

There is a status of recommendation document - "Recommendation Superceded" which is described at https://www.w3.org/2019/Process-20190301/#rec-rescind [there is interesting discussion about this at https://github.com/w3c/w3process/issues/36 ]

Please can we discuss here. Do we want to supercede DCAT v1?

makxdekkers commented 4 years ago

The question for me is whether there is a strong incentive to move people from DCAT1 to DCAT2. In my mind, DCAT1 remains valid and if people don't have a need for the new bits in DCAT2 (e.g. Data Services, geo-stuff, time intervals, qualified relations, packaging etc.), they may not need to upgrade. So, I would say that we don't have to make DCAT1 a superseded recommendation, just link from DCAT1 to DCAT2 indicating that there is a newer version.

nicholascar commented 4 years ago

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. Is this as intended?

dr-shorthair commented 4 years ago

I'm leaning towards Makx view - perhaps with some nuances.

  1. There is just one 'DCAT' and one dcat: namespace.
  2. There are two descriptions of it, one which has additional features.
  3. Existing DCAT users don't need to change anything to remain in conformance with DCAT.
  4. The DCAT 2014 document describes what is essentially a 'profile' of (current) DCAT, which is currently reflected the DCATv2 document but will evolve more.

I wonder if a note could be added to DCAT 2014 explaining that it is a profile of DCAT?

dr-shorthair commented 4 years ago

It means it's now no-longer possible to find DCAT 1 online.

Apart from the DCAT 2014 document, @davebrowning does the NS document have a link to the old RDF representation?

davebrowning commented 4 years ago

It means it's now no-longer possible to find DCAT 1 online.

Apart from the DCAT 2014 document, @davebrowning does the NS document have a link to the old RDF representation?

The draft updated NS document (which isn't published yet) does have a link to a copy of the old rdf -which it assumes is renamed dcat2014.rdf (as per the naming in github).

Of course, we could make the "DCAT 2014 is a profile of DCAT" more explicit on that page.

davebrowning commented 4 years ago

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. Is this as intended?

That's a surprise to me at this stage in the process, so I certainly didn't intend that. [You can get to DCAT1 from the PR, of course but that's a bit silly] . I'd assumed that that wouldn't happen, certainly not till final publication and after this conversation.

Generally, I agree with the Makx/Simon approach, its just how we sign post that. (So I think that means we're not superceding.....)

akuckartz commented 4 years ago

Maybe DCAT1 can be declared deprecated as soon as DCAT2 has become a Recommendation?

andrea-perego commented 4 years ago

@pwin said:

There is a status of recommendation document - "Recommendation Superceded" which is described at https://www.w3.org/2019/Process-20190301/#rec-rescind [there is interesting discussion about this at https://github.com/w3c/w3process/issues/36 ]

IMO, stating that DCAT2 supersedes DCAT1 should not be a big problem (as DCAT2 is backward compatible with DCAT1). Said that, I am perfectly happy also with the other proposal, outlined by @makxdekkers in https://github.com/w3c/dxwg/issues/1177#issuecomment-557919538

I am more concerned about the issue reported by @nicholascar in https://github.com/w3c/dxwg/issues/1177#issuecomment-557939410 :

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. Is this as intended?

I don't think this should be the right behaviour: the DCAT1 spec should be still accessible at its URL, and no redirection should be in place.

dr-shorthair commented 4 years ago

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

nicholascar commented 4 years ago

So it looks like the redirect from https://www.w3.org/TR/vocab-dcat/ to https://www.w3.org/TR/vocab-dcat-2/ just needs to be broken and for https://www.w3.org/TR/vocab-dcat/ to have a note at the top as OWL Features does re OWL2: "New Version Available: OWL 2". There doesn't seem to be a status change from just plain Red in the OQL1 docs, just that note.

riccardoAlbertoni commented 4 years ago

I would in favour of "superseding" DCAT 2014. This, in my opinion, is not in contrast with Makx's view and does not force users to update, (I am afraid no one has such a strong power;)). Superseding DCAT 2014 do not remove DCAT 2014 from the web (the https://www.w3.org/TR/vocab-dcat/ remains available with a warning forwarding to the new specification), and the existing metadata descriptions which were compliant to DCAT 2014 will remain compliant to it.

However, It is important to make clear that we recommend the new solutions provided by DCAT 2 for requirements that were not considered or were underrepresented in the previous DCAT, such as those related to Data Services, geo-stuff, time intervals, qualified relations, packaging etc. For the other cases, as pointed out by others "Existing DCAT users don't need to change anything to remain in conformance with DCAT.

agreiner commented 4 years ago

I agree with Andrea and Riccardo. Looking at the descriptions of the alternatives, it seems to be that "superseded" is what we're after.

"W3C may obsolete a Recommendation, for example if the W3C Community decides that the Recommendation no longer represents best practices, or is not adopted and is not apparently likely to be adopted. An Obsolete Recommendation may be restored to normal Recommendation, for example because despite marking it Obsolete the specification is later more broadly adopted.

W3C may declare a Recommendation Superseded if a newer version exists which the W3C recommends for new adoption. The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; only the name and explanation change.

W3C may rescind a Recommendation if W3C believes there is no reasonable prospect of it being restored for example due to burdensome patent claims that affect implementers and cannot be resolved; see the W3C Patent Policy and in particular section 5 (bullet 10) and section 7.5."

davebrowning commented 4 years ago

I've raised a separate issue for the DCAT 1 PID uri at #1182

pwin commented 4 years ago

I have mentioned to @plehegar that the consensus is to supercede version 1, and so we must now decide what text we include in version 1 to indicate this. https://www.w3.org/TR/2019/SPSD-WebCGM20-20191205/ is an example

What are your thoughts about what information must be present?

plehegar commented 4 years ago

some examples: https://www.w3.org/TR/hr-time-1/ , https://www.w3.org/TR/2019/SPSD-WebCGM20-20191205/ , https://www.w3.org/TR/html50/

agbeltran commented 4 years ago

I agree with the comments by Riccardo and Andrea, also having read the points that Annette highlighted from https://www.w3.org/2019/Process-20190301/#rec-rescind, as superseding means that we would recommend to use DCAT2 for new adoption.

I'd like to see some text clarifying that we are superseding but not making DCAT1 obsolete (as "A Recommendation can be both superseded and obsolete") and emphasise on the backward compatibility. I couldn't find anything around backward compatiblity in the Process Document either. The examples linked above don't seem to have any similar text, so we may need to write our own.

riccardoAlbertoni commented 4 years ago

I couldn't find anything around backward compatiblity in the Process Document either.

Well I think the first note in the Proposed Rec goes in that direction, see below

DCAT 2 maintains the DCAT namespace as it preserves backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break existing DCAT implementations.

Perhaps we might want to elaborate a little more on this, and move the note earlier in the document.

For example, saying

DCAT 2 supersedes DCAT [VOCAB-DCAT-20140116]. It maintains the DCAT namespace as its terms preserve backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break the definition of previous terms. Any new implementation is expected to adopt DCAT 2, while the existing implementations might not need to upgrade to it. In particular, current DCAT deployments that do not overlap with the DCAT 2 new features (e.g., data services, time and space properties qualified relations, packaging) don't need to change anything to remain in conformance with DCAT 2.

agbeltran commented 4 years ago

I couldn't find anything around backward compatiblity in the Process Document either.

Well I think the first note in the Proposed Rec goes in that direction, see below

DCAT 2 maintains the DCAT namespace as it preserves backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break existing DCAT implementations.

I meant in the W3C Process Document (https://www.w3.org/2019/Process-20190301/#rec-rescind), not in the DCAT Proposed Rec

About your text - here it goes again with a few changes in italics:

"DCAT 2 supersedes DCAT [VOCAB-DCAT-20140116], but it does not make it obsolete. DCAT 2 maintains the DCAT namespace as its terms preserve backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break the definition of previous terms.

Any new implementation is expected to adopt DCAT 2, while the existing implementations do not need to upgrade to it, unless they want to use the new features. In particular, current DCAT deployments that do not overlap with the DCAT 2 new features (e.g., data services, time and space properties qualified relations, packaging) don't need to change anything to remain in conformance with DCAT 2."

What do you think?

pwin commented 4 years ago

Looks good Alejandra

Perhaps we should also refer to the github issues and ask for a report should anybody experience any difficulties with this

Cheers Peter

On Mon, 9 Dec 2019 at 18:01, Alejandra Gonzalez-Beltran < notifications@github.com> wrote:

I couldn't find anything around backward compatiblity in the Process Document either.

Well I think the first note in the Proposed Rec goes in that direction, see below

DCAT 2 maintains the DCAT namespace as it preserves backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break existing DCAT implementations.

I meant in the W3C Process Document ( https://www.w3.org/2019/Process-20190301/#rec-rescind), not in the DCAT Proposed Rec

About your text - here it goes again with a few changes in italics:

"DCAT 2 supersedes DCAT [VOCAB-DCAT-20140116], but it does not make it obsolete. DCAT 2 maintains the DCAT namespace as its terms preserve backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break the definition of previous terms.

Any new implementation is expected to adopt DCAT 2, while the existing implementations do not need to upgrade to it, unless they want to use the new features. In particular, current DCAT deployments that do not overlap with the DCAT 2 new features (e.g., data services, time and space properties qualified relations, packaging) don't need to change anything to remain in conformance with DCAT 2."

What do you think?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/dxwg/issues/1177?email_source=notifications&email_token=AAIFYTDCIKALF6FPL7C32S3QX2BXRA5CNFSM4JRAMA3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGKCRRI#issuecomment-563357893, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIFYTHIPEDZNJI6FITIMWLQX2BXRANCNFSM4JRAMA3A .

riccardoAlbertoni commented 4 years ago

@agbeltran wrote

What do you think?

I like it. The only doubt is about the part "if they want to use the new features."

Let's consider an existing implementation in which a SPARQL endpoint is described in the old fashion DCAT style as embedded in a distribution instead of the DCAT 2 data service.

My opinion is that, in cases like the above, we should encourage to follow DCAT2 and then recommend to upgrade to DCAT 2 data service, while the sentence seems to leave this slightly open.

I guess that being DCAT 2014 not obsolete, the user can decide anyway not to stick to DCAT 2014, but he/she should be aware that this comes at the cost of being uncompliant with DCAT2. Am I too restrictive?

Perhaps we might change "if they want to use the new feature." in "if they need to use the new features."?

makxdekkers commented 4 years ago

@riccardoAlbertoni @agbeltran & all,

I like Alejandra's version better, with the want instead of the need.

By the way, I find @plehegar's examples very confusing:

So, no best practice there. I think W3C needs a clear policy for linking old and new recommendations.

makxdekkers commented 4 years ago

As I see it, documents published in the process of developing and maintaining evergreen recommendations take part in two chains:

  1. the REC chain, i.e. REC1, REC2, REC3
  2. the development chain, i.e. RECx comes about through WD1, WD2, .., CR, PR, REC

Both chains need to be reflected in a very clear way in the document metadata of every document in either chain.

In the REC chain there are several possible relationships between subsequent RECs:

These relationships could maybe be expressed with a controlled status vocabulary: under development, completed, superseded, deprecated, withdrawn etc.

How can we develop such a policy?

riccardoAlbertoni commented 4 years ago

@makxdekkers

@riccardoAlbertoni @agbeltran & all,

I like Alejandra's version better, with the want instead of the need.

Ok, let's keep Alejandra's revision, probably we cannot explain everything in once, and anyway, other parts of the document solves the concerns related to the example I was making.

riccardoAlbertoni commented 4 years ago

Alejandra's revision is now merged in the document. Is there any other activity we need to accomplish before closing this issue?

plehegar commented 4 years ago

are we clear on what modifications we want to make to the DCAT 1 REC, if any?

dr-shorthair commented 4 years ago

I don't think we can or should make changes in DCAT1. But the version delivered by W3C should make it clear that it has been superseded - e.g. see what happens when you get https://www.w3.org/TR/2006/WD-owl-time-20060927/

andrea-perego commented 4 years ago

I concur with @dr-shorthair .

I would also like to mention that, in SpecRef, the key "VOCAB-DCAT" still returns the bib reference about the original version of DCAT. The fact that the URL included there (https://www.w3.org/TR/vocab-dcat/) points to DCAT2 is confusing for people.

See https://api.specref.org/bibrefs?refs=VOCAB-DCAT:

{
  "VOCAB-DCAT": {
    "aliasOf": "vocab-dcat",
    "id": "VOCAB-DCAT"
  },
  "vocab-dcat": {
    "authors": [
      "Fadi Maali",
      "John Erickson"
    ],
    "href": "https://www.w3.org/TR/vocab-dcat/",
    "title": "Data Catalog Vocabulary (DCAT)",
    "status": "REC",
    "publisher": "W3C",
    "deliveredBy": [
      {
      "url": "https://www.w3.org/2011/gld/",
      "shortname": "gld"
      }
    ],
    "versions": [
      "vocab-dcat-20140116",
      "vocab-dcat-20131217",
      "vocab-dcat-20131105",
      "vocab-dcat-20130801",
      "vocab-dcat-20130312",
      "vocab-dcat-20120405"
    ],
    "id": "vocab-dcat",
    "date": "16 January 2014"
  }
}
riccardoAlbertoni commented 4 years ago

I concur with @dr-shorthair .

I would also like to mention that, in SpecRef, the key "VOCAB-DCAT" still returns the bib reference about the original version of DCAT. The fact that the URL included there (https://www.w3.org/TR/vocab-dcat/) points to DCAT2 is confusing for people.

@andrea-perego The dcat 2 bib ref is identified by vocab-dcat-2 see https://api.specref.org/bibrefs?refs=vocab-dcat-2

If I understand your point, you would like to have a URL consistent with this (i.e., the DCAT URL https://www.w3.org/TR/vocab-dcat-2/ instead of https://www.w3.org/TR/vocab-dcat/). However, as far as I have understood reading issue #1182, we have to live with the fact that https://www.w3.org/TR/vocab-dcat/ points to the latest rec (see phillipe's comment ).

Or you were suggesting something else? I apologize in advance if I am misinterpreting your comment.

agbeltran commented 4 years ago

I think that what @andrea-perego is pointing out would be solved by changing the href in https://api.specref.org/bibrefs?refs=VOCAB-DCAT to the specific DCAT 1 URL: https://www.w3.org/TR/2014/REC-vocab-dcat-20140116/

At the moment the href for "VOCAB-DCAT" is pointing to https://www.w3.org/TR/vocab-dcat/, which will always be the latest DCAT rather than the specific version one wants to point to.

andrea-perego commented 4 years ago

Thanks, @agbeltran . Yes, that would be an option. But, actually, I was not pointing to a specific solution - just reporting an inconsistency.

If VOCAB-DCAT should always refer to the latest version, this needs to be reflected in the corresponding bib entry in SpecRef, I guess, Of course, this will have a negative side effect in existing specifications using that key / URL to point specifically to DCAT 2014,

agbeltran commented 4 years ago

Yes, @andrea-perego the inconsistency is unfortunate.

But given that specs might have used VOCAB-DCAT and we won't want to break them, I am not sure if we could use the biblio reference VOCAB-DCAT for the latest version, but we will have to make sure it points to DCAT1.

Perhaps we should have an alternative key for the latest spec (e.g. VOCAB-DCAT-LATEST), even though it won't match the 'vocab-dcat' in the URL

riccardoAlbertoni commented 4 years ago

@agbeltran wrote:

Perhaps we should have an alternative key for the latest spec (e.g. VOCAB-DCAT-LATEST), even though it won't match the 'vocab-dcat' in the URL

It seems that the VOCAB-DCAT-LATEST is already foreseen and corresponds to https://www.w3.org/TR/dcat-voc/latest in the slides mentioned by Philippe, see also https://github.com/w3c/tr-pages/wiki/Latest-versions-proposal-for-leveled-specifications.

However, I haven't found a correspondent bib entry for https://www.w3.org/TR/dcat-voc/latest The bibliographic entries for DCAT 1 are "vocab-dcat" and those with the date if the citer needs to distinguishing among the DCAT 1 versions (e.g., vocab-dcat-20140116) while for DCAT 2 we have "vocab-dcat-2" plus those with the date.

riccardoAlbertoni commented 4 years ago

To get to a point with this issue, I would concur with @agbeltran's and @dr-shorthair's suggestions combined.

@dr-shorthair wrote:

I don't think we can or should make changes in DCAT1. But the version delivered by W3C should make it clear that it has been superseded - e.g. see what happens when you get https://www.w3.org/TR/2006/WD-owl-time-20060927/

@agbeltran wrote:

I think that what @andrea-perego is pointing out would be solved by changing the href in https://api.specref.org/bibrefs?refs=VOCAB-DCAT to the specific DCAT 1 URL: https://www.w3.org/TR/2014/REC-vocab-dcat-20140116/

That's what we can have according to the previous comments, and it does not break previous citations.

agbeltran commented 4 years ago

I agree with that approach.

Additionally, we should try to get VOCAB-DCAT-LATEST into the bibliography replacing the current VOCAB-DCAT

riccardoAlbertoni commented 4 years ago

I agree with that approach.

Additionally, we should try to get VOCAB-DCAT-LATEST into the bibliography replacing the current VOCAB-DCAT

I think vocab-dcat-latest should not be used as a bibliographic entry as it is going to change any time a new rec version is out ..

agbeltran commented 4 years ago

https://www.w3.org/TR/vocab-dcat/ always points to the latest spec, so VOCAB-DCAT-LATEST should include that href - as per comments above

andrea-perego commented 4 years ago

I think that, whatever the solution is/will be, this is not going to apply only to DCAT but to all TRs - as far as I know, so far citation keys always correspond to the last part of the URI, so I guess this is not going to change.

@plehegar , could you shed some light on this?

plehegar commented 4 years ago

Re https://api.specref.org/bibrefs?refs=VOCAB-DCAT , there is currently a bug in the W3C API See https://github.com/w3c/w3c-api/issues/96 . Once the bug gets fixed, it will match https://www.w3.org/TR/vocab-dcat/ , and respec will point to the same place.

riccardoAlbertoni commented 4 years ago

This issue is on the hand of W3C, and we can't do much on it.

However, I think we might want to recheck how URL links and bibliographic refs work after DCAT 2 rec is published. Shall we move this issue to the milestone of "future work"?

plehegar commented 4 years ago

SGTM. our webmaster is working on resolving the issue. I doubt it will get fixed by Jan 31 but hoping shortly after.

agbeltran commented 4 years ago

@riccardoAlbertoni if this is being handled, I agree with moving it to the "future work" milestone and deal with it after DCAT2 REC is public.

andrea-perego commented 4 years ago

+1 from me as well.

plehegar commented 4 years ago

https://www.w3.org/TR/vocab-dcat-1/ is now officially superseded.

I propose to close this issue. Note that the API bug remains (mismatch between /TR and API for "vocab-dcat"). If we want to track https://github.com/w3c/w3c-api/issues/96 , we could open a separate issue in this repo.