assumed primary use case is for discovery services
building the harvesting service, not the OAI harvester (i.e. FOLIO is source of harvested data)
benefit: provides a standard that abstracts out ILS for retrieving data
Harvesting will happen on mod-marc-storage (as opposed to Inventory module); long term functionality (native data stores vs. inventory harvesting is TBD)
Harry is working as product owner, Craig McNally as tech lead
JIRA dashboard for the project is available; Harry will send link
questions/discussion
upper limit to number of harvesting sources (OHIOlink has 53)?
no software limit; might be performance/storage issue
initial harvest might be more resource-intensive, but subsequent update harvests will be less so
anybody relying on OAI-PMH for any consortial services?
none known (for ILS at least)
union catalog as patron-facing user interface vs. central repository of records that is exposed through a discovery interface
harvesting could be either directly to the discovery layer (i.e. patron-facing UI) or to a central repository of records, depending on the goals of the union catalog
bi-directional requirements for union catalog data flow
this project would enable one direction (local ILS to union catalog)
10min
Wrap-up/planning
All
follow up on single implementation model, more discussion about multi-tenant model (multi-tenant is very important to a lot of consortia; how do we move this forward?)