• 3 Information Retrieval Service
• • 3.2 Facilities of the Information Retrieval Service
  • • 3.2.1 Initialization Facility
    • • 3.2.1.1 Init Service
      • 3.2.2.1 Search Service
      • 3.2.3.1 Present Service
      • 3.2.3.2 Segment Service
      • 3.2.4.1 Delete Service
      • 3.2.5.1 Access-control Service
      • 3.2.6.1 Resource-control Service
      • 3.2.6.2 Trigger-resource-control Service
      • 3.2.6.3 Resource-report Service
      • 3.2.7.1 Sort Service
      • 3.2.8.1 Scan (Browse) Service
      • 3.2.9.1 Extended Services Service
      • 3.2.10 Explain Facility
      • 3.2.11.1 Close Service
  • 3.6 Composition Specification.
  • • 3.6.2 Comp-spec Omitted.
    • Brief Element Set (B)
    • Price Element Set (P)
  • 3.7 Type-1 and type-101 Queries.
• Appendix 3. ATR: Attribute Sets.
• • Table A-3-1. Use Attributes.
  • Table A-3-2: Bib-1 Relation Attributes.
  • Table A-3-3 Bib-1 Position Attributes.
  • Table A-3-4 Bib-1 Structure Attributes
  • Table A-3-5 Bib-1 Truncation Attributes.
  • Table A-3-6 Completeness Attributes.
  • Table A-3-7 Z39.50 Version-3 Compliance.

ProQuest Direct

Z39.50

Protocol Implementation Specification

Revision B

U-M-I

300 North Zeeb Road

Ann Arbor, Michigan 48106

Revision History

Notice of Proprietary Information

All information contained in or disclosed by this

document is confidential and proprietary to

University Microfilms, Int. (U-M-I).

By accepting this material the recipient agrees

that this material and the information contained

therein will be held in confidence and will not

be reproduced in whole or in part without

express written permission from U-M-I.

File Name: R:\PROJECTS\ADDS\DOCS\OCLCZ39\Z39IMPL4.DOC

Copyright Ó 1996 University Microfilms, Int.

31

3 Information Retrieval Service

3.2 Facilities of the Information Retrieval Service

3.2.1 Initialization Facility

3.2.1.1 Init Service

The Init service allows an origin to propose values for initialization

parameters. The target system may propose alternative values for some of

the parameters. If so, the origin must either accept the alternative values proposed by the target or else terminate communication.

3.2.1.1.1 Version

Both the origin and target indicate all versions that they support.

UMI: Version 2 (Z39.50-1992).

NOTE: Although this server meets the core requirements for version-3, we still set the version parameter to version-2 because we do not support the majority of the version-3 functionality.

3.2.1.1.2 Id/Authentication

The origin and target agree, outside the scope of the standard, whether or

not this parameter is to be supplied by the origin, and if so, what the value

is. This value is used by the target to determine if the origin is authorized

to enter into communication with the target.

UMI expects the following format:

IdAuthentication [7] CHOICE{

open VisibleString,

idPass SEQUENCE{

groupId [0] IMPLICIT OPTIONAL,

userId [1] IMPLICIT GeneralString OPTIONAL,

password [2] IMPLICIT GeneralString OPTIONAL}}

If the “open” method is used, we expect a UMI user-id(authorization

number) followed by a slash ('/') followed by a password. E.g.

100023456/antimony.

If the “idPass” method is used, the groupId, if provided, is ignored.

3.2.1.1.3 Options

The Init request specifies either "will use" or "will not use", and the Init response specifies "will support" or "will not support" for the following capabilities:

1. search **

2. present **

3. delete

4. resource-report

5. trigger-resource-control

6. resource control

7. access control

8. scan **

9. sort

10. extended-services

11. level 1 segmentation

12. level 2 segmentation **

13. concurrent operations

14. named result sets **

** UMI supports these options

3.2.1.1.4 Preferred-message-size and Exceptional-record-size

The Init request contains the origin’s proposed values of Preferred- message-size and Exceptional-record-size, specified in bytes. The Init response contains the Preferred-massage-size and Exceptional-record-size that the target is going to use; these may be different from (and override) the values proposed by the origin.

