> Date: Fri, 19 Nov 2004 11:43:59 +0000
> From: Dr Robert Sanderson <[log in to unmask]>
>
> > But that doesn't give you ability to express the fact that your
> > manuscript-submission date is a special form of date, in the neat
> > attribute-architecture BIB-2 way.
>
> It would only make sense to me to do this if the components are
> generally reusable, in the iso11179 sense.

Of course.

> Which means that we would just be formalising the CQL naming system
> into the query language, rather than as an implementation guideline.

No; it's better for two reasons.

One is that we don't pollute the namespace, because we have a+b+c+d
indexes and index modifiers (where a, b, and c are the numbers of
modifiers available on each of three putative orthogonal semantic
axes) rather then a*b*c*d index-names.

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.  Classic
example: metasearcher broadcasts a search for Bath title "dinosaur",
and I only have Dublin Core data.  At present the server just sees one
opaque string, "bath.title", that doesn't match another opaque string,
"dc.title", and has to throw an error.  If index modifiers were used,
it would see the index-name "dc.title/bath.title" and _know_ that it's
a refinement on DC title.

Of course, such information could be abused.  Don't Do That Then.

> 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

> 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

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.
        dc.title/type=heraldry = baron
or
        dc.title/type = heraldry        # "= baron" is left over
That ambiguity can't be resolved without either multi-token lookahead
or context-sensitivity (the interpretation of the relation being
determined by which particular index-modifier name is used).  And both
of these are intolerable implementation burdens.

Conclusion: I still think index modifiers are a cute thing, but
implementation considerations neuter them by denying them the ability
to take values; so on pragmatic grounds I withdraw the proposal, and
redirect my attention to considering whether Eliot's problems can best
be solved using relation modifiers.

 _/|_    _______________________________________________________________
/o ) \/  Mike Taylor  <[log in to unmask]>  http://www.miketaylor.org.uk
)_v__/\  "But I remember ...  Three lions on the shirts; Jules Rimet
         still gleaming" -- Skinner, Baddiel & Broudie, "Football's
         Coming Home"

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