Versions Compared

Version Old Version 15 New Version 16
Changes made by

Kathleen Gerdink (Unlicensed)

Kathleen Gerdink (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

Section
Column
width50%

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" “core” elements, it does allow for the addition of "local" “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.

Column
width50%


false
Panel
borderColor#97A0A9
bgColor#F8FCFF
titleBGColor#F2F8FF
borderStyledashed
Page Tree
rootOLE:@self
expandCollapseAlltrue
startDepth3
searchBoxFalse
Table of Contents
minLevel1
outline
Wiki Markup

{pagetree:root=@self|searchBox=False|startDepth=3|expandCollapseAll=true}
{toc:outline=false|minLevel=1}

DATA

META DATA

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

...

  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‘bound-withs'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.