The ideal definition discovery method would have the following properties:

1. Simple. Having too many options or too many things to remember makes discovery fragile and impedes uptake.
2. Easy to deploy on Web hosting services. Uptake of linked data depends on the technology being accessible to as many Web publishers as possible, so should not require control over Web server behavior that is not provided by typical hosting services.
3. Easy to deploy using existing Web client stacks. Discovery should employ a widely deployed network protocol in order to avoid the need to deploy new protocol stacks.
4. Efficient. Accessing a definition should require at most one network round trip, and definitions should be cacheable.
5. Browser-friendly. It should be possible to configure a URI that has a discoverable definition so that 'browsing' to it yields information useful to a human.
6. Compatible with Web architecture. A URI should have a single agreed meaning globally, whether it's used as a protocol element, hyperlink, or name.

It is not certain that all of these goals can be met simultaneously.

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.

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.)

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).

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.More precisely, the definition will be found in the imports closure of the document containing the URI.

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.

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] as has "xri:" for "extensible resource identifiers" (n.b. xri: has been deprecated in favor of http: and Web Linking). See and 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.

A URN namespace for which there is a general definition method is the 'lsid' namespace. URIs beginning 'urn:lsid:' are called LSIDs. 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.

The LSID protocol improves on 303 redirects (see below) in that only one round trip is required to obtain a definition.

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 rely on DNS for both authority and resolution, and therefore have the same vulnerabilities as http: URIs. LSIDs do not meet the "browser friendly" criterion.

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.

The interpretation of a 'hash URI', say 'http://example/eq#eq018', depends (according to ) 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. If IR('http://example/eq') (the information resource at URI 'http://example/eq') has multiple representations, it is important that all representations provide definitions of every URI that needs one, and that corresponding definitions in different representations be compatible with one another. (See section 3.2.)

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.

Initially (around 2000) 'hash URIs' were advanced as the recommended method for definition provision and discovery. In the 2002-2005 time period demand arose for a discovery method applicable to absolute URIs. This led to the invention of a new protocol for use in situations where 'hash URIs' are considered unacceptable.

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 by interpreting the document on the Web at the second URI, which presumably contains a definition of the first URI. The document may carry definitions of other URIs as well, so the referent of the URI is not necessarily the document's primary topic - it may be only one of many things "described by" the document. [Draft note: TBD: cite HTTPbis]

Another pattern is to use a 303 redirect to a document whose primary topic is the intended referent, similar to the Chicago use case (). 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:

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:

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 ).

A concise alternative would be syntactic sugar:

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: These are good as far as they go, but they do not meet the demand for defined URIs. In particular, it can be difficult to detect that blank nodes in separate graphs are meant to refer to the same thing. Data integration is easier when shared URIs are used.

In the case of syntactic sugar, there would be adoption overhead in publishing new RDF serialization specifications and getting them implemented.

[Or, "parallel properties."] The idea here is that you don't need to define a URI if you are willing to use properties that are defined or understood as indirecting through information resources. Instead, just use a URI that refers to the information resource at that URI, and use it as the subject of such properties.

Assume that each information resource can have an associated entity, which we'll call its "designated subject".Why 'designated subject' instead of 'primary topic'? Because they might be different things. Consider identical content, served from two URIs u1 and u2, containing information about the designated subjects of both u1 and u2. Even though the content is identical, the URIs would have to refer to distinct information resources with different designated subjects. But the content can have only one primary topic. Information about the designated subject is expressed using properties whose subject is the information resource.

Instead of defining eq:epicenter to be a property relating an earthquake to its epicenter, one defines eq:epicenter to be a property that relates an information resource to the epicenter of its designated subject. Then, as long as you have a URI for the IR, you don't need a URI for the earthquake. If property eq:epicenter has domain eq:Earthquake, then the members of eq:Earthquake are IRs whose designated subjects are earthquakes.

The nature of the designated subject is inferred from information found in the IR. For example, if the IR says that its eq:epicenter is E, then you can infer that the designated subject has epicenter E.

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

If one's domain of discourse mixes information resources (used as above) and entities that might be their designated subjects, then maintaining parallel properties, one set that applies the 'designated subject' coercion and one that doesn't, might be considered an unacceptable cognitive and clerical burden. (There is quite a lot of variation in opinion on this point.) In this case one might try combining the two properties into a single property that can be used in either way. Suppose that P is the initial property (not defined via designated subject coercion) and Q is the overloaded property we'd like to define and write. Then an obvious definition of Q would be

