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.


>>> [log in to unmask] 06/10 5:28  >>>
Hi All,

This is a SRU/W for MetaSearch Engines (MSEs) question. It occurred
internal discussions in MuseGlobal and then again at the ELAG meeting

As far as I can tell from the documentation and from searching this
there is no preferred/recommended/allowed method of asking a server to
search more than one target database. Obviously with "real" SEs this is
a problem as they only have one database (well, the vast majority of
but for SRU/W to be used to connect TO an MSE it is obviously a bit of
problem. From the MSE to the SEs is no problem.

In the message from the client to the MSE we're, obviously, not
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
name" is not a problem, only the number of them allowed in the SRU

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
be much better addressed now rather than later.

Ideas? suggestions? modifications to standards?


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]