I agree, but the solution is that when not specifying the dc. prefix, it
is up to the server to choose an index. So when you specify "title" it
is up to the server to use this as bath.title or dc.title or both. This
is part of the SRU specs but - when it does not lead to ambiguity - the
support of this feature should be encouraged.
>>> [log in to unmask] 26-8-04 22:55:08 >>>
At 06:02 AM 8/26/2004, Robert Sanderson wrote:
>>I tried using the index "dc.title" with record schema "dc".
>>But, I get disconcerting results--most of the retrieved
>>records do not have my search term value in the XML element
>>called "dc.title". On the surface, this looks badly broken.
>When I was playing (remotely) with the new Aleph server at the BL, I
>search for title all "xml language" and got back a record that had
>word anywhere, let alone in the title.
>The perils of data transformation is that information gets lost or
Perhaps so, but in my example at LoC the server behaves correctly
according to the standard, yet the results are counter-intuitive.
This is an issue for the standard, not merely an implementation.
>[...] the issue is more that if you're mapping a field to a
>dc index, then it should also be mapped to the same dc schema
>element as they do have the same semantics.
OK, then it follows that one should NOT use dc elements as
generalized search access points. The notion of inheriting
"existing" elements doe not make sense if such elements are
also associated with a particular record schema.
Yet, we still need abstract search access points for
the (quite common) case when the searching client is
unfamiliar with what kind of items are in the collection.
It seems to me that CQL can define a small set of such
abstract concepts, perhaps ten or so in addition to
"anywhere" (ISO 11179 suggests concepts like "name", "person",
"organization", "location", "identifier", "category"...)