For example, taking P = dc:creator as defined by the Dublin Core definition, and Q = dc:creator as overloaded, the statement

could be taken to imply that P(<http://example/eq018>, "Alice") as long as it is agreed ahead of time that earthquakes don't have creators.

This manner of overloading can make correct recovery of P-relationships impossible when a designated subject is an information resource, so it's probably better use a "tie breaking" rule such as

There may be better tie-breakers than this one; this is just for illustration.

All considerations that apply to the subject of a property also apply to the object, making the coercion rules that much more complex.

Criticism: This approach presents a couple of challenges.

First, any tie-breaking rule is going to be fragile and will make the "losing" side of the race difficult to express. One can expect many mistakes where the designated subject was the intended subject of some metadata but the tie-breaking rule implicated the other information resource.

Second, this method, by design, creates the illusion that the URI actually refers to the designated subject, not the information resource. If predicates that already possess meaning are being reinterpreted as overloaded properties, there is risk that an agent will draw unsound conclusions. For example, if two URIs u, v refer to distinct information resources with the same designated subject, and one then writes <u> owl:sameAs <v> having their designated subjects in mind, then one can incorrectly impute that the two information resources are identical. A similar situation holds with functional properties, which induce equations.

The network round-trip (303 redirect) used 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 the one kind of URI to the other, as such a rule can be applied on the client without server involvement. It is probably too much to hope for 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 a file containing such rules can be stored . 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 rule 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, but registering a new well-known file name would also be a viable option.

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.

For compatibility with clients that are not aware of discovery rules, 303 redirects for these URIs should be retained when possible.

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

Jeni says: "the disadvantage is that you lose the distinction between status codes for the thing [described] and the document" -- but JAR doesn't understand this. Any information that would have been conveyed by the status code from a GET on the original URI, could be conveyed in the document retrieved by definition discovery.

Jeni says: "in some cases the mapping from thing URI to document URI can be complex or change over time in ways that make it hard to use a definition rule file; in legislation.gov.uk for example, we return a 303 redirection from a legislation item to either an as-enacted version or the most recently revised version, depending on what is available for that particular item of legislation (which changes as new revised versions are added). It would be quite hard to create a definition-rule file in those circumstances (we would have to solve it by having a simple mapping with some URIs 307 redirecting to others)."

To reduce the number of round trips relative to the 303 redirect, we might use a new HTTP status code to indicate that what is being returned is a definition of the request URI, rather than a representation associated with the information resource at that URI. Alternatively, we could define an HTTP method to request a definition of a URI.

New status code: In response to GET of a URI, a server might provide a definition of the URI directly in a non-success response, as opposed to indirectly via a 303 redirect. (The definition can't go in a successful GET response since that 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 (maybe 209); a new 3xx status (maybe 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 same situation might apply to any 3xx or 4xx response, making a 2xx status code the most attractive.

New method: The URIQA specification defines MGET, a new HTTP request method. An MGET request on a URI yields a response containing information about the referent of the URI. If the URI is dereferenceable, then the URI refers to the information resource at that URI, so the MGET result is metadata for that information resource. Otherwise, the MGET result might be a definition of the URI. A GET in that case would yield a 303 See Other linking to the same definition obtained by MGET, or maybe to a 405 Method Not Allowed response.

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

The Link: HTTP header is useful for indicating a metadata source for an information resource (see POWDER spec, citation needed). In case a URI is not dereferenceable, Link: could be used for directing a client to a definition of a URI. However, the advantage of Link: over a 303 redirect is unclear, since a second network round trip would be required in either case.

Criticism: Although they reduce the expected number of round trips, all HTTP extensions are generally as difficult, or more difficult, to deploy than 303 redirects. And it's not clear which status codes play nicely with the "browser friendly" goal. We would have to check to make sure that proxies, caches, and Web clients do something reasonable with the proposed status code.

Under this approach, some or all dereferenceable absolute URIs - call them "indirect" URIs - would get their meaning according to a definition found in the information resource (document, usually) at the URI; they would no longer refer to their information resource . 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.