2024-03-20 Meeting notes: Agreements + Inventory interaction + WOLFcon

Date

20 Mar 2024 

Meeting will be an hour earlier for Europeans due to time changes.

Housekeeping

• Convener and notes: Martina Schildt 
• Next meeting: 24 Mar 2024 

Discussion items

1. AGR and INV interactions
2. WOLFcon session ideas
3. Meeting frequency

Minutes

BELA Update (Amanda Ros):

UAT testing for Quesnalia is going on.

Functionality planned for Quesnelia and delayed until Ramsons:

• ISBN and ISSN identifiers support for triggering bulk edit will be addressed in Ramsons.

  • Delayed to do issues with finding duplicates and normalization

    • Preventing changes to records that were not intended to be changed

• Building query based statistical codes.

  • Needs more conversation around what kinds of operators needed before implantation

AGR and INV interactions 

Questions to be answered

1. App A provides a link to the “details” pane of a record owned by App B
2. App A provides a link to the “edit” pane for a record owned App B
3. App A provides a link to the “find-records” pane in App B
4. App A displays a modal with the details for a record that is owned by App B
5. App A displays links to records in Apps B, C, D (i.e. ui-dashboard becomes universal to any record type).
6. App A provides a link to create a record in App B

• users would like to link to individual records as well as to a list of search results
• There may be issues when syntax changes
• seems to be point 5 in the below list
• stripes registry allows to say: the way we display results maps to a certain URL
• UI-user knows how to show a specific record
• Sara in chat: Owen, you are overthinking it. And it does not matter. Then I redo my search and link. It is mine to control in this case.
• Martina in chat: Agree, you could redo the search
• Owen in chat: I see Sara’s comment and do understand that you could correct broken links (although it’s hard to know from where we stand right now how much work that might end up being). But actually the question of adding a URL field or supplementary doc to an AGL is really an ERM topic - we don’t need to discuss that here.
• Laura in chat: I hope we can avoid creating additional inter-app dependencies that break when a record in one app is moved or changed
• We do want to check options - if we just add a field to add any URLs than we may regret later on
• but we should have in mind not to create additional dependencies
• Laura in chat: I don't like the way, for example, orders links to Inventory records and in doing so copies some data elements--I understand why this seemed desirable, but it makes the whole thing fragile and complicated
• Charlotte and Martina agree
• more specific than just storing a URL and slightly less specific than storing a URL from a specific app
• maybe differentiate between: store URL or store FOLIO URL
• Laura agrees in chat: I very much like the idea of seeking a middle way (and it sounds sort of Buddhist)
• store value and type render the e.g. name
• or just store the value and render it as a link
• Dung-Lan in chat: URLs can be added freely and as needed in Organizations - mostly for information and for convenience in my mind if we enter such info.
• think about this in a more standardized way
  • this is the UUID
  • this is the type its for in this application
• Zak: that was what I meant with the registry
• "last updated" information has a link to the user
• requests has a UI dependancy on Users and UI-inventory app - apps are coupled already - so far this works fine
• let Dashboard get data from any app and get out to any app
• Owen in chat: I’m onboard with the registry 🙂
• Sara: our minimal requirement (just having the URL on the AGL) gives a lot of options
  • user can link to a list of things instead of only linking to one recrod at once
  • users can link do discovery layer directly
    • currently sometimes users need to load data into Inventory to get the link to the data that is in Discovery
• Owen in chat: That’s completely do-able. I don’t see it as an app-interaction issue
  • would need a week's time of development > is an ERM discussion
• maybe we can have a single standard way of validating URLs
• Charlotte in chat: Just wondering Owen if e.g. this URL would be validated as well-formed in the Agreement URL validator: https://folio-snapshot.dev.folio.org/inventory/view/f31a36de-fcf8-44f9-87ef-a55d06ad21ae?filters=staffSuppress.false&qindex=title&query=girl&sort=title
• Owen in chat: Yes it will validate it https://folio-snapshot.dev.folio.org/erm/agreements/c21d1cdd-fe3d-4842-9496-ae3fbf444c8a?filters=agreementStatus.active%2CagreementStatus.draft%2CagreementStatus.in_negotiation%2CagreementStatus.requested&page=1&sort=name
• Laura: Sara, are the searches you want to link to based on some sort of "hook" in the underlying source MARC data?
• Kristin: yes, that was how I was thinking about it
• Sara in chat: Yes, Laura, that is what I do. We have hooks in our metadata for our e-records. … And like Kristin.
• Kristin in chat: We're sort of mis-using a general URL field to create a cross-app link because it's easy.
  • Owen in chat: I think I’d say it’s not just easy, but it’s very generalised solution. It works for many many use cases. It wouldn’t be very much more complicated to allow an inventory lookup and store and link an Inventory UUID - but obviously it would only solve that single use case
• we need to keep in mind: when migrating to another system, the links created by entering URLs will no longer work
• Owen in chat: Out of interest … is there any maximum length of a URL supported Folio? I’m not sure this makes sense as a question 🙂. What happens if the title you want to search for is very very long.
• Kirstin in chat: Hope not. I remember running into a 255 character limit in OLE and being unable to store Gale links until that was expanded.
• Zak in chat: 4096 I think (backend APIs)
• Charlotte in chat: See: UIIN-2673 [RRT] 414 URI Too Long
• Owen in chat: The link validator we use in Agreements supplementary documents (and a few other places) will reject anything over 2083
• seems to be a related conversation
• Progressing the registry would mean we need an RFC to TC > Zak: no, maybe not
• We need an understanding of the use cases
• Zak - questions that need answering
  • what are the circumstances when we are creating a typed link -
  • where does this functionality need to exist
  • does one app own the link?

From last meeting

Minimal requirements

• ability to display link in all records | generic link field that simply points to another record 
  • in Agreements users would like to have this as a first step for AGLs
  • ability to add multiple links to one AGL
  • a URL (might be list of records or concrete titles) > to get a list of records you currently need to add codes to Inventory records (as pre-work)
    • in contrast to the record UUID that would always link to a specific record
  • similar to what is already available in supplementary documents in agreements
  • using URLs seems more flexible 
  • adding URLs as well as linking to UUIDs will provide one way linkage
  • URLs are searches
  • URL would also give flexibility to link to other things

Maximal requirements

• Changing a link on one side should update it in the other app automatically

Level at which linkage needs to take place

• Inventory side: Instance versus Holdings
• Agreements: resource in a KB exposed by Agreements versus AGL level (resource or package of resources)
• example: this AGL covers this Inventory resource
• linkage from both sides needed

WOLFcon sessions

Meeting frequency

• less frequent meetings 
• keep alternating meetings
• Martina will propose a new meeting frequency that can be discussed on

Next steps

Chat

Attendees

Action items