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