RE: [search-ws] queryn: A proposal for SRU to facilitate formsprocessing

[Matthew Dovey <m.dovey@jisc.ac.uk>]

Ray,

If we start with an SRU request of the form

queryType=cql&query=index1%20relation1%20term1

Tony's proposal is (if I've understood correctly), that a form-based client would send

queryType=cql&queryn=1&qi1=index1&qr1=relation1&qt1=term1

The presence of the queryn parameter would indicate to the server that the request is not a "proper" SRU message (it does not contain a parameter called query, for instance) but an intermediate from which the "proper" SRU message (queryType=cql&query=index1%20relation1%20term1) can be constructed (via an established and published mechanism).

My counter proposal is that the form based client would send

queryType=fbcql&qi1=index1&qr1=relation1&qt1=term1 

In this case this is a "proper" SRU message in which the value of queryType indicates to the server which parameter(s) contains the query 

This, however, requires a change to the underlying spec for how queryType works - rather than defining the syntax passed in the parameter called query, the queryType now also determines the name of the parameter(s) in which the query can be found i.e. for queryType=cql, the server should look in for a parameter called query; for queryType=fbcql, the server should look for parameters of the form qi<n>, qr<n>, qt<n> etc.

I'm not entirely happy with either proposal to be honest - but I still agree with Tony that this is a use case we need to address/solve.

Matthew


> -----Original Message-----
> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> Sent: 14 December 2010 20:03
> To: 'Hammond, Tony'; Matthew Dovey; 'LeVan,Ralph'; 'OASIS SWS TC'
> Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms
> processing
> 
> Tony - forgive me for being dense but I don't completely understand what is
> proposed. So let's go back to square one.
> 
> 
> 
> Would a query go over the wire, where:
> 
> 
> 
> queryType=cql (or omitted as default)
> 
>   &queryn=2
> 
>   &q1.idx=index1
> 
>   &q1.rel=relation1
> 
>   &q1.trm=term1
> 
>    etc.
> 
> &query=  WHAT?????
> 
> 
> 
> would there be a real (redundant) cql query in the cql parameter.  Or what?
> 
> 
> 
> If the queryType is 'cql' (default or explicitly) and the query does not contain
> what we know to be a cql query, then this is a radical departure from the
> current spec.
> 
> 
> 
> I honestly cannot tell if this is what you're proposing.
> 
> 
> 
> When you say: 'Whether the query travels wholesale through a single
> "query" parameter or is split up over mutiple querylets (can I use that word?
> :) as signalled by a "queryn" parameter does not affect the query itself.'
> 
> 
> 
> I don't know what to make of that statement.  The purpose of the protocol is
> (a) to tell the server what the query type is, and (b) to present a query of
> THAT TYPE in the query parameter.
> 
> 
> 
> When you say:
> 
> "What I proposed was a *prerocessing* step an SRU server could take to
> *assemble* the query string into the parameter "query" so that it could be
> read by the parser indicated by queryType ("cql" by default)."
> 
> 
> 
> Then I really get worried.  This seems completely counter to the protocol
> model that we know and love.
> 
> 
> 
> Don't get me wrong, I'm not trying to dismiss the idea altogether, but I would
> like to see it done in a manner consistent with protocol principles that we all
> agree with.
> 
> 
> 
> --Ray
> 
> 
> 
> 
> 
> From: Hammond, Tony [mailto:t.hammond@nature.com]
> Sent: Tuesday, December 14, 2010 5:44 AM
> To: Matthew Dovey; Denenberg, Ray; LeVan,Ralph; OASIS SWS TC
> Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms
> processing
> 
> 
> 
> Hi Matthew:
> 
> > To me the queryType parameter instructs the SRU server which parser it
> should use to read the incoming query.
> 
> I would agree with that to the extent that the query string is read from the
> "query" parameter. From Sect. 5:
> 
>     "The request parameter queryType is a string indicating the query language
> supplied in the parameter 'query'"
> 
> What I proposed was a *prerocessing* step an SRU server could take to
> *assemble* the query string into the parameter "query" so that it could be
> read by the parser indicated by queryType ("cql" by default).
> 
> So, according to the current spec the proposal is covered by "queryType=cql"
> allowing that a reassmbly mechanism required by presence of "queryn"
> parameter has been activated.
> 
> It could be argued that there might be countless preprocessing steps, but
> this I believe - assembly from web form input - occupies a special position in
> that it is intimately bound to current web technologies for user input.
> 
> Tony
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
> Sent: Tue 12/14/2010 9:55 AM
> To: Hammond, Tony; Ray Denenberg, Library of Congress; LeVan,Ralph;
> OASIS SWS TC
> Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms
> processing
> 
> > but am less convinced about your point b) which has to do with
> > presentation. In my opinion presentation (or wire encoding) is purely
> > an SRU function and has nothing to do with CQL. SRU is the protocol
> > whose job is to get the query across. Whether the query travels
> > wholesale through a single "query" parameter or is split up over
> > mutiple querylets (can I use that word? :) as signalled by a "queryn"
> > parameter does not affect the query itself.
> 
> Semantically the query is unchanged, syntactically it is.
> 
> In the same way in classical propositional logic we have the "standard"
> notation (e.g. a ^ b) but some use Lukasiewicz's notation (e.g. Kab). Whilst
> both notations express the same query, I would regard these as different
> queryTypes.
> 
> Similarly, if for some reason, I decided to write a variant of CQL which used
> polish (or reverse polish) notation instead of infix, that would be a different
> queryType.
> 
> I think, there may be a nomenclature problem, as I agree that these are the
> same type of query, but not the same queryType! To me the queryType
> parameter instructs the SRU server which parser it should use to read the
> incoming query. The SRU server will require a different parser depending on
> whether the CQL is encoded in the normal format, your form-based
> encoding or my mythical polish variant.
> 
> Matthew
> 
> 
> **********************************************************
> **********************
> DISCLAIMER: This e-mail is confidential and should not be used by anyone
> who is not the original intended recipient. If you have received this e-mail in
> error please inform the sender and delete it from your mailbox or any other
> storage mechanism. Neither Macmillan Publishers Limited nor any of its
> agents accept liability for any statements made which are clearly the sender's
> own and not expressly made on behalf of Macmillan Publishers Limited or
> one of its agents.
> Please note that neither Macmillan Publishers Limited nor any of its agents
> accept any responsibility for viruses that may be contained in this e-mail or its
> attachments and it is your responsibility to scan the e-mail and attachments
> (if any). No contracts may be concluded on behalf of Macmillan Publishers
> Limited or its agents by means of e-mail communication. Macmillan
> Publishers Limited Registered in England and Wales with registered number
> 785998
> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
> **********************************************************
> **********************
> ________________________________
> 
> 
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1170 / Virus Database: 426/3315 - Release Date: 12/14/10