Why relations?
Relations are the key principle of the DMLex data model. The DMLex relations facilitate:
- dictionaries with complex entries while keeping simple entry structure,
- entry mobility – the entry can exist on its own and/or inside other entries (think of idioms, phrases…),
- links which stay valid when the dictionary is exported or moved to a different location.
About DMLex
Making lexicography truly digital: the road to DMLex (by Michal Měchura)
What lexicographers need to know about DMLex (by Michal Měchura)
Formatting and relations
The existence of a relation between entries, senses or other elments does not determine how the linked information will be presented to the reader of the dictionary. It is the responsiblity of the presentation environment—the Lexonomy viewer, a bespoke presentation website, an app or the graphic designer of the printed book—to configure or design how the information will be visualised.
Here is a non-exhaustive list of presentation options:
- the full entry is displayed together with the linked entry,
for example the full entry for an idiom is displayed under the full entry of the word it contains - only selected information is displayed together with the entry,
for example the idiom and its definition only is displayed together with the full entry of the word it contains, users need to click the idiom to display its full entry - only clickable link is displayed
for example a button IDIOMS is displayed and clicking it will display the actual idiom entries - the linked entries are only displayed as individual entries, links are ignored for the display purposes, they are only used for machine processing of the data
Example — idioms and other multiword expressions
This example used an idiom to illustrate how relations work. Relations will work analogically for collocations, set phrases, phrasal verbs and other multiword expressions.
The problem
When including idioms, the ideal solution is to place the idiom together with each headword that the idiom contains. For example, to kill two birds with one stone should appear with the entry for kill, with the entry for bird and the entry for stone.
This, however, leads to complex entries, complex entry structures and also to editorial problems — when the entry is updated, it must be updated in three different places. Not ideal. This is when relations come in.
The solution
Create kill, bird, stone and to kill two birds with one stone as four independent entries based on the same entry structure. Then add three relations:
- to kill two birds with one stone ⎯relation type: idiom→ kill
- to kill two birds with one stone ⎯relation type: idiom→ bird
- to kill two birds with one stone ⎯relation type: idiom→ stone
Note: The above example does not use the actual syntax of the relation. It is simplified for easy understanding.
This will indicate that the entry for to kill two birds with one stone is related to the three entries and the nature of the relation is idiom.
The outcomes
Although the data are registered as four independent entries, the existence of relations makes it possible to display the idiom as a separate entry but also display them together with each of the three headwords. The idiom can be presented in various ways:
- display the headword and only the idiom, the user must click the idiom to view the idiom entry,
- display the idiom and its full entry with each of the respective headwords,
- display the idiom with only selected elements (e.g. the definition and exmple only), the user must click the idiom to display the remaining information.
How the idiom is presented to the user depends on the environment in which the data will be presented to the user. The data are stored in a format that does not limit the presenation options. If the dicionary is published in Lexonomy, the presentation depends on the settings of the Lexonomy viewer.
Relations should be used with many other types of information:
synonyms antonyms collocations meronymy multiword expressions see also sub-entry word family etc.
Relations avoid repetition of the same information in different places. They also make use of the basic entry structure and avoid complex structures. A dictionary entry no longer needs to contain a structure for collocations or multiword expressions or subentries. Each can can exist as a separate entry using the basic entry structure and then visualized as required.
Example — subsense
Relations can exist between entry elements, not only between entries. This is an example of a relation between two sense elements which indicates that one of them is a subsense of the other.
Look at his simple entry with a sense (1) and a subsense (1a) and the entry structure that can accommodate entries with subsenses:
The structure repeats the exact same sense block inside another sense block. The indentation shows that one sense can be dependent (it can be a child) of another sense. Although possible, it is not desirable.
The repetition makes the entry structure unnecessarily complex. Especially as a sense typically contains many elements (translation, usage, label, example translation, register, formality…). Having it duplicated can lead to a headache when looking for the right element.
The structure can be simplified with relations.
With relations, the entry es encoded with three senses, instead of two senses and one subsense. Because all senses are registered as equal, the entry structure can be simplified, no nested sense is required.
In addition, a relation is added to the data:
entry:harvest
sense:crop quantity⎯relation type: subsense→ sense:crop collection
Note: The above example does not use the actual syntax of the relation. It is simplified for easy understanding.
