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

On Sat, 24 Nov 2001, Tim Berners-Lee wrote:

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

In-principle plausible, although _please_ define "document". The distinction
is only useful if it can be defined clearly enough to implement to. Is a Web
Service a document? (CGI-based, SOAP etc) An image? What about a mailbox
(eg. could http: URIs name the same things as mailto: URIs)? What about
Shakespeare's "Hamlet", abstractly conceived, is that a document? Could it
have an http: URI scheme? A "farenheit-to-centigrade conversion service"?
What about a category of thing (eg. an RDFS class) or relationship? Are
these sufficiently document-like? If not, whose definition do they fail?
How does an rdfs:Class like wordnet:Logo differ from the notion of 'the
W3C logo, distinct from its concrete fileformat representations'. The
latter has a http: URI (we can use it in web browsers). What makes that a
document, but not http://xmlns.com/wordnet/1.6/Logo ? Or rather, why can't
documents have instances/members?

Instinctively, some notion of "bits not atoms" seems to be what we're
after here, although http:-named services screw things up somewhat, as
does the notion of an abstract work distinct from its concrete (paper,
file formats etc) representation. In practice, I'm not sure what value
their is for pursuing the distinction: it is a very high level, broad
brush distinction. Maybe it is useful because whenever we see a resource
whose name begins 'http:' we can conclude "that's not the sort of thing
that can have a size-in-pounds"? (although books, an old fashioned kind of
a document, have such a property...).

There seems to be a high cost (upper ontologising is rarely fun) and
dubious benefits (what additional inferences can we draw?) to saying that
'http:' URIs can only name the members of some as-yet-illdefined class.

Flipping things around, here's a practical reason that I chose to use a
'/' instead of a '#' as the final character of the URI that names my
Wordnet-to-RDFS-class namespace:

If I'd used http://xmlns.com/wordnet/1.6# instead of
http://xmlns.com/wordnet/1.6/ then the URI reference for a class in that
namespace would be something like: http://xmlns.com/wordnet/1.6#Image
instead of http://xmlns.com/wordnet/1.6/Image

This affects deployability in a very practical way. The Wordnet RDF Schema
has 50,000 classes. If one attempts to dereference
http://xmlns.com/wordnet/1.6#Image using good old fashioned HTTP/1.1, the
actual request you do is:

(remembering that #Image gets stripped off before HTTP requests are made)

GET http://xmlns.com/wordnet/1.6 HTTP/1.1

...which clearly doesn't pass enough information up to my server to give
it any useful information about wordnet. So it can't do what I currently
do, which is return a description of the relevant portion of the class
hierarchy. I guess it could return a dump of the _entire_ schema (huge),
or some (as yet undefined) manifest file format, or SOAP connection
details for talking to the server's SOAP query interface. But it can't do
the most useful thing, which is return a description focussed on the class
we're interested in.

So, I deployed a namespace ending in '/' to see if this was a useful,
feasible thing to do. Apart from the accusation that I've made a category
mistake (by assuming that at least some classes and properties can be
thought of as http:-namable 'documents') I've not run into any practical
problems.

Dan


-- 
mailto:danbri@w3.org
http://www.w3.org/People/DanBri/

Received on Sunday, 25 November 2001 05:52:32 UTC