Catalogue searching contains two essential elements, the identification of bibliographic data and the identification of physical copies of the works. To date, bibliographic searching and retrieval has been standardised and an acceptable level of inter-operability has been demonstrated in Z39.50 catalogue implementations. Although many of these Z39.50 implementations have included holdings search and retrieval, there is no current standardisation of the way in which the holdings data is requested and presented that has resulted in various methods being implemented with a corresponding lack of inter-operability.

The effort to achieve holdings inter-operability has been separated into two areas of effort that are inter-dependent. One work stream is the mechanism for searching and retrieving holdings. The other, is the way in which the holdings data is structured via an OPAC holdings schema.

This schema derives its name from Online Public Access Catalogue and it reflects the fact that this type of implementation was the first to signal the need for the exchange of holdings information. In fact, there are more applications.

Usually, holdings data are presented with at least some brief bibliographic information, e.g. author and title to provide descriptive context for the holdings information. The Z39.50 standard currently allows for holdings to be delivered using MARC holdings format or the OPAC holdings schema. Both these format combine some bibliographic elements with the holdings information. The USMARC holdings format does not allow all holdings associated with one bibliographic record to be combined together in one record, thus requiring transfer of duplicate information in some cases. The OPAC holdings schema is designed to return only one record combining a bibliographic record with all of its associated holdings, or all relevant associated holdings. For most servers, this entails the assembly of multiple holdings records into one for despatch.

By grouping all holdings and bibliographic data together into one record, the OPAC holdings schema provides the structure and linkages between the bibliographic record and its associated holdings in an unambiguous way.

A proposal to enhance the OPAC holdings schema is in preparation, under the editorship of Rolande St. Gelais of DRA Associates.

NETWORK MODEL - Union Catalogue with Summaries; Remote local databases

The method for searching and retrieving holdings needs to address the needs of all three models.

In the Simple model, the holdings occur as fields within the bibliographic record. It is easy for the target to determine the holdings count as the holdings records are already assembled. This model is most likely to be employed in a union catalogue that has summary holdings statements.

In the database model, the holdings occur in files or entities linked to the bibliographic record. This model is common in integrated library management systems (ILMS). In the diagram, holdings may be linked directly to bibliographic data or they may be linked indirectly via such things as serial issues of volume records.

In the network model, the union catalogue may be either a database or a simple model with remote access to databases that contain detailed holdings information. A variation on this model is where the union catalogue contain no summary holdings information.

1. A search on SUBJECT (bibliographic access point) AND AVAILABILITY (holdings access point) AND LOCATION (holdings access point).

All books about DINOSAURS available NOW, preferably in DARWIN

2. A search on SUBJECT (bibliographic access point) AND LOCATION (holdings access point) AND FORMAT (holdings access point)

All books about DINOSAURS in DARWIN, preferably in LARGE PRINT.

3. A search on SUBJECT; FILTER requirement for holdings on LOCATION

All books about DINOSAURS, no matter where they are located, with an indication of

locations just for Darwin

4. A search on TITLE (bibliographic access point) AND ENUMERATION (holdings access point) AND LOCATION (holdings access point) AND FORMAT (holdings access point)

NEW ENGLAND JOURNAL OF MEDICINE, AND VOLUME 150, ISSUE 35, located in

TORONTO, preferably PRINTED (not CDROM)

5. A search on TITLE (bibliographic access point) AND ENUMERATION (holdings access point) AND FORMAT (holdings access point) AND LOCATION (holdings access point).

The examples give an explanation of the importance of the holdings search attributes. The most important search attribute is given first, others are expressed as preferences. Some solutions will not need to understand the difference, e.g. where holdings attributes as combined in a boolean AND expression. In this case, all attributes are equal. However for other solutions, such as the "Interim Present" described later, it is necessary to know the most important limiting attribute.

Sometimes a search requirement mixes bibliographic and holdings criteria, requiring the target to combine the bibliographic and holdings data to perform the search. Searches 1, 2, 4 and 5 are examples of this. Sometimes, the holdings criteria in the search are secondary to the bibliographic criteria as per example 3.

Search

The search response will include a results count that effectively reflects the number of bibliographic records retrieved and no indication of the number of associated holdings records. One exception to this is where records are returned in the search response (piggy back present), then the origin will be able to calculate the number of holdings from the leaf nodes of the records themselves.

The target only needs to know the name of the bibliographic database. It will know itself how to access the auxiliary holdings information, whether it is in the same record, same database, a separate linked database or a separate unlinked database. Some targets may not be able to accept such a search, e.g. targets following the network model. In this case, the target would fail the search, with the appropriate diagnostic, e.g. 121 - unsupported attribute set or 114 - unsupported use attribute.

If piggy back present is used, then the search request may need to contain attributes (PRUNE or FILTER attributes) to ensure that the OPAC holdings records returned contain only those holdings required. The "present section" below elaborates this requirement.

Present

For cases 1, 2, 4 and 5, bibliographic records that do not have associated holdings will not match the search criteria and will not therefore be included in the search results.

The challenge is to ensure that the OPAC holdings records returned by the target only contain the holdings that are required by the origin.

When the search contains Holdings ACCESS POINT attributes, does it also need to include a statement that will tailor the contents of the OPAC record to match the search statement? If such a search were done using many report generators, the results returned would not include holdings records that were not matched to the search criteria.

