[Scrollkeeper-devel] Does Simple-URI equal URN?

[Bob S. <bo...@sc...>]

> From: Dan Mueth <d-...@uc...>
>
> You don't typically want the completely unique identification (UUID is for
> {document, language, version, format}, but the document identifier (NUID
> is what I called it) {document but not language, version, or format}.  
> This would be mapped onto names to make things "nice" like IP addresses
> are mapped onto names.  Of course we won't use a DNS server - we'd put the
> name into the metadata and use a database on the web for reference use
> only.  It would still be a "first come, first serve" basis for giving out
> names (like domain names), although inappropriate use would be frowned
> upon of course.

This unique ID is sounding a lot like the Uniform Resource Name (URN)
effort at IETF and W3C.  Various parties have been trying to settle
on a standard for identifying a given resource with a single
stable ID name, which can then be mapped in some fashion to
an address (or addresses).  They are trying to solve the
same problem of creating logical cross references (stable) instead
of hard-coded address references (unstable).

Here are the stated requirements for URNs:
(From: <http://www.dlib.org/dlib/february96/02arms.html>)

- "Global scope: A URN is a name with global scope which does
not imply a location. It has the same meaning everywhere. 

- "Global uniqueness: The same URN will never be assigned to
two different resources. 

- "Persistence: It is intended that the lifetime of a URN be
permanent. That is, the URN will be globally unique forever,
and may well be used as a reference to a resource well
beyond the lifetime of the resource it identifies or of any
naming authority involved in the assignment of its name. 

- "Scalability: URNs can be assigned to any resource that
might conceivably be available on the network, for hundreds
of years. 

- "Legacy support: The scheme must permit the support of
existing legacy naming systems, insofar as they satisfy the
other requirements described here. ... 

- "Extensibility: Any scheme for URNs must permit future
extensions to the scheme. 

- "Independence: It is solely the responsibility of a name
issuing authority to determine the conditions under which it
will issue a name." 

The URN effort has been going on since 1994
without yet producing a real standard.  As far
as I can tell, the only de facto standard is the IETF
RFC 2141 "URN Syntax" at <http://www.ietf.org/rfc/rfc2141.txt>.
I think the general global solution must be a hard
problem.  There is certainly plenty of material to
study at www.w3.org on URNs.

But the URN syntax could be used for Dan's suggested SK
identifier.  In fact, OMF already seems to support it.
Looking at the OMF Template form at
<http://www.ibiblio.org/osrt/omf/cgi-bin/template.pl?verflag=1>
I see that they define the <identifier> element as "a
unique ID by which the resource may be identified and from
which the resource may be retrieved (e.g. a URL or URN)."

Also, the OMF DTD says that all elements can be repeated
for a resource.  That means a resource could have one
<identifier> for its URI and another <identifier>
containing its URN.  Add yet another to fall back to
the source site, if necessary.

The URN syntax is pretty simple.  From the RFC:

   <URN> ::= "urn:" <NID> ":" <NSS>

   where <NID> is the Namespace Identifier, and <NSS> is the Namespace
   Specific String.  The leading "urn:" sequence is case-insensitive.
   The Namespace ID determines the _syntactic_ interpretation of the
   Namespace Specific String

The OMF project, which is setting itself up as the
centralized cataloging site, would define the Namespace as
perhaps "omf:".  Then OMF would assign and regulate
Namespace Specific Strings, which are the names that
Dan has proposed.  So a simplified URN for a Linux man page
might look something like <urn:omf:linux.man1.ls>.  Of
course, the trick is still assigning unique names for the
third field (please don't take my example as a literal
suggestion for a naming scheme).  The OMF naming scheme
would have to take into account the many factors that have
already been discussed.  But the OMF would have the final
authority since its namespace would be used.  Using an OMF
namespace reduces the problem of a unique id from
globally-unique to OMF-unique, a far simpler problem.

You might think having two <identifier> elements would
be confusing, but each is recognizable by its own
protocol, as in this example:

<resource>
 <title>ls manual page</title>
 <identifier>urn:omf:linux.man1.ls</identifier>
 <identifier>file:/usr/share/man/man1/ls.1</identifier>
 <identifier>http://www.linuxdoc.org/man/man1/ls</identifier>
</resource>

Any document could cross reference to an OMF-registered
document's URN.  If an SK-aware browser was reading a
document with a cross reference to a URN, it could look in
its metadata set to see if that urn:<identifier> also had a
file:<identifier>.  If not, it could fall back to an
http:<identifier> if it were available.  As a last resort,
the browser would query the OMF site for the latest
resolution of that URN.  

I went a little further and checked the Dublin Core
Metadata Element Set, on which OMF is based.
Their definition of the <identifier> element is
"An unambiguous reference to the resource
within a given context.  Comment:  Recommended best
practice is to identify the resource by means of a string
or number conforming to a formal identification system.
Example formal identification systems include the Uniform
Resource Identifier (URI) (including the Uniform Resource
Locator (URL)), the Digital Object Identifier (DOI) and the
International Standard Book Number (ISBN)."

Dublin Core doesn't mention URNs, probably because they aren't
recognized as a formal standard.   There is no global
registration and resolution mechanism for the Namespace
part of a URN, so one cannot rely on a URN being
resolved in all contexts.  But within the "given context"
of an SK metadata set, the omf: namespace has sufficient
meaning to be resolved.

My point of all this verbiage is that I think OMF already
has a mechanism for these unique names, although I am not
suggesting the actual naming scheme.  I also wanted
to make sure this scheme stays within the RDF standard
so that RDF tools can be used to process them. 

Comments?

bobs
Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The Santa Cruz Operation, Inc.              fax:   (831) 429-1887
                                            email: bo...@sc...