[versioning-3] is redirection enough?

[Norman Gray]

On 2008 Jan 29, at 21:58, Rob Seaman wrote:

> I suggest that there should also be a "latest" link that is  
> redirected as appropriate.  At any given time there will be several  
> historical versions, a single current version, and a single version  
> under development.  Presumably each vocabulary will contain metadata  
> describing versioning such that an application that cares about such  
> changes can detect them.  Beyond that we start to enter a realm of  
> evolutionary complications that I don't think we're ready to deal  
> with.

I suppose this depends on how the vocabularies are served, and on how  
clients use them.

Scenarios:

1. Clients use http://blah/latest#X, and so GET http://blah/latest,  
this returns a 302 Found to http://blah/2008, and that's the RDF that  
the client uses.  In this case, the versioning is done partly by the  
HTTP protocol in pointing to the latest version, and partly by the  
RDF, since the latest version of a vocabulary would presumably include  
the links to the version it replaces.  This is how DC works.

2. Clients GET http://blah/latest and are returned (200) the contents,  
as RDF, of the latest version.  I think this is a non-starter, since I  
think serving it this way would require those RDF contents to include  
an internal declaration of http://blah/latest as their namespace, and  
not the http://blah/2008, and that's too confusing.

3. Clients use http://blah/2008 as the namespace, and GET that.  In  
this case, the only way clients learn about an updated vocabulary is  
if either (a) when it's superceded, a vocabulary is reissued with SKOS  
mappings to the replacement terms; or (b) a new version of a  
vocabulary contains SKOS mappings to the terms it replaces, and  
documentation of terms that are deprecated; or (c) vocabularies don't  
contain such mappings internally, but a separate list of inter-version  
mappings is maintained at an unchanging well-known URL, which  
applications can retrieve when necessary.

The Jakob Voß paper is interesting, but doesn't really seem to deal  
with the problem at this level.

I think (2) is out, because of the namespace complications.  I think  
(3a) is out, because reissuing a vocabulary with changes gives me the  
creeps.

(3b) seems awkward, because it doesn't alert a client to the presence  
of a new vocabulary.  But I don't believe that a client needs to know  
this (though it might depend on what the client is wanting to do).  If  
a client has retrieved a vocabulary file at http://blah/2008, it is  
because it needs to know something about a concept in the namespace http://blah/2008 
  (via either scenario 1 or 3), which it doesn't have in-built  
knowledge of.  It discovers that it is linked to a previous version of  
that vocabulary which it _does_ know about, so it goes away happy.   
Alternatively, if it has built-in knowledge of http://blah/2009, then  
it also presumably has knowledge of that vocabulary's links to the  
earlier version at http://blah/2008, which means it doesn't even have  
to bother retrieving the 2008 version's RDF.

Thus, theorem: a client never needs to be directed forward in time in  
a list of vocabulary versions.

If so, then (1), (3b) and perhaps (3c) all seem reasonable to me.

Thus, when Bernard says:

>> Wouldn't it be better for me to say that the thing is a http://blah/2008#X 
>>  once and for all?  At least then I'm committing myself to what  
>> this concept means in 2008, and not whatever shades of meaning it  
>> might acquire in the future.

> But what happens to applications relying on this URI, but wanting to  
> use only up-to-date versions of the concept. How will they know  
> when, if, how to ... update to new URIs and descriptions?

perhaps the answer is: they don't.  If the application knows what http://blah/2009#X 
  is, then it knows what .../2008#X is (because .../2009 explained),  
and if it doesn't, then it doesn't care anyway.

And:

> Deprecation mechanism can be implemented in structured vocabularies.  
> Actually we manage that in Mondeca's software. You can't delete an  
> indexing concept without redirecting to another one. It does solve  
> every problem, for example it does not provide any solution to the  
> situation where a single concept is split into several ones, etc.

Sure.  I thought the SKOS standard had a variety of annotations  
defined for expressing such deprecations, but I can't find it in the  
current (20080125) reference.  But I'm sure there are other  
vocabularies defined for this.  Does Mondeca use one such?

Best wishes,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
eurovotech.org  :  University of Leicester