From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199404061756.AA05355@oit.gatech.edu>
Subject: Re: Seattle minutes
To: atotic@ncsa.uiuc.edu (Alexsander Totic)
Date: Wed, 6 Apr 94 13:56:15 EDT
In-Reply-To: <9404060312.AA14442@void.ncsa.uiuc.edu>; from "Alexsander Totic" at Apr 5, 94 10:12 pm
Alexsander Totic said this:
> > Good point. Should I write everything down that I think URIs should be?
> > It actually makes good sense when you look at it all together...
> > I wrote the requirments such that you could encode everything that
> > everyone wants to encode (libraries:MARC records;CS folx:document
> > structure and format;users: cost and size;accountants:audit trails;
> > law enforcement:accountability, etc). Now that I think about it it
> > actually make sense that we worked out URLs and URNs the way we did
> > before we came up with a set of functional requirements.
>
> Why don't we start with the lowest common denominator:
> - URC will contain the metainformation about the URN.
Well. What about thos humpteen jillion WWW users out there that will want
to find out the URN given their favourite URL? Just change URN to 'resource'
and thats essentially correct.
> >From this definition, it is obvious that one can never specify all the
> information that can be stored inside the URC. Some fields will be commonly
> used, and we should specify these, so that smart clients can parse them.
>
> We also need to define how will different fields within the URC be
> specified, so that clients can parse it. The most commonly mentioned format is
> RFC822 header style, which has the advantage of being widely used, and human
> readable. If needed, we could extend this definition to allow associations
> between attributes. (URL[0]: url:mine. Format[0]: application/rtf).
Association twixt attibutes can be handled fairly robustly by just specifying
which objects have precedence over other objects. Your example above can
be easily done without the number by simply saying that whenever the
Format: attribute occurs it pertains to the last occuring URL or URN.
Beyond widely used and human readable it's also writeable by secretaries,
undergrads, marketing jocks, janitors, etc.....
> Many clients would need only a part of the URC. For example, the WWW client
> would in most cases only request a list of URLs. Search client would look at
> abstract information. Curious client would ask for the whole URC and
> display it to the user.
Exactly! I (Joe Client) only get the info that I want.
> The hard issues arise when designing a protocol for URN->URC resolution.
> What should be in this protocol? Should the protocol be really simple,
> with a single GET command, or should we add facilities for searching,
> database updating, etc. Would a single protocol for different URN->URC
> scenarios be desired at all?
I think we'll need all of those. That's why I like whois++ for this
since it already has all of that specified. Two of the biggest things
you'll need are view limitiations and the ability to update records.
> > > There's a chicken-and-egg problem here. We need to agree on vocabulary
> > > before we can discuss the proper function of each piece of the system, but
> > > it's impossible to define what a URC is without specifying its function.
> >
> > Definitly! I just decided to try and build a little bit of chicken so
> > I could start talking about the egg (did that make sense? ;-)
>
> We do have the gibblets (resolution scenarios).
This statement could cause a lot of bad jokes to start cropping up. ;-)
> Lets try defining a
> part of the system around them, and then accomodate the system for other
> uses.
Yes. Make it simple and extensible so that it will grow with time but
not leave everyone else behind....
-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!