>> - The meta-index cql.anywhere searches all indexes defined in the
>> Adlib database at once. It does not search all indexes in all
>> context sets, as the CQL context set suggests. This might be a slow
>> search if there are a lot of indexes.
> It is at best inadvisable, and probably just wrong, to _re_define the
> meaning of an existing index like this -- especially such a core one.
I think that's exactly what cql.anywhere means. Search all indexes that
you know about, but you can't be expected to search indexes that you don't
Which is (thankfully, for once) exactly how it's defined:
This means "search all indexes from all context sets you know".
>> - The adlib.record meta-index searches the whole record. The
>> operator doesn't matter. This is a slow search since no index can
>> be used.
> Perhaps we should consider adding cql.record for whole-record
> searching (where supported).
I'm not sure what exactly happens here. Is it:
(a) You send some terms and it searches the entire record. (And how is
this different to cql.anywhere in practice?)
(b) You send the entire record as a term, and it returns the entire
record back to you if it finds it. (seems ... odd)
> You can't really say "the operator doesn't matter" as this is
> overriding established semantics of CQL and the CQL context set. It
> would be much better to say "the operator must be '=': all others will
> be rejected".
> (And by the way, it is conventional in CQL to talk of "relations"
> rather then "operators". Unless you have a compelling reason, you
> should probably stick to this convention.)
> There really should be a thesaurus-use context set defined outside of
> Adlib, for use in this and other profiles (or the relevant elements
> should be added to the existing Zthes context set). We actually
> started this process a month or two back, but got sidetracks -- or
> maybe mired in excess complexity.
>> - The 'encloses' and 'within' operators are implemented using the
>> Adlib WHEN operator. Some examples:
>> 'term encloses "2000 2004"' translates to 'term >= 2000 WHEN term
>> <= 2004'
>> 'term within "2001 2005"' translates to 'term > 2001 WHEN term <
Here are some uses for within and enclose:
dc.date within "2000 2004"
-> Does the record contain a date between (inclusive) 2000 and 2004
foo.rangeOfDates encloses 2002
-> Does 2002 fall within (inclusive) the date range in the record.
would match the within query.
would match the encloses query.
(Hopefully this is how your internal queries work)
>> These two indexes can be be reflected using two separate CQL
>> indexes. It is not possible to use modifiers to switch from one to
>> the other.
> Why not? It seems an eminently sensible way of expressing the
Yep. This is, for example, how title is commonly implemented.
> No, we all agreed that "exact" does _not_ imply unmasked.
But it does imply anchored.
>> + operator '=': implied modifiers are cql.masked and either cql.word
>> or cql.string, depending on the index type. This cannot be seen
>> in the explain information but must be described in a profile.
> This is _not_ what "=" means in CQL. It means that the term is
> word-structured, irrespective of the index being searched, unless
> overridden by a relation modifier.
I disagree, Mike. It means, currently, exact equality, but does not say
how equality is to be determined.
Unless the term is a list (which may be a singleton) of words.
>> + adlib.record meta-index: implied operators are cql.string and
> There is nothing in CQL that allows you to infer different
> term-structure and masking semantics from an index name.
So you have to treat dc.date = "2004-12-25" as a word? or a string?
Sure you can do this.
,'/:. Dr Robert Sanderson ([log in to unmask])
,'--/::(@)::. Dept. of Computer Science, Room 805
,'---/::::::::::. University of Liverpool
____/:::::::::::::. L5R Shop: http://www.cardsnotwords.com/
I L L U M I N A T I