- From: Stella Dextre Clarke <sdclarke@lukehouse.demon.co.uk>
- Date: Tue, 10 Aug 2004 19:54:20 +0100
- To: "'Miles, AJ \(Alistair\) '" <A.J.Miles@rl.ac.uk>, <public-esw-thes@w3.org>
Glad to see this issue getting aired. I'm not going to comment on the
options offered, but just raise the questions "Why does it matter?" "Why
would anyone want to know?" And I'll offer at least a couple of answers.
1. On encountering a thesaurus or portion of a thesaurus, one often
wants to know if this represents the current version. One wants to be
quite sure that these are the terms now considered valid for use -
either for indexing or for searching. In this circumstance, typically
one wants to identify which version the portion belongs to, and secondly
whether a later version exists. Depending on the findings, one might
then want to turn to the later version.
2. A slight variation on the above is, having found a thesaurus or
portion thereof, simply to identify which version it belongs to - either
the version number or the dates within which that version was current.
This need might occur in a housekeeping context rather than an
indexing/searching application.
3. A different context is when one is doing retrospective searches. One
wants to find the version of the thesaurus that was valid in a certain
date range, so as to identify the appropriate search terms in that
period. An alternative approach may be to ignore the version(s) but just
to check on particular thesaurus terms and their history notes - during
what period were Terms A and B valid, and before then what was the next
best thing? I should confess that only a perfectionist searcher
actually does this, once in a blue moon; most people don't bother even
looking up the thesaurus in the first place. But they ought to.
There may be other good reasons for wanting to check the versioning. But
the ones above already present several variables - are you doing it in
the course of vocabulary management, or in the course of running an
application for indexing/retrieval? And then, do the publishers allow
access to any version other than the current one? Do they have several
simultaneously online, or perhaps just the current one and if you are
very lucky you can download a text file with the archival versions.
Different authorities take different views as to what is best.
Sorry - no solutions there, just complications. But I hope it is useful
to clarify the need before trying to satisfy it.
Cheers
Stella
*****************************************************
Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, Oxon, OX12 8RR, UK
Tel: 01235-833-298
Fax: 01235-863-298
SDClarke@LukeHouse.demon.co.uk
*****************************************************
-----Original Message-----
From: public-esw-thes-request@w3.org
[mailto:public-esw-thes-request@w3.org] On Behalf Of Miles, AJ
(Alistair)
Sent: 10 August 2004 16:23
To: 'public-esw-thes@w3.org'
Subject: Scheme versioning & change management
Hi all,
A request has come to me about how to handle periodic releases of a
thesaurus encoded in SKOS/RDF. I do think we need to have at least a
basic framework of recommendations to handle this type of scenario
(which is very common), so have started writing up some ideas and
surveying some possibilities for support for existing vocabs ...
(This pasted from
<http://esw.w3.org/topic/SkosDev/SkosCore/SchemeVersioning>)
1 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).
1.1 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 [WWW]DCTerms vocabulary
<http://dublincore.org/documents/dcmi-terms/>
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 [WWW]OWL vocabulary <http://www.w3.org/TR/owl-guide/> 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'.
1.2 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 [WWW]vocab status vocabulary
<http://www.w3.org/2003/06/sw-vocab-status/ns#> 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:
1. where a concept should be replaced in metadata by EITHER one or
other of the targets.
2. 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.
---
Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
Email: a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440
Received on Tuesday, 10 August 2004 20:05:12 UTC