Brainstorm page for the title update interface
- Uwe Reh
- Cory Lown
Owned by Uwe Reh
What's needed to fill/update the search index of an discovery system.
This intended as a unstructured collection of needs, wishes, use cases, etc.
Please add any thoughts. Don't care about duplicates or potential already supported functions.
In the upcoming discussion it's much easier to drop a point than to find a missing one.
| Title / Key | Who (optional) | Description | Rank | Tickets, facts and comments by the investigators |
|---|---|---|---|---|
| Data format marc | Uwe Reh | Since VuFind and most other discovery systems, are well prepared to handle marc, this format should be the default. | ||
| Deletions | (Perhaps it is standard feature of OAI) The interface should deliver deleted and blocked titles/items as:
| |||
| Invisible data | Sometimes a title or an item needs to be visual for the staff but not to the patrons. This data should be ignored by the interface. | |||
| Item information | OAI server currently injects special 9xx fields into the MARC records containing things like suppression status, item details, etc. I would suggest that, if that standard meets our needs, we should try to use it consistently to reduce confusion/configuration. Copied from slack by Uwe Reh. | |||
| Detecting changed records | Cory Lown | Indexing needs to take account of changes made by librarians as soon as possible, but these changes can occur on any level in the FOLIO hierarchy. Instances, Source Records, Items, and Holdings can all be independently marked “suppressFromDiscovery”. Need a way to detect changes via API at all these levels. | ||
| Complete record for indexing | Cory Lown | A complete record for indexing needs to know things like its catalog date (from the instance), bibliographic data (from the source record), ILL policy (from the holdings), and damaged status (from the items). We also need course reserve information at index time. | ||
| Display names | Cory Lown | Discovery requires human readable names for things, not UUIDs. We would prefer not to have to make additional API calls to get the names of Location Types, Holdings Note Types, Item Status Types, etc | ||