UMI: We will accept Preferred-message-size and Exceptional-record-size values up to 1,048,576.

3.2.1.1.5 Result

The target indicates whether or not it accepts the association by specifying a value of "accept" or "reject" in the parameter Result. If "reject" is indicated, the origin is expected to terminate communication.

UMI: If the result is “reject”, the socket connection is dropped.

3.2.1.1.6 Implementation-id, Implementation-name, and Implementation-version.

We don’t do anything with this if it is present in the request. The init response contains “1996”, “UMI”, and “1.0” for Implementation-id, Implementation-name, and Implementation-version.

3.2.1.1.7 User-information-field

This field may be used by either the origin or target for additional information not specified by the Z39.50 standard.

UserInformation ::= SEQUENCE {

motd [1] IMPLICIT VisibleString,

dblist SEQUENCE OF DBName,

failReason [3] IMPLICIT SEQUENCE {

diagnosticSetId OBJECT IDENTIFIER OPTIONAL,

code [1] IMPLICIT INTEGER,

text [2] IMPLICIT VisibleString OPTIONAL }

OPTIONAL

}

DBName ::= [2] IMPLICIT VisibleString

UMI: motd contains a “message-of-the-day”. We currently have

“Welcome to the Proquest Direct Z39.50 Gateway” as the message of the

day. This field could also contain other notices for users, including dates

and times for expected system downtime, etc. The dblist contains a list of

the databases available on the server, this is always “PQD”. The failReason

contains additional information when the result is “reject”.It will contain a

code and a text message describing in more detail why the init was

rejected.

3.2.1.1.8 Other-information.

Ignored.

3.2.1.1.9 Reference-id

See section 3.4.

UMI: We will echo back whatever you send us.

3.2.2.1 Search Service

3.2.2.1.1 Query-type and Query

Five types are defined by the standard: type-0, type-1, type-2, type-100, type-101.

UMI: Supports both the type-1 and type-101 queries.Type-1 is a “Reverse Polish Notation” (RPN) query specified in section 3.7. Type-101 queries are RPN queries that allow proximity searching.

