How Is a Term Record Structured? Fields and Attributes

The quality of a termbase grows out of the quality of its individual records. A term record is the structured unit that holds a concept together with its equivalents, its fields, its definition and its status. The termbase is these records brought together; if the record is weak, the termbase is weak too. The structure of the record is therefore the most concrete decision in terminology management.

Contents

The structural problems Hann discusses in the appendix to his dictionary are in fact an early example of record design: which information should go where, and by which relations should terms be linked? This article looks at why a term record is structured at all, which fields it contains and what makes a good record good.

Why Is a Term Record Structured?

An unstructured record is no more than two columns in the form “source = target”. At first sight this looks sufficient, but it collapses as the concepts multiply. Which equivalent is valid in which field, which one is preferred, how the term is actually used: none of this fits into those two columns. Structuring brings the missing information into the record.

Structuring also makes searching and filtering possible. If subject-field information is kept in a field of its own, you can filter for the terms belonging to one particular field only. If status is kept in a separate field, you can list only the preferred terms. Structure turns the record from a static piece of text into data that can be queried.

That queryability is also what lets the termbase integrate with translation tools. A record whose fields are held in a defined structure lands in the right fields when it is transferred to a translation tool; subject field, status and definition travel across without being lost. An unstructured record, by contrast, flattens on transfer and the types of information run into one another. Structure makes the record readable not only for people but for systems as well.

Most importantly, structure makes knowledge durable. When the reason a term was chosen, the source it was verified against and the context it is used in are each held in a field of their own, that knowledge is not lost. An unstructured record carries only the answer; a structured record carries the reasoning behind the answer as well. The record thus becomes the organisation’s memory.

Which Fields Does a Record Contain?

A term record carries many types of information at once. Some of them define the concept, others describe the equivalent in each language. The table below summarises the typical fields and what they do.

Field	Level	Function
Definition	Concept	Drawing the boundary of the concept
Subject field	Concept	Tying the concept to a field
Preferred term	Term	Stating the standard
Synonym / status	Term	Managing the other names
Grammatical information	Term	Ensuring correct use
Example of use	Term	Showing the context

Not all of these fields have to be filled in on every record, but there must be a place for all of them. A field left empty can be filled in later; a field that does not exist at all shuts that information out for good. Good record design anticipates the needs of tomorrow, not only those of today.

Concept-Level and Term-Level Fields

The most important distinction in a good record is the one between concept-level and term-level fields. Concept-level fields are shared by all the equivalents: the definition and the subject field belong to the concept itself and do not change from language to language. Term-level fields, on the other hand, are specific to each language and each equivalent.

This distinction prevents repetition. Instead of writing the definition out separately for the equivalent in every language, you write it once at concept level and all the languages share it. The gender or the form of a term belongs to that language alone and is held at term level. The way Hann’s dictionary assigns gender to the German terms and a subject field to the concept is precisely a trace of this two-level thinking.

This two-level thinking matters even more in multilingual termbases, because concept-level information is shared by every language while term-level information stays specific to one. Confusing the two levels corrupts the termbase. If a piece of concept-level information is written at term level, it is repeated in every language, and when one copy is updated the others fall behind. Information held at the right level sits in a single place and is updated in a single operation. The separation of levels protects both the order and the consistency of the record.

Mandatory and Optional Fields

Not every field is equally critical. Good record design settles which fields are mandatory and which are optional. The preferred term and the subject field may be mandatory, for instance, while the example of use and the reasoning are kept optional. This distinction keeps the burden of record-keeping realistic.

Keeping the number of mandatory fields low makes records easy to create and encourages people to contribute to the termbase. Too many mandatory fields put translators off creating records at all; too few leave the record inadequate. The balance is struck against what the organisation actually needs. The aim is to design a record that is both fillable and sufficient.

Optional fields can be filled in over time. A record is created with the mandatory fields first, and as it is used it grows richer with examples of use, reasoning and further context. This gradual growth is far more valuable than a perfect record that is never created at all. A good record does not have to be complete from the outset; it matures. The material in our knowledge centre illustrates this gradual structure.

