- markup (76)
- xml (11)
- xslt (23)
- pipelines (8)
- atom (9)
- overlapping markup (6)
- schema (11)
- creole (5)
- dtll (1)
- xforms (1)
- xpath (1)
- xquery (2)
- coding (2)
- datagovuk (1)
- genealogy (4)
- hardware (1)
- linked data (16)
- modelling (1)
- named graphs (1)
- opendata (1)
- provenance (1)
- psi (3)
- skos (1)
- sparql (4)
- Talis (7)
- unicode (1)
- uri (4)
- versioning (1)
- visualisation (6)
- web (78)
- google (4)
- html5 (5)
- jQuery (2)
- rdf (46)
- ontologies (2)
- rdfa (8)
- rdfQuery (5)
- rest (6)
- wikis (1)
- work (3)
- legislation (2)
- xmlsummerschool09 (2)
- life (28)
- children (5)
- equality (6)
- gtd (1)
- environment (4)
- gadgets (5)
- software (3)
- xlinq (2)
- conferences (11)
- ukgc09 (1)
- xtech (9)
- xtech2008 (3)
- blog (8)
- drupal (3)
Re: Versioning URIs
Really clear laying out of the issues Jeni. However I got a sense of deja vu, as this is an issue that pre-dates the web.
In my very first computing job (COBOL programming for Cumbria County Council) many many years ago, I read an article in Computer Weekly about choice of keys (I think for ISAM not even relational DBs). The article argued that keys should NEVER contain anything informational as it is bound to change. The author gave an example of standard maritime identifiers for a ship’s journey (rather like a flight number) that were based on destination port and supposed to never change … except when the ship maybe moved to a different route. There is always an ‘except’, so, the author argued, keys should be non-informational.
Just a short while after reading this I was working on a personnel system for the Education Dept. and was told emphatically that every teacher had a DES code given to them by government and that this code never changed. I believed them … they were my clients. However, sure enough, after several rounds of testing and demoing when they were happy with everything I tried a first mass import from the council’s main payroll file. Validations failed on a number of the DES numbers. It turned out that every teacher had a DES number except for new teachers where the Education Dept. then issued a sort of ‘pretend’ one … and of course the DES number never changed except when the real number came through. Of course, the uniqueness of the key was core to lots of the system … major rewrite :-/
The same issues occurred in many relational DBs where the spirit (rather like RDF triples) was that the record was defined by values, not by identity … but look at most SQL DBs today and everywhere you see unique but arbitrary identifying ids. DOIs, ISBNs, the BBC programme ids - we relearn the old lessons.
Unfortunately, once one leaves the engineered world of databases or SemWeb, neither arbitrary ids nor versioned ones entirely solve things as many real world entities tend to evolve rather than metamorphose, so for many purposes http://persons.org/2009/AlanDix is the same as http://persons.org/1969/AlanDix, but for others different: ‘nearly same as’ only has limited transitivity!