W3C home > Mailing lists > Public > www-tag@w3.org > May 2010

Re: larry's position on URIs as names

From: Jonathan Rees <jar@creativecommons.org>
Date: Tue, 18 May 2010 08:29:08 -0400
Message-ID: <AANLkTimy0H87H6_kwxhoQfC6cYt3MF_tR0gJ5xhai0V4@mail.gmail.com>
To: Larry Masinter <LMM@acm.org>
Cc: www-tag@w3.org
Thanks! This should enable me to translate my meta-dialect into yours,
so that maybe we can begin to have a conversation. More later.

Jonathan

one comment inline below.

On Mon, May 17, 2010 at 10:36 PM, Larry Masinter <LMM@acm.org> wrote:
> 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?

How about a web cache?  Or maybe the 'representation' was bundled as
part of a software installation, and never sent over HTTP.  Or maybe a
different protocol such as some fancy high-performance successor to
HTTP was used. Or maybe the URI is being used for coreference and not
in relation to 'representations' at all - e.g. a namespace URI.

I think this is a theme that Roy has been pounding on for years now,
so you are probably familiar with it. If you haven't bought into it so
far, well OK, I'll accept that as being your position, as this is a
matter of judgment, not fact. But there are consequences to the
position that are sort of inconvenient.

>> 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 12:29:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:20 GMT