Skip to end of metadata
Go to start of metadata



Discussion items

Minute takerBethany Greene

ERM Update

  • Kirstin gave an update on the ERM Project Plan:
    • GOKb is fully integrated in FOLIO for v1 - you download the metadata from GOKb into FOLIO and use it with other FOLIO services - the problem with eHoldings is that it only contains data from EBSCO's kb - if you don't use the EBSCO kb you won't have any data in FOLIO
    • Tricky situation for institutions that don't use GOKb as their kb provider. Those institutions can still pull in bibliographic data from GOKb to link up to ERM functionality, but they will have to activate the resource within their external kb as well.
    • Consortial and reporting features are integrated
    • Discussion of integrating other kbs will be necessary moving forward

  • Peter is going to investigate whether or not the ProQuest/SerialsSolutions kb data can be integrated into FOLIO
  • Followup

    Subscribers can download files showing their specific e-resource entitlements from their link resolver/data management vendor. These files could then be used to populate a local instance of the FOLIO ERM tool, after the library has modified the knowledgebase output to meet FOLIO input requirements. Customers are not harvesting all the data that’s available from a knowledgebase vendor; they are only collecting data that reflects the holdings at their institution.

    Here are some specific instructions for several common knowledgebases:

    EBSCO Holdings Management: Follow instructions at this link.

    ExLibris SFX: (can someone fill in specifics here?)

    OCLC WorldCat e-resources knowledgebase: (can someone fill in specifics here?)

    ProQuest 360 Knowledgebase tools (former Serials Solutions): Go to Reports, then Management Reports. Select the “Tracked eJournals” dropdown option, name the output, and click the “Request Report” button. Very large files may take up to 10-15 minutes to be generated.

    PMc, 8/31/18


    Clarification Re "Customers are not harvesting all the data that’s available from a knowledgebase vendor; they are only collecting data that reflects the holdings at their institution." . The starting point for Folio ERM is harvesting the entire knowledgebase. The point I (badly) tried to make in the meeting was that this was information the library would have access to through existing access to the KB, and there was no intention for that data to be shared outside the subscribing library.

    I can see us looking at the possibility of only harvesting Local holdings from a KB, but that isn't the initial approach we are taking.

    Owen Stephens 4th Sept 2018

  • Bjorn gave an update on the eUsage app:
    • Enter your SUSHI credentials and the app will automatically harvest COUNTER statistics on a monthly basis
    • The stats are stored and will be made available to other FOLIO apps like ERM through APIs
    • Aim to finish the UI and harvesting process by October 2018; will then start working on allowing for manual upload of non-COUNTER statistics
    • In-app reporting in the ERM app using eUsage app data
    • Link to eUsage app Project Plan:

Announcements/PC Updates

  • No PC Meeting this week
  • Acquisitions update
  • Proof of concept for workflow functionality going up to PC soon

  • Acquisitions small group update:
    • Finance sample data will be populated next week
    • Orders module is being integrated into testing environment next week as well - able to create POs and PO lines
    • In queue: handful of issues enhancements from UAT for Vendors app, Acquisitions units/teams in the works
Current State of Batch Loading
  • Nine developers assigned to batch loading
  • Types of records: MARC bib data, EDI invoicing, MARC holdings, MARC authority, delimited/flat files (interim solution: convert to MARC before loading), order API data (not via Batch Loader)
  • MARC details: binary and XML, JSON is out of scope for v1
  • Miscellaneous: loading single records into FOLIO, rollback the load, scheduler, queuing the loads, exporting files from FOLIO, full bib/holdings/item data migration from previous library system
  • Starting with one use case and fitting it against the wireframes to make sure the design works
  • User stories: only research spikes so far, no UI stories yet, no backend stories yet
  • Next steps: finalize UI and requirements, understand MARC loader development done to date, outline backend architecture, write backend stories, write UI stories
  • Timeline: prelim release in mid-October 2018 - live in January 2019
  • Stuck on a name for the batch loader

FOLIO Data Migration Subgroup Survey

  • Report on needs for migrating historical data
  • Deadline Sept. 14
Kristin Martin
  • Put your notes directly into the Google document.
  • Institutional needs for migrating historical data - we should think about it in terms of acquisitions data (ERM data too if you have an integrated ERM)

Action items



  1. Re: the ERM/KB conversation, and harvesting the whole KB versus one library's holdings: I totally understand that the ERM has a tight timeline and a model that is being driven by the German libraries who will be using it with GoKB. At some point, it would be good to understand what a workflow might look like for early adopter libraries who use commercial KBs (mainly PQ and EBSCO, I guess, but maybe OCLC?), and will also have access to the tools within the ERM and eHoldings app. Between licenses, packages, eUsage, eHoldings, linking to orders, linking to vendors, etc - can that be pulled together into a workflow that is useful for those libraries? Since that is beyond the scope of the ERM group, maybe we could have a further conversation about it at an upcoming RM SIG meeting? Or maybe this is not a pressing issue for the early adopter libraries, so not necessary to discuss at this time. If that's the case, maybe we just acknowledge and document that and move on. In any event, thanks for considering.

  2. Hi Ann-Marie, Ian and I are at the moment sitting together and discussing this topic. We thought about asking the other libraries about their needs. So, it may take until tomorrow, then we will come back with some ideas.

  3. Commercial knowledgebase vendors will not provide the complete contents of their knowledgebases to use as a basis from which a library selected or managed content. I don't know if GOkb will provide an effective tool for libraries to use; even if it offers the ability for German libraries to download its entire data set, FOLIO implementation will then need a way to manage the changes between the knowledgebase and local changes and updates. It will be necessary for libraries to determine how often they want to update their version of the GOkb database; presumably they would need to update their version of the GOkb database at least once per week, if not more often. They would then need to manage knowledgebase updates versus local changes and updates. 

  4. Indeed. I think owen has clearer thinking here, and we went through some of this in KB+ where we queued up "ToDo" items which allowed the eresources librarian to approve change by change the modifications coming from the KB which implied a change to their agreement. Institutions were then free to accept the change, or to challenge it. However, we almost instantly had to implement an "Accept All" as the initial shine of this feature quickly became a burden given the rate of change for some packages. I think where we ended up was deciding that the default setting would be to automatically apply changes to an agreement BUT always provide an "undo" button on the alert. Of course you could turn this off and revert to the old manual style. And this would really only work for "Managed" packages where you have decided to track what comes and goes at the title level. Users choosing the "Package" level entitlement would get what they are given. This means that an eresources librarian would  see an alert like "Journal of Clincial Cancer Drugs was removed from Package Bentham Science which is an entitlement in your Bentham Science Subscription Agreement. Click here to revert this change. In later projects, we started moving in the direction of flagging specific titles (This applied more to core text ebooks) for which the administrator wanted a special level of alert if they suddenly vanished. The interplay of "Core" here is something we never really bottomed out. Owen - have I misrepresented? I don't think what I've described here is necessarily v1, but I think it is where our thinking is.....

  5. Ooh Peter McCracken currently the KB sync is a nightly. In theory it could be more often, but that feels unnecessary - interested in thoughts about that tho – IE does weekly protect us slightly from daft changes that shouldn't have been published and get pulled as soon as they go out - Should we deliberately introduce a lag into the propagation of KB data? Feels a bit like gmails "undo" feature (smile)