NOTE: All linked bib fields will have a $0 populated and will be read-only on the UI. The $0 will populate a URI that includes the linked Authority record 010 $a or 001 as a unique identifier. A MARC bib field's $0 will serve as a match point.
Jira Legacy | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Overall requirements for Nolana/Orchid (manual)
- Change Authority 1XX value will change all linked bib fields.
- Change 010 $a value will change all linked bib fields $0 values
- Updating linked bib fields WILL NOT be a part of the update Authority records DI job
- Will conduct performance/scalability tests to
- ensure no degradation of DI
- determine expected turnaround timeframe based on # of bib fields updated
- Will generate a report/log to inform users
- Status for processing linked bib field updates
- Any errors/failures
- Will allow for authority record deletion via UI. Formerly linked bib fields will retain all values... just uncontrolled.
- Will honor data field protection settings
Scenarios
# | Scenario | Manual Outcome Options (Nolana/Orchid development)
| Auto-link Outcome Options (Orchid/Poppy development) | Comments | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Create new MARC authority record via data import | No change. Nothing happens as far as linking. | JAC- Would like to be able to auto-link records based on the 010 matching a $0, but would prefer this to happen outside of the import process due to other potential processes happening at the same time. Would prefer that linking isn't tied to data import, including separate logs. JE: I feel that the linking is slightly different than the import. The 2 are related in that the import will launch the linking. I'd like to see a place to govern when, where, and what has been linked with errors and the ability to schedule linking jobs. | |||||||||||||
2 | Edit MARC authority (1XX field) records via data import
|
Phase 2 requirement options A. Job logs list similar to data import (UX) - https://bugfest-mg.int.aws.folio.org/data-import (username: folio / password: folio)
| I think this will depend on institutions and the number of authority records and how authority records are managed (loaded by vendor, other). I'd like to see options to set this and change it when necessary. I'd like to see something else perhaps even a separate utility for managing authorities that lists jobs, has scheduling, perhaps even reports on errors or even the ability to link to external authority services. | |||||||||||||
3 | Edit MARC authority (1XX field) records via quickMARC
|
Phase 2 requirement options A. Job logs list similar to data import (UX) - https://bugfest-mg.int.aws.folio.org/data-import (username: folio / password: folio) | Question 1 JC- Hard to determine without knowing the update mechanism. If this is a shadow DI job, performance and other concerns much higher, would want to do large sets overnight even more. JC - DI log style JE: The more I think about this, I'd like to see a utility or something where you can manage linking, perhaps integrations with external services, scheduling. | |||||||||||||
4 | Edit MARC authority (NOT 010 $a or 1XX field) field via quickMARC
| No impact to any bib records linked to the authority record
| Same as manual | |||||||||||||
5 | Edit MARC authority (NOT 010 $a or 1XX field) records via data import
| No impact to any bib records linked to the authority record
| Same as manual | |||||||||||||
6 | Edit MARC authority (010 $a field) record via data import (rare use case)
| Update 010 $a value and update all linked bib fields' $0 Phase 2 requirement options A. Job logs list similar to data import (UX) - https://bugfest-mg.int.aws.folio.org/data-import (username: folio / password: folio) | RW- This one I would want to talk out possibilities more. Especially when dealing with formerly undifferentiated names. JC–if the 1xx field changes, then I would want B, but if the 010 changes then the records would need further examination–usually this doesn't happen unless a record is being deleted, and that typically requires human intervention due to the complexity of undifferentitated names. I would prefer a report of these types of string matches based on the 1xx. JE: I think institutions will have different needs. A utility tool that has options would be great. | |||||||||||||
7 | Edit MARC authority (010 $a field) record via quickMARC (rare use case)
| " " | Question 1 LED-I cannot think of a use case for making local changes to the 010. But if we did change the 010 the bibs should no longer be linked. Question 2 RW- I'm not sure which method I want, but I would want a push notification of some type because chances are that I forgot this running a couple of minutes after it started | |||||||||||||
8 | Delete MARC authority record via quickMARC
| Allow for deletion to proceed. Ask user to confirm that they want to delete the authority record. Ensure they understand impact of unlinking these records by providing # of records to be unlinked. Linked bib fields are no longer linked. Retain [$a Twain, Mark, $d 1835-1910 $0 <<URI>>] only change is user can now edit these values because no longer controlled. |