From: atotic@ncsa.uiuc.edu (Alexsander Totic)
Message-Id: <9404060854.AA00297@void.ncsa.uiuc.edu>
Subject: Re: URC's
To: moore@cs.utk.edu (Keith Moore)
Date: Wed, 6 Apr 1994 03:54:47 -0500 (CDT)
In-Reply-To: <199404060303.XAA25853@wilma.cs.utk.edu> from "Keith Moore" at Apr 5, 94 11:03:45 pm
> 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.
This depends upon the kind of meta-information that is stored.
In general case, It is up to the maintainer of the URC to decide which
information is guaranteed to be consistent. For example, while it is
desirable for a page count of a document to be consistent, it is not
necessary. The probable place where URI group could mandate
consistency is for the particular well-defined fields of the URC
(such as MD5: ).
Since different parts of the URC will be used by different services,
different parts of the URC might also be maintained by different services.
The question is do we want to spec these services in advance, or create
a general URC spec, and then slowly enumerate services and procedures
required for different fields.
> 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.
>
> 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.
No. This only applies to the system that contains URCs whose context
mandates consistency. Again, There is no need to impose consistency
requirement where it is unnecessary.
>I'll draw an analog 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-informationfor 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.
A very nice parallel.
> 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?)
Lets take an analogy a little further. When I find a citation
using a computer search in the same library, I expect an option on
my screen that will let me find out if the book is checked out.
This is because computers can keep track of these things.
Internally, library is probably maintaining two databases,
one relatively static and heavily indexed (abstracts), and another
database of circulation information. The ISBN ties them together.
The URCs could develop in a similar direction, where they might
be internally be distributed, but still appear as a single depository
of meta-information to the world.
>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.
This question is a hydra, because each different service will impose
different constraints. What I would like to see is a spec that
allows a simple retreival of a URC, or a part of, given a URN.
The details of field maintenance can then be ironed out separately.
What directory service should we use?
- DNS for URN server location, and then a separate protocol for URC
retreival from the URN.
- Some kind of directory services protocol, such as CLDAP, that would
resolve the whole URN in a single query
Aleks