[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws] RE: A further role for queryn: Leading and trailing booleans
No, the server can't figure it out if there is the potential for omitted parms and unintentionally provided parms (Booleans, indexes and relations without terms).
The server gets qt2=cat qb2=and qt3=dog qb3=or
How does the server know if an AND or an OR is being requested? Was that Boolean provided for term2 supposed to apply to the omitted term 1 or to the provided term 2? Was the Boolean provided with term 3 supposed to apply to term 2 or to the omitted term 4?
Ralph
> -----Original Message-----
> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> Sent: Monday, December 20, 2010 2:39 PM
> To: 'Matthew Dovey'; Hammond,Tony; LeVan,Ralph; 'OASIS SWS TC'
> Subject: RE: [search-ws] RE: A further role for queryn: Leading and trailing
> booleans
>
> Boolean operators evaluate left to right so
> A AND B OR C
> is equivalent to
> (A AND B) OR C
>
> The issue Tony raises is that forms systems represent Booleans by appending
> the Boolean onto the search clause, where in some cases the Boolean
> precedes
> the search clause, and in other cases follows it.
>
> So if it is supposed to precede the search clause, A AND B OR C
> would be represented as:
>
> 1. search clause A;
> 2. search clause B; Boolean AND
> 3. search clause C; Boolean OR
>
>
> if the boolean is suppose to follow the search clause, it would be
> represented as
>
> 1. search clause A; Boolean AND
> 2. search clause B; Boolean OR
> 3. search clause C;
>
> In general, for preceding booleans, the first clause omits the Boolean; for
> following Booleans the last clause omits the Boolean.
>
> However, in both cases the search can be completely reconstructed and they
> are equivalent, aren't they? So why does the request need to signal whether
> it's preceding or following Booean? The server can figure that out for
> itself.
>
> -Ray
>
> > -----Original Message-----
> > From: Matthew Dovey [mailto:m.dovey@jisc.ac.uk]
> > Sent: Monday, December 20, 2010 11:33 AM
> > To: Hammond, Tony; LeVan,Ralph; Denenberg, Ray; OASIS SWS TC
> > Subject: [search-ws] RE: A further role for queryn: Leading and
> > trailing booleans
> >
> > 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
> > > **********************************************************
> > > **********************
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]