Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.toronto.edu!ietf-distribution-owner
Message-ID: <9106182204.AA07720@spartacus.psi.com>
Original-To: ietf@ISI.EDU
Subject: Re: draft-osids-resdescripx500
Reply-To: yeongw@psi.com
Date: Tue, 18 Jun 1991 18:04:54 -0400
From: yeongw@spartacus.psi.com
Newsgroups: list.ietf
Distribution: list
Sender: list-admin@cs.toronto.edu
Approved: list.ietf@mail.cs.toronto.edu
Lines:       49

> i'm not fond of this document, and i'd like to try to figure out why.

I was not overly enthused with this document either, when I first
saw it, and have (privately) sent comments to Chris Weider about it.

However, I feel obliged to say something in Chris's defense here:

> first problem is that there's already a perfectly good protocol
> (Z39.50) for accessing structured data in MARC-like tagged formats.
>		[ ... ]
> i'd think you'd expect to look up internet resources in the card
> catalog, not in the phone book.

While I agree with Ed that Z39.50 is a more appropriate protocol
for the purposes of searching bibliographic databases., I have to
disagree with the implication ("i'd think you'd expect ... in the
card catalog, not the phone book") that Z39.50 is the answer to
the entire problem.

Basically, I view the problem of networked information retrieval
as actually consisting of three subproblems:

	- discovery: finding potential sources ("providers") of
	  information. In other words, finding out what's out there,
	  and who is providing what's out there.

	- searching: having found potential sources of information,
	  this involves meaningfully searching the provider's
	  data for the subset that is of interest

	- delivery: having identified "interesting" data, having
	  it delivered.

Essentially, I think X.500 is a good mechanism to solve the discovery
problem/subproblem, by providing an "Information Yellow Pages" that
would list potential sources of information.

On the other hand, Z39.50 is a potentially good mechanism to address
and solve the second problem of searching. While some work still
needs to be done (and is being done) to get Z39.50 into a useful
form, I think it shows great potential to be a very powerful
search protocol. And for more than bibliographic data too.

So, I don't totally agree with either Chris or Ed: neither X.500 nor
Z39.50 represent the complete answer to the problem. Instead, each
forms part of the solution, in my opinion.


Wengyik