RE: A further role for queryn: Leading and trailing booleans

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

In practice will we mix different Booleans in queries of this form (as opposed to all the terms being and-ed or all the terms being or-ed) since we don't have any brackets?

I know that in practice it is quite easy to create a form which allows you to specify three terms and the intervening two Booleans,

But given the query A and B or C, to the naïve use this may be ambiguous - is it

(A and B) or C 

Or

A and (B or C)

Now, I know that there is a preference order, so that in reality there is no real ambiguity. However, I must confess to being a little rusty, so *I* don't actually know which is the correct one which going and looking it up - on which basis I suspect the casual user wouldn't know either.

Matthew







> -----Original Message-----
> From: Hammond, Tony [mailto:t.hammond@nature.com]
> Sent: 20 December 2010 08:55
> To: Hammond, Tony; LeVan,Ralph; Ray Denenberg, Library of Congress;
> Matthew Dovey; OASIS SWS TC
> Subject: A further role for queryn: Leading and trailing booleans
> 
> Hi:
> 
> Following the feedback about the possibiltiy of missing fields for empty
> values, I do think there is a role for the queryn parameter to signal the
> number iof serach clauses. It is already known at form create time so why not
> share that information with the processor?
> 
> But now I've found a second role for queryn.
> 
> One thing that has bothered me is the placement of booleans. In a simple
> form table they must necessarily be placed fore (leading) or aft (trailing) of
> the search clause. This leads to two problems: 1) there is choice to be made
> between leading or trailing order, and 2) there is a redundant boolean
> (leading or trailing depending on order).
> 
> In the proposal to date (which also follows the explinResponse.xsl stylesheet
> as distributed with oclcsrw - and which we use), the booleans are taken to be
> trailing. Other forms I have seen present the booleans in leading order. I
> suggest we can support both presentations.
> 
> If we allow queryn to be a *signed* integer, then we could have the
> processing rule that for positive integers treat the booleans as trailing (as to
> date), or for negative integers treat the booleans as leading. To show this by
> way of an example (and here I am using the qirt_ shorthand to stand for qi_,
> qr_, qt_, i.e. a complete search clause):
> 
> // trailing booleans
> queryn = 3
> qirt1 qb1 qirt2 qb2 qirt3 [qb3]
> 
> // leading booleans
> queryn = -3
> [qb1] qirt1 qb2 qirt2 qb3 qirt3
> 
> The boolean in brackets ("[]") is redundant and needs to be dropped in the
> processing.
> 
> In fact, this is no real big deal to implement. In the JavaScript below theere is
> an "if (signed)" test which handles both cases:
> 
>       form = document.form;
>       signed = form["queryn"].value;
>       queryn = Math.abs(signed);
>       cql = "";
>       prevn = 0;
>       for (var n = 1; n <= queryn; n++) {
>         indx = form["qi" + n].value;
>         reln = form["qr" + n].value;
>         term = form["qt" + n].value;
>         if (term) {
>           if (n > 1) {
>             var bool;
>             if (signed > 0) {
>               bool = form["qb" + prevn].value;
>             }
>             else {
>               bool = form["qb" + n].value;
>             }
>             cql += " " + bool + " ";
>           }
>           cql += indx + " " + reln + " " + term;
>           prevn = n;
>         }
>       }
> 
> Seems to me that this would be a very useful generalization - and possibly
> also something of a reprieve for queryn. :)
> 
> I am easy as to whether +/- signals trailing/leading (as used to date) or
> leading/trailing.
> 
> Tony
> 
> 
> **********************************************************
> **********************
> 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
> **********************************************************
> **********************