RE: larry's position on URIs as names

Sorry, I'm way behind on mail, and I think this request got
lost.  I hope this is helpful? If you remember, I am really
of the notion that it makes more sense to talk about 
"belief" than "knowing", and use a speech acts view of
what sending a URI "means".


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

I don't know what you mean by "reliable". Nothing is 100% reliable.
Some things are better than others. "tdb:" is just a convenience,
a way of adding one level of indirection. (Think of "tdb:" as a
kind of "eval".)


> 2) http: URIs make reliable names only when HTTP exchanges with the
> URI as request-URI play no role in determining what they name.

I don't understand what you mean in "determining what they name".
I think of the act of party A sending party B a URI as a speech
act. Party A has some idea of what they want party B to understand,
sends a URI  X to party B, and party B interprets the URI X 
in some context.  Something is 'reliable', I guess, if it's
useful for communication and the two parties are interoperable.

If I send you "http://larry.masinter.net" and you *don't* actually
use the HTTP protocol to retrieve the web page there, well, what
*do* you use? The DNS WHOIS database? 


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


I don't understand this at all. 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.

I would have to rewrite this to use "believe" rather than "know":
Party B believes that an assertion frobular( "http://example.com/x" )
to make an assertion about the high frobularity of a particular
PNG file.

You're asking whether party B coming to some conclusion about
the frobularity of ... what? The png file at some later date?
That would be jumping to conclusions.



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


Jumping to unwarranted conclusions is bad. 

If Party A asserts "frobular(X)" to Party B, and Party B trusts
Party A, then Party B isn't coming to an unwarranted conclusion.

I'm not sure of your use of "trust" there?

Received on Tuesday, 18 May 2010 02:45:05 UTC