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

Re: Sort criteria in Search Request

From: Ian Ibbotson <ian.ibbotson@k-int.com>
Date: Sun, 16 Sep 2001 13:48:51 +0100
To: ZIG <www-zig@w3.org>
Message-Id: <01091613485103.13119@www.k-int.com>
Well, when I posted the question a few weeks ago about considering sort 
instructions as a part of search request I was actaully thinking more along 
the lines of "Logical Models" than implementations. It just seemed to me 
(After having many conversations with people about a specific toolkit) that 
one of the most common requirements passed on to developers who use an IR API 
is "Search for X and sort by Y". In their translation of this requirement 
into code-calls, it seemed to me that of all the issues with (my) z39.50 API, 
the need to sort-after-search is the one that caused most dissonance. After 
talking with people about the sorting requirements, it started to look (To 
me) as though developers new to Z39.50 have a conceptual model whereby sort 
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.

I'm not really worried about the semantics of encapsulated sort, it's not so 
difficult (after all ;-)) and the toolkit now hides all this from the 
Application programmer anyway. However, I am a teeny bit worried about how 
many servers actually support encapsulated sort, and about providing the best 
model possible for developers who use a Z39.50 origin without being drawn 
into the inner workings of the various toolkits out there. I was just 
wondering how many people actually create a single result set and then sort 
it multiple times, If people really only sort once, then I was just exploring 
the idea that the sort instructions could be contained in the search request.

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.


On Sunday 16 September 2001 12:05, Robert Sanderson wrote:
> > My point is to illustrate how easy this is (even though you have to
> > support encapsulation). Or let me put it this way: a number of people
> > said "encapsulation is too hard, let's just come up with an agreement
> > to put a sort pdu in otherInfo". That's all the proposal does
> > basically, is put a sort pdu in Otherinfo (and set an option bit).
> Could someone please explain the actual point of doing this as opposed to
> just sending multiple requests as per the status quo?
> Eg why do:
> 1. init
> 2. search+sort
> 3. present
> rather than:
> 1. init
> 2. search
> 3. sort     (after you know that the search has actually -succeeded-)
> 4. present
> It seems that then the next logical step in the progression is:
> 1. init+search+sort+present (ala HTTP etcetc.)
> Thanks,
> Rob

Ian Ibbotson
Knowledge Integration Ltd - http://www.k-int.com
Sheffield Science Park
Cooper Buildings
Arundel Street
S1 2NS
Tel : +44 (0)114 22 11 813
Mobile: 07968 794 630
Mail: ian.ibbotson@k-int.com
Received on Sunday, 16 September 2001 07:46:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:03 UTC