Domains
You can use so called domains to validate data by logical subsets within a thesaurus that physically only consists of one dataset. Such subsets are known as domains. The advantage of domains is that in one authority database (like a thesaurus) many types of terms can be stored, while terms are validated against specific domains. The way domains work, is best explained with an example.
Let's say we have a thesaurus containing topographical names, e.g. names of countries, cities, streets and districts. The fields linked from the catalogue are co (country), ci (city), st (street) and di (district). To be able to validate the name entered by a user when a city is filled in, it is necessary to know whether a topographical name in the thesaurus is the name of a city or of something else (to avoid data corruption). Therefore, all terms in the thesaurus must have been assigned to a domain. When city names like "Rome", "London", and "Amsterdam" have been assigned to e.g. the domain "city", this allows you to search or validate only on city names by specifying this domain.
The example below discusses a situation in which there is a single linked field in the catalogue: city (tag ci). This is also an example of a link to a fixed domain name. To make the link to the thesaurus and to the correct domain, i.e. the fixed domain city within the thesaurus, certain settings are necessary in both the thesaurus and the catalogue database definitions:
In the thesaurus (thesau.inf) database definition
• | Field settings: if the domains that can be used in the thesaurus are all known (country, city, street and district, in our example) they should preferably be entered in the field definition of the thesaurus Term type field as an enumerative list (in the Enumeration values setup). You therefore specify that the field do (Term type) is an Enumerative field with a Static list containing the values country, city, street and district. This makes it possible in the thesaurus in a running application to assign one of these four domains to each term; you can then choose that domain from a list in the Term type field. |
• | Index settings: first, you must make sure that domains are included in the index. This is done in the index in which all thesaurus terms can be quickly retrieved (in this case, the term index). For the Domain name tag property in the Text index te, you enter the tag of the thesaurus data dictionary field in which all the domain names can be found: this is usually do: the tag for the Term type field in which an enumerated list provides an easy choice between all domains. The reason for having to indicate in the term index in what field the domain name for each term is stored, is that in the thesaurus structure there is no association between a term and its domain: both fields merely occur in the same record. Only in an Text index you can create this association by specifying the domain field. In this index the term field value will then be stored with its domain name as: domain::key. If you add domains to existing thesaurus terms, the index on these terms will automatically be updated with the domains, if the index was already defined as an index with domain names. If on the other hand no Domain name tag was set for this index, and you now want to be able to search and validate on domains, you'll have to set the Domain name tag property, and also reindex this index to include all domains with the terms. (After changing an index definition you'll have to reindex the index to update its contents.) |
In the catalogue database definition (e.g. collect.inf)
• | Field settings: you have to specify that the city field (e.g. tag sd) is a linked field, linked to the authority database. This is done through the field properties. For Name of the domain to link to (on the Linked field properties tab) the name (Value) is entered that was specified as enumerative item in the thesaurus (e.g. city). This is a so-called fixed domain. (A distinction is made between capitals and lower case, so the names must be identical.) |
Variable domains
The example above was for a fixed domain of a certain field in the catalogue database: for entering a new term in there or searching on appropriate terms for this field, always the domain city will be used. When filling in a new city name you therefore cannot choose another domain. City names should just always be stored with the city domain.
We speak of variable or flexible domains when you fill in a new term in a catalogue database (not in an authority database like the thesaurus), and you are offered the choice of domain to which the term should be assigned. Usually this will be implemented through an enumerated domain field beneath the term field. The settings in the thesaurus you have to make for such a flexible domain in the catalogue, are no different from those described above for a fixed domain. Only the field settings in the catalogue are different:
In the catalogue database definition (e.g. collect.inf)
• | Field settings: you have to specify that the term field is a linked field, linked to the authority database. This is done through the field properties. On the Linked field properties tab, mark the Variable radio button. For Tag which holds the domain name to link to () you fill in the tag of the catalogue field in which the name of the domain will be saved. This catalogue domain field is NOT a linked field and should preferably be an enumerated list of all available domains for the term field above it. (A distinction is made between capitals and lower case, so the names must be identical.) In the term index the field value will be stored with the domain name chosen by the user, as: domain::key. The user may also select no domain for the term entered. Just like when you do this in a validation file, the term will just be stored without a domain. Assigning a domain to a certain term, remains optional. |
Note that the thesaurus is not the only authority database you can have, and that above examples could also be applied to for instance the People and institutions data source (people.inf, in which the Name type field holds the domains).
Multiple domains for one term
A single term in a thesaurus or other authority database may be a member of multiple domains. For example, a person's name can be a writer, a customer, and a publisher.
The way to implement this is to make the enumerated domain field a repeated field in the authority database and maybe also in the catalogue (dependent on where you want to offer this functionality). Then the user can add a new occurrence of the enumerated domain field for each domain the term should belong to.
In the term index of this field, each entered domain::key combination will be present separately.