Truncation (?) and embedded truncation (wild card) characters (#) are accepted as part of the query term. Result set id names may be used as operands on subsequent searches.

Plural and possessive forms of the query term may be obtained by adding a “+” to the end of the term. For example, “child+” will return: child, children, child’s, and children’s.

See also the following sections (below):

3.7 Type-1 and type-101 Queries

Appendix 3. ATR: Attribute Sets

3.2.2.1.2 Database-names

The target designates, by agreement outside the scope of the standard, what databases may be specified on a Search request, and also in what combinations they may be specified. For example, a target might specify that databases A, B, and C, may be searched individually, and that A and B may be searched in combination (but not A and C, nor B and C). If an origin requests a combination of databases which is not supported, the search will result in a diagnostic such as "combination of specified databases not supported".

UMI: We currently support only 1 database, ProQuest Direct (PQD). “PQD” must be the name used in the search request.

3.2.2.1.3 Result-set-name and Replace-indicator

The parameter Result-set-name specifies a name to be given to the result set which will be created by the query so that it may be subsequently referenced within the same association.

UMI: We support arbitrarily long Result-set-names, and put no limit on the number of ResultSetNames that can be used.PQD will save up to 100 result sets for a 24-hour period.

We ignore the Replace-indicator and automatically replace old result sets when a ResultSetName is reused.

3.2.2.1.4 Small-set-element-set-names and Medium-set-element-set-names

An element set name is a primitive name which specifies a particular subset of the elements in a database record which are to compose the response records. The specified subset is made up of components of the abstract- syntax description of the database records and is, therefore, a formal subset of that abstract-syntax-definition. Element set names are specified, along with their definitions, for a given database, by the target, outside of this standard. The target specifies a default element set for each database.

UMI: We support 2 element set types for piggyback search

requests. This is a subset of the 4 types supported for present requests (see Present Service, 3.2.3.1). The two elements sets available are:

“B” - Brief record (title, journal, author, date.) There is no charge for this type. It is returned by default.

“P” - Price and Availability. (title, journal, author, date, delivery methods, element sets available, price). There is no charge for this record format. You can request the “P” element set in order to determine the whether fulltext (“T”) or abstract (“F”) element sets are available, and what the prices are for each.

For more information on the USMARC tag fields/Bib-1 Use Attributes included in each element set, see 3.6, Composition Specification.

3.2.2.1.5 Preferred-record-syntax

The parameter Preferred-record-syntax identifies the preferred abstract syntax for the records to be returned, from among the set of abstract syntaxes for records for which presentation contexts are currently established for this application association. If the target cannot supply the information in the requested abstract syntax, it will supply it in one of the other abstract syntaxes from the established set.

UMI: We return documents in one of three abstract syntaxes: OCLC’s ANS.1/BER format (OID: 1.2.840.1003.5.1000.17.1), USMARC format (OID: 1.2.840.1003.5.10, or SUTRS (simple unstructured text record syntax, OID: 1.2.840.1003.5.101). The default is OCLC BER syntax.

3.2.2.1.6 Small-set-upper-bound, Large-set-lower-bound, and Medium- set-present-number

The result set is considered a "small-set", "medium-set", or "large- set", depending on the values of parameters Small-set-upper-bound and Large-set-lower-bound of the Search request, and Result-count of the Search response (see section 3.2.2.1.8). The result set is a small-set if Result-count is not greater than Small-set-upper-bound. The result set is a large-set if Resultcount is larger than or equal to Large-set-lowerbound. Otherwise, the result set is a medium-set.

UMI: The use of these parameters is exactly as specified by the protocol.

3.2.2.1.7 Response records.

The target processes the search, creating a result set which identifies a set of database records. It cannot be assumed however that search processing requires physical access to the database records; thus one or more records might not be returnable, but this circumstance might not be recognized until an attempt is made to transfer such a record. After processing the search, the target attempts to retrieve the first N records identified by the result set, to be included in the Search response (N depends on the search parameters and result-count, as described in 3.2.2.1.6). For each record which cannot be returned, a surrogate diagnostic record is substituted. Thus the parameter Database/diagnostic- records is one of the following:

• N database and/or diagnostic records,

• A number of database and/or diagnostic records, which is less than N because of message size constraints;

• A single non-surrogate diagnostic record indicating that the search cannot be processed, and why it cannot be processed; or

• A single non-surrogate diagnostic record indicating that records cannot be presented, and why not, e.g. "element set name not valid for database".

The order of occurrence of records (database and/or surrogate diagnostic) within the parameter Database/diagnostic-records is according to the order in which they are identified by the result set. Each database or surrogate diagnostic record may optionally be accompanied by the name of the database in which the record resides. However, the database name must accompany the first database or surrogate diagnostic record being returned, and must accompany any record coming from a database different than its immediate predecessor.

UMI: The database name (“PQD”) is returned with the first response record only. Diagnostic Set Bib-1 is used for standard error codes/messages. UMI-specific error messages have a code of 100 (unspecified error).

3.2.2.1.8 Result-count and Number-of-records-returned

The parameter Result-count is the number of records identified by the result set. If the result set is empty, result-count is zero. The parameter Number-of-records-returned is the total number of records (database and diagnostic) returned in the Search response.

UMI: The result count is the total number of documents that satisfy the search request (this may be less than the number of records returned). The number of records returned does not include diagnostic records.

3.2.2.1.9 Next-result-set-position

The parameter Next-result-set-position specifies the position within the result set of the next record following those returned (or zero if the last record in the result set is being returned).

3.2.2.1.10 Search-status

The parameter Search-status, returned in the response, assumes one of the following two values:

success (1) -...the search completed successfully

failure (0) -...the search did not complete successfully

UMI: We sometimes return a status of “failure” if the results are partial. This may happen in cases in which the query is so broad (and the client has asked for so many documents to be returned), that due to system resource limitations, we cannot return all of the documents that satify the search criteria. In those cases, the search status = failure(0), the result-set- status=subset(1), and the present status=failure(5). An appropriate diagnostic error message that suggests methods for narrowing the search is returned. The subset results are accessible via subsequent present requests.

3.2.2.1.11 Result-set-status and Present-status

These are status descriptors necessary to disambiguate certain situations that can occur during search and present operations. Result-set-status occurs if and only if the value of Search-status is "failure", and its value is one of the following:

subset (1) - Partial, valid results available.

interim (2) - Partial results available, not necessarily valid.

none (3) - No results available (result set is empty).

UMI: A result-set-status of “subset” is possible in the case noted above (search status, 3.2.2.1.10). For all other search failures, the result-set-status is set to “none”.

Present-statuses can have one of the following values: success(0), partial-1 (1), partial-2 (2), partial-3 (3), partial-4 (4), and failure(5).

success-0 - All of the expected database (or surrogate diagnostic) records are available.

partial-1 - Not all of the requested response records can be returned because the response was terminated by access control.

partial-2 - Not all of the expected response records can be returned because they will not fit within the preferred message size.

partial-3 - Not all of the expected response records can be returned because the request was terminated by resource control, at origin request

Partial-4 - Not all of the expected records can be returned because the request was terminated by resource-control at target.

Failure-5 - None of the expected database (or surrogate diagnostic) records can be returned. A single diagnostic is returned, which is not a surrogate for a database record.

UMI: Partial successes due to message size limits are coded as success(0)

3.2.2.1.12 Additional Search Information.

On the response, the target may use this parameter to convey information which is a by-product of the search process On the request, the origin may use this parameter to indicate the preferred format or content of that information. User Information format SearchResponse-1 has been defined for use with this tag. Additional Search Information may only be used with version 3 of the protocol.

UMI: We occasionally use the Additional Search Information as part of the search response. When we do, the OtherInformation “category” is characterInfo (2), and the text message is likely to be advisory information for achieving better search results. We don’t interpret the Additional Search Information tag if it is included as part of a search request.

3.2.2.1.13 Other Information.

This parameter may be used by either the origin or the target for additional information not specified by the standard. This parameter may be used only when version 3 is in force.

UMI: We interpret the Other-information tag when it is a part of a search request. We don’t use it for search responses.

3.2.2.1.14 Reference-id See section 3.4

UMI: We echo back whatever you send us.

3.2.3.1 Present Service

3.2.3.1.1 Number-of-records-requested and Result-set-start-position

The origin requests the return of N records beginning at record M, from the result set, where N = Number-of-records-requested and M = Result- set-start-position (and N is not greater than (Result-count - M) + 1).

3.2.3.1.2 Additional Ranges.

Not currently supported.

3.2.3.1.3 Result-set-id

Result-set-id specifies the result set from which records are to be retrieved. It is the result set created by a previous Search request for which the value of the parameter Result-set-name matches the value of Result-set-id.

3.2.3.1.4 Element-set-names

The parameter Element-set-names describes the preferred composition of the records expected in the present response.

UMI: We accept five different “element set” types:

“B” - Brief record (title, journal, author, date.) There is no charge for this type. It is returned by default on piggyback searches

“F” - Full record (all bibliographic & index fields, including abstract but excluding fulltext). There is a charge for this document format. (unless included within a subscription)

“T” - Full record + fulltext. There is a charge as stated with “F”.

“P” - Price and Availability (title, journal, author, date, format, availability, price). There is no charge for this record format.

“Image” - Image. The full-page image of the document. This element set is available in PDF record syntax only. As with “T” and “F” there is a charge for this element set.

If the requested element is not available for one of the documents, we will substitute a “lesser” format (e.g. substitute “F” for “T”, or “B” for “F”). If “Image” is requested but not available there will be no substitution of a different element set. Instead a diagnostic will be returned. Subscription customers will not be charged for any of the element set types, if the document requested is part of their subscription bundle.

3.2.3.1.5 Preferred-record-syntax

UMI: One of four record syntaxes may be requested: raw ASN1/BER (OID: 1.2.840.10003.5.1000.17.1), US MARC (OID 1.2.840.10003.5.10), SUTRS (Simple Unstructured Text Record Syntax - OID 1.2.840.10003.5.101), or PDF (OID: 1.2.840.10003.5.1000.68.1). PDF syntax is available for the “Image” element set only.

3.2.3.1.6 Comp-spec.

Not currently supported.

3.2.3.1.7 Max-segment-count, Max-segment-size, Max-record-size.

These parameters should only be included when level-2 segmentation is in effect.

Max-segment-count specifies the maximum number of segments the target may include in the aggregate Present response. If its value is 1, no segmentation is applied for the operation. If not included, it is assumed the origin can receive as many segments as are required to satisfy the request.

Max-segment-size is the largest allowable segment. If not included, it assumes the value of Preferred-message size.

Max-record-size is the largest allowable retrieval record within the aggregate Present response. If not included, Max-record-size would assume the value Max-segment-count * Max-segment-size.

3.2.3.1.8 Response-records

This parameter consists of a sequence of response records, or one or more non-surrogate diagnostic records indicating that the request cannot be processed, and why not. The first record will be accompanied by the name of the database.

3.2.3.1.9 Number-of-records-returned and Next-result-set-position

The parameter Number-of-records-returned is the total number of database and diagnostic records returned. Next-result-set-position is the position within the result set of the next record following the last database or surrogate diagnostic record being returned (or zero, if the last database or surrogate diagnostic record in the result set is being returned).

3.2.3.1.10 Present-status

Present-status is mandatory in a Present response and its values are the same as those listed for Present-status in 3.2.2.1.11.

UMI: The following present statuses are returned: 0 (success), 5 (failure), 2 (partial due to message size limitations), or 4 (partial, for a reason other than message size).

3.2.3.1.11 Other Info.

Not currently used.

3.2.3.1.12 Reference-id

UMI: We'll echo back whatever you send us.

3.2.3.2 Segment Service

If segmentation is in effect, and the record(s) requested by a Present request will not fit in a single segment, the target returns multiple segments, each of which contains a portion of the record(s). Each except the last segment is returned as a Segment request. The last segment is returned as a Present response.

3.2.3.2.1 Segment-records.

The parameter Segment-records may include complete response records as well as fragments. Each response record and starting fragment will be accompanied by the name of the database to which it pertains. Each fragment will also include the PDF record syntax field. A fragment is a proper substring of a record. Segmentation of a record results in two or more fragments whose concatenation (not including protocol control information) results in the original record. A starting fragment is a fragment that starts at the beginning of a record. An intermediate fragment is a fragment that neither starts at the beginning nor ends at the end of a record. A final fragment is a fragment that ends at the end of a record. The sum of the sizes of the complete records and record fragments in a segment, not including protocol control information, will not exceed Max- segment-size.

3.2.3.2.2 Number-of-records-returned.

This is the total number of complete response records and starting fragments included within the segment. NOTE: if a Segment request only contains an intermediate fragment, this parameter will be zero.

3.2.3.2.3 Other-information.

Ignored.

3.2.3.2.4 Reference-id.

UMI: We’ll echo back the reference-id sent in the Present request.

3.2.4.1 Delete Service

UMI: We do not currently support this service.

3.2.5.1 Access-control Service

UMI: We do not currently support this service.

3.2.6.1 Resource-control Service

UMI: We do not currently support this service.

3.2.6.2 Trigger-resource-control Service

UMI: We do not currently support this service.

3.2.6.3 Resource-report Service

UMI: We do not currently support this service.

3.2.7.1 Sort Service

UMI: We do not currently support this service.

3.2.8.1 Scan (Browse) Service

3.2.8.1.1 Database Names

The database name is “PQD”.

3.2.8.1.2. Term-list-and-start-point.

The origin supplies an attribute list and term.

UMI: Our implementation is a little non-standard, due to the hierarchical nature of the PQD Table of Contents. It is intended to allow customers to browse our database in the same manner that they would the table of contents of a book. They will be scanning through a three-level hierarchy of journal index, volume and issue index, and article index. At the lowest level, the article index, they may select a document to view online.

This is how it is intended to work:

1. The client supplies a term (or “phrase”) that they wish to search for in the journal index, followed by the ScanJournalIndex “use” attribute (201), and an (optional) structure attribute. This is what “term list and start point” should contain for the first scan request.

2. Our server responds with a list of journals containing that term or phrase. In the “alternate” term part of the “entries” field of the response will be a numeric identifier for each journal.

3. The client submits a second scan request that uses the alternate term (numeric identifier for a journal), followed by the ScanIssueIndex “use” attribute (202). This is what the “term list and start point” should contain in the second scan request.

4. Our server responds with a list of all the available volumes and issues for the selected journal. In the “alternate” term part of the “entries” field will be a numeric identifier for each volume/issue.

5. The client submits a third scan request that uses the alternate term (numeric identifier for an issue), followed by the ScanArticleIndex “use” attribute (203). This is what the “term list and start point” should contain in the third scan request.

6. Our server responds with a list of all the available article titles for that volume and issue.

7. The client submits a search request for the selected article. The search may be a “piggyback” search (for either the B or P element sets).

Note: At any point in the hierarchy, it is possible for the client to scroll in the current index (e.g. journal) by submitting a second or third scan request using the same “use” attribute & the same query (but a different position in response parameter) as the previous request.

Although the scan “term” is not a type-1 or type-101 query, it is possible to use the Z39.50 embedded truncation (wildcard) character (#) as part of the term. It is also possible to truncate the term by using our non-standard truncation character(?). Phrases (e.g. The New Yorker, Washington Post) can be searched by using a structure attribute of “phrase”. The default structure attribute is “phrase” for the ScanJournalIndex (201), word for the others.

3.2.8.1.3 Step-size.

A default step-size of 0 (don’t skip any entries) is assumed.

3.2.8.1.4 Number of Entries.

As per the standard.

3.2.8.1.5 Position-in-Response

Our use of this is somewhat non-standard. We use the Position-in- Response parameter to indicate the start point in the result set (similar to Present requests), not the position of the “seed” term on the screen. Clients can use this parameter (by incrementing or decrementing it) to scroll through the journal, issue and article indexes. An attempt to scroll beyond the “top” or “bottom” of the result set will return either a status of partial-4 or failure, depending on whether there are some entries to be retrieved (see Scan-status, below). The default value for this parameter is 1 (the top of the term list).

3.2.8.1.6 Scan-status

Our implementation returns the following scan statuses: success (0), partial_2 (only some of the records could be returned due to message size limitations), partial_4 (the result set contains less records than requested), and failure (5).

3.2.8.1.7 Entries

This consists of N entries, where each entry is a “term list-entry” or surrogate diagnostic. “Entries” may also include one or more non- surrogate diagnostic records.

In our implementation, every “term-list” consists of the term itself, and an alternate term. The alternate term has the form of “AttributesPlusTerm” (numeric identifier for the selected journal or issue plus the “use” attribute for the next scan operation). For example, if the first scan request was for journals containing the term “education”, the alternate term field will contain the numeric identifier for each journal that satisfies the request, as well as the value of the ScanIssueIndex “use” attribute (202).

The structure of the entries field follows the Z39.50 standard, and can be represented as follows:

entries[7]

|

ListEntries [1]

|

TermInfo [1]

|

[Term[45] --- alternativeTerm [4]]

|

AttributePlusTerm [102]

|

[AttributeList[44] --- Term[45]]

|

ASN.1 Sequence[16]

|

[attributeType[120] --- attributeValue[121]]

There are also two surrogate diagnostic records that are included with all responses that return terms. These mark the beginning and ending of the term list. We use the DefaultDiagFormat for these records, with the Object Identifier for the Bib-1 Diagnostic set as the diagnosticSetId, 241 for the condition code (Scan: Beginning or end of term list)and a VisibleString (“No more terms in this direction”) for addinfo.

When the scan request is not successful, we return a non-surrogate diagnostic to the client. Again, the diagnostic set used is Bib-1. In cases of UMI-specific errors, the code return may be generic (100), but the message will reveal the source of the problem. Two commonly seen error messages are “Sorry, but at this time we do not have issue-level details for this information source”, and “Sorry, but at this time we do not have document-level details for this information source”. These message are common because UMI’s journal, issue, and article indexes are fairly comprehensive and may include items only available in paper form through UMI’s document delivery service, the InfoStore (for more information about this service, see your UMI sales representative).

3.2.8.1.8. Other-information.

If there are entries returned in the scan response (scan status isn’t = failure), then the Other_information field contains the total number of entries available from UMI (which may be more than requested). The “category” for this information is binaryInfo (3), an implicit octet string.

3.2.8.1.9. Reference-id.

We echo whatever was in the request.

3.2.9.1 Extended Services Service

UMI: We do not currently support this service.

3.2.10 Explain Facility

UMI: We do not currently support this facility.

3.2.11.1 Close Service

The Close service allows either an origin or target to abrubtly terminate all active operations and to initiate termination of the Z-association.

UMI: The server will accept a Close PDU and will disconnect the user from the database. No further actions can take place until the origin sends another Initialization request.

3.2.11.1.1 Close-reason.

This parameter indicates the reason why the origin or target is closing the Z-association.

3.2.11.1.2 Diagnostic-information.

The target may include an optional text message, providing additional diagnostic information.

3.2.11.1.3 Resource-report-format.

Ignored.

3.2.11.1.4 Other-information.

Ignored.

3.2.11.1.5 Reference-id.

UMI: We echo the value sent in the request.

3.6 Composition Specification.

We don’t currently support the use of the Comp-spec parameter on Present requests.

3.6.2 Comp-spec Omitted.

We support the following element set types: B (brief), P (price information), F (full bibliographic record), T (fulltext), and Image (full document Image). All element sets, except Image, are available in the ASN.1/BER record syntax. Element sets B and F are also available in SUTRS and USMARC syntaxes. Element sets T and P are available in the SUTRS format. Element set “Image” is available in PDF record syntax only. Element set “B” and ASN.1/BER syntax are the defaults. If the “Image” element set is requested it is always returned in PDF record syntax. If PDF record syntax is requested for any element set besides “Image”, the records will be returned in MARC record syntax. If element set “T” is requested in PDF record syntax, an error is returned. Tables describing the composition of the “B” and “P” element sets follow.

Brief Element Set (B)

Price Element Set (P)

3.7 Type-1 and type-101 Queries.

The RPN query has the following structure:

RPN-query ::= argument |

argument+ argument + operator

argument ::= operand | RPN-query

operand ::= AttributeList + term |

Result-set-id

operator ::= AND | OR | AND-NOT | Prox

Where ::= means "is defined as",

| means "or",

+ means "followed by", and + has precedence over | (i.e., + is evaluated before |).

UMI supports the AND, OR, AND-NOT, and Proximity operators. We do not support the Restriction operator or the Extended Result Set Model for Proximity. Result-set-ids may not be used as operands.

Appendix 3. ATR: Attribute Sets.

UMI uses the attribute set Bib-1. This is composed of the following attribute types: use, relation, position, structure, truncation, completeness.

Table A-3-1. Use Attributes.

The table on the following pages lists all the Bib-1 use attributes used by UMI. Please note: the “search mnemonics” in column three can be used instead of the use attributes only with UMI’s client. Tables in section 3.6, Composition Specification, list the attributes (and their USMARC tag equivalents) for some of the UMI element set types.

Table A-3-2: Bib-1 Relation Attributes.

These attributes are currently ignored. Relations are always assumed to be “equal”.release of the software, relation attributes are ignored. In the next release, there will be some support for it, which will make date range searching possible.

Table A-3-3 Bib-1 Position Attributes.

These attributes are currently ignored.

Table A-3-4 Bib-1 Structure Attributes

The Z39.50 server supports the following “structure” attributes: phrase, word, normalized date, wordlist, and the non-standard “ordered wordlist”. Clients will be able to make use of the word and phrase structure attributes with the PQD database. A term with a structure attribute of “word” will have internal blanks replaced with ANDs. The normalized date structure can be used to search the PQD numeric date field. Expected input for numeric date terms are in the form of MM/DD/YY-MM/DD/YY. The day and month values can be dropped as well as the starting or ending date. If the string starts or ends with the hyphen character then an open ended date range will be searched.

Table A-3-5 Bib-1 Truncation Attributes.

We support right truncation (1) and processing of the embedded truncation character, # (101). We also look for the “no truncation” value (100).

Table A-3-6 Completeness Attributes.

Completeness attributes are ignored.

Table A-3-7 Z39.50 Version-3 Compliance.

The UMI Z39.50 server meets all the Core Requirements of a Version-3 Z39.50 server.