scope:

CORE Transactions

The CORE protocol has been generalized in order to be useful for a variety of transaction partners by identifying and defining data elements that are generally supported by ILS, ERMS, subscription agents, and materials vendors.

The CORE protocol defines the semantics for a set of transactions implied by three defined CORE use cases (see Appendix B). While not every CORE implementation may require the full set of use cases, the design supports all three.

An XML schema conveys CORE protocol transactions (see Appendix A). The schema, using COREspecific derived data types (see Section 6.3), frequently restricts the form and value of data components. The schema presented supports single-query requests with possible multi-part replies.

Transport Mechanism

The CORE protocol describes a data structure and not the transport mechanism. While the NISO CORE Working Group recommends SOAP be used as the Web Services transport mechanism, the specifics of the SOAP configuration are beyond the scope of the CORE recommended practice and are left to trading partners to devise. Implementers of the CORE protocol may also use other transport mechanisms that are already in place, such as FTP or SMTP, or even physical transfer media.

Out of Scope

It is not the intent of this recommended practice to specify or restrict whether the request shall be initiated automatically or manually, nor whether the data provided in the response should be used for purposes of display or data population. The recommended practice is only intended to specify the data elements and a schema used in such an exchange.

CORE, by definition, is transmitting financial information and, therefore, data transferred in the CORE message should be considered confidential between the two parties. CORE, being the payload, does not include methods for secure transmission. Some suggested methods for securing the CORE payload are provided in Appendix C.

Purpose

The purpose of the Cost of Resource Exchange (CORE) specification is to facilitate the transfer of cost and related library acquisitions information from one automated system to another. This transfer may be from: 1) an Integrated Library System (ILS) acquisitions module (the data source and CORE responder) to an Electronic Resource Management System (ERMS) (the data recipient and CORE requester), both belonging to the same library; 2) a book or serials vendor to a library's ERMS; 3) a transfer of cost and transaction data among members of a consortium; or 4) any transaction partner to another that can benefit from the sharing of cost and library acquisitions-related data.

Using the defined CORE XML data schema, this recommended practice provides a common method of requesting cost-related information by a client application (an ERMS, for example) for a specific order transaction, a specific resource, or all resources that the library owns, within the boundaries of a payment period or access period. The client requester must supply sufficient request information (e.g., a unique order identifier, a date range) in its request, so that the responding system (an ILS, for example) can interpret the request, identify the appropriate financial record(s), and respond with the appropriate financial and/or resource data elements.