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

Tim Berners-Lee wrote:
>
> > [...]
> 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.

This is very apropos to the discussion. Clearly you, as the only source of
information regarding your worldview, are the only individual able to make
this claim. Yet your worldview, to me, is just an abstract 'resource', which
I cannot independently examine for consistency, or usefulness. All I can
examine are the documents in which you transmit representations of your
worldview to the rest of the world :-)

But are you now suggesting that these documents are themselves abstract
resources that I cannot fully 'know'? Oh dear, it is getting more difficult
to get at the bottom of this. Perhaps the answers to a few burning questions
might help me out a bit.

For example http://example.org/x is a URI (we all agree on this). Do you
mean to say:

1) the _resource_ identified by http://example.org/x is necessarily a
_document_
2) if so, then what is the relationship between the entity retrieved via the
HTTP protocol and this document? Is it an 'abstract document' vs. an actual
document?
3) if so, what is an abstract document? does it have structure?
4) if so, is the structure a series of characters or something like an RDF
graph?

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

Yes this is really what is confusing me.

But if the protocol can only give representations about documents, how can a
_fragment_ of such a _representation_ of a document represent an _abstract
resource_?

5) Isn't this what the entire argument is fundamentally about?

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

6) by 'bits' do you mean a sequence of bits, i.e. a character string? Again
what does http://example.org/x represent? a resource (agreed). Is this
resource _necessarily_ a fixed sequence of bits?
7) if not, is this resource always a sequence of bits, and if not what is
the relationship between the sequence of bits and the 'abstract document',
(what again _is_ an abstract document?)

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

8) How is that? A fragment identifier identifies a _fragment_ of a document,
and this fragment is determined by the media type of the HTTP response
entity. How do we get from a sequence of bits to an abstract concept?

It seems to me, as I interpret Roy as suggesting, that it is RDF which does
this! But RDF treats URI references as _opaque_, that is there is nothing in
RDF that prevents

http://example.org/x rdf:type ex:abstactConcept

nor mandates:

http://example.org/x#foo rdf:type ex:abstractConcept

Unless of course we assume that

ex:abstractConcept rdfs:subClassOf rdf:Resource

In summary, I see the distinction you are attempting to make between
documents and abstract concepts, yet feel that the terminology:

resource,entity,document,fragment

is not finegrained enough to properly make these distinctions. I think what
is needed is a new terminology in which these concepts are properly defined.
(or else this just needs to be explained to me in a way that I can
understand -- if that is possible).

Jonathan

Received on Monday, 26 November 2001 11:27:34 UTC