OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [search-ws] Groups - Contextual Query Language (cql-first-draft-april-6-2009.doc) uploaded


76: " The empty search term [example d] has no defined semantics."

So CQL does not define a query like a <> "" to retrieve all non-empty  
strings? If so, I find that an unnecessary restriction (and line 299  
suggests you did too, so the statement here is too broad.) True,  
whitespace is a problem, but it's a problem that can be defined. It's  
problematic to allow an empty search term without an index or  
relation; but the answer to that is to ban the empty search term from  
occurring without quotes (or at most, without an index and relation).

56: Context sets are repeatedly mentioned in the document, but are not  
introduced until line 193. This is confusing, and I don't see why 2.3  
can't move as is to the start of the document.

86: "If multiple '.' characters are present, then the first should be  
treated as the prefix/base name delimiter". This means that a context  
set name cannot start with a dot?

87: "If the prefix is not supplied, it is determined by the server".  
Say explicitly it is cql.anyIndexes. Why is there a distinction  
between cql.anyIndexes and cql.serverChoice?

131: "the prox operator is". Sentence incomplete. (I'm not really  
surprised... :-) Forward reference to 2.1.9?

149: "Within the CQL set they [proximity terms] are explicitly  
undefined, subject to interpretation by the server." How can I find  
out how the server has chosen to interpret them? I find the refusal to  
define their behaviour a concern. People will make the obvious  
orthographically-based assumptions about the meaning of word,  
sentence, paragraph, and will not be happy if that is not what's  
implemented. Obviously what counts as a word depends on locale, but  
locale settings telling you what a word is already exist, and they are  
what CQL should refer to. (Locale is already assumed, after all, in  
the definition of sort.)

BNF: comparator, not comparitor

199: "Context sets permit CQL users to create their own indexes,  
relations, relation modifiers and boolean modifiers". Sort modifiers  
too.

200: "and there are rules to determine the prevailing default set is  
not supplied". if it is not supplied.

203: "When defining a new context set, it is necessary to provide a  
description of the semantics of each item within it". No minimum  
requirements for this description are provided.

207: "Each context set has a unique identifier, a URI". Not  
necessarily an HTTP URI. You should introduce the info-uri schema here.

208: "When sending the context set in a query, a short form, or  
nickname, is used". These have already been called prefixes above, and  
should still be to avoid confusion. (The connection is only made in  
the next paragraph.)

234: "cql.resultSetId = "a" AND cql.resultSetId = "b" " I'm surprised  
this works, since the instance of the record is unique to a result  
set. Does the wording of the response set data model explicitly  
license such result set manipulation?

244: "allIndexes". Remind readers that this is not equivalent to a  
full text search.

258: "keywords". Note that the search terms in the keywords index need  
not be present in any other defined index. (Are they still included in  
cql.allIndexes? Presumably yes.)

271. "=". How can I find out how a server has implemented "="?

284. "==". Remind readers that CQL does not strip whitespace, so the  
index better had.

301. "<" etc. I would insert a textual comparison example, since  
textual comparisons are defined (subject to the locale), and  
comparisons are not limited to numbers.

311. "adj". You've dodged any mention of word delimiters in the  
adjacency definition, but clearly adjacency is meaningless without the  
notion of a delimiter. The delimiter, again, is determined by the  
locale.

314. "The query could also be expressed using the PROX boolean  
operator". By a sequence of PROX queries, one for each adjacent pair.

323. "These relations [all, any] have an implicit relation modifier of  
'cql.word', which may be changed by use of alternative relation  
modifiers.". That presumably also holds for "adj".

334. "Within may be used with a search term that has multiple  
dimensions". You haven't said how dimensions are specified; the  
examples use space delimiters, but more geometrical applications might  
use commas. It would be better to fix space as the default delimiter  
here, since that's what people will implement by example, and giving  
such a default would help syntactic interoperability, as is your  
avowed aim.

352. "stem". Being the same stem is different from being the same  
lemma, and often lemma is what you actually want (e.g. "computer" and  
"computers" but not "computing".) I'd make the distinction here ---  
especially for languages not as morphology-poor as English.

362. "partial". Word fragments could also usefully be searched in  
normal searches.

375. "locale=value". Rather than giving illustrative examples, say  
that locales are used as understood under Unix, and refer to a more  
canonical listing (in whatever gizzards of BSD or Java that might  
reside). It'd be nice if you could move away from "C" as a locale and  
just used ISO, but that's a big ask....

412. A more useful illustration of string searches would be one that  
includes spaces or punctuation.

495. "container=field" sits clumsily with how indexes are normally  
defined. Is a query like "author = jack prox author = jones" well- 
defined? Is "author = jack prox title = jones"? (It shouldn't be.) Is  
"author = jack prox/container=title author = jones"? (Again it  
shouldn't be).

I've asked Ray to forward my comments on the bib context set to the  
ZNG list where they were first posted, but I'll post them here too  
separately.





On 08/04/2009, at 06:20, rden@loc.gov wrote:

> For discussion at next Monday's call, April 13.
>
> -- Ray Denenberg
>
> The document named Contextual Query Language
> (cql-first-draft-april-6-2009.doc) has been submitted by Ray  
> Denenberg to
> the OASIS Search Web Services TC document repository.
>
> Document Description:
>
>
> View Document Details:
> http://www.oasis-open.org/committees/document.php?document_id=31986
>
> Download Document:
> http://www.oasis-open.org/committees/download.php/31986/cql-first-draft-april-6-2009.doc
>
>
> PLEASE NOTE:  If the above links do not work for you, your email  
> application
> may be breaking the link into two pieces.  You may be able to copy  
> and paste
> the entire link address into the address field of your web browser.
>
> -OASIS Open Administration
>

---
      DR NICK NICHOLAS.                opoudjis@optushome.com.au
  LINK AFFILIATES, MELBOURNE                skype:opoudjis
In Athens, news spreads fast: they know everything as soon as it  
happens,
sometimes before it happens, and often without it happening at all.
--- Jean Psichari, _My Voyage_.        http://www.opoudjis.net




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]