I'm not sure it's a _big_ mess, though, at least for metasearching.
I was just looking at our metasearch logs this morning, so did a quick count: 93% of the searches were keyword searches. Not a lot of exactness required there. It's mostly in the 7% who are doing more specific searches (author, title, subject) where the bulk if the problems lie, I suspect.
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
From: Code for Libraries [[log in to unmask]] On Behalf Of Ray Denenberg, Library of Congress [[log in to unmask]]
Sent: Tuesday, April 28, 2009 8:32 AM
To: [log in to unmask]
Subject: Re: [CODE4LIB] exact title searches with z39.50
Right, Mike. There is a long and rich history of the debate between loose
and strict interpretation, in the world at large, and in particular, within
Z39.50, this debate raged from the late 1980s throughout the 90s. The
faction that said "If you can't give the client what is asks for, at least
give them something; make them happy" was almost religious in its zeal.
Those who said "If you can't give the client what it asks for, be honest
about it; give them good diagnostic information, tell them a better way to
formulate the request, etc. But don't pretend the transaction was a success
if it wasn't" was shouted down most every time. I can't predict, but I'm
just hoping that lessons have been learned from the mess that that mentality
got us into.
--Ray
----- Original Message -----
From: "Mike Taylor" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, April 28, 2009 10:43 AM
Subject: Re: [CODE4LIB] exact title searches with z39.50
> Ray Denenberg, Library of Congress writes:
> > > The irony is that Z39.50 actually make _much_ more effort to
> > > specify semantics than most other standards -- and yet still
> > > finds itself in the situation where many implementations do not
> > > respond correctly to the BIB-1 attribute 6=3
> > > (completeness=complete field) which is how Eric should be able to
> > > do what he wants here.
> > >
> > > Not that I have any good answers to this problem ... but I DO
> > > know that inventing more and more replacement standards it NOT
> > > the answer. Everything that's come along since Z39.50 has
> > > suffered from exactly the same problem but more so.
> >
> > I think this remains to be seen for SRU/CQL, in particular for the
> > example at hand, how to search for exact title. There are two
> > related issues: one, how arcane the standard is, and two, how
> > closely implementations conform to the intended semantics. And
> > clearly the first has a bearing on the second.
> >
> > And even I would say that Z39.50 is a bit on the arcance side when
> > it comes to formulating a query for exact title. With SRU/CQL there
> > is an "exact" relation ('exact' in 1.1, '==' in 1.2). So I would
> > think there is less excuse for a server to apply a creative
> > interpretation. If it cannot support "exact title" it should fail
> > the search.
>
> IMHO, this is where it breaks down 90% of the time. Servers that
> can't do what they're asked should say "I can't do that", but -- for
> reasons that seem good at the time -- nearly no server fails requests
> that it can "sort of" fulfil. Nine out of ten Z39.50 servers asked to
> do a whole-field search and which can't do it will instead do a word
> search, because "it's better to give the user SOMETHING". I bet the
> same is true of SRU servers. (I am as guilty as anyone else, I've
> written servers like that.)
>
> The idea that "it's better to give the user SOMETHING" might -- might
> -- have been true when we mostly used Z39.50 servers for interactive
> sessions. Now that they are mostly used as targets in metasearching,
> that approach is disastrous.
>
> _/|_ ___________________________________________________________________
> /o ) \/ Mike Taylor <[log in to unmask]>
> http://www.miketaylor.org.uk
> )_v__/\ "I try to take one day at a time, but sometimes several days
> attack me at once" -- Ashleigh Brilliant.
