On Thu, Sep 2, 2010 at 2:00 PM, LeVan,Ralph <[log in to unmask]> wrote:
> Nope, nothing like that in our grammar.  The intent is that SRU is a
> machine interface and software can turn a user query like you propose
> into the CQL query.

Who's intent? That seems unnecessarily limiting to me. *IF* that
truly is the intent, I would suggest the LOC folks have some
misleading descriptions going on... from the web page,

"The design objective is that queries be human readable and writable,
and that the language be intuitive while maintaining the
expressiveness of more complex languages."

> However, there is an easier way to do what you want.
>
> title = sea and title any "fish or turtle"

A typo? Boolean clauses aren't allowed in an any relation are they?

> This does the same thing.  The "any" relation puts an implicit "OR"
> between the terms and the relation "all" puts an implicit "AND" between
> the terms.

Yeah, I get the any and all, they're nice. When there are many of
them with only two terms though, and the need for prox's and not's
mixed in, that's not the cleanest solution. Supporting a construct
where an index+relation get projected upon a clause seems like a
no-brainer for the next version to me.

--tim

> Hope this helps!
>
> Ralph
>
>> -----Original Message-----
>> From: SRU (Search and Retrieve Via URL) Implementors
>> [mailto:[log in to unmask]] On Behalf Of Tim Williams
>> Sent: Thursday, September 02, 2010 1:12 PM
>> To: [log in to unmask]
>> Subject: Boolean search within an index
>>
>> I have this need to support complex boolean queries within a field.
>> I'd like to not have to repeat the 'index relation' over and over
>> within the statement.  Rather, I'd like something like
>>
>>    title = ((fish OR turtle) AND sea) - though, much more complex -
>> and don't want to have to write:
>>
>>   ((title = fish OR title = turtle) AND title = sea)
>>
>> Logically, it's just projecting the index and relation upon the
>> enclosed terms.  Before we depart from the CQL spec I thought I'd see
>> if there was a way to get similar 'shortcutting' using build-in
>> extension mechanisms?
>>
>> Thanks,
>> --tim
>