This document is also available in these non-normative formats: XML.
Copyright © 2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The specification governing Uniform Resource Identifiers (URIs) [rfc-3986] allows URIs to refer to anything at all, and this feature is exploited in a variety of applications, including the Semantic Web and Linked Data. A few methods are in use to help an agent provide an explanation of what they want a URI to refer to, including RDF fragment identifier resolution and the 303 HTTP redirect. However, difficulties in using these methods has led to a search for new methods that are easier to deploy and perform better than the established ones. This report brings together in one place information on current and proposed practices, with analysis of benefits and shortcomings of each.
The purpose of this report is not to make recommendations but to provide a foundation for a discussion that might lead to consensus on the use of current and/or new methods.
This document is an editors' copy that has no official standing.
This document has been developed by the AWWSW Task Force of the W3C Technical Architecture Group in order to provide background material for further discussion among those affected by this architectural question, and to help drive TAG issue 57 [issue-57] to a conclusion.
This version has not received review within either the task force or the TAG.
Publication of this draft finding does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time.
Please send comments on this document to the publicly archived TAG mailing list www-tag@w3.org ( archive ).
1 Introduction
1.1 Information resources
1.2 Glossary
2 Use case scenarios
2.1 Preparing and consuming metadata
for a Web-accessible information resource
2.2 Choosing a phrase, providing an account of the phrase, using
the phrase
2.3 Referring to the primary topic of a document
3 Methods in current use
3.1 URI scheme and URN namespace registrations
3.2 The LSID URN namespace
3.3 A dereferenceable URI refers to the information resource
at that URI
3.4 Non-URI phrase
3.5 Cite your sources
3.6 'Hash URI'
3.7 'Slash URI' with HTTP 303 See Other redirect
4 Critique of the current solution suite
4.1 Fragment identifiers get lost
4.2 The common fragment identifier pattern fails with large namespaces
4.3 Fragment identifiers aren't seen by servers
4.4 303 is difficult, sometimes impossible, to deploy
4.5 303 leads to too many round trips
4.6 303 makes the URI difficult to bookmark
5 Possible new methods
5.1 Syntactic sugar
5.2 'Hash URI' with fixed suffix
5.3 'Slash URI' with site-specific discovery rules
5.4 'Slash URI' with new HTTP request or response
5.5 Dereferenceable URI refers to chimera entity
5.6 Dereferenceable URI refers to WS(u) or IR(u), depending
6 Summary
7 Notes
8 References
This is an old issue, and people are tired of it. — Sandro Hawke, January 2003 [disambiguating]
Languages such as OWL and RDF that pervasively use URI-based vocabularies require that one be able to refer, in those languages, to things one has to refer to, in such a way that the reference will be understood by someone encountering the reference. These references either are URIs or are built on URIs, so the problem of referring reduces to that of either knowing, or influencing, the way that readers will interpret URIs referentially.
Consider the following scenario. Suppose that Alice, in communication with Bob, refers to Mount Everest using the phrase "Q-261", as in "Alice would like to climb Q-261 next summer". If Bob does not know what "Q-261" refers to, he will have to find out. He might be able to ask Alice directly, although in many cases this will be impossible - Alice might be too busy, or otherwise unavailable. Lacking that option he must do some sleuthing, and consult dictionaries, encyclopedias, or search engines in the hope of obtaining the correct explanation of Alice's use of the phrase.
The essential idea is that there are one or more methods available to Bob by which he can discover what Alice means by the phrase. Discovery succeeds by way of bits of writing that explain what the phrase in question refers to. (These bits are called "accounts" of the phrase, below.)
When the phrase is a URI such as http://example/everest, the methods include, in addition to those already mentioned, network protocols that involve the URI directly. Methods that use the Web protocol for the URI in order to determine what the URI refers to are called "follow your nose" (FYN) methods. This kind of discovery is not the same as Web dereference, and some care must be taken to avoid getting confused between the two operations.
The nature of accounts need not concern us here - many forms are familiar, including translation between languages (e.g. providing an English or Spanish phrase equivalent to a URI), descriptions (the URI refers to the entity possessing some set of properties), axiomatic systems, and so on. Also not of concern here are the many ways in which reference can fail as a result of what information is transmitted about the phrase in question, and how it is used. Our concern is only with the method by which enabling information is conveyed.
This report presents follow-your-nose methods in current use, reports some criticisms of them, and suggests some new FYN methods that might be used to address these criticisms.
[Advice welcome on what else needs to go in an intro.]
[Terminology option: Maybe "metadata subject" instead of "information resource"??]
"Information resources" figure prominently in this story both as providers of accounts of reference, and as things that you refer to (metadata subjects). The following explains the particular theory of "information resources" assumed in this document. More elaborate theories are certainly possible, but this is all we need to assume here.
Each information resource has one or more associated versions, each having fixed content (octet sequence) and interpretation directives (media type, language). An information resource having more than one version is said to be generic. No particular meaning is implied by the word "version;" the word is chosen as suggestive of its most common use. (We might have said "representation" here but discussions of this subject have been waylaid by this word in the past and it seems better to avoid it.)
One can apply metadata properties such as author, title, and topic to versions in the obvious way. These properties extend to generic information resources in a systematic way, as follows: if a property is shared by all of an information resource's versions, then we say that the information resource possesses the property, and vice versa.
Operationally, this means that if you have knowledge of its versions, you can write metadata using an information resource as subject, and someone reading this metadata can then apply that metadata to whatever version they access.
Information resources need not be accessible at a URI; they might exist only inside a local file system or database, or they may be ephemeral.
[All terminology choices are provisional; for most of them I am testing the waters to see how well the word works, and am prepared to change.]
Bob is preparing a bibliography. He finds a report on spoonwings provided by Alice at the URI http://example/spoonwing and wishes to refer to the report for the purpose of composing metadata such as its title, author, and publication date. He selects a phrase to use to refer to the report, then composes the metadata, using the chosen phrase as the subject of each statement.
Subsequently Carol encounters an entry from Bob's bibliography. Wanting to know what the subject phrase refers to, she is led somehow to dereference http://example/spoonwing, and is led to understand that IR('http://example/spoonwing') is the document that Bob is talking about.
Variant use case: Same as above, but Bob's bibliography includes a number of RDF documents, and his metadata includes information relevant for making use of those RDF documents.
Variant use case: Same as above, but instead of being a person, Bob is a tool that is charged with updating all the documents on a Web site with license metadata.
Alice wants to refer to Fred, a mynah living at a local zoo. Alice "mints" a new phrase (one that is not yet in use; either a new URI or a phrase built on one) with the purpose of using that phrase to refer to Fred. Alice publishes a document that would lead a reader to understand that the phrase refers to Fred.
Bob then learns of Alice's phrase and uses it in a document of his own.
Subsequently Carol encounters Bob's document. Wanting to know what the phrase means, she is led to Alice's published account, which she reads. She is enlightened.
Variant use case: Same as above, but instead of Fred, the referent of the phrase is to be an information resource that is not accessible on the Web, or at least not at any URI known to Alice. The account might describe where the information resource might be found, and other aspects such as bibliographic metadata (author, title, etc.) or SHA1 hash.
Variant use case: Same as above, but instead of Fred, the referent is to be an information resource that is Web accessible, via a URI known to Alice. The account that Alice writes explains that the phrase is to refer to that information resource. That is, there are two information resource at play here, one carrying the account and one that's a subject of the account. It's important in this case to make sure that metadata can be written about either information resource. (In this situation, which is common in the publishing industry and digital archives, Alice's account is often called a "landing page".)
Bob desires to refer to Chicago. He finds a Web page on the Web at http://example/chicago (provided by, say, Alice) that consists of a description of Chicago. Somehow he comes up with a phrase that will be understood as referring to the primary topic of Alice's Web page.
Carol encounters the phrase Bob used, is led to Alice's description of Chicago, and then somehow discovers that the phrase is meant to refer to Chicago.
This differs from the previous use case in that the description of Chicago has no mention of the phrase, which is unknown to the author of the description. So it does not, in itself, constitute an account of the meaning of the phrase. In fact it might include accounts of other phrases, none of which refers to Chicago.
[This use case keeps coming up (e.g. tdb:) but I don't think anyone is seriously interested in it. Need text to admit that it's important but not important enough to talk about.]
This section describes how people currently implement the "somehows" in the use cases.
Each URI scheme, e.g. mailto:, http:, ftp:, and so on, has its own URI scheme registration, accessible via a registry maintained by IANA [rfc-4395]. A URI scheme registration helps to account for the meaning of URIs using that scheme. For example, the registration for the data: URI scheme fully explains the meaning of URIs that use that scheme.
Most URI scheme registrations, such as that for http:, only provide a partial account, and other sources of information must be consulted in order to understand a particular URI using that scheme.
Registering a new URI scheme requires community and IETF Expert Review; see RFC 4395 [rfc-4395].
[Not exactly common - is this worthy of mention? But it is used. Maybe rule out all non-linked-data solutions up front?]
The urn: URI scheme is subdivided into 'namespaces', one of which is the 'lsid' namespace. The urn:lsid: namespace has an associated protocol that has separate methods for dereference and discovery. Someone wanting to determine what a urn:lsid: URI refers to would use the discovery method, which generally yields an RDF document.
To refer to the information resource accessible via a given URI, just use the URI itself: http://example/ir refers to IR('http://example/ir'). Those who encounter the reference can dereference the URI, and on seeing that the dereference is successful, take the URI to be a reference to the particular information resource that is accessible via that URI.
URIs are just one kind of phrase that might be used to refer to something. In RDF serializations, for example, we have blank node notation:
[ foaf:isPrimaryTopicOf <http://example/chicago> ]
Because RDF has compositional semantics, the problem of figuring out (or documenting) the meaning of the overall phrase reduces to that of figuring out (or documenting) the meaning of the URIs that occur in it.
Whenever using a URI to refer to something, provide a link to the document that carries an account of the URI's meaning. This is the approach taken by OWL (owl:imports). The rdfs:definedBy property could also be used for this purpose.
Both of these properties beg the question in that they do not say how to figure out what the URI that is the target of owl:imports or rdfs:definedBy refers to. If the meaning of that URI had to be given by citing a source, there would be infinite regress.
To refer to something, mint a URI with a fragment identifier, and provide an account of that URI's meaning at the pre-fragment stem of the URI. That is, if the URI is http://example/vocabulary#term, then put an account of that URI in the document at http://example/vocabulary .
Those encountering http://example/vocabulary#term will access http://example/vocabulary and read the account, as informed by the registration for the media type returned. (See AWWW section 3.2. [webarch])
This approach and the following one are completely generic methods and may be used, in principle, even when the referent is to be an information resource. If the information resource is accessible via its own URI (and it might not be), there will be URIs by which it is known, one dereferenceable and one not.
To refer to something, mint an http: or https: URI without a fragment identifier (say http://example/fred), make an account of it accessible via a second URI (say http://example/about-fred) , and arrange for a GET of http://example/fred to yield a 303 response carrying a Location: header with http://example/about-fred as its target.
Those encountering http://example/fred will attempt dereference, but this will fail, with a 303 redirect delivered instead. The 303 redirect indicates that the URI does not refer IR('http://example/fred'), but rather that the document at http://example/about-fred provides an account for the meaning of http://example/fred. [see HTTPbis]
Another pattern is to use 303 redirect to a document whose primary topic is the intended referent, similar to the Chicago example above. [Is anyone, in practice, deploying 303 redirects to a "primary topic" page not mentioning the URI to be accounted for, rather than to a document that explicitly mentions the URI?]
URI scheme registration is generally considered to have two problems. First, it has a high social overhead, and generally makes sense only for the creation of new standards, not for use in individual projects. Second, any new URI scheme will not be understood by simple Web clients, and thus will not (in the short run at least) support the "follow-your-nose" discovery idea where a wide variety of existing clients can obtain useful information about the URI's meaning with no additional programming.
The "cite your sources" approach, while important in OWL, is considered to have an unacceptably high overhead in RDF in general.
Non-URI phrases have similarly high overhead and low discoverability.
"People forget to put it there when writing and cut and pasting URIs." (Harry) [More information needed.]
When a large number of URIs are formed by combining a fixed "namespace" prefix with a single suffix using hash as a connector, there will be a single underlying document that must provide accounts of all of the large number of URIs. This is an unacceptable performance hit for the server, the network, and the client. "Slash" URIs don't have this problem as the response can be specific to each URI.
(1) The document provided by the server must account for all of the hash URIs that are based on the document's URI. This could be an impracticably large number. (2) Hash URIs don't work with HTTP PUT, POST, or DELETE methods. (Manu)
Deploying a 303 redirect requires giving the correct directive to a web server, for example adding a Redirect line to .htaccess in Apache. Unfortunately many hosting solutions do not allow this.
The Chicago use case is an extreme version of this - the entity providing access to the Chicago document (Alice) does not even care about providing URIs that refer to Chicago; it is someone having no control over how the URI dereferences (Bob) who needs a reference to Chicago.
With fragment identifiers and the 303 redirect identified as the sources of current difficulties, a number of alternative methods have been suggested to get around these problems.
Use a new kind of non-URI phrase, for example
*<http://example/about-fred>
the asterisk being suggestive of indirection in languages derived from C.
[This idea derives from JAR's TAG slides. Talking about this is mainly to remind people that the problem is one of notational engineering, not philosophy.]
This idea attempts to address one reason for using "slash URIs" instead of fragment identifiers. Suppose you want to combine a large number of local name a, b, c, ... into a namespace. The usual solutions would be to write http://example/namespace#a (a "hash namespace") or http://example/namespace/a (a "slash namespace").
In the "singleton fragid" approach one would write http://example/namespace/a# (a null fragment identifier) or http://example/namespace/a#_, using a fixed suffix for every URI and varying the part between the namespace prefix and the suffix.
As in the 303 approach, each URI in the namespace would (or could) have its own document, providing an account for that single URI rather than every URI in the namespace.
The choice of fixed fragment identifier (null, "_", or something else) is largely a matter of taste.
A null fragid precludes the use of qnames to abbreviate such URIs. (In particular it would not be possible to use them as predicate names in RDF/XML.) However, SPARQL, Turtle, and RDFa are being extended to admit CURIEs that include #, making this a newly attractive option.
To address the "hash gets lost" problem we could explore heuristics to automatically replace http://example/fred with http://example/fred# (or http://example/fred#_) when needed.
For http://example/fred, obtain the host-meta file for its host via http://example/.well-known/host-meta. (See [hostmeta] and [rfc-5988].) Then look in the host-meta file for a link-template rule that maps http://example/fred to another URI, say http://example/fred.about, and then look for an account by dereferencing http://example/fred.about.
When the host-meta file is cached, and many accounts are sought from the same host, this reduces the number of round trips from two (in the 303 case) to one.
Such rules could augment or replace the use of 303 (or even 404) responses in order to reduce the number of round trips required to obtain accounts of URIs.
Looking for a host-meta file for every host that has URIs for which accounts need to be discovered would be expensive if only a few of them have such files, so some cleverness would be required to reduce the expected number of round trips. The details would have to be worked out, but this could be a boon to bulk consumers of "slash" URIs.
To reduce the number of round trips, we might use a new HTTP method to request an account of a URI's meaning, or the server could use a new status code to indicate that what it is returning is an account of a URI's meaning.
The URIQA specification proposes such an HTTP request method. Unfortunately URIQA sacrifices the works-in-browser property enjoyed by 303.
Possibilities for HTTP response status codes: 203, new 2xx (e.g. 209), new 3xx (e.g. 308), 404. 301, 302, 303, and 307 redirects are problematic as the entity in the response is not displayed in a browser.
Any of these options would mean fewer round trips than a 303 redirect. Unfortunately they are generally as difficult, or more difficult, than 303 redirects to deploy.
[Ed Summers's favorite]
In this approach we take a dereferenceable URI to refer to IR(that URI), as usual, but we obtain additional information about that referent from the retrieved content. If the content appears to say that the URI refers to something not very IR-like, we interpret the referent as a "chimera" entity having some properties of an IR and some properties of whatever the IR says that the URI refers to. In effect:
IR('http://example/fred') = WS('http://example/fred')
Ways that this can fail:
To make the "chimera" approach work, strategies are needed for avoiding each of these pitfalls. E.g. (1) could be addressed by a prohibition on the use of predicates that might apply to either IRs or non-IRs, or by a priority system explaining which subject is meant, (2) by saying that the account of the URI must not lead to the URI as being understood to refer to any IR other than IR('http://example/fred'), (3) by having the community agree that axioms that enable equational inferences shouldn't be written for these entities.
Currently we use a dereferenceable URI http://example/fred to refer to the information resource at that URI, IR('http://example/fred'). To use a 'slash URI' to refer to anything else, one must use the 303 redirect (or a non-http: URI scheme). It has been suggested that, because the 303 redirect is sometimes hard to deploy, a different convention be adopted where a dereferenceable URI u refers to WS(u). Then we would be able to arrange for a 'slash URI' to refer to anything we like simply by deploying an account that says so at that URI.
This would of course be an incompatible change as tools assuming that u refers to IR(u) will misunderstanding u. However, most URIs do not dereference to accounts of their own use, so it might make sense for most or all of those URIs to refer to their information resources instead, maintaining compatibility for those URIs.
How to distinguish the two situations? The criterion "provides an account of the use of URI u" is not machine actionable as stated, but perhaps some approximation to it could be made so, based on some combination of media type and aspects of the content. One simple rule might be: If there is a version with media type application/rdf+xml, then take u to refer to WS(u), otherwise take u to refer to IR(u). This ignores the fact that there are many other serializations of RDF, and also that not all RDF/XML documents provide accounts of the URI from which they're retrieved, but it illustrates the idea.
For those URIs u whose referents would be changed incompatibly from IR(u) to WS(u), another way would have to be provided to refer to WS(u), so that metadata applicable to IR(u) can be expressed. This could be done in RDF by giving a way to write, in RDF, the predicate corresponding to what we've been calling 'is accessible via'. For example, the Turtle phrase
[ :accessibleVia "http://example/fred"^^xsd:anyURI ]
could be ne way to refer to IR('http://example/fred'). (Let's call this "clumsy notation".) A local name could be defined to the same effect:
:fred-doc :accessibleVia "http://example/fred"^^xsd:anyURI .
Or the referring document could just assert that it's using the URI to refer to the IR in question:
<http://example/fred> :accessibleVia "http://example/fred"^^xsd:anyURI .
which would constitute an explicit opt-in to the httpRange-14 rule.
To avoid the need for clumsy notation, some convention could be used to provide a URI for IR(u), when one is available. This could be done using a Link: header, or via an RDF statement such as
<http://example/fred#ir> :accessibleVia "http://example/fred"^^xsd:anyURI .
Table summarizing the options. Could be as many as 14 rows (one for each current approach + one for each suggested approach) and as many as seven columns (one for each critique).
| compatible | easy to deploy | round trips | >1 account | |
| hash+fixed | + | + | 1 | + |
| slash+hostmeta | + (ext) | ? | 1+ε | + |
| slash+newHTTP | + (ext) | - | 1 | + |
| chimera | + | + | 1 | - |
| it depends | - | + | 1 | + |
[For reference, here's a similar analysis - not the same problem, but a related one - with a matrix.]