Catalogers want the ability to link a MARC bib field(s) to MARC authority heading(s)/reference(s) because authority records are seen as the source of truth about a person/place/corporation/conference/subject/genre. This linking allows the library user to learn more and feel 100% confident that the information provided is accurate and allows them to search/browse for their research.
Phase 1 will focus on handling Personal/Corporate/Meeting names. Additional spikes will be created for the technical design for handling Subjects (i.e. Topical terms, Genre/form) and Titles (series/uniform titles)
d.) Delete the MARC bib tag via the quickMARC bib record
|Description||Controlled MARC bib tag||MARC bib indicator code 1||MARC bib indicator code 2||MARC bib subfield codes - minimum||Controlling to MARC authority tag||Controlling MARC authority subfield codes - minimum|
|Personal name||100||/||/||a||100||a (whatever subfields are present will populate MARC bib 100 and control it.)|
|Subject Added Entry - Personal name||600||/||/||a||100||a (whatever subfields are present will populate MARC bib 100 and control it.)|
|Added Entry - Personal name||700||/||/||a||100||a (whatever subfields are present will populate MARC bib 100 and control it.)|
|Corporate name||110||/||/||a||110||a (whatever subfields are present will populate MARC bib 110 and control it.)|
|Subject Added Entry - Corporate name||610||/||/||a||110||a (whatever subfields are present will populate MARC bib 100 and control it.)|
|Added Entry - Corporate name||710||/||/||a||110||a (whatever subfields are present will populate MARC bib 100 and control it.)|
|Meeting name||111||/||/||a||111||a (whatever subfields are present will populate MARC bib 111 and control it.)|
|Subject Added Entry - Meeting name||611||/||/||a||111||a (whatever subfields are present will populate MARC bib 111 and control it.)|
|Added Entry - Meeting name||711||/||/||a||111||a (whatever subfields are present will populate MARC bib 111 and control it.)|
The instances/bibs could be updated during some time (up to 10 minutes for popular authority) after authority is updated.
The main implementation of the functionality should be done in the new module called "mod-entities-links". Also it should be done in SRS, mod-inventory-storage, mod-search and on UI of quick marc.
The new module should be created for handling links between Instances fields and authorities. The module should contain the following database (postgres) table ("linking_table").
|id||authority_id (btree index)||instance_id (btree index)||bib_record_tag||bib_record_field_id||linked_sub_fields|
|Integer, auto_increment||The same authority id for Inventory and SRS||Instance Id, which SRS currently knows|
the number(e.g. 100 or 700)
The value of the id field (e.g. $0).
|The characters (numbers or alphabetic) of existing fields of authority records, that will control the subfields of linked bibs.|
For the bib_record_field_id column, the $0 sub-field should contain the value which is generated based on Managing Authority source files.
Mod-entities-links listens for inventory.authority domain events Kafka topic. If the message is received the there is such authority in link table then the record in the following table ("job_table") is created:
|Integer, auto_increment||json field, that contains the authority data from Kafka_message||number of processed records||is completed flag||id latest of the row in the links table for the current batch|
Then mod-entities-links iterates over all records in links table that has the authoriy_id as in Kafka message by batches of 500 records (of "linking_table") and after every batch is processed update the next_record_id field with the latest id in the batch and increment value (by the number in batch) of the processed_count. And the next batch takes the records from linking table, that has id > job_table.next_record_id. NextRecordId is also saved in memory.
Saving in database is done for ensuring the consistency in case if module fails during the processing of batch. On @PostConstract of the module it should read the job_table and if there is job with completed equals to "false" it should start processing of this job starting from next_record_id. It could cause double processing of the job if another instance is up during the job processing, but it is not a problem, as the process is idempotent.
For every row in a batch mod-entities-links should:
Consequent modification of the same record (nice to have)
Before start of the job_processing mod_links should check if the job for such authority already in progress and if it is so, it should stop such process and make this job completed.
The method that is used for propagation of mod-inventory id to SRS (via Kafka messaging) should be adjusted in order to support updating of any field of the record, so that it should support updates from mod-entities-links.
If $9 is populated in the MARC record that is being imported and there is existing MARC record in SRS that will be updated, the source-record-storage should request mod-entities-links to get the fields that should be updated (linked_sub_fields) and authority_id. All subfields of fields except the linked fields should be retained. Mark protection rules should be ignored for it.
Mapping profile should be adjusted to take the value from the $9 field and set it to the subfield "authority_id" in "contributors" field. For the update, the authority_id should be requested from mod-entities-links by instance_id and bib_record_field_id.
The sub-field "authority_id" should be added to the "contributors" field in mod-inventory-storage. This sub-field should contain the value of the $9 sub-field of MAR bib field.
Existing functionality: When the changes to authority happens in inventory the Kafka domain event message is sent accordingly and it triggers changes in mod-search and mod-entities-links.
The "authority_id" subfield should be added to the "contributors" field. It should be keyword field.
For the contributors browsing the contributors index should changed, so that if contributors with the same names has different authority_id, it should be different records in the index. The mark near the record in the UI table should be shown based on the "authority_id". If the filtering for having link to authority should be performed, the ES query should be changed to have "authority_id" in EXISTS clause.