:page_facing_up::zap: Importing .marc approaches (English)

I like B2 as the simple option - there are a lot of staff who just need to import the record and move on.

But there are also a lot of staff who will need to do more complicated things. For those, I think I’d prefer the plugin variant of A - where you go to your app (Inventory, Workflow, To-Do, etc.) to choose the complicated thing you need to do, and once you’ve opened that thing, drop the file. If a staff member could customize which things they need/do most often within that app, and hide the rest of the complicated-thing choices, that would also be handy.

So I think I’d like there to be a setting where a staff member can choose between B2 and A-plugin (or whatever) as their default.

(And I really, really like the idea of dropping the file into a To-Do. That’s super for not having to hunt for the file when you finally have time to work on it.)

Thanks for your advice, Heather!

Can you name a few examples of the ‘complicated things’ you mention people might be doing after they upload a file?

Sure thing - off the top of my head:

1. When we get big MARC files from different sources, our Batch Processing unit evaluates their quality and often has to add/edit metadata to bring them up to our standards. They have a bunch of different scripts configured for regular MARC sources, to make the edits that specific vendor’s files usually require.

2. They also have a bunch of different import profiles - when you import this MARC and it finds a duplicate, does it bounce out for manual evaluation, overwrite, or merge onto the record while preserving specific fields on the old record? We use the first one for DDA imports, the second for metadata corrections, and the third for loading updates to our Serials Solutions MARC records.

3. I buy e-book packages; if I’m importing MARC records, I’m going to want to attach them to their… uh… I haven’t looked at what exists in the way of package-level records or licenses and stuff yet. But I’m going to want to attach those individual titles to their appropriate e-resource management stuff, as soon as I import them.

4. I also design special maintenance projects, usually as training in e-resources for less-experienced staff members. In this case, it would be more likely that I’d be dropping a spreadsheet into a workflow or a task, and then write out detailed instructions for what my staff should do with this data.

5. Thinking of invoices and PDFs - there are some vendors with whom we consistently have Discussions about whether or not we’ve purchased a title or package. In the invoicing area, I’d like to be able to drop in a PDF copy of the invoice itself, so it’s ready at hand to send back to the vendor when we have such a Discussion - possibly also attached to a note explaining what, exactly, this vendor tends to give us problems with. I don’t expect to need to do this for every vendor, but there are a few frequent offenders.

6. And along the same lines, I’d like to be able to drop spreadsheet title lists of what was supposed to be in a package onto… an invoice? The package-level e-resource record? (It would also be cool if FOLIO could compare that title list to the Inventory to check on which titles we haven’t actually gotten yet, which would be useful for frontlist purchases, but that’s just a random brainstorm popping out.)

Hi @Heather,
Number 6 and number 7 sounds much like ERM funcionality. I would find it very helpful to be able to add documents like invoices, notes and spreadsheets to the FOLIO apps.

I like variant B1 because one can postpone the further processing to later. This might be helpful if the library has received metadata from the provider, but the activation and further processing depends on other factors.

HI Filip- this is great. I like the idea of a ‘general purpose’ file importer. As we roll more ERM-type stuff into FOLIO, we’d definitely want the ability to import .pdf’s; word docs; as well as spreadsheets for invoicing & package lists; and - of course- MARC records.
Here at NCSU - we have tons of automated record loads - Order confirmation records + brief bibs from vendors; to be replaced by full bib/order/invoice records in later loads is one common example. So what you outline in “D” is right up our ally. We’d need to be able to customize the loading profile & matching rules & it would be great if we could set it up as an automatic (daily/weekly) process that just runs in the background.
as Heather indicates, there is a range of complexity, from just uploading and attaching a document, to generating order records from an invoice or spreadsheet, to loading marc records with order, invoice, and item data & the system ‘automagically’ generates all those associated records. Being able to associate a loaded file with a specific workflow will definitely help for complex processing. And I agree with Heather & Felix that being able to put the file on one’s ‘to-do’ list will be super helpful!

There may likely be cases where we’d only want someone to be loading/linking certain types of files (for example: acquisitions staff can only upload .pdf files to the acquisitions module; cataloging staff can only import marc files) - do you envision that we’d be able to define permissions that granularly for file upload?

Hi Lynn,

Thanks for your advice and descriptions of your workflows. It is all very good advice!

Regarding limiting what people can upload, here is my take on it:

I do not see any version of the future in which we would want to limit what people can upload to the system. For this reason: Anything you upload does not necessarily get placed in any record. You would be able to upload a stack of spreadsheets, and do nothing with them. They would simply sit there in the Files app until you choose to do something with them, or unless we implement the auto-suggested actions feature outlined in my sketches above.

I feel strongly that a much better and less frustrating approach for end users would be this: That we limit which file types can be added to certain record types and/or which apps will process which types of files. However, because the system can never fully know if it’s appropriate for any given person to upload a spreadsheet or marc file for their own usage, or to share it with a colleague, it would—in my humble, but strongly held, opinion—not be prudent to attempt to limit anyone from simply uploading a file to FOLIO, in itself.

HI Filip-
Limiting what file types can be processed/ingested by which apps; or what
filetypes can be linked to certain records makes sense. Thanks for the
response!

Lynn

Lynn Whittenberger
Associate Head, Acquisitions and Discovery (Monographs)
NCSU Libraries
Lynn_Whittenberger@ncsu.edu
919-513-3833
(Pronouns: she, her, hers)

Filip – will this import process apply to single records brought into FOLIO as well as files of multiple records? That might influence what kind of functionality I do/don’t want.
Thanks,
Laura

I think we will want both to be supported through these mechanisms — what do you think?

I am more likely to want default, automatic behaviors for single records and to want more options to specify behaviors for files of multiple records. Would some examples be helpful?

Examples would be great!

Here’s my attempt to give examples, with rather wordy explanations of what I’m thinking.

Single record

1. A cataloger (or other staff member) imports a new MARC record from OCLC into the local inventory. Ideally, staff member can push the record from OCLC Connexion into FOLIO without necessarily opening the inventory app. A default profile would be applied (which fields are imported, how they are mapped, and other settings such as whether the record displays in discovery or not).

2. A staff member imports a MARC record from OCLC intended to replace an existing record in FOLIO. Either in inventory app or in OCLC Connexion, the staff member can either select/define an existing profile (specify which record to match on, specify a set of field mappings, etc.) or the default will be applied.

In both cases, it would be nice for the staff member not to have to specify anything, assuming they understand the default behaviors. This allows people performing straightforward, routine copy cataloging with a fairly simple workflow.

Multiple records

1. A cataloger has retrieved a file from a vendor and edited the file in MarcEdit. Either from MarcEdit or from within the FOLIO inventory app, the cataloger selects a load profile and possibly other follow-up actions.

It is much less important to me for there to be a default behavior for batch loading (others may disagree) as someone is not usually loading multiple batches repeatedly in the same way they might be loading single records repeatedly. However, it’s more important with batches to have lots of customizable options as I want to avoid bulk editing after the records have been loaded. For example, we might want to attach a holdings record to each bibliographic record in a batch load. So what might seem like excessive customization at the point of import for single records would actually be more efficient for batches of records.