Message-Id: <199404201747.LAA13061@idaknow.acl.lanl.gov>
To: mitra@pandora.sf.ca.us (Mitra)
Subject: Re: Re urn2urc-00
In-Reply-To: Your message of "Wed, 20 Apr 94 05:16:22 GMT."
<CoJLBB.KLJ@pandora.sf.ca.us>
Date: Wed, 20 Apr 94 11:47:52 -0600
From: rdaniel@acl.lanl.gov
Mitra (mitra@pandora.sf.ca.us) wrote:
>Terry -thanks for the questions - its good to see some more people have
>read it well enough to find problems with it!
>
>Terry Allen (terry@ora.com) wrote:
>: Mitra, you write in draft-ietf-uri-urn2urc-00.txt, at (3),
>: that the client locates a URN > URC resolution service to
>: get from a URN to a URL. But you never explain why this
>: is the way to go. I have imagined URCs as collections
>: of information that would allow one to choose among URNs;
>: the question of locating specific instances (URLs) of
>: URNs should be much simpler. Would you expand on why you
>: think this is reasonable?
>
>I'm not quite sure I understand your question Terry, first did you
>misprint URN for URL up above, I see a URC as a collection of info that
>tell you about a URN and then typically gives you enough information
>about specific URLs to allow either a user or a clever client to select
>which URL to retrieve (based on cost, content-type etc).
Both approaches are useful. Mitra's scenario talks about finding
locations once you know the name of a particular resource. The
name will typically be known because it is in a hyperlink.
Terry seems to be thinking of a resource discovery scenario.
Imagine connecting to a large URI server and doing queries against
all the URCs to find ones that contain particular keywords, authors,
etc.
Alan Emtage alludes to these multiple uses in the Seattle minutes
<URL:http://www.acl.lanl.gov/URI/archive/uri-archive.messages/1229.html>
where he enumerated 3 potential services:
1) General lookup
URN --> URLs
URCs
2) Reverse lookup
URL --> URNs
URCs
3) Characteristics/attribute matching
URC --> URNs
URLs
It appears that a query mechanism, such as that in whois++, can
easily handle the cases of URN->URL and URN->URC once the server
has been located. It can also handle URL->URC (and probably
URL->URN), but easily locating a server that knows of the URL does
not seem possible with the mapping of publisher to domain name in
Mitra's scenario.
The operations Terry seems to be thinking of, URC->UR[N,L], seem
straightforward if all the URCs for a resource are identical, which
is implied by Mitra's scenario. (Mitra, please correct me if I am
wrong about this implication).
However, not everyone thinks that URCs should be like this. As an
example, consider when we want to write documents that are
annotations, critiques, or extensions of earlier documents.
I would like to be able to put the URNs of these annotations into
the URC of the original source. This is so that if you find, say, an
interesting research paper, you can easily find out about subsequent
work in the field. These URNs take space to store, bandwidth to
send to remote servers, and computational power to search. This
puts authors and publishers in the position of paying to provide
highly critical reviews which may point to competing resources. They
are not too likely to want to do this, and they have a very easy
way of avoiding it - just don't put the URN of the annotation
into the URC of the original.
There are at least two ways around this "censorship" problem.
One is that we invert the annotations relation so that URCs have a
list of references rather than annotations. Finding the
resources that annotate other resources is then a
computationally expensive process on lots and lots of servers.
Another approach is to have distributed URCs where no one entity
has total control over all the content. We still have to consult
multiple servers, but the URC fragments will presumably point
to each other, reducing the space and complexity of the search.
If URCs are distributed, obtaining URNs, URLs, and other URC
fragments once you have a single URC fragment will not be so
easy. I would assume that each URC fragment has the URN in it, but
it will not have a full list of URLs and other URC fragments.
I am trying to come up with an architecture for a distributed
URC system, but don't yet have anything I am satisfied with.
Other people who want distributed URCs - lets talk to see where
we are.
Ron Daniel