Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Version subject [RVSS] #93
Version subject [RVSS]
Identify DCAT resources that are subject to versioning, i.e. Catalog, Dataset, Distribution.
Related use cases: Dataset Versioning Information [ID4] Identification of versioned datasets and subsets [ID44]
Jan 18, 2018
@agbeltran If our decision is to allow versioning for all first-class citizens in DCAT, then this would also include
@makxdekkers and @agbeltran: I agree,
For example, both the unqualified relation prov:wasRevisionOf and the qualified counterpart prov:qualifiedRevision works on prov:Entity, which can be any of the first class citizens we were mentioning before.
Similarly, does PAV which specialize PROV with specific authorship, curation and digital creation terminology.
So in order to deal with this issue,
+1 from me to not limiting the scope of versioning to some specific classes.
Said that, I wonder what actually means versioning a "service": is this about the version of the software and/or service interface? This can be already addressed by indicating the specification to which the service conforms to.
In other words, shouldn't versioning be related to content/data only?
This is the key question, isn't it? We're certainly more interested in content/data than in versions of software but I'm struggling to see how that could work in practice. For example, if I say that I'm using a specific version of a
So I don't see how we can limit it just to the content/data... Of course I may be missing a subtlety somewhere that we need to explain.
@davebrowning , I see your point, but what has changed is the version of software/API used, and this can already be specified via
E.g., the following is a service conformant with CSW 2.0.2:
a:Service a dcat:DataService ; dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/csw/2.0.2> .
If the service is switched to the latest version of the CSW specification, its description would be:
a:Service a dcat:DataService ; dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/csw/3.0> .
The version here does not concern the service, but the reference specifications:
<http://www.opengis.net/def/serviceType/ogc/csw> a dct:Standard , adms:Asset ; dct:hasVersion <http://www.opengis.net/def/serviceType/ogc/csw/2.0.2> , <http://www.opengis.net/def/serviceType/ogc/csw/3.0> . <http://www.opengis.net/def/serviceType/ogc/csw/2.0.2> a dct:Standard , adms:Asset ; dct:isVersionOf <http://www.opengis.net/def/serviceType/ogc/csw> ; adms:next <http://www.opengis.net/def/serviceType/ogc/csw/3.0> ; . <http://www.opengis.net/def/serviceType/ogc/csw/3.0> a dct:Standard , adms:Asset ; dct:isVersionOf <http://www.opengis.net/def/serviceType/ogc/csw> ; adms:prev <http://www.opengis.net/def/serviceType/ogc/csw/2.0.2> ; .
Reading the discussion here and in the last sprint on versioning, I understand that the vocabularies under consideration are DCTerms, PROV and PAV.
It may be worth mentioning that versioning was also addressed in ADMS, where specific properties are defined:
Please note that, despite what said in their discursive definitions, no domain or range restriction is specified for these properties.
I don't remember if this was already mentioned, but another aspect of versioning may concern the resource "status" - e.g., draft, stable, deprecated, withdrawn.
The EU Publications Office maintains some reference code lists - the two that may be most relevant here are:
E.g., the dataset status code list above includes the following statuses (alphabetically ordered):
The concept status code list includes additional statuses.
This information is clearly useful for administrative purposes, but relevant as well for users.
E.g., in the JRC Data Catalogue, these statuses determine where a dataset can be published (e.g., a dataset in draft status is not supposed to be published in production). On the other hand, deprecated, discontinued, or withdrawn records are not removed from the catalogue (because of the persistence policy we have in place), but they are "marked" as such, so that users are aware they shouldn't be used or are not longer available.