Development and support of Willow is now discontinued. Willow was removed from production at UW on June 30, 1999.
This document provides an introduction to the Z39.50 protocol, followed by information on how to configure and use Willow's Z39.50 driver. Readers who are already familiar with the protocol may wish to go directly to Configuring a Z39.50 Database. Creating a Z39.50 Database gives some pointers for finding a Willow/Z39.50 compatible server for your own data. For current information on Z39.50 in general, see the Z39.50 resources pages at http://lcweb.loc.gov/z3950/agency and http://ds.internic.net/z3950/z3950.html
The Z39.50 Information Retrieval Service and Protocol Standard provides an interoperable way to search databases, retrieve database records, scan term lists, and perform ancillary tasks related to information retrieval (IR). It is a platform and operating system independent client/server protocol that addresses communication between an origin (client) and a target (server). It does not define user-interface behavior.
ANSI Z39.50-1992 was a revision of the (now obsolete) Z39.50-1988 protocol. The 1992 standard defined version 2 of the protocol and was bit-compatible with ISO 10162/10163, Search and Retrieve, SR. Z39.50-1995, the current revision of the standard since 1995, defines protocol versions 2 and 3.
The Library of Congress is the maintenance agency for the standard and is advised by the Z39.50 Implementors Group (ZIG). The ZIG maintains an active listserv (Z3950IW@NERVM.BITNET) and meets 3 or 4 times each year. ZIG membership is open to all interested parties.
The application protocol data units (APDUs) for the 1992 and 1995 revisions of the standard are expressed in Abstract Syntax Notation One (ASN.1) 1990. An html version of the 1995 ASN.1 is available at the Maintainence Agency Home Page.
Z39.50 interactions take place within the context of a Z39.50 service. Most implementors accept the INIT, SEARCH, and PRESENT services as forming the "core" of the protocol, and virtually all Z39.50 clients and servers support these. Other services, less widely implemented, are SCAN, SEGMENT, DELETE, ACCESS-CONTROL, RESOURCE-CONTROL, TRIGGER-RESOURCE-CONTROL, RESOURCE-REPORT, SORT, EXTENDED-SERVICES, and CLOSE. Willow currently supports version-2 INIT, SEARCH, PRESENT, SCAN, and RESOURCE-CONTROL.
A Z39.50 session begins with the INIT service. The origin sends an InitRequest to the target. The InitRequest specifies which protocol versions it can use, which Z39.50 services it may wish to use during the session, and what size messages and records it can accept. Optionally, the InitRequest may identify the client software and include userid and password information.
The target responds with an InitResponse that confirms which protocol version will be used, which of the proposed Z39.50 services it will support, and whether or not the InitRequest has been accepted. Optionally, it may identify the server software.
Upon receiving an InitResponse, and assuming the InitRequest was accepted, the origin decides whether to continue with the session.
The SEARCH service allows many different types of queries. The most common is the type-1 RPN (reverse polish notation) query. RPN queries consist of two operands followed by an operator that should be applied to them. The advantage of RPN is that it allows complex queries to be expressed unambiguously. For example, the expression 2 x 3 + 2 would normally be interpreted as "(2 x 3) + 2", but is ambiguous without the parentheses. The same query in RPN would be "2 2 3 x +", and allows only one possible interpretation. Operands may themselves be RPN queries, or they may consist of one or more search terms plus "attributes" that describe the desired characteristics for a term. The type-101 query adds proximity operators to the boolean of type-1 queries, but few systems support type-101 queries at this time.
Attributes are type/value pairs which collectively form an "attribute set". The most commonly implemented attribute set is "BIB-1"; this attribute set is public and registered, which means that implementors cannot arbitrarily change it. The BIB-1 set includes elements for "use" (an access point, roughly analagous to an index), "relation" (equal, greater than, etc.), "position" (first in field, first in subfield, any position), "structure" (word, phrase, etc.), truncation (left, right, etc.), and "completeness" (incomplete subfield, complete subfield, complete field). A list of the BIB-1 attributes and how to specify them in Willow can be found in the Specifying Z39.50 Attributes section below. Other public, registered attribute sets include STAS (scientific and technical) and GILS (government information). Implementors may design private attribute sets; specifications for these must be obtained from the owner.
Even given the relatively well-understood domain of bibliographic data, the semantics of the BIB-1 attribute set are problematic. In the past, targets often redefined queries they were unable to process ("fuzzying" the search). If, for example, an origin submitted a search asking for "Smith, John" as a personal author phrase and the target had no concept of "personal-name-as-author", it might map the query to "personal-name-as-subject-or-author". Almost certainly, this was not what the user expected. Implementors are aware of this problem, and several solutions are being tried. Profiles are being developed for certain classes of data (WAIS and GILS are already defined), BIB-1 semantics are being explicitly defined, and servers are no longer arbitrarily fuzzying searches. Version-3 adds a semanticAction flag that allows the origin to specify how much fuzzying it is willing to accept.
The assumed operator between words is usually AND (for the structure attribute WORD_LIST). Some servers will use a default operator other than AND, and ultimately choosing the default is up to the server. Some indexes, like TITLE_WP, are phrases by default (structure attribute PHRASE). The completeness attribute affects whether the phrase has to be the complete subfield, complete field, or incomplete subfield. You can override structure, completeness, and position attributes on a per-field basis in the database configuration file, but your user cannot do so on a per-search basis.
Regardless of your database configuration settings, the target's indexing practices will determine much of your search strategy. For example, OCLC WorldCat indexes subject headings as phrases at the complete subfield level. If you try to search "united states history" as a subject phrase (looking for documents with the subject heading "United States -- History"), you will fail since the indexing is
history united states
Similarly, "united states history" fails as a phrase search in WorldCat; there is no index for that database that spans subject subfields. Your only alternatives are to search "united states history" as a wordlist (which assumes AND between words), or to connect the subfield phrases with AND:
united states AND history
= equal to < less than <= less than or equal to > greater than >= greater than or equal to ~= not equal to ^= not equal to
'hogan''s hero''s' or "hogan's hero's"
would search for the string "hogan's hero's". A quote mark may be either a single quote (') or a double quote (").
With some targets, punctuation (or the lack of it) is significant. Among the more common practices are:
Willow's Z39.50 driver normalizes search arguments by default. See Configuring a Z39.50 Database below for more details.
A few servers truncate by default, so a search for "wash" also retrieves "washington". In these cases, you can use '|' to indicate no truncation. For example, "wash|" will retrieve "wash" only, even if the server truncates by default.
You can override the target's default truncation setting in the database configuration file on a per-field basis.
The SCAN service provides a way to browse ordered lists of terms. The origin specifies a database, starting term, attributes, step size, number of terms requested, and preferred position in the response. The target should return the terms and/or an error diagnostic. Targets are free to support SCAN for some attributes and not for others, or not to support SCAN at all. SCAN performance can be erratic, especially if the target has to sift through a concatenated term list looking for those terms that match a particular request. Willow's SCAN has been extensively rewritten to comply with Z39.50-1995.
PRESENT allows the origin to request records that were found by a search. Preferred record syntaxes are part of the INIT negotiation between origin and target. The protocol allows for many different record syntaxes, although only MARC and SUTRS (Simple Unstructured Text Record) are in widespread use today; Willow supports both MARC and SUTRS records. Some developers are beginning to implement GRS-1 (Generic Record Syntax), a syntax that allows encoding of arbitrarily complex records like image formats, SGML data, etc.
MARC is an encoding standard (Z39.2) for bibliographic data that has been in widespread use in libraries for 30 years. Within the library community, a set of content guidelines (USMARC Format for Bibliographic Data) and a set of data format rules (Anglo-American Cataloging Rules) have attached themselves to the MARC communications format specified in Z39.2.
It should be noted that the use of MARC as a record syntax in Z39.50 does not imply the use of USMARC content guidelines. Willow's MARC record formatting is table-driven, which gives a site administrator the flexibility required to design rational displays for MARC records that do not use USMARC content rules.
This section provides supplemental information to the Database Configuration Files section of Administration for configuring Z39.50 databases. When using the Z39.50 driver, the following differences from that section apply.
env_name = HostName env_val = fionavar.mit.edu
An exception is if you use the University of Washington's license manager system (see below), in which case the driver can aquire a login "ticket" from the license manager which will include a Z39.50 server name.
To use the latter method, use an "auth_id" environment specifier. I.e.
env_name = auth_id env_val = uname/password
The value is a user name and a password separated by a slash, with no whitespace.
The third option is to use the UW license manager system, which can provide userid and passwords for connections to remote hosts as needed. With the UW license manager, all of the connection information can be maintained centrally on the license manager. When a user starts a database session, the driver contacts the license server and obtains the connection information and password. The license manager can be configured to limit the number of concurrent sessions, as some vendors require.
env_name = Z39.50Port env_val = 210
To turn normalization off on a per-database basis, specify:
env_name = canon_rule env_val = none
t_field_name = Exact Titles t_field_cmd = TITLE_WP list_name = TITLE_WP
Optionally, you may specify a starting term by appending "@<term>" to the list name. To begin scanning titles at 'a', for example:
list_name = TITLE_WP@A
The translation may have problems with certain servers which use a collating sequence other than ASCII. The driver can support a pseudo-EBCDIC sequence for a browse list; this feature can be activated by appending :EBCDIC to the index name, e.g.:
list_name = TITLE:EBCDIC.
ASCII is the default; specifying :ASCII explicitly is also allowed.
env_name = preferred syntax env_val = SUTR
With SUTR records, the fields to display for the summary record are selected using the summary_fields field in a database entry. For example,
summary_fields = TITLE,"AUTHOR:"
will match any line beginning with TITLE or AUTHOR for summary display.
Each field with an 'E' flag indicates that the summary display should end if this field is matched. If none of these fields are matched, the Summary_Field_Count tag will be used to determine how many fields will be used for the summary. It must be the last tag:
summary_fields = Land boundaries:E,Coastline:E,Summary_Field_Count:8
title_fields = summary_fields =
For MARC databases the contents of the summary and full records are controlled by two files -- bibbrief for summaries and title lists, and bibfull for the full records. They are described more fully below, in MARC Record Formatting.
There is one bibbrief and bibfull file that comes stock with the z3950
driver (located in the z3950.format subdirectory, relative to the
Willow*databaseConfigDir X Resources). But you can
specify a different file to look for with bib_suffix. For example:
env_name = bib_suffix env_val = mitcat
would cause your database to look for bibbrief.mitcat and bibfull.mitcat before the standard bibbrief and bibfull files. If one or both files are not found, Willow silently defaults. If one or both are found, their contents OVERRIDES the default. So you should clone bibfull and bibbrief, make changes to the clone and install it as your custom file with the custom bib_suffix.
extension_fields = PATH:@,|,|,690,|,~,PAGE:@,|,|,505,|,~, extension_label = Article View extension_program = launcher
When you press the button labeled "Article View" the 'launcher' program is started and receives a full record with the MARC 690 field prefixed by "PATH: ", and the MARC 505 field prefixed by "PAGE: ". MARC Record Formatting below gives more information about setting up the MARC formatting description. The Multi-Media Extensions section of Administration gives more information on using the extension mechanism.
The attribute-spec specifies the search index (also known as the USE Attribute), and optionally can also set Structure, Completeness, Positional, and Truncation attribute parameters.
<attribute-spec> ::= <use> | <use>'/'<attribute_type>':'<attribute_value> <attribute_type> ::= <relation> | <position> | <structure> | <truncation> | <completeness>
Where <use> is any name that matches the indexes defined for the database and <other_attribute> is any one of the non-use attributes.
It is not necessary to specify non-use attributes unless a particular behavior is desired. Willow associates default values for <relation> and <structure> with each <use> attribute. Targets will generally ignore or supply server defaults for any missing non-use attributes. "Well-behaved" targets believe that you want the behavior you specify, so it is prudent to leave unspecified those attributes that are irrelevant to you.
Attribute: <use> Integer: 1 Syntax: <value> Default: none. <use> attribute is required. Example: t_field_cmd = TITLE
Except for those noted below, <use> attributes ending in "_wp" default to PHRASE structure, and others to WORD_LIST. <use> attributes identified with '*' in the list below default to WORD structure and FIRST_IN_SUBFIELD position.
<use> Integer PERS_NAME 1 AUTHOR_PN 1 PERS_NAME_WP 1 PAP 1 CORPORATION 2 ORGANIZATION 2 CAP 2 CORPORATION_WP 2 CONFERENCE 3 CONFERENCE_WP 3 TITLE 4 TITLE_WP 4 TWP 4 SERIES 5 SERIES_WP 5 UNFRM_TITLE 6 UNFRM_TITLE_WP 6 ISBN 7 ISSN 8 LCCN 9 BNBN 10 * BGFN 11 * LOCAL_NUM 12 * DEWEY_NUM 13 * UDC_NUM 14 * BLISS_NUM 15 * LC_CALL 16 * NLM_CALL 17 * NAL_CALL 18 * MOS_CALL 19 * LOCAL_CALL 20 * SUBJECT 21 SUBJECT_WP 21 SP 21 RAMEAU_SUBJ 22 RAMEAU_SUBJ_WP 22 BDI_SUBJ 23 BDI_SUBJ_WP 23 INSPEC_SUBJ 24 INSPEC_SUBJ_WP 24 MESH_SUBJ 25 MESH_SUBJ_WP 25 PA_SUBJ 26 PA_SUBJ_WP 26 LC_SUBJ 27 LC_SUBJ_WP 27 RVM_SUBJ 28 RVM_SUBJ_WP 28 LOCAL_SUBJ 29 LOCAL_SUBJ_WP 29 DATE 30 PUBDATE 31 ACQ_DATE 32 KEY_TITLE 33 KEY_TITLE_WP 33 COLL_TITLE 34 COLL_TITLE_WP 34 PLL_TITLE 35 PLL_TITLE_WP 35 COVER_TITLE 36 COVER_TITLE_WP 36 TITLEPAGE 37 TITLEPAGE_WP 37 CAPT_TITLE 38 CAPT_TITLE_WP 38 RUN_TITLE 39 RUN_TITLE_WP 39 SPINE_TITLE 40 SPINE_TITLE_WP 40 OVAR_TITLE 41 OVAR_TITLE_WP 41 FORMER_TITLE 42 FORMER_TITLE_WP 42 ABBR_TITLE 43 ABBR_TITLE_WP 43 EXPN_TITLE 44 EXPN_TITLE_WP 44 PRECIS_SUBJ 45 PRECIS_SUBJ_WP 45 RSWK_SUBJ 46 RSWK_SUBJ_WP 46 SUBDIV_SUBJ 47 SUBDIV_SUBJ_WP 47 NATBIB_NUM 48 NATBIB_NUM_WP 48 LGLDEP_NUM 49 LGLDEP_NUM_WP 49 GOVTPUB_NUM 50 GOVTPUB_NUM_WP 50 MUSIC_PUB 51 MUSIC_PUB_WP 51 DB_NUM 52 DB_NUM_WP 52 LOCAL_ID 53 LOCAL_ID_WP 53 LANGUAGE 54 GEO_CODE 55 INST_CODE 56 NAME_TITLE 57 NAME_TITLE_WP 57 GEO_NAME 58 GEO_NAME_WP 58 PUB_PLACE 59 CODEN 60 MFORM_GEN 61 ABSTRACT 62 ABSTRACT_WP 62 NOTE 63 NOTE 63 PUB_TYPE_EXACT 500 AUTHOR_TITLE 1000 AUTHOR_TITLE_WP 1000 RECTYPE 1001 RECTYPE_WP 1001 NAME 1002 NAME_WP 1002 AUTHOR 1003 AUTHOR_WP 1003 PERS_AUTHOR 1004 PERS_AUTHOR_WP 1004 CORP_AUTHOR 1005 CORP_AUTHOR_WP 1005 CONF_AUTHOR 1006 CONF_AUTHOR_WP 1006 STANDARD_ID 1007 STANDARD_ID_WP 1007 LC_CHILD_SUBJ 1008 LC_CHILD_SUBJ_WP 1008 PERSNAME_SUBJ 1009 PERSNAME_SUBJ_WP 1009 TEXT_BODY 1010 TEXT_BODY_WP 1010 DB_ADD_TIME 1011 DB_ADD_TIME_WP 1011 DB_MOD_TIME 1012 DB_MOD_TIME_WP 1012 ATY_FMT_ID 1013 CONCEPT_TEXT 1014 CONCEPT_TEXT_WP 1014 CONCEPT_REF 1015 COCEPT_REF_WP 1015 DEFAULT 1016 DEFAULT_WP 1016 ANY 1017 ANY_WP 1017 SERVER_CHOICE 1017 SERVER_CHOICE_WP 1017 PUBLISHER 1018 RECORD_SOURCE 1019 EDITOR 1020 BIB_LEVEL 1021 GEO_CLASS 1022 INDEXED_BY 1023 MAP_SCALE 1024 MUSIC_KEY 1025 REL_PERIODICAL 1026 REPORT_NUMBER 1027 STOCK_NUMBER 1028 THEMATIC_NUMBER 1030 MATERIAL_TYPE 1031 DOC_ID 1032 HOST_ITEM 1033 CONTENT_TYPE 1034 ANYWHERE 1035 ATS 1036 SICI 1037 Attribute: <relation> Integer: 2 Syntax: R:<attribute_value> Default: EQUAL Example: t_field_cmd = DATE/R:GREATER_OR_EQUAL <attribute_value> Integer EQUAL 3 GREATER_OR_EQUAL 4 GREATER_THAN 5 LESS_THAN 1 LESS_THAN_OR_EQUAL 2 NOT_EQUAL 6 PHONETIC 100 RELEVANCE 102 STEM 101 Attribute: <position> Integer: 3 Syntax: P:<value> Default: ANY_POSITION_IN_FIELD Example: t_field_cmd = TITLE_WP/P:FFIELD <attribute_value> Integer ANY_POSITION_IN_FIELD 3 FFIELD 1 FSUBFIELD 2 FIRST_IN_FIELD 1 (synonym for FFIELD) FIRST_IN_SUBFIELD 2 (synonym for FSUBFIELD) Attribute: <structure> Integer: 4 Syntax: S:<value> Default: varies by <use> attribute _wp <use> attributes default to PHRASE other <use> attributes default to WORD_LIST, except where noted in the <use> section Example: t_field_cmd = TITLE/S:WORD <attribute_value> Integer DATE_NORMALIZED 5 DATE_UNNORMALIZED 100 DOCUMENT_TEXT 106 FREE_FORM_TEXT 105 KEY 3 LOCAL_NUMBER 107 NAME_NORMALIZED 101 NAME_UNNORMALIZED 102 PHRASE 1 STRUCTURE 103 URX 104 WORD 2 WORD_LIST 6 YEAR 4 WORD_ADJ 7 Attribute: <truncation> Integer: 5 Syntax: T:<value> Default: none (server default) Example: t_field_cmd = TITLE_WP/T:RIGHT_TRUNCATION <attribute_value> Integer DO_NOT_TRUNCATE 100 GLOB 102 LEFT_AND_RIGHT 3 LEFT_TRUNCATION 2 PROCESS_#_IN_THE_SEARCH_TERM 101 REGEXP 103 RIGHT_TRUNCATION 1 Attribute: <completeness> Integer: 6 Syntax: C:<value> Default: none (server default) Example: t_field_cmd = TITLE_WP/C:CSUBFIELD <attribute_value> Integer CFIELD 3 CSUBFIELD 2 COMPLETE_FIELD 3 (synonym for CFIELD) COMPLETE_SUBFIELD 2 (synonym for CSUBFIELD) INCOMPLETE_SUBFIELD 1
for a subject search that groups subfields as phrases, but will match the subfield phrase if it occurs anywhere in the field.
t_field_cmd = SUBJECT/S:PHRASE/P:ANY_POSITION_IN_FIELD
If the database had defined a default TITLE index as:
use structure completeness position TITLE WORD_LIST CFIELD ANY_POSITION_IN_FIELD
The following attribute-spec expressions are equivalent:
TITLE TITLE/S:WORD_LIST TITLE/S:WORD_LIST/C:CFIELD TITLE/S:WORD_LIST/C:CFIELD/P:ANY_POSITION_IN_FIELD TITLE/C:CFIELD TITLE/C:CFIELD/P:ANY_POSITION_IN_FIELD TITLE/P:ANY_POSITION_IN_FIELD
The reason why so much redundancy is allowed, is to make it easy for a user to specify an attribute spec.
NO whitespace should appear anywhere in an attribute spec. This is because the parser considers the attribute spec to be one token, and cuts it apart at the slashes.
All of these parameterizations are controlled through arrays in src/z3950/api/client/bib1.h and src/z3950/api/client/bib1attr.h. So if you hear of a new kind of attribute, you can add it there.
The contents of the summary and full records are decoded from the MARC format received from the Z39.50 server. How the user sees them is controlled by two files 'bibbrief' for summaries, and 'bibfull' for the full records.
These two files get stored as bibbrief, and bibfull in the db-config/z3950.format directory. As discussed in Configuring a Z39.50 Database it is also possible to specify alternate bibfull and bibbrief files for specific databases.
Conventions: Comment lines are delimited by beginning and ending with a slash. If you want to put a space in your output, denote it with the at-sign -- '@'. The vertical bar '|' denotes "default" and is used to match anything. The tilde '~' means "not" and is used to match all but those named.
The files consist of a set of tab-separated fields.
short: The short name string to be displayed. ind1: MARC first indicator. ind2: MARC second indicator. tag: MARC tag. subfields: MARC subfields present.
Control is exercised as follows: if the tag, indicators and subfields in the record match the contents of a line, the short name entry will be prepended and the data from the record will be displayed. In bibbrief, the summary field tells how wide to make the field in the title display; since the title display is fixed width, the number of characters specified in the summary column is always reserved for that shortname, even if no data is present.
/short ind1 ind2 tag subfields summary / AU:@ | | 100 | 20
Twenty characters out of the author appear in the title line display. All subfields are displayed.
SU:@ | | 600 ~w ~
Subject does not appear in the title line display. All subfields except w are displayed.
/short ind1 ind2 tag subfields summary / AU:@ | | 100 ~w ~
Parameters 0 "R2"
R2 was created to format the MeSH subject headings (as they occur in OCLC FirstSearch MEDLINE) into a more reasonable form. R2 looks for a MARC 650 tag with the second indicator set to '2'; this identifies the heading as MeSH. R2 assumes that the first occurrence of the 650_2 should be labeled as a "MeSH Major Subject", and all of the a subfields will be grouped under that label. The second occurrence of the 650_2 is assumed to hold "MeSH Minor Subject", and each subfield a entry will be grouped under that label, with each subfield starting on a new line. Subsequent 650_2 are not labelled, and will appear on a separate line following the "MeSH Minor Subject" entries.
Example: the following three MARC fields:
650 2 $a Aortic Aneurysm, Abdominal--surgery (*SU) $a *Implants, Artificial 650 2 $a Aorta--pathology (PA)/ultrastructure (UL) $a Dogs $a Microscopy, Electron, Scanning $a Stents 650 2 $a Animal $a Support, Non-U.S. Gov't
would be formatted and shown to the user as:
MESH MAJOR SUBJECT: Aortic Aneurysm, Abdominal--surgery (*SU) *Implants, Artificial MESH MINOR SUBJECT: Aorta--pathology (PA)/ultrastructure (UL) Dogs Microscopy, Electron, Scanning Stents Animal Support, Non-U.S. Gov't
Parameters 0 "R3" 1 (decimal) field tag 2 string for first occurrence of MARC field (if null, use bibfile label) 3 string for second occurrence of MARC field . . : : n string for n-1th occurrence of MARC field
Example: AUTHOR:@ | | R3!700!!OTHER@AUTHORS:@! | ~ will display 700 1 |a Mahin, John Lee, |d 1907- 700 10 |a Arthur, Robert. 700 10 |a Wayne, John, |d 1907-1979. 700 10 |a Ross, Katherine. as: AUTHOR: Mahin, John Lee, 1907- OTHER AUTHORS: Arthur, Robert. Wayne, John, 1907-1979. Ross, Katherine.
Parameters 0 "R4" 1 (decimal) field tag 2 (decimal/hex/octal) beginning character offset 3 (decimal/hex/octal) ending character offset (leading 0x = hex; leading 0 = octal) must be >= beginning offset Example: OCLC@NO:@ | | R4!001!0!10! | ~ will display "001 ocm20885381" as: OCLC NO: ocm20885381
Parameters 0 "R5" 1 (decimal) field tag 2 data for first occurrence of MARC field 3 data for second occurrence of MARC field . . : : n data for n-1th occurrence of MARC field Example: HOLDINGS:@ | | R5!948!Check@at@ILL.@! | ~ will display "948 $hLIBRARIES: STATE: LA LIBRARY: LMJ" as: HOLDINGS: Check at ILL.
Parameters 0 "R6" 1 (decimal) field tag (use 008) Example: YEAR:@ | | R7!008! | ~ will cause dates to be formatted as: /07 008/6-14 display s d19041905 YEAR: 1904-1905 s d181u18uu YEAR: 181u-18uu m i17651770 YEAR: 1765-1770 m r19911926 YEAR: 1991, 1926 m c19701958 YEAR: 1970, 1958 m d198606 YEAR: June, 1986 m s1903 YEAR: 1903 s c19869999 YEAR: 1986 m b YEAR:
Parameters 0 "R7" 1 (decimal) field tag 2 string to append to each subfield except the last in the MARC field 3 string to append to the last subfield in the MARC field Example: SUBJECT:@ | | R7!650!@--@!.! | ~ will cause "650 $aUnited States $aHistory $yCivil War 1861-1865" to be formatted as: SUBJECT: United States -- History -- Civil War 1861-1865.
This section gives some pointers for finding a Z39.50 compatible server to put your data into, to allow you to search with Willow. The development of Z39.50 software is progressing quite rapidly, so the information in this section may be out of date by the time you read it.
The best way to start looking for current Z39.50 information is to point your favorite Web browser at the Z39.50 Resources page at URL: http://ds.internic.net/z3950/z3950.html The Library of Congress, in its capacity as the Z39.50 maintenance agency, also maintains a resource page at: http://lcweb.loc.gov/z3950/agency/
The Isite software package from CNIDR provides a text indexer, search engine, and Z39.50 communications stack to access databases. This is a versatile package that offers features such as field-specific searching, field maps, and Boolean operators. See http://vinca.cnidr.org/software/Isite/Isite.html for information on the current version.
The National Library of Canada has made their server code available, but it includes only the protocol engine -- you still have to integrate a search engine. Denmark's Index Data offers a version 3 protocol engine and API called YAZ; again, you must integrate your own search engine. There are also commercial search engines like OCLC's Newton that come with a Z39.50 protocol stack, but they tend to be fairly expensive for light-duty use.
WAIS is an extremely popular database system that speaks Z39.50, however Willow speaks Z39.50 version 2 (1995), with some version 3 enhancements. WAIS-0.2 and WAIS-0.3 speak z39.50 (1988), which is not compatible with version 2.
At the University of Washington, we are using currently using Willow to provide campus-wide access to a growing list of FirstSearch databases at OCLC (http://www.oclc.org/) and to the Zephyr database suite at RLG (http://www.rlg.org/toc.html). We are testing Z39.50 access to MEDLINE from servers at the National Library of Medicine. Most recently, we have begun testing with servers at SilverPlatter Information, who supply several hundred database titles worldwide.
Questions and comments about Willow to: