- From: Jonathan Rees <jar@creativecommons.org>
- Date: Sat, 27 Mar 2010 19:51:59 -0400
- To: Larry Masinter <masinter@adobe.com>
- Cc: www-tag@w3.org
Larry, I wanted to ask this while it's still fresh... at my presentation on web semantics I was making the point that GET/200 exchanges ("corresponds to" relationships in 2616 parlance) are of little use on their own in discerning what entity the "URI owner" means to name with the URI, since any set of responses is compatible with the entity being a wide variety of things. You made a comment about ambiguity that I think was in agreement with this. But I wasn't clear on your exact position around the use of http: URIs as names because, as I had just arrived at (3) below, providing a list of possible sources of "other evidence", you appeared to disagree with one of my premises. I suspect that was a misunderstanding. Can you tell me which of the following most closely matches your view of best practice? 1) http: URIs don't ever make reliable names/designators for use as the subjects of metadata assertions. Use tdb: or guids or ____ instead. 2) http: URIs make reliable names only when HTTP exchanges with the URI as request-URI play no role in determining what they name. 3) http: URIs make reliable names but only in the presence of evidence other than HTTP exchanges with the URI as request-URI. (If exchanges are useful it's only when they're used in combination with that evidence.) 4) http: URIs make reliable names. A consequence of 2) might be, for example, that if you knew (via independent communication with the "URI owner") that http://example.com/x was intended to name some unchanging particular PNG file, and did a GET soon thereafter on http://example.com/x and got a PNG file, you could not infer that http://example.com/x was intended to name *that* PNG file, absent other metadata. Whereas with 3) you could. If that's not good enough, the "other evidence" in 3) might be an SLA that you and the URI owner have entered into that guarantees response uniqueness over some period of time ("trust"), or metadata giving enough checkable information about the image (e.g. a date/time or checksum) that the chance of accidental collision is satisfyingly small (verifiability). Would evidence like this, in addition to the belief (above) that the representation is fixed, enable use of HTTP exchanges as a way to help figure out what entity is meant? Just trying to figure out where you set the bar. Jonathan
Received on Saturday, 27 March 2010 23:52:32 UTC