[versioning-3] is redirection enough?

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