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 release date [RVSDT] #91

Closed
jpullmann opened this issue Jan 18, 2018 · 11 comments · Fixed by #1257
Closed

Version release date [RVSDT] #91

jpullmann opened this issue Jan 18, 2018 · 11 comments · Fixed by #1257

Comments

@jpullmann
Copy link

Version release date [RVSDT]

It must be possible to assign a date to a version. The version identifier might refer to the release date.


Related requirements: Version definition [RVSDF] Version identifier [RVSID] 
Related use cases: Dataset Versioning Information [ID4] 
@andrea-perego
Copy link
Contributor

andrea-perego commented Jan 20, 2018

If a dataset version is modelled as a dataset, then the version date can be specified with properties already supported in DCAT - (dct:created /) dct:issued / dct:modified.

@dr-shorthair
Copy link
Contributor

dr-shorthair commented Jan 21, 2018

There may also be some useful options coming from the proposed PROV-O alignment - see #76 and #94
Any prov:Entity (superclass of dcat:Dataset?) is the result of a prov:Activity which has a start and end time.
And PAV shows how to build a versioning system on top of PROV-O.

@nicholascar
Copy link
Contributor

It's going to be a lot easier in catalogues to indicate properties of the dataset as an Entity, like prov:createdAtTime, than properties of the Activity that generated the Entity. We should make sure future DCAT has PROV-O property chain axioms for all the "normal" dct properties in addition to dct:created/prov:createdAtTime, like dct:modified. PROV-O has no sense of modified as a data property.

@nicholascar
Copy link
Contributor

Re-represented as RDA Prov Patterns WG Use Case 43: http://patterns.promsns.org/usecase/43

@larsgsvensson
Copy link
Contributor

We should make sure future DCAT has PROV-O property chain axioms for all the "normal" dct properties in addition to dct:created/prov:createdAtTime, like dct:modified

Is it really possible to create OWL property chain axioms where the chain ends with a data property? To my knowledge OWL property chain axioms can only chain object properties and the chaining of data properties has to be done with rules. What do the OWL experts say?

@dr-shorthair
Copy link
Contributor

@larsgsvensson - yes, I think you are correct. Unfortunate, but true.

@dr-shorthair dr-shorthair added this to the Dataset versioning milestone Mar 16, 2018
@dr-shorthair dr-shorthair removed this from the Dataset versioning milestone Aug 21, 2018
@davebrowning davebrowning added this to the DCAT Backlog milestone Mar 14, 2019
@davebrowning davebrowning added the future-work issue deferred to the next standardization round label Sep 25, 2019
@riccardoAlbertoni
Copy link
Contributor

We have discussed this issue in the last DCAT call. We have agreed that dct:created can indicate the release date, as we are assuming that each version is a new entity, for example, a new version of a dataset will be a new dataset, and we do not need to mint a specific property for "version date".

Connected to this, the discussion has drifted to solutions adopted by other vocabularies (PAV and Version), please take a look at the meeting minutes

@andrea-perego
Copy link
Contributor

@riccardoAlbertoni said:

We have discussed this issue in the last DCAT call. We have agreed that dct:created can indicate the release date [...]

I think it should be dct:issued. dct:created refers to the creation date (which does not necessarily correspond to the date when a resource is published).

@nicholascar
Copy link
Contributor

I think it should be dct:issued. dct:created refers to the creation date (which does not necessarily correspond to the date when a resource is published).

Correct! I've not been following this closely - only saw the issue close notice - but I hope the sense of this last comment was adhered to.

@andrea-perego
Copy link
Contributor

I think it should be dct:issued. dct:created refers to the creation date (which does not necessarily correspond to the date when a resource is published).

Correct! I've not been following this closely - only saw the issue close notice - but I hope the sense of this last comment was adhered to.

Thanks, @nicholascar . It is - see last paragraph in §10.2 Version information.

@andrea-perego
Copy link
Contributor

andrea-perego commented Nov 11, 2020

Issue closed as decided in the 11 Nov 2020 DCAT call and following the extension of the versioning section in the ED - in particular, see §10.2 Version information.

New issues should be created for further discussion on this topic.

@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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants