 |
 |
Although I already mentioned, that I agreed with Mike's suggestion and intended to be quiet on this subject as it seems to be agreed not to mandate prefixes, I give one more reaction. On 16 May 02, at 16:46, Ray Denenberg wrote: > "LeVan,Ralph" wrote: > > > Sorry, but the ZIG has spent the last five or six years recovering from the > > problems caused when we originally did that. Clients would sent me an > > Author search. I didn't have an Author index, but I did have a Names index. > > So I turned the Author search into a Name search because bad results are > > better than no results. > > > > The ZIG played with the idea of semantic switches that would permit or > > forbid that kind of stuff and we have finally settled on flat forbidding it. > > Let's not recapitulate that process in SRW! > > That's convincing enough for me, and I retract my earlier acceptance of the idea > of a non-prefixed list. I would go so far as to support the idea that a prefix > need not be mandated by the cql syntax, but is encouraged, and that we give no > guidance whatever about what to do if there is none, and that we don't define a > list of non-prefixed indexes. > > --Ray Ralph's example does not apply on the prefix discussion. If a server finds that it should call its name-index a name-index and not the author-index, it has its reasons for it and it is up to the server to determine if its name-index is to be considered identical to an author-index or not. When the client doesn't know, the use of prefixes does not solve this problem. CQL does not allow the client to say "I don't care whether it is bath or dc or whatever, just give me the author". I never considered attributesets as mechanisms to modify the meaning of access points but more as a mapping of numbers and access points. And I also did not consider profiles as a mechanism to modify the meaning of an access point but more as an agreement on which attributes are to be supported by all partners supporting a certain profile. Mixing prefixes for namespaces(dc), profiles(bath) and attributesets(Bib1) in access points is in my view in cross domain searching not the solution of a problem but the introduction of a interoperability problem. Clients and servers have to be aware of other new introduced prefixes to be able to determine whether access points are identical or not. When the prefix is needed to modify the meaning of the index name than - in most cases - the index name wasn't a good choice. I think it is agreed that prefixes are not mandated and all the risc of ambiguity is at the client side when it does not add prefixes. I can live wiith that and will become quiet on this subject now. PS. There is one suggestion to be made with respect to future functionality on this issue. As soon as we introduce "scan", it would be nice when a search for an unprefixed term could OPTIONALLY return the index names for which a search term is available. It is then up to the user to decide how to proceed and he becomes aware of access points that were previously unknown to him but could be very helpfull. Theo