> 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
>> ... 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
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