Page Comparison

• Welcome to Cheryl Malmborg who will be attending for the day.
• We need a note taker, as this session may be a little technical.Wayne will take notes.
• New members: Cheryl Malmborg from University of Chicago, Steve Bischof from Five Colleges

Comparison of the Folio model for loans with the legacy data elements contributed by our members. Discussion will center around the loans spreadsheet, which can be found here.

Regarding related data: do we need to know the source element for record IDs, or is it enough to just specify "retrieved from FOLIO"? Consensus: yes, the source ID is useful.

What about referential data (e.g. "item.title")? Is this really stored, or just calculated?

Currently it is really stored, because of the need to store data even after item may be removed. Source should be indicated. How is this data updated if it changes in the instance record or item record?

Concern expressed by Cheryl Malmborg: There might be a need to store historical data in a different location, rather than just all in loans, as millions of lines of loan history may be migrated.

loanPolicyId: likelihood of being able to migrate this data is slim.

holdingsRecordId: it will be challenging to map across different data structure (some sites don't have holdings structured the same way as FOLIO) – it may be that this will have to be calculated based on the item.

How to represent historical data (e.g. circ_trans_archive)? Need to indicate both current circ data and historical sources. No place to represent compiled (collapsed) transactions for historical data.

Might it make sense to load history directly into a reporting system, rather than loading into the loans endpoint.

userId is a required field – how are data anonymized when a transaction is closed? May need to make userId not required.

metadata fields – LBS is not allow to store information regarding the user ID of the operator

Missing data elements:

• Patron group: does patron group need to be stored with the loan? What about when data is anonymized?
  • Multiple uses of this data make things complicated – need for storing data for historical or statistical purposes, while live data may change (e.g. patron group)
• Recalls – Voyager handles this data separately (e.g. due date may be stored in a different field)
• Where is in house use stored?

We have a few additional modules for which we need to compare our legacy data with the Folio data model. Could we list those in order of priority and get people working on them?

Anne L. Highsmith is working on a spreadsheet for requests, should be available by end of today

Fees and fines – is FOLIO model mature enough? We may not have a rich enough data model to start mapping.

For next week: complete work on loan analysis, begin work on requests.