# Re: URC's

Keith Moore (moore@cs.utk.edu)
Tue, 05 Apr 1994 23:03:45 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Karen R. Sollins: "URC's"
- Previous message: Alexsander Totic: "Re: Seattle minutes"
- In reply to: Karen R. Sollins: "URC's"
- Next in thread: Michael Mealling: "Re: URC's"
- Reply: Michael Mealling: "Re: URC's"
- Reply: Alexsander Totic: "Re: URC's"

    Message-Id: <199404060303.XAA25853@wilma.cs.utk.edu>

    From: Keith Moore <moore@cs.utk.edu>

    To: "Karen R. Sollins" <sollins@lcs.mit.edu>

    Subject: Re: URC's

    In-Reply-To: Your message of "Tue, 05 Apr 1994 19:41:49 EDT."

                 <9404052341.AA26944@zippy.lcs.mit.edu>

    Date: Tue, 05 Apr 1994 23:03:45 -0400

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.

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.

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

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

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

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

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.

* * *

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?").

(One hopes that clients will attempt to recover from those situations where
they do find inconsistencies, but there are many cases where the client cannot
reasonably be expected to use a resource without accurate information that is
external to the resource itself.)

* * *

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.

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.

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.

Keith Moore

- Next message: Karen R. Sollins: "URC's"
- Previous message: Alexsander Totic: "Re: Seattle minutes"
- In reply to: Karen R. Sollins: "URC's"
- Next in thread: Michael Mealling: "Re: URC's"
- Reply: Michael Mealling: "Re: URC's"
- Reply: Alexsander Totic: "Re: URC's"