On Mon, 30 Sep 2002, Alan Kent wrote:
> On Fri, Sep 27, 2002 at 11:01:07AM -0400, LeVan,Ralph wrote:

> > I believe we still need first-in-field and last-in-field indicators.  I
> > still like the caret ('^') and dollar-sign as new special characters at the
> > beginning of words to do that.
> If these operators map on to attributes, I would prefer to keep them
> out of the string literals. That is, I believe '^' will map on to
> the first-in-field attribute, not be included in the actual term.
> My preference is to keep the text in the string literals exactly what is
> sent to the server - no local processing required. If this is desirable,
> then can anchors be turned into modifiers too? lanc/leftanchored/first/start,
> ranc/rightanchored/last/end, lranc, etc. Or else something outside the
> string literal?

Designing CQL such that it maps onto attributes rather than being easy to
understand and construct is counter productive IMO.  In the Z39.50 world
we already have the converts and are unlikely to gain too many more until
SRW becomes mainstream and they -have- to. If you can demonstrate how this
is intuitive or useful -without- relying on making it easier to map to
Z39.50, I'd be more convinced.  The same applies to the 'modifier'
suggestion, IMO.

> Also, Robert Sanderson wrote:
> > how is
> >    indexset.index:token = "term"
> > any less extensable than:
> >    indexset.index token "term"
>
> Its not a silly idea at all. In fact, if you remove the ':' character
> and allow words or a set of symbols as modifiers, then '=' just becomes
> the attribute 'equals'. Most servers would default to this anyway
> (or has it changed in AA?) It means queries could be written as
>
>     dc.title stem = "hi there"
> or
>     dc.title stem "hi there"

Right. Or if there's no 'stem' it would just be '=' But my point is that
the modifier and the relation together are irrelevant ...  there's no
case when you would want more than one of the two. (At least that I can
think of, and no one has yet to provide a case on the list to my
knowledge)

If the GEO folk want to define <=> as an operator for within, then all
power to them and we should allow it as a valid operator. But I reiterate
my question:

What facility does the index:modifier relation "term" construction allow
us that the current construction without the modifier does not?

> Someone else asked what does the following mean?
>     dc.title relevance > "a"

That was me too :)

> I have no idea. But is it necessary in the grammar to disallow such
> constructs? The idea is to have a general way to form attribute lists.

Preferably.  The tighter the grammar, the easier it is to write parsers
against it and the easier it is to construct well formed queries in it
from user input.

See also Ralph's desire to have Explain/ZeeRex as tight as possible to
allow for validation. Especially as we have XCQL the same applies here.

> ps: Putting parenthesis around everything is pretty ugly in my opinion
> too, and quite unusual for such grammars - unless you like Lisp.

Parentheses only go around -boolean- operators.

eg:

(title = "dublin" and title = "core)

not
((title = "dublin") and (title = "core"))


Rob

--
      ,'/:.          Rob Sanderson ([log in to unmask])
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Twin Cathedrals:  telnet: liverpool.o-r-g.org 7777
____/:::::::::::::.              WWW:  http://liverpool.o-r-g.org:8000/
I L L U M I N A T I