Re: Back to HTTP semantics

On Fri, Jun 12, 2009 at 9:59 AM, David Booth<david@dbooth.org> wrote:

> Hold on, that's *way* overstated.  While Pat may not agree that URI
> ownership gives *absolute* authority in establishing the referent of a
> URI -- and I agree with that, as described in "The URI Lifecycle in
> Semantic Web Architecture" http://dbooth.org/2009/lifecycle/ -- it is
> quite clear that URI ownership at least has a very strong *influence*.

This is an empirical question that would be difficult to evaluate. By
"matters" I probably meant something more rigorous than what you
thought I meant. To conclude that webarch "identification" ought to be
aligned with RDF "interpretation" requires reading between the lines,
since it's never explicitly stated normatively for HTTP or AWWW
(neither of which talk about RDF) or in RDF semantics (which has no
reference to the web). If someone takes on some RDF as a result of
nose-following, they probably do so because they choose to, not
because any spec they've seen tells them to.

> If http://example/ont#asdf dereferences to an RDF document saying that
> that URI denotes an elephant, it is *far* more likely that others will
> use that URI to denote an elephant than a tree, other factors being
> equal.

This is not because of any theory of URI ownership, but because they
get the RDF when they nose-follow *and* they happen to like what they
find (or are not picky). And the important thing is not what the URI
"denotes" (as if that were an objective notion, or as if anyone could
ever figure what the owner thinks its denotes, if they've even thought
about that), but what sort of thing it *ought* to denote if specified
logical constraints and informal advice, assuming they make sense and
are acceptable to the consumer, are respected.

> So I think, though Pat will have to correct me if I have guessed
> wrong, the difference in view is whether URI ownership gives prima facie
> evidence of such authority..

In this case authority is (maybe) earned and (maybe) granted, not
legislated. Even if there were a W3C recommendation that said you had
to drive on the right, instead of just a GPN saying it was a good
idea, it could have no real authority since the relevant practices
have been deployed for eight(?) years, and it's too late to *require*
changes in what everyone's doing - unless you want to publish a
revised the RDF spec and provide a way to signal that it is, or should
be, followed. We just don't have jurisdiction over the installed base.
We can politely suggest and ask and implore, which is what Tim and the
TAG do when they ask others to use the httpRange-14 rule, and we're
likely to get respect in most places, but we're not in a position to
dictate.

> I agree, but I just want to point out that the httpRange-14 advice is
> the other way around.  It does *not* tell A not to say that U names a
> person.  Rather, it says that if U, which presumably is under A's
> control, yields a 200 response then U names an IR.  But again, there is
> no architectural need for Person and IR to be considered disjoint.

As I've said many many times, I think you are misreading the
resolution. Yes, it is grammatically written the way you say, but it
simply *can't* mean what it literally says. Look at it - the first
line is critical:

"The TAG provides advice to the community that they may mint "http"
URIs for any resource provided that they follow this simple rule for
the sake of removing ambiguity:
    * If an "http" resource responds to a GET request with a 2xx
response, then the resource identified by that URI is an information
resource; ..."

This is a *rule* for the community to follow. The only thing the
community can do, and indeed all the TAG wants it to do, is to
modulate the way servers behave - that is, modulate what kinds of
responses are yielded for GET requests in a certain situation. It is
not phrased as a rule, but it is easily converted into one by
contraposition:

    * If the resource identified by [the new] http: URI is not an
information resource, the resource identified by that URI does not
respond to a GET request with a 2xx response [when this rule is
followed].  [i.e. *should not* respond that way.]

Again, the TAG does not have jurisdiction over HTTP or RDF, and this
rule has not even had formal review, so taking the * statement as fact
or dictum as opposed to voluntarily adopted good practice is like
ordering mulberry trees to grow in France (as Henry XIV did).

(This conversation previously took place here:
http://esw.w3.org/topic/ErrataHttpRange14 )

Jonathan

> --
> David Booth, Ph.D.
> Cleveland Clinic (contractor)
>
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of Cleveland Clinic.
>

Received on Monday, 15 June 2009 01:38:49 UTC