Instance Document Review

Agenda Outline

Doodle Poll (closed): http://www.doodle.com/8bqama5tym9ny6wd

Time: 11:00am- 1:00 pm EDT
Date: Tuesday, July 17, 2012
Location: CIB 207A and Webex
Webex: https://kuali-ole.webex.com/kuali-ole/j.php?ED=205661172&UID=498170687&PW=NZmZkOGJmNWQ3&RT=MiMxMg%3D%3D. Tel: 1-408-600-3600 (mtg ID- 625 833 990 )

Invitees: John Pillans, Docstore, IU; Mechael Charbonneau, Gary Charbonneau, Jackie Byrd -Describe/Cataloging, IU; Chris Case- Deliver, Systems Integration, FL; Tod Olsen (for Frances), Chicago; Michelle Suranofsky- Editors, Describe, Lehigh; Doreen Herrold- Editors, Lehigh; Jeff Fleming- NCIP/Systems Integration, Duke; Peri Subramanya, HTC; Nianli Ma, Dan Sweeney, Kathy Gerdink, Patty Mescher

Agenda:

Instance Schema
1. Paired Values/Sequencing
  1. Issue: Does existing Schema account for “paired fields” sufficiently, for examples such as Marc 583 $n$o via <linkage> and <fieldLinkAndSequenceNumber> that are commented out? COMMENTS: data storage as data attributes vs. data string is a.o.k, as long as presentation is based on functional requirements.Action Item: Linkage that has been commented out and must be reviewed and then restored.
  2. Should display/edit of Call Numbers- parsed to 4 elements, be modified in how it is stored?
    1. Users need to copy the entire call number and copy and paste - do not want to copy a piece of the call number to specific fields. prefix and suffix very local - should not be copied from OCLC - we need to determine if we can split the call number from item (classification/item) is there a real business case to split these at the database layer (classification team may determine the real need for this) Action Item: Mechael: Provide use cases - Patty/Dev Team - options; Jeff: easier to keep separate - we can combine when needed (storage)
2. Legacy Data
  1. Issue: is this about complexity of mapping old data to new structure?
    1. challenge - pulling from mark holding to the instance record for legacy data- ; User Interface is challenging for the amount of data that needs to be entered for instance vs. holdings.
    2. Editor User Interface - take a look and determine what we can do
  2. And how/where to account for “extension elements”? HOLD until further notice......
3. MFHD mappings
  1. Issue: is this same as above or more about renaming and reordering of key elements that occurred in OLE instance, Instance-to-MFHD (brief)
4. Omitted/missing data elements
  1. Issue: Values not yet included in 9.x schema – need approach for adding/extending vs what is stored in linked transactional --number of circulations, Donor public display; donor note; price (why needed?); number of pieces (calc); checkin note (or does this stay in tx); other notes. How to use <institutionToWhichFieldApplies> . (COMMENT: These may all have a functional story tied to them. This is back to the Mark Holdings support) COMMENT: Jeff: 850 - 860 - paired fields - looking at how this is going to convert to instance schema- this will be related to our overall Mark holdings support decisions. Jeff has documentation on this mapping.
  2. Proposed Solution Discussed:
  3. Refactor Cost:
5. Configuring "extension" elements (for UI, indexing)
  1. Issue: Need to determine approach and future support for adding local “extension elements” provided for in schema at Instance, Holding, and Item levels- need functional and technical scope for 1.0 (what do libraries need, esp if not all MFHD fields provided in initial xml? How extensible and editable will our indexing, Search logic, Search UIs, Editor UIs need to be for early adopters?)
6. Location elements- in Items, Hierarchy
  1. Issue: Variation of opinions on use of Temporary, Permanent as Location statuses, instead of repeatable elements named separately; Locations stored in provided 5 level hierarchy (OLE coding 5, but only have 2 levels in sample data, and NCSU wants X levels); location of Location elements at Item level. COMMENT: we are in agreement with the 5 level limit. COMMENT: LOCATION is at the ITEM level - further discussion...especially from a user interface perspective and how the location will be updated/managed between holdings and items. This is a frequent activity for changing location of several hundred records at one time. (XML for each record, modified and imported back)
Bib-Instance
1. Item linkages
  1. Issue: what/how is OLE using unique identifiers to support NCIP, Discovery layer-Bib Numbers in OLE-Email thread
    1. UUID in docstore is not a preferred number reference - Need an additional sequential number tied to the institutions legacy numbering system for bib records
    2. COMMENT: This additional field should be additional requirements for DocStore. Requirements: Jeff/Tod/John - Mechael & Gary (Infrastructure? - Functional side of house representation? - Patty follow-up)

Technical Implication Issues/Review

Functional Implication Issues/Review

Reference Documentation

Instance 9.x
1. Docstore: summary "not yet completed"
2. See all related Google Docs-Working files: questions, schema mapping, MFHD comparison for next Schema Iteration; SME comments from May 16th Instance demo
OLE Technical Documentation (wiki)
1. OLE DocStore (Docstore Architecture Model)
2. OLE Instance- Docstore
3. OLE Bibliographic Documents - Docstore
4. Search Documentation
  1. OLE Search- Design Planning
NOT AT THIS MEETING- Future Discussion Topics or Issues --to be Moved to Another Venue
1. DocStore
  1. Loading Legacy Data; a follow-up to design discussions in June, with John P concerns and recommendations
  2. Search strategy: SOLR vs KNS (for how/where to store and create indexes- combined bib/instance/transactional data)
  3. Metadata storage and updating
2. Discovery layer
  1. bib Links or identifiers (discovery layer)
  2. data transformations vs literal mappings
3. Related Issues/Framework issues:
  1. Editors- esp Combined? Linking from Search UIs
  2. Editors/other extensible or configurable UIs
  3. Configurable Indexes, sorts, search fields, facets
  4. Technical or UI framework