18 Feature Structures

Table of contents

A feature structure is a general purpose data structure which identifies and groups together individual features, each of which associates a name with one or more values. Because of the generality of feature structures, they can be used to represent many different kinds of information, but they are of particular usefulness in the representation of linguistic analyses, especially where such analyses are partial, or underspecified. Feature structures represent the interrelations among various pieces of information, and their instantiation in markup provides a metalanguage for the generic representation of analyses and interpretations. Moreover, this instantiation allows feature values to be of specific types, and for restrictions to be placed on the values for particular features, by means of feature system declarations.69

18.1 Organization of this Chapter

This chapter is organized as follows. Following this introduction, section 18.2 Elementary Feature Structures and the Binary Feature Value introduces the elements fs and f, used to represent feature structures and features respectively, together with the elementary binary feature value. Section 18.3 Other Atomic Feature Values introduces elements for representing other kinds of atomic feature values such as symbolic, numeric, and string values. Section 18.4 Feature and Feature-Value Libraries introduces the notion of predefined libraries or groups of features or feature values along with methods for referencing their components. Section 18.5 Feature Structures as Complex Feature Values introduces complex values, in particular feature-structures as values, thus enabling feature structures to be recursively defined. Section 18.7 Collections as Complex Feature Values discusses other complex values, in particular values which are collections, organized as sets, bags, and lists. Section 18.8 Feature Value Expressions discusses how the operations of alternation, negation, and collection of feature values may be represented. Section 18.9 Default Values discusses ways of representing underspecified, default, or uncertain values. Section 18.10 Linking Text and Analysis discusses how analyses may be linked to other parts of an encoded text. Section 18.11 Feature System Declaration describes the feature system declaration, a construct which provides for the validation of typed feature structures. Formal definitions for all the elements introduced in this chapter are provided in section 18.12 Formal Definition and Implementation.

18.2 Elementary Feature Structures and the Binary Feature Value

The fundamental elements used to represent a feature structure analysis are f (for feature), which represents a feature-value pair, and fs (for feature structure), which represents a structure made up of such feature-value pairs. The fs element has an optional type attribute which may be used to represent typed feature structures, and may contain any number of f elements. An f element has a required name attribute and an associated value. The value may be simple: that is, a single binary, numeric, symbolic (i.e. taken from a restricted set of legal values), or string value, or a collection of such values, organized in various ways, for example, as a list; or it may be complex, that is, it may itself be a feature structure, thus providing a degree of recursion. Values may be under-specified or defaulted in various ways. These possibilities are all described in more detail in this and the following sections.

Feature and feature-value representations (including feature structure representations) may be embedded directly at any point in an XML document, or they may be collected together in special-purpose feature or feature-value libraries. The components of such libraries may then be referenced from other feature or feature-value representations, using the feats or fVal attribute as appropriate.

We begin by considering the simple case of a feature structure which contains binary-valued features only. The following three XML elements are needed to represent such a feature structure:
  • fs (feature structure) represents a feature structure, that is, a collection of feature-value pairs organized as a structural unit.
    typespecifies the type of the feature structure.
    feats(features) references the feature-value specifications making up this feature structure.
  • f (feature) represents a feature value specification, that is, the association of a name with a value of any of several different types.
    nameprovides a name for the feature.
    fVal(feature value) references any element which can be used to represent the value of a feature.
  • binary/ (binary value) represents the value part of a feature-value specification which can contain either of exactly two possible values.
The attributes feats and the fVal are not discussed in this section: they provide an alternative way of indicating the content of an element, as further discussed in section 18.4 Feature and Feature-Value Libraries.
An fs element containing f elements with binary values can be straightforwardly used to encode the matrices of feature-value specifications for phonetic segments, such as the following for the English segment [s].
+--- ---+
| consonantal + |
| vocalic - |
| voiced - |
| anterior + |
| coronal + |
| continuant + |
| strident + |
+--- ---+
bibliography
This representation may be encoded in XML as follows:
<fs type="phonological_segments">
 <f name="consonantal">
  <binary value="true"/>
 </f>
 <f name="vocalic">
  <binary value="false"/>
 </f>
 <f name="voiced">
  <binary value="false"/>
 </f>
 <f name="anterior">
  <binary value="true"/>
 </f>
 <f name="coronal">
  <binary value="true"/>
 </f>
 <f name="continuant">
  <binary value="true"/>
 </f>
 <f name="strident">
  <binary value="true"/>
 </f>
