> >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