W3C home > Mailing lists > Public > www-tag@w3.org > October 2010

Re: Memo on persistent reference - TAG please read before F2F discussion

From: Graham Klyne <GK-lists@ninebynine.org>
Date: Wed, 13 Oct 2010 23:11:02 +0100
Message-ID: <4CB62E76.9050605@ninebynine.org>
To: Jonathan Rees <jar@creativecommons.org>
CC: www-tag@w3.org
Jonathan Rees wrote:
> http://www.w3.org/2001/tag/doc/persistent-reference/
> 
> 
> ISSUE-50
> ACTION-444

Very interesting analysis...

A thought that occurred to me while reading through this was that there is a 
related notion, which I'll call "fragility", that might usefully be considered.

 From your note:

"In choosing one form of reference over another - traditional vs. electronic, 
urn: vs. http:, and so on - one is placing a bet that the form you chose will be 
adequately persistent, or at least more persistent than the one you didn't choose."

"Conservative practitioners will probably not want to rely on a URI or any other 
short "identifier" string alone for reference - they would continue to provide 
references as a combination of conventional metadata (slow to act on) and 
machine-actionable forms such as http: URIs. It might be nice if this practice 
of hybrid references were codified a little bit..."

These comments also allude to what I mean by "fragility" - that a mechanism that 
is subject to a single point of failure (especially when technology-dependent) 
is more likely to fail than one that offers multiple routes to resolution. 
Maybe it's bit like security: for dependability look to multiple overlapping 
layers, such that failure of one (or a few) doesn't leave the system completely 
broken.

(In my observation, a problem with http: URIs can be that in many organizations 
the HTTP URI space is controlled by a (powerful) marketing department with 
little regard for persistence.  This may lead to a certain expectation that HTTP 
URIs are transient, despite exhortations that they should be otherwise and the 
existence of exemplars that stability is possible.)

#g
Received on Thursday, 14 October 2010 07:09:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:28 GMT