Feedback links
Contents
If you want to be able to make changes in authority records, like making a preferred term in the Thesaurus a non-preferred term, or like deleting a name in Persons and institutions, and automatically have all records in other databases that are linked to the concerning term or name, automatically updated, you need feedback links.
Feedback links are references in a database definition (often an authority database), to other databases that link to the authority database. The difference with reverse links is that feedback links can be used in databases that have no linked fields to other databases. Typically, in Collections applications this would apply to the Thesaurus and Persons and institutions (although any linked database, even with its own links, may be a candidate): catalogues and other primary databases have linked fields to these authority databases to validate the input of terms or names, but there are no fields in those authority databases that are linked to the catalogues, because usually you don't need to include data from catalogues in the authority records.
To ensure the integrity of all your (primary) databases, it would sometimes be nice if deletions or changes in term preference which you make in an authority (or other linked) record, would update all records in the (primary) databases that refer to this (authority) record, so that e.g. if you'd make a preferred term a non-preferred term, all catalogue records that would point to this term (through a forward reference) would be updated to point to the new preferred term (another authority record), and that if you'd delete an authority record, you would be warned that there are references in catalogue records to this authority record, or relations with other authority records, and that you are about to remove the record number or key of this authority record from their forward reference fields or internally linked fields. (Note that this type of updating functionality is not provided in reverse links.)
On deletion of an authority record, you will only get one warning that the key appears in a specific catalogue record, even if there are many catalogue records in which the reference appears. However, if you click Yes to remove the reference from the catalogue record, all catalogue records with the reference will actually be updated. If in catalogue records a reference to an authority record is stored in a linked field which is part of a data dictionary field group, and the field group is repeated, then when you remove the authority record, the reference in the catalogue record field group occurrence will be removed while the other fields in the same occurrence will remain unchanged; only if the other fields in the same occurrence were empty already, will the entire field group occurrence be removed.
However, in most existing Collections applications prior to model applications version 3.6, feedback links were not being used (with good reason, at the time), even though this may cause problems if you were to make certain modifications to authority records prematurely: for instance, with just forward references to authority files and no feedback links, the record numbers in these references are not deleted when you delete the linked authority record, which in effect corrupts your primary database. Therefore if you do not use feedback links, then in this case you should always first empty all linked fields in the primary databases that contain the authority term that you want to delete from the authority file, and only then delete the authority record itself. For making modifications in existing authority records, similar considerations apply.
The general advice before making changes to authority records is to first perform an appropriate search-and-replace action in all primary databases, and only then make the corresponding change in the authority record: this prevents your primary databases completely from getting corrupted in any way.
So if you need some automatic procedure to ensure the integrity of your data (because the order in which primary and authority records should be updated manually, and the completeness of such an update, is not always carefully observed), it may be a good idea to implement feedback links in your application, as far as those are not already present. In that case, the steps to take for a minimal implementation of feedback links are:
| 1. | Check that all linked fields to authority files, have link reference fields. For Axiell Collections-compatible applications this check has already been done for you. |
| 2. | If a linked field is part of a (repeatable) field group, the field group should have been (or must be) defined in the data dictionary. For Collections-compatible applications this is already the case. (In older applications, field groups have sometimes only been defined on a screen, but that is not enough to make the feedback functionality work properly.) |
| 3. | Create integer indexes for all those link reference fields (if they do not exist yet), and build them (reindex them), if that didn't happen automatically. For Collections-compatible applications this has already been done for you. (A missing index could result in an error 174 when deleting an authority record.) |
| 4. | For each authority database, in the Feedback databases list in the database setup, sum up the databases which have fields that link to this authority database. |
In Collections model applications version 3.6 and higher, feedback links are present for all linked fields by default, and not just for links to authority databases. This ensures maximum security against database corruption through deletion of linked-to terms or through changes in the preference of terms.
See also