Message-Id: <199404252230.QAA22873@idaknow.acl.lanl.gov>
To: David Robison <robison@nwnet.net>
Subject: Re: Yet more URI/URC
In-Reply-To: Your message of "Mon, 25 Apr 94 13:41:37 PDT."
<Pine.3.89.9404251309.R4911-0100000@norman.nwnet.net>
Date: Mon, 25 Apr 94 16:30:20 -0600
From: rdaniel@acl.lanl.gov
David Robison <robison@nwnet.net> wrote:
> On Fri, 22 Apr 1994 rdaniel@acl.lanl.gov wrote:
> > Terry Allen writes:
[Terry worries about the fine line between bibliography and anthology
when anyone can create their own URCs for a URN.
Ron replies that publishers should be able to control the list
of URI servers you get when you access a URN of theirs. Other
people are free to create URCs for particular URNs and serve them
up. However, to locate those additional services you will have to
know THEIR URN, not just the URN of the original article. This takes
the URCs out of the impartial service, so Ron was not too worried
about such (potentially biased) URCs.
]
> But it
> does worry me. Publishers are in the business to sell books. They are not
> in the business to collate and collect scholarship _about_ their works
> (esp. things like negative reviews). If we rely on publishers to create
> these mega URCs, I see a couple problems: many will not bother
> participated in some esoteric scheme cooked up by some Unix weenies
> (please, no flames, some of my best friends are Unix weenies ;-) and we
> may see way-out-there publishers using the URC to create a stilted view
> under the guise of neutral publishing (as Ron fears).
Hmm, I think there is a misunderstanding here - but I am not sure if
I don't understand David's objections or if he misunderstands what I
propose. Here's what I propose, based on Mitra's scenario.
1) A URN contains (at least) a publisher name and an opaque string.
2) When you want to resolve the URN into a URL (by way of a URC), the
publisher's name has something like ".uri.int" appended to it. A
gethostbyname() is performed and you get a list of aliases and/or
IP addresses that the publisher has sanctioned to serve up URCs.
The publisher has control over this list of addresses. After all,
they are putting their name on it.
3) You pick one of the servers, connect to it, and give it the opaque
string. You get back a URC (or portion of it, such as a URL).
Publishers don't have to put much into the URC. I think URCs will have a
very small number of required fields (the URN is about the only one I can
think of). There will be a larger number of optional but customary
fields (Author, Title, Publisher, URL, Cost). There will other optional
fields that are well-defined but not so common (Abstract, References, MD-5).
There will be experimental fields that specialized service providers
use (X-Referenced-By, X-Related-Material, X-Author-Biography).
Publishers do not have to collect and collate scholarship about their
works. Other people will do that, and more power to them (IMHO). However,
the publisher is under NO obligation to put these other servers into the
list of servers you get back when resolving "publisher.uri.int".
If the publisher doesn't provide the address of their server, how will you
find it? It will have its own URN. From that you will get the URL for the
special service, give it the URN for the original work, and get back the
specialized URC. However, this specialized service is clearly the product
of a particular publisher, not a default system service that we would
like to think of as impartial. How will you find the URN for the
specialized service? Good question. It is not addressed in Mitra's
scenario. I think painless ways will be developed, but that is current
work.
> Now publishers should be able to do this if they please, but I doubt most
> of them will anyway. This is the stuff of librarians and other scholars,
> and I say again, I don't think URCs are the place.
I don't think the "authoritative" URCs provided by the publisher are the
place. Those should provide basic information, perhaps with an abstract
and references list. It is in the interests of the publisher to provide
an abstract so that it is easier to find the resource. These can be like
abstracts from scholarly articles, but they can also be "electronic dust
jackets". Providing references is less obviously a benefit, and so it
will not be as common.
Having said that the "authoritative" URC provided by the publisher is not
the place for lots of extra stuff doesn't mean (to me) that the extra
info other people collect should not be called a URC. It is meta-data
about the resource and will be treated in much the same way, except that
it is not where we (typically) go first to get info on a resource.
(As an aside, I really don't like calling the publisher's URC
"authoritative". "Default" is closer to how I envision them. You
can't even call them impartial because publishers will be more than
happy to point to laudatory reviews while ignoring slams.)
> I am concerned that if
> the IETF or ISOC presents these very-inclusive-URCs (VIURC) to the
> publishing world they will laugh. As a librarian I can tell you that
> while Books in Print works, it is full of errors and lots of problems. It
> is also very simple. We want the publishers to buy into this, so lets
> give them something the will use.
I hope this attempt at clarification has alleviated your concerns. If
it has not, we can keep hashing it out. The information I expect publishers
to provide is (IMHO) pretty minimal, while there will be a framework
for providing extra information should they wish to do so. At the same
time, other publishers are free to publish new works that add value to
the original in non-derivative ways.
Ron