Meeting Time:    8 am EST /  2 pm CET / 1 pm UK

Call in Number:     https://zoom.us/j/995679876 

Meeting URL:  https://zoom.us/j/995679876 Password needed: please see link below

https://folio-org.atlassian.net/wiki/display/COMMUNITY/FOLIO+Meetings+with+Zoom

ERM Sub SIG Folio Wiki: https://folio-org.atlassian.net/wiki/display/RM/ERM+Sub+Group 

Google Folder: https://drive.google.com/drive/folders/17X3tr6siZH8iS07kGcjAqUNl01zVrJmB

Terms and definitions: https://docs.google.com/document/d/1vue-mbcULpZivWu69a7nAZEdC-H2yXPQqSblbL_0J6U

Slack Channel: # erm-team

Agenda Sep 8th 2021

Convener: Martina S.

Notetaker: Martina T.

Housekeeping

• All: Please edit the attendees list below and indicate when you are there!
• Next ERM meeting:  Sep 15th
  
  • looking for volunteers to describe how Agreements vs. Agreement Lines are used to handle different use cases

  • looking for volunteers for a FOLIO Forum: in a panel presentation on how FOLIO libraries are managing ERM & acquisitions, specifically:

    • walking through the acquisition of a new e-resource start to finish (ordering, invoicing, activation, and agreement tracking)
    • walking through a renewal from an orders/invoices/agreement perspective
    • maintaining changes in title lists year over year
• all questions and topics for the ERM implementers meeting can be posted on this confluence page: https://folio-org.atlassian.net/wiki/x/SABS
• Open discuss posts: right now no new posts regarding erm

Agenda items:

1. Development progress - ERM Sprint 122
   
2. Continue on „Agreements vs. Agreement Lines“ - use cases, scenarios and questions to feedback (Jessica)

Minutes

• Development progress - ERM Sprint 122
  

  • ERM 121 was longer sprint, therefore ERM 122 shorter sprint

  • A lot of the work is Background work – migration of test cases to new test software

  • Work on bug fixes

  • Work on how data is loaded from GOKb into the internal KB

  • Trying Different approaches to support it
  • In this sprint: Ability to harvest high quality title information independently of package information
  • Felix (chat): What Jira issue is related to the independent title loading? -> ERM-1801Implement Title Ingest process 
  • Have implemented the ability to do it separately but right now only for GOKb import
  • Harvest title from GOKb separately from GOKb packages

  • Opening up the possibility for other resources

  • We started from harvesting the packages – so behind every title there is a package (platform / provider / sold as part of a package)

  • Harvesting title independently – titles don’t have platform or package information associated with them – no option for acquiring displayed

  • to look at solutions e.g. filters (Search for title with option for acquiring)

