Re: Scheme versioning & change management

At 17:23 10/08/2004, Miles, AJ (Alistair) wrote:
>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.

Many thesauri are simply published in editions. There is edition 1, 
followed by edition 2, edition 3, and so on. There is no notion of a "base 
vocabulary" in this kind of scenario (though there may be, as Stella has 
mentioned, a need perhaps to identify the most recent edition.) I don't 
understand to what the URI for the "base vocabulary" (i.e. 
http://example.org/myScheme) would refer in this kind of situation and/or 
how it would be used. Would it resolve to the latest edition?

>1.2 Management of Concepts
>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 [snip]
>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.

It seems to me that there are already two ways to express this kind of 
relationship.

1) Non-preferred terms (alternative labels)
A concept that is split into two new concepts should have as non-preferred 
terms the original term used for the original concept. A concept that is 
merged with another concept to form a third should carry in the new concept 
the previous terms as non-preferred terms. You may not be able to map a 
URI, granted, but you can certainly map a previously accepted/now 
deprecated label to a new term to be able to find these cases. This may not 
be as explicit as one would like, but it would do well enough for a number 
of use cases.

2) Mapping
The newer version of the thesaurus could be mapped to the previous version 
of the thesaurus using the same facilities as are available for mapping 
between any two vocabularies. The fact that most of the mappings are 
straightforward doesn't matter, only the non-direct mappings need to be 
handled. This should handle all the use cases that need more explicit 
information than is available through the non-preferred terms.

In short, I personally don't really see any overwhelming need to invent new 
vocabulary to handle these changes in concepts at the cost of further 
complications in the SKOS-Core schema.

Ron