Decentralizing the thing-described-by.org approach

Ok, here's a new proposal that extends the thing-described-by.org
approach to address DanBri and Benjamin's concerns about centralization.

PART 1: ABSOLUTE INDIRECTION PREFIX
How about defining the concept of an "absolute indirection prefix"
(essentially a prefix that causes 303-redirect through a service like
thing-described-by.org), and then allow each site to declare (in RDF of
course) what absolute indirection prefix it uses?  

For example, suppose site example.org decides to use the t-d-b.org
redirect service for the URIs in its color ontology, and it mints the
following URIs:

	http://t-d-b.org?http://example.org/concepts/colors/red
	http://t-d-b.org?http://example.org/concepts/shapes/circle

When you come across the first URI,
	http://t-d-b.org?http://example.org/concepts/colors/red
you want to learn more about it, so you do a GET on it, and the
t-d-b.org server does a 303-redirect to
	http://example.org/concepts/colors/red
You then retrieve the RDF document from that URI, and among other
interesting information, you read the following RDF assertion
(pseudo-N3):

	http://example.org/concepts/
		ns:uses-absolute-indirection-prefix
			http://t-d-b.org? .

which asserts that documents under http://example.org/concepts/ may use
http://t-d-b.org?" as a an absolute indirection prefix.  I.e., if a
document under http://example.org/concepts/ uses a URI of the form

	http://t-d-b.org?u

then "http://t-d-b.org?" is the 303-redirection prefix, and the request
will be forwarded to u, where u is an absolute URI.  

Since your software knows what an "absolute indirection prefix" is
(i.e., ns:uses-absolute-indirection-prefix has become a well-known
predicate), when it later comes across the URI
	http://t-d-b.org?http://example.org/concepts/shapes/circle
it is able to optimize away the access to t-d-b.org and go directly to
http://example.org/concepts/shapes/circle .  Thus, only the *first*
access using the "http://t-d-b.org?" prefix involves an access to
t-d-b.org, and t-d-b.org does not need to be well known in advance.  All
subsequent accesses to it (pertaining to documents under
http://example/concepts/ ) can be optimized away.

PART 2: RELATIVE INDIRECTION PREFIXES
The idea of "relative indirection prefix" extends the idea of an
absolute indirection prefix to permit shorter URIs when a site chooses
to provide its own 303-redirection service.

For example, suppose site example.org provides its own 303-redirect
service, and uses the prefix
	http://example.org/concepts?
for this purpose.  It could declare this prefix as a "relative
indirection prefix", something like this:

	http://example.org/documents/
		ns:uses-relative-indirection-prefix
			http://example.org/concepts? .

which asserts that a URI of the form

	http://example.org/concepts?u

will always be 303-redirected to

	http://example.org/documents/u

where u is a relative URI.  This means that a concept URI like

	http://example.org/concepts?colors/red

will 303-forward to the corresponding document URI

	http://example.org/documents#colors/red

much like URI rewriting (which of course is how the redirect would be
implemented).  The relative-indirection-prefix approach gives the same
efficiency gains as the absolute-indirection-prefix approach, but
permits shorter URIs (at the cost of having to host the 303-redirection
service).

FRAGMENT IDENTIFIERS
Incidently, I think this approach (and the thing-described-by.org
appoach in general) also plays well with fragment identifiers.  For
example,
	http://t-d-b.org?http://example.org/concepts/colors#red
would effectively be redirected to
	http://example.org/concepts/colors#red
(though of course the fragid processing is at the user agent -- not the
server).  The key thing to note here is that, unlike conventional #
URIs, the meaning of
	http://t-d-b.org?http://example.org/concepts/colors#red
is independent of the media type returned by
	http://example.org/concepts/colors

Comments are invited, though I won't be able to respond until after
August 29 when I return from vacation.

David Booth, Ph.D.
HP Software
dbooth@hp.com
Phone: +1 617 629 8881

Received on Saturday, 20 August 2005 16:08:48 UTC