</fs>
Note that fs elements may have an optional type attribute to indicate the kind of feature structure in question, whereas f elements must have a name attribute to indicate the name of the feature. Feature structures need not be typed, but features must be named. Similarly, the fs element may be empty, but the f element must have (or reference) some content.

The restriction of specific features to specific types of values (e.g. the restriction of the feature strident to a binary value) requires additional validation, as does any restriction on the features available within a feature structure of a particular type (e.g. whether a feature structure of type phonological segment necessarily contains a feature voiced). Such validation may be carried out at the document level, using special purpose processing, at the schema level using additional validation rules, or at the declarative level, using an additional mechanism such as the feature-system declaration discussed in 18.11 Feature System Declaration.

Although we have used the term binary for this kind of value, and its representation in XML uses values such as true and false (or, equivalently, 1 and 0), it should be noted that such values are not restricted to propositional assertions. As this example shows, this kind of value is intended for use with any binary-valued feature.

18.3 Other Atomic Feature Values

Features may take other kinds of atomic value. In this section, we define elements which may be used to represent: symbolic values, numeric values, and string values. The module defined by this chapter allows for the specification of additional datatypes if necessary, by extending the underlying class model.featureVal.single. If this is done, it is recommended that only the basic W3C datatypes should be used; more complex datatyping should be represented as feature structures.
  • symbol/ (symbolic value) represents the value part of a feature-value specification which contains one of a finite list of symbols.
    valuesupplies the symbolic value for the feature, one of a finite list that may be specified in a feature declaration.
  • numeric/ (numeric value) represents the value part of a feature-value specification which contains a numeric value or range.
  • string (string value) represents the value part of a feature-value specification which contains a string.
The symbol element is used for the value of a feature when that feature can have any of a small, finite set of possible values, representable as character strings. For example, the following might be used to represent the claim that the Latin noun form mensas (tables) has accusative case, feminine gender, and plural number:
<fs>
 <f name="case">
  <symbol value="accusative"/>
 </f>
 <f name="gender">
  <symbol value="feminine"/>
 </f>
 <f name="number">
  <symbol value="plural"/>
 </f>
</fs>
More formally, this representation shows a structure in which three features (case, gender, and number) are used to define morpho-syntactic properties of a word. Each of these features can take one of a small number of values (for example, case can be nominative, genitive, dative, accusative, etc.) and it is therefore appropriate to represent the values taken in this instance as symbol elements. Note that, instead of using a symbolic value for grammatical number, one could have named the feature singular or plural and given it an appropriate binary value, as in the following example:
<fs>
 <f name="case">
  <symbol value="accusative"/>
 </f>
 <f name="gender">
  <symbol value="feminine"/>
 </f>
 <f name="singular">
  <binary value="false"/>
 </f>
</fs>
Whether one uses a binary or symbolic value in situations like this is largely a matter of taste.
The string element is used for the value of a feature when that value is a string drawn from a very large or potentially unbounded set of possible strings of characters, so that it would be impractical or impossible to use the symbol element. The string value is expressed as the content of the string element, rather than as an attribute value. For example, one might encode a street address as follows:
<fs>
 <f name="address">
  <string>3418 East Third Street</string>
 </f>
</fs>
The numeric element is used when the value of a feature is a numeric value, or a range of such values. For example, one might wish to regard the house number and the street name as different features, using an encoding like the following:
<fs>
 <f name="houseNumber">
  <numeric value="3418"/>
 </f>
 <f name="streetName">
  <string>East Third Street</string>
 </f>
</fs>
If the numeric value to be represented falls within a specific range (for example an address that spans several numbers), the max attribute may be used to supply an upper limit:
<fs>
 <f name="houseNumber">
  <numeric value="3418max="3440"/>
 </f>
 <f name="streetName">
  <string>East Third Street</string>
 </f>
