Re: OASIS/SRU: Represent Scan within SearchRetrieve operation - - draft message

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

We don't have to reach consensus on this, but we should at least agree on
the content of the message that I post on our behalf.  So I will add: "Some
committee members support the idea of merging the searchRetrieve and Scan
function, others oppose the idea, and some are undecided."  Once the message
is posted you are all free to voice your positions in the SRU list
discussion.

I would like to post this today (I'll likely be out the rest of the week).
Please speak up before 5pm today if you do not agree with the draft message
as amended:



 AMENDED DRAFT MESSAGE

 ---------------------------------------------------------

 There is a suggestion to eliminate the Scan operation, and instead
represent
 the scan function as part of the searchRetrieve operation.

 Consider the typical scan example:



http://myserver.com/sru?operation=scan&version=1.2&scanClause=dc.title=frog&;
 responsePosition=1&maximumTerms=25

 To simplify discussion discard the operation and version parameters. (There
 are proposals to eliminate these; those discussions have not completed, but
 for purposes of this duscussion assume they are discarded.)

 This reduces to:


http://myserver.com/sru?scanClause=dc.title=frog&responsePosition=1&maximumT
 erms=25

 Next:
 - Model all the terms from all indexes for a database to be database
records
 in that database. The record syntax for retrieval would be the fragment of
 xcql that scan uses.
 - Define a query type scanClause (come up with a better name later). (We
 have talked about introducing multiple query types. That discussion hasn't
 completed but let's accept it for the sake of this discussion.)
 - Change responsePosition to startRecord.
 - Change maximumTerms to maximumRecords.


 And you get:


http://myserver.com/sru?scanClause=dc.title=frog&startRecord=1&maximumRecord
 s=25

 Then you essentially have a searchRetrieve request.

 Alternatively, introduce an explicit query type parameter, qtype:


http://myserver.com/sru?qtype=scan&query=dc.title=frog&responsePosition=1&ma
 ximumTerms=25


 For the query "dc.title=frog" the result set would be the term records
where
 'frog' is in record position 1 (or zero, subject to debate), and of course
 we need to extend the definition of startRecord to allow non-positive
 integers. (And add a sortby clause to the query to ensure the
 terms/"records" are ordered correctly.)


 Alternative approach:

 Define a scan context set, with an index whose name is 'index'  whose term
 values are the names of the indexes.

 So a query clause could be

                      scan.index=dc.creator

 The result set would be all of the dc.creator terms. (Again,  include a
 sortby clause to make sure you get terms in order.) With this approach you
 could present from the start of the index, if you wanted to (can't do that
 with Scan now).

 Say you want to include a seed term.  Define another index in the scan
 context set, 'term':

 scan.index=dc.creator AND scan.term >= <term>

 The result set would be all dc.creator terms beginning with <term>.

  The OASIS Search Web Services TC solicits feedback on this proposal and on
the various possible approaches. Some committee members support the idea of
merging the searchRetrieve and Scan function, others oppose the idea, and
some are undecided. We would like it to be discussed on the SRU listserv.