...
- Rename mod-entities-links to mod-authority-manager.
- Fully move Authority API, Authority Note Types API, and Authority Source Files API from mod-entitiesinventory-links storage to mod-authority-manager. This API provides just CRUD operations and does not have any business logic.
- Move authority reindex API.
- Adjust mod-authority-manager to use an internal database instead of interacting with mod-inventory-storage and mod-search.
- Disable the above APIs in mod-inventory-storage and remove APIs implementation and enable it in mod-authority-manager. The dependent UI and BE modules will not experience any differences.
- Create a migration script for existing authorities.
...
| Area | Question | Answer |
|---|---|---|
| Duplicate Identifier | Do we want to implement authority validations that prevent saving an authority record if a similar authority already exists in the system, based on either the identifier (naturalId or 001/010a) or the heading? | KG - Not for this initial implementation. There is some logic we need to support for LOC related to 010 always having 12 characters. Also based on looking at some of the National Library of Poland authority records, we might have a situation where the 001/010a is the same as LOC. We need to more authority file analysis before implementation. cc: Marcin Mystkowski and Jacek Gajkiewicz please share your comments on this question. |
| Multiple Headings and Types | Do we want to enforce a validation rule that restricts saving an authority record if it contains multiple headings of the same type (e.g., several personal names) or multiple types (e.g., a combination of personal name and geographic title)? | KG: Yes. We need a rule that the authority record can only have one 1XX. I thought this rule was already in place. Or did I misunderstand the question? NOTE - We will support more than the 1XX values we support today. I have received feedback that some customers have authority records whereby 1XX is not on the list outlined in MARC authority documentation: 100, 110, 111, 130, 147, 148, 150, 151, 155, 162, 180, 181, 182, and 185 (https://www.loc.gov/marc/authority/ad1xx3xx.html). cc: Marcin Mystkowski and Jacek Gajkiewicz please share your comments on this question. |
| Tracing Field Consistency | Do we want to implement a validation that ensures the "see from" and "see also from" tracing fields accurately reflect the heading? For example, if the heading is a personal name, should the tracing field be a meeting name? | KG: So the question is the following, should we apply a validation rule that if the heading is 100 that the 4XX must be 400 and the 5XX must be 500? No. See examples https://lccn.loc.gov/no2007000953 https://lccn.loc.gov/no2019024399 NOTE - When we allow for creating a local authority via UI or support creating local authority records via DI then we should consider tenant level MARC validation rules related to this question. cc: Marcin Mystkowski and Jacek Gajkiewicz please share your comments on this question. |
| Duplicate Headings | Do we want to prevent saving an authority record if a similar heading with the same heading type already exists in the system? | KG: Pavlo Smahin - can you provide an example? |
| Duplicate Tracing Fields | Do we want to address duplicates in search results by cleaning up duplicate tracing fields? For instance, if multiple 400 fields with the same values exist in a MARC record, should the search results remove the duplicates? | KG: No. The example seems very edge case. I cannot imagine this will happen very often. We can always support as a tenant level MARC validation rules check. cc: Marcin Mystkowski and Jacek Gajkiewicz please share your comments on this question. |