On Jul 31, 2006, at 9:58 AM, Robert Sanderson wrote:

>>> I'm going to flipflop and prefer '==' to 'eq' now, because I don't
>>> think that the disadvantage of == is real :)
>
>> query language construct. If the query language can capture 80 of the
>> cases with the "basic" relational operations, uniary flags and
>> boolean operators used is query languages today, why dirty it up with
>> more complexity, If folks are going to adopt the technology, the
>> learning curve and simplicity are key to its success and popularity.
>
> I don't buy this argument.  If we wanted to use SQL, we'd just SQL.
> Secondly, SQL is not what I would describe as simple or having a  
> shallow
> learning curve. XQuery is in another league in terms of complexity.
> And both are syntactic, not semantic/contextual.  That aside...
>

But the equivalency relations I point out from XPath 2.0 before "are  
simple" use "eq" for exact and and "=" for contains, this applies for  
"ne" and "!=" as well. Yes the context is slightly different but I  
would highly recommend  this strategy of "latter based" vs "symbol  
based" to classify these two sets of relations. Thats all...

>
> The simple fact is that CQL needs an equality relation.  Given that
> there is the strong desire (to make the learning curve shallower)  to
> make word queries do the right thing using '=', it cannot be '='.
>
> eg:  dc.title = "fellowship of the ring"
> should *not* do an exact equality search for that string.
>

I think I'm being misinterpreted because I wasn't being clear enough.  
I wasn't really suggesting what you state here.


> however dc.identifier = "http://foo.org/foo/1.2/1" and some.number
> = 6 should both perform exact equality searches, the first string and
> the second numeric.  With these requirements, '=' must be the 'do the
> right thing' relation.

Well, implementations like Lucene also factor in index field "type"  
that effect how relations are handled. dc.date=2006/12/31 (dc:date  
being of type date) while ds.description=2006/12/31 are two very  
different searches depending on how the fields are defined in Lucene.


>
> The main options for what the equality relation is to be called are
> currently:
>   'eq', 'is', '=='
>
> None of which are relations with the same semantics in other query
> languages, to my knowledge.

Sorry, I probably abused the word semantics. I just prefer the XPath  
approach to classifying equivalency relations, thats all.


Mark R. Diggory
~~~~~~~~~~~~~
DSpace Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology