Providing and discovering definitions of URIs

2.1 Choosing a URI, providing a definition of the URI, using the URI

Alice wants to refer to a particular earthquake. Alice "mints" a new URI (one that is not yet in use) with the purpose of using that URI to refer to the earthquake. Alice publishes a document containing a definition of the URI, i.e. a document that would lead a reader to understand that the URI refers to the earthquake.

Bob then learns of Alice's URI and its definition, and uses the URI in a document of his own.

Subsequently Carol encounters Bob's document. Wanting to know what the URI means, she is led somehow to Alice's published definition, which she reads. She is enlightened.

Any method for implementing this use case would need to explain: what kind of URI Alice should use (syntactic constraints); where and how should Alice should publish the definition so that it can be found; and how Carol might come to discover Alice's definition, given the URI.

2.2 Using a document as a definition by reference to its primary topic

Bob desires to refer to Chicago. He finds a Web page on the Web at 'http://example/about-chicago' (provided by, say, Alice) that consists of a description of Chicago, and wants to use it for the purpose of referring to Chicago. He chooses a URI and associates it with Alice's Web page in such a way that Bob's URI will be understood as referring to Chicago.

Carol encounters Bob's URI, is led to 'http://example/about-chicago' and thence to Alice's description of Chicago, and then somehow understands that Bob's URI is meant to refer to Chicago.

Any method for implementing this use case would need to explain: what are the syntactic constraints on the URI Bob chooses; what Bob needs to do to associate his URI with the document about Chicago; and how Carol comes to discover and use that association.

