> >I almost agree with their solution, but not quite. I'd prefer
> ><multipleSearchRetrieveRequest>
> > <singleSearchRetrieveRequest>
> > <resource>/foo/</resource>
> > <searchRetrieveRequest>
> > <query>...
> 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.
Yes. For example, if one database has to be searched using dc.foo and a
second database has to be searched using bath.foo.
Perhaps one database has subject fields, but another you have to rely on
a free text search of 'topic' or 'description'.
Perhaps:
<resources>
<resource>/foo</resource>
<resource>/bar</resource>
</resources>
If people are concerned that we might end up repeating the identical query
many times.
> >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
> >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
Yes :) Definitely. But currently we don't have a space for metadata
outside of the record itself, which is where I think it belongs...
otherwise you can't retrieve metadata for a record which doesn't have
space for metadata in the schema.
Rob
--
,'/:. Rob Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Twin Cathedrals: telnet: liverpool.o-r-g.org 7777
____/:::::::::::::. WWW: http://liverpool.o-r-g.org:8000/
I L L U M I N A T I
