Print

Print


I think you both rather miss the point. The service being accessed is the
MetaSearch Engine - not the databases it will access. It is the province of
the MSE to determine all of this "messy crock". All the protocol has to do
is pass along instructions and let the target system do its best with them.
After all no search protocol tells a SE how to construct indexes and what
algorithms to use when assigning documents to subject clusters or any of the
other things SEs do for a living. SRU/W should not try to undertake this
level of complexity - I agree, and I was not asking for it.

All I would like to see is SRU/W make provision for a simple request to
search in more than one place - not specify how the world's semantics are
organised. There are, as I have said before, a number of rather
sophisticated - but not perfect - systems out there which handle this
problem.

Unfortunately, if SRU/W cannot find an extension to handle this it will
become a non starter for client -> MSE communications (at least in a
standard non-extended form) and an opportunity to introduce some sanity into
this growing area will be lost.

I will not be at the ZING meeting in Chicago (but will be at ALA), but I
really would like it if this topic can be discussed and some ideas we could
use come out of it.

Peter

> -----Original Message-----
> From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]On Behalf Of
> LeVan,Ralph
> Sent: Monday, June 20, 2005 9:58 PM
> To: [log in to unmask]
> Subject: Re: Betr.: Re: Multiple Sources in SRU/W
>
>
> > -----Original Message-----
> > From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]
> > On Behalf Of Dr Robert Sanderson
> >
> > I disagree.  The amount of complexity in Z39.50 for searching
> > multiple databases at once was a serious impediment to
> > implementation, and the same will apply to SRW.
>
> I absolutely agree!!
>
> What sort of explain record are you going to generate for this ad hoc
> amalgam database?  How are you going to explain that records from
> database A are available as MARC and B's are available as DC?  It's a
> messy crock and we shouldn't go there.
>
> Ralph
>
>