Without doing anything, multiple databases on a server can be considered
to form a single target. The actual originating
database/collection/source can be part of the metadata record
(dcterms:isPartOf).
I agree with Ray that is is not that complicated to add an additonal
parameter for specifying one or more collections inthe request. As long
as the result is a single response nobody has to change current SRU
implementations when this parameter is not supported, except the
multiple database content providers, that want to support this. The
restriction is that the query is the same for all databases, but I do
not think this is a very big restriction. Having the results of
different databases in a single <SearchRetrieveResponse> may be
considered as a restriction but when records are returned per database
it is not a big deal to have them sorted per database. In other words
the metasearch requirements can be fulfilled to a large extent without
making changes in the current protocol.
However, the thing that is still missing, is the ability to get the
number of records per database before actually retieving the records.
My proposal would be to allow for an optional response tag that may
contain the number of hits for different conditions in a more generic
way. Something like:
<srw:miscelaneous>
<srw:consitions>
<srw:numberOfHits>x</srw:numberOfHits>
<srw:queryCondition>dbname</srw:queryCondition>
<srw:queryValue>database_xyz</srw:queryValue>
</srw:consitions>
<srw:consitions>
<srw:numberOfHits>y</srw:numberOfHits>
<srw:queryCondition>dbname</srw:queryCondition>
<srw:queryValue>database_abc</srw:queryValue>
</srw:consitions>
</srw:miscelaneous>
Query condition does not only have to apply to the database or
collection but could be any catagory that a target may use for selecting
catagories and can be used very generic. The advantage of this concept
is that the target may split results in different categories
unsollicited and that the client - having to know the possible
conditions before - can offer valuable suggestions to the user. In case
of 0 hits this could be used for offering terms that are very much
alike.
My proposal is to introduce the above structure as optional in the
<SearchRetrieveResponse>. Clients that cannot handle this tag just
ignore it.
Theo
|