    UDT Series on Data Communication Technologies and Standards for Libraries Models for Open System Protocol Development : A Technical Report (1994)5. JTC1 Application ProtocolsISO/IEC JTC1 is the ISO committee responsible for general computer standards. ISO TC46 develops computer-related standards only for library and information service applications, frequently using JTC1 standards as the foundation, although TC46 standards may be useful outside the information sector. JTC1 is responsible for the Open System Interconnection (OSI) protocols for layers 1-6 and has developed some general purpose layer 7, application, protocols which are discussed below. (Layers 1-6 are briefly discussed in section 13.)5.1 DirectoriesCCITT's (now TSB) X.500, and the equivalent ISO 9594, are protocols for the Directory service. The Directory service was planned to function as the white pages in the telephone book. When looking up a name one gets the postal address, the electronic mail address, telephone number, etc. An extension to the equivalence of the yellow pages, as a subject look up, is planned.The Directory is essentially a distributed database, though its functionality reflects the requirements of its intended application, and it lacks many features found in other database applications. It is envisaged that a global hierarchical database will develop. The Directory comprises a number of Directory Service Agents (DSAs). A user (person or program) interacts with the Directory by means of a Directory User Agent (DUA). The DUA concentrates all functions related to user interface and structure of dialogue, whilst the DSA concentrates on the access and efficient management of the database. Queries to a DSA may be chained onto other DSAs, or referred back to the DUA with suggestions for other DSAs to query. The cooperating DSAs provide the global service. The information held in the Directory is known as the Directory Information Base, and this is distributed in a hierarchical way among the DSAs. This hierarchy is known as the Directory Information Tree. Information about objects (countries, organizations, persons, databases, etc.) is stored as entries. Each entry has a set of attributes. One attribute is the entry's object class.
