Internal link properties
Contents
On the Internal link properties tab, which is present when you have selected a new or existing internal link in a database definition, you set up this internal link between two or more existing data dictionary fields.
Click here for information on how to edit properties in general. And click here to read about how to manage objects in the tree view in the Application browser. On the current tab you'll find the following settings:
Enter or select the term tag or field name of the normal field on which you want to base this internal link. Base each internal link in a database on the field in which a keyword is defined in each record in that database. Typically, in the thesau file this is te (term), and BA (name) in people.
Choose the type of link you want to make. There are five possible types. For any type you have to fill in the appropriate tags in the accompanying Relation tags on this tab (each type of course has different associated Relation tags):
| 1. | Hierarchical (type 1) - broader and narrower: for this type, in the Broader field and Narrower field options, enter existing tags or field names from the current database definition, in which broader and respectively narrower terms are saved. |
| 2. | Related (type 2): for this type, in the Related field option, enter an existing tag or field name from the current database definition, in which related terms are entered. |
| 3. | Equivalent (type 3): for this type, in the Equivalent field option, enter an existing tag or field name from the current database definition, in which equivalent terms are entered. |
| 4. | Preferred (type 4), and non-preferred: for this type, in the Use field and Used-for field options, enter existing tags or field names from the current database definition, in which preferred and respectively non-preferred terms are saved. |
| 5. | Semantic factoring (type 5): for this type, in the Semantic factor field and Semantic factor-for field options, enter existing tags or field names from the current database definition, in which semantic factors and respectively concept terms are saved. |
| 6. | Pseudonym (type 6): for this type, in the Pseudonym field and Pseudonym for field options, enter existing tags or field names from the current database definition, in which pseudonyms and respectively proper names are saved. Click here for information about how to set up Pseudonym internal links in model applications older than 4.5.2. |
With this option, Collections sorts the terms entered in different occurrences of the linked fields that make up this internal link definition, either Ascending (0-9, a-z), or Descending (z-a, 9-0) before saving a record in this database table. The linked fields mentioned here, are the Broader term field and the Narrower term field set in the options below. Choose Unsorted if you want to leave terms in these fields in the order in which you entered them or if the fields that make up this internal link definition are multilingual fields.
In the properties of any field you may also set an Occurrence sort order. This may result in conflicting sort instructions if you set both sort options differently for internally linked fields. But Collections simply first executes any sorting set in the internal link definition and after that, any sorting set in the field properties.
The type of sorting is determined by the index Key type setting: this is relevant for numerical and alphanumerical fields for example. Text indexes are sorted alphabetically. However, you still need to set the current Sort values option to either Ascending or Descending to make sure that the different occurrences of the linked fields that make up this internal link definition will actually be sorted that way when you save a record.
A related feature is that the sorting of records in the Hierarchy browser actively depends on the index Key type setting and the Sort values setting, independent of the actually stored sorting order of the relevant field occurrences in records.
Choose whether the automatic updating of internally linked fields after saving a record with such links must be done throughout the entire Database (table) which holds the specified tags on this tab, or only in the Dataset in which the user currently saves a record. More specifically, the current dataset is the dataset opened by the user explicitly before editing a record. This is relevant when a record is part of more than one dataset, which for example would be the case for a book which is part of both a super-dataset called fullcatalogue (encompassing the whole database) and a sub-dataset called book; a hierarchical dataset structure is also common in so-called enterprise edition applications.
If you allow the user to create new linked records from within an internally linked field, and you want the internally linked record to be saved in the same dataset as the current record, then make sure you set this option to Dataset. To make sure that internally linked records will be stored in the current dataset you should also set the Folder property of all linked fields which are part of the internal link setup in the current database to a single dot (instead of ../data) and the Database property below it should literally be set to =. The Dataset property of those linked fields should not be set: setting that property would mean that the linked record will always be stored in the set dataset instead of the actual current one.
In model applications 4.4 and newer, all database definitions have at least one dataset, the purpose of which is to have a link structure in place that is prepared for any upgrade to an enterprise edition application, should it ever come up: without going into too much detail, when links already include a dataset, instead of just the database name, it's easier to ensure a proper data migration to an enterprise model in which even the thesaurus can have multiple datasets.
In collect.inf the Database scope for the related term field is Database, because even though collect.inf has different datasets, it is allowed to link to objects from those other datasets while the user cannot create new linked records that way.
A practical example of this option is the following: suppose you have a library catalogue that is divided into books and serials datasets (amongst others), and you want to continue registering a magazine under a different name than before. You decide to implement this through a broader/narrower internal link in the catalogue database, where the new name will become the broader name of the old name. Because you want the changes you make to the name of the magazine only to have effect on records in the serials dataset, you set the Database scope for this internal link to Dataset.
Another example would be an enterprise edition of a Collections application. In such an application, different branches of an organisation all use the same centralized databases, but most or all of those databases are separated into branch-specific datasets, so that each branch always only handles data within its own dataset in the central database table. In this case, authority files like the Thesaurus and Persons and institutions may also have been separated into datasets and you might want to set the Database scope property to Dataset to make sure that internally linked records are all saved in the same dataset.
(On a side note, this would mean that a term could occur more than once in the database table, so then you cannot have a unique index on the relevant field.) On the other hand, if you want a record from a sub dataset to be able to link internally to other records within a larger super-dataset that encompasses the entire database, even though the new term is created within its own sub dataset, then set the Database scope option to Database or leave it at Undefined.
If you have a database table which has only one super-dataset, you can choose either Database scope, but to set it to Dataset is the safer option in preparation for a possible future addition of datasets, should those be required.
Allow duplicates
Non-functional option.
For hierarchically (internally) linked fields (like Part and Part of) and reversely linked fields (all must be in their own field group) which are displayed in a table grid and are used heavily (linking hundreds or thousands of records to a single record), you can implement so-called indexed link tables to improve load and display performance of such records significantly. Please see the General topics: indexed link table structure topic for more information.
This checkbox must be marked as part of the setup of the indexed link table.
Broader sort field/Order/Narrower sort field/Order
For hierarchically (internally) linked fields (like Part and Part of) which are displayed in a table grid and are used heavily (linking hundreds or thousands of records to a single record), you can implement so-called indexed link table structures to improve load and display performance of such records significantly. Please see the General topics: indexed link table structure topic for more information.
Of broader and narrower field occurrences, this table structure no longer saves the occurrence numbers in which data was originally entered, so the preferred sort order must be set here. So select a Broader sort field and a Narrower sort field from the drop-downs. You can only pick from indexed fields in the same relevant field group. Also set the sort Order for both. For example:
For the detailed presentation of records from hierarchically built database tables like an archive database table, the Thesaurus, or Persons and institutions, you can display the tree structure of all records that are linked internally to the currently displayed record through broader and narrower terms as well as related and/or equivalent terms, in the Hierarchy browser. (See the Collections Help for the user aspects of this functionality.)
By default, the tree view displays all narrower and broader terms of the current term and you can expand that hierarchy by displaying related and/or equivalent terms too. However, for some hierarchical database tables you want to be able to set which fields must be displayed in the tree structure. Because a document number in an archive for instance, is probably not very informative in such a structure.
In the current option, for an internal link definition of type 1 (broader and narrower), type 2 (related) or type 3 (equivalent), you can make this setting. This format string is constructed as follows:
%<tag><[occ]>%<fixed text>…
The part between percent characters is the data part: provide the tag that you want to display in the hierarchy. If you do not enter an occurrence number, by default the first occurrence will be used.
Behind the data part you may (optionally) provide a fixed text, e.g. explanatory, or to introduce the next data part, since you may repeat %<tag><[occ]>%, with or without <fixed text> in between. Examples of filled-in format strings are:
%te%; non-preferred term: %uf%
%te[2]%
You can also use field names. And both the data and text parts are optional. If you do not provide a Format string, by default the field will be displayed on which the internal link has been defined.
If you have a hierarchical database table with different record types, you can specify per hierarchical internal link definition which relations between the different record types are allowed. You can do this by interactively putting together the allowed hierarchy, here in the Relationship dependency rules box for the desired hierarchical internal link if you have already defined a Record type field for the current database: without the required Record type field the Record type drop-down list remains empty and useless. (You can specify different rules for other hierarchical internal link definitions, if you want, but it's never mandatory to specify rules since the hierarchical type of the internal link relation already implies standard rules.) Here's how to proceed:
| 1. | First make sure you have selected a Record type field on the Advanced properties tab of the current database definition. Once you have, the Record type drop-down list in the Relationship dependency rules box will actually contain all possible value types from the enumerative field. |
| 2. | The interface bit to build your relationship model is a bit unusual: just leave the Record type selection as it is (WORK in our example) when you build the model. You may click the Add node icon to insert a node in the box on the left. As long as you don't select any node in the model, newly added nodes will be added at root level, while once you select any node in the model, a newly added node will be inserted underneath the selected node (one hierarchical level down). Suppose you'd like to build the model that can be seen in the screenshot below, then proceed as follows after adding the first WORK node: select the top WORK node and click Add node; select the top WORK node again and click Add node; select the third WORK node and click Add node; select the fourth WORK node and click Add node. Now subsequently select the third node and set the Record type to MANIFESTATION, select the fourth node and make it an ITEM after which you select the last WORK node and change it to VARIANT.  If you make a mistake you can always delete a node by selecting it and clicking the Delete node icon (the red cross). If you select a node that has narrowers, deletion will delete that node plus its narrowers. |
In effect, the model hierarchy you specify here defines which direct parent and which direct children any record of the listed type is allowed to have. So a WORK record in our example can parent other WORK records and MANIFESTATION records, but not ITEM or VARIANT records, while it can be a child of another WORK record (e.g. if a WORK is part of a series of WORKs). A MANIFESTATION record can only be parented by a WORK record and can only have ITEM children. And so on. Note that the model in itself only demands that if you create a relation between two record types, it must comply to this model: it doesn't require you to actually create relations at all.
In Collections, after you've created hierarchical links in an edited record, the legality of the links will only be checked when you try to save the record: if a created link doesn't comply to the model, the record won't be saved and you'll receive an error message (RECORD_TYPE_NOT_ALLOWED = 378). The WebAPI doesn't perform this check yet.
Collections also takes your relationship rules into account when you are about to create child records in batch for a selected parent record from within the Hierarchy browser: you can only add children of the record type(s) allowed by your model hierarchy.
See also
The Collections Help (for information about hierarchical relations in the Thesaurus and Persons and institutions)