> Date: Fri, 5 Nov 2004 05:22:20 -0500
> From: Eliot Christian <[log in to unmask]>
>
>>> So, should the CQL context set list "dc.author" as an alias for
>>> "dc.creator"?
>>
>> This particular mistake may now be so widespread that we'd do
>> better to bend with the wind rather than breaking.
>
> I agree that it would be folly to emit an error message on receipt
> of "dc.author".
>
> Perhaps what we have here is a philosophical issue: Does a context
> set *reflect* the manner in which a community labels its indexes, or
> does a context set *dictate* the manner in which a community labels
> its indexes?
Well, I would argue that the context set should be created by the
community anyway, so the putative conflict between the community and
the context-set authors doesn't arise. Clearly only the community can
say what indexes it needs to search; it should then be encouraged to
write a context-set definition that provides one and only one way to
express each such search. Some communities may have very strong
reasons for violating this guideline, and I think the widespread abuse
of "author" in Dublin Core is a case in point. (I make this mistake
myself all the time: I made it, by implication, in a presentation on
CQL that I was writing only yesterday). But such exceptions should
_be_ exceptions, and I really don't think we should go about creating
aliases lightly.
> I am wondering about the rules on inheriting from one context set to
> another.
A clarification: there is NO "inheritance" of context sets. This
paradigm is a holdover from Z39.50 version 2, when all the attributes
in a Type-1 query had to be taken from the same attribute set, with
ugly results such as the GILS and CIMI sets both importing BIB-1
wholesale. But in Z39.50 version 3, and of course in SRW/U, there is
no such limitation: indexes from different context sets can be freely
mixed, so there should ideally be _no_ duplication of indexes between
context sets.
And now, on to your specific query:
> For instance, the index named "identifier" occurs in the Record
> Metadata http://srw.cheshire3.org/contextSets/rec/1.1/ as "A unique
> local identifier for the record within the current context". This
> is quite general and similar to Dublin Core, where it is defined as
> "An unambiguous reference to the resource within a given context."
Aha -- not quite! The Dublin Core identifier element is the
identifier of the resource you're describing, whereas the Rec set's
identifier is that of the record that's describing it. If this seems
like an esoteric distinction, then consider this example. I have a
database of records that describe books, each record contains a title,
author, ISBN and my own comments on the book. Each of my records also
has a local-ID field that identifies it with my database. Now you
would search ISBN with dc.identifier, and local-ID with
rec.identifier.
Hope that's helpful. For a slower, more patronising discussion of
this subject, I recommend my informal paper _One Man's Ceiling is
Another Man's Floor -- or -- Why your data may not be as meta as you
think it is_, which is available at
http://www.miketaylor.org.uk/tech/metadata.html
> So, should the practice be to have rec inherit this index from dc or
> should dc inherit from rec. (My sense is that DCMI insists on dc
> being the "uber set" and admits no supersets.)
Neither: in this case the issue doesn't arise because the two elements
really are different. But if a new application profile, say the
Fruitbat profile, needs to include record-identifier searching, then
the correct approach is not to have the Fruitbat context set "inherit"
the identifier index from the Rec set, but just to have the Fruitbat
profile say "we use fruitbat.wingNumber and rec.identifier". For a
fine example of how this should be done, see the in-progress GILS
attribute set, by ... er ... wait ... :-)
_/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "Shut up, be happy. The conveniences you demanded are now
mandatory" -- Jello Biafra.
--
Listen to free demos of soundtrack music for film, TV and radio
http://www.pipedreaming.org.uk/soundtrack/
|