Database setup: internally linked fields

<< Click here to display Table of Contents >> Navigation: Axiell Designer > Database setup:

Internally linked fields

Contents

Internal links define hierarchical, preferred or otherwise related relations between terms in one and the same database, usually an authority database like the Thesaurus or Persons and institutions.
Internal links are typically used for searching and validating terms entered in linked fields in a primary database, making it possible to automatically have non-preferred terms substituted by preferred terms, to always use the right spelling when entering existing keywords, and to search for narrower, broader, equivalent terms and semantic factors and pseudonyms. In the authority databases themselves the internal links are used to automatically create the correct reciprocal (mirrored) records when you define a hierarchical relation in one term record, and to validate new terms against earlier saved terms to make sure your authority databases won't get corrupted.

The term field in the Thesaurus and the name field in Persons and institutions database that hold the main keywords in authority records are not linked fields, but normal fields. All the other relational fields in such a database are linked fields, linked to the term or name field. (In the properties of such internally linked fields, enter a dot for the Folder to indicate the current folder, enter "=" for the Database to indicate the current database, and mark Link only first occurrence.) An internal link setup is not part of the properties of any one field; internal links are listed and created as separate objects in the tree view of the Application browser, and can be found on the same level as fields and indexes in a database.

There are six different types of internal links. The type defines which reciprocal records are to be created if the current type is (implicitly) used when filling in and saving a term record in an authority database. The types are:

•

Hierarchical (type 1) - defines the relation between the Term field, and the Broader term and Narrower term field, for example: transportation > motorized vehicles > motorbike. A broader term encompasses more than the term, while a narrower term has a more confined meaning: the narrow term is a subset of the term, and the term is a subset of the broader term.
For each narrower (or broader) term entered in an authority record, Collections will create a mirrored record, in which e.g. an "original" narrower term becomes the Term, and the "original" term the Broader term.
In a Collections application, this relationship allows the user to search generically on a term. (See the Collections Help for more information on searching hierarchically, using the hierarchical operator.)

•

Related (type 2) - defines the relation between the Term field and the Related term field, for example: transportation <-> traffic. (Related terms are rather like "see also" references.)
For each related term entered in an authority record, Collections will create another record in which this term is entered in the Term field, and places the other related terms, including the original term, in the Related term field.

•

Equivalent (type 3) - defines the relation between the Term field and the Equivalent term field, for example: car = automobile. Equivalent terms are terms that mean the same, but for which you want to use other terms, for whatever reason. Equivalent terms are often used to represent a term in different languages.
For each equivalent term entered in an authority record, a reciprocal record is created, in which term and equivalent term switch places.
When the user searches on a term in an application, the search is automatically extended to all equivalent terms of this term (if available). So in effect the user searches on the term and all its equivalents.

•

Preferred (type 4) - defines the relation between the Term field and its preferred or non-preferred term in the Use or Used for field, for example: chopper, use motorcycle.
A reciprocal record is created for each Use or Used for term you enter in an authority record. Use contains a preferred term if the Term is non-preferred, while Used for contains a non-preferred term if the Term is preferred.
If the user searches on a non-preferred term in an application, or enters a non-preferred term in a record, the non-preferred term is automatically replaced by the preferred term.

•

Semantic factoring (type 5) - defines the relation between a (complex) concept term and its semantic factors. The concept is defined under Term, and the semantic factors in (the occurrences of) the field Semantic factors. For every relationship you build using semantic factoring, the reciprocal records are generated automatically. In the record of one semantic factor for example, the field Semantic factors of sums up the concepts (as a repeated field) for which this term is a semantic factor.
(Most existing Collections thesauri do not have such an internal link set up in the application yet. Your application may have to be modified to be able to fill and read the semantic fields (SF and FV) through the application. But if you do not plan on using semantic factors, your application does not have to be modified.)

•

Pseudonym (type 6) - in a relation of this type you can associate proper names (aka "main" names) with pseudonyms. This allows you to register e.g. the proper name of an author as well as his or her pseudonym(s) in the Persons and institutions data source and link these names to each other in a way that doesn't prefer one name over the other.
The Standard and Advanced search in Axiell Collections allow the use of a pseudonym operator when you search Persons and institutions or when you search a field in another database, linking to Persons and institutions. When you are searching using pseudonym, you search on the proper name and all its pseudonyms as specified in the Pseudonym entry field (in Persons and institutions), provided these names have the same domain (name type) as the linked field you are searching. It doesn't matter if the name you enter is a proper name or pseudonym and it also doesn't matter if the search key actually does appear in records for the search to succeed on the other names in the pseudonym relation. For example:
author.name pseudonym "Kopland, Rutger"
In this example all records would be retrieved in which the author name is either the search key itself or the proper name or any pseudonym of the search key.
Pseudonyms can be entered in Persons and institutions records once relevant fields and internal links have been added to the database structure and screens (as is the case in Collections model applications 4.5.2 and higher). When your application is ready for it and you've actually registered pseudonyms and you try to validate field data linking to Persons and institutions, you may encounter the following icons in the first column of the list on the View table tab of the Find data for the field window:

A star with an exclamation mark indicates a proper name while an open star indicates a pseudonym. Pseudonyms can be registered in linked fields just like proper names: there won't be any automatic substitution of names.
See the full topic for more information about how to set up this functionality in model applications older than 4.5.2.

Internal links on reference

For Axiell Collections, the fields used in an internal link must be linked on forward reference.

An internal link on reference only stores the record number of the linked record in a link reference tag (the Forward reference of an internally linked field), and fills the linked field with a value from the linked term or name record only when you open or use an authority record with such a linked field, or export it (with processing links); but each term appears only once in the authority database, which prevents redundancy.