 |
 |
> 1. > Searchfields being identified by a two-part identifier, where > the first part identifies the scope of the second part, > contain the potential danger that there will be many scopes > and it will become very difficult to make sure that "one > search fits all". I have a very strong preference for forcing > search terms into a single scope (a default attribute set). > Maybe I see it wrong. Are there examples where it makes sense > to distinghuish between title and dc.title in searching? Bath Profile title and DC.Title are clearly different. There will be many others. But more importantly, as we discovered with Bib-1, we don't want to be in the position of blessing the indexes of other communities. When Les Wibberly comes to us with a Boiling Point index, are we going to lump it into the same default index? No, that was the easy, but wrong, answer that we started the ZIG with and I'd prefer not to repeat it. > 2. > We will use SRU to query multiple databases and I would like > to send the a query unchanged to all these targets. That is > the main reason for standardisation and the main reason for > us to use SRU. Sorry, but I just don't see how that is possible. SRU implies that there is no client software in the loop. How could you send an SRU request to multiple targets and what would consolidate the results? > 3. > A very important scenario will be: users with a webbrowser > that supports XSL/XML and an HTML page in which the user will > enter one query that will be send to multiple servers. The > results will be catched in multiple browser windows that do > the XSL-transformation but this is monitored by the main > search window. We have this scenario working but the main > problem is now indeed that different (external) targets > require a different query. > NB. This scenario is called the "personal portal" because it > does not require any central portal for querying different > SRU targets and every user can have his own portal (being > just an HTML page and one or more XSL stylesheets) as long as > this portal speaks SRU. Okay, you've answered the consolidation question: you don't consolidate. I still don't see how you take a query and pump it to multiple sites. > 4. > The idea that in SRU users must type a query as it is being > sent to the targets is not correct. In the html search page > all the required processing can be done to convert a user > query to CQL. I would like however that CQL and what the user > types in are the same or as much alike as possible. What processing in a search page? If you have processing, then you can change the query during that processing. > 5. > The preferred language for index types is English rather than > numbers. We use lots (>100) of index types among which are > the most conventional types as title, auther, keyword, > subject, TSBN and ISSN. Some of the other index types are > specific for specific databases and it does not hurt when an > index type that does not exist in all databases is sent to > multiple targets. The others just do not give any hits. This > seems to be a very attractive approach for most people > (users, developers database owners) that are involved in the > develeopment of websites for different projects/databases. The strong conclusion of the ZIG was that it was wrong to ignore attributes that you did not understand. I suspect that we will come to the same conclusion in SRx. > 6. > I prefer queries like: > > title:power and fame (boolean) Does this mean that "power" is qualified with "title" and "fame" is unqualified? > title:"power and fame" (phrase) > creator:xyz and subject:standards > author:smith (it is > up to the target to convert his to creator:smith) > > I think it makes sense to use the Dublin Core fields as index > types (so we do not need the dc.prefix). I thought you said you had hundreds of indexes. There are only 15 DC indexes (presuming that we create a DC Index set). You can certainly declare DC to be your default index set, but I think you go too far in suggesting that we will all do that. I suspect that you will want your local index set to be the default one so that the hundreds of indexes don't need prefixes. > This can be > complemented with namespaces from relevant Application > Profiles (like the Library Application Profile). > Everybody is free to use exotic index types in as well the > query as in his databases but it is obvious that it is in > everyone's own interest to conform to a single standard for > the conventional index types. There are already multiple profiles. I suspect that they will each define their own Index sets and different servers will support different combinations of them. The more popular ones will be broadly supported and the more local ones will only be locally supported. Ralph