>>>> [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
associated
>> > > with it and must be distinguished from the query."
>
>> engines. They would vastly prefer a model where the metasearch
engine
>> (gateway) is able to bundle such requests together so they can
optimize it
>> adequately.
>
>Ahha.
>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
one.
>
>I almost agree with their solution, but not quite. I'd prefer
something
>like:
>
><multipleSearchRetrieveRequest>
> <singleSearchRetrieveRequest>
> <resource>/foo/</resource>
> <searchRetrieveRequest>
> <query>...
> <singleSearchRetrieveRequest>
> <resource>http://srw.o-r-g.org/l5r/</resource>
> <searchRetrieveRequest>
> <query>...
>
><multipleSearchRetrieveResponse>
> ...
>
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
servers
>that don't need to/can't optimise will just step through the requests
as
>if it had received them individually.
>
>A bit more verbose, but it doesn't use attributes and is easy to farm
out.
>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
searchRetrieveRequest,
>it just adds another service to handle the multipleSRR element.
>
>> > > There was also a desire for more result-set and record
metadata.
>> >Were any specifics given?
>> Yes, the big wish was basically for more "branding", primarily in
the form
>> of links back to the information provider... they (perhaps
justifiably)
>
>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>
tag.
>Which I blushingly admit isn't documented on the site, but is in the
DTD
>for just that reason.
>
>
>> their database, and they would like to see metasearch vendors
provide links
>> to their native interface for individual records as well as for
result
>
>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
display.
>Sounds reasonable.
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
record.
Theo
|