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

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

"Generic documents" [1] in DesignIssues appears to be relevant.

[...]
> The actual document which is represented will always exist,
> and always need a URI so that we can reference *it*.

So you must agree that one can define a predicate relationship to
identify the concept that is referred to by the "generic document"?
For example:-

   [ :conceptOf <http://logicerror.com/myWeavingTheWeb> ] .

But whoops... Aaron is already using that URI to identify his copy of
Weaving The Web. He can still use the inverse of "conceptOf" (e.g.
"documentOf") to identify the document, but you argue that he can't.
Why shouldn't he have the choice, even if it means a change to HTTP?
Or, more pragmatically, what will happen to your view of HTTP
resources as documents if and when HTTP is extended: does this mean
that you cannot base anything on the assumption that an HTTP resource
is a document? If you cannot, then what is the utility?

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

Well, if you do take ../Logo to mean the "concept of a logo", once
again, it's just a simple relationship to identify the "document".

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

The problem with this is that whilst a FragmentID is useful in this
sense, it is also quite limiting. For example, if you want to use the
Logo document to assert "Logo#Logo identifies the *concept* of this
logo", often you cannot, because you run up against the fact that the
content type of the representation is a key factor in deciding what a
FragID identifies, and often content types do not even allow you to
talk about bits of FragID space.

I am arguing weakly that, from a practical POV, it's not a GoodThing
to restrict people to HTTP URIs as documents, because often there will
be utility in using the URI to identify the concept described by the
document, and yet people can still refer to the document itself with a
simple relationship. Of course, the counter argument is that if all
HTTP URIs necessarily identify generic documents, we can still use the
relationship the other way to talk about the concept... but I really
do think that people should be given the choice.

> I don't mind the semantic web architecture being built
> on a infrastructure of documents ((and messages)).

O.K., but surely you can't even necessarily know that
http://example.org/x is a document *if* you acknowledge that
extensions can be made to HTTP in the future? The metro-map diagram in
the SW roadmap [2] is close to arm-wrestling me into submission,
though: if you can only ever get bits back as a representation, then
it does seem sensible to define HTTP resources as documents. But I
think that if you set that down as a lot, you'll lose a certain amount
of flexibility to the SW that you may want again in the future.

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

Fair enough... but I remember you suggesting (on #rdfig) a new
response code that says "here is some information *about* what you're
looking for". My suggestion is that because "200 OK" is so abstract, I
can't see why that information can't be added to that form of
response, in the form of a simple header.

[1] http://www.w3.org/DesignIssues/Generic
[2] http://www.w3.org/DesignIssues/diagrams/loop

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

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