Re: Meta info tags

Nick Arnett (narnett@verity.com)
Tue, 20 Sep 1994 14:23:39 -0700

Message-Id: <9409202118.AA21472@nasty.verity.com>
Date: Tue, 20 Sep 1994 14:23:39 -0700
To: Michael.Mealling@oit.gatech.edu (Michael Mealling)
From: narnett@verity.com (Nick Arnett)
Subject: Re: Meta info tags

At 12:15 PM 9/20/94 -0400, Michael Mealling wrote:

>Not really. Those two paragraphs only specify that we need some method of
>specifying 'well known' attribute names. It is intended that anyone can
>put any attribute/value pair they want in a URC. There are no gaurantees
>that anyone will be able to use it but if it is a well known pair then
>atleast someone can find a definition for it.

This is much clearer to me now... I also saw Larry Masinter this morning at
Stanford's Web conference and got a bit further down the road on the
issues. He said that there's some desire for nested entries of some sort
(in response to my asking about relational or semantic data modeling for
URCs, v. flat-file). It seems clear that in dealing with structured text
or compound documents of others sorts, the notion of what constitutes "a
document" can't be a flat one.

>URCs are not meant to carry a minimal number. My best hope is that they
>carry a very rich amount of information that allows ALL systems (not
>just those that understand HTML) to parse them easily depending on how
>much information they require to function.

Is the intent to offer nothing "in between" the URCs and documents? In
other words, as it stands, I would think that I'd put a certain amount of
meta-information into URCs and then expect client applications to retrieve
whatever else might be available directly from the document itself via HTML
and HTTP headers.

However, I'm thinking that one type of attribute I might include in a URC
would be where to go to get additional kinds of meta-information. I think
this could be a powerful capability. For example, as a publisher, I might
index my data six different ways, using various search engines (obviously I
think ours, Topic, is best, but it's a heterogeneous world, after all).
The URC could be the mechanism for client applications to ask "Where's a
Topic index to this document?"

Then, armed with the URN and a place to do full-text searches, the client
could search for something within that document, without ever having had to
retrieve the document itself or its headers.

I guess I'm implying that for various purposes, there are various
combinations of URCs that will apply, full-text search being just one.
It's a significant one, however, due to the size of the index, so it's not
something you'd want replicated except when utterly necessary.

Nick

P.S. Is the URI list maintained by a listserv? I don't see anything in
its messages' headers to indicate an address for subscribing and I'd like
to add it to my archive, which will be available (and highly searchable, of
course) at our site soon.