Re: Z39.50 Searching

The issues you have highlighted in were in part what moved many of us to 
develop and support Z39.50 profiles. These documents intended to nail 
down the server behavior as well as the semantics of the Z39.50 queries 
using the bib-1 attribute language. If you haven't looked at them yet, 
you might want to check out:

The Bath Profile: An International Z39.50 Specification for Library 
Applications and Resource Discovery, Release 2.0
http://www.collectionscanada.ca/bath/ap-bath-e.htm

ANSI/NISO Z39.89 - 2003 The U.S. National Z39.50 Profile for Library 
Applications
http://www.niso.org/standards/standard_detail.cfm?std_id=734

In the U.S. National Profile, we put into the Foreward a description of 
the terminology used in the profile, some of what relates to issues of 
fields/subfields (very MARC oriented), indexes, access points, etc.

Hope this helps some.

Bill

Heiko Jansen wrote:

> Am Mittwoch, 15. September 2004 20:29 schrieb Slavko Manojlovich 
> <slavko@mun.ca> [RE: Z39.50 Searching]:
> 
> 
>>I thought that structure = wordlist was deprecated because it supported
>>default behaviour vis a vis the application operators on the server side.
>>Some servers default to "AND" and other servers default to "SAME FIELD".
>>Ideally, you would send this search as structure = 2 with the "AND"
>>operator.
> 
> 
> Seems to be bad luck for me: I was hoping I could tell the server implementors 
> to change their serversī behaviour, but if there is no exact definition of 
> how a server should react to such queries my negotiating position seems quite 
> weak.
> 
> 
>>Quoting "LeVan,Ralph" <levan@oclc.org>:
>>
>>>It's not obvious to me why you get these different results. 
> 
> 
> Neither to me ;-)
> In my opinion the "word list" query should yield all hits as there is attr 3=3 
> (Position = any pos. in field) which IMHO should apply to all words of the 
> word list separately. And there should be no hidden logic about differrent 
> fields beneath the index and the occurence of all words in one of these. But 
> after all thatīs just an opinion....
> 
> 
>>>An experiment would be to repeat the search, omitting attribute types 2,
>>>3 and 5, since they were also omitted from the ANDed search.
> 
> 
> That still gives me no hits.
> 
> 
>>>If you still get different results, I'd contact the database provider.
> 
> 
> I contacted one of the developers of that system and he told me their system 
> would conform to the standard because it assumes that searching with a word 
> list implies "all words from one field/subfield" (regardles of the value of 
> the Structure attrib in the query).
> If Slavko is right, thatīs not entirely true but then neither is my opinion.
> 
> Iīm still wondering, however, what is really meant by the terms 
> "field"/"subfield"?
> Since Z39.50 provides an abstraction layer for searching and the record 
> syntaxes are decoupled from the search indices: how am I supposed to find out 
> what fields and subfields there are?
> Could anyone provide me with a definition of these terms or point me to a 
> discussion of this topic?
> 
> Still wondering
> Heiko

Received on Thursday, 16 September 2004 17:46:56 UTC