URIs and Persistence: How long is forever?

1. Acknowledgements

• I'm fortunate to work with and learn from some of the proprietors of the Web
  • Most notably Tim Berners-Lee and Dan Connolly
• They're not in any way responsible for the opinions presented here

2. URIs unpacked

• 'URI' stands for

  Uniform

  There's a standard generic syntax (specified by IETF RFC 3986) and (partial) semantics

  Identifier

  URIs are identifiers, that is, names (not addresses)

  Resource

  What it is they identify -- anything at all

3. More about syntax

• Organised hierarchically
  • Left-to-right dominance
  • scheme ":" hier-part [ "?" query ] [ "#" fragment ]
• Federated (each scheme defines its own syntactic details)
• Absolute or relative

4. More about resources

• Who gets to say what the resource is that a URI identifies?
  • The owner of the URI
• Who is the owner (sometimes also called the 'minter')?
  • For URI schemes (such as http and ftp) whose hier-part starts with a domain name, the owner of that domain name.
  • For others, should (!) be specified by the scheme specification.

5. More about identification

• In principle, all URIs are opaque
  • That is, no conclusions about the shape of the space of things identified should be drawn from the shape of the set of their identifiers.
• In practice, e.g. for http URIs, this is false
  • It's entirely up to minters to manage this, and document it (or not :-(
• As for (some) naming elements of ordinary language, URIs can be deiectic:
  • http://localhost/
  • file:///etc/hosts (and indeed, all file: URIs
  • http://www.guardian.co.uk/

6. What about web pages?

• Isn't that what URIs are really for?
• Short answer
  • No!
• It's perfectly OK to mint URIs with no intention to ever produce a web page at all
  • http://www.ltg.ed.ac.uk/~ht/Concepts/democracy
  • There, I just did it.
• Longer answer
  • 3 billion web page authors can't be wrong
  • But what they've authored are not the resources identified by the URIs
    • They're representations of those resources.
    • (from WebArch)

7. Resources vs. representations

• Why make this distinction? That is, why isn't the web page itself the resource?
  • Some resources don't have web pages associated with them in any way
  • Many resources have more than one web page associated with them
  • Many URIs produce representations without there being any static web pages involved

8. A digression about media types and encodings

• [Assume all URIs are http: URIs and all retrieval uses HTTP]
• A message, i.e. the response to an HTTP GET request, includes information about the character encoding and media type of the byte-string which follows.
• The character encoding tells you how to interpret the byte-string as a character string, e.g. iso-8859-1, shift-jis, utf-8.
• The media type tells you how to interpret the resulting character string, e.g. application/jpg, application/pdf, text/html

9. Multiple representations

• So a server might have
  • utf-8 or iso-8859-1 encodings of
  • application/xml or text/html representations of
  • a document in English or Irish
  • representing today's weather report for Dublin
• 8 representations for one (time-varying) resource.
• WebArch uses the phrase 'information resource' for the subset of resources which can be pretty much completely captured in a message.
• So (today's) Dublin weather report is an information resource, but Dublin itself is not.

10. Information resources

• Another way to look at this is that for information resources, the retrievable representations are (isomorphic to) the information resource itself -- consider
  • Beethoven's Symphony No. 6: http://downloads.bbc.co.uk/rmhttp/radio3/symphony6_beethoven_radio3.mp3
  • The Charge of the Light Brigade: http://eserver.org/poetry/light-brigade.html
  • The XML 1.0 Recommendation: http://www.w3.org/TR/REC-xml/
  • The W3C at 10 logo: http://www.w3.org/2004/09/logos/W3C10_logo_short_fc.png

11. The Network Effect

• The history of XML is illuminating
  • XML was designed to solve the online-documentation problem
  • It succeeded for a completely different reason
    • The commercial value of data interchange
• The use of http: URIs as the foundation of the Semantic Web is intended to enable the same effect
  • But for machines this time, instead of people

12. Architecture of the World Wide Web

• A grandiose concept
  • In practice an ongoing post-hoc analysis project with respect to a vast, messy, poorly delimited real-world phenomenon
• A document
  • The first publication from the Technical Architecture Group of the W3C (World Wide Web Consortium)
  • Architecture of the World Wide Web, Volume One
  • The goal of the document is to "preserve [the properties underlying the success] of the information space as the technologies evolve"
  • It contains a number of "Principles, Constraints and Good Practice Notes"

13. Grandmother observations about the Web

• "Global naming leads to global network effects"
  • A prerequisite for citation
  • A challenge for many existing schemes
• "To benefit from and increase the value of the World Wide Web, agents should provide [http:] URIs as identifiers for resources"
  • I.e. not just any global name, but a particular kind of global name

14. More from Grandma Webarch

• It's good for the ownership of a name (URI) to be manifest in the form of that URI
  • We need to know who is responsible for the name and its use
• "A URI owner should not associate arbitrarily different URIs with the same resource."
• "Agents do not incur obligations by retrieving a representation."
  • HTTP 'GET' is side-effect free (c.f. cookies)
• "A URI owner should provide representations of the resource it identifies"

15. More on terminology and technology

• A retrieved representation is always accompanied by one crucial kind of metadata:
  • Its media type, e.g.
    • text/html
    • image/png
    • audio/mp3
    • See the IANA registry for a full list
  • That is, information sufficient to enable an agent to interpret the representation.
    • Some agents, e.g. web browsers, present interpreted representations to human beings
    • Others, e.g. search engines, process interpreted representations automatically for their own purposes
  • Retrieval may involve content negotiation
    • When multiple representations are available
      • JPG vs. PNG vs. SVG vs. GIF . . .
      • French vs. German vs. Chinese vs. . . .
      • DTD vs. XML Schema vs. . . .
• So information resources are not necessarily concrete
  • It's perfectly coherent to get real value from a URI which indentifies an abstraction
  • For example, http://www.guardian.co.uk/uklatest

16. Connection with "persistent indentifiers"

• The TAG is concerned not only to protect the Web as it is
  • but also to extend its reach and value
• This often amounts to strenuous efforts to combat the NIH syndrome
  • It's so hard to accept that the solution to your problem is already available, off the shelf, but with someone else's name on it
• "No scheme or syntax guarantees persistence of any kind" (John Kunze)
  • Accordingly persistent identifier efforts can and should save huge amounts of fuss by focussing on the non-technology substrate issues involved in producing persistence
  • Just use http: URIs as the technology substrate

17. Lookup plus hierarchy

• Virtually all public distributed naming system proposals we have seen have these properties
  • Some kind of global lookup to establish a context
  • Some kind of navigation through a structured space determined by that context
• These properties address the fundamental needs of such a naming system
  • It's distributed (no single central source of name bindings)
  • It's scalable (no intrinsic upper bound on what can be named)
• The http URI scheme is such a system
  • The domain name part (e.g. www.w3.org) can be resolved by appeal to a distributed lookup mechanism (DNS)
  • The path part (e.g. /2001/tag/webarch/) provides for scalable navigation to a particular name binding within that context
• There are huge benefits to using an existing, well-tried approach, that is, http URIs
  • So you need a very good reason to attempt to launch a new public distributed naming story

18. (Parenthesis on distributed, secure and human-readable)

• You can have any two :-(
• See SFS (Self-certifying File System)
• The simplest kind of secure names are names which include a one-way unique hash of the thing that they name.

19. Parenthesis on versioning and extensibility

• The scandal of computer science
• None-the-less, try not to forget that none of what you build will last forever
  • or even until next year

20. Just what is the problem?

• If http: is so cool
  • Why do people keep proposing new naming stories?
    • urn:nzl
    • RFC 3688
    • UBL
    • xri:
    • RFC 4452
    • info:
    • LSID
    • to name just a few. . .
• Surely there must be good reasons for all of this?

21. myRIs and http: URIs compared

• Let's give all these naming proposals a name: myRIs
• And compare the requirements they are typically advertised as addressing with the situation wrt http: URIs.

22. Standardised

myRI goal

myRIs should be susceptible to standardization within administrative units.

• This goal appears to be directed at guaranteeing certain invariants
  • For example with respect to the structure of identifiers and the availability of the resources they identify.

http: response

This is largely a management issue, not a technical one. Whatever invariants are in view can as well be enforced on (sub-parts of) http:-served resource collections as on those identified via myRIs.

23. Protocol Independence

myRI goal

Access to resources identified by myRIs should not be dependent on any particular protocol.

http: response

http: URIs are no more protocol-dependent than any other identification mechanism.

24. Location Independence

myRI goal

myRIs should not be locations.

http: response

http: URIs are not locations.

• Misunderstanding of http: URIs as locations has a long and, in part, justifiable history
  • They were, after all, originally called Uniform Resource Locators.
• But it's not longer justifiable either in principle
  • The RFC for URIs [RFC 3986] is quite clear on the subject.
• Or in practice
  • There's lots of software support for server-side management of the relationship between http: URIs and their representations.
• "That indirection has always been a native part of the web while being so lightly utilized for the persistence of web-based objects is an indication of how unsuited most organizations are to the task of [identifier] maintenance and to the overall challenge of digital permanence." [ARK scheme]

25. Structured names

myRI goal

myRIs should provide for structuring resource identifiers with shareable tags

http: response

The query component of http: URIs supports non-hierarchical structured naming.

26. Uniform access to metadata

myRI goal

myRIs should provide for consistent access to metadata about a resource as well as to representations of that resource.

http: response

Naming conventions or response headers can provide this already

27. Flexible Authority

myRI goal

myRIs require different approaches to identifying namespace authorities, in some cases simpler and in others richer than that provided by hierarchical domain names administered by IANA and resolved via DNS.

http: response

http: URIs can encode arbitrarily complex (or simple) namespace authority expressions.

• Compare e.g. http://lccn.info/2002022641 to info:lccn/2002022641

28. Persistence

myRI goal

The relation between myRIs and the information resource they identify should persist indefinitely.

• What exactly does this mean?
  • No more 404 Not Found
  • The results of retrieval should not change:
    • Names should indicate degree of commitment
    • Representations themselves should not change

http: response

http: URIs support persistence as well as it is in-practice possible to do so.

• 404s are an institutional problem, not a technical one
• Indicating degree of commitment is a matter of naming conventions;
• Guaranteed representation invariance is a technical question (use hashes/signatures), but equally available with http: as with myRIs.

29. Some folk wisdom

• The Web works because you can
  • View Source
  • Follow your nose
  • Write URIs on the side of a bus
  • Use generic tools
  • Redirect, cache and proxy
• The Web is hands-down the most successful distributed name-based system the world has yet seen
  • Postal addresses and the telephone system are not counterexamples
• Ergo anyone designing a persistent identifier system should start from the assumption that http: URIs are sufficient for their technology needs.
  • For an example of how to satisfy all the technical requirements of persistent identifiers using http: URIS see the ARK indentifier approach of John Kunze.

30. Conclusions

• No-one ever expects the network effect
• That is, committing to http: URIs for your (public) names will have unforseen benefits
  • And few if any real costs compared to any other naming scheme.