Dxwg: "Current" vs "last" versions

[aisaac]

I'm afraid I'm not fully buying the new properties for versioning dcat:hasCurrentVersion and dcat:hasLastVersion introduced by #1295

First, I believe the words do not sound entirely appropriate.
I.e. it seems that the main difference regards status, especially publication status. I don't think the opposition between 'current' and 'last' reflect this. For many people, these adjectives mean the same thing.
If we want to represent that difference in shade of status, then maybe other words would be better. The current text (well, maybe I am forbidden to use 'current' and I should use 'last' here ;-) ) mentions 'stable', maybe this is a word that is more helpful. The W3C categories at the top of the spec distinguish 'Latest published version' from 'Latest editor's draft', maybe these words could be used too.

Second, the use case motivating them is interesting, but perhaps it's a borderline case for dataset versioning. I.e., if I go to a dataset catalogue, I'm not expecting to find many draft versions datasets. Would you?
In other words, I would expect dcat:hasCurrentVersion to be always present, while dcat:hasLastVersion would be used for specific cases.
Maybe we can find a Litmus test for this discussion: if the 'latest' version that can be accessed is an 'official' one, would DCAT recommend that two statements are created to link twice the same pair of resources, one with dcat:hasCurrentVersion and one with dcat:hasLastVersion?
If yes, then I'm not sure I like this but I will accept it ;-)
If not, then maybe we're on the same line, in the end. But then it would be good to indicate in the text that one property is more essential to the representation of version histories than the other. And maybe to push dcat:hasLastVersion into an own (sub)section, not systematically presenting it on a par with dcat:hasCurrentVersion.

Continuing on this second aspect, maybe here there's a bit of a bias introduced here by having used DCAT itself for the versioning example. I reckon that ontologies can be claimed to be datasets, but they're not very typical ones. (but perhaps that remark deserves another issue!)

[andrea-perego]

Thanks, @aisaac .

I think that probably we should first start with deciding whether these properties are useful and should be included in DCAT. Just a quick note: dcat:hasCurrentVersion reflects the semantics and naming of pav:hasCurrentVersion, but dcat:hasLastVersion is a DCAT (experimental) addition, to complement the former.

About the use of DCAT in the examples, I tend to agree. The rationale is that DCAT, as all other W3C specs, uses a well-defined (and known) versioning policy, which helps explain the use of all the properties included in the current draft, as well as the notions of version chain and hierarchy. It would indeed be better to use a dataset instead - so, any examples from the WG would be more than welcome!

[dr-shorthair]

Maybe dcat:hasPreviousVersion - 'last' has additional implications ('final') that could confuse a casual reader. I.e. clarify if you mean 'previous' or 'final'.

[makxdekkers]

Continuing on this second aspect, maybe here there's a bit of a bias introduced here by having used DCAT itself for the versioning example. I reckon that ontologies can be claimed to be datasets, but they're not very typical ones. (but perhaps that remark deserves another issue!)

Please let's not (again) get into the discussion of what can or cannot be claimed to be a Dataset! I am, and have been, involved in activities that use DCAT to descibe vocabularies and ontologies, and it works very well.

[aisaac]

@makxdekkers I'm not claiming that using DCAT for vocabularies and ontology doesn't work (and in fact I wouldn't hesitate characterize some 'vocabularies' as datasets, especially thesauri) but it's just that using this example may lead us to give more importance to rather untypical cases.
@andrea-perego Maybe we could just continue with the bus stop example, for the sake of simplicity.

As for the name of the property, I guess I can live with re-using PAV's "current" wording, as long as there is no "last" just next to it in DCAT. So maybe just changing the name of dcat:hasLastVersion would be alright.

Coming back to my questions, considering @andrea-perego 's point on the experimental nature of dcat:hasLastVersion I assume that the answer to my first point/question

In other words, I would expect dcat:hasCurrentVersion to be always present, while dcat:hasLastVersion would be used for specific cases.

would be that yes, dcat:hasCurrentVersion should be always present, while dcat:hasLastVersion would be used for specific cases.
And this would be in favour of not introducing dcat:hasLastVersion (or whatever new name for it) at the same level as the others.

I'm still wondering about the other one:

if the 'latest' version that can be accessed is an 'official' one, would DCAT recommend that two statements are created to link twice the same pair of resources, one with dcat:hasCurrentVersion and one with dcat:hasLastVersion?

[andrea-perego]

@dr-shorthair said:

Maybe dcat:hasPreviousVersion - 'last' has additional implications ('final') that could confuse a casual reader. I.e. clarify if you mean 'previous' or 'final'.

The property is supposed to point to the most recent / latest version (irrespective of its status - draft or stable). So an option could be dcat:hasLatestVersion. I would not use "final", as this is can be understood to point to a stable version.

[andrea-perego]

@aisaac said:

@andrea-perego Maybe we could just continue with the bus stop example, for the sake of simplicity.

That example is not completely fit to illustrate all the properties, but we can give it a try. Anyway, if the WG has any real-world cases we can re-use, that would be much better.

As for the name of the property, I guess I can live with re-using PAV's "current" wording, as long as there is no "last" just next to it in DCAT. So maybe just changing the name of dcat:hasLastVersion would be alright.

I am open to proposals.

Coming back to my questions, considering @andrea-perego 's point on the experimental nature of dcat:hasLastVersion I assume that the answer to my first point/question

In other words, I would expect dcat:hasCurrentVersion to be always present, while dcat:hasLastVersion would be used for specific cases.

would be that yes, dcat:hasCurrentVersion should be always present, while dcat:hasLastVersion would be used for specific cases.

Yes. It is likely that the presence of an instance of dcat:hasLastVersion implies also that an instance of dcat:hasCurrentVersion is used. But this does not mean that dcat:hasCurrentVersion should always be present.

The only properties that should be used to specify a version chain and hierarchy are, respectively, dcat:previousVersion and dct:hasVersion. Using of not the other properties depends on the use case, as said in §10.1.1 Version chains and hierarchies - quoting:

_Property dcat:previousVersion is used to build a version chain, that can be navigated backward from a given version to the first one. This reflects the most typical use case - i.e., linking different versions published as distinct resources in a catalog._

_In addition to this, property dcat:hasVersion can be used to specify a version hierarchy, by linking an abstract resource to its versions._

_If needed, the version hierarchy can be further described by specific properties. More precisely, property dcat:isVersionOf (inverse of dcat:hasVersion) gives the possibility of specifying a back link from a version to the abstract resource, whereas properties dcat:hasCurrentVersion and dcat:hasLastVersion link to, respectively, the current and last versions of the resource. Note that the current version of a resource may be different from the last version: e.g., when the last version is still in draft status, the current one may correspond to the latest stable version of the resource._

And this would be in favour of not introducing dcat:hasLastVersion (or whatever new name for it) at the same level as the others.

Do you have any suggestion on how to revise the text?

I'm still wondering about the other one:

if the 'latest' version that can be accessed is an 'official' one, would DCAT recommend that two statements are created to link twice the same pair of resources, one with dcat:hasCurrentVersion and one with dcat:hasLastVersion?

Possibly yes.

[dr-shorthair]

Yes, in that case, dcat:hasLatestVersion would be preferable. 'Last' can be interpreted in too many ways!

[agreiner]

I think 'latest' is better than 'last' here, but it's still not intuitive in my opinion. Maybe we should have hasCurrentVersion and hasCurrentStableVersion.

[andrea-perego]

@agreiner said:

I think 'latest' is better than 'last' here, but it's still not intuitive in my opinion. Maybe we should have hasCurrentVersion and hasCurrentStableVersion.

Based on what discussed so far, I'm still unsure whether there's a consensus that dcat:hasLast(est)Version is needed.

About dcat:hasCurrentVersion, I'm actually re-considering my claim that this should point to a stable version, which was mainly reflecting the examples under discussion, but not alternative scenarios.

dcat:hasCurrentVersion (as pav:hasCurrentVersion) links an unversioned resource to a version exactly corresponding to it. Nothing else. So, whether it points or not to a stable version depends on the publication rules in place. E.g., a publisher may decide that the unversioned resource must always correspond to the latest version, irrespective of its status (draft, stable, whatever). Or, as in the case of DCAT 3, if a stable version of a resource (e.g., a Recommendation) is not yet available, dcat:hasCurrentVersion points to the latest published draft.

This may make even more unclear the difference between dcat:hasCurrentVersion and dcat:hasLastVersion, so it might be safer to drop dcat:hasLastVersion unless we have a strong use case to support it.

PS: I'll update the draft to clarify the actual semantics and use of dcat:hasCurrentVersion. My apologies for having driven the discussion in the wrong direction.

[andrea-perego]

Following the discussion on these issues during the last DCAT subgroup call, it seems there's a general consensus on the following points:

1. dcat:hasLast(est)Version is not strictly necessary and potentially confusing.
2. For the versioning diagrams, using DCAT as an example is not representative of the most common cases, and it would be better to use a dataset.

As this is in line also with what discussed here, I revised PR https://github.com/w3c/dxwg/pull/1295 as follows:

• I removed dcat:hasLastVersion from the relevant sections - see commit https://github.com/w3c/dxwg/pull/1295/commits/1b2456a8e81dcc656091360940655217990ad7d5
• I replaced the DCAT versioning diagrams with one describing the versioning of the MyCity bus stops dataset - see commit https://github.com/w3c/dxwg/pull/1295/commits/5fe2778170ff09c311a50a7f9aa7de6b082f9632

Preview: https://raw.githack.com/w3c/dxwg/dcat-versioning-v2/dcat/index.html#dataset-versions

Please review.

[aisaac]

@andrea-perego these changes improve the proposal greatly, I think!

[andrea-perego]

PR https://github.com/w3c/dxwg/pull/1295 is now merged.

Unless there are any objections, I suggest we close this issue.

[riccardoAlbertoni]

Yes, It can be closed.