• Continue on „Agreements vs. Agreement Lines“ - use cases, scenarios and questions to feedback (Jessica)
  • Example 4: Brill subscriptions: same renewal dates, same license, different POs, all subscribed to direct through Brill. 

    • none of them through consortium

    • several of them encyclopedias – one Agreement for those encyclopedias and each an agreement line

    • Sara: would look at different formats – a lot of them encyclopedia / Another thing to look at which ones have the same platform e.g. Oxford has their encyclopedias / ebooks / handbooks on separate platforms
      Platform and all encyclopedias on one Agreement, Platform and all handbook and linking them to make related agreements 
      Trying to match up usage statistics – which ones I need to look up as groups / Review process – maybe you want different reports or you get them on one report / Vendor the same, renewal date – makes nice groups or sets 

    • Jessica: Do you log your usage statistic type for each of the resources at agreements?

    • Sara: no - I do have it for journals as spreadsheet – started linking it in suppl. documents / In sup. Documents you can upload the file or link to it and nice note filed – preferred method for statistic (counter4 or 5)  

    • Felix (chat): There's also an eUsage - Agreements integration

    • Jack (chat): We currently have three supp. properties configured in our tenant - Resource URL, Simultaneous Users, and Authentication Method. The first two are just open text fields so we can enter the appropriate URL or number/text and the third is a picklist we defined to have what we considered all the relevant auth. methods.

    • Owen: if you are using Licenses as well, it might be appropriate that the suppl. properties are on the Licenses -whatever best for you – you can look up which licenses supports this property - it is more designed into the license applications than the agreement applications - In this case using the same license – you can record the license terms once in the license record and link it to multiple agreements  / Suppl. properties and suppl. documents in agreements can be used for whatever is appropriate for you – but to highlight if you are also using licenses to think about where the information is stored 

    • Owen (chat): Everything here for me points to it being OK to have these as a single agreement for all of these with an agreement line for each title. The breakdown Sara describes as being appropriate as well - but increases the number of agreements - so it might depend on how much variety there is across these different resource types in terms of how they are managed, your contacts, etc. etc.

    • Owen: One renewal date, one license, one organization – single agreement with multiple agreement lines each agreement line link to each own PO / Division more categorized make sense as well to have 3 Agreements rather than one / Just the title in this example might be overkill if you have more agreements / Are there a lot of titles there can be a benefit to separate it / License is the same but there are specific terms that only apply to certain types of resource, then splitting it to agreement – express them as amendment to the license 
    • Sara: platform aspect – using HLM via e-holdings – you might link to different packages / In HLM the Handbooks are one package and the encyclopedia are one – keeping them on different agreements helps to manage the package interaction / Multiple packages on the same agreement and it can be messy / Vendor also packaging them differently 

    • Abby Wickes (chat): I like the idea of capturing authentication methods

    • Jack (chat): We were actually capturing it in two places in CORAL - on the resource record access tab and as a term on the license. Licenses can sometimes grant you more than one option - some are open and some don

    • Felix Hemme (chat): We have a supp. property to record what resource type(s) are managed in the agreement. Feedback from staff is quite good till now

    • Kristin (chat): When will Agreement Lines be searchable?

    • Owen: Like to see it happen – not solid proposal for it at the moment – prepare some proposal to get feedback from the group / Dennis presented at app interaction some ideas in acquisition search across orders and orders line in one search and one search result list / Not the same scenarios, but a lot of parallels / Ideally if possible approach that works across orders and agreements – harder as a new tab in agreements – need to consider cost vs benefit and time scales 

    • Owen: additional complication - because searching for resources and finding the agreement and agreement line as there are part of and that is different in eHolding and internal KB.  / Search internal Kb in the e-resources search – all the agreement that contains that resource – directly or part as a package – same in eHoldings – some differences - not intuitive 

    • Sara (chat): And only if the resource is in eHoldings

    • Owen: yes if the resource is not in eHoldings, then you back to the agreement line level

    • Owen: additional complications: 3 levels – agreement and agreement line and resources that make up the agreement line and then the resource can be in the internal KB or eHoldings / Difficult to find a solution   - More difficult as to make agreement line searchable 

    • Sara: not equal solution – appear in an order that makes senses – agreement lines alphabetically not random / To find it I go into edit more and do an F4 – but I cannot go through all the fields 

    • Owen: putting this on the agenda for another call / Gill and Owen discussing use of edit screen access better to be on the view screen – to explore this further – edit screen is used but not for editing but t give you view type task 

    • Felix (chat): <Sorting> is cumbersome in other areas as well and there was discussion about it last summer.

    • Jessica (chat): We're thinking of using supp. properties for Read & Publish (and other OA agreements), multi-year agreements, fund codes, and hosting fees (depending on how we end up setting up our agreements)

    • Jack (chat):  That's why I'm erring on the side of 1 agreement per resource (with appropriate agreement line based on how the EKB represents that resource)
      Where I have brought together multiple resources it's more like these reference/encyclopedia titles but I don't actually know if it's beneficial yet to have them grouped up because we weren't tracking them as close as say - a popular database or big journal package

  • Example 5: Gale one-time purchase: Some have hosting fees, some do not. Many hosting fees are paid on one PO through our consortium. Some are paid individually direct to Gale.

    • More complicated: Hosting fee – direct and through a consortium

    • Should the one paid through a consortium be on a separate agreement? Should there all go on one agreement, but then how do you differentiate?  

    • Jack: Complicated because free gale through consortium – no associated license – but we need to track access / All free resources are on one agreement – everything else it is its own agreement e.g. the 18th century collection / and sometimes as the EBSCO KB breaks it down / In the description what it is e.g. database, ebook-package / recording the type of acquisition / Coral is using the acquisition type + material type + format for a renewal workflow

    • Jessica: Are you putting your invoices in?

    • Jack: not currently – not using orders yet – stored in internal drive – would like to attach to orders / when live on orders – than attaching the POL to the AGL 

    • Sara (chat): I have been putting inv # & date with $$ in AGL lines for one-time purchases that were long and won't be migrated

    • Sara: proving to the vendor – that we paid – so in a future project scan physical files and attach them

    • Kristin: for the example that all our hosting fee paid though consortium – one agreement per database or all on one – can each Agreement line be attached to the same one POL for the access fee payment?

    • Owen: Same POL on multiple AGL – repeat the link to every single one/ One agreement line per collection you can attach the right order line with agreement line / Caution with reporting not to double count

    • Sara: have you tried in the agreement to differentiate – access fee, subscriptions, hosting fee?

    • Jessica: one of the supp. properties e.g. hosting fee or access fee / Access fee are automatically renewed 

    • Kristin: Proquest – content fee and access fee – do have to split them apart for reporting as different cost type – one is collection cost and the other is not, access fee is not a capital expense

    • Owen: paying the hosting fee – nature of payment what the invoice is for or PO is for – not on the agreement – no way of describing that

  • Example 6: EBSCO databases & packages of databases

    • Several databases in EDS package – each PO and one license agreement / Other databases through consortium or directly from EBSCO 

    • Jack: single Agreement

    • Sara: each one agreement with one agreement line

    • Owen (chat): And here lies the strength (and weakness?) of providing the flexibility :) But on the whole I think a strength

    • Felix (chat): It depends: Some of our databases are managed in the same agreement, but for ProQuest OneBusiness and ProQuest Ulrichsweb we had to create 2 agreements, because the start dates vary and we have different licenses.