One could argue that, when searching, the holdings are regarded as separate records. Once retrieved, they are combined with the relevant bibliographic record and consolidated into one OPAC holdings record for presentation.

Or, could there be cases where there is a requirement to search, limiting by holdings criteria, but to retrieve bibliographic details with all attached holdings details? If yes, perhaps it is necessary to be able to include the OPAC FILTER statement in the search. (The element set cannot do this because it includes no variable selection criteria). A way that enables the target to determine its best operation is to state the requirement initially within the search itself. A new PRUNE / FILTER attribute has been suggested. Normally holdings PRUNE / FILTER attributes will be the same as holdings search attributes as in the examples of searches 1, 2, 4 and 5, but they would not necessarily be the same.

Example:

A search on SUBJECT (bibliographic access point) AND AVAILABILITY (holdings access point) AND LOCATION (holdings access point) PRUNE / FILTER (holdings access point) PRUNE / FILTER (holdings access point).

*** PRUNE / FILTER attributes - what sort of attributes are they? - what do they look like in terms of the new attribute architecture? They seem to be a form of ACCESS POINT with an "action qualifier" of FILTER as opposed to SEARCH.

If PRUNE / FILTER attributes are employed, this would meet the requirements of all 3 holdings models. No target would be required to gather holdings records that would later be discarded.

For the PRUNE / FILTER solution, the target does not need to convey the name of the holdings database to the origin.

In order to filter the OPAC holdings records to be retrieved, the origin sends a present request for data in the OPAC holdings format but with an element set or specification that limits the data to just one data element, e.g. location. The target returns the holdings records with hit vectors (or pointers) for requesting the precise holdings required.

This solution has the advantage of enabling the target to return an indication of the size of the attached holdings. However, the origin can only request the summary based on one element. Although the element can vary, the view of holdings is hierarchical rather than relational, meaning that the target, rather than the origin, largely determines the view. This also means that the origin may only filter by one element.

This solution does require the target to send skeletal information for all holdings records that are associated with the selected bibliographic records. In the simple and database model, this would not be difficult, but in the network model, it may require the target to perform surrogate searches of remote databases.

New diagnostics are needed. If the target cannot provide a summary based on any elements, it needs to indicate this and indicate the names of the holdings databases or databases to search. Perhaps it would be unlikely that this would happen if the target supports the OPAC holdings schema? If the target cannot summarise by the element requested, then it needs to indicate this and the elements that are supported in "other information" in the diagnostic.

For the INTERIM PRESENT solution, the target does not need to convey the name of the holdings database to the origin.

This solution seems to involve the following steps:

• search request / response
• explode request
• search request to exploded database
• present request

This method is similar to the interim present method in the following ways:

• It allows the target to indicate the size of the holdings
• It requires the target to gather all holdings

Unlike the interim present method, its view of the holdings is not restricted to one element and a hierarchical view, allowing the origin to define the view of holdings.

The target would send the name of the exploded holdings database in the explode response.

Re-iteration: The challenge is to ensure that the OPAC holdings records returned by the target only contain the holdings that are required by the origin.

Solution 1 - Search includes Prune / Filter attributes

This is as discussed before. The search would include no holdings attributes as search limiters but would include Prune / filter attributes.

Solution 2 - Successive searches

One way to achieve this is for the origin to conduct successive searches and to add holdings to the display of a bibliographic search. The first search would be a bibliographic search and the other would be a search of the type already discussed above, i.e. one containing limiting holdings attributes.

By making a successive search, the second search is actually a search containing limiting holdings attributes, as already discussed. Therefore, the method of filtering the OPAC record can be any of the four already proposed and discussed.

Explanation:

• Bibliographic search; e.g. DINOSAURS; response returns count

• Present - with an element set that retrieves bibliographic records

• Bibliographic search combining bibliographic and holdings access points, e.g. DINOSAURS AND AVAILABLE AND in DARWIN; response returns count (equal, but more often less than for the first search

• Present holdings records.

The second search can be sent before the present has completed for the first. Alternatively, the second search could use a named results set instead of repeating the bibliographic search. This is more server friendly.

In this solution, the origin sends only two searches.

Alternative:

• Bibliographic search; e.g. DINOSAURS; response returns count

• Present - with an element set that retrieves bibliographic records containing record Ids plus the name of the holdings database

• As each bibliographic record is retrieved a new search is made of the holdings database using holdings search attributes

• Present holdings records.

Note that holdings database searches can be made as results are received from the bibliographic present. The client interface could possibly "colour" a dimmed icon indicating that holdings had been retrieved against the bibliographic record. For every record retrieved in the bibliographic present, there will be a holdings search and holdings present.

Solution 3 - Interim Present

This is as discussed before.

• Bibliographic search
• Interim present
• Real present

If the target cannot gather the necessary holdings easily, e.g. for the network model, it may wish to indicate which elements it can support in the interim present.

Solution 4 - Explode

This is as discussed before.

• Bibliographic search
• Explode
• Search
• Present

If the target cannot gather the necessary holdings easily, e.g. for the network model, it would not support the explode extended service and would use standard ES diagnostics to indicate this. Would the target give some indication of how it supports holdings search and filtering??