Our preferred option is some form of separated list of names of targets
whether they be services, databases, sub-databases, collection or whatever.
That is a matter for the three elements of the transaction (client - MSE -
SE) to sort out and agree on.

The idea of a single named set of targets is not really practical as the
user (sitting at the client) is able to choose the Sources to search
dynamically. Thus we would need a combinatorially big number of permutations
of the available database Sources and some sites have in the hundreds.

There are various combinations of multi-part operations such as Theo
describes which could be used, but all of them suffer from one problem
"multi-" part. Speed of response to the user is paramount and adding another
transaction pair is not the base solution most people want.

A comma (or other separator) delimited list of database names would be our
preference.

Peter

> -----Original Message-----
> From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]On Behalf Of
> Theo van Veen
> Sent: Friday, June 10, 2005 2:59 PM
> To: [log in to unmask]
> Subject: Betr.: Multiple Sources in SRU/W
>
>
> Even when one single database is connected to, it is desirable to
> specify a subset of that database as target. We use "x-collection" as
> parameter to specify a single target. I would suggest a comma-separated
> list of collections as value for x-collection in case there are more
> collections. It is also possible to have virtual collections which can
> be a predefined list of collections but will appear as one name for
> x-collection. One could add an extension to the service that allows a
> client to define a set of databases as a single virtual database which
> can be used as a surrogate for the list of targets.
> We have done an experiment with accessing a MSE via SRU. It is not only
> a matter of specifying the metasearch targets but also how to return the
> results. In the experiment we did we defined a "operation=metaSearch"
> with a normal SRU query but with a response consisting of a list of
> target ids with the number of hits for each speciifc target. To obtain
> the actual results for a specific target the target id is used as value
> for the x-collection parameter and the query is retransmitted.
>
> Theo
>
>
> >>> [log in to unmask] 06/10 5:28  >>>
> Hi All,
>
> This is a SRU/W for MetaSearch Engines (MSEs) question. It occurred
> during
> internal discussions in MuseGlobal and then again at the ELAG meeting
> last
> week.
>
> As far as I can tell from the documentation and from searching this
> thread
> there is no preferred/recommended/allowed method of asking a server to
> search more than one target database. Obviously with "real" SEs this is
> not
> a problem as they only have one database (well, the vast majority of
> them),
> but for SRU/W to be used to connect TO an MSE it is obviously a bit of
> a
> problem. From the MSE to the SEs is no problem.
>
> In the message from the client to the MSE we're, obviously, not
> talking
> about real database, but what we call Sources which are a particular
> database (or other Data Service) at a particular Host. However they
> have IDs
> just like any internal database for an SE, so the semantics of the
> "database
> name" is not a problem, only the number of them allowed in the SRU
> string.
>
> We have a couple of methods in mind, (just stringing the IDs together
> as one
> long 'database name' string is one way which would be sort of legal,
> but not
> very elegant) but they would be 'non-standard'. It's a problem which
> would
> be much better addressed now rather than later.
>
> Ideas? suggestions? modifications to standards?
>
> Peter
>
> Dr Peter Noerr
> Chief Technical Officer
> Museglobal, Inc.
>
> tel: +1 801 208 1880
> fax: +1 801 208 1889
> cell:+1 801 910 4912
>
> [log in to unmask]
> www.museglobal.com
>