Re: Namespaces wihtout "#" Was: Few CWM Bugs

> [...]
Tim:
> > The second issue is more significant.   In my worldview,
> > (which I claim to be (a) consistent and (b) useful)
> > http://example.org/x is a document.  You can't reuse
> > its URI for an abstract thing without a change to HTTP.

Sean:
> O.K., then we just change HTTP. What we're all quibbling over are
> those few words in the HTTP spec.:-
>
> [[[
> 10.2.1 200 OK [...]
>    GET    an entity corresponding to the requested resource is sent in
>           the response;
> ]]] - RFC 2616, 10.2.1


I don't think we are quibbling over a few words.
The HTTP spec provides a whole protocol for giveing representations of
documents.  You can't change a few words and make it a protocol
for getting information about abstract things described by documents.

> Roy has argued strongly that an entity corresponding to the resource
> is a representation of the resource.

I agree.  There are only some sorts of thing which can be represted in bits.
Those I call documents.

>You are saying that the
> correspondance pertains to the resource as a document. "200 OK" is
> certainly an acceptable return code (IMO) whether you find some
> information that *represents* what you're looking for, or whether the
> information *is* what you're looking for, so all we need to do is add
> some more information to the header to disambiguate.

No, it is not a question of disambiguating.  The actual document which
is represented will always exist, and always need a URI so that we can
reference *it*.  The problem with  the worldnet "Logo" URI ( .../Logo)
is that it actually does identify, usefully, a document.  We still need
the URI for that document.

Fortunately, the fragment ID allows us to refer to something defined
or described by the document, and that can be quite abstract.

By analogy, note that, for example, legal concepts are referred to
indirectly through the laws which define them
"A non-profit as defined in Section 501(c)3"
"Road vehicle as definde in Art IIB of section 82.3 of the penal code"
and so on. Documents are documents. They are powerful
because (with HTTP and slew of existing and future languages) we
can do a whole lot with them. We can argue about their contents logically.
I don't mind the semantic web architecture being built on a
infrastructure of documents ((and messages)).

> So, here goes with a new field name:-
>
>    EntityType = "Entity-Type" ":" ( "Resource" | "Representation" )
>
> If the header is added, then there can be no argument. If the header
> is not present, then we simply do not define what is meant. I'm sure
> that this will satisfy both points of view: for the
> representationalists (Roy, Aaron, DanBri) a response of "Entity-Type:
> Resource" means that the representation that is returned is also the
> resource being requested.
>
> It would satify me too, because I've always argued that people use the
> two different levels interchangably without giving the holder of the
> resource a chance to define it. Well, now you can. We've not really
> needed to define before, because we didn't build formal KRep systems
> on top of it, or if we did, then we just generally agreed what the
> things meant.
>
> So... call for objections? Comments?


I must agree with Roy's  "aaagh!" I'm afraid.

Tim

> --
> Kindest Regards,
> Sean B. Palmer
> @prefix : <http://webns.net/roughterms/> .
> :Sean :hasHomepage <http://purl.org/net/sbp/> .
>

Received on Monday, 26 November 2001 10:40:00 UTC