W3C home > Mailing lists > Public > www-zig@w3.org > September 2001

Re: Sort criteria in Search Request

From: Robert Sanderson <azaroth@liverpool.ac.uk>
Date: Sun, 16 Sep 2001 13:47:27 +0100 (BST)
To: Ian Ibbotson <ian.ibbotson@k-int.com>
cc: ZIG <www-zig@w3.org>
Message-ID: <Pine.LNX.4.30.0109161315560.30708-100000@gondolin.hist.liv.ac.uk>

> instructions are bundled with the search criteria. As I said at the time, I
> suspect this comes from a long tradition of SQL where the order by is an
> integral part of the whole statment.

Right. But in Z39.50, it isn't explicit. Equally, you can't (as far as
I'm aware) do something like:

search for X and scan the results by Y.

(compared to 'search for X and sort the results by Y')
(eg:  'Search for books written by Tolkien, and browse their titles'
 vs:  'Search for books written by Tolkien, and sort based on their titles')

> > Could someone please explain the actual point of doing this as opposed to
> > just sending multiple requests as per the status quo?

> The real need for sort to be close to search-request is, as the doc says, for
> targets that need to be able to optimise the way they work. I have a few SQL
> backends, and it's really inconvienient to execute what can be a heavy SQL
> statement, only to have to immediately re-evaluate it because a sort-request
> has just come in and now we need to tag some order by clause on the end.

So the point is just to make it easier for using SQL as a backend then?

I don't have a great problem with doing this sort of thing, but it seems
to be getting away from what makes Z a good protocol for IR. See also ZNG.
Like Unix, you have small units that are put together in various ways to
get to the results you want, rather than the Microsoft one thing-does-all
approach.

On the other hand, look at Microsoft for what happens when you 'extend' a
protocol to make it more integrated with currently existing applications.

Our (generic) Z client makes use of Explain. It's -extremely- inconvenient
that this simply isn't implemented at all in most servers, which means
that most of the time we need to try to search -all- of the possible USE
attributes for supported indexes. With the (very good) proposed Bib2, as I
understand it, even this won't really be a feasable approach to
discovering how its possible to get records from the target as the index
types are qualified semantically rather than having a separate set of
attributes.

A lot of targets, according to their Supported Requests info in Init don't
support sort. And a lot of the ones that claim it, don't in truth. Things
like encapsulating sort in search tends to beg the questions of is sort
supported at all, and being able to find out that it is with reliability.

Rob
-- 
      ,'/:.          Rob Sanderson (azaroth@liverpool.ac.uk)
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Syrinnia:  telnet:  syrinnia.o-r-g.org 7777
____/:::::::::::::.                WWW:  http://syrinnia.o-r-g.org:8000/
I L L U M I N A T I
Received on Sunday, 16 September 2001 08:51:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:27 UTC