CMS 2021.08.17

Reminders / announcements

1. Remote work agreements for fall semester in effect as of 8/16; supervisors retain ability to approve ad hoc exceptions, ad hoc WFH days.

2. Free parking in select lots/garages ends 8/31; if you need a parking pass, acquire from the Parking Office and expect a two week turnaround.

3. Mask and vaccine mandates: details are available on Together We Will FAQ page; details on MSUL’s implementation of the mask mandate are in the 8/12 all-staff email from Terri Miller.

   1. Joe has acknowledged feedback received re: complications around eating in the building. The next few weeks will be seen as capacity testing on the demand for reservable rooms for eating, etc. in half hour blocks. Please take advantage of those rooms so that we can truly test capacity. Ask your supervisor if you need help navigating the room reservation process.

   2. Joshua’s advice on vaccine mandate: if you still need to get yours, consider doing so before potentially high demand from students arriving to campus.

   3. Your vaccine information is due to the university by 8/31 by reporting here: https://covidresponse.msu.edu/vaccine/survey

   4. Vaccine mandate will be enforced at university level.

FOLIO review

1. Sierra setup:

   1. Sierra is an integrated library system (ILS); all transactions with our collection and metadata about our collection flow through it, are facilitated by it.

   2. Before FOLIO, our setup consisted of Sierra, the Sierra OPAC and Summon

   3. Sierra generally contained: print collections, title-level records for e-resources (e-books, journals, etc.); these records were directly surfaced via the Sierra OPAC in real time

   4. Summon contained the same as Sierra, with the addition of more granular article-level and/or full-text data; Summon received input from Sierra every night, via a custom mapping that we devised when we implemented Summon. Article and full-text data was managed separately by ProQuest, based on what MSUL was supposed to have access to as indicated in our knowledgebase (i.e. stuff that Ranti, Diane and Anne handle that Joshua doesn’t understand).

2. FOLIO setup (our goal setup after cataloging migrates and we’ve fully implemented FOLIO):

   1. We will work a lot with FOLIO’s Inventory app. Inventory is just one app in the larger FOLIO universe (but a really big, important app). FOLIO isn’t an ILS like Sierra; it’s a modular system of apps that work together, can be added to or supplemented by other apps, etc.

   2. We will migrate all MARC data from Sierra into MARC Source Record Storage (SRS) in FOLIO; this data will serve as our “source of truth” for what appears in Inventory. SRS data will underlie Inventory, flow into Inventory, where staff will engage with the collection and perform transactions via the Inventory interface. When we create new MARC records (moving them from Connexion into FOLIO) they will be stored in SRS, where the data will flow into Inventory and be generally viewable to staff.

   3. We will have our own custom map for moving data from SRS to Inventory (e.g. 245 $a should go to the FOLIO title field; 246 should go to alternative title, etc.)

   4. Inventory consists of Instance, Holdings and Item records

      1. Instance records are generally analogous to MARC bib records

      2. Holdings records are analogous to MARC holdings records, but this marks a change for us. Sierra does not have holdings records: but we did have a practice of creating serial holdings statements in MARC form and storing these in Sierra checkin records. Checkin records were only used on continuing resources (e.g. serials) in Sierra. FOLIO will have holdings records for everything, serial or not. So we have to map Sierra checkin and item data in such a way to populate FOLIO holdings records - some of which will have underlying MARC holdings data in SRS (e.g. the serials that we have MARC-style holdings statements for will (hopefully) be mapped this way).

   5. We will have another custom map for moving data from SRS to EDS.

   6. EDS is our sole discovery platform in this setup. But the representation of the things we catalog won’t come from Inventory into EDS; it will flow from SRS into EDS by its own custom mapping - so two mappings at play: one for SRS>Inventory, another for SRS>EDS. This is an upshot of modularity.

   7. Resources managed in Inventory (whose source data lives in SRS) will be surfaced in a subset of EDS called the “custom catalog”. This is analogous to the Sierra OPAC from our former setup, but it is subsumed in EDS - not a standalone discovery platform.

FOLIO happenings

1. E-book problem:

   1. Separate decisions converged to obscure e-books in MSUL’s bento box discovery display:

      1. “Articles” pane was filtered to retrieve articles from Summon, and then from EDS when we made the switch

      2. “Books & more” pane pulled from Sierra OPAC; but we stopped supplying e-resource records to Sierra when switch to EDS was made

      3. This meant no e-books were showing at all in bento box, even though they were being loaded into EDS

      4. Staff in Digital Initiatives division are re-working the bento box to accommodate

2. Holdings & item mapping:

   1. Cataloging & Metadata Task Force are mapping data from Sierra checkin and item records to FOLIO holdings and item records

   2. Sierra checkin and FOLIO holdings are not analogous. Sierra checkins are only used by MSUL for serials; FOLIO holdings are used in Inventory across the entire collection

   3. Mapping therefore will be from combination of Sierra checkin & item to FOLIO holdings and from Sierra item to FOLIO item

   4. Several issues being discovered that are slowing the process: our complicated call number hierarchy in Sierra; Remote Storage barcodes; e-bookplate notes & links; multipart resource holding statements being recorded both in Sierra bib and Sierra checkin; coded vs. textual serial holdings statements