ABCDEFGHIJKLMNOPQRSTUVWXYZAAABAC
1
Versioning aspects in the wiki Desiderata and refinement of version aspectsDCTermsPROV-OADMSPAVRegistry / VersionFRBRPossible solution in DCATCorrisponding issue on github
2
Provided on a stable namespaceyesyesyesyes, PURLyes, PURLyes, PURL
3
Being a standard with the maturity required to be included in DCAT normative partyesyesnonono
4
Reusing/mapped with DCTERMSXa non normative mapping existmostlyyes, yes??
5
Reusing/mapped with PROVa non normative mapping existXnoyesno??
6
Supporting qualified relationsnoyesnononono
7
Fitting in the DCAT backbone yes, it is orthogonalyes, it is orthogonalyes, no domain inferring new classes for the property involved in the versioningyes, no domain inferring new classes for the property involved in the versioningRegister could be partially overlapping with DCAT. property as reg:status has domain reg:RegistryItem. The version ontologies is orthogonal though it entails the classes version:VersionedThing and version:Versionfour-levels backbone which can be mapped to dcat, probably in more than a way, and with some interpretations
8
Applicable to all the DCAT first class citizensyesyesYes, no domain inferring new clases for the property involved in the versioningyes, no domain inferring new classes for the property involved in the versioningNo entirely, some relations can soleluy be applied to certain kinds of frbr entity ( for example, frbr:alternate only to frbr:Manifestation, frbr:revision only to frbr:Expression)
9
Driven by a community effortyesyesyespartiallyyes
10
Available in RDFyesyesyesyesyesyes
11
Version informationDistinguishing between versions and VersionedThingsNot explicitlyXnoyes, without defining specific class, but property are suggested to be used considering the disctinction bewteen long living resource and versioned resourcesyes, defining specific class, version:VersionedThing and version:Versionsomehow
12
Providing terms for version informationnonoyes, via owl:versionInfopav:versionyes, via owl:versionInfonoowl:versionInfo
https://github.com/w3c/dxwg/issues/92
13
Providing terms for version differencesnonoyes, via adms:versionNotesnonono?adms:versionNotes or equivalent in the DCAT namespace depending on if ADMS can be admited as normative namespace
https://github.com/w3c/dxwg/issues/89
14
Resource status / lifecycleProviding terms for status and life cyclenono +adms:status rages in skos:Concepts
- no entailing specific domain classes
-no specific conceptscheme for status, and terms for ordering the stages of the status		-reg:status entails the reg:RegistredItem as domain.
+ it uses also a default conceptscheme derived from ISO 19135 for expressing the status.
+ reg:nextState reg:priorState give the label of a state which can follow/precede a state.		 +adms:status ranges in skos:Concepts or equivalent in the DCAT namespace depending on whether or not ADMS is admited as normative namespace
? we might proposed a default conceptscheme, for example derived from ISO19135
? we might consider to mint some dcat:nextState dcat:priorState to point of a state which can follow/precede a state
? let's keep the notion of "workflow" as simple as belonging to a prefigured set of status. We do not want to reinvent the wheel and more complex info can be provided by provenance using PROV, also http://www.opmw.org/model/OPMW provides explicit definition of Workflows execution and templates by extending PROV-O and Plan-P
https://github.com/w3c/dxwg/issues/1238
15
Providing terms for period of validitydcterms:validnono, but it could have used dct:validno +version:interval relates a thing version to an interval during which the version was valid, ranges in time:Interval ;
? we can adopt (1) dct:valid providing specific note for its range to make it homogeneous with dct:temporal or (2) version:interval, or (3) reuse extend the definition of dct:temporal
16
Providing dates fo acceptance, submission, etcyesnoIt could have used the dct terms dcterms:dateSubmitted etcnno, but it could have reuse the dcterms'sReusing DCTerms
17
Earlier/later versionsProviding current version it seems that DCT mixes together these aspects defining dcterms:hasVersion and its inverse dct:isVersionOfnoadms:lastpav:hasCurrentVersion (subproperty of dct:hasVersion and prov:generalizationOf)Version:currentVersion and dct:isVersionOf
18
Providing specialization/generalization prov:specializationOf,
prov:generalizationOf		nopav:hasVersion (subproperty of prov:generalizationOf)
19
Providing previous, next versionnoadms:next , adms:prev pav:previousVersion (subproperty of prov:alternateOf)
pav:hasEarlierVersion (subprop of prov:alternateOf and prov:wasRevisionOf)		It seems that every version is displacing the previous, the vocabulary does not provides terms for non-displacing revision, in fact, it uses dct:replaces see supersession row
20
Providing a revision (it isn't necessarly a displacement /supersession)
prov:wasRevisionOfno
21
Supersessiondcterms:replaces , dcterms:isReplacedByprov:wasInvalidatedBy might provide some support, but it links to an activitynono, it could have used dct:replaces or prov:wasInvalidatedBydcterms:replaces , dcterms:isReplacedBy
22
Derivationdcterms:sourceprov:wasDerivedFrom, prov:hadDerivationpav:derivedFrom
23
VariationDistinguishing alternate noprov:alternateOfyes, versions are alterateOf as embedded in the pav:previousVersion
pav:hasEarlierVersion
24
Distinguishing translationnono adms:translationno
25
Distinguishing adaptation mixed together by dcterms:hasVersion and its inversenonono
26
Distinguishing curator from creatordct:publisher is a kind of curator?nonopav:curatedBy
27
Compatibilitynononono
28
29
30
Green - feature we can consider as inspiring for building a solution
31
Yellow - weak points
32
Red - problematic aspects
33
 + indicates pros
34
 - indicates cons
35
? indicates set of possibilities in which we might want to pick one
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100