# Re: Yet more URI/URC

Michael Mealling (ccoprmm@oit.gatech.edu)
Tue, 26 Apr 1994 12:53:02 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: rdaniel@acl.lanl.gov: "Re: Yet more URI/URC"
- Previous message: Dirk Herr-Hoyman: "Re: Yet more URI/URC"
- In reply to: Dirk Herr-Hoyman: "Re: Yet more URI/URC"
- Next in thread: Peter Deutsch: "Re: Yet more URI/URC"

    From: ccoprmm@oit.gatech.edu (Michael Mealling)

    Message-Id: <199404261653.AA20220@oit.gatech.edu>

    Subject: Re: Yet more URI/URC

    To: hoymand@gate.net (Dirk Herr-Hoyman)

    Date: Tue, 26 Apr 1994 12:53:02 -0400 (EDT)

    In-Reply-To: <m0pvmy5-0004JIC@inca.gate.net> from "Dirk Herr-Hoyman" at Apr 26, 94 09:14:00 am

(as a quick aside: Terry, could you post that example you gave me? The
one about the french guy in the middle east....It's such a good example!)

Dirk Herr-Hoyman said this:
> 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.

I definitly agree with this. I see certain services/clients only being
able to handle 1 and maybe 2 and special ones (ala Mosaic) handling
the last.

> 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.

I'm planning on my next version of the URC paper proposing a set of
elements that we need right now:

Size
Content Type
Cost
Title
Author
Version

Can you think of anymore?

> 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.

This is where I start disagreeing. I know of large numbers of people who
will want to ENCODE THE INFORMATION AVAILABLE in a MARC record in a URC.
I don't necessarily want an entire MARC record in there in it's raw
form but the same information could very well be in there.

> 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.

You don't need to negotiate which one you want. That's something that
is best left up to the resolution method we end up with. That's
why I like whois++. My client can say something like this:

template=urn;URN=bla:include=URL
Which gives you your location example

template=urn;URN=bla:include=URL,size,content-type,cost,title,author,version
which gives you your minimal example

template=urn;URN=bla
which gives you your full

> 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.

You didn't quote enough of that line. It states:

* Encapsulation: In the most basic sense, a URC must _BE ABLE TO CONTAIN_
ANY conceivable type of meta-information or URI.

This doesn't mean that a URC must always contain all the information but
that it CAN.

> What I see URCs are
> meant to do is provide a scalable locator service.

So do I. But when the location of that service also has to do information
discovery in order to find it then you need to be able to handle as much
information as possible.

> The meta-data is there
> to allow for better selections of the available URLs.

This is what all that meta-information is for. For example, how
is a grad student supposed to find a URN for a 16th century manuscript
1/4 of which was published in French first while the other 3/4 were
published in English 20 years latter. The student wants the earliest
full English edition with pointers to an abridged translation of
the French. You need all this information in the URC in order to
find the resource they want. This search will not be fast. It will
take several minutes if not an hour or so but the user will get
something of value.

BUT

This does not preclude the user down the aisle from having a URN
and getting a URL in a very short amount of time by specifying
template=urn;urn=bla:include=urn
to his/her local whois++ server....

> And this needs to be
> fast, which is not mentioned in Michael's document either.

That document is a list of requirement for a URC. The above requirment
is for the resolution protocol which should be addressed in another
document. I agree it needs to be as fast or faster than as DNS but
that is not something that can or should be made a requirement of
something that doesn't have the conept of being fast or slow.

    --
    ------------------------------------------------------------------------------
    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!

- Next message: rdaniel@acl.lanl.gov: "Re: Yet more URI/URC"
- Previous message: Dirk Herr-Hoyman: "Re: Yet more URI/URC"
- In reply to: Dirk Herr-Hoyman: "Re: Yet more URI/URC"
- Next in thread: Peter Deutsch: "Re: Yet more URI/URC"