I don't think there's any need to talk about sorting, if we're just trying to
solve the relevance issue.

Recall how this was resolved in classic Z39.50. (About 8-9 years ago.)
Relevance was treated as a relation attribute (as in "bib1.any relevantTo
Term").  Nobody has ever claimed any implied semantics that this gives you a
result set sorted on relevance, as this would break the Z39.50 model,  only that
the results are relevant (where relevance is determined by the server) and the
result set could potentially be in random order with respect to relevance. But
as a practical matter, those systems that supported relevance ranking all
supplied results in relevance order.   So it was a moot point.

Is that good enough?

--Ray


"LeVan,Ralph" wrote:

> > -----Original Message-----
> > From: Robert Sanderson [mailto:[log in to unmask]]
> > Sent: Monday, June 03, 2002 3:37 PM
> >
> > Agreed. But that opens a great big can of worms known as
> > 'sort' and all
> > the various options of sorting that you can ask for in Z39.50.
> >
> > Not that I'm against opening it, but I think that it takes us
> > another step
> > away from the simple lean clean and hopefully useful SRW towards the
> > not-so-simple, putting on weight, slightly dirty and more likely to be
> > useful SRW which others don't want to go to yet.
>
> I don't want to go there yet.  When we do go there, I'm going to push hard
> for sort being a completely separate service.  I'm very aware that the
> sorting can be made much more efficient if done while creating the result
> set and I'm eager for a compromise that puts it into the search.  But, we
> never came up with a clean way to do that in classic z39.50 and I'm not
> optomistic about it happening in SRW.  But, I'd like to defer the debate for
> a while.
>
> Ralph