Administration secrets for ISite
This link contains information that supplements the implementation required to set up an active Clearinghouse Node. If you have a topic that should be addressed here, please send email to email@example.com and we will consider incorporating it.
Understanding Z39.50 "Fields"
The Z39.50 search and retrieval protocol relies on the establishment of common data elements and behaviors to achieve search interoperability across multiple servers that may manage their information using different data models, data managers, and search engines. The protocol enforces a level of abstraction that permits access to these heterogenous data collections through common vocabulary and functions.
Use Attributes are fields (or collections of fields) that are directly addressible through the protocol. Each Use Attribute has a set of Relations or operators that are valid for it (e.g. "greater than", "less than", "equals"). There are other characteristics that Z39.50 fields may support, but these are the fundamental ones. To promote the common use of certain Use Attributes, they are registered with the Library of Congress, the maintenance agency, by implementors, within Profiles that specify how the information is logically accessed and presented. Use Attributes are assigned an attribute set (a parent entity) to which they belong, and an integer identifier which is used in queries. Relations are similarly given a numeric identifier for proper reference in a query. The use of integer tags, usually 1-4 bytes long, simplifies the composition of unambiguous queries from Z39.50 clients to server processes and facilitate the internationalization of attribute sets, since it is the semantic meaning that is being associated with the identified field or operator.
A query is typically composed in a client piece of software, showing the user the field names they prefer to see in the form. The form or submission process translates the contents of the user query into Reverse Polish Notation using the numeric Use Attribute and Relation tags. The query is sent to a Z39.50 server where it is decomposed and passed to a search engine. On the server site there is a mapping between the Z39.50 fields and the local form of abstraction in the database or document collection, and the query is passed to the search engine for resolution. In Isite, for FGDC metadata, this mapping is stored in the fgdc.map file in the Isite's bin directory. Other attribute sets, such as GILS and bib-1 for bibliographic information, can be used and referenced this way.
The use of numeric attributes internal to the query protocol should be understood in the decoupling of information from its query and from its presentation. Metadata may be managed in a specialized database, queried via Z39.50 attributes and relations that map the query, and can be requested for display as HTML, SGML, or text using display tags in one of many languages.
Element sets are a subset of attributes for presentation in Z39.50. These can be formally defined in a Profile or privately defined at a server to enable the delivery of something less than a full entry to a client. In this way, custom or executive overviews can be generated without changing content, storage, or client requirements.
Running zserver as a background process (UNIX)
When the zserver process is stable and registered, it is recommended that you configure the software to be started whenever the system reboots to ensure minimum down-time and administrator interaction. To do this you will need to research how the system's startup daemons are configured. Usually there is a resource directory (in Linux daemon processes are linked from /etc/rc.d but are stored as scripts in /usr/sbin. A zserver.boot script is available for download to be installed in such a directory, scanned at startup by the startup daemon. Copy this boot script, being sure to make it executable (chmod +x zserver.boot), into the proper location on your system (Linux: in /etc/rc.d/rc5.d -- the "level 5" boot status).
At any time you are interested to see if the zserver process is active, type ps -e | grep zserver to display active processes. To shutdown the server, use the process ID (pid) listed by the ps command and type kill -9 pid where pid is the process number. The process must be killed by the userid who invoked it. More than one zserver "parent" process on the same port will cause the software to not work. Use the kill command to kill any spare zserver processes.