It must be possible to assign a date to a version. The version identifier might refer to the release date.
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.
There may also be some useful options coming from the proposed PROV-O alignment - see #76 and https://github.com/w3c/dxwg/pull/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.
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.
Re-represented as RDA Prov Patterns WG Use Case 43: http://patterns.promsns.org/usecase/43
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?
@larsgsvensson - yes, I think you are correct. Unfortunate, but true.
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
@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).
I think it should be
dct:issued.dct:createdrefers 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.
I think it should be
dct:issued.dct:createdrefers 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.
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.
Most helpful comment
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.