SkosDev/SkosCore/SchemeVersioning
Vocabulary Support and Conventions for Scheme Versioning and Change Management
Versioning and change management is a vital issue. There are a number of vocabularies and de facto conventions that support bits and peices of what's needed ... let's see if we can bring it all together into a coherent and fairly complete framework ...
(Basically this is a survey of change management and versioning features from various vocabs, with some suggested usage scenarios and applications, and also some new suggested terms ... all hypothetical and suggestion).
Versioning and Management of Concept Schemes
Scenario: An authority owns and manages a vocabulary. Although the vocabulary is continuously evolving, the authority periodically releases versions (snapshots) for their user community to work to.
In this scenario I suggest the convention that a URI be defined to refer to the scheme, and separate URIs are defined to refer to each version of the scheme. E.g. (trivial example) ...
http://example.org/myScheme http://example.org/mySchemeVersion1 http://example.org/mySchemeVersion2 http://example.org/mySchemeVersion3
However, the base URI for all concept identifiers should not be altered between versions.
I.e. A set of concepts is defined and published. This set of concepts are members of the base vocabulary. Additionally these concepts may or may not be members of versions of the vocabulary, e.g. (examples in RDF+turtle) ...
@prefix ex: <http://example.org/>. @prefix skos: <http://www.w3.org/2004/02/skos/core#>. ex:conceptA skos:inScheme ex:myScheme; skos:inScheme ex:mySchemeVersion1; skos:inScheme ex:mySchemeVersion2. ex:conceptB skos:inScheme ex:myScheme; skos:inScheme ex:mySchemeVersion3.
The DCTerms vocabulary has properties that allow you to express the relationship between the base vocabulary and vocabulary versions ...
@prefix ex: <http://example.org/>. @prefix dct: <http://purl.org/dc/terms/>. ex:myScheme dct:hasVersion ex:mySchemeVersion1; dct:hasVersion ex:mySchemeVersion2; dct:hasVersion ex:mySchemeVersion3. ex:mySchemeVersion1 dct:isVersionOf ex:myScheme. ex:mySchemeVersion2 dct:isVersionOf ex:myScheme. ex:mySchemeVersion3 dct:isVersionOf ex:myScheme.
The OWL vocabulary has properties that allow you to express relationships between scheme versions ...
@prefix ex: <http://example.org/>. @prefix owl: <http://www.w3.org/2002/07/owl#>. ex:mySchemeVersion3 owl:priorVersion ex:mySchemeVersion2. ex:mySchemeVersion2 owl:priorVersion ex:mySchemeVersion1.
OWL also has an annotation property allowing you to describe version information as prose ...
@prefix ex: <http://example.org/>. @prefix owl: <http://www.w3.org/2002/07/owl#>. ex:mySchemeVersion3 owl:versionInfo 'The following concepts have been added: x y z. The following concepts have been deprecated: a b c. etc. ...'.
DCTerms also has some basic properties allowing you to state the dates at which a resource was created, issued (i.e. published) and modified ...
@prefix ex: <http://example.org/>. @prefix dct: <http://purl.org/dc/terms/>. ex:mySchemeVersion3 dct:created '2003-06-20'; dct:issued '2003-08-04'; dct:modified '2004-06-26'.
Management of Concepts
Usually in the thesaurus world concepts go through a lifecycle in relation to the schemes in which they are members: they begin as candidates, then they are full members, and finally they may be dropped (deprecated).
This could be a requirement of SKOS Core to support this style of concept management. To offer a suggestion, one way of doind this would be to extend the skos:inScheme
property, as in e.g. ...
@prefix ex: <http://example.org/>. @prefix skos: <http://www.w3.org/2004/02/skos/core#>. @prefix poss: <http://example.org/skoscoresuggestions#>. ex:conceptA poss:candidateInScheme ex:mySchemeVersion1. ex:conceptA skos:inScheme ex:mySchemeVersion2. ex:conceptA poss:deprecatedInScheme ex:mySchemeVersion3.
There is also the vocab status vocabulary which allows you express the stability of an individual term in and RDF vocabulary (as one of 'stable' 'testing' and 'unstable'. This could also be used for SKOS concept schemes, as in e.g. ...
@prefix ex: <http://example.org/>. @prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#>. ex:conceptA vs:term_status 'stable'; ex:conceptB vs:term_status 'testing'; ex:conceptC vs:term_status 'unstable';
... although how this should be combined with the candidate/member/deprecated scheme status values (if they are used) is not clear.
The vocab status vocabulary also has another property, vs:moreinfo
which is designed to point to some prose describing the status of the term further.
As a convention for managing URIs for concepts, I suggest that once a concept URI has been published, preference should always be given to deprecating and replacing with a new concept, rather than altering the concept.
Usually, when a concept is dropped from a scheme, another concept or combination of concepts is added to replace it.
Where one concept has been replaced by another, the DCTerms vocab has some properties that allow this relationship to be expressed e.g. ...
@prefix ex: <http://example.org/>. @prefix dct: <http://purl.org/dc/terms/>. ex:conceptA dct:isReplacedBy ex:conceptC. ex:conceptC dct:replaces ex:conceptA.
Where a concept has been replaced by a combination of concepts, some new vocabulary may be required. I can imagine two cases:
- where a concept should be replaced in metadata by EITHER one or other of the targets.
- where a concept should be replaced in metadata by BOTH of the targets.
... we could invent som enew vocab to cover these. The interesting use scenario here is, if replacement rules are expressed in RDF, then automated tools can be written to update metadata repositories, or at least provide support to humans in that work.