</fs>
It is also possible to specify that the numeric value (or values) represented should (or should not) be truncated. For example, assuming that the daily rainfall in mm is a feature of interest for some address, one might represent this by an encoding like the following:
<fs>
 <f name="dailyRainFall">
  <numeric value="0.0max="1.3trunc="false"/>
 </f>
</fs>
This represents any of the infinite number of numeric values falling between 0 and 1.3; by contrast
<fs>
 <f name="dailyRainFall">
  <numeric value="0.0max="1.3trunc="true"/>
 </f>
</fs>
represents only two possible values: 0 and 1.

As noted above, additional processing is necessary to ensure that appropriate values are supplied for particular features, for example to ensure that the feature singular is not given a value such as <symbol value="feminine"/>. There are two ways of attempting to ensure that only certain combinations of feature names and values are used. First, if the total number of legal combinations is relatively small, one can predefine all of them in a construct known as a feature library, and then reference the combination required using the feats attribute in the enclosing fs element, rather than give it explicitly. This method is suitable in the situation described above, since it requires specifying a total of only ten (5 + 3 + 2) combinations of features and values. Similarly, to ensure that only feature structures containing valid combinations of feature values are used, one can put definitions for all valid feature structures inside a feature value library (so called, since a feature structure may be the value of a feature). A total of 30 feature structures (5 × 3 × 2) is required to enumerate all the possible combinations of individual case, gender and number values in the preceding illustration. We discuss the use of such libraries and their representation in XML further in section 18.4 Feature and Feature-Value Libraries below.

However, the most general method of attempting to ensure that only legal combinations of feature names and values are used is to provide a feature-system declaration discussed in 18.11 Feature System Declaration.

18.4 Feature and Feature-Value Libraries

As the examples in the preceding section suggest, the direct encoding of feature structures can be verbose. Moreover, it is often the case that particular feature-value combinations, or feature structures composed of them, are re-used in different analyses. To reduce the size and complexity of the task of encoding feature structures, one may use the feats attribute of the fs element to point to one or more of the feature-value specifications for that element. This indirect method of encoding feature structures presumes that the f elements are assigned unique xml:id values, and are collected together in fLib elements (feature libraries). In the same way, feature values of whatever type can be collected together in fvLib elements (feature-value libraries). If a feature has as its value a feature structure or other value which is predefined in this way, the fVal attribute may be used to point to it, as discussed in the next section. The following elements are used for representing feature, and feature-value libraries:
  • fLib (feature library) assembles a library of feature elements.
  • fvLib (feature-value library) assembles a library of reusable feature value elements (including complete feature structures).
For example, suppose a feature library for phonological feature specifications is set up as follows.
<fLib n="phonological features">
 <f xml:id="CNS1name="consonantal">
  <binary value="true"/>
 </f>
 <f xml:id="CNS0name="consonantal">
  <binary value="false"/>
 </f>
 <f xml:id="VOC1name="vocalic">
  <binary value="true"/>
 </f>
 <f xml:id="VOC0name="vocalic">
  <binary value="false"/>
 </f>
 <f xml:id="VOI1name="voiced">
  <binary value="true"/>
 </f>
 <f xml:id="VOI0name="voiced">
  <binary value="false"/>
 </f>
 <f xml:id="ANT1name="anterior">
  <binary value="true"/>
 </f>
 <f xml:id="ANT0name="anterior">
  <binary value="false"/>
 </f>
 <f xml:id="COR1name="coronal">
  <binary value="true"/>
 </f>
 <f xml:id="COR0name="coronal">
  <binary value="false"/>
 </f>
 <f xml:id="CNT1name="continuant">
  <binary value="true"/>
 </f>
 <f xml:id="CNT0name="continuant">
  <binary value="false"/>
 </f>
 <f xml:id="STR1name="strident">
  <binary value="true"/>
 </f>
 <f xml:id="STR0name="strident">
  <binary value="false"/>
 </f>
<!-- ... -->
</fLib>
Then the feature structures that represent the analysis of the phonological segments (phonemes) /t/, /d/, /s/, and /z/ may be defined as follows.
<fs
  feats="#CNS1 #VOC0 #VOI0 #ANT1 #COR1 #CNT0 #STR0"/>

<fs
  feats="#CNS1 #VOC0 #VOI1 #ANT1 #COR1 #CNT0 #STR0"/>

<fs
  feats="#CNS1 #VOC0 #VOI0 #ANT1 #COR1 #CNT1 #STR1"/>

<fs
  feats="#CNS1 #VOC0 #VOI1 #ANT1 #COR1 #CNT1 #STR1"/>
The preceding are but four of the 128 logically possible fully specified phonological segments using the seven binary features listed in the feature library. Presumably not all combinations of features correspond to phonological segments (there are no strident vowels, for example). The legal combinations, however, can be collected together, each one represented as an identifiable fs element within a feature-value library, as in the following example:
<fvLib xml:id="fsl1n="phonological segment definitions">
<!-- ... -->
 <fs
   xml:id="T.DF"
   feats="#CNS1 #VOC0 #VOI0 #ANT1 #COR1 #CNT0 #STR0"/>

 <fs
   xml:id="D.DF"
   feats="#CNS1 #VOC0 #VOI1 #ANT1 #COR1 #CNT0 #STR0"/>

 <fs
   xml:id="S.DF"
   feats="#CNS1 #VOC0 #VOI0 #ANT1 #COR1 #CNT1 #STR1"/>

 <fs
   xml:id="Z.DF"
   feats="#CNS1 #VOC0 #VOI1 #ANT1 #COR1 #CNT1 #STR1"/>

<!-- ... -->
</fvLib>
Once defined, these feature structure values can also be reused. Other f elements may invoke them by reference, using the fVal attribute; for example, one might use them in a feature value pair such as:
<f name="dental-fricativefVal="#T.DF"/>
rather than expanding the hierarchy of the component phonological features explicitly.

Feature structures stored in this way may also be associated with the text which they are intended to annotate, either by a link from the text (for example, using the TEI global ana attribute), or by means of standoff annotation techniques (for example, using the TEI link element): see further section 18.10 Linking Text and Analysis below.

Note that when features or feature structures are linked to in this way, the result is effectively a copy of the item linked to into the place from which it is linked. This form of linking should be distinguished from the phenomenon of structure-sharing, where it is desired to indicate that some part of an annotation structure appears simultaneously in two or more places within the structure. This kind of annotation should be represented using the vLabel element, as discussed in 18.6 Re-entrant Feature Structures below.

18.5 Feature Structures as Complex Feature Values

Features may have complex values as well as atomic ones; the simplest such complex value is represented by supplying a fs element as the content of an f element, or (equivalently) by supplying the identifier of an fs element as the value for the fVal attribute on the f element. Structures may be nested as deeply as appropriate, using this mechanism. For example, an fs element may contain or point to an f element, which may contain or point to an fs element, which may contain or point to an f element, and so on.

To illustrate the use of complex values, consider the following simple model of a word, as a structure combining surface form information, a syntactic category, and semantic information. Each word analysis is represented as a <fs type='word'> element, containing three features named surface, syntax, and semantics. The first of these has an atomic string value, but the other two have complex values, represented as nested feature structures of types category and act respectively:
<fs type="word">
 <f name="surface">
  <string>love</string>
 </f>
 <f name="syntax">
  <fs type="category">
   <f name="pos">
    <symbol value="verb"/>
   </f>
   <f name="val">
    <symbol value="transitive"/>
   </f>
  </fs>
 </f>
 <f name="semantics">
  <fs type="act">
   <f name="rel">
    <symbol value="LOVE"/>
   </f>
  </fs>
 </f>
</fs>
This analysis does not tell us much about the meaning of the symbols verb or transitive. It might be preferable to replace these atomic feature values by feature structures. Suppose therefore that we maintain a feature-value library for each of the major syntactic categories (N, V, ADJ, PREP):
<fvLib n="Major category definitions">
<!-- ... -->
 <fs xml:id="Ntype="noun">
<!-- noun features defined here -->
 </fs>
 <fs xml:id="Vtype="verb">
<!-- verb features defined here -->
 </fs>
</fvLib>
This library allows us to use shortcut codes (N, V, etc.) to reference a complete definition for the corresponding feature structure. Each definition may be explicitly contained within the fs element, as a number of f elements. Alternatively, the relevant features may be referenced by their identifiers, supplied as the value of the feats attribute, as in these examples:
<!-- ... -->
<fs xml:id="ADJ" type="adjective" feats="#F1 #F2"/>
<fs xml:id="PREP" type="preposition" feats="#F1 #F3"/>
<!-- ... -->
This ability to re-use feature definitions within multiple feature structure definitions is an essential simplification in any realistic example. In this case, we assume the existence of a feature library containing specifications for the basic feature categories like the following:
<fLib n="categorial features">
 <f xml:id="NN-1name="nominal">
  <binary value="true"/>
 </f>
 <f xml:id="NN-0name="nominal">
  <binary value="false"/>
 </f>
 <f xml:id="VV-1name="verbal">
  <binary value="true"/>
 </f>
 <f xml:id="VV-0name="verbal">
  <binary value="false"/>
 </f>
<!-- ... -->
</fLib>
With such libraries in place, and assuming the availability of similarly predefined feature structures for transitivity and semantics, the preceding example could be considerably simplified:
<fs type="word">
 <f name="surface">
  <string>love</string>
 </f>
 <f name="syntax">
  <fs type="category">
   <f name="posfVal="#V"/>
   <f name="valfVal="#TRNS"/>
  </fs>
 </f>
 <f name="semantics">
  <fs type="act">
   <f name="relfVal="#LOVE"/>
  </fs>
 </f>
</fs>

Although in principle the fVal attribute could point to any kind of feature value, its use is not recommended for simple atomic values.

18.6 Re-entrant Feature Structures

Sometimes the same feature value is required at multiple places within a feature structure, in particular where the value is only partially specified at one or more places. The vLabel element is provided as a means of labelling each such re-entrancy point:
  • vLabel (value label) represents the value part of a feature-value specification which appears at more than one point in a feature structure.
For example, suppose one wishes to represent noun-verb agreement as a single feature structure. Within the representation, the feature indicating (say) number appears more than once. To represent the fact that each occurrence is another appearance of the same feature (rather than a copy) one could use an encoding like the following:
<fs xml:id="NVA">
 <f name="nominal">
  <fs>
   <f name="nm-num">
    <vLabel name="L1">
     <symbol value="singular"/>
    </vLabel>
   </f>
<!-- other nominal features -->
  </fs>
 </f>
 <f name="verbal">
  <fs>
   <f name="vb-num">
    <vLabel name="L1"/>
   </f>
  </fs>
<!-- other verbal features -->
 </f>
</fs>

In the above encoding, the features named vb-num and nm-num exhibit structure sharing. Their values, given as vLabel elements, are understood to be references to the same point in the feature structure, which is labelled by their name attribute.

The scope of the names used to label re-entrancy points is that of the outermost fs element in which they appear. When a feature structure is imported from a feature value library, or referenced from elsewhere (for example by using the fVal attribute) the names of any sharing points it may contain are implicitly prefixed by the identifier used for the imported feature structure, to avoid name clashes. Thus, if some other feature structure were to reference the fs element given in the example above, for example in this way:
<f name="classfVal="#NVA"/>
then the labelled points in the example would be interpreted as if they had the name NVAL1.

18.7 Collections as Complex Feature Values

Complex feature values need not always be represented as feature structures. Multiple values may also be organized as sets, bags or multisets, or lists of atomic values of any type. The vColl element is provided to represent such cases:
  • vColl (collection of values) represents the value part of a feature-value specification which contains multiple values organized as a set, bag, or list.

A feature whose value is regarded as a set, bag, or list may have any positive number of values as its content, or none at all, (thus allowing for representation of the empty set, bag, or list). The items in a list are ordered, and need not be distinct. The items in a set are not ordered, and must be distinct. The items in a bag are neither ordered nor distinct. Sets and bags are thus distinguished from lists in that the order in which the values are specified does not matter for the former, but does matter for the latter, while sets are distinguished from bags and lists in that repetitions of values do not count for the former but do count for the latter.

If no value is specified for the org attribute, the assumption is that the vColl defines a list of values. If the vColl element is empty, the assumption is that it represents the null list, set, or bag.

To illustrate the use of the org attribute, suppose that a feature structure analysis is used to represent a genealogical tree, with the information about each individual treated as a single feature structure, like this:
<fs xml:id="p027type="person">
 <f name="forenames">
  <vColl>
   <string>Daniel</string>
   <string>Edouard</string>
  </vColl>
 </f>
 <f name="motherfVal="#p002"/>
 <f name="fatherfVal="#p009"/>
 <f name="birthDate">
  <fs type="datefeats="#y1988 #m04 #d17"/>
 </f>
 <f name="birthPlacefVal="#austintx"/>
 <f name="siblings">
  <vColl org="set">
   <fs copyOf="#pnb005"/>
   <fs copyOf="#prb001"/>
  </vColl>
 </f>
</fs>

In this example, the vColl element is first used to supply a list of ‘name’ feature values, which together constitute the ‘forenames’ feature. Other features are defined by reference to values which we assume are held in some external feature value library (not shown here). For example, the vColl element is used a second time to indicate that the persons's siblings should be regarded as constituting a set rather than a list. Each sibling is represented by a feature structure: in this example, each feature structure is a copy of one specified in the feature value library.

If a specific feature contains only a single feature structure as its value, the component features of which are organized as a set, bag, or list, it may be more convenient to represent the value as a vColl rather than as a fs. For example, consider the following encoding of the English verb form sinks, which contains an agreement feature whose value is a feature structure which contains person and number features with symbolic values.
<fs type="word">
 <f name="category">
  <symbol value="verb"/>
 </f>
 <f name="tense">
  <symbol value="present"/>
 </f>
 <f name="agreement">
  <fs>
   <f name="person">
    <symbol value="third"/>
   </f>
   <f name="number">
    <symbol value="singular"/>
   </f>
  </fs>
 </f>
</fs>
If the names of the features contained within the agreement feature structure are of no particular significance, the following simpler representation may be used:
<fs type="word">
 <f name="category">
  <symbol value="verb"/>
 </f>
 <f name="tense">
  <symbol value="present"/>
 </f>
 <f name="agreement">
  <vColl org="set">
   <symbol value="third"/>
   <symbol value="singular"/>
  </vColl>
 </f>
</fs>
The vColl element is also useful in cases where an analysis has several components. In the following example, the French word auxquels has a two-part analysis, represented as a list of two values. The first specifies that the word contains a preposition; the second that it contains a masculine plural relative pronoun:
<fs>
 <f name="lex">
  <symbol value="auxquels"/>
 </f>
 <f name="maf">
  <vColl org="list">
   <fs>
    <f name="cat">
     <symbol value="prep"/>
    </f>
   </fs>
   <fs>
    <f name="cat">
     <symbol value="pronoun"/>
    </f>
    <f name="kind">
     <symbol value="rel"/>
    </f>
    <f name="num">
     <symbol value="pl"/>
    </f>
    <f name="gender">
     <symbol value="masc"/>
    </f>
   </fs>
  </vColl>
 </f>
</fs>

The set, bag, or list which has no members is known as the null (or empty) set, bag, or list. A vColl element with no content and with no value for its feats attribute is interpreted as referring to the null set, bag, or list, depending on the value of its org attribute.

If, for example, the individual described by the feature structure with identifier p027 (above) had no siblings, we might specify the siblings feature as follows.
<f name="siblings">
 <vColl org="set"/>
</f>

A vColl element may also collect together one or more other vColl elements, if, for example one of the members of a set is itself a set, or if two lists are concatenated together. Note that such collections pay no attention to the contents of the nested vColl elements: if it is desired to produce the union of two sets, the vMerge element discussed below should be used to make a new collection from the two sets.

18.8 Feature Value Expressions

