TagIssue57Proposal27/Suggestion

A suggestion of JAR (2012-09-29)

Work in progress...

In order to progress toward a sensible compromise on the idempotency and come-from problems (which relate to interoperability of hash URIs and "compensating" or M/N-declared properties), I want to consider the following axioms for the scenario in the diagram, which together would be satisfied by an interpretation/model (call it I4) distinct from I1, I2, and I3:

 <U200-omf> = <U200-lp>
 <U200-omf> ≠ <U#omf>
 <U200-lp> ≠ <U#lp>

(These relationships could of course be written in OWL.) According to the I4 I have in mind, the hashless http: URIs U200-omf and U200-lp identify something that I'll call "protocol behavior thing" or PBT. A PBT is how the Web will respond to requests (HTTP, etc.) where the request URI is a hashless http: URI. If Web behavior (the PBT) is the same for U200-omf and U200-lp, then naturally the two URIs would be synonyms (co-identify). A "protocol behavior thing" is not necessarily the same as a "generic resource". I4 and I5 share the equality (of what U200-omf and U200-lp identify) with I1, and the inequalities (between the hashless URIs and these particular hash URIs) with I3.

Accepting the equality of U200-omf and U200-lp (or the possibility that someone else could accept it) involves a concession only from adherents of I2: they have to give up on depending on being able to assign distinct meanings to "200 URIs" that are behavioral aliases of one another. Although several proposals (Ian Davis's, "does not imply", proposal 25) depend on this kind of behavioral aliasing in the presence of semantic distinction, my guess is that this concession would have little or no deployment consequences, depending on how much uptake there has been of this detail of the proposals. But this is an empirical question.

Here's how such an I4 would give meaning to M and N (i.e. affect what F* and G* are):

F*(x) = if x is a PBT then {if yielding 2xx, then a generic resource with that representation as instance, else ?}, else x
G*(x) = if x is a PBT then {if yielding 2xx, then what the representation says it should be, else ?}; else x

Similar to I4 (in regard to equations and inequations) would be a version of I3 (with ordered pairs) in which 200-lp was interpreted to be the pair <LP,OMF>.

The price of this proposal (beyond just the M/N declaration idea) is the inelegance of the creation of a singular type PBT that is a second-class citizen ontologically.

This leaves the question of the treatment of 303. For any "303 URI" there would exist one of these PBTs, so a choice is to be made as to whether to interpret a "303 URI" to be one. Clearly this is desirable in the RDF world for legacy reasons - there is significant community investment in treating 303 URIs like hash URIs. ("303 URIs" are essentially a way to write a hash URI without using a hash character.) But there is an option of making the treatment of "303 URIs" specific to RDF (perhaps an interpretation I5), without affecting other notations or languages in which it might be useful, or necessary as a matter of integrity, to interpret all hashless http: URIs as PBTs. The advantage of I5 is that it eliminates the categories of "200 URIs" and "303 URIs" altogether, and therefore reduces or eliminates the annoyance of URI meaning that is contingent on what is retrieved (200, 303, etc.). This desideratum was articulated at the June TAG F2F.

Under I5, F* and G* would be like I4's versions, with the provision that if x is a PBT yielding 303s, then the result is what the 303 target says it should be (true for both F* and G*!).

So my thought is:

what a URI means in a data format or protocol is ultimately the responsibility of the format or protocol definition (and/or community consensus) to determine
we give a background suggestion (opinion, not justified by the URI or HTTP specifications) at the level of the architecture that hashless http: URIs might identify PBTs or something similar, without diving too deep into the ontology and properties of such things
in the unlikely event one wanted to rehabilitate the AWWW "information resource" idea one could venture that IRs are akin to a particular kind of PBT (the ones for which retrieval succeeds, i.e. that "have representations")
RDF says an interpretation should map URIs to "what they identify" without saying what they identify, implicitly deferring to RFCs 3986 and 2616, which don't say either; the TAG offers #2 above as a particular profile of RDF, in case anyone wants to know what the TAG thinks has broadest interoperability potential
the "303 hack" then becomes a sort of legacy override local to the RDF community, and that's OK because of 1