Page Comparison

...

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. 

...

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.

...

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" “type” as “codeOrIdentifier” so local implementers can choose data values from locally controlled "maintenance documents"/"code lists"“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" “included” within or "imported" “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" “owners” of OLE Instance documents.
10. Determine how to identify "circulation" “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.

...