Systems implementing the SR and/or the ILL protocol will need a mechanism for obtaining the network address of the Target systems. The use of a Directory service is one way to do this.
5.2.1 Overview of DFR ProtocolThe DFR model consists of two components:
The DFR-Server contains objects which may be search for, retrieved, copied, deleted, etc. by the DFR-User. Each DFR object consists of a description of the object structure (the content), and the attributes. The structure of a DFR object depends on which object class it belongs to.
5.2.1.2 DFR-AttributesThe attributes for a DFR object type describe the content of the DFR object and also the functions which may be applied to the objects. Attributes for one object type may be ISSN, Coden, etc. The DFR-Server and the DFR-User sort the DFR objects when creating them, according to a chosen attribute. Part of this attribute may later be used for retrieval. DFR defines the set of attributes for a type of objects in two subsets:
The DFR-Basic-Attribute-Set consists of the DFR-specific attributes, while the DFR-Extension-Attribute-Set defines the general attribute types. Each type of use of the DFR may define attribute sets, but they must support the DFR-Basic-Attribute-Set.
5.2.2 DFR and LibrariesThe DFR service and protocol was defined after SR/Z39.50. However, the library community has studied it to see if it could be used for library systems.5.2.2.1 Search Requests in DFRDFR uses Remote Operations, which consists of highly structured argument, result, and error constructs. A Search-Request is specified as an Abstract-Operation. It includes the Search-criteria which contains the search string and may contain boolean operators. Each term in the Search-criteria consists of an Attribute-Type and an Attribute-Value. The Attribute-Types are defined in an appendix to the DFR protocol. New attribute sets may be defined.5.2.2.2 Suitability for Library SystemsThe attributes needed for searching in bibliographic databases (ISSN, CODEN, Main Title, Part Title, etc.) can not be mapped to the attribute set defined in the DFR protocol. A new attribute set would have to be defined.The specification of record composition for the retrieved records is not possible. SR defines "small result set" (all records are returned in the search response), "medium result set" (a list of the first records in the result set is returned, records usually in a short format), and "large result set" (only number of hits are returned in the search response). In DFR it is only possible to define one "max number of hits" to be used in the search response. When the result set contains fewer than this number, the records are returned (as for small result set), if it is greater the Document Numbers are returned. It is not possible to choose different formats for the different "types" of result sets. A search may result in a large result set. In order to just receive the number of hits, the user must first create a new DFR-Object (object class DFR-Search-Result-List), then the Search must be performed with the search mode set to "new-search-stored". Then the result-set is stored in the DFR-DS (server) and the number of hits are returned to the DFR-User. The created DFR-Object must be deleted by the DFR-User. A Search and Present may have to be carried out by using four different services (Create, Search, List and Delete).
Since the end-user may not know in advance the probable size of the result set, the search may have to be performed twice. First as a single search (which will return the "document numbers" for all records in the result set), then as a sequence of Create, Search, List and Delete. If the DFR-User will not be able to receive even the full set of document numbers, it is necessary to always use the Create, Search, List and Delete sequence. This may create a large amount of overhead and unnecessary network traffic.
It is possible to use FTAM instead of the SR Present-service, but in that case the records one wants to retrieve must be placed in a separate file. Then FTAM may be invoked to transfer the whole file or part of it. FTAM does not, however, include the analogue of an element set name. Thus one cannot request only a subset of the fields of the records to be transferred. If an FTAM file is structured, a tree structure is assumed. A READ operation may specify the identifier of a node and
The transfer of records from a result set to a structured file must take this into consideration, but one may choose to use unstructured files instead. Using structured files makes it difficult to substitute SR's PRESENT with FTAM in general. For example, there is not an FTAM command equivalent to "please transfer record number 5 to 10 in the result set".
FTAM does not appear to include any analogue of the Resource control function. Since the retrieval of one record may cost more than the retrieval of another (e.g., different royalties), the client cannot tell what the charges will be simply by counting the number of records it has requested to present. When using the SR Present the client may use the Resource Control and thus be able to inform the end-user of the cost. When using FTAM, the client does not have access to this facility.
The SR/Z39.50 protocol allows two computer systems connected to a network to exchange messages in order to co-operatively provide an information retrieval service. The emphasis of the protocol is on information retrieval; but augmentations to provide capabilities for updating remote databases are being progressed. The basic model of interaction is client-server between two systems. One of the two systems is the Origin, which wants to retrieve information, and the other is the Target, which has at least one, and possibly many, databases containing information. Most of the time the Origin sends requests to the Target and receives responses in return. The requests may be searches or may be requests to present records found by a previous search. The responses will contain information as to how the request was processed and may contain records. The focus of SR/Z39.50 activity is the database record, which represents, for example in the case of a bibliographic database, the bibliographic description of a book, periodical, journal article, etc. While the concept of record is basic to the model of operation of SR/Z39.50, there is no constraint on the definition of what constitutes a record. Thus, the protocol is generic in the sense that it can be used to retrieve information from any environment where the information can be modelled for retrieval purposes as a set of records. The SR/Z39.50 standard supports only synchronous processing, where the Origin can issue only one request at a time and must wait for the response before initiating another request. However, extensions to both SR and Z39.50 are being defined to support asynchronous operation so that an Origin can issue multiple requests before a response is received. Reflecting its Origin within the library community, the protocol allows search queries to be formulated in terms familiar to one who is comfortable with searching on-line catalogues, e.g., find all books with the keywords COMPUTER ART in the subject field. However, the standard is not limited to bibliographic information retrieval. It can in principle support any type of query, as long as both the Origin and Target system share an understanding of the query and application semantics.
Since SR/Z39.50 is a protocol standard, it does not specify how the Origin program communicates with its user, although clearly some kind of communication must take place in order for the Origin to know what to do next. Neither does the standard indicate how the Target program communicates with the database engine at its end. This is a key feature, allowing the protocol to be used in any database environment that supports the desired information retrieval semantics. This feature also frees the Origin from having to know the details of how the Target database is implemented.
The generic RDA standard provides a framework for managing and controlling the relationship between a client and one or more servers. It provides services for association management, for transfer of database operations and parameters from client to server, for transfer of resulting data from server to client, and for transaction management, supporting both one-phase and two-phase commitment. It does not specify what database operations are permissible. It assumes the existence of a language specialization that specifies the exact syntax for standard operations. The basic model of interaction between client and server is asynchronous, i.e., a client may invoke operations without waiting for the result of previous operations.
At present, only one specialization for RDA has been standardized, that for SQL. This specialization defines how SQL operations and results are packaged for interchange between the client and server, using the generic RDA services.
While a standard query type is defined (the Reverse Polish Notation Type 1 query) in SR/Z39.50, other query types are permitted (e.g. Common Command Language). Thus, it is possible to transfer SQL queries using the SR/Z39.50 protocol. Further, no constraints are imposed in terms of attribute sets used with the Type 1 query. At the level of record syntax, the SR/Z39.50 standard is fully flexible. Records retrieved as a result of a search can have arbitrarily complex syntax. While RDA provides the greater degree of decoupling, SR/Z39.50 does provide decoupling in significant areas. As experience with SR/Z39.50 is gained, additional operations will likely be supported. A proposal for a generic facility to support a range of additional operations, e.g., stored queries, saving result sets, etc., is being considered. When RDA is coupled with its SQL specialization, SQL semantics become a dominant factor. Queries must conform to SQL syntax and record syntax is constrained by the data types supported by SQL and by the existing column specifications within the Target database.
The retrieval operations supported by SQL are more restrictive than SR/Z39.50. Whereas the Present operation of SR/Z39.50 allows the retrieval of an arbitrary number of records from a result set, beginning at an arbitrary starting point, the SQL equivalent allows only the retrieval of an entire table or of a single row at a time from the current cursor position.
The SR/Z39.50 standard places no constraints on the nature or amount of processing undertaken by a Target system in order to create a result set on the basis of a query. Even in bibliographic applications where simple string matching is the norm, complex transformations of date information or other quasi numeric data may be required to process a search. The SR/Z39.50 standard supports the use of only a single attribute set with a search. An unlimited number of attribute sets could conceivably be defined for specific search applications and situations. In addition, the query notation permits the use of previously created result sets in subsequent queries, allowing efficient use of resources at the Target while permitting the Origin substantial freedom in developing and modifying complex search strategies. SQL, as a general purpose relational database manipulation language, can search, update, and retrieve information contained in any number of tables. Tables can be manipulated to produce new tables by cartesian products, unions, intersections, joins on matching columns, projections on given columns, etc. The language has powerful constructs for expressing conditions, performing aggregate operations, predicates for comparison and string operations, features to partition tables by groups, etc., all in a strictly declarative fashion and completely transparent to the RDA protocol. There remains some doubt within the information retrieval community as to the suitability of SQL for general purpose information retrieval. It is believed that extensions, in particular to support user-defined data types and operators, as well as indexing to support them, are needed to achieve a suitable level of capability. Such extensions are expected to be included in SQL3 in the form of support for abstract data types. SQL3 is not expected to be available before 1995.
A key distinguishing feature between the SR/Z39.50 Type 1 query and SQL is the larger scope of data manipulation functions available with SQL. This difference relates to the underlying model of RDA and SQL, where all data manipulation is performed by the database server. The function of the RDA protocol is simply to convey SQL statements and related control operations to the database management system. The model of SR/Z39.50 is of an agent at the server that is logically separate from the database management system. This agent is capable in its own right to support additional operations on the results of queries, operations such as present, delete and sort.
SR/Z39.50, with its ability to support different attribute sets with its Type 1 query, provides the desired capability. For example, the bib-1 attribute set is oriented toward bibliographic retrieval. It allows a searcher to specify a query in terms of access points (e.g., author, title) to a catalogue, with boolean and relational operators on selected values for these access points. The Origin's query handler does not need to have any knowledge of the physical representation of the database at the Target. It only needs to know whether the semantics of the query can be understood by the Target. This can greatly simplify the Origin implementation, as the same query handler can be used to communicate with different Target systems that support similar semantics, e.g., library catalogues, despite the fact that they may have fundamentally different supporting database management systems. As a query is sent from one Target to another, the only changes that may be needed are in the database names used by the Target system. RDA with its SQL specialization requires that the Origin map the user's query into SQL statements that reflect a relational data model understood by the Target database. To achieve consistency of queries across multiple databases, a common external database view must be defined. Each Target system would then internally map queries based on this common external view to a form suitable for local processing.
This approach is possible in theory, and the concept of common external repository interfaces has been proposed by the SQL community to address this type of problem, but to our knowledge, no work has been done to date to specify such an interface for the bibliographic community. This would require a separate and additional standardization effort, parallel and additional to the one which has already been undertaken in the development of SR/Z39.50.
In the case of RDA with SQL, its use in the bibliographic community would require that many non-SQL systems define a mapping from SQL to their environment. The non-relational server in effect defines a "tabular" view of the information controlled by it and provides an "SQL Information Schema" that describes all the tables accessible to external SQL applications and equivalent data types for the columns of the tables. While some major vendors are reportedly offering SQL front-ends to their non-relational DBMS products, there is to our knowledge no instance of a library system vendor or information utility providing such a capability.
When RDA is used with SQL, the limitation of retrieving one row at a time can be alleviated by using the RDA mechanism to repeat a requested operation any number of times, such that one RDA request/response interaction could retrieve multiple rows of a table. However, this capability may be of limited use in practice, as it appears that the Call Level Interface (CLI) defined by the SQL Access Group does not support this feature, so the ability to invoke multiple repetitions of an SQL operation may not be accessible to application programs that use the CLI. SR/Z39.50 in general provides more flexible retrieval capabilities. It allows the Origin system to specify small, medium and large result set boundaries, and thereby to control the amount of information that is returned in a search response. It does not constrain the syntax of retrieved records, and even allows the syntax selected at time of search to be different from the syntax at time of retrieval using the Present operation. Dynamic definition of record syntax is not explicitly supported at this time, but is being added to SR/Z39.50.
SR/Z39.50 also has features for controlling at the application level the volume of information that is returned. No comparable features are available with RDA/SQL.
One area where RDA provides capabilities that SR/Z39.50 does not is concurrency control. SR/Z39.50 provides no mechanisms to ensure the synchronization of records in a result sets with the databases from which the result set records originated.
The access control features of SR/Z39.50 could be implemented equivalently using the Security Application Service Element being developed by ISO, but this would require a new application context definition.
There is at present no mechanism for achieving the SR/Z39.50 equivalent of resource control within RDA.
SR/Z39.50 does not use the concept of functional units per se, but has an equivalent capability, whereby optional functional capabilities can be negotiated during initialization. Examples of such options, each of which is logically equivalent to a functional unit, are search, present and delete-result-set. Both protocols have equivalent features with regard to negotiation of functional capabilities; they simply use different terminology. When RDA is used in conjunction with the transaction management capabilities provided by the ISO Transaction Processing (TP) protocol (ISO 10026), it can be used to perform information retrieval in a coordinated manner with multiple servers. SR/Z39.50 provides no equivalent capability explicitly. Retrieval from multiple servers must be coordinated explicitly, or an application-context definition could be created to allow the use of SR/Z39.50 with the ISO TP protocol. There is at least one example, Mead Data, where SR/Z39.50 is being used to provide a single point of access to multiple database servers. This is a case where an intermediary system supports both SR/Z39.50 client and server functions, acting as a Target for user Origin systems and as an Origin for multiple database provider systems. The coordination of queries to multiple database Targets is handled locally by the Mead Data intermediary, without the use of additional protocol features.
While the transaction management features of RDA do facilitate information retrieval from multiple database servers, it is not clear whether the additional complexity created by the use of the ISO TP protocol is warranted in a database access environment where the requirement is only for information retrieval.
The first X.400 recommendation were ratified in 1984. Thereafter CCITT and ISO collaborated to produce a multi-part standard for message handling which is editorially and technically aligned with the X.400 standard. The multi-part standard is referred to as MOTIS, or Message oriented Text Interchange (ISO 10021). Both MOTIS and the second series of X.400 recommendations were ratified in 1988.
The component responsible for transferring the message is called the Message Transfer Agent (MTA). It collects messages, sorts them by destination and forwards them in bulk over the network. The MTA also sorts and delivers incoming messages.
The collection of MTAs in a network is called the Message Transfer System (MTS). MTS provides delivery services between UAs just as the post offices in the postal service provide delivery of paper mail to a personal mailbox.
The 1988 version also define how the X.400 electronic messaging system will interact with the Directory services (X.500). Another enhancement is the Physical Delivery Capability (PDC), which allows paper copies of electronic messages to be delivered using physical media such as fax machines. This enables the users to send messages to people who do not have a personal e-mail address.
Security is another enhancement in the 1988 version. Messages can be sent in a cryptic form.
It is important to distinguish between "electronic mail" and "message handling". "Electronic mail" refers to electronic systems that support messaging between users for correspondence purposes. In contrast, "message handling" refers to the exchange of messages in standardized formats so that they may be used by other applications.
| ||
 |
||
|
| ||
| Latest Revision: April 27, 1995 |
Copyright © 1995-2000
International Federation of Library Associations and Institutions www.ifla.org | |