Inventory Records Deletion
- Magda Zacharska
- Khalilah Gambrell
Work still in progress
Deleting MARC Bibliographic Records
Deleting via Inventory UI (Settings Instance as deleted)
When an Inventory instance with source =MARC is set as deleted in Inventory UI then:
Inventory instance record is set as suppressed from discovery and staff suppressed
Underlying SRS record deleted property is set to true and LDR05 is set to “d”
As a result, the record is included as deleted in all export types and harvested by OAI-PMH as deleted as well.
Deleting through API call
Deleting an Inventory instance with source =MARC directly through API from inventory-storage does not handle any dependencies but a copy of the record is stored in internal (not available to the users) table audit-instance. The underlying SRS record is not updated.
As a result, the record is excluded from all export types but is harvested by OAI-PMH as deleted.
Deleting instance with source = MARC directly through API from source-record-storage does not handle any dependencies, removes MARC record but leaves linked inventory instance without underlying SRS record.
As a result, the record is excluded from all export types and OAI-PMH harvests.
Deleting via quickMARC UI (Updating LDR05)
Editing an Inventory instance with source= MARC directly in quickMark by setting LDR05 to “d” does not reflect any changes in the linked Inventory instance record. However, because of the correct value of LDR05 the record is exported as deleted in all export types and it is also harvested by OAI-PMH as deleted.
Deleting FOLIO Instances
Deleting via UI (Settings Instance as deleted)
When an Inventory instance has source= FOLIO and it is set as deleted in Inventory UI then the record is set as suppressed from discovery and staff suppressed.
When the record is exported it will have a simplified record generated on the fly since there is not underlying SRS records for FOLIO instances. When harvested via OAI-PMH, the record is harvested with suppressed from discovery flag set to true.
Deleting through API call
Deleting FOLIO instances directly through API does not handle any dependencies but a copy of the record is stored in internal (not available to the users) table audit-instance. As a result, the record is excluded from all types of exports but based on the entry in the audit-instance table the record is harvested as deleted.
Deleting MARC Authority Records
Deleting via UI
<to be added>
As a result the record is included in export of deleted authority records. OAI-PMH - not applicable
Deleting vi API call
<to be added>
As a result, data export <to be added> . OAI-PMH - not applicable
Deleting MARC Holdings Records
Deleting via Inventory UI
Deleting MARC holdings in the UI handles some of the record dependencies and a copy of the record is stored in the internal (not available to the users) audit-holdings table. After deleting in the UI the Inventory app does not find the record and the inventory storage module does not store the record anymore. However, the linked MARC holdings that is stored in source storage record - reminds unchanged (no changes to LDR05) and is still linked to the non-existing inventory holdings record. The deleted property of the associated SRS record changes to “deleted”.
The record is not included in OAI-PMH harvest and any data export.
Deleting through API call
Deleting a holdings record with source =MARC directly through API from inventory-storage does not handle any dependencies but a copy of the record is stored in internal (not available to the users) table audit-holdings. The underlying SRS record is not updated and is left without linked inventory record
As a result, the record is excluded from all export types but is harvested by OAI-PMH as deleted.
Deleting a holdings record with source = MARC directly through API from source-record-storage does not handle any dependencies and removes MARC record but leaves linked inventory holdings record without underlying SRS record.
As a result, the record is excluded from all export types and OAI-PMH harvests.
Deleting via quickMARC UI (Updating LDR05)
Editing a holdings record with source= MARC directly in quickMark by setting LDR05 to “d” marks SRS record’s status as deleted but does not reflect any changes in the linked Inventory holdings record. or internal audit-holdings table. As a result, the record is exported as deleted but the change does not trigger OAI-PMH incremental harvest.
Deleting FOLIO Holdings
Deleting via UI
Deleting FOLIO holdings in the UI handles some of the record dependencies and a copy of the record is stored in the internal (not available to the users) audit-holdings table.
As a result, the record is excluded from all exports. However, an instance record associated with the holding will be included in an incremental harvest based on the entry in the audit-holdings table.
Deleting through API call
Deleting FOLIO holdings directly through API does not handle any dependencies but a copy of the record is stored in the internal (not available to the users) audit-holdings table.
As a result, the record is excluded from all exports. However, an instance record associated with the holding will be included in an incremental harvest based on the entry in the audit-holdings table.
Deleting Item Records
Deleting via UI
Deleting item record in the UI handles some of the record dependencies and a copy of the record is stored in the internal (not available to the users) audit-items table.
As a result, the record excluded from all exports. However, an instance record associated with the item will be included in an incremental harvest based on the entry in the audit-item table.
Deleting through API call
Deleting item record directly through API does not handle any dependencies but a copy of the record is stored in the internal (not available to the users) audit-items table.
As a result, the record excluded from all exports. However, an instance record associated with the item will be included in an incremental harvest based on the entry in the audit-item table.
Additional consideration
How Data export: export-all endpoint determines deleted records
MARC Instance is considered deleted when:
LDR05 is set to ‘d’ (treat MARC fields as a source of truth)
005 as base to determine when the record was deleted.
MARC holdings is considered deleted when:
LDR05 is set to ‘d’ (treats MARC fields as a source of truth)
005 as base to determine when the record was deleted.
FOLIO Instance is considered deleted when instance is set as staff suppressed and discovery suppressed
FOLIO holdings is considered deleted when holdings-audit table contains the UUID
How OAI-PM handles deleted records
MARC Instance is considered deleted when
instance-audit table contains the UUID , or
LDR05 is set to “d” and SRS record state is set to ACTUAL or DELETED, or
SRS record is set to “d”
MARC record is harvested as it is stored in SRS (no matter what is the value of LDR05. If SRS does not has corresponding MARC record then error is recorded in OAI-PMH error logs available to the user
MARC and FOLIO holdings is considered deleted when holdings-audit table contains the UUID.
Holdings data that is included in the harvest is populated based on the Inventory holdings record.
FOLIO items is considered deleted when item-audit table contains the UUID.
Item data that is included in the harvest is populated based on the Inventory item record
Audit tables maintenance scripts
Since FOLIO does not provide a robust way to track the deleted records the audit tables allow OAI-PMH to indicate if record was deleted so that it can be correctly indicated in the incremental harvests.
The audit tables are populated each time the record is deleted either through API or direct delete in the database (common during the initial data load) and can accumulate a lot of data over the years, significantly impacting performance of OAI-PMH. The hosting provides should run the maintenance scripts on the regular basis but with the full harvest coordination so that incremental harvests are not affected by prematurely deleted data.