- From: Jonathan Rees <jar@creativecommons.org>
- Date: Mon, 17 May 2010 14:50:54 -0400
- To: Larry Masinter <masinter@adobe.com>
- Cc: www-tag@w3.org
Larry, The question I asked you below was not rhetorical. Your answer will help me to prepare for our June F2F. Thanks Jonathan On Sat, Mar 27, 2010 at 7:51 PM, Jonathan Rees <jar@creativecommons.org> wrote: > 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 Monday, 17 May 2010 18:57:32 UTC