Message-Id: <9410051919.AA00261@ulua.hal.com>
To: avatar@jolt.mpx.com.au (Andrew Pam)
Subject: Re: No "TOP" of the docuverse [Was: URC usage scenarios ]
In-Reply-To: Your message of "Thu, 06 Oct 1994 02:34:01 +1000."
<m0qsZI2-0005tXC@jolt.mpx.com.au>
Date: Wed, 05 Oct 1994 14:19:36 -0500
From: "Daniel W. Connolly" <connolly@hal.com>
In message <m0qsZI2-0005tXC@jolt.mpx.com.au>, Andrew Pam writes:
>First of all, the Xanadu system has never had a distinction between URLs
>and URNs; Xanadu has always been conceived as a distributed filesystem in
>which every document has a unique address or identifier, but the actual
>storage and retrieval is the responsibility of the back end (preferably at
>the OS level). Any document can - and should - be physically located at
>any number of servers with complete locational transparency.
Bingo. I don't know why folks go to such trouble to distinguish URLs
and URNs. The URL concept grew out of the WWW addressing architecture
which was designed to include locationally transparent addresses[1].
The fact that such addresses have not yet been deployed is not a
design decision but a reflection of the fact that it takes time to
deploy technology.
The idea that URNs are somehow fundamentally different from URLs is
odd, and the proposals of deploying a namespace disjoint with the WWW
address syntax is just plain silly. The WWW address space acomodates
multiple addressing schemes. When we come up with a service that
provides the features that folks are looking for in URNs (high
availability and authentication), we can start writing urn://... if we
like, but I bet we will write whois://... and solo://... and
lifn://... or md5://... for a while until one becomes the clear
winner and the others die out.
>It is anticipated that in most cases a document would be located within the
>docuverse (a Xanadu term coined by Ted in the 1960s, BTW) by a user by
>searching (perhaps even fuzzy searching) attributes of the document familiar
>and memorable to humans such as the publisher (or author) and title.
>This is probably analogous to the concept of URC -> URN resolution,
>and alleviates the "bar napkin" problem.
I think the "human transcribable" requirement is overrated too. I've
heard estimates that we're trying to name some 10^15 objects. Folks
will develop vocabularies of symbols and keywords. On a bar knapkin,
folks will write "It's on gatekeeper in the X contrib stuff. I think
it's called Xmunger." We should design a system that can adapt to a
vocabulary like that, and do effective searching.
>However, [...], the Xanadu addressing scheme [...] operates as
>[...] a hierarchy of four trees. [...]
> Thus the structure is:
>
>host.id.0.publisher.id.0.document.id.0.fragment.id
>
>I hope that this message has provided somewhat more useful food for thought.
Very much so... in fact, I'd like to see a more thorough and concrete
example of how this works. Could you give an example of
(1) what the results of an author/title/pub-date search might look like
(2) how to follow links from those results to the full text
of the documents, and
(3) how to follow a link from one document to another
[1] "Naming -- /DesignIssues"
http://info.cern.ch/hypertext/WWW/DesignIssues/Naming.html
Tim BL 1991
Daniel W. Connolly "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010
<connolly@hal.com> http://www.hal.com/%7Econnolly/index.html