Home | Workrooms | CORE | CORE FAQs - Systems Developers & Subscription Vendors

CORE FAQs - Systems Developers & Subscription Vendors 

  1. How does the CORE protocol work?
  2. How often will the CORE schema be updated?
  3. What are the various technologies involved with CORE implementation?
  4. What is the difference between the cost-related information supplied by the client and the server in a CORE implementation?
  5. What variable information has to be supplied in a CORE (client) request?
  6. What variable information has to be supplied in a CORE (server) response?
  7. What is the transport mechanism for CORE (client) request and (server) response data?

 

  1. How does the CORE protocol work?
    The CORE protocol acts as a standardized interface between two systems that exchange financial information, such as an ILS and an ERMS. A system on either end of the exchange needs to create a one-time interface to the CORE protocol and can then exchange data with any other CORE-compliant system, as illustrated in Figure 1.

    CORE Figure 1


    The CORE protocol supports single-query requests with possible multi-part replies in either a client/server or peer-to-peer architecture. The basic element of the protocol is the COREDocument; all elements within the schema are children of the COREDocument element.

    The schema uses an object-oriented approach and is deliberately terse to encourage rapid implementation and lightweight profiles. Placing each major unit in its own sub-schema promotes schema reading and editing while enhancing reusability. Implementers may unit-test components with a validating parser by building an XML document from any of the sub-schemas. The entire schema has been kept as flat as possible; there are no unnecessary elements.
     
  2. How often will the CORE schema be updated?
    Changes to the schema that meet the standard's definition of allowable changes will be made as needed, but no more than annually.
     
  3. What are the various technologies involved with CORE implementation?
    • ERM: Electronic resource management (ERM) software is developed for the specific purpose of managing a library’s electronic resource collections and subscriptions. ERM systems, which can be either standalone or directly tied to a library system vendor’s other modules, usually track the life cycle of an electronic resource. This can include management areas such as: access, acquisitions, licensing, cost, invoicing, workflow, trial use of electronic products, and resource usage.

      Many of today’s ERM systems are based on the Digital Library Federation’s Electronic Resource Management Initiative report. Currently, there is work underway at NISO to review current ERM data standards and best practices, to be provided in an updated report mid-2011 (see www.niso.org/workrooms/ermreview).
       
    • ILS: An integrated library system (ILS) is defined as:

      [A]n enterprise resource planning system for a library, used to track items owned, orders made, bills paid, and patrons who have borrowed.

      An ILS usually comprises a relational database, software to interact with that database, and two graphical user interfaces (one for patrons, one for staff). Most ILSes separate software functions into discrete programs called modules, each of them integrated with a unified interface. Examples of modules might include:

      • acquisitions (ordering, receiving, and invoicing materials)
      • cataloging (classifying and indexing materials)
      • circulation (lending materials to patrons and receiving them back)
      • serials (tracking magazine and newspaper holdings)
      • the OPAC (public interface for users)

      [Source: Integrated library system. (2011, January 18). In Wikipedia, The Free Encyclopedia. Retrieved January 25, 2011.]

       
    • XML schema: An XML schema is “is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntax constraints imposed by XML itself. An XML schema provides a view of the document type at a relatively high level of abstraction.” [Source: XML schema. (2006, July 6). In Wikipedia, The Free Encyclopedia. Retrieved July 27, 2006.] More on XML can be found at: http://www.w3.org/XML/.
       
  4. What is the difference between the cost-related information supplied by the client and the server in a CORE implementation?
    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.
     
  5. What variable information has to be supplied in a CORE (client) request?
    The CORE protocol supports a single request, intended to retrieve a record (or set of records) that contain fields related to the product information, order transaction, and payment details. The requester may supply either a specific OrderId, a specific ProductId, or request all records, qualified by either access period (subscription period) or payment period (e.g., fiscal year), date range, and a CustomerId.

  6. What variable information has to be supplied in a CORE (server) response?
    The response will return a CORE Response record (or set of records) with payment detail, order transaction, and product fields. For any given requested OrderId or ProductId, there may be multiple PaymentDetailsRecords contained within the CORE Response, depending on how many payments were made during the date periods specified in the query. A query request for all records, whether date qualified or not, can result in a response with multiple transaction records (AcqRecords), each of which could contain multiple PaymentDetailsRecords.
     
  7. What is the transport mechanism for CORE (client) request and (server) response data?
    The CORE protocol describes a data structure and not the transport mechanism. While the NISO CORE Standing Committee 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.