-
Notifications
You must be signed in to change notification settings - Fork 47
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
Notes on reviewing DCAT FPWD #1275
Comments
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. |
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 |
@agreiner , about this point:
Could you please elaborate? Currently, the versioning section recommends using |
Just providing more context to the discussion. I wonder if we want to keep the same line and add a new line in the mapping for the correspondence between |
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>.
|
@agreiner wrote:
Yes, it is mainly for ontology terms, but using it for datasets is a common practice. |
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. |
I created a new issue on this topic: #1280 I suggest we move all discussion there. |
@agreiner , @riccardoAlbertoni , as the discussion has been eventually moved to #1280 , I propose we close this issue. |
Fine to me. |
yes, that's fine with me. |
Thanks, @riccardoAlbertoni & @agreiner . Closing. |
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.
The text was updated successfully, but these errors were encountered: