Return to the SDD starting page.
First published 2003-11-08, last update: 2004-05-14.
TDWG working group: Structure of Descriptive Data (SDD)
Modifiers modify categorical states or statistical parameters. Examples: "usually red petals", "slightly rough leaves", "probably pale blue eyes", "flower violet (when mature)".
Most character states are the equivalent of adjectives of the objects being described (exceptions are kind-of states, e. g. fruit: capsule, berry, nutlet, ...). In English grammar (not necessarily in other languages!) modifiers are therefore considered adverbs. The following types of adverbs are distinguished in English grammar:
In classical DELTA these expressions must either be expressed through free-form comments within the descriptions or they may be included in the differentiation of states. For a character: "Stem (hairiness)" the states could be:
Such a design is often unsatisfactorily. Consequently, DELTA data sets usually use comments to express these statements. The problems with doing so are:
Unpublished results by G. Hagedorn during the design of DeltaAccess showed that between 60 and 90 % of the comments in DELTA descriptions are repeatedly used adverbial expressions like those listed above. Removing them from the comments and defining them in the terminology increases the analytical value of the SDD and drastically reduces the amount of comment translation.
In ontological computer languages (see e. g. OWL) it is possible to reify statements (reify = make a thing of something). This allows to make statements about statements. Introducing such a general mechanism seemed to overload the design with undue complexity and is analytically difficult to trace. A single level of modifiers seemed a good compromise instead. Note that if more than one modifier is applied to a state it is not possible to express the difference between "(usually reddish) green" and "usually (reddish green)". However, at least for human consumption of the information, this is not a practical problem.
A list of modifiers is defined for the entire project in Terminology/Modifiers. The list is broken down into 3 sublists for Certainty modifiers, Frequency modifiers, and General modifiers. Further modifiers could be distinguished (e. g. temporal/spatial modifiers) but so far additional analytical attributes have been identified only for frequency and probability modifiers.
The following documents describe the various modifiers:
Important note for implementers: in the current schema version all modifiers are derived from a single base type, but the probability, frequency, and general modifiers have separated identity constraints (xs:key). Without this measure it would be possible to declare multiple probability or frequency modifiers in the data elements provided for general modifiers, which shall be prevented. However, in addition to the separate key constraints (GeneralModifierKey, FrequencyModifierKey, ProbabilityModifierKey) and an additional key identify constraint has been defined (CombinedModifierKey) so that no two key values from any group of modifiers may be identical. This additional constraint is intended to allow the choice of alternative database implementations (separate entities for general, frequency and probability modifiers versus a single entity with subtypes).
To become applicable to the states of a character, the modifiers must be enabled for this character. The intention is to give the designer the ability to restrict the modifier vocabulary for data entry of new descriptions. However, a set of description may include older descriptions that use a richer set of modifiers than the designers agreed to use in the future. To accommodate both such "legacy data" (which may be the result of markup of natural language descriptions) and new more stringently coded data, the enabling of modifiers for characters has been deliberately not formulated as an identity constraint. As a consequence, it is perfectly legal to have a modifier in a description that is not currently enabled for this character (it must only be present in the terminology of the project). SDD conforming applications may choose whether to use the information about modifier/character association for data entry or not. They are encouraged to do so.
Enabling each modifier for each character would be significant additional work for the designer and changes would quickly become difficult to manage. To simplify the task, the additional concept of modifier sets has been introduced.
ModifierSets are defined in Terminology/Modifiers/Sets. Each set has a label that allows to select it in a user interface, provision for InternalNotes and ApplicationData, and a list probability, frequency, and general modifiers. A modifier may be a member in multiple modifier sets.
ModifierSets are references from within the characters definitions (Terminology/Characters/Character/ModifierSets). A character may be associated with multiple modifier sets. The union of all modifiers defined in these sets is then available in an editor for this character.
Gregor Hagedorn; Vers. 1; 14. May 2004