On Mon, 3 Jan 2005, Hedzer Westra wrote:
>>>> So adlib.allIndexes will search all indexes in the adlib
>>>> context-set, yes?
>>> Yep, the adlib context set being all indexes defined for the
>>> configured database.
>> Errr, no. To clarify: The adlib context-set contains only the bits that
>> you would prefix with 'adlib.' in the CQL. So for example,
>> adlib.allIndexes would NOT search dc.title or net.host, but would
>> search adlib.foo and adlib.bar
> Ah. But how do I define it then, in a way that doesn't 'trample' CQL ?
What you're doing is just what cql.anywhere does -- any index which the
database knows about. Right?
> And another question: it's possible (and allowed) to map an index to
> more than one context set, right?
I don't understand the question?
> Then why won't you allow me to define the adlib context set as: all
> indexes the exported database knows (natively)? Seems valid CQL to me..
Because a context set is very much like a namespace in XML. You can't say
that <dc:title> is part of the EAD namespace any more than you can say
that dc.title is part of the CCG context set.
> If I may say so: CQL defines a lot of (fortunately optional) pretty
> esoteric stuff like word proximity searches and the prox operator, and
> is prepared for implementation dependent things like relation modifiers.
Esoteric perhaps, but absolutely essential in some disciplines. :)
> All of this leads me to the conclusion that CQL is supposed to be
> pluggable for any kind of search language, with it's own quirks.
Not really. It's supposed to be flexible, but for example, you'll have a
very hard time mapping everything that SQL can do into CQL, or RDF
searches for that matter, as CQL doesn't have any notion of relations
between searchClauses apart from the PROX operator.
The main point of CQL as opposed to most other languages is that it is
abstract. You don't search /ead/eadheader/titlestmt/titleproper, you
search dc.title. You don't search x.title where x is marcDataTable, you
search dc.title.
> But what happens when I file a profile in which I neatly define all
> these quirks?
You get a lot of comments as to how to improve it from [overly] helpful
CQL people =)
Here's the real reasons though:
You're one of the first non Z39.50 people to come to CQL and try to write
a profile and then come to the group for comments. Everything else that
has been linked from the main site has been done by one of us, so far.
That's not to say that you're the first to try it that we know of, but to
be perfectly honest, your first attempt was still MILES better than some
others, and what we're doing now is *improving* rather than *correcting*.
Secondly, we want the first context sets and profiles to be as correct as
possible. Because as was found with Z39.50, it doesn't really matter what
the specification document says if nobody implements it like that for
whatever reasons. If the first big SRW/CQL implementations are simply
bad, then it'll be much much harder to keep the standard on track, so we
have a large large interest in ensuring things are correct first time.
Hope this helps soften the critique.
A happy new year to you too :)
Rob
,'/:. Dr Robert Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. 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
|