> Date: Thu, 18 Nov 2004 17:08:24 +0000
> From: Dr Robert Sanderson <[log in to unmask]>
>
>>> I think that the Referent Object in the 11179 CQL naming system makes it
>>> redundant.
>>
>> ... but at the expense of doubling or tripling the number of indexes.
>
> Yes.  However, we're unlikely to run out of them :)

:-)

Still, though ...

> > I think we are _very_ close to reinventing semantic/functional
> > qualifiers.
>
> I think we already have, they're just not so confusing and more
> generally applicable.  They're just relation modifiers in CQL, but
> you can name them what you want, and don't have to spend half an
> hour figuring out if it's a semantic distinction or a functional
> distinction.

Hmm.  Sort of.  I agree that most of the while it is nice that a
modifier is just a modifier, and you don't have to think about whether
it's semantic or functional.  There _is_ a real difference, but for
those context sets that need to observe it, they can just go ahead and
do so using modifier-naming conventions.  So that's all good.

What's not so good is that we are now overloading relation modifiers
to modify relations, the structure of the associated term _and_ the
index.  As in:
        dc.date =/mike.dateIsManuscriptSubmissionDate/fuzzy/iso.date 2003-02
Doesn't that make your skin crawl a bit?

The obvious answer would be legitimate index modifiers:
        dc.date/manuscriptSubmission =/fuzzy/iso.date 2003-02

I don't recall that we've ever seriously considered doing this.  Have
we, and I missed it?  Or is there a good reason why it won't do?  I
think it's syntactically unambiguous, given the specialness of "/".

 _/|_    _______________________________________________________________
/o ) \/  Mike Taylor  <[log in to unmask]>  http://www.miketaylor.org.uk
)_v__/\  It's hard to retro-fit correctness.

--
Listen to free demos of soundtrack music for film, TV and radio
        http://www.pipedreaming.org.uk/soundtrack/