- From: Sean B. Palmer <sean@mysterylights.com>
- Date: Wed, 11 Apr 2001 16:50:28 +0100
- To: <swag-dev@yahoogroups.com>
- Cc: <www-rdf-interest@w3.org>
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 contextualization. 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 like:- <#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 format. -- 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