It is sometimes desirable to express the value of a feature as the result of an operation over some other value (for example, as ‘not green’, or as ‘male or female’, or as the concatenation of two collections). Three special purpose elements are provided to represent disjunctive alternation, negation, and collection of values:
  • vAlt (value alternation) represents the value part of a feature-value specification which contains a set of values, only one of which can be valid.
  • vNot (value negation) represents a feature value which is the negation of its content.
  • vMerge (merged collection of values) represents a feature value which is the result of merging together the feature values contained by its children, using the organization specified by the org attribute.

18.8.1 Alternation

The vAlt element can be used wherever a feature value can appear. It contains two or more feature values, any one of which is to be understood as the value required. Suppose, for example, that we are using a feature system to describe residential property, using such features as number.of.bathrooms. In a particular case, we might wish to represent uncertainty as to whether a house has two or three bathrooms. As we have already shown, one simple way to represent this would be with a numeric maximum:
<f name="number.of.bathrooms">
 <numeric value="2max="3"/>
</f>
A more general way would be to represent the alternation explicitly, in this way:
<f name="number.of.bathrooms">
 <vAlt>
  <numeric value="2"/>
  <numeric value="3"/>
 </vAlt>
</f>
The vAlt element represents alternation over feature values, not feature-value pairs. If therefore the uncertainty relates to two or more feature value specifications, each must be represented as a feature structure, since a feature structure can always appear where a value is required. For example, suppose that it is uncertain as to whether the house being described has two bathrooms or two bedrooms, a structure like the following may be used:
<f name="rooms">
 <vAlt>
  <fs>
   <f name="number.of.bathrooms">
    <numeric value="2"/>
   </f>
  </fs>
  <fs>
   <f name="number.of.bedrooms">
    <numeric value="2"/>
   </f>
  </fs>
 </vAlt>
</f>
Note that alternation is always regarded as exclusive: in the case above, the implication is that having two bathrooms excludes the possibility of having two bedrooms and vice versa. If inclusive alternation is required, a vColl element may be included in the alternation as follows:
<f name="rooms">
 <vAlt>
  <fs>
   <f name="number.of.bathrooms">
    <numeric value="2"/>
   </f>
  </fs>
  <fs>
   <f name="number.of.bedrooms">
    <numeric value="2"/>
   </f>
  </fs>
  <vColl>
   <fs>
    <f name="number.of.bathrooms">
     <numeric value="2"/>
    </f>
   </fs>
   <fs>
    <f name="number.of.bedrooms">
     <numeric value="2"/>
    </f>
   </fs>
  </vColl>
 </vAlt>
</f>
This analysis indicates that the property may have two bathrooms, two bedrooms, or both two bathrooms and two bedrooms.
As the previous example shows, the vAlt element can also be used to indicate alternations among values of features organized as sets, bags or lists. Suppose we use a feature selling.points to describe items that are mentioned to enhance a property's sales value, such as whether it has a pool or a good view. Now suppose for a particular listing, the selling points include an alarm system and a good view, and either a pool or a jacuzzi (but not both). This situation could be represented, using the vAlt element, as follows.
<fs type="real_estate_listing">
 <f name="selling.points">
  <vColl org="set">
   <string>alarm system</string>
   <string>good view</string>
   <vAlt>
    <string>pool</string>
    <string>jacuzzi</string>
   </vAlt>
  </vColl>
 </f>
</fs>
Now suppose the situation is like the preceding except that one is also uncertain whether the property has an alarm system or a good view. This can be represented as follows.
<fs type="real_estate_listing">
 <f name="selling.points">
  <vColl org="set">
   <vAlt>
    <string>alarm system</string>
    <string>good view</string>
   </vAlt>
   <vAlt>
    <string>pool</string>
    <string>jacuzzi</string>
   </vAlt>
  </vColl>
 </f>
</fs>

If a large number of ambiguities or uncertainties need to be represented, involving a relatively small number of features and values, it is recommended that a stand-off technique, for example using the general-purpose alt element discussed in section 16.8 Alternation be used, rather than the special-purpose vAlt element.

18.8.2 Negation

The vNot element can be used wherever a feature value can appear. It contains any feature value and returns the complement of its contents. For example, the feature number.of.bathrooms in the following example has any whole numeric value other than 2:
<f name="number.of.bathrooms">
 <vNot>
  <numeric value="2"/>
 </vNot>
