Message-Id: <9404071626.AA04537@emmetal.cs.wisc.edu>
To: pays@faugeres.inria.fr
Subject: Re: URC's
In-Reply-To: Your message of "06 Apr 1994 21:27:47 +0200."
<765660467.16730.0-faugeres.inria.fr*@MHS>
Date: Thu, 07 Apr 1994 11:26:15 -0500
From: Bob Kummerfeld <bob@cs.wisc.edu>
In message <765660467.16730.0-faugeres.inria.fr*@MHS>, pays@faugeres.inria.fr w
rites:
>> >
>> > 1. If as karen says any one may have a URC with a different content
>> > for the same URN I don't know why this is being discussed in this group,
>> > and I would rather call them SRC Specific Resource Context :-)
>> > as this is no longer Universal and more a personal and changing over
>> > time Context that a specific user associates to an URN.
>>
>> But it's Universally understood. A URC contains things that should be
>> Universal but may not be resolvable....
>>
>
>The following has to be clearly decided and stated
> either a URC is just a concept there will never be any computer entity
> associated with it. Then from now on, no one will be allowed to state
> on this list I will GET the URC from URN using a protocol.
> I would thus maintain my claim that this is only a SRC(ontext).
> or a URC has indeed a computer representation reachable over the
> network and it can be retrieved using a name server type
> directory request when providing the URN.
> In that case the URC has to be located somewhere, it is no longer a
> concept of a bag containing all the meta information bound
> as well to the document as well to the different instances
> and versions (because these will be located in potentially
> hundreds or thousands of locations many of them unknown.
>
I think most people think of a URC as a real piece of data about some object
and that it can be obtained from a directory service. I don't see how this
precludes it being "a bag containing all the meta information bound
as well to the document as well to the different instances and versions".
It may be that one directory holds an abbreviated URC that tells me some basic
information about an object (eg it is a movie with a certain title, director,
actors, keywords etc) but it also contains a hint on where to obtain a more
expanded URC that contains a plot summary and some URNs for reviews.
......
>
>I know and the SOLO stuff we have (see below) is using the concept
>of centroid from whois++. What I wanted to say is that
>before using any kind of directory there is a need to collect
>the information that will be made available through the directory
>(whatever the name and protocol).
>What is apparently not studied so far is how to collect this information
>automatically without requiring any one putting available
>a copy (instance) of a resource somewhere being obliged to
>explicitely have to update a directory.
>In my mind there should be
> a tool/service to automatically collect the information of the
> existing instances
> another one (directory type) to make this information available
> through the net.
YES, exactly.
I like the concept of "publication" for objects on the net. At present, when
someone develops a new piece of the Web they announce it to the world by sending
mail to NCSA with entry for the "What's new" page or announcing it in
the news group comp.infosystems.announce. I would like a tool that helped me
construct a URC and submit (publish?) it to the directory service. This
is needed now and is a much easier problem to solve than attempting to
collect the information from the net automatically.
....
>Not only I have a concrete scenario in mind, but we also have
>an experimental prototype working here:
> . the URN for us are DN (understand X.500 Directory Names)
> . the resolution protocol is SOLO
> . the URC is the entry which name is the URN (the set of attr in that entry)
> and it contain locators for different versions and formats
>Of course we certainly not pretend it is the ultimate solution
> . it is probably not fast enough for plenty of usage
> . it is unclear how a directory will know how to select
> the locator *closest* to you
>but it works, is scalable (eg. CLDAP might provide the UDP
>speed for real name server responsiveness), allow to combine
>(limited) searches from an interactive user agent, with name server
>type of usage for simple and fast URN -> URL resolution,
>we have even developped a libwww module which knows how to
>handle these URNs (ie. make the directory request URN -> URL)
>enabling thus to have URN in our documents instead of URL only
>when using the enhanced version of Mosaic linked with that
>additional commolib module.
I'm impressed! The URNs don't look like the proposals from this group but the
basic structure a workable URN->URC/URN->URL system is there.
However, I don't think DNs are appropriate as URNs.
Bob.