From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199404011616.AA16621@oit.gatech.edu>
Subject: Re: A modest suggestion for the URN->URL service
To: uri@bunyip.com
Date: Fri, 1 Apr 94 11:16:49 EST
In-Reply-To: <199404010657.XAA19291@collie.acl.lanl.gov>; from "Ronald E. Daniel" at Mar 31, 94 11:57 pm
Ronald E. Daniel said this:
> A MODEST SUGGESTION FOR THE URN->URL SERVICE
>
> Ron Daniel Jr.
> Advanced Computing Lab
> Los Alamos National Laboratory
>
>
> INTRODUCTION
>
> I think Karen and Larry did a very good job with the requirements
> document and deserve praise (and a few brews should they be so
> inclined). However, up to now the discussions I have seen concentrate
> solely on the URN->URL lookup (by way of URCs) and have not addressed
> some other operations that are going to be necessary for the service.
I think this might be a mistake made by some of us. I myself have
made the mistake of aggregating all of the functions that we plan on
implementing into the name "URN->URL resolution". I for one
assume that any service will have large numbers of functions that
can be done on URIs. They should not hinder the basic purpose of
a URN, though.
> I think that a few small modifications to the requirements may be needed to
> account for these other operations. What operations? Well, for
> starters, how is a resource published and registered with the system?
> How does a publishing authority grant permissions to a sub-authority?
> Since a major motivation for URNs is to cure the "roaming URL" problem,
> how do we register a resource's new location with the service? If we
> have multiple URLs for a URN, how do we register these additional
> locations and verify that their content is correct? All of these
> operations seem implied by the current model of URN->URL via URCs.
Some of us see using whois++ as a URC expansion service (read
URN->URL resolver). whois++ has all of the above functions as
well as encription, views, result limitations, result encoding
specifications, etc.
> One thing I think we all would agree on is that we should cite our
> sources. I think that the 99 % of us who have used the Science Citation
> Index would agree that it would be very nice to have links from the
> original resource to annotations, critiques, extensions, etc. of that
> resource. To extend this slightly, some of those annotations might be
> SOAPs (Seals of APproval), which seems to be the current consensus on
> how peer review will be handled in the future world of on-line
> publishing. So now we need operations to register SOAPs and other URNs
> that annotate the original URN. The URC seems, to me at least, to be
> the natural place to store all this extra junk.
Correct. URCs as specified in my URC func requirments paper are
extendable to infinity (i.e.: anyone can put any object in them).
> Of course, now the URC of a URN is far too big to download to a browser
> every time we just want to get the URL for the next resource. What do
> we do to cope with this problem? Well, we need a way to pick out the
> appropriate fields of the URC. Here is my modest suggestion. We
> extend the structure of a URN from
> <URN:opaque_string>
> to
> <URN:method[(arg_list)]:opaque_string>
>
> and define a set of methods.
>
Doesn't that breaks everything a URN is meant to be? How can
I compare one URN string to another and find out whether I have
equality? A URN is meant to be an identifier, not a complete object in
the OOP sense. Those functions operate ON URNs therefore you can't include
the function in what it's operating on (can you?).
>
>
> CONCLUSION
>
> Thanks for reading all this. This note has drug on long enough, so just
> a quick wrapup. It may be premature to specify the representation of
> URCs within a URN->URL server. It matters a bit when a query is made
> that returns a complex result, but we never want to be sending the
> whole damn URC down the wire to a poor hapless client unless they are
> begging for it. We should define the basic operations to support, and
> the formats for complex queries and complex results, but this can be
> independent of the internal representation of the URCs.
I think most of us who are thinking of URCs envision some
type of view limitation function so that a client can specify limitations
on it's requests. For example, I see very limited clients like gopher
using gateways that only request URCs with URL and URN fields. Here's
an example:
client has URN1
it connects to whois++.int and says:
"Give me the record for URN1 but only give me fields that start with
URL: and URN: and limit the results to 50 hits and restrict the search
to URLs in the continental U.S." (forgive me for not being able to
construct the full whois++ query here!)
Then the client gets back about 5 URLs mapped to one URN that is written
up in a 6 line URC.
I do agree that we have not focused very much on the functions that we
plan on using all these things for but I think that is due to the fact
that there are so many functions that one can do. It's kind of like
designing numbers with the intention of one day getting around to
trying to write down all the functions that you plan on using them for.
I do think we need to sit down and write down that we plan on using
these things to do basic functions akin to add,subtract,multiply and
divide. Comments? Flames?
-MM
-- ------------------------------------------------------------------------------ Michael Mealling ! Hypermedia WWW, WAIS, and gopher will be Georgia Institute of Technology ! here soon via MIME. Your view of the Michael.Mealling@oit.gatech.edu ! internet is about to change completely!