OLE Instance- Docstore (to OLE 0.6)

Owned by Kathleen Gerdink (Unlicensed)
Last updated: Aug 06, 2012Version comment

See also: OLE Instance Document as recommended replacement August 2012, pending PM and FC approval.

Instance v 9.0 (OLE 0.8) https://jira.kuali.org/browse/OLE-2980 (v 9.x under review)
Instance v 8.1 (OLE 0.6) https://jira.kuali.org/browse/OLE-2293 (Available in OLE-DEMO)
Instance Editor: https://jira.kuali.org/browse/OLE-2555 and related linked tasks

Overview

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.


Expand all   Collapse all

DATA

META DATA

Currently, the meta data keeps as the properties in instance/item nodes, following is the list:

  • DateEntered
  • CreatedBy
  • LastUpdated
  • LastUpdatedBy
  • Harvestable
  • Status
  • SuppressFromPublic
  • FastAddFlag

Instance meta metadata meeting notes is the best place to learn the more detailed information or background knowledges.

SCHEMA

OLE 0.6 release: Instance schema V8.1

OLE 0.8 release: Instance schema V9.0

Some useful documentations:

Instance Data Requirements as mapped to OLE Instance Schema 9.0

The instance schema changes between v8.2 and v9.0

Meeting notes on applying instance schema v9 to DocStore

TEST DATA

John Pillans is working on re-evaluating the loading data, need to check with Gary so that we are all on the same stage.

FEATURES

LINKING

Currently the linkage information is kept as the instance properties in the instance node.

VERSIONING

The versioning for instance/holding/items was turned off now.

BUSINESS RULES 

(Carried forward from OLE release 0.6- to be modified as changes made)

  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.

Operated as a Community Resource by the Open Library Foundation