BDF Parking lot
- Jenn Colt
- Monica Arnold
- Axel Dƶrrer
Owned by Jenn Colt
| Issue or question | Relevant links | Added by |
|---|---|---|
FromĀ Plan: No support for indicators in the MARC-to-Instance map. Not sure what this refers to, since we definitely support mapping based on indicators in the 5xx, 245, and 856 fields. (Response byMonica Arnold Indicators can be used in functions. But how do we use them if a function isn't already written? Do we have the ability to write our own functions? Is there a way to reference and use indicators directly from the map?) | ||
| From the Plan comments: Do not store SRS MARC when just being used as a transport mechanism. Support for this is already planned in UXPROD-2661, but not yet prioritized | ||
| From #metadata-management: Instance Resource Identifiers are not referenced by the UUID in rules.json. This causes problems if the reference term is edited. Theodor request a code to be added as for RDA terms. The wider implication of following that suggestion needs to be analysed together with tech leads, and MM-SIG. Also has implications for PO lines linked to Instances. The POL pulls some (but not all) of the instance identifier types into the POL bibliographic data. | ||
| Logging - users should be able to track the results of complex data flows accurately. For batch jobs, logs should be created. For work done through the UI, the results of changes should be clear to the user. For complex processes that cannot deliver immediate feedback, accurate eventual feedback should be available somewhere in the UI. The ability to accurately report on the results of data changes should be considered in the design phase. Connects to logging/audit theme from the roadmap group. | Jenn Colt | |
| How does this data flow interact with conflict resolution (optimistic locking, etc)? | ||
| Design should anticipate the need for other systems to interact with it. For instance, data import should allow the assignment of UUIDs to job profiles by outside systems, as most other FOLIO endpoints accept UUIDs at the point of creation. This aligns with PTF requests for automated testing and implementer needs for automating the copying of profiles between test and production systems. | Jenn Colt | |
| The need to perform all CRUD actions, including delete should be taken into account at design time. | Jenn Colt | |
| Should eletronic resource data within the internal knowledge base also be part of the considerations in this group? | ||
| Survey of long-running data import spikes? How do they prioritize against current work (ex. field protections) | ||
| Preventing MARC lock-in | Whole group | |
| Documentation for data import | Jenn Colt | |