</f>
Strictly speaking, the effect of the vNot element is to provide the complement of the feature values it contains, rather than their negation. If a feature system declaration is available which defines the possible values for the associated feature, then it is possible to say more about the negated value. For example, suppose that the available values for the feature case are declared to be nominative, genitive, dative, or accusative, whether in a TEI feature system declaration or by some other means. Then the following two specifications are equivalent:
(i) <f name="case">
 <vNot>
  <symbol value="genitive"/>
 </vNot>
</f>
(ii)
<f name="case">
 <vAlt>
  <symbol value="nominative"/>
  <symbol value="dative"/>
  <symbol value="accusative"/>
 </vAlt>
</f>

If however no such system declaration is available, all that one can say about a feature specified via negation is that its value is something other than the negated value.

Negation is always applied to a feature value, rather than to a feature-value pair. The negation of an atomic value is the set of all other values which are possible for the feature.

Any kind of value can be negated, including collections (represented by a vColl elements) or feature structures (represented by fs elements). The negation of any complex value is understood to be the set of values which cannot be unified with it. Thus, for example, the negation of the feature structure F is understood to be the set of feature structures which are not unifiable with F. In the absence of a constraint mechanism such as the Feature System Declaration, the negation of a collection is anything that is not unifiable with it, including collections of different types and atomic values. It will generally be more useful to require that the organization of the negated value be the same as that of the original value, for example that a negated set is understood to mean the set which is a complement of the set, but such a requirement cannot be enforced in the absence of a constraint mechanism.

18.8.3 Collection of Values

The vMerge element can be used wherever a feature value can appear. It contains two or more feature values, all of which are to be collected together. The organization of the resulting collection is specified by the value of the org attribute, which need not necessarily be the same as that of its constituent values if these are collections. For example, one can change a list to a set, or vice versa.

As an example, suppose that we wish to represent the range of possible values for a feature ‘genders’ used to describe some language. It would be natural to represent the possible values as a set, using the vColl element as in the following example:
<fs>
 <f name="genders">
  <vColl org="set">
   <symbol value="masculine"/>
   <symbol value="feminine"/>
  </vColl>
 </f>
</fs>
Suppose however that we discover for some language it is necessary to add a new possible value, and to treat the value of the feature as a list rather than as a set. The vMerge element can be used to achieve this:
<fs>
 <f name="genders">
  <vMerge org="list">
   <vColl org="set">
    <symbol value="masculine"/>
    <symbol value="feminine"/>
   </vColl>
   <symbol value="neuter"/>
  </vMerge>
 </f>
</fs>

18.9 Default Values

The value of a feature may be underspecified in a number of different ways. It may be null, unknown, or uncertain with respect to a range of known possibilities, as well as being defined as a negation or an alternation. As previously noted, the specification of the range of known possibilities for a given feature is not part of the current specification: in the TEI scheme, this information is conveyed by the feature system declaration. Using this, or some other system, we might specify (for example) that the range of values for an element includes symbols for masculine, feminine, and neuter, and that the default value is neuter. With such definitions available to us, it becomes possible to say that some feature takes the default value, or some unspecified value from the list. The following special element is provided for this purpose:
  • default/ (default feature value) represents the value part of a feature-value specification which contains a defaulted value.
The value of an empty f element which also lacks a fVal attribute is understood to be the most general case, i.e. any of the available values. Thus, assuming the feature system defined above, the following two representations are equivalent.
<f name="gender"/>
<f name="gender">
 <vAlt>
  <symbol value="feminine"/>
  <symbol value="masculine"/>
  <symbol value="neuter"/>
 </vAlt>
</f>
If, however, the value is explicitly stated to be the default one, using the default element, then the following two representations are equivalent:
<f name="gender">
 <default/>
</f>
<f name="gender">
 <symbol value="neuter"/>
</f>
Similarly, if the value is stated to be the negation of the default, then the following two representations are equivalent:
<f name="gender">
 <vNot>
  <default/>
 </vNot>
</f>
<f name="gender">
 <vAlt>
  <symbol value="feminine"/>
  <symbol value="masculine"/>
 </vAlt>
</f>