OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [search-ws] queryn: A proposal for SRU to facilitate forms processing


Title: RE: [search-ws] queryn: A proposal for SRU to facilitate forms processing

Hi Ray:

> This seems completely counter to the protocol model that we know and love.

So, the question I am asking is:

    Given that web data entry is usually handled via forms with multiple controls which present the data in a URI querystring (or via a POST body) in a *distributed* fashion, is SRU correct to assume that the query will be always be pre-assembled into a single monolithic query?

This to my mind seems to indicate two possibilities:

    1. The CQL query is input as a single string by an IR expert. (Unlikely.)

    2. Postprocessing is required to assemble a CQL query. (Likely.)

The former situation harks back to pre-Web days when only certain privileged folks had access to information resources (or the knowledge to use them).

The latter situation can be handled either on the client with JavaScript, or more robustly on the server, or it could be translated directly to the backend query system bypassing CQL altogether.

Client or server postprocessing to assemble a CQL string is straightforward but not painless. A chore at best.

Conversely if CQL is bypassed altogether then what is the point of SRU? (I know there are practical benefits - diagnostics, for one - but the main prize has to be CQL.)

So, has SRU gone far enough in bringing Z39.50 semantics to the Web (as it is experienced by end users)? Or could the protocol accommodate (to some degree at least) distributed queries in querystrings?

Tony









-----Original Message-----
From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Tue 12/14/2010 8:03 PM
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  
****************************************************************************
****



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]