Notes on reviewing DCAT FPWD

[agreiner]

There is some interesting reading about possible uses of the term "version". I think it would be helpful to go a step further and clarify what our own definition of the term is. Moreover, I'm surprised, given the requirement to add support for versioning, that we do not seem to be ready to add a version term of our own. It's true that one can interpret the word to mean a handful of different things, but I don't think we solve the problem by simply reiterating the complexity and then telling people to do whatever works for them. I think that people who have asked for DCAT to support versions are asking that because they don't think that solution works.
If we will add such a term, the text should clearly state that and should define it narrowly. I'm worried about overlap with other concepts that people may add in a profile, like series. Obviously, one can't use the same term for all the things suggested, and there will be datasets that use more than one (e.g., series where one item is updated).
The one usage with which I disagree entirely is for languages. I don't believe that different language distributions are versions in the sense we're discussing, and I think that including that is potentially confusing.
Backward compatibility seems unhelpful for datasets, but helpful for software. I think it is a great idea to support metadata about software! If we support that, we should also think about supporting other aspects of software (e.g., language, OS compatibility).
Since schema.org is already supporting version as a term, and it is in some sense a child vocabulary, following what schema is doing would be helpful for compatibility with them.

[andrea-perego]

Thanks, @agreiner . This is very helpful to move a step forward the revision and consolidation of the versioning approach proposed in the current draft.

I'm going to create specific issues for the points you are raising. I'm not sure we will be able to address them before the FPWD for DCAT3, but anyway we can already kick-start the discussion and complement it with further feedback that we expect to get from the FPWD.

[agreiner]

I think it would be good to request feedback on the first point in the FPWD in particular. As of my reading, the text didn't make it clear to me that the proposed path forward was not to add explicit support for versions, since the draft contains references to the related requirements, and readers may well assume we do plan to add terms for them.

[andrea-perego]

I think it would be good to request feedback on the first point in the FPWD in particular. As of my reading, the text didn't make it clear to me that the proposed path forward was not to add explicit support for versions, since the draft contains references to the related requirements, and readers may well assume we do plan to add terms for them.

Indeed, @agreiner .

A reference to the relevant issue (#1277) will be included in the FPWD - see PR #1279

[andrea-perego]

@agreiner , about this point:

Since schema.org is already supporting version as a term, and it is in some sense a child vocabulary, following what schema is doing would be helpful for compatibility with them.

Could you please elaborate?

Currently, the versioning section recommends using owl:versionInfo to specify the resource identifier. Do you see any issue in re-using this property?

[riccardoAlbertoni]

@agreiner , about this point:

Since schema.org is already supporting version as a term, and it is in some sense a child vocabulary, following what schema is doing would be helpful for compatibility with them.

Just providing more context to the discussion.
We provide an alignment between schema.org and DCAT, see appendix B in the current FPWD. The alignment was already included in DCAT 2.

I wonder if we want to keep the same line and add a new line in the mapping for the correspondence between owl:versionInfo and schema:version.

[agreiner]

Yes, I think owl:versionInfo is meant to describe versions of ontology terms and constructs specifically.

…

On Nov 12, 2020, at 1:54 PM, Andrea Perego ***@***.***> wrote: @agreiner <https://github.com/agreiner> , about this point: Since schema.org is already supporting version as a term, and it is in some sense a child vocabulary, following what schema is doing would be helpful for compatibility with them. Could you please elaborate? Currently, the versioning section recommends using owl:versionInfo to specify the resource identifier. Do you see any issue in re-using this property? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGVLN23FA7V5MKSBEHMXVDSPRKP3ANCNFSM4TSV5TIA>.

[riccardoAlbertoni]

@agreiner wrote:

Yes, I think owl:versionInfo is meant to describe versions of ontology terms and constructs specifically.

Yes, it is mainly for ontology terms, but using it for datasets is a common practice.
For example, owl:versionInfo is one of the implementation examples considered in the "Data Web Best Practice 7: Provide a version indicator" https://www.w3.org/TR/dwbp/#dataVersioning. Examples in the DWBP Rec have not normative status. Nevertheless, they should still suggest proper ways to implement Best Practices.
Similarly, it is reused by ADMS (see https://www.w3.org/TR/vocab-adms/#owl-versioninfo).

[agreiner]

I think both those examples would have happily preferred a dcat:version had it been available, and neither was in a position to mint their own, so it's not surprising that they would use what was available, whether or not it was a strong choice.

[andrea-perego]

I created a new issue on this topic: #1280

I suggest we move all discussion there.

[andrea-perego]

@agreiner , @riccardoAlbertoni , as the discussion has been eventually moved to #1280 , I propose we close this issue.

[riccardoAlbertoni]

@agreiner , @riccardoAlbertoni , as the discussion has been eventually moved to #1280 , I propose we close this issue.

Fine to me.

[agreiner]

yes, that's fine with me.

[andrea-perego]

Thanks, @riccardoAlbertoni & @agreiner .

Closing.