Re: [dxwg] Revision to the versioning section (#1295)

> @riccardoAlbertoni said:
> 
> > * I think that the ability to determine the latest/current version is a very fundamental use case when people look for data (what is the latest (official or draft) version released?). Considered this, I wonder if we need to bind more explicitly the semantics of `dcat:currentVersion` and `dcat:lastVersion` to the `dct:replaces` and `dcat:previousVersion` chains. For example, saying " `dcat:lastVersion` is the head of the `dcat:previousVersion` property chain and dcat:currentVersion is the 'head' of the `dct:replaces` chain". That might provide an agreed way to work out the latest version and current version, which might help maintain the metadata consistent and updated.
> 
> IMO, `dct:replaces` and `dcat:previousVersion` denote two different relationships - a new version is not necessarily replacing the previous one.

Sure, this is very clear in the draft. 
I was trying to understanding more about the relations between these two properties.

Thinking of `dcat:currentVersion`, I was not considering that you can have more than one version between the last and current version. (e.g., on the same spirit of the included examples,  we could have more public working drafts of DCAT 3).

Also, I guess a replacement is not necessarly a new version, aka `dct:replaces` is  *not* a  subproperty of `dcat:previousVersion`, 

> About the other point, you can get to the head of the version chain from a given version by using the property chain `dcat:isVersionOf`/`dcat:lastVersion`. Are you suggesting an additional solution?

 Generally speaking, `dcat:lastVersion` ranges to the head of the chain build on `dcat:previousVersion`  at least when a previous version exists. Independently on whether or not OWL 2 can formalize this, I was hinting to say this explicitly in the usage notes of `dcat:lastVersion`. 

As for `dcat:currentVersion`,  I have now realized in light of the previous observations, there is no much we can say in terms of chains.


> 
> > * Is `owl:versionInfo` a sub-property of `dcat:version`? Is `owl:priorVersion`  sub-property of `owl:priorVersion`? Or do we want to keep DCAT versioning and OWL versioning as two distinct alternative approaches?
> 
> IMO, there is no strong need to formally link these properties, and I would simply keep DCAT and OWL as two complementary approaches to versioning - DCAT, for all resources documented in a catalogue, OWL for those resources that can be typed as `owl:Ontology`'s.
> There're also some problems in formally defining the relationships between DCAT and OWL. E.g., if `dcat:version` could be a superproperty of `owl:versionInfo` (in the sense that the latter is supposed to be used for only some resource types), on the other hand, there is no domain restriction preventing `owl:versionInfo` from being used on any resource. Moreover, `owl:priorVersion` is not explicitly linked to the notion of "version chain" as `pav:previousVersion` / `dcat:previousVersion`.
> 

The question arises from the back compatibility with the current practices and DCAT profiles, in which `owl:versionInfo` is used instead of `dcat:version`. However, in prospect, I guess the above subproperty is a trick to convert the old approach into the new that some adopters can consider, and it is not necessarily something we need to suggest in the standard.

> > * Should we align the DCAT versioning with DCAT provenance?  PAV aligns with DCT, and PROV (see [SPRINT on Versioning ](https://github.com/w3c/dxwg/wiki/Material-for-a-SPRINT-on-Versioning) for a summary). If we state the `owl:equivalentProperty` to PAV's terms, that will induce these alignments for the DCAT's, but that is quite an indirect way to have DCAT versioning align with DCT and PROV for versioning. In case we want to keep the alignments provided by PAV for DCT and PROV, I suggest restating them explicitly in DCAT. This could be also the occasion to double-check that these alignments hold and fit well in DCAT. Whether these alignments will be normative or not is another issue that we might need to debate.
> 
> I think we can explain this in the sections where we define these new properties, and maybe in the last subsection of the versioning section. I also think that we should be a bit careful not to overload the guidance sections with too much information, which may make the narrative less clear.

Yes, my comment aimed to explicit the alignments in the sections where we will define these new properties. I agree on not overloading the narrative.



-- 
GitHub Notification of comment by riccardoAlbertoni
Please view or discuss this issue at https://github.com/w3c/dxwg/pull/1295#issuecomment-782299810 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 19 February 2021 19:43:54 UTC