At 09:36 AM 8/30/2004, Ray wrote:
>I agree of course, but as there isn't anything that formally ties the DC
>index set to the DC schema, I'm trying to imagine how such a recommendation
>is to be formulated.
How about something like this:
Developers of context sets should be aware that searchable content will
be mapped to search indexes and then results will be mapped to a record
schema separately. This can lead to confusion in the case where an index
has the same name as a record schema element. For example, a server may
map the "dc.title" index to several MARC fields in a database yet map
the "dc.title" record schema element to only MARC field 245$a. Although
both mappings are sensible individually, the searcher would see result
records that may not have the searched words in the "dc.title" element.
The general recommendation, therefore, is that an index name be the
same as a record schema element name only if both are to be mapped to
the same content.
>Would it apply only to DC?
No, it is a general situation that will most often occur with indexes
that are re-used in multiple context sets.
> And then if in the future there is are similar
>pairs where an index set corresponds to a schema in the same manner, we
>issue a separate recommendation for each pair?
I hope the above statement addresses the general case.
>Or a more general recommendation to apply to all such pairs? In that case
>how do we assert this relationship?
It is my belief that the root problem with DC elements is that they try
at once to be abstract (as indexes) and concrete (as record schema elements).
Obviously, it is useful to have a small set of named concepts (title, author,
subject, date...) as abstract search access points to be inherited into
other context sets. I don't see why we should expect the DC set to serve