OLE Instance Schema for OLE .6

Owned by Lydia Reid (Unlicensed)
Last updated: May 15, 2012 by Kathleen Gerdink (Unlicensed)Version comment

OLE Instance

OLE Instance documents are used to identify and describe library resources locally owned/licensed by libraries and as such contain unique information that can not be captured in Bibliographic documents that may be used/shared by multiple libraries.

OLE Terms and Definitions
  1. Instance. This document type includes information traditionally known as holdings and item information. It is a single document type with 2 categories of information (holdings and item).
  2. Holdings. Describes the extent of a resource available to the user. In the case of continuing resources holdings data may record the pattern of issuance of a resource and/or a summary statement of volumes held.
  3. Item. Describes the smallest unit of a resource that is managed and/or circulated individually.  It provides specific information regarding the physical location when pertinent.

The OLE Instance schema is loosely based on the MARC Format for Holdings Data (MFHD) and represents core elements that must be included when describing holdings and items.  The schema does not support every MFHD field/subfield but does include additional pieces of information not supported by MFHD. Additionally, the OLE Instance schema has taken some elements traditionally captured with holdings data and moved those to item descriptions.   These include elements for describing the location of items (MFHD 852 field and subfields) as well as information relating to how users may access electronic resources (MFHD 856 field and subfields).  Because the current schema only represents “core” elements, it does allow for the addition of “local” pieces of data via the <extension> element. 

The OLE Instance schema does not dictate how libraries combine items to comprise holdings data.  As with MFHD, libraries may choose to describe multiple copies of a single resource in one OLE Instance or provide separate OLE Instance documents for each copy.  The OLE Instance <separateOrCompositeReport> element will allow libraries to indicate for each OLE Instance document whether or not it is for only one copy or for a consolidation of information about more than one copy of the bibliographic item.

High Level Business Rules
  1. 1 Bibliographic Description must have at least 1 OLE Instance Description.
  2. 1 Bibliographic Description may have more than 1 OLE Instance Description.
  3. 1 Instance may have more than 1 related Bibliographic Description (to account for ‘bound-withs’/analytics).
    1. An Instance document will contain references to each parent system-generated Bibliographic Universally Unique Identifier (UUID).
    2. An Instance document will have a system-generated UUID.  
    3. Instance documents may be moved from one Bibliographic description to another Bibliographic description.
    4. An Instance must have 1 Holdings description and only 1 Holdings description.
      1. A Holdings description will have a system-generated UUID.
        1. Identifiers from legacy systems will be stored/managed in <formerIdentifiers>  within the holdingsGroup which allows for the capture of the former identifier and the type of the former identifier).
        2. An Instance must have 1 Item description and may have many Item descriptions.
          1. Each Item description will have a system generated aka UUID - distinct from the item barcode or URL/URN).
            1. Identifiers from legacy systems (former barcodes, former system identifiers) will be stored/managed in <formerIdentifiers> within the itemGroup which allows for the capture of the former identifier and the type of the former identifier.
            2. Within an Instance document, Holdings information is shared by all Items, but is not physically inherited by the Items.  If Holdings specific data is changed, it is therefore changed for all Items within the same Instance document.
              1. Data captured for Items, (e.g. Location information) can be changed globally across Items, but via parameters and not by just simply changing it at the "holdings" level.
              2. Requisition Line Item references 1 Item description within an Instance document.  This relationship is captured in the OLE rdbms.
              3. Purchase Order (PO) Line Item references 1 Item description within an Instance document.  This relationship is captured in the OLE rdbms.
                1. The PO Line Item UUID  will also be captured in the Item description for auditing purposes.
                2. Receiving Line Item references 1 to Many Item descriptions within an Instance document.  This relationship is captured in the OLE rdbms.
                3. When a new Item description (within an Instance document) is created during Receiving – or during any other library process that occurs subsequently to the ordering process - the related PO Line Item primary key/identifier will need to be populated in the newly created Item description.
                4. Item descriptions may be moved from one Instance document to another Instance document.
                5. References to the PO Line Item primary key/identifier must be retained within the Item descriptions for auditing purposes.

Both the schema and the schema documentation (with an internal OLE version number of 8.1) may be found in Google docs:

OLE Meta- Metadata

The following are NOT part of the Instance Schema or even other Docstore Document schemas, but are instead stored on Dosctore nodes in the architecture .....including Bibliographic documents.

  • Date Entered 
  • Created By
  • Last Updated
  • Last Updated By
  • Harvestable?
  • Status 
  • Suppress From Public
  • Fast Add Flag

Tasks or Issues to be completed/addressed for OLE .8 or later releases

  1. For OLE Instance elements that parallel MFHD fields/subfields - update <documentation> tags that were copied from the Library of Congress MFHD website: http://www.loc.gov/marc/holdings/.
    1. Remove references to MFHD fields and subfields and instead refer to related OLE instance elements.
  2. Make structural changes: e.g., change some global elements to complexTypes or imbed them within the holdings / item sections so there are only 2 root elements (<instance> and <instanceCollection>.
  3. Where needed, re-sequence and/or regroup elements to better match the parallel MFHD structure.
  4. Remove <enumeration values> for a variety of elements and designate the “type” as “codeOrIdentifier” so local implementers can choose data values from locally controlled “maintenance documents”/“code lists”.
  5. Apply data lengths to some elements to better ensure that OLE Instance descriptions can be exported to the MFHD format as needed and stay within the character length limit of a MFHD record.
  6. Create separate schemas for individual modules of data to allow for easier updates and efficient maintainability, e.g., a separate schema for location that can be “included” within or “imported” to the OLE Instance schema.
  7. Determine usefulness of <linkage> and <fieldLinkAndSequenceNumber> and update schema appropriately.
  8. Determine usefulness of <alternateGraphicRepresentation> - if it is retained, will need to add a <linkage> subelement.
  9. Determine how to identify of “owners” of OLE Instance documents.
  10. Determine how to identify “circulation” locations.
  11. Final analysis and determination of status information – what types of statuses are needed – acquisitions, cataloging, circulation?  How are the statuses generated? What should status data values be?  Where should the status attributes be stored – the Docstore or OLE relational database management systems.

Note: Tasks/issues 1-5 have been completed in OLE Instance schema version 9.

Operated as a Community Resource by the Open Library Foundation