On Fri, 19 Nov 2004, Mike Taylor wrote:
>> Which means that we would just be formalising the CQL naming system
>> into the query language, rather than as an implementation guideline.

> One is that we don't pollute the namespace, because we have a+b+c+d
> axes) rather then a*b*c*d index-names.

Sure, but no one -needs- to know all a*b*c*d indexes, just the ones that
their community/profile has prescribed.


> The second is that, because the refinements are visible at the CQL
> language level rather than only within the opaque string that is index
> name, implementations can do clever things with them.

This is the advantage of the proposal, IMO.


>> So you'd end up with:
>>
>> rec.record/xd.creation/xd.agent/cql.name
>> instead of rec.recordCreationAgentName

> No.  In this case, the modifiers are not modifying, but completely
> changing.  What would a search on (unmodified) "rec.record" mean?  The
> example is a straw horse.  A more realistic one would be
>        date/creation

No, I just got it back to front:

cql.name/xd.agent/xd.creation/rec.record

name
name of an agent
name of an agent that created something
name of an agent that created the record

You could also have

dc.date/xd.creation/rec.record

Date of the creation of the record.

But how is that different to:

dc.date/dc.creator/rec.record

?

>> It further exacerbates Eliot's problem of wanting to support aliases
>> based on existing usage.
>
> Au contraire.  It _solves_ Eliot's problem, because he can use
> dc.creator (enhancing interoperability) while at the same time making
> explicit that he is using "screator" in the specific and somewhat
> different sense that GILS means it.
>        dc.creator/gils.creator = azaroth

I thought the problem was more that GILS already has 'record-source'
whereas we want to call it something different.


> However.  There is a problem with syntax.  Putative index modifiers
> could not take values as relation modifiers and boolean modifiers can,
> because the relation that introduces the value would be ambiguous with
> the relation attaching the modified index to the query term.  e.g.

True.

> Conclusion: I still think index modifiers are a cute thing, but
> implementation considerations neuter them by denying them the ability
> to take values;

None of the examples so far have required values.  And indeed anything
that does require a value can simply be enumerated.  So I don't think that
this is an insurmountable issue.

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