Status management of authority records
Contents
Terms and names forced from within a catalogue into an authority database like the Thesaurus or Persons and institutions by clicking the Create entry button in the Find data for the field window, are assigned the "candidate" status if in the relevant linked database a field has been set up for the status. In that case, a Show candidate terms slider will appear in the Find data for the field window. Only when you switch it on, forced terms or names will be shown in the displayed list of found keys too. When switched off, the list of keys only shows all non-candidate terms or names: these are terms or names which have been created as new records from within the Thesaurus or Persons and institutions, or as a new record from within a zoom screen to the Thesaurus or Persons and institutions via the Create and edit entry button. Of course, terms or names which have been forced into the linked database, having initially received the candidate status, can always be assigned a different status by editing the relevant term/name record.
To be able to really do something with this functionality, application and database adjustments are necessary in older model applications: by default, no data dictionary field has been set up in the model applications up to and including 3.5, to store this status in; however, in newer model applications, status management is implemented fully (apart from the "group" status* maybe, which was introduced in 5.0). You can also adjust your own application yourself if you have Axiell Designer. Then proceed as follows:
| 1. | You may create a status field in any linked database. However, you should only do this in databases in which you would like to set and maintain the status of entered terms, for instance because spelling rules have to be checked or guidelines for thesaurus terms have to be observed. The Thesaurus and Persons and institutions come to mind first, but the principle is valid for any database. Open the Application browser in Axiell Designer and create in e.g. the Thesaurus (the THESAU file) a new enumerative field with the name term.status and the tag ts (if that name and tag do not exist yet, that is). On the Enumeration values properties tab, you must specify the following static list: |
Value |
Language text (English) |
0 |
undefined |
1 |
approved preferred term |
2 |
approved non preferred term |
3 |
candidate |
4 |
obsolete |
5 |
rejected |
6 |
group |
Note that the status of a term can have one of seven different values. Value 6 for "group" is optional*. Terms forced into the Thesaurus from within another database, automatically receive the value 3 "candidate".
For every language on the Default values tab you can, if you wish, enter the number of the value which you would like to see filled in in the status field by default when you create a new record in the Thesaurus (directly as well as by forcing the record): if you mainly enter approved preferred terms for example, then 1 would be appropriate, but if you equally often enter candidate terms, approved preferred terms and approved non-preferred terms then 0 would probably be the best default value. Let's look at the different values for a moment: 0 means that no status has been assigned yet, 1 must be assigned to approved preferred terms, 2 to approved non-preferred terms, 3 to candidate terms - forced terms (without default value) are candidate terms automatically, 4 to obsolete terms which shouldn't be used any more, and 5 to rejected terms. The advantage of assigning status 5 instead of removing a rejected term altogether is that the information about rejecting the term is saved: no-one will ever attempt to enter an earlier rejected term as a preferred term again, simply because it is still present in the database as a rejected term. 6 is a special status: see the insert below for more information. Further note that terms and names with the obsolete or rejected status won’t be displayed in the Find data for the field window for linked fields. That way the user won’t accidentally pick a term here which shouldn’t be used any more. The user will get an appropriate warning if he or she tries to enter such a term.
| 2. | In the properties of the relevant authority database (in our example the Thesaurus) on the Advanced tab, you'll find the Thesaurus term status field option. Enter here the name or tag of your new status field, and save the changes in this database. |
| 3. | Now you must place the field on a screen for the authority database. For the Thesaurus you can do this on thes.fmt (Thesaurus term), below Term code for instance - this screen may have a different name in your application though. The new screen field must be of data type Text, Not repeatable, and have Read and write access rights. Remember to save your changes in the screen file. |
You are done as far as the Thesaurus is concerned. In the running application you can now assign a status to every term in this database. Everywhere in other databases where a field links to the Thesaurus you may include candidate terms in the list of found keys in the Find data for the field window, or leave them out. And when you force terms into the Thesaurus, they automatically receive the candidate status (unless a different default value has been set for the status field).
* The “group” term status (neutral value 6) |
||||||||||
The group status is intended for terms which are useful or important in your thesaurus management to distinguish term collections and which themselves can be part of the term hierarchy but are not allowed to be used as a term in catalogue records. An example might illustrate this concept. Suppose that in your thesaurus you’d like to construct a term hierarchy of body armour: armour armour (by construction) mail armour plate armour scale armour armour (by form) cuirass gambeson gauntlet helmet leg guard shoulder plate armour (by function) battle armour horse armour parade armour Although the terms armour (by construction), armour (by form) and armour (by function) come in handy here in the term hierarchy, you would probably not want anyone to link to such a term from within the catalogue (contrary to the other terms). Precisely for this purpose you could assign the group status to the mentioned three terms in this example. Terms which have been assigned the group status, adhere to the following specific rules:
|
Setting access rights for showing candidate terms
The Show candidate terms slider in the Find data for the field window for linked fields in catalogue records can be hidden from certain user groups via access rights, if you don’t want everyone to be able to view and/or link candidate terms. Set those access rights in the Access to view candidate terms in link window list on the Advanced tab of the relevant authority database (the Thesaurus or Persons and institutions). For all fields linked to this authority database from within some other database, the slider will then be hidden from users with a role which has been assigned the access rights No. By default (without having set any access rights), users do have access to candidate terms.
Notes
| • | Disabling (via limiting access rights for enumerative value 3) value 3 (candidate) in the status field enumeration list does not disable/hide the Show candidate terms slider for fields linking to the database that contains the status field. |
| • | Removing value 3 (candidate) from the status field enumeration list does not disable/hide the Show candidate terms slider for fields linking to the database that contains the status field. |