Skip FOLIO Project Navigation

MM/RM Notes from Simmons FOLIO Day (from Ann-Marie Breaux)

resource-management

#1

Also relates to resource management. Here’s some notes I sent to MM and RM SIG conveners last week:

Yesterday there was a FOLIO Day at Simmons in Boston, sponsored by the Fenway Libraries Online (http://www.flo.org/). It was a general intro to the FOLIO project, plus some emphasis on small/medium libraries and consortia. There were ca. 60 attendees. Main speakers were Neil Block, Mike Winkler, Sebastian Hammer, and Tania Fersenheim.

I facilitated a breakout on metadata & resource management, along with my colleague Marc Keepper. Here’s a few notes that I thought would be helpful to pass along for the RM and MM SIGs. Most important bits are highlighted.

Breakout 4: Metadata: Ann-Marie and Marc (ca. 15 librarians)

  1. Is anyone taking part in any of the FOLIO SIGs? A couple folks had attended a couple sessions

  2. Using other FOLIO communication channels? A little

  3. Questions about anything you’ve heard this morning?
    Some confusion that the codex meant that the source records would be taken apart (e.g. break apart the MARC record), making it hard to work with the data; explained that the source records would remain whole, but that the key data would be distilled into the codex for 1) indexing/searching across all metadata types and 2) to attach local data to, e.g. items, orders, holdings

  4. What kinds of metadata are they managing?
    MARC, MARC, and more MARC
    Drupal for archives
    Dublin Core; OAIdc? [whatever Content DM supports]

  5. What are key topics they want to be sure FOLIO handles in terms of metadata?
    Authority control – especially important for music; not handled well by discovery systems
    Important to recognize and protect the unique stuff that has to stay that may not be in the master/source records
    Should authority control be its own SIG? Maybe a subgroup within the MM SIG?

  6. Do you use other open source software in your library?
    Blacklight/Fedora for course reserves
    Coral for ERM
    Evergreen
    Avalon for streaming audio and video
    Drupal
    FileZilla
    MarcEdit [not open source, but free]

  7. For libraries that are not comfortable with a system that’s in such an early phase, they don’t want to have to start too early, when there’s not enough to play with and react to yet (we talked about people who get involved early (and have some input, like Purdue with Alma) and others who prefer not to, which is also fine

  8. Why would everything have to get translated into MARC before showing up?
    In FOLIO it wouldn’t (e.g. federated search against all various metadata types)
    Lots of libraries do that (represent all in MARC), regardless of what may be in the IR or other metadata sources

  9. Have a way to include types of data that may be important to a particular type of resource
    Example:
    Oral histories
    — Be able to go to minute 2 of every oral history
    — When an interview was done, location of interview
    — Relationship between the interviewer and the subject (parent/child, teacher/student, spouse, etc.)

  10. Being able to pull a shelflist (listing in call number order), to help with assigning call numbers, with accreditation stats
    Some systems can’t easily do that
    Some libraries want call numbers for E-content as well as physical, as another access/stats data point

  11. Systems not forcing simplicity or conformity or complexity (e.g. complexity of circ policies, copy numbers, complexity of locations); not requiring lots of print overhead if the library doesn’t use print

  12. Music and Visual Materials people not represented well in the SIGs yet, and they have special needs (the arts library communities)

  13. Consortial comments
    Fenway Libraries Consortium: Voyager works; FOLIO feels scary and underdeveloped; leery about it being easy to get up and running, especially for a consortium
    MARC is not implemented in the same way in every system, which can be extremely limiting
    Single record approaches vs separate records in a shared catalog
    Full-on holdings vs abbreviated holdings

  14. Be able to have reporting out from FOLIO to the institution’s enterprise system (Banner or WorkDay or Other) so that they can run and make the payments

  15. Having a workflow store, or a API store, or a report store; benefit from the work that other members of the community have already done

  16. Open Source
    Some of the attendees are using Evergreen, so they’re already used to the idea of open source ILS
    A benefit of open source: you have access to your data: can use system reporting tools, or develop own tools, or write a query
    How you work with open source can change over time: maybe start with hosted system, then bring it in house

  17. The idea of APIs are scary and intimidating (but they don’t have to be); individual FOLIO libraries won’t have to write their own APIs, but can if they want to


#2

This is an interesting comment because I think of “master/source records” as the metadata-of-record – those records from which everything else is derived. In way-back times, there could be local notes penciled on shelflist cards (hence the reason why shelflist lasted so long in cataloging departments). Is there something I’m missing?

Good question. I for one would be interested in a local authority service, and at the Dublin developers meeting earlier this month there was a discussion about how a plug-in structure for FOLIO could facilitate that at the point where someone builds a MARC record editor for FOLIO. Anything that would help put more structure in the records for discovery systems to use would be a good thing.


#3

Hi Peter,

Remember I’m only passing along notes from the conversation, not necessarily advocating for all of this!

With regards to the unique stuff: may depend on what the master/source record is (shared consortial record, individual library record, stored locally, or referenced), and whether the unique info has to do with individual copies. Also may depend on where unique copy-level info is ultimately stored - in an item record perhaps?

Authorities: I’m definitely not an authority (!) on this, but I agree wholeheartedly that all of the work that’s done to coordinate and consolidate/distinguish various versions, people, places, things, concepts is one of the long-standing strengths of library metadata. MARC authority records may be an overly-cumbersome model in this day and age, but having a way to store and use that data, whether MARC or some other way, will be very important and useful.


#4

Seems to me that Person Authority is well setup to be referential via VIAF or similar construct. Subject Authority doesn’t have as strong an infrastructure, but we should assume that this is developing and will mature. This sort of linking would obviate FOLIO of having persist these things locally.


#5

VIAF can be one source of Person Authority records, but there will be lots of name authorities that would never rise to the level of being included in national databases. For example, during the IMLS-funded, Cornell-coordinated effort on sharing local authorities, I learned that libraries want to have controlled access to entities like thesis advisor names. Those names may not have published works, and so they wouldn’t have a natural way to find themselves into the NACO → LC → VIAF chain. What FOLIO would need to do is provide a way to reuse these local authorities between systems at an institution and hopefully share them with other institutions.


#6

i certainly wasn’t saying only VIAF. might be good to use ORCID which could pick up some of those names that you refer. we will need to include local authorities, for sure, but we should encourage use of ids at the network level.