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.