What Name Should A Namespace Name?

The recent SW identification by URIs problem has hurt my head. There
are so many apparently unresolvable conflicts within our proprietary
use of the URI space that I'm beginning to wonder if we ought to start
again or not :-) Seriously though, as I see it, there are only a
handful of base problems, cuased by the fact that:-

We all want to identify something, either by representing it perfectly
(e.g. a data:, URI), by describing an address process (e.g. many forms
of URLs, HTTP GET etc.), or by giving something a "name", e.g. a
namespace name (there are many conflicts here, not least of which is
that this may inadvertantly resolve to the former two).

Representing something as a literal is a perfect solution, but not
really practical because one ends up with long data:, URIs... the way
the Web works is that a URI is a resource identifier, not the resource
itself. Even data:, URIs aren't strictly the resource themselves,
because they map to some series of information which is explicitly
contained in the URI itself: it's just a deceptively precise mapping
from identifier to resource.

The problem that I want to resolve with this message is a more
pragmatic one: what should one use as a namespace name in a Semantic
Web system? (or: should one use an HTTP URI as a namespace name).

One can ideally choose any part of the URI space that one controls for
a namespace name. Technically, I guess one could use data:, URIs for
namespace name, e.g. @prefix myns:
<data:,the%20thing%20that%20I%20call%20> although this doesn't resolve
who "I" am (a more precise URI could). Of course, lately, people seem
to be using the HTTP space as if it were the *only* URI space...
certainly, it is probably the most useful, being so widely
implemented. The problem is that people see HTTP URIs as addresses,
and indeed the URI specification seems to define them as such.

HTTP URIs map to a resource b.w.o. the DNS system etc. It is an
unaviodable fact that if you use an HTTP URI to "name" something,
people are going to associate the GET resource (if there is one) with
the thing that one is naming. In my opinion, they are correct to do
so. If they find nothing there, they may assume that the term is void:
I believe this to also be correct. This wouldn't be so much of a
problem is the HTTP URI space were perfectly persistent: if the URIs
always mapped to the data.

The PURL [1] system is a neat way of getting an HTTP URI to always map
to some object, b.w.o. HTTP redirect (moved temporarily). The PURL
system depends on the PURL database not collapsing, and each
particular user maintaining the redirect in question. One (very, very
sneaky!) way around this would be to use the PURL to redirect to a
data:, URL, which is technically allowed (although I guess/hope that
the PURL system has some limit on the maximum length of URI), which
would be like using the PURL resolving meachnism as ones server... a
rather unscrupulous thing to do, but at least persistence would be
guaranteed :-) A better idea would be to use your own server under a
date-stamped root to return a data:, URL based upon a query string
(GET) that one sends it. [2] That way, one can use this query string
anywhere in the data, URI returned, allowing for more flexibility.

The fact of the matter is that we still have the old names vs.
addresses problem on the Semantic Web. Currently, many people are
using addresses as names, and then scratching their heads when the
public use them as addresses.

So, to my original question (what to use as a namespace name), I think
that using an HTTP URI should probably be avoided, unless one requires
to have a lengthy description of the particular term. Such a URI
should be persistent (as persistent as possible...), and one should
expect people to resolve it (i.e. use it as an address). As for the
"/" vs. "#" debate, I don't see any difference in them... using #
might be worse because it infers resolution based upon MIME type,
which is decidedly ambiguous, but using / makes people identify the
term with an entire Web resource (e.g. page), not something
particularly defined within it.

Next problem: many-to-one resolutions, and the opacity of the RDF
mechanism. I conclude not much of a problem due to equivalence and

BTW, a note on the intended scope and purpose of this message: one of
the SWAG aims was to investigate URIs and best practises, which we
haven't done all that much. Hopefully we can help to publish some of
this material, rather than let things be repeated a million times. I'm
CC'ing this to RDF IG just in case anyone cares for YANT.

[1] http://purl.org/
[2] Maybe the W3C could set up such a service? For example,
http://www.w3.org/2001/04/resolver/?myTerm could return something

     <#myTerm> rdfs:label "myTerm" .

encoded in a data:, URI upon resolution? By adding an extra bit to the
URI, e.g. /resolver/n3/ or /resolver/xrdf/ one could even choose the

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

Received on Wednesday, 11 April 2001 11:51:55 UTC