# Re: Yet more URI/URC

David Robison (robison@nwnet.net)
Mon, 25 Apr 1994 16:46:07 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Peter Deutsch: "Re: Yet more URI/URC"
- Previous message: rdaniel@acl.lanl.gov: "Re: Yet more URI/URC"
- In reply to: rdaniel@acl.lanl.gov: "Re: Yet more URI/URC"
- Next in thread: Peter Deutsch: "Re: Yet more URI/URC"

    Date: Mon, 25 Apr 1994 16:46:07 -0700 (PDT)

    From: David Robison <robison@nwnet.net>

    Subject: Re: Yet more URI/URC

    To: rdaniel@acl.lanl.gov

    In-Reply-To: <199404252230.QAA22873@idaknow.acl.lanl.gov>

    Message-Id: <Pine.3.89.9404251625.T4911-0100000@norman.nwnet.net>

On Mon, 25 Apr 1994 rdaniel@acl.lanl.gov wrote:

> 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.
>
I do feel better about this--that publishers only need to supply the basics.

>
> (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.)
>
Agreed (is it bad taste to agree with an aside?)

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

This makes me feel better, but I still worry that we are taking a small,
specific desire (a system for mechanistically locating information on the
Internet), and trying to turn it into a grand scheme. Let us focus on the
"simple" issue of URN->URC->URL(n) resolution (or even
URN->URC(x)->URL(n)), leaving hooks for others to take on larger issues
later. The more focused we stay on the resolution-resource-location
issue, the sooner we will come out with a standard that people will
actually use.

I think we are mostly in agreement here, but the emphasis may vary.

David

- Next message: Peter Deutsch: "Re: Yet more URI/URC"
- Previous message: rdaniel@acl.lanl.gov: "Re: Yet more URI/URC"
- In reply to: rdaniel@acl.lanl.gov: "Re: Yet more URI/URC"
- Next in thread: Peter Deutsch: "Re: Yet more URI/URC"