RE: URNs for personal documents?

While 
       tag:felix.klee@inka.de,2006:...
is longer than
       urn:urn-6:a... 

by 10 characters, readers of your text documents are likely
to appreciate the implicit metadata, especially if they
come across the reference some time after you've moved on
from maintaining your resolution service. It gives a clue.

And the result scales -- everyone could use 'tag' for their
privateIDs (although it's better if you have a short email
address), while the URN registry would be a mess if everyone
applied for a URN namespace for their personal collection
of documents.

Surely scalability is an important characteristic of any
recommended practice.

Larry


> At Wed, 22 Mar 2006 15:11:29 -0500,
> Michael Mealling wrote:
> > But now that you've been inundated with the "use HTTP!", "use DOIs!",
> > "use XRIs", "use PURLs!" suggestions I'm sure your more confused than
> > when you started. ;-)
> 
> Well, none of the suggestions really matches my requirements (except
> yours):
> 
> * Short URNs (for example, I want to use URNs in text documents, and
>   long URN names hamper readability).  Violated by: tag URI, duri, DOI,
>   PURL.
> 
> * Ability to create new URNs free of charge and without having access to
>   the outside world (e.g. the Internet).  Violated by: DOI, personal
>   domain, PURL.
> 
> * Precise identification of documents and independence of a particular
>   environment (OS or whatever).  Violated by: Yahoo desktop, Google
>   desktop.
> 
> * Persistency.  Violated by: personal domain.
> 
> So, I plan to indeed apply for an informal URN namespace, as you
> suggest.  The specification for "urn-4" comes pretty close to what I
> have in mind.  Thus, I may largely reuse it.
> 
> I'm almost finished with writing two little tools.  One is for quickly
> resolving URNs to local documents using a special cache file. 
>  The other
> is for extracting URNs from meta information of documents and putting
> them into the cache.  This tool also checks cache consistency, i.e. it
> checks that no two documents have the same URN, and that each URN
> previously assigned is associated with a document (one document may have
> multiple URNs).
> 
> Furthermore, I've written a simple EMACS package for browsing documents
> associated with URNs:
> 
>   http://www.emacswiki.org/cgi-bin/wiki/BrowseURN
> 
> All in all, this solution seems to work pretty well: I'm already
> employing it for everyday use, so far with the namespace identifier
> "urn-6" which I may eventually get.  As a side note: At the moment I'm
> limiting myself to URNs of the form "urn:urn-6:a..." (note the "a")
> where "..." is any string composed of characters permitted according to
> <urn:ietf:rfc:2141>.  This allows me to later specify further sub name
> spaces with special properties, though I may rarely if ever need this.
> 
> -- 
> Felix E. Klee
>

Received on Monday, 3 April 2006 07:41:26 UTC