Re: RFC 2616 vs. AWWW

I think we are in agreement here, but let me blab on to make sure.

On 10/12/07, Xiaoshu Wang <wangxiao@musc.edu> wrote:
> Jonathan,
> > The httpRange-14 resolution [1] is about identification (of a thing
> > by/to an http server), not reference.
> "httpRange-14" is an *engineer* but not a *philosophical/ontological*
> solution because a server response code such as 200/303/404 etc. do not
> tell you more about what you already know or don't know about the URI.

Agreed: RFC 2616 is an engineering specification, and httpRange-14 is
meant to overlay one small bit of philosophy onto it - the double
entendre of 2xx HTTP response codes as having both their HTTP meanings
(as given in 2616) and ontological content (as given in httpRange-14).
I agree that 2616 doesn't tell you what 200 says about 'the URI', but
independent senses of response codes can be employed inside any
community that agrees to observe them. (Unless httpRange-14 finds its
way into an HTTP or RDF spec, there is no way to know whether any
server means by any response code what the code means to the TAG -
making the whole httpRange-14 exercise sort of frivolous.)

> HTTP specs is an engineer protocol, it instructs how client/server
> suppose to communicate. But HTTP spec does not govern the meaning of the
> returned resource/thing.  AWWW just happens to ride on top of it and
> give it some interpretation.  HttpRange-14 is *not* about identification
> but is a solution to relate and disambiguite two closely related
> things.  There is nothing wrong if one URI is used to identify both me
> and my RDF representation.  It just makes it difficult to talk about the
> RDF-less me and the me-less RDF.

I was with you until the last 'identify'. Pat's method of explaining
the overloading (the overloading is not necessarily 'wrong', but is
confusing) is to have two different words for the two relationships.
'Identifies' is nice for the endpoint because 2616 already uses it
that way (identifying a network resource to a server), while 'refers
to' seems perfectly fine to me for what URIs want to do when written
in RDF graphs. If you overload 'identifies' in the way you do above,
which is what AWWW does and what I did initially, you get into all
sorts of nasty arguments.

I might quibble over whether any RDF will ever 'represent' me, or with
how 'closely' an RDF is related to something it describes, but I don't
think these matter here so we needn't get into it.

Let's hope that we never need to create URIs to refer to http
endpoints that never respond with 2xx. But if we did then we could do
with the endpoint what we do with any other kind of thing - give it a
URI (not the original one) and a definition, which is published
somewhere. Or we can use blank node notation to talk about them,
assuming we have a good name for the way they're related to their
URIs.

One way to see httpRange-14 is as identifying [sic] cases where semweb
reference = HTTP identification. This shorthand frees you from the
need to make independent assertions that specify the referent of URIs
for 'information [network] resources'. This is good because publishing
independent definitions of all those bilions of network resource URIs
would be a terrible burden - no one would do it. The 2xx response code
*is* a Boothian declaration.

It's still a house of cards, but this feels like progress to me.

Establishing this distinction (identify vs. refer) would require an
overhaul or deprecation of AWWW, but I think we need this in any case.

Received on Friday, 12 October 2007 12:50:10 UTC