The split between mandatory and optional also reflects the organisation’s terminology policy. In a field that is critical in legal or safety terms, the definition and the source may be made mandatory; in a team producing at speed, only the preferred term may be required. The same tool is used with different levels of obligation in different organisations. In this respect record design is as much a strategic decision as a technical one.

Lessons from Hann’s Record Structure

Hann’s dictionary offers records that are surprisingly well structured even on paper. Every entry carries the term, the field code, the equivalent and, more often than not, relation descriptors together. The note “co: disc, caliper, pad; ct: drum brake” on the disc brake entry shows how many types of information a single record can carry.

This structure turns the record from a line of equivalence into something closer to a profile of the concept. The term is defined not only by its equivalent but by what it is part of, what it stands opposed to and which field it occurs in. Today’s electronic records carry the idea forward; the fields have been formalised, but the types of information they hold are largely the same.

The discussion in the appendix also carries a warning: hierarchical relations must be built with care. When the narrower terms do not stand in the same kind of relation to the broader term, the structure becomes confusing. This is a reminder that record design is not merely a matter of filling fields but of building relations consistently. A good record calls for consistent relations as much as for completed fields.

Another lesson from the book is that the record has to stay readable. However many fields are added, the record must be laid out so that a translator can scan it quickly and find the information needed. Excessive detail makes the record harder both to complete and to read. Good design strikes the balance between sufficient information and scannable simplicity; every field is there because it genuinely answers a question.

The Criteria for a Good Record

The first criterion for a good term record is that it gives the next user enough information. The record must let the translator use the term correctly and consistently without researching it again. An incomplete record makes the same research happen over and over; a good record makes the effort last.

The second criterion is that it carries the decision and the reasoning behind it together. A good record answers not only “which term” but “why this term”. That reasoning leaves something concrete to fall back on when the question is reopened later. A decision without reasoning is up for debate again the moment it is forgotten.

The third criterion is consistency: the record must follow the same logic as the other records in the termbase. The same information must sit in the same field, in the same form, on every record. A termbase with a consistent structure stays searchable and dependable even at thousands of records. A good record is good as part of a system rather than on its own; the value of a single record only emerges fully when all the records share the same arrangement.

The Türkiye context

In Türkiye term records are most often kept in two-column spreadsheets: the foreign term on the left, the Turkish equivalent on the right. This arrangement works for simple projects, but it cannot carry information about subject field, status or context. Given how many polysemous words and how many synonyms Turkish has, this bare structure soon proves inadequate and starts to generate confusion.

A particularly valuable field for Turkish is the root form of the term together with its typical inflections; without that information, the agglutinative structure of the language makes searching and automatic matching difficult. At our office in Ankara Kızılay we build corporate termbases on a multi-field, two-level record structure, holding the definition at concept level and the equivalent and the grammatical information at term level. The termbase then becomes a searchable and sustainable resource, far beyond a two-column list.

What does this mean for you?

If you are an organisation building a termbase, or having one built, the record structure will determine its long-term value. A two-column start reaches its limits quickly. For a sound record structure:

1. Separate concept-level and term-level fields from the outset.
2. Make the definition and the subject field mandatory for every concept.
3. Design few mandatory fields and a rich set of optional ones.
4. Make sure every record follows the same structure, and check the consistency.

We build corporate termbases on a multi-field, two-level structure, and our translation services cover this design work. To have us review your existing record structure, write to us through the contact page.

Frequently asked questions

What is a term record?

It is the structured unit that holds a concept together with its equivalents, its fields, its definition and its status. A termbase is made up of these records brought together.

Which fields does a term record contain?

At concept level, the definition and the subject field; at term level, the preferred term, synonyms, grammatical information, status and examples of use. Mandatory and optional fields are designed together.

What do concept level and term level mean?

Concept-level fields are shared by all the equivalents (definition, subject field). Term-level fields are specific to each language and each equivalent (form, gender, status). Keeping the two apart keeps the record orderly.

What does a good term record achieve?

It lets the next translator use the term correctly and consistently without researching it again. A good record carries the decision and the reasoning behind it together, and makes knowledge durable.

References

• Hann, M. (1992). The Key to Technical Translation, Vol. 2. John Benjamins.
• ISO 16642:2017. Terminological markup framework (TMF).
• ISO 12620:2019. Management of terminology resources – Data categories.