From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199404061943.AA08456@oit.gatech.edu>
Subject: Re: URC's
To: moore@cs.utk.edu (Keith Moore)
Date: Wed, 6 Apr 94 15:43:16 EDT
In-Reply-To: <199404060303.XAA25853@wilma.cs.utk.edu>; from "Keith Moore" at Apr 5, 94 11:03 pm
Keith Moore said this:
> I'd like to offer a somewhat different idea of a "URC". For the moment
> I'll leave off discussion of the specifics of what goes where.
Well....your idea of what a URC is and my idea of what a URC is seem
to be fairly in sync. Comments to follow...
> Off the top of my head, I can think of several kinds of meta-information
> about an object:
>
>* Part of the description of the resource itself (keywords, author, etc) may be
>useful in resource discovery. A searchable database could be constructed from
>individual URCs and serve a similar function to a library card catalog.
Correct. Say I know the Title and the Author. I (my client) constructs
this URC:
Title: Moby Dick
Author: Herman Melville
and then contacts his local URC expander (I'm not going to call them
URN->URL resolvers anymore. Since I consider a URN and a URL to be
just small URCs) and get's back something like this:
URN:bla
Title: Moby Dick
Author: Herman Melville
URL:bla
Cost: US$25.00
Content Type: text/plain
> * A description of a resource may be useful or necessary in allowing the
> resource to be used. As a crude example, since ftp doesn't provide a reliable
> mechanism for determining the content-type of a file, a client might need to
> obtain this meta-information (from the "URC") in addition to the file itself.
Correct. Say the user has this URC:
URL:file://foo.com/fe/fi/fo/fum;format=b (Is that what that ended up being?)
Content Type: image/jpeg
This then tells the client that I need to use binary mode transfer and that
what I'm getting back is a jpeg file.
> * As Karen pointed out, information about the characteristics or costs of
> different instances of an object might be useful in helping the client choose
> which ones to access.
Right. Given this URC it's kind of obvious which one I would pick:
URN:bla
Title: Schindler's List
URL:bla
Format: video/mpeg
Cost: $US10.00
URL:fee
Format: video/mpeg
Cost: $US0.00
> * Other meta-information might be useful in ensuring integrity/authenticity of
> a file .. e.g. an MD5 digest of the file signed with an author or publisher's
> private key.
URN:bla
Signed MD5:lamvc;aosin; laksnv;aosih; alsdnv;aklsdhgal;ksdjhflksdjnlkjcl
Title: My Bank Balance
URL:bla
>* Some people have suggested that information about locations of an object also
>belongs in the URC. Maybe it does and maybe it doesn't, but locations
>certainly fall into the nebulous category of "meta-information".
By locations you mean URLs? Most definitly they belong in URCs since
the location is just meta-info about the name. When you get down to
it everything ABOUT a resource is meta-information. Only the resource
itself is not meta-information.
> Observe that different kinds of meta-information get used in different ways.
> Some are involved in resource discovery, some in resource location, some
> in access. Some of the elements are used for more than one purpose, so we
> may not be able to draw clean lines between functional groups of elements.
Correct. That's why it needs to be in one structure. You may use an
element for resource discovery whereas I use it for accounting and audit
trails. You draw your line twixt which elements deal with which functions
and I'll draw mine.
> * * *
>
> It may seem obvious, but I'll state it anyway:
>
> The meta-information for a resource needs to be consistent with the
> resource (and instances of that resource) that the meta-information
> purports to describe.
>
>If a resource changes, at least some of the characteristics of the resource
>will also change. Attempts to use the "old" characteritics with the new
>instance of the resource may result in various failures. Imagine what happens
>when a client attempts to use an obsolete content-type, size, MD5 signature, or
>cost for a particular object ("gee, the URC said it was free...so why is there
>a charge on my bill?").
That's why I specify that URCs have a Time To Live of 0. You can try to cache
it for longer than that but it's not gauranteed. With things like Cost I
would expect the client and server to have someway to confirm the cost
before the transfer. For example:
user has:
URN:bla
Title: Moby Dick
URL:bla
Cost:$US35.00
and connects with that URL to the server, before any transaction is made
I would expect the client and server to exchange a gauranteed cost record.
(If this were put into a URC it might look like this:)
Server gives this back:
URN:bla
Title: Moby Dick
URL:bla
Cost: $US40.00
Digital Signature:eoewi85y6ofw98ytw8yo5ywpo98ytpw985ytfgp9wj8pyf985yp
at which point the client has the perogative to disconnect and not incurr
any charges.
>I imagine that a significant percentage of the resources to be described with
>URCs, named with URNs, and located with URLs, will change over time. If there
>are to be multiple copies of a resource, and multiple copies of the description
>of a resource, spread at various locations across the net, it is infeasible to
>update them all "at once", or to update the description of an object at the
>"same time" as the object itself.
>
>The trick is to design a system by which the instances of resources which are
>accessed using various meta-information, will be consistent with the
>meta-information obtained during the process of discovering/locating/accessing
>the resource.
Good point. I would expect there to be an "authoritative" site for the
one tried and true URC with just global information being authoritative.
> Such a system, if it is to be implemented and operate correctly and
> efficiently, must (a) place some constraints on what kinds of information are
> stored in various parts of the system, and (b) impose a discipline on how
> resources and their meta-information are updated.
True. I think you could really only qualify global information as truly
authoritative since any local instance may have changes (or just may not
be trustworthy).
>I'll draw an analogy to the old-fashioned, paper-only library. In such a world
>we do not expect that the card catalog contains all of the possible
>meta-information for a book. For instance, it doesn't tell us whether the book
> is currently checked out (even though that would be useful), because that
> information needs to be maintained elsewhere (say, so the library can easily
> tell when to assess fines) and it is too much trouble to update each instance
> of the card catalog every time a book is checked out or returned. Likewise,
> there is a discipline that governs how new books are added (or retired from)
> the library, so that the card catalog and the library's inventory are kept
> reasonably up-to-date. None of these things surprises us because we are very
> familiar with the constraints of the physical world.
>
> Of course, we'd *like* the networked library to keep track of every possible
> relationship between an object and its instances and their locations and the
> characteristics of all of these, and even the relationships between similar
> objects. But just as the physical world imposes constraints on a
> books-and-shelves library, so the networked world has constraints of its own
> which govern the design of a networked library. (Perhaps these are not as
> familiar?)
>
> We need to keep those constraints in mind when talking about where the various
> pieces of meta-information "go", how they are used, and how they will be
> maintained.
Someone else handled this one nicely. One of the past messages over the
morning gave a good example of how to deal with this.
-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!