HashlessUriContention

Deprecated page. Instead please see HttpRange14Requirements and HttpRange14Options.

Deprecated page

First read http://www.w3.org/2001/tag/2011/09/referential-use.html

Hashless, retrieval-enabled URIs (HRUs?) are a valuable syntactic property, and there is contention over this property. The two most vocal contenders are the following needs:

• D1. Given any HRU, refer to the document at that HRU
• S1. Given any description, choose a URI to name the entity described by the description, such that nose-following goes from URI to description

There are other contenders, but let's stick with these.

Call a URI (not necessarily an HRU) enabled for D1 "direct"; for S1 is "indirect".

Requirements for a solution

TBD: Define terms e.g. 'FYN' 'retrieval enabled' 'easy to deploy'

TBD: Enumerate components of a solution

Any proposed solution must meet both needs. Proposed requirements for any solution:

1. Must provide a procedure that maps an HRU to a way to refer to the document at that HRU (Tim would say: a URI)
2. Must provide easy to deploy indirect hashless URIs
3. Must provide automatable FYN method
4. Must provide efficient FYN procedure (fewer than 2 expected round trips)
5. Must allow descriptions in any format (e.g. RDFa, Manchester)
6. Must "work in browser"

Let's give this requirement set a try on a few possible solutions to see how it works.

TAG's status quo

httpRange-14 resolution.

1. SORT OF. You can use an HRU to refer to the document there, but httpRange-14 doesn't say the HRU will refer to that document. Also FAIL: The AWWW "information resource" definition is impenetrable and doesn't imply anything like "document".
2. FAIL. 303 not easy to deploy
3. SORT OF. Just look at status code. Again 200 doesn't tell you which "information resource"
4. FAIL. 303 needs 2 round trips in general
5. OK. 303 not sensitive to media type of description
6. OK

JAR's modified version of httpRange-14

This modifies httpRange-14 clause a by saying that an HRU refers to the generic resource at that URI, not to just any old "information resource".

1. OK. You refer to the document at U as U (or <U>).
2. FAIL. 303 hard
3. OK. Do a GET or HEAD. If you get a 2xx, assume the URI refers to the document at that URI. 303 goes to description.
4. FAIL. 2 round trips
5. OK. 303 not sensitive to media type of description
6. OK

Ian Davis's plan

This says that D1 is the default, but if there is an RDF/XML representation, then S1 kicks in.

1. NOT CLEAR. You have to first do a GET requesting application/rdf+xml. If there is no such a representation, then you're done. Otherwise the suggestion is that the Content-location: (if there is one) gives a second URI naming the document at the first URI. Problem: If first URI has conneg, will second URI refer to something with conneg? I.e. does the second URI really name the document at the first URI, or does it only name the RDF/XML representation? - n.b. could use JAR's blank-node idea here [ir:onWebAt "uri"]
2. OK. Deploy the description as RDF/XML using 200.
3. OK. Do a GET or HEAD requesting RDF/XML; if you get RDF/XML then indirect, otherwise direct.
4. OK, only one round trip
5. FAIL. Assumes description is expressed in RDF/XML. This may be fixable.
6. OK

Note: If there is an RDF/XML representation, but it does not contain a "description" connected to the URI, then the URI will be be nonreferring.

Larry Masinter's suggestion

Here we use non-http: URIs, avoiding HRUs entirely.

1. OK. Use a new URI scheme such as duri:, or blank node notation.
2. OK. Something like tdb: will be easy to deploy
3. FYN starts by looking at URI scheme
4. OK. Something like tdb: will be as efficient as fragids.
5. OK
6. FAIL - no "works in browser"

duri: is not quite specified properly for this purpose since it says that the duri:2011:x "identifies" what x meant to in 2011, and the whole point is that we don't know, or can't agree on, what x "identified" in 2011.

Agnostic

D1 and S1 reflect particular relationships between the representations available at U and what U refer to. Any particular choice is going to be fragile due both to deployed server behavior and to the strong likelihood that future servers will be unaware of, or defiant against, any particular advice, not matter how rational and consensus-based. So what would it look like if we said that any relationship had to be opted into?

The particular method(s) of opting in to a relation would have to be designed. We have Link: header, <link> element, RDF in its various forms, and perhaps other techniques at our disposal.

Opt-in would best be done by the publisher (the agent controlling HTTP responses for the URI), but it could be bilateral between sender and receiver of a message, or multilateral within a community, without publisher involvement. The latter has a higher risk of interoperability failure because different sender/receiver pairs can opt-in to different relationships.

1. OK. If publisher opts in to D1, use the URI. Otherwise, blank node [ir:onWebAt "uri"] or new URI scheme.
2. OK, easy to deploy, just opt-in to S1.
3. OK. Do a GET or HEAD and look for the opt-in marker. If none, the URI is nonreferring.
4. OK assuming the opt-in design yields the needed information in the HTTP response.
5. OK - any generality or lack thereof is bundled into the relation.
6. OK - depends on the relation, but "works in browser" can be arranged

So if this is so wonderful, why isn't it already agreed by everyone? Maybe there is a missing requirement. The weird thing about this one is that it doesn't default to URI-refers-to-document (in the non-S1 case). E.g. it doesn't let you conclude that http://www.w3.org/TR/html401/ refers to the HTML 4.01 specification. To enable that inference requires either publisher opt-in or some other source of sender/receiver agreement. It remains to be seen how people will feel about this.