Dictionaries are Books, but Cards in a Card Catalogue are not...

> > ...descriptions are not representations -- and for this reason,
> > I think it's not quite kosher to use GET to provide descriptions
> > (or anything other than representations).
> 
> You are making a two-level system, of resources and "descriptions".
>  This is, if you don't mind my saying so,
> a common temptation in global system design, but an error.
> A one-level recursive system is more powerful and general.
> It is the same type of error as the proposal that schemas should not
> be in the web.  I wrote "Dictionaries in the library?"
> http://www.w3.org/DesignIssues/NamespacesAreResources.html
> to try to make that point.  Reading "Goedel, Escher Bach" is better.
> :)

I agree that "bodies of knowledge" about a resource are also
resources, just as a dictionary is also a book.

But is a card in a card catalog a book?

And what about the description of the dictionary as a book?

And do cards in a card catalog have their own libarary codes?
Or are they anonymous resources accessed indirectly by the
code of the book they describe?

Just because we might wish to treat some bodies of knowledge
more explicitly like documents (books) does not mean we will 
want to treat all bodies of knowledge like documents (books).

We may prefer to interact with those bodies of knowledge like
cards in a card catalogue. Or simply as a response from the
librarian to a request about a book. Think of GET as a request
to the librarian "get me this book" and MGET as a request
to the librarian "tell me about this book".

Granted, the librarian might respond to the second request
by handing you a book -- that described the other book. Well,
OK, but perhaps the descriptive book given to you is in a
language you don't understand, or in braille, etc. And if
every time you asked for information about a book, you got
a *different* kind of book, because each author, or each
publisher of each book, or each library
chose to describe their own book in different ways. Soon enough,
you'd tire of such a burdensome means of obtaining information
about books.

How much better to always get descriptions of books in a consistent
manner, in a consistent form of expression, which enables us to
decide whether we care to or eve are able to inspect the content
of the actual book. I.e. like a card from a card catalog.

Perhaps the book is in a long-term storage archive and will
take days to get. Perhaps it's in a language we don't understand.
Perhaps you have to pay to get it. Nice to know these things
before troubling yourself and the librarian to get it, eh?
And nice to not have to know an arbitrary number of languages
and encodings to get that information as well.

So, while we may have large RDF/XML instances (dictionaries) with
explicitly assigned URIs residing on the web (as books), and
we may reference those documents by GETting them by their URI,
we also should have "cards" of descriptive knowledge which are generally
anonymous resources referenced indirectly by the URI of the
resource described.

I see MGET and friends as providing a well defined, consistent,
efficient "card catalog" for the web whereby one is able to
obtain the "card" (or a specified subset of it) describing a
given resource based on the identity of the resource. Just as one
would obtain a card from a card catalog (physical or digital)
in a library based on the identity of the book. And yes, that
book might very well also be a dictionary. And if one chooses
to give it a name, it might even be another card. Recursively.

Thus, MGET is not adding a second layer to HTTP per se. It is
simply providing a means to consistent and explicitly interact
with a (very) special class of (normally) anonymous resources
which are essential to the interoperability of SW applications.
MGET does not circumvent GET. It compliments GET.

Thus:

GET  {URI} -> representation of resource (book)
MGET {URI} -> description of resource    (card)

and if that card has a URI, and you want another card describing
the first card:

GET  {URI} -> representation of card1 (card1)
MGET {URI} -> description of card1    (card2)

Though I think that, like with most libraries, folks won't care
particularly about the cards, just the information they provide
about the books.

So why force all libraries to explicitly name all their cards?

Cheers,

Patrick

--
Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com

Received on Tuesday, 18 February 2003 02:59:05 UTC