Information and documentation—Information retrieval(Z39.50)—Application service definition and protocol specification
Some standard content:
ICS 35. 240. 30
National Standard of the People's Republic of China
GB/T27702--2011/1S0 23950:1998 Information and documentation
Information retrieval (Z39.50)
Application service definition and protocol specification
Information and documentation--Information retrieval (Z39, 50)-Application service definition and protocol specification(IS23950:1998,IDT)
2011-12-30 Issued
General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China Standardization Administration of China
2012-05-01 Implementation
GH/T 27702—2011/ISO 23950: Before 1998
Existing Normative References
Terms and Definitions
4 Information Retrieval Service
4.1 Model and Characteristics of Information Retrieval Service
4.2 Information Retrieval Service Mechanism
4.3 Message/Record Length and Segmentation
4.1 Operations and Reference Identifiers
4. Concurrent Operations
1.6 Composition Specifications
4.7 Type-1 Queries and Type-li1 Query 5 Protocol specification
5.1 Z39.50 APDU abstract spectrum and ASN.I specification 5.2 Protocol process.
53 Extensibility rules·
5.1 Conformance
Appendix A (normative appendix)
Appendix (normative appendix)
Appendix (existing normative appendix)
Appendix (existing normative appendix)
Appendix E (existing normative appendix)
Appendix F (normative appendix)
Appendix (normative appendix)
Appendix II (viewing normative appendix)
(IJ:739.59) Token identifier
CTX, application environment basic-239,c-ac
ATR: attribute collection
ERR: error diagnosis·||tt ||REC: Record Syntax
RSC: Resource Report Format
A: Access Control Mode
EXT: Extension Services of this Standard
Appendix I (Normative Appendix)
[SR: User Information Format
Appendix K (Normative Appendix)
Appendix I (Normative Appendix)
FSI: Element Format
VAR: Variant Set
TAG: Tag Set Definition and Schema
Appendix M (Informative Appendix)
FRS: Extended Structured Case Model
Appendix N (Informative Appendix)
Appendix 1 (Informative Appendix)
RFT:739. 50 Request
PRO:239.5 Frame support
Designation of maintenance organization
TTTKAONATKACA
This standard was drafted in accordance with the rules given in GB/T1.1-2009, GBT:27702-20111S023950.1998 This standard is equivalent to the international standard IS023950:1908% Information and Documentation Information Retrieval (7.39.50) Application Service Definition and Protocol Specification
This standard has modified the Chinese translation of the international standard IS0)23!50:1998, and the technical content has not been changed. This standard has a total of 16 appendices.
Appendix A to Appendix L are normative appendices, and Appendix M to Appendix P are informative appendices. This standard was proposed and approved by the National Information and Documentation Standardization Technical Committee (SAC/IC:4). This standard was drafted by: China National Defense Science and Technology Information Center, China Institute of Scientific and Technical Information, and Chemical Beijing University. The main drafters of this standard are: Zhen Qian, Gong Changcheng, Tang Shanhong, Li Xiujin, Zhao Jinwei, Feng Meitao, and Chen Bei. TTTKANYKAcA
GB/T:27702—2011/1S023950:1998 Introduction
IS(）239.50 and ANSI/NIS(）Z39.59--199 have alternate contents, but there are some slight differences in style. For example, "Annex" in ANST/NISO Z39.50 is called "Appendix" in ISO 25950. The two standards have related names: "Information Retrieval (239.50): Application Service Definition and Protocol Specification". To avoid the perception that these are two different standards, "239.50" is explicitly used in the names of both standards. The "239.50" refers to the services and protocols defined in this standard. When approved, 15023950 will replace related standards ISO 10162 and ISO 10163. In the rest of this preamble, , all references to Z39.50.-1995 refer to ANS1/NIS() Z39.50-1995. It is identical to [ISO] 23950. All references to Z39.50-1988, Z39.50-1992, and Z39.50-1994 refer to earlier versions that differ from ISO 29.
AVSI/NIS() 239.50-1995 Information Retrieval (Z39.50): Application Service Definition and Protocol Specification" is a revision of AVSI/NISO) 239.50-1992. The draft version of 239.50-1995 refers to 239.50-1904. Implementers should note that none of the drafts reported as 239.50-1591 are the latest versions of the standard. All drafts of 739.50-1994 were proposed before Z39.50-1995. 239.50-1995 is the final version, dated 191. When this protocol was proposed, it was only used in the field of book information. As more and more professional fields became interested in 239.50, the 239.30 Implementation Group (ZIG) was established in 1990. Members of 2IG include manufacturers, retailers, consultants, information providers and universities who want to obtain or provide various information, including book information, text information, image information, financial information, public facilities information, chemical information and news. All interested parties can become members of 2IG. The 239.50 Maintenance Office was established in 1989 and is affiliated with the Library of Congress. Its task was to revise Z39.501988 to make it fully compatible with the international standard ISO10162/10163 Search and Retrieval (SR). At that time, several new features were proposed for the 1992 version to support a variety of information retrieval activities. However, these new features had not yet been fully developed, and if they were included in the 1992 version, it would greatly delay the publication of the standard. Therefore, the Maintenance Office postponed the adoption of the proposal for new features, but at the same time promised implementers that it would continue to develop new features and the next version of the standard would become a superset of the 1952 version. 239.50-1992 replaced 239.50-1985 and became a trend compatible with 1S01016210163 search and request.
In 1992, the Maintenance and Extension Office conducted a survey of 739.50 implementers to determine the importance of proposed new features. The purpose of the survey was to: (a) narrow the features to a manageable size; (b) determine whether the proposed new features were fully described and understood; and (c) estimate their cost and complexity. The survey results showed that some features were essential. 239.501095 was developed in late 1991. From December 1991 to April 1999, the Maintenance Office proposed a revision proposal at every 71° meeting. Implementers carefully read and thoroughly discussed each draft on the 71° Internet mailing list and in meetings. Comments and suggestions on each draft were posted on the 21° meeting; the agreements reached at the meeting were posted on the Office. In April 1994, the 7IG recommended that the draft be finalized. The 1992 version is considered "version 2" and the 1995 version is considered "version 3". These version names actually have specific protocol meanings, but do not refer to standard versions. 2.30.5) 1992 specifies the second version of the protocol; Z39.50-1995 specifies the second and third versions of the protocol. 239.50-:1992 replaces the obsolete 2.39.501988, but 239.501992 and 239.501995 are not the same.The relationship between 239.50-1995 and 239.50-1999 is completely different. 239.50-1999 is a compatible superset of the 1992 version. Implementers can obtain full details of the second version from 239.50-1995. Implementations should be compatible with 239.50-1992. Protocol Basics
This protocol specifies the form and process of information exchange between clients and servers. It enables a client to (a) request that a server search a database and identify records that satisfy a specific request, and (b) retrieve some or all of the identified records. A client may create requests on behalf of a user. This protocol describes the communication between a client and a server (which may be located on different computers). It does not describe the interaction between client users. CB/T 27702—2011/IS023950:1998239.50-1992 and IS023950 both support the following basic functions: The client can send a search request, specifying one or more databases, and including a query and parameters for determining whether the searched records are sufficient to be returned as part of the response. The server responds with the number of records identified and may return some or all of the records. The client can then request the selected records. The client assumes that the retrieved records form a "result set" (an ordered set whose order is determined by the server), which can be referenced according to their position in the result channel: Optional functions include: In some cases, when the client does not want to receive a complete database record request, it can specify a data element to specify the data element to be requested. For example, the client can specify "If the identified records are less than 5, then transmit the complete record; if more than 5, then transmit the "brief record".
The client can specify the preferred syntax for the response record - for example: USMARC. The client can name the result set for later reference. The client can delete the named result set.
The server can require authentication before processing the request to impose access control on the client. The server can provide resource control by sending non-solicited or solicited status reports; the server can suspend processing and allow the client to indicate whether to continue.
Query Expression
IS02395C makes detailed provisions and requirements for the support of Type1 queries. Type1 queries are represented by a search, and each search item has a set of attributes, such as whether the search item type (subject, name, etc.) is blocked, and the structure of the search item. The server is responsible for mapping these attributes to the logical design of the database. In a Type1 query, search items can be combined using Boolean operators. These search items and operators are represented by Boolean notation. Attribute nests
The attributes associated with a search term belong to a particular set of attributes whose definitions are registered, that is, they are assigned a unique, fully identifiable object identifier that is included in the query, the attribute file identifier. Appendix D ERR defines and registers the attribute set bib-1, which describes the various attributes that can be queried using the BIB-1 book. The BIB-1 attribute set was developed by the publishing community; other groups may develop and register attribute sets as needed. Additional attribute sets may be registered outside of IS23950.
Response records
: This protocol divides the records that appear in server response messages into two categories: database records and diagnostic records. Appendix D ERR registers object identifiers for several MARC formats, including USMARC, LKMARC, TWAYMARC, and CANMARC. Database records returned by the server carry these object identifiers. This appendix defines several other types of record formats and specifies methods for registering additional record formats. Diagnostic records also carry object identifiers that identify their format. Appendix D ERR Two diagnostic record formats are defined and registered (Z39.50-1992 defines one of them), including various diagnostic codes for bibliographic applications. Other diagnostic record formats are also registered from time to time.
New Features
The following is a summary of the enhancements to 239.50-1995 (relative to the 1992 version). "Release 2" and "Release 3" are two versions of the protocol; "Z39.50-1992" and "Z39.50-1995" are two versions of the standard. A feature described by "new features of Z39.50:1995" generally applies to both protocol versions. For example, scanning: an implementation can add scanning services to an existing 239.50-1992 implementation without taking advantage of other new features. The following enhancements are described in four categories: slow search, new services and mechanisms, and other enhanced features, search attributes. Flat attributes and attribute sets have many new features. In version 3, the attributes in a single query (or even a single search item) can come from different attribute sets: this has two advantages: first, this feature can be used to search multiple databases (although version 2 supports searching multiple databases, all attributes included in a query must belong to a single attribute set, which restricts the ability to search multiple databases - unless these databases are similar); second, it can reduce duplication when defining new attribute sets: version 3 adds two new features that can flexibly define attribute sets: defining new data types for attribute values (in version 2, attribute values can only be numeric types). Second, the attribute set definition can now list some optional evaluation rules (for example, whether to allow the server to use the attributes it thinks are more appropriate to replace a certain attribute), and you can choose one of them when querying: The enhanced lbih-1 attribute set definition adopts this new feature. In 23.501995 (in addition to including all the attributes in Z30.501992), the bib 1 definition also includes many new attributes. Extended result set model. 739.50 - The basic model for developing result sets in 1992: The 1995 version also describes the "extended result set model", which supports extended proximity search. This extended model also supports a new search function in version 3. It allows records to be selected from the result set based on specified attributes. Restrictions, this function is (in fact) an operation on the result set. The search items used in the query in version 3 can have a variety of data types. (In version 2, the search items are binary types and have no data type in essence. The type is usually described by the result attribute.) In order to reduce the need for structural attributes, this New features will simplify query and attribute set definitions.
Intermediate results. In 739501995, the server reports the progress of the search and can provide information about each query component (that is, each data item in the query) as part of the search response (only in version 3) or as part of the resource control. The server can also create result sets for individual query components and provide access to result sets. Request
Segmentation. In version 2, a request response is confined to a single message. The server tries to fit as many records as possible in the message, and if that doesn't fit, it tries to fit as many records as possible. For example, a client wants to retrieve 10,000 records, and knows that it cannot get all 10,000 records in a single message. The typical approach is for the client to request all 10,000 records, wait for a response to determine how many records were retrieved, and then send another request for the remaining records. In many environments, this approach works well, but on high-speed networks it can be very slow because the server must wait for the request before sending each set of records, which creates a delay. For normal networks, this delay is negligible, but for high-speed networks, this delay is unacceptable. In version 3, the server can use multiple consecutive requests to send the same set of records. The response message responds to a request. There is no need to interleave requests. When a single record is too long to fit in a single message, segmentation becomes more serious. Version 3 introduces two levels of segmentation: a record can span multiple response messages. The client or server can choose to support any level of segmentation, or no segmentation (the version 2 rules apply in this case).
Request tools. To support a variety of request applications, especially document request applications, 2IG has spent more than two years developing an extended model and set of tools with semi-rich request and functionality: Appendix N describes the model in detail. Z3H,50-1995 specifies several new object classes (schemas, tags, and variables) and defines specific objects based on these and other classes. This annex provides detailed definitions of these objects and describes how they can be used together to provide multiple document retrieval capabilities. Here are a few examples: A database record can contain multiple documents. A client can find and retrieve a specific document, but not the entire database record.
The client can request a specific logical or physical part of a document, such as a specific page, a specific chapter, a specific title, all titles, or all images. The client can also request only titles, such as all pages or all section titles. A document can be retrieved in multiple formats (such as OpenScript, SGMI), languages, presentation parameters (such as line length, number of lines per page, columns, etc.), and other variables. The client can discover which variables a document supports and information related to a particular variable form; for example, request the cost of a document according to a specific variable or contributor. Finally, the client can request the document (or a particular part) according to the required variables.
For a given search, associated with a document may be hits: pointers to search terms (in the document) that are relevant to the search. Clients can request hits in a document to quickly locate those parts that satisfy the search. Clients can also request only hits (in non-ordered order of importance) and then retrieve those parts that satisfy the specified total. 1
TTTKAONATKACA
New Services and Mechanisms
H3/T277022011/IS023950:1998
Scanning and Sorting. Scanning and sorting are new services added in 239.50-1995. The former is used to scan search terms in a table or index: the latter is used to sort the result set. It is currently a service that is only available in the Z39.50 browsing mechanism. It is planned to add other browsing functions in future versions. Extension Service Group: Extension Service Group is a new mechanism in Z39.50-1995. It contains a new 239.50 core service, the Extension Service Group service, which is used to create a specific extension service task that is performed outside of the 239.50 session. The progress of the task can be monitored by the 739.0 service. Specific extension services include: saving result sets, setting up periodic query plans, exporting documents, ordering documents, and updating databases:
interpretation. The new interpretation mechanism allows clients to request details of the server implementation: general characteristics (description, contact information, runtime, restrictions, usage fees, etc.), searchable databases, indexes, attribute sets, attribute combinations, schemas, record syntax, sorting capabilities, and extension services. The server maintains interpretation information in a special database. Clients can access this database using the Z39.30 search and retrieval mechanism. This specification describes the format of the interpretation information in detail. Some interpretation information is transparent to the client, so that it is displayed directly to the client user and is also specified by the client (for example, "a property". Some interpretation information calls out to the client and the user. For example, the client can request a list of searchable databases: the client displays an informal name, an icon, and a brief description for each database in the list. At the same time, the client can retain the real database name used in the protocol message and may not display this real name. Some interpretation information is completely transparent to the user. For example, the client can request information about the attributes supported by a database and use this information when forming a query expression (that is, when converting the user-supplied query into an Iype-1 query in z39.50). Other Enhanced Features
Termination and Reinitialization: Version 3 includes more flexible methods for terminating 239,50 sessions: this actually allows for reinitialization without interrupting the network connection,
concurrent operations. Version 3 allows multiple concurrent operations. In version 2, diagnostics are replaced by proof-of-conformance diagnostics. Most 239.50 services include diagnostics. In version 2, a diagnostic must conform to a specific format defined by the standard. In version 3, diagnostic formats can be defined and registered externally. The standard defines such a (new) diagnostic format and comes with a comprehensive set of diagnostics.
Access control formats. Z39.50-1992 provides access control but does not define any access control formats. 239.50-1985 defines encryption and authentication formats and defines formats that allow servers to prompt clients with various information. Character set support A new data type for strings, InternationalString, is defined to allow clients and servers to more flexibly decide whether to use a particular language and one or more character sets in a session. Units of measure. New data types are introduced to support units of measure. These definitions allow the type of unit of measure and the unit of measure to be expressed in a standard way. For example, the type of the unit of measure is "mass" and the unit of measure is "gram". Extensibility and negotiation. Version 3 provides strong extensibility: all protocol information contains a field for marking those information in externally defined formats, which are used as temporary extensions and experiments of 150)235, registered and managed by the 239.5C Continuing Office, and may be merged into other versions. Z39.501995 introduces the concept of "negotiation record". The client machine can include a negotiation record in the initialization message to suggest that certain conditions are valid in the public call (for example, the use of a specific language and one or more character sets). The server can respond to indicate whether the suggestion is accepted or make a counter-suggestion. The negotiation record is an application of the new extensible feature. The negotiation record can be defined externally and maintained in the 23%.50 maintenance center. 1 Scope
GB/T27702—2011IS0239501998
Information and Documentation Information Retrieval (Z39.50) Application Service Definition and Coordination Specification
This standard specifies the application service definition and protocol specification for information retrieval. The service definition part describes the service for implementing the search and retrieval of information in a database in an application: the protocol specification part includes the definition of protocol control information, the rules for exchanging this information, and the consistency requirements that need to be met for the implementation of the plan.
This standard applies to" support information Information retrieval service system, as well as information service agencies, universities, libraries, joint editing centers such as paper
note, Z39.30 has issued materials, Z39.50-1988, 239.50-1902 and Z3U.50: 1995. The issuance and prosecution agreement has a publication: [5101631: 1993239.50-150215001631: 1003 and 239.50-175 (excluding 239.50-15 8) This work describes the concept of protocol version and defines three protocol versions: version 1, version 2 and version 3. 1SC) 01631:1993 is based on the first version of the protocol. Z33.501992 is based on the second version of the protocol. 239.5-:1995 is based on the second and third versions of the protocol. (239.551888 is particularly related to the protocol version.) This standard is based on the second and third versions of the protocol. It assumes that the first and second versions are consistent, and supports the implementation of the second version. Edition (In addition, the 1st edition is not directly mentioned anywhere else in this standard). For references in this standard that only the 2nd or 3rd edition is applicable, a note is given separately.
2 Normative referenced documents
The following documents are indispensable for the application of this document. For any applicable document with a date, only the version with the latest date applies to this document. For applicable documents without a date, the latest version (including all amendments) applies to this document. GB/T1569519 Information Technology Open System Representation Service Definition (IS()/IF8822:1934.IDI) G13/162%2--199% (all parts) Information Technology Abstract Syntax Notation ( ASN.1) specification (IS0/1EC5824: 2002IDT)
GB/T162631996 (all parts) Information technology ASN.1 encoding rules (IS0/1EC5825: 2002.11T) GB/T16587.1-2008 Information technology open system five links, and the connection control service element purple protocol Part 1: Coordination specification (I08650: 1996.1D1) GB/T166882008: Information technology open system connection control service element service definition (IS0/1E86191996, ID)
ANs/NIsOZ39.53-1904 Codes for the presentation of language for information exchange (ANSI/Vis) Z39.58—1992 Common command language for on-line interactive information retrieval (COMMON COMMAND LANGUAGE FOR ONLINE INTERACTIVE INFORMATION RETRIEVAL) 2709:1999 Information and document exchange format (INFORMATION AND DOCUMENTATION - FORMAT INFORMATION INTERCHANGE) 1S0 4217:1990 Codes for the representation of currencies and funds (IS) 7498:1984 Open Systems Interconnection Basic Reference Model (OSI) 1984 8649:1987 Information processing systems - Open systems interconnection - Connection control service - Definition of service (Informatinnpru-cessing systems - Operations interconnection - Protocol specification for the association control service) ISO8649:1987 Information processing systems - Open systems interconnection - Connection control service - Definition of service (Informatinnpru-cessing systems - Operations interconnection - Protocol specification for the association control service) ISO8649:1987 Information processing systems - Open systems interconnection - Connection control service - Definition of service (Informatinnpru-cessing systems - Operations interconnection - Protocol specification for the association control service) ISO8649:1987 Information processing systems - Open systems interconnection - Connection control service - Definition of service (Informatinnpru-cessing systems - Operations interconnection - Protocol specification for the association control service) ISO8822:1988 Information processing systems - Open systems interconnection - Connection oriented presentation service interconnectionConneclin orivnled prcscntation service definition)ISO8824：u9 Information technology open systems interconnection abstract syntax notation (AsN.1) specification (Tnformatiotechnology-()pen systcmn intercannectian-Specification of abstract syntax notation one(ASN-1))IS()8825：1990 Information technology open systems interconnection abstract syntax notation 1 (ASV.1) basic encoding rules specification (Infor-mation technology Open systems interconnection Specificatior of basic encoding rules for abstract syntax notation one(AsN.13)
1so1016o.1997 Information technology open systems interconnection interlibrary loan application service definition (Iufornationanddocumentation (pen xyaten:intertonnertion.Interlibraryloau application service definition)IS0101611：199？ ISO 10163-1:1993 Information and documentation-Open system interconnccion.Inlerlibrary laan application protocol specification, Part 1: Protocol specification) Information znd torumentation (pen sysletns interconnccion-Search Lnd retrieval applicationprotocol spucifiration Part 1: Protocol specification Note: This standard replaces IS(I)10183-1. Due to the existence of an implementation of IS(I)10163-1, this standard sets out some provisions in order to maintain compatibility with IS(I)63-1.
IS(I) International Registration of Coded Character Sets.
3 Terms and Definitions
The following terms and definitions apply to this technical document. 3.1
A-association
See application association.
Abstract database record abstract database record abstract representation of database record information. Applying an abstract record structure (defined by a schema) to a database record forms an abstract database record. Applying a data structure to an abstract database record forms another abstract database record. 3.3
Abstract record structure structurcThe main component of the database schema. Apply the abstract record structure to the database record to form an abstract database record. 3.4
Abstract Syntaxahstractsyntax
Description of a special data type using an abstract syntax notation can be referenced by an object identifier (OID). 3.5
Abstract Syntax NotationabstractsyntaxnntationA language that allows the use of a representation-independent method to describe data types. ASN.1 is an example. 2
Access Pointacuesspointl
GB/T27702—2011/[S023950.1998When accessing a record, a unique key or non-unique key can be specified alone or in combination with other access points. The access point may be equal to a data element defined by the abstract syntax, which is captured from a collection of one or more data elements. The access point may also be unrelated to any data element. 3.7
According to access point clauseType-1 The operand of a query (non-terminal definition). 3.8
Aggregate extract response
agxregate present response
The collective name for the segment request (if any) and the extract response in the operation. 3.9
See application protocol data unit.
Application associationapplicationalion associationA communication session between a database user and a database provider. It can be composed of one or more consecutive 7-link groups. 3.11
application protocol control information format and information exchange rules between the originating party and the destination party. 3.12
application protocol control information total information transmitted by application protocol data unit. 3.13
application protocol data unit
application protocol data unit A unit of information transmitted between the originating party and the destination party, its format is given by 239.50 Protocol specification, consisting of application protocol information and, if applicable, application user data.
Applied variant
One of two uses of a variant specification. An application variant is a variant specification used by the user to request data elements contained in a record. See variant request and supported variants.
See abstract record structure.
Abstract syntax notation specified by IS08824 and IS08825 13.17
Attribute attribule
A feature of a search term or one of several feature components that together constitute a feature of a search term 3.18
Attribute element aitribule element
An attribute represented by an attribute type and a value of that type. 3
GB/T27702—2011/ISO2395019983.19
attributelist
A collection of attribute elements and the attribute set identifiers to which they belong. The attribute list, combined with the search terms, forms the operands of a typed query: In general, an attribute element in the set corresponds to a normalized access point that matches the search terms (defined by the other attribute elements).
attributesetattributese
A collection of attribute types, for each of which there is a list of extended values, each of which is represented by an integer that is unique in the set (represented by its attribute set identifier), and for a given attribute type, each of which is unique. 3.21
attributesetidentifierattributesetid
The object identifier of the attribute set to which an attribute element in the attribute list belongs. 3.22
attribute typeattributetype
a component of an attribute element. An attribute set defines one or more attribute types and assigns an integer to each type (and also defines specific values for each type). For example, bib-1 assigns the integer 1 to the attribute type. 3.23
attribute valueattributevalue
a component of an attribute element. An attribute set defines one or more values for each attribute type it defines. For example, bib-1 defines the attribute value of a person's name.
clientclient
Contains the application of the originating party; the database user. 3.25
clientsystemclientsystcm
The system to which the client belongs.
compositionspecificationcompositionspecificationA specification contained in a request that specifies the composition of the requested record (e.g., data elements and record syntax). It includes a schema identifier, data element specifications, and a record syntax identifier. 3.27
conditionallydefined serviceConditional confirmed service
A service that can be called as a confirmed service or as an unconfirmed service request. A service that may receive a response from the other party after the request is made is a conditional confirmed service. For example, resource control is a conditional confirmed service created by the H. See unconfirmed service and confirmed service, 3.28
Confirmed service service
A service that must have a response after a request (sent by the originating party or the destination party) is a confirmed service: search is a confirmed service created by the originating party, and access control is a confirmed service created by the destination party. See also conditional confirmed service and non-confirmed service. 3.29
Databasedatabasc
A collection of information units containing related information, where each unit is a database record. 3.30
Database recordlatabaserecord
Represents the same data structure of an information unit in the database. dntabaseschema
Database schema
GB/I 27702—2011/ISO 23950: 1998 A common understanding of the information contained in a database record that allows selection of parts of that information through data element specification. A schema defines the structure of an abstract record that is applied to a database record.
Data element dataelement
See data element.
Data element element
Unit of information defined by a schema.
Data element request
element request
A data element specification is a request to retrieve a specified data element. A data element request may contain: a variable specification indicating the variable form of the desired data element
Data element set name element set name a data element specification in the form of a base name. 3.36
element specificatiun
Data element specification
An example of a data element specification format or a data element set name. A data element specification transforms one abstract database record into another abstract database record (this may be an empty transformation). A data element specification selects data elements from the abstract database record and may specify variations for those data elements.
Data element specification formatThe element specification format is used to represent the structure of a data element specification.
Data element specification identifier
element specificatien identifierThe object identifier of the data element specification format or the name of the data element set. 3.39
Exceptional record size
Exceptional record length
The maximum length of a record that may be included in a request response in special circumstances, when a record that is unusually long (i.e., longer than the preferred message length) is required.
Facility
A logical grouping of Z39.5 services, sometimes a single service. For example, a retrieval facility consists of a retrieval service and a fragmentation service; a search facility consists of a search service. Alternatively, a facility may consist of no services, but of services that utilize other mechanisms. For example, a solution facility does not define any services, but uses both search and retrieval services.3.41
Final fragment
A fragment that ends at the end of a record. See fragment.523
Attribute valueattributevalue
A component of an attribute element. An attribute element defines one or more values for each attribute type it defines. For example, the attribute value of bib-1 is "name".
Clientclient
Contains the originating application; the database user.3.25
Client systemclientsystcm
The system to which the client belongs.
Composition specificationcamposIonspecificationContains a specification in a request to obtain a record, which specifies the composition of the record (e.g., data elements and record syntax). It includes a schema identifier, data element specifications, and a record syntax identifier3.27
conditionallyconfirmed serviceConditionally confirmed service
A service that can be invoked as either a confirmed service request or an unconfirmed service request. A service that can have a response from the other party after the request (from the originating party or the destination party) is a conditionally confirmed service. For example, resource control is a conditionally confirmed service created by H. See unconfirmed service and confirmed service. 3.28
confirmed service
A service that must be responded to by (the other party) after a request (issued by the originating party or the destination party) is a confirmed service: search is a confirmed service created by the originating party, and access control is a confirmed service created by the destination party. See conditional confirmed service and unconfirmed service. 3.29
databasedatabasc
A collection of information units containing related information, where each unit is a database record. 3.30
database recordlatabaserecord
The same data structure that represents an information unit in the database. dntabaseschema
Database schema
GB/I 27702—2011/ISO 23950: 1998The common understanding of the information contained in a database record by the originating party and the destination party, which allows the selection of parts of this information through data element specifications. A schema defines an abstract record structure that, when applied to a database record request, results in an abstract database record.
data element dataelement
See data element.
data element element
unit of information defined by a schema.
data element request
element request
A data element specification is a request to retrieve a specified data element. A data element request may contain: a variable specification indicating the variable form of the desired data element
data element set name an element set name a data element specification in the form of a base name. 3.36
element specification
data element specification
an instance of the data element specification format or data element set name. A data element specification transforms one abstract database record into another abstract database record (this may be an empty transformation). A data element specification selects data elements from an abstract database record and may specify variant forms for those data elements.
The element specification format is used to represent the structure of the data element specification.
The element specification identifier
The element specificatien identifier is the object identifier of the data element specification format or the data element set name. 3.39
Exceptional record size
Exceptional record length
The maximum length of a record that may be included in a request response in special circumstances, when a record that is unusually long (i.e., longer than the preferred message length) is required.
Facility
A logical grouping of Z39.5 services, sometimes a single service. For example, a retrieval facility consists of a retrieval service and a fragmentation service; a search facility consists of a search service. Alternatively, a facility may consist of no services, but of services that utilize other mechanisms. For example, a solution facility does not define any services, but uses both search and retrieval services.3.41
Final fragment
A fragment that ends at the end of a record. See fragment.523
Attribute valueattributevalue
A component of an attribute element. An attribute element defines one or more values for each attribute type it defines. For example, the attribute value of bib-1 is "name".
Clientclient
Contains the originating application; the database user.3.25
Client systemclientsystcm
The system to which the client belongs.
Composition specificationcamposIonspecificationContains a specification in a request to obtain a record, which specifies the composition of the record (e.g., data elements and record syntax). It includes a schema identifier, data element specifications, and a record syntax identifier3.27
conditionallyconfirmed serviceConditionally confirmed service
A service that can be invoked as either a confirmed service request or an unconfirmed service request. A service that can have a response from the other party after the request (from the originating party or the destination party) is a conditionally confirmed service. For example, resource control is a conditionally confirmed service created by H. See unconfirmed service and confirmed service. 3.28
confirmed service
A service that must be responded to by (the other party) after a request (issued by the originating party or the destination party) is a confirmed service: search is a confirmed service created by the originating party, and access control is a confirmed service created by the destination party. See conditional confirmed service and unconfirmed service. 3.29
databasedatabasc
A collection of information units containing related information, where each unit is a database record. 3.30
database recordlatabaserecord
The same data structure that represents an information unit in the database. dntabaseschema
Database schema
GB/I 27702—2011/ISO 23950: 1998The common understanding of the information contained in a database record by the originating party and the destination party, which allows the selection of parts of this information through data element specifications. A schema defines an abstract record structure that, when applied to a database record request, results in an abstract database record. bZxz.net
data element dataelement
See data element.
data element element
unit of information defined by a schema.
data element request
element request
A data element specification is a request to retrieve a specified data element. A data element request may contain: a variable specification indicating the variable form of the desired data element
data element set name an element set name a data element specification in the form of a base name. 3.36
element specification
data element specification
an instance of the data element specification format or data element set name. A data element specification transforms one abstract database record into another abstract database record (this may be an empty transformation). A data element specification selects data elements from an abstract database record and may specify variant forms for those data elements.
The element specification format is used to represent the structure of the data element specification.
The element specification identifier
The element specificatien identifier is the object identifier of the data element specification format or the data element set name. 3.39
Exceptional record size
Exceptional record length
The maximum length of a record that may be included in a request response in special circumstances, when a record that is unusually long (i.e., longer than the preferred message length) is required.
Facility
A logical grouping of Z39.5 services, sometimes a single service. For example, a retrieval facility consists of a retrieval service and a fragmentation service; a search facility consists of a search service. Alternatively, a facility may consist of no services, but of services that utilize other mechanisms. For example, a solution facility does not define any services, but uses both search and retrieval services.3.41
Final fragment
A fragment that ends at the end of a record. See fragment.5--A logical grouping of services that may be a single service. For example, a retrieval mechanism consists of an extraction service and a segmentation service; a search mechanism consists of a search service. Alternatively, a mechanism may not consist of services, but may make use of services from other mechanisms. For example, a resolution mechanism does not define any services, but makes use of search and extraction services. 3.41
final fragment
A fragment that ends at the end of a record. See fragment. 5--A logical grouping of services that may be a single service. For example, a retrieval mechanism consists of an extraction service and a segmentation service; a search mechanism consists of a search service. Alternatively, a mechanism may not consist of services, but may make use of services from other mechanisms. For example, a resolution mechanism does not define any services, but makes use of search and extraction services. 3.41
final fragment
A fragment that ends at the end of a record. See fragment. 5
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.