Subgroup members: please add any relevant use cases. If a use case is already represented, add any additional details (your name, record source, other notes) to the existing case instead of creating a new case.
Note: Assume any files in the Use Case are MARC unless otherwise specified
| Use case (brief) | Use case description | File source | FOLIO components affected | Functional Area(s) | Submitted by | Notes | |
|---|---|---|---|---|---|---|---|
| 1 | Loading pre-order records | User prepares bib and pre-order data in vendor system; load to FOLIO to create bib & order, then finalize order and send from FOLIO to vendor | GOBI, PQ-OASIS, OCLC | MARCcat, Instance, Holdings, Item, Order | Acquisitions | May match to an existing bib record or create a new bib record. May need to create different FOLIO components depending on P or E (e.g. items) | |
| 2 | Loading order records | User orders in vendor system, then loads to FOLIO to create bib and order | GOBI, OCLC, PQ-OASIS, OttoEds, Casalini, Amalivre, ATC, (Cornell has local system POOF which loads order records pulled from OCLC via Search API) | MARCcat, Instance, Holdings, Item, Order | Acquisitions | May match to an existing bib record or create a new bib record. May need to create different FOLIO components depending on P or E (e.g. items) | |
| 3 | Loading shelfready cataloging records from acq vendor | User receives shelfready services from vendor; loads to FOLIO to overlay any previous bib record, update holding with final location/call number/other info, update item record with barcode/piece/other info | GOBI, OCLC, Casalini, HRSW, Amalivre, Proquest/Coutts, CNPIEC, Qingyinkemao Development Center | MARCcat, Instance, Holdings, Item | Cataloging | Key piece of this is matching to any pre-existing bib, holdings, item | |
| 4 | Loading approval cataloging records, separate EDIFACT invoice | User receives records for incoming approval plan purchases (P or E); loads to FOLIO to create bib, holdings, item, order; followed by separate EDIFACT invoice load | GOBI, OCLC, Casalini, Amalivre, Harrassowitz | MARCcat, Instance, Holdings, Item, Order, Invoice | Acquisitions Cataloging | May match to an existing bib record or create a new bib record; may have full shelfready data or may require manual updating by library staff to finalize everything | |
| 5 | Loading eresource catalog records from a knowledge base MARC record service | User receives files of new, update and delete records to manage discovery of electronic resources. Loads to FOLIO to create, update or delete bib records. | ExLibris, EBSCO, OCLC, ProQuest, Oxford, Project MUSE, Swank, Kanopy, Cambridge | MARCcat, Instance, Codex?, ERM? | Cataloging | Each file is split between monographs and serials to streamline processing and troubleshooting. Currently matches on vendor-supplied system number. Match file is further subdivided by the ILS between records with temporary vendor system numbers and stable vendor system numbers. (More details available) Codex situation: may have a version coming from Inventory and from External KB Lisa McColl - We use provider neutral records. If we receive two "copies" of ebooks that are from two different platforms, we currently need the system to match on OCLC number (although I realize other institutions that have provider neutral records choose other match points such as ISBN), then either 1) add the new ebook to the existing record if there is one, both updating the bib with an added 856 field and adding an holdings to that existing bib or 2) create a new instance/holding for this new ebook. | |
| 6 | Loading outsourced cataloging records (contract cataloging) | User receives a file from a vendor of fully-cataloged non-Latin script records to overlay brief bib records, and update holding records. Source of bib record is not the acquisitions vendor. | Wuheba, Backstage, DK Agencies, Panmun, CIBTC, Leila | MARCcat, Instance, Holdings, Item | Cataloging | When initial file is sent to the vendor it includes item barcode information for each title. The completed vendor cataloging file then uses the barcode recorded in a MARC field as the match point. Holding records are either created or updated with final call number, which also update the item record. May just bring in bib record and do the rest (holdings, items) locally. | |
| 7 | (re)Loading bibliographic records that have been exported from the system, and edited - updating bib data only. | User may need to perform a batch cleanup on a set of bibliographic records for many reasons. Examples could be adding a consistent note to a set of identified records so the records display in a certain way in the discovery layer or making a set of records RDA compliant. | FOLIO | MARCcat, Instance | Cataloging | Lisa McColl McColl | (In scope?) - Sometimes it is necessary to update the bibliographic portion of the records only, without touching the holdings and items attached to them. This could be seen also as a "Global Edit" issue, in addition to an import issue or even instead of. That depends on the scope of this loader. Match points would probably best be the FOLIO ids in this case. Batch editing/global updates in FOLIO might help keep from having to export records. |
| 8 | (re)Loading bibliographic, holdings, items records that have been edited | User receives a notice that the URLs for a particular set of eresources have changed. Those eresource need to be identified, exported, then reimported with the correct URL that is placed in the bibliographic record but also on the holding record (presumably not the item record, but I'm not sure) | FOLIO | MARCcat, Instance, Holding, Item | Cataloging | Lisa McColl McColl | Unlike the above scenario, in this one, multiple parts of a record will need updating. Match points would probably best be the FOLIO ids in this case. Again, whether or not this is in scope depends on the ability of MarcCat to perform a global edit and send the changes to the Inventory app, without needing to export at all. |
| 9 | Loading approval cataloging records, plus MARC invoicing | User receives a file of cataloging records with order and invoice data in 9xx fields. Import process creates instance, holdings, items, order, and invoice. All happens at point of receipt. | Bach, Books from Mexico, Eastview, Erasmus, Iberoamericana, Karno, Retta, Weinberg, Worldwide, Amalivre, Rossi, Iturriaga, (JPT), MIPP, Lexicon, Leila (EDI available from Casalini, Harrassowitz, GOBI) | MARCcat, Instance, Holdings, Item, Order, Invoice | Acquisitions Cataloging | Unlike the approval scenario that describes the ingest of an EDIFACT invoice after processing the MARC order; these are approval records for which we only receive invoice data in MARC 9xx fields. We do use the same process for other vendors as well, but I have excluded vendors from the list if we are able to receive EDIFACT invoices. Our current process is actually two processes; the invoice import process immediately follows the order import process. (scheduled once, then calls the order process, then invoice process). It would be preferable if a single process could create the order and the invoice. Duke runs one invoice at a time, a macro process. | |
| 10 | Loading non-Latin firm cataloging records with MARC invoicing | User receives a file of fully cataloged records with non-Latin script and with invoice data in 9xx fields. Import process updates instance, holdings, item, and invoice. | CIBTC, Leila | MARCcat, Instance, Holdings, Item, Invoice | Acquisitions Cataloging | This is similar to the "Loading outsourced cataloging records" scenario with the addition of invoice data in the 9xx field. Point of order: creating orders locally manually or spreadsheet (no vendor records). At point of receipt, these records are full cataloging (to overlay brief record), plus 9xx invoicing data. | |
| 11 | Loading catalog records for physical materials with no orders | User receives a file of records and loads to FOLIO to create bibs, holdings, and items | LC-Cairo (PL-480) plan, MARCIVE, (and many other vendors for Cornell) | MARCcat, Instance, Holdings, Items | Cataloging | These types of loads do not need order or invoice generation. No interaction with acquisitions. For physical materials. Similar to approvals without interacting with acquisitions. | |
| 12 | Loading catalog records for e-resources with no orders | User receives a file of records and loads to FOLIO to create bibs, holdings | Lots of e-vendors | MARCcat, Instance, Holdings | Cataloging | These types of loads do not need order or invoice generation. No interaction with acquisitions. For e-materials. Similar to approvals without interacting with acquisitions. | |
| 13 | Loading catalog records with no orders | User receives a file of records and load to FOLIO to create bibs | CRL (shared collection) | MARCcat, Instance | Cataloging | These types of load do not need order or invoice generation. Uses 852 in the bib to point users to the ILL form. Also use this for lots of e-resource files, with URL in 856. Holdings not mandatory in FOLIO inventory. | |
| 14 | Single record import/overlay | User in cataloging department needs to overlay a brief record that may have come in via acquisitions with a fully fleshed out record. | OCLC, Z39.50 | MARCcat, Instance, Holdings, Item | Cataloging | Lisa McColl McColl | (In scope?) While this defies the word "batch" I wanted to put something here, even if it's a placeholder, to make the ability to import a single record in a simple way, does not get overlooked. Currently in OLE our single record import is so clunky that everyone uses the "batch import" even for single records, because it is easier to use than the "single bib import" feature in OLE. In our system, previous to OLE, users had the ability to overlay a record that was open in the ILS without having to force a match point. The overlay was made just by virtue of the fact the record they wanted to overlay was open. This feature has been sorely missed by staff members. Without out it this once simple process has become exponentially complicated to staff members. |
| 15 | Loading items to a single holding record | User takes a spreadsheet of item information and loads to a single holding record in FOLIO to batch create items | Spreadsheet | Holding, Items | Cataloging | Used for special collections projects and large holdings management projects. Large donor projects. Link to the holdings, plus a way to create the items from the spreadsheet data. Might need to match on the bib first? Would be best if could match to the actual holdings ID though. | |
| 16 | Performing batch authority control updates to catalog records | Extracts from the catalog are sent to an authority control vendor. Vendor returns a file of updated bib records; user loads into FOLIO to overlay existing bib records | LTI Backstage | MARCcat, Instance | Cataloging | Extracts and returned update files can run weekly or quarterly, or both. | |
| 17 | Loading authority records | Authority control vendor provides new, changed, (and deleted?) authority records, based on catalog data sent by the library. Library loads the authority records to FOLIO to inform the authorized headings and cross-references | LTI Backstage | MARCcat | Authorities | Do we know how much or how little Inventory and Codex will be paying attention to authorized headings and cross references? | |
| 18 | Load single authority record | Search from FOLIO to find authority record and import. | VIAF, OCLC, other sources | MARCcat | Authorities | ||
| 19 | DDA Discovery Records/PDA | Vendor provides DDA Discovery records. Import creates a new instance with a local electronic holdings record. | GOBI, Kanopy, Coutts-OASIS, eBook Central | MARCcat, Electronic Holdings (Local - Inventory) Unless only loading to Discovery | Cataloging | The instance receives an Instance Status of DDA Discovery to differentiate the record from that of an instance with owned items. Discovery records may be loaded into discovery only (outside the scope of FOLIO) or into FOLIO. Often a code so that the library knows these are not owned (yet) | |
| 20 | DDA Purchase (POP)/PDA | Vendor provides a MARC file with order and invoice data in 9xx fields. Import replaces DDA Discovery record and updates local electronic holdings record. | GOBI, Kanopy | MARCcat, Electronic Holdings (Local - Inventory), Order, Invoice | Acquisitions' Cataloging | The Instance Status is changed from DDA Discovery. If Discovery records are loaded into discovery system only (not ILS), then POP records are new to FOLIO. If Discovery records are loaded to FOLIO, then POP records have to overlay/update the discovery records, plus take care of the acq stuff. | |
| 21 | EBA DIscovery | Publisher provides EBA Discovery records. Import creates a new instance with a local electronic holdings record. | Cambridge, Docuseek2 (streaming video), Taylor & Francis, Project MUSE, Oxford Scholarship Online, Sage, JSTOR | MARCcat, eHoldings (Local Inventory) Unless only loading to discovery | Acquisitions | Lisa McColl McColl | May extract the ISBNs from the publisher records to harvest better OCLC records. Code to brand these records, so that they can be removed or suppressed. (Note: EBA not working so well for Lehigh/Cornell) |
| 22 | EBA POP | At end of a cycle, library decides which titles will be purchased and which will be dropped. | Cambridge | MARCcat, Electronic Holdings (Local - Inventory), Order, Invoice | Acquisitions Cataloging | Lisa McColl McColl | Would need to change the flag and do the acq work |
| 23 | Orders from spreadsheets | Bibliographer provides bibliographic and order data in spreadsheet. Import creates a new instance, holdings, item, and order. | local spreadsheet Andromeda Research, Zahraei, Sulaiman, Nazeer, MG Noura, Libra, Lexicon, Kozmenko, Panmun, Iran Farhang | MARCcat, Instance, Holdings, Item, Order | Acquisitions | Bibliographer enters data for orders into a spreadsheet or uses spreadsheet provided by vendor. Staff uses MarcEdit to convert the spreadsheet to a brief MARC record with order data in the 9xx fields. Some vendors for which we create orders in this manner include: Andromeda Research, Zahraei, Sulaiman, Nazeer, MG Noura, Libra, Lexicon, Kozmenko, Panmun, Iran Farhang. (Cornell does this for Korean and Vietnamese books, but do not create order records - just pay on a dummy record.) This workflow is also of interest to Duke. Maybe add OCLC numbers, so that you have a matchpoint for the cat record. MIght just want to create Instance, and then create MARC later. Others may want to create both Instance and MARCcat. If only creating Inventory, maybe just creates Inventory JSON. If loading to MARCcat, create MARC version too. | |
| 24 | Invoice records from EDI file | EDI file is automatically imported into system. | EBSCO Harrassowitz GOBI, Coutts, Nardecchia, Casalini, Hein | Invoice | Acquisitions | User links invoice (scanned image) to order. Match point is a single number representing title/account#/sub-account#. | |
| 25 | Load MARC file to create Inventory instance, but don't store a MARC record in FOLIO | Maybe at point of order - I want an inventory instance and order, but no MARC record. Then at point of receipt, I'll load or create a MARC cataloging record and link it up to the pre-existing Inventory instance. | ??? | Instance, Order | Acquisitions | Would start to break the "tyranny of MARC." Have to be mindful of what is being exported to patron discovery layer, and from where within FOLIO. Maybe a time-saver for spreadsheet workflow, if can just create a brief Inventory JSON record and not have to deal with MARC details. | |
| 26 | Load bib and order data via API (XML format) | Real-time load to create bib and order | GOBI, Coutts, HRSW | Instance, maybe MARCcat, Holdings, maybe Item, Order | Acquisitions | Chicago already has this with OLE; also used by Alma, Sierra, Koha libraries | |
| 27 | Load records for print and e-resources that are conglomerates of OCLC records, vendor records, and local information. | Vendors supply records that are often substandard in quality to what is available through OCLC. We take what we need from the vendor records: the indication that we now have access to this resources via an identifier for that resource, and in the case of eresources, our institution specific URLs, locate appropriate OCLC records (using OpenRefine and OCLC's API), merge the records, keeping most of the OCLC information, but also adding the institution specific URL, then run a MarcEdit macro to add local information such as collection codes that relate to our CORAL. This is all done at a pre-import stage at the moment. Mostly MARC files, but sometimes spreadsheets. | OCLC OpenRefine Publishers | Instance, MARCcat, Holdings, maybe Item | Cataloging | Lisa McColl McColl | Since we currently do this before the point of import, I would not expect this from v.1 of FOLIO, I don't think. However, I think if a system gave the user the ability to construct records in a staging area, giving the user the ability to select what they want to take from various record sources, including local fields, it would the steps listed in the description area. Relates to "beefing up" smaller vendor records with TOC, local format info, by merging OCLC data with vendor records. Mostly just keep the URL and ISBN from the vendor record, hopefully an OCLC number. Track in CORAL, with CORAL IDs. In an ideal world we would all use the same record from one source, but there is a lot in place preventing libraries from achieving that ideal, so this system of constructing records from various sources is what we need to do to try to have important information like the Table of Contents, 33X fields, 006 and 007 fields appropriately coded, included in the record. |
| 28 | (re)Loading bibliographic records that have been exported from the system, and edited - updating OCLC number only. | User may need send out records to match to OCLC, then reload to FOLIO to update the OCLC number. That may be the only piece of data that they want to update in the FOLIO MARC record and Instance. | FOLIO | MARCcat, Instance | Cataloging | Chicago Cornell | May only need to import a delimited file with FOLIO HRID and OCLC number. |
13 Comments
Leeda Adkins
For the "Loading shelfready cataloging records" use case, Duke has Shelf-Ready plans with GOBI that both utilize the OCLC WCP records and divide into a firm order and an approval workflow. The firm order workflow looks like the use case described above; however the approval workflow does not work off a pre-order record. Our approval shelfready workflow generates a new bib, holding, order and item with the full barcode populated.
Should I add this as a use case, or do you think it's more-or-less covered in the one above?
Thanks!
Ann-Marie Breaux
Hi Leeda, is that the same as the "loading approval cataloging records" scenario (the last one listed currently)? If yes, then just add some notes or updates to that scenario.
I didn't create all the scenarios that I could think of (DDA, EBA, loading various cataloging files, loading authorities), hoping that others would start filling those in. So hopefully everyone will have at it!
Leeda Adkins
Thanks Ann-Marie! I think your note for "loading approval cataloging records" covers it. Another question: for "Record Source," do we need to add more use cases for other approval vendors (Casalini, Amalivre, Harrassowitz) if the case is basically covered above, or can we just add the vendors into the Record Source for the existing cases?
I'm going to try to tackle a use case for Serials Solutions 360Marc update loading today, with the caveat that it may be a confusing bear. (I only learned how to load them myself late last year.)
Ann-Marie Breaux
Hi Leeda - I missed this earlier question. If it's the same workflow, but records come from a different source, just add the additional source(s) into the existing case. That will help us get a feel for how widespread that workflow is, and how many sources are already attuned to it. Thank you!
Christie Thomas
Leeda: Do Iberoamericana and Retta provide EDIFACT records along with the MARC for your approvals? We do not receive an EDIFACT invoice with our approvals, so the approval workflow that requires the invoice to be loaded separately would not work for us.
Leeda Adkins
Hi Christie, they do not supply EDIFACT for us; in fact, none of our monograph loads have EDIFACT at the moment. They all come in with order and invoice data in the 9xx fields. Should we parse these out as a new use case? For now I will add a note to the existing use case, that everything applies except the EDIFACT part.
Christie Thomas
Thanks, Leeda. I added a new use case just to capture it even if it is out of scope for v1.
Ann-Marie: Should we add workflows for electronic resources and assume that the electronic holdings data will be represented within the holdings? I don't know if it has yet been decided where local electronic holdings will be stored.
Lisa McColl
Same question here about electronic resources and holdings.
Ann-Marie Breaux
Hi Lisa and Christie, Sorry - just surfacing for air from nonstop meetings today. Yes, please add those as use cases. If you think that there may be related ERM updates, be sure to add a note about that. Speaking of which, we should talk for a minute tomorrow about whether we have any ERM subgroup members in our group, or if we need to solicit someone from ERM to join this group. Would be good to have a person who can connect us to the latest thinking on that portion of FOLIO.
Lisa McColl
I see Kristin Martin's name on the group members page...
Gary
Cornell only uses EDIFACT for invoice data both firm and continuations. The vendors are Coutts, Yankee, Amalivre, Casalini, Harrassowitz, Hein, and Midwest.
Ann-Marie Breaux
Thanks, Gary - I've added Hein and Midwest to our list of sources for batch data.
Uschi Klute
Loading User data is a common use case also. A large number of our University Libraries uses a process in which patrons enter their data via a web form. This data is converted into the format of the library system in the background and then imported into the library system on a daily/hourly/minutely basis. Entering user data at the service point is not an option for these libraries.