At 05:04 PM 6/16/2005 +0100, Dr Robert Sanderson wrote:
>>OK, that's good enough for me. Theo and Peter have independently run
>>into the same problem. I move that the "one endpoint, one database"
>>simplification that we made when designing SRW/U has proven itself an
>>_over_ simplification, and that we should fix the core protocol so
>>that it includes a way to specify a search in multiple databases, just
>>like Z39.50. Hacks with extensions and funny CQL indexes don't convey
>>the impression of a serious protocol.
>
>I disagree. The amount of complexity in Z39.50 for searching multiple
>databases at once was a serious impediment to implementation, and the same
>will apply to SRW. SRW is a protocol to search ONE database. If the
>metasearch environment want a protocol to search more than one database
>which extends SRW, then we should do our best to ensure that comes about,
>but we shouldn't make the protocol any more complicated at this stage.
I agree with Rob that the devil is in the details when it comes to
multi-database searching.. however, when the database providers DID talk
about their requirements to SRW, last year, the need to search multiple
databases was very explicitly mentioned. The most compelling reason to them
was that they felt they had more control if they received a bunch of
requests wrapped up in one package.
I haven't heard this requirement mentioned so strongly at the latest NISO
MI meeting, but I suspect it's still there. As a metasearch hacker, I'm
probably just as happy to launch individual searches because that gives me
much more control and feedback as things progress. I am rarely able to rely
on server-side merge/dedup functions, anyhow.
I believe that the editorial board has previously discussed a model in
which multiple SRW requests are bundled in one 'compound' request, which
would be an easy way to support individual queries to individual databases,
as well as individual error handling. This doesn't really affect the core
SRW service model.. it just wraps it in a repeatable structure.
--Sebastian
--
Sebastian Hammer, Index Data, www.indexdata.com
Direct phone: (603) 209-6853 Fax: (603) 357-1813
|