Message-Id: <m0pvmy5-0004JIC@inca.gate.net>
Date: Tue, 26 Apr 94 09:14 EDT
To: David Robison <robison@nwnet.net>, rdaniel@acl.lanl.gov
From: hoymand@gate.net (Dirk Herr-Hoyman)
Subject: Re: Yet more URI/URC
At 4:46 PM 4/25/94 -0700, David Robison wrote:
>This makes me feel better, but I still worry that we are taking a small,
>specific desire (a system for mechanistically locating information on the
>Internet), and trying to turn it into a grand scheme. Let us focus on the
>"simple" issue of URN->URC->URL(n) resolution (or even
>URN->URC(x)->URL(n)), leaving hooks for others to take on larger issues
>later. The more focused we stay on the resolution-resource-location
>issue, the sooner we will come out with a standard that people will
>actually use.
>
David, along with this requirement, there is one to provide a *minimal*
set of meta-data about a resource to aid in the determination of whether to
retrieve or not. This would include such attributes as size, format, cost,
language. A location resolution service is primary, certainly, but these
other attributes are right behind it.
If I may digress for a moment on URCs (and I believe we must understand how
the resolution service and URCs will work in order to understand how URNs
will be used), I am seeing now 3 levels of detail:
1. Location
2. Minimal
3. Full
The location would be just a set of URLs, the original intent of URNs.
There could be services that choose to only provide this type of URC.
Minimal would be the meta-data needed for determination of retrieval. Of
course, what it necessary is a moving target, but clearly it's more than
the location, as Mitra's scenario points out. If we can do just the
location, then we ought to be able to provide for a few more attributes.
I'm thinking of something like 100 bytes here, so that it would take about
the same amount of time as for just location (supposing that most of the
time is not being spent in transmission itself). I took the term minimal
from another working group that is trying to contruct minimal bibliographic
templates for resources (and not necessarily Internet one) that don't
always go thru a library.
Both location and minimal levels would fall under "Member Element Control"
that Michael Mealing spoke if in his URC document. We would be defining or
at least recommending attributes for these.
Full would be anything/everything. I'm concerned that this will entice
some to put into something like a MARC record, that would be bad (not short
and sweet). Rather than putting lots and lots of attributes into a URC, I
feel it would be better to point to another source of meta-data, such as a
library catalog (or full whois++ or X.500 or ...). While not wanting to
constrain possible innovation, this innovation ought to be oriented towards
IIR use, not a general directory service.
If we buy into this model, it would imply 3 templates for URN/URC lookup.
Having both a minimal and full template would allow for innovation, without
throwing a large URC at clients that don't want them. Presumably more
"standard" templates could be defined, but not more than a handfull. We
might, then, make recommendations as to what attributes ought to be in a
minimal template, though URC servers could provide whatever fields they see
fit. I don't believe that negotiating a template to use is a good idea
(too much overhead), though that might be possible.
Part of this model does not jive with Michael's. I'm suggesting that URCs
are "lightweight" and NOT meant "to contain ANY conceivable type of
meta-information", though that would be possible. What I see URCs are
meant to do is provide a scalable locator service. The meta-data is there
to allow for better selections of the available URLs. And this needs to be
fast, which is not mentioned in Michael's document either.
-- Dirk Herr-Hoyman | CyberBeach Publishing | Practice * Internet publishing services | random acts of kindness Lake Worth, Florida, USA | and hoymand@gate.net | senseless beauty +1.407.540.8309 |