2022-10-18 Discovery Integration Subgroup Meeting notes

General approach: we want general solutions to discovery integrations, we expect to draw from our specific experiences with our own discovery interfaces and define changes to FOLIO edge APIs that will support needs.

We need to talk about FOLIO here, not about a particular discovery system. After that, we need to talk about implementation.

Sequence: we plan to go through the APIs in sequence and evaluate current state and needed changes to each. 

• Who has already used these modules ? If not, why have they not been used ?
• APIs seem like they go in the right direction, but do not go far enough to be useful.

See also Related resources.

Refinement: take each API, define what we think the requirements are, then define solutions

Include course-reservation edge api.

Patron API

• Using an API key is like a super user, if you have the key the API can access all patrons. Need a way for users to opt in to granting permission to accessing their data. Do we want an OAuth workflow? Something else?

Uwe: mod-patron is to general. At Hebis, there are restricted service points depending on the item; there are special reading rooms for example. You can not order every item to every service desk. The availability API should deliver also the allowed service points.
Need to have the possibility to ask what are the allowed service points for an item.
Uwe: Missing the opportunity to integrate a single sign on system via OAuth. Can't use the FOLIO system in the discovery system.
  We have to use the institutional identity provider. Need to access with the account of the patron to the FOLIO system.
   The library system could have supervisory rights. But the right way is an OAuth which will ask: 
   Do you allow to access in this way in your library system ?
   Problem: Sometimes the libraries have more users than the institution has.

 Tod: Do you want the APIs to be accessed with the patron identity. Or do you want to use a service user that will
    act on behalf of the patron ?
   Uwe: At the moment we have this service user. They need an API key. For me this is like doing something but not knowing enough about how to do this.
      Blacklight or some other systems need to know this API key. At the moment it is always the same API key.
      Then, the Discovery system can access all patrons. But with OAuth, you have an additional step. You can ask
      OAuth: "Will you allow this now for this user ?". The granted right is then only for this user.
      The Discovery system will access the data only for the granted users. Each of them have their own token in the API or the discovery system.
     This is some kind of data security.
     I would like the superuser to live in the discovery system, I would like to have it in the API. But it is not a show stopper.

Demian: The edge-api adds a third abstraction layer in the middle.

Next week:

Patron APIs:

• Review the APIs, use brainstorming pages, write out requirements
• Uwe could talk about mod-patron.
• Demian Katz and Stewart Engart could talk about oai-pmh.
• Magda is the PO of oai-pmh; maybe want to invite her also.

Tod: Maybe start with edge-patron. Then the question would be: What do we need from edge-patron.
   What are the functions that edge-patron needs to do ? order, do placeholds, ....  First define the requirements-
 Nicole: Let's flesh out the brainstorming documents.
 Uwe: Look at the brainstorm page for patron empowerment. We should have a request sheet for edge-patron.