Chat

Von Felix Hemme (ZBW) an alle:  02:07 PM
What Jira issue is related to the independent title loading?
Von Owen Stephens an alle:  02:13 PM
So we have the answer in the chat: ERM-1801
Everything here for me points to it being OK to have these as a single agreement for all of these with an agreement line for each title. The breakdown Sara describes as being appropriate as well - but increases the number of agreements - so it might depend on how much variety there is across these different resource types in terms of how they are managed, your contacts, etc. etc.
Von Felix Hemme (ZBW) an alle:  02:18 PM
There's also an eUsage - Agreements integration
Von Jack Mulvaney an alle:  02:18 PM
We currently have three supp. properties configured in our tenant - Resource URL, Simultaneous Users, and Authentication Method. The first two are just open text fields so we can enter the appropriate URL or number/text and the third is a picklist we defined to have what we considered all the relevant auth. methods.
Von Abby Wickes (she/her/hers) an alle:  02:20 PM
I like the idea of capturing authentication methods
Von Jack Mulvaney an alle:  02:21 PM
We were actually capturing it in two places in CORAL - on the resource record access tab and as a term on the license. Licenses can sometimes grant you more than one option - some are open and some don
Von Peter McCracken an alle:  02:21 PM
+1 Abby; I think that’d be really valuable.
Von Jack Mulvaney an alle:  02:21 PM
't mention it at all
Von Felix Hemme (ZBW) an alle:  02:21 PM
We have a supp. property to record what resource type(s) are managed in the agreement. Feedback from staff is quite good till now
Von Abby Wickes (she/her/hers) an alle:  02:21 PM
Gradually
Von Kristin Martin an alle:  02:23 PM
When will Agreement Lines be searchable?
Von Jessica Harris (she/her) an alle:  02:27 PM
We're thinking of using supp. properties for Read & Publish (and other OA agreements), multi-year agreements, fund codes, and hosting fees (depending on how we end up setting up our agreements)
Von Jack Mulvaney an alle:  02:29 PM
That's why I'm erring on the side of 1 agreement per resource (with appropriate agreement line based on how the EKB represents that resource)
Where I have brought together multiple resources it's more like these reference/encyclopedia titles but I don't actually know if it's beneficial yet to have them grouped up because we weren't tracking them as close as say - a popular database or big journal package
Von Sara Colglazier (MHC/5C) an alle:  02:30 PM
And only if the resource is in eHoldings
Von Felix Hemme (ZBW) an alle:  02:34 PM
<Sorting> is cumbersome in other areas as well and there was discussion about it last summer.
Von Owen Stephens an alle:  02:36 PM
I have to admit one agreement per resource makes me sad as it suggests we’ve got something fundamentally wrong :( (this is not a criticism of your approach, just me reflecting that there are some issues)
I did some analysis of these Gale resources for another project several years ago and they are a nightmare - for one of them I found Gale had about 5 different names for the same resource and three different lists of their 
Von Sara Colglazier (MHC/5C) an alle:  02:39 PM
I plan to with Supp doc ... and I may have one already
As in retro from files
Von Abby Wickes (she/her/hers) an alle:  02:39 PM
that sounds about right for Gale :)
Von Owen Stephens an alle:  02:39 PM
:)
OK - I’ll try not to feel too sad ;)
Von Sara Colglazier (MHC/5C) an alle:  02:42 PM
I have been putting inv # & date with $$ in AGL lines for one-time purchases that were long and won't be migrated
Von Owen Stephens an alle:  02:53 PM
I think I’d be looking at that information to go on the POL or the Invoice Line probably
Is that like Postage & Packing on a physical purchase?
And here lies the strength (and weakness?) of providing the flexibility :) But on the whole I think a strength
Von Felix Hemme (ZBW) an alle:  03:00 PM
It depends: Some of our databases are managed in the same agreement, but for ProQuest OneBusiness and ProQuest Ulrichsweb we had to create 2 agreements, because the start dates vary and we have different licenses.
Von Sara Colglazier (MHC/5C) an alle:  03:01 PM
Also because in many cases I am not linking them up to HLM
Von Owen Stephens an alle:  03:02 PM
Really great discussion

Attendees list