(This differs from the previous use case in that the document about Chicago was not written with the purpose of defining Bob's URI. In fact Bob's URI doesn't even occur in it. Rather than look in the document for a definition mentioning Bob's URI, Carol must determine the topic of the document and take the topic as the meaning of Bob's URI.)

3.1 Colocate definition and use

One way to lead someone encountering a URI to a definition of the URI is to make sure that the definition of the URI occurs in each document in which the URI occurs. This makes the definition easy to find, since anyone who encounters the URI will have in hand the definition that they need. The form of the URI in this case is arbitrary.

This method treats URIs similarly to blank nodes in RDF, which have to stay close to their own definition, since they are scoped to a graph. An example of the application of this approach would be the use of a URI in an OWL ontology file that defines that URI.

Criticism: In RDF, this method is fragile in the same way as are blank nodes, because use and definition can get separated, e.g. when uses of the URI are deposited into a triple store and then retrieved by a query. Carrying a definition around with a reference does not help in the common case where an out-of-context reference is needed (as one would want in, say, a Semantic Web).

3.2 Point to the document that contains the URI's definition

When using a URI, provide, again in the document in which the URI occurs, a reference to a document that carries a definition of the URI. This is the approach taken by OWL; the document containing the URI is related to the one from which the definition of the URI should be obtained via the owl:imports relation.^[1]

Criticism: Like the previous approach, this one is good so far as it goes, but it suffers in similar ways. The URI and the link to its definition can get separated, or keeping the definition link close to the occurrence of the URI may prove to be too difficult for applications.

3.3 Register a URI scheme or URN namespace

In principle, one could create a new URI scheme or URN namespace, in which case the registration document would constitute a definition (although perhaps not on its own; often there is delegation of some kind to other documents). A recent example is RFC 5870 for URIs defined to name geographic locations. Another is the definition of the URI about:blank, which is in progress as of this writing. A "tdb:" (thing-described-by) URI scheme has also been proposed. [TBD: cite Masinter] See [rfc4395] and [rfc3406] for details.

Criticism: The review process for new URI schemes and URN namespaces is probably too stringent for all but a very few definition discovery applications. There would likely be poor protocol support for discovering definitions in a new URI scheme or URN namespace. It is possible, manually, to look up a scheme or namespace in the appropriate registry, but few client applications are able to do this, and the resulting document is not machine actionable in any standard way. One could attempt to modify all Web clients to understand the new scheme, but this would be difficult.

3.4 Use the LSID getMetadata() method

A URN namespace for which there is a general definition method is the 'lsid' namespace.^[2] URIs beginning 'urn:lsid:' are called LSIDs. [lsid] LSIDs have an associated SOAP-based protocol that has separate methods for dereference (getData) and discovery (getMetadata). According to the LSID specification, an LSID for which the getData method yields nonempty content refers to a representation, while the LSID could refer to anything at all if getData yields empty content. In the latter case the information yielded by the getMetadata method generally constitutes, or at least contains, a definition of the LSID.

For clients lacking an LSID protocol implementation, HTTP/LSID gateways are available.

Criticism: LSIDs rely on an unregistered URN namespace, calling their consensus status into question and making them impossible to understand through the usual chain of IETF URI specifications. The LSID protocol itself is poorly deployed. As currently used, LSIDs have the same vulnerabilities as http: URIs, since they rely on the domain name system for both authority and resolution. What advantage they have over http: URIs (below) for the application is not clear.

3.5 'Hash URI'

With this method, the URI must be a 'hash URI', i.e. must contain a hash character '#'. (For historical reasons the part of the URI following '#' is called the 'fragment identifier', even when it is null.) The definition of the URI is placed in the document on the Web at the URI that is the pre-hash stem of the URI.

Example: 'Hash URI'

The interpretation of a 'hash URI', say 'http://example/eq#eq018', depends (according to [rfc3986]) on the media types of representations of the information resource on the Web at its stem URI 'http://example/eq'. For media type application/rdf+xml, the media type registration defers to the content of the representation — that is, the representation itself gets to arbitrarily define what the 'hash' URI means.^[3]

Criticism: Using 'hash URIs' in this way is a retrofit of an existing architecture intended for locating parts (fragments) of documents to definition discovery. As such the mechanism has some rough edges. Some of the objections to the use of 'hash URIs' are as follows.

  http://example/ns#a  http://example/ns#b  http://example/ns#c ...

  http://example/ns/a#_  http://example/ns/b#_  http://example/ns/c#_ ...

  http://example/ns/a#  http://example/ns/b#  http://example/ns/c# ...

3.6 Absolute URI with HTTP 303 See Other redirect

In the 2002-2005 time period, when 'hash URIs' were advanced as the recommended method for definition discovery, a demand arose for a discovery method applicable to absolute URIs. This led to the invention of the following protocol.

In this approach, one mints an absolute (i.e. hashless) http: URI, puts a definition of it on the Web at a second URI, and then arranges for a GET request of the first URI to redirect, using a 303 'See Other' status code, to the second URI. The first URI is not dereferenceable, and therefore does not name the information resource at that URI (since there is none). The first URI then gets its meaning according to the document on the Web at the second URI. [Draft note: TBD: cite HTTPbis]

Example: 303 redirect

Alice chooses 'http://example/eq018' as the way she will refer to a particular earthquake. At 'http://example/about-eq018' she publishes text and/or RDF that defines 'http://example/eq018', explaining the URI by providing details about the earthquake (date, location). For the URI 'http://example/eq018', which will not be dereferenceable (since otherwise, it would refer to the information resource at that URI [ir], not the earthquake), she arranges that a GET request yields a 303 redirect with a Location: header specifying 'http://example/eq018' as the redirect target.

Those encountering 'http://example/eq018' will attempt to dereference it, but this will fail, with a 303 redirect delivered instead. The 303 redirect indicates that the document at 'http://example/about-eq018' provides a definition of the URI 'http://example/eq018'.

Another pattern is to use a 303 redirect to a document whose primary topic is the intended referent, similar to the Chicago use case (2.2 Using a document as a definition by reference to its primary topic). This could, in theory, lead to ambiguities, as the primary topic of the document and the entity referred to using the URI might be different things.

Criticism: Again, a number of objections to this approach have been raised:

4.1 Use something other than a URI

URIs are just one kind of term that might be used to refer to something. If defining a URI is too difficult or costly, then perhaps one might do without. In RDF serializations such as Turtle, for example, we have blank node notation:

  [ foaf:isPrimaryTopicOf <http://example/about-chicago> ] 

Here we have managed to refer to Chicago without defining a new URI; we have simply referred indirectly using a URI that refers to an information resource according to a generic method (see [ir]).

A more concise alternative is syntactic sugar:

  *<http://example/about-chicago> 

which might be supported in a hypothetical new RDF serialization as a shorthand for the previous example. (The asterisk is meant to be suggestive of indirection in the C programming language.)

Criticism: This is agood as far as it goes, but does not meet the demand for defined URIs.

4.2 Absolute URI with site-specific discovery rules

The network round-trip (303 redirect) to map the URI whose definition is to be discovered to the URI of the information resource that defines it can be avoided if we know a general rule that maps one kind of URI to the other, as such a rule can be applied on the client without server involvement. It is too much to hope that a single rule could work uniformly for all URIs whose definition might be sought, but an individual host may have a rule that applies for URIs at that host.

The "well known URIs" protocol gives a place where such a file containing such rules can be stored [rfc5988]. The rule might be stored in a well-known file 'definition-rule', as in 'http://example/.well-known/definition-rule'. To obtain a definition of 'http://example/eq018', obtain the definition-rule file for its host. Then if the rule says to map 'http://example/{path}' to, say, 'http://example/{path}.about', a definition of 'http://example/eq018' can be sought by dereferencing 'http://example/eq018.about'.

When the mapping is cached, this reduces the number of round trips from two (in the 303 case) to one.

This would be a new protocol and the name and format of the definition-rule file would have to be pinned down. One option might be to use the link-template feature of the host-meta file [rfc5988].

Looking for a definition-rule file for every host that has URIs for which definitions need to be discovered would be expensive if only a few of them have such files, but with some cleverness the number of such failed requests can probably be kept small. The details would have to be worked out, but this approach could be a boon to bulk consumers of absolute URI definitions.

Criticism: Web site authors without write access to the appropriate .well-known file would not be able to take advantage of this facility.

4.3 Absolute URI with new HTTP request or response

To reduce the number of round trips, we might use a new HTTP method to request a definition of a URI, or the server could use a new status code to indicate that what it is returning is a definition of the request URI.

The URIQA specification [uriqa] defines MGET, a new HTTP request method. An MGET request on a URI yields a response containing a definition of that URI.

In response to GET of a URI, a server might provide a definition in a non-success response. (A successful response would mean that the URI refers to the information resource at the URI.) Possibilities for HTTP response status codes that might signal this situation: 203 Non-Authoritative Information, a new 2xx status (e.g. 209), a new 3xx status (e.g. 308), or a variety of 4xx codes. (Placing the definition in the content of a redirect response (status code 301, 302, 303, and 307) is unsatisfactory as the content would not be displayed in a Web browser.)

[The Link: header or other HTTP response header might play a role here? TBD: explain and cite Web Linking and HTTPbis.]

Any of these options would mean fewer round trips than following a 303 redirect.

Criticism: Although they reduce the expected number of round trips, all such methods are generally as difficult, or more difficult, to deploy than 303 redirects.

4.4 Coerce an information resource to what it defines its URI to name

[Draft note: We are trying to represent Ed Summers's proposal, which others have echoed, in this section.]

Currently we use a dereferenceable absolute URI, e.g. 'http://example/eq018', to refer to the information resource at that URI, IR('http://example/eq018') (see [ir]). To use an absolute URI to refer to anything else, one uses an HTTP 303 redirect. To address performance and deployment difficulties with 303 redirects, it has been suggested that the same URI be used for two purposes: to refer to the information resource at that URI, and to refer to some entity given by a definition that is carried by the information resource itself.

  <http://example/eq018> eq:magnitude 6.9.
  <http://example/eq018> eq:epicenter <geo:37.040,-121.877>. 

  <http://example/eq018> dc:creator "Alice".
  <http://example/eq018> dc:title 
    "Loma Prieta earthquake URI definition".

In general, what agents using this protocol need - both those composing statements and those deciphering them - is an agreed rule for classifying each occurrence of a URI u as referring either to the information resource IR(u) or to what the content at IR(u) describes.

There are probably many ways in which one might accomplish this; the following method is provided for illustration. Suppose that it "makes sense" or "is appropriate" for the subject of a particular property to be an information resource. For example, the subject of Dublin Core properties might be seen as "making sense" when the subject is an information resource. The judgment of "making sense" might be made according to an asserted or inferred domain constraint, or it might simply be by fiat (asserted). Call such a property a subject-IRS property. A property that is not subject-IRS would be subject-NIRS. Similarly, we would have object-IRS and object-NIRS properties.

We now consider an implicit coercion to be applied any time an information resource occurs in an NIRS position of a subject- or object-NIRS property, replacing the information resource with something (the same thing each time, for a given URI) that it describes. That is, the information resource acts as a proxy for what it is about.

In the example, dc:creator and dc:title would be classified as subject-IRS object-NIRS, while eq:epicenter and eq:magnitude would be classified as subject-NIRS object-NIRS.

To avoid mistakes, the IRS/NIRS classifications of all properties would have to be understood in the same way by both Bob and Carol, i.e. the classifications would have to be part of the shared meaning of all properties.

Criticism: This approach presents a couple of challenges.

First, not all subject or object positions of properties are easily classified as IRS vs. NIRS. For example, the object of "likes" and the subject of "is located at" are not obviously either IRS or NIRS. Even if the choice is agreed, no matter what the choice is, meanings that required the other choice would be difficult to express - you would have to revert to a mode of expression that did not involve a 200 response (hash, 303, blank node, etc.).

Second, this method, by design, creates the illusion that the URI refers to what the information resource is about (e.g. an earthquake). Because predicates that already possess meaning are being reinterpreted, there is risk that an agent will draw unsound conclusions. For example, if two URIs u, v refer to distinct descriptions of the same thing, and one then writes <u> owl:sameAs <v>, then one incorrectly imputes that the two descriptions are identical. A similar situation holds for situations involving functional properties.

4.5 Change what dereferenceable absolute URIs mean

Under this proposal, some dereferenceable URIs - call them "indirect" URIs - would get their meaning according to a definition found in the information resource (document, usually) at the URI, rather than referring to that information resource [ir]. This approach avoids the deployment and performance difficulties of 303 redirects. Defining an indirect URI is easy — it is the same as publishing any Web document — and access to its definition is also easy, not requiring an indirection step.

How does one learn whether a URI is indirect or not? One might like to say that an indirect URI is one that dereferences to a definition of itself, and that all others are direct. But this criterion is not machine actionable as stated, both because the definition might be couched in an arbitrary language or notation (the number of RDF serializations is increasing steadily), and because even for a known notation it may not be obvious how to distinguish content that contains a definition of a particular URI from content that doesn't. One actionable approximation that has been proposed is as follows: If IR(u) has an associated representation with media type 'application/rdf+xml', then take u to be defined by IR(u), otherwise take u to refer to IR(u). This rule would generate false positives (e.g. documents not containing u) and false negatives (e.g. those defining the URI only in an associated text/owl-manchester representation), but it illustrates the idea.

In order to compose or use metadata, an agent would first check whether a URI is direct by requesting an application/rdf+xml representation. If the URI is direct, the agent could compose or use metadata in the usual way (at some risk that the URI might change status in the future from direct to indirect). If the URI is indirect, the agent would write or interpret the metadata in some other way.

This proposal would need to compensate for the loss of a way to refer to information resources on the Web at indirect URIs. A standard way to refer to IR(u) is needed in a variety of circumstances:

1. when u is an indirect URI
2. when it is not known whether u is direct or indirect
3. when the cost of determining whether u is direct or indirect is judged to be too high
4. when it is desired not to impose on others the cost of determining whether u is direct

Although direct URIs might still be used to refer to their information resources, the risks and costs of doing so would probably lead people to stop using them.

In any case, there are many design alternatives for referring to an information resource without depending on its URI being direct. For example, the Turtle term

  [ ir:onWebAt "http://example/eq018"^^xsd:anyURI ] 

could be a new way to refer to IR('http://example/eq018'), which we formerly referred to in Turtle as '<http://example/eq018>'. [TBD: Reference Halpin and Presutti's closed access ESWC 2009 paper.] A local shorthand could be defined to the same effect:

  :about-eq018 ir:onWebAt "http://example/eq018"^^xsd:anyURI . 

(Note that either a 'hash' URI or a 303 URI could be used to refer to an information resource — defined perhaps in this way.)

Yet another possible replacement notation would be syntactic sugar:

  &<http://example/eq018> 

which might be supported in a hypothetical new RDF serialization. (The ampersand is meant to be suggestive of the address-of operator in the C programming language.)

Alternatively, the referring document could just assert that a URI is direct:

  <http://example/eq018> ir:onWebAt "http://example/eq018"^^xsd:anyURI . 

This would be an instance of 3.1 Colocate definition and use. However, this runs some interoperability risk as there may be other agents that interpret the same URI as indirect. ^[4]

To avoid the need for the clumsy ir:onWebAt notation, some convention might be used to provide a URI (other than u) to refer to IR(u), when one is available. One way to do this would be with a Link: HTTP response header [rfc5988].

Criticism: Currently it is easy to write and interpret Web metadata (meaning metadata written using a dereferenceable absolute URI to refer to the information resource at that URI). This proposal makes metadata more complicated, fragile, and costly, and forces all existing producers and consumers of Web metadata to be updated to be aware of indirect URIs.

It is likely that there is deployed content that would be interpreted differently under the proposed rule than at present. This would be hard to know, and inconsistencies could be consequential, such as the assignment of authorship or a copyright license to the wrong information resource. More complex and costly heuristics would reduce misinterpretation but would not eliminate it.

As most of the Web (e.g. HTTP clients and servers) will continue to adhere to the current interpretation of dereferenceable absolute URIs, the proposed rule introduces a split in the URI namespace, with two communities interpreting the same URIs in incompatible ways. This goes contrary to both the Web architecture and to the Web Consortium's "One Web" vision.