>
>>>> [log in to unmask] 14-02-02 13:51 >>>
>> 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.
>
No they are not. The distinction is artificial and the same title is just forced into different fields for both the Bath Profile and DC.Title. 

>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.
>
I do not see the problem. When I sent a title query to a bibliographic database and any arbitrary  database then I get titles of objects with different types or classes but a title remains a title.
>
>> 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.
>
The processing that can't be done by XSL is done by Javascript. Searching multiple sites is done via Javascript by opening multiple windows, frames or tabs.
>
>> 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.
>
We like to minimize the procesing and I certainly want to prevent to adapt each individual query to each individual target.
>
>> 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.
>
It would indeed be better if we could distinguish between "zero hits" and "index not available", but I do not know how to implement that for a boolean query. 
>
>> 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.
>
I hope that I never have to distinguish between different prefixes and that in SRU/SRW we will have all the same and only one default index set.  I understand that Dublin Core will not be sufficient because of the use of qualifiers. In fact a lot of "dc-element and qualifier" combinations will correspond to specific index types.  
Local indexe types can always be used without prefixes and will never be disturbing for others.
  
>
>> 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.
>
I keep hoping we end up with a single common index set.

>Ralph
>
>>
Theo