Robert Sanderson wrote:
>>>>What are people afraid of? Is it difficult to implement? Difficult to
>>>>understand? Difficult to describe?
>>>>
>>>>
>>>Yes to all of the above.
>>>
>>>
>
>
>
>>>dc.title = ( dc.author = fish )
>>>I see no reason to make that legal as dc.title is just a waste of time,
>>>making the query less readable for no gain.
>>>
>>>
>
>
>
>>You don't like the notion of default index. I see.
>>
>>
>
>If it's a protocol language: The few bytes saved are not worth the
> expense.
>
>
Agreed, except that wasn't the argument. The argument for having it is
to be able to offer a _subset_ of a CQL query to a mere user. The user
is able to enter his/her own query in a text field, but if he/she
doesn't explicitly enter a field themselves there is no way to direct
them to a _default_ index.
Without a default index you'll have to go through each term in the query
and add index/relation where omitted, skip booleans, other reserved
words.. It is extra work for the implementor that CQL could solve so
elegantly.
>If it's not a protocol language: The human readablity/understandability
> expense is not worth it either.
>
>
>
>
>>>dc.title = (fish or cat)
>>>
>>>
>
>
>
>>>I see no reason to make that legal either, as we can do:
>>> dc.title any "fish cat"
>>>and have the same result for no gain.
>>>
>>>
>
>
>
>> dc.title = title no cat
>>then..
>>
>>
>
>'not' can't be expressed in a single relation, correct, but the other
>three booleans can. Gain is very very small. The same style of argument
>applies to a unary not operator, which we also don't have.
>(not title = cat)
>
>
Well well you can't express
dc.title = (a and b) or c
either.
>To express (not title = cat), we need to fall back to ridiculous
>expressions like:
> myset.matchesEverything=1 not title = cat
>
>Unary not: a) is understandable b) is simple and intuitive c) adds to the
>expressive power of the language as a whole.
>
>
I didn't mean to start a discussion of unary not, really.
>But we don't have it. I put forwards that Unary not is a better candidate
>for inclusion than CQL structured search terms. I'm not saying we should
>have it, I'm saying that we've rejected it /and/ it's a better candidate
>for inclusion.
>
>
>
>>>dc.title = (dc.author any fish or cat)
>>>Is just ugly. Is cat searched in author or title? Yes, I'm sure there's
>>>
>>>
>
>
>
>>I can't believe you don't know the scope of dc.author in the query
>>above. Does that mean you wouldn't whether 'cat' is author search below?
>> dc.author any fish or cat
>>If yes (you're in doubt), then words fail me.
>>
>>
>
>author scopes only its own searchClause, title scopes cat.
>
>
Thank you.
>My point was that just quickly looking at it, it's hard to see the right
>answer and would be much worse in a long query. For someone new, it's
>not obvious, especially as prefixes bind more tightly:
>
> >foo=baz foo.title = (>foo=bar foo.title = bar or foo.title = bar)
>
>Yes it's understandable, but complex for no real gain.
>
>
>
>>>readily apparent. To my partner (who's not technical at all, but
>>>understood Mike's CQL tutorial in one reading) it would be totally opaque.
>>>
>>>
>
>
>
>>I take it you partner didn't understand Mike's example
>>title = ((dinosaur and bird) or dinobird)
>>as well, then..
>>
>>
>
>I told her to ignore it as it's not official CQL, but she probably
>understood it. With no other indexes then it's understandable, it's when
>you add the new indexes, relation modifiers and such like that it becomes
>complicated.
>
>
The end-user doesn't have to understand the whole thing, but a user _may
enter Q in
p.freetext = Q
where Q is, say,
keyword and author=jensen
or
author=jensen and keyword
>
>
>
>>>It's harder to implement ...
>>>(you need to constantly check the type of 'term' when processing and
>>>resolve clauses/booleans/strings, rather than knowing they'll be strings.
>>>And then we need to decide the scope of term describing relation modifiers:
>>>
>>>
>
>
>
>>>dc.date any/iso.YYYYMMDD ( dc.author = "fish" and "20030224" )
>>>geo.location within/geo.box/geo.pointFormat ( ... )
>>>
>>>
>
>You agree, I take it?
>
>
Having indexes that could be overriden in a different scope didn't pose
a problem in our parser implementation.
>
>
>
>>>... harder to understand ...
>>>(try describing dc.title = dc.author = fish to someone who's not
>>>technically inclined, rather than dc.author = fish and seeing which they
>>>grasp)
>>>... and harder to describe ...
>>>
>>>
>
>
>
>>I'm sure Mike will give it a try! Again, the fact that some queries are
>>difficult to read is not an excuse for limiting the ease of use for
>>building end-user interfaces (which will collect information from
>>various entries and build resulting CQL queries).
>>
>>
>
>
>I don't buy it. Most interfaces will need some term processing or user
>education. Apart from index = (a not b), everything else can be expressed
>in a single searchClause anyway. Constructing queries is easier than
>understanding the rules, IMO! One right way to do things, not many.
>
>
searchClause? Typo. If you accept that a searchClause may follow an
index that's OK. In particular a searchClause may be a '(' cqlQuery ')'
so recursive - and powerful again.
I guess you mean term or searchTerm. That's not flexible.
>
>
>
>>>I don't mind if Indexdata's parsers implement it, but I am not going to
>>>try and describe why such queries should be legal to end users of CQL,
>>>who are supposed to be not technical people.
>>>
>>>
>
>
>
>>Which (again) puts us to the issue for CQL. I thought it was a protocol
>>language rather than an end-user language. It is a language that aim for
>>easy_implementation_ of end-user interfaces...
>>
>>
>
>I thought it was a protocol /and/ end user language:
>
>"CQL's goal is to combine the simplicity and intuitiveness of google
>searching with the expressive power of the Z39.50 Type-1 query."
>
>This is not simple, nor intuitive, nor does it add any expression
>which couldn't previously have been described. Unary Not would better fill
>all of these goals, but has been rejected in the past.
>
>
So, since "not" operator is not there, you think indexes shouldn't be
powerful and flexible. You can do better than that:)
-- Adam
>Rob
>
>--
> ,'/:. Dr Robert Sanderson ([log in to unmask])
> ,'-/::::. http://www.o-r-g.org/~azaroth/
> ,'--/::(@)::. Special Collections and Archives, extension 3142
>,'---/::::::::::. Nebmedes: http://nebmedes.o-r-g.org:8000/
>____/:::::::::::::.
>I L L U M I N A T I
>
>
>
|