 |
|
|
Main BTR Sections
|
|
|
|
Reviews
|
|
|
© Biblio Tech Ltd. All rights reserved.
|
|
|
|
Z39.50 stand-alone client software review |
|
|
|
|
|
Contents |
|
Assessment, Introduction, Z39.50 searching problems, Query formulation, Reverse Polish Notation, Query building, Reviews: BookWhere 2000, ZNavigator, SLS PC Browser, Features compared, Technology Briefing
|
|
|
|
Z39.50 clients can exist as stand alone products bibliographic tools for use against any database. They can be used as
personal research tools or as a part of a cataloguer’s PC “workbench”. We have reviewed three standalone Z-clients.
Each one has a different history and purpose and so it should be stressed that they should not be viewed strictly as direct
competitors. What is interesting in such a new product breed is the fast development of features and their approaches to solve common problems.
Z-clients are new products for searching catalogues. They have added dimensions over a standard OPAC for example session
control and host management and they may have to worry about simultaneous access to hosts with many results coming back at once a level of complexity that OPACs addressing a single
database do not have. On the whole they manage this part of the function well with saved sessions and folders being used imaginatively. Where they have a lot to learn from conventional
OPAC design is in entering the search query - although it must be said that to exploit the inherent power of Z39.50 is going to involve complexity beyond what is required in most OPACs
|
|
|
|
|
|
|
The Z39.50 searching problems
|
|
The searching experience with Z39.50 is interesting to say the least. The ease with which
it is possible to find and retrieve records from multiple databases is very impressive, but the detail of what is retrieved from particular search statements can be inconsistent and
confusing. There are several reasons for this but they mostly boil down to:
- inconsistencies between versions of the standard on client and server
- translation of diagnostic reports between Z-client and Z-server
- unsupported features on the target database e.g. Z-server supports separate corporate author searching but underlying library system does not.
- Z-server set-up many Z-servers are not “tuned” to the library system after installation.
For example, if a user sets up a query on a Z-client which cannot be handled by the
Z-server, then the response may be just a search with zero hits. It may be that the user has asked for truncation of a term in order to widen a search. By widening the search, they get zero results!
Many of these types of problem are only seen when using some of the more advanced
attribute sets and could be easily handled by better use of diagnostic response at both ends of the process. In the meantime tremendous useful work can be done reliably and
easily with these tools. In the future Z-servers will become more adept and informative about situations that now just generate an error and no results.
|
|
|
|
Query formulation in Z39.50 |
|
Reverse Polish Notation (RPN) |
|
Boolean queries can be expressed in several ways. The Z39.50 clients and servers talk in
Reverse Polish Notation (RPN). It sounds complex but it is simple and unambiguous for computers to read. RPN pairs up terms and adds a Boolean operator to define how they
relate. You read it from right to left which makes it tricky for people used to left-right reading. Thus:
Orwell:NOT:Down:AND:Paris:London:AND - using RPN
means (Paris AND London AND Down) NOT Orwell - in the more familiar algebraic format.
RPN gets rid of the brackets and, for computers it is very easy to process. The bracketed
form above is generally termed algebraic and is easier to understand. We all learned about brackets in algebra at school and most retrieval systems use a variant on this style of query presentation.
A variation on RPN is Prefix RPN, used by ZNavigator, where the Boolean operators prefix the pairs of terms and sub-queries e.g.
NOT:AND;London:AND:Paris:Down:Orwell
|
|
|
Building and displaying complex queries unambiguously is not an easy job. The three
products reviewed approached it slightly differently - see screen shots. SLS PC Browser was easiest to understand.
ZNavigator and BookWhere build up a “query tree” with search terms and attributes added
to a growing graphical representation of the query as branches and leaves. The problem is making sure that the terms and operators are entered at the right place in the structure to
get the results you require. There is not a lot to choose between the interfaces used BookWhere needs more space to display the tree but is slightly easier to read since it
does not display the attribute codes. It also gives an algebraic style summary of the query on the status line - which is comforting. ZNavigator displays the “Prefix RPN” once the
query is built complete with all attribute codes. The resulting string is very long for complex queries difficult to check. You can edit the string directly or even enter the RPN code directly if you wish.
Editing “query trees” - the graphical search statement - is mostly simple but can be
dangerous you can wipe out a carefully constructed query very easily in both products.
The SLS PC browser interface is easiest to use and understand since it creates the
equivalent of bracketed “groups” of terms to reduce the complexity. Each group can be expanded if needed and reduced tidily once you have got it correct.
Personally, I would like to see a “Power” search which took a more traditionally phrased
search statement e.g. T=(Computer AND JAVA) AND A=(Evans OR McNeally) and compiled it into RPN which could then be viewed by those who wanted to. No doubt the
industry will work hard and imaginatively on this problem.
|
|
|
|
|
