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

Version definition [RVSDF] #90

Closed
jpullmann opened this issue Jan 18, 2018 · 9 comments
Closed

Version definition [RVSDF] #90

jpullmann opened this issue Jan 18, 2018 · 9 comments
Labels
dcat due for closing Issue that is going to be closed if there are no objection within 6 days provenance requirement status versioning

Comments

@jpullmann
Copy link

Version definition [RVSDF]

Provide clear guidance on conditions, type and severity of a resource's update that might motivate the creation of a new version in scenarios such as dataset evolution, conversion, translations etc, including how this may assist change management processes for consumers (e.g. semantic versioning techniques)


Related requirements: Version subject [RVSS] 
Related use cases: Dataset Versioning Information [ID4] Annotating changes that do not change the information content [ID50] 
@dr-shorthair
Copy link
Contributor

@andrea-perego
Copy link
Contributor

I wonder whether there are definitions of "versions" from standards / communities we can be inspired from.

Actually, it would be already useful to document / compare how the notion of "version" is defined and implemented in different domains / communities.

@makxdekkers
Copy link
Contributor

makxdekkers commented Mar 17, 2018

@andrea-perego I am not sure it is doable to look for ways that different communities are handling versions. There are a lot of communities that could be considered. In the end, I agree with what @dr-shorthair wrote back in October 2017 (https://lists.w3.org/Archives/Public/public-dxwg-wg/2017Oct/0017.html):
"the notion of 'version' is usually a publisher's choice to assign a memorable identifier to a product".
So it may depend on the type of product, the intentions of the publisher and the expectations of the consumer. There might not be much consensus even within a particular community.
In my mind, a fundamental characteristic of a version is that it is a resource that results from a change that was applied to or occurred in a pre-existing resource. In my mind, such a definition would point to the need, as a minimum, to be able to provide:

  • a reference to the resource of which it is a version
  • a name, number or timestamp (e.g. 'MkII', '3.0.1 build 1902', '2018' etc.)
  • a description of what the changes were (e.g a change log)

I think that we may not be able to go much further than that without digging into the particular aspects of specific products and communities. This could take a lot of time for little gain.

@makxdekkers
Copy link
Contributor

The European DCAT-AP specifies for those three aspects:

  • dct:isVersionOf: a related Dataset of which the described Dataset is a version, edition, or adaptation.
  • owl:versionInfo: a version number or other version designation of the Dataset.
  • adms:versionNotes: a description of the differences between this version and a previous version of the Dataset.

@dr-shorthair
Copy link
Contributor

dr-shorthair commented Jul 25, 2018

Version is a special case of #81 (Related datasets) also concerned with #76 (Provenance information)

@andrea-perego
Copy link
Contributor

@makxdekkers wrote:

@andrea-perego I am not sure it is doable to look for ways that different communities are handling versions. There are a lot of communities that could be considered. In the end, I agree with what @dr-shorthair wrote back in October 2017 (https://lists.w3.org/Archives/Public/public-dxwg-wg/2017Oct/0017.html):
"the notion of 'version' is usually a publisher's choice to assign a memorable identifier to a product".
So it may depend on the type of product, the intentions of the publisher and the expectations of the consumer. There might not be much consensus even within a particular community.

I agree as well. My comment was actually more a hint to say that we should not define ourselves what a "version" is, but rather recognising that there are different practices.

@dr-shorthair dr-shorthair removed this from the Dataset versioning milestone Aug 21, 2018
davebrowning added a commit that referenced this issue Mar 26, 2019
Draft of sentence addressing issues #90 and #93 about versions given full story has been deferred into the backlog
@davebrowning davebrowning added the future-work issue deferred to the next standardization round label Sep 25, 2019
@riccardoAlbertoni
Copy link
Contributor

DCAT 2 says: "The notion of version is very much related to the community practices. For this reason, we refrain from providing definitions or rules about when changes in a resource should turn in a new release of it."

I am in favor of keeping this line, and if no one is objecting, I think we can close this issue.

@dr-shorthair
Copy link
Contributor

replace 'turn in' by 'become' or 'turn into' in the last line.

@riccardoAlbertoni riccardoAlbertoni added the due for closing Issue that is going to be closed if there are no objection within 6 days label Sep 18, 2020
@riccardoAlbertoni
Copy link
Contributor

I'm closing this issue as DCAT 2 already registered a shared view, saying:
"The notion of version is very much related to the community practices. For this reason, we refrain from providing definitions or rules about when changes in a resource should turn into a new release of it."

@andrea-perego andrea-perego removed the future-work issue deferred to the next standardization round label Mar 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dcat due for closing Issue that is going to be closed if there are no objection within 6 days provenance requirement status versioning
Projects
None yet
Development

No branches or pull requests

8 participants