>>>> [log in to unmask] 05/23 2:17 nm >>>
>> > > searching multiple databases has been dropped . . . if the
>> > > each one has revenue and royalty related business rules
>> > > with it and must be distinguished from the query."
>> engines. They would vastly prefer a model where the metasearch
>> (gateway) is able to bundle such requests together so they can
>Yep, having now read the paper, I see the issue. Depending on the
>backend, it would be possible to do less work than (query *
>databases) if you knew that the client wanted it applied to more than
>I almost agree with their solution, but not quite. I'd prefer
In which cases is there a need to send =different= queries to different
databases on the same system simulateously? I can imagine a single query
is broadcasted simultaneously.
>Then we could simply put existing messages inside a wrapper, and
>that don't need to/can't optimise will just step through the requests
>if it had received them individually.
>A bit more verbose, but it doesn't use attributes and is easy to farm
>Also, if database were a full URL as in the second instance, it would
>provide a mechanism for SRW<->SRW gateways, something that I vaguely
>recall Adam discussing the current impossibility of a while ago.
>It also doesn't change the existing definition of
>it just adds another service to handle the multipleSRR element.
>> > > There was also a desire for more result-set and record
>> >Were any specifics given?
>> Yes, the big wish was basically for more "branding", primarily in
>> of links back to the information provider... they (perhaps
>These are per database, rather than per record? In which case they
>belong in ZeeRex, and we have scope for them already with the <link>
>Which I blushingly admit isn't documented on the site, but is in the
>for just that reason.
>> their database, and they would like to see metasearch vendors
>> to their native interface for individual records as well as for
>So a field which allows you to point at other ways to get to the same
>digital object, regardless of the schema that's requested for the
I would prefer to let such a field be part of the record metadata
rather than part the SRW/SRU parameters. Data providers can decide for
themselves to put this link in their records. In The European Library
metadata registry we defined a term for the link to the original