www  | Addressing

Catalog Numbers: URNs

(Issues of reliability, authenticity, and latency are discussed in Link Reliability: URNs are Not the Answer)

See Also: Catalogs

Naming is as much a social problem as a technical problem. Requiring 100% persistent names is folly. (See: notes on reliable links) But there is a use for institutionalized names, going all the way back to Engelbart's requirement for Library service.

STANF Terry Winograd Early draft version 12/2/93
an excellent discussion of the nature of the problem, and a proposed solution
Introduction to Persistent Uniform Resource Locators, Keith Shafer, Stuart Weibel, Erik Jul, Jon Fausey
another proposed solution, using the existing http: URL schemes so as to be compatible with the installed base of clients.
The Handle System Version 3.0 An Overview
Another system employing the "indirect though a stable institution" technique. It claims to solve problems it does not: "The name lasts longer than any specific computer system or organization" but later states the truth: "The long term value of the handle system depends upon the effectiveness of the organizations that operate it." The use of hashing into a pool of servers is an interesting idea.
How Roy would Implement URNs and URCs Today, R. Fielding, 07 Jul 1995
more solutions using technologies as specified, with some enhancements to the implementations
Decoupling the URL Scheme from the Transport Protocol
@@why I like this doc, related to original web implementation guidelines

Research Notebook

See also: notes on hyper-g p-flood consistency mechanism



N2C  - Given a URN, return a collection of meta-information on
                    the named resource. The format of this response is the
                    subject of another document.

             N2L  - Given a URN, return a URL
i.e. "given N find one L such that N --located-at--> L"

(where located-at is defined in a profile/schema about web names)

             N2Ls - Given a URN, return a set of URLs
i.e. "given N find some/all L such that N --located-at--> L"

             N2R  - Given a URN, return an instance of the resource.
i.e. GET, that is
     "given name N, find one artifact A such that N refers to A"

             N2Rs - Given a URN, return multiple instances of the resouce,
                    typically encoded using multipart/alternative.
hmmm... cool idea. need a collection of metadata to describe the
relationships between the artifacts (instances)

     "given name N, find some/all artifacts A[i]
         such that N refers to A[i] for each i"

             N2C  - Given a URN, return a collection of meta-information on
                    the named resource. The format of this response is the
                    subject of another document.

     "given N, find artifact A such that
           A ==describes--> N"

             N2Ns - Given a URN, return all URNs that are also identifers
                    for the resource.
      "given N, find all N' such that N' --alias--> N"

             L2R  - Given a URL, return the resource.
       same as U2R, i.e. GET
             L2Ns - Given a URL, return all the URNs that are identifiers for
                    the resource.
       "given L, find all N such that N --located-at--> L"

             L2Ls - Given a URL, return all the URLs for instances of
                    of the same resource.
       "given L, find all L' such that ??? "

             L2C  - Given a URL, return a description of the resource.

     id -- rel --> id
     id refers to artifact
     artifact ==rel--> id
     id has rel artifact

Naming profile:
      id1 --located-at--> id2
      id1 --moved-permanently-to--> id2
      id1 --alias--> id2

last update by $Author: sysbot $ on $Date: 2014/02/24 22:45:39 $