Constraints on the segment inventory of Dutch

The system of nine features yields a large number of possible segments (9! = 362 880), whereas only twenty are actually used in adult Dutch. The number of Feature Co-occurrence Constraints that are active to separate out the illegal

segment combinations, however, is limited to 19, out of a possible 108 (1.5•N(N-1)). They are listed below in (48a) (c-constraints) and (48b) (i-constraints).

(25) a. c-constraints

*[lab, dors]

*[lab, dist]

*[lab, liq]

*[voice, dors]

*[voice, dist]

*[voice, nas]

*[voice, liq]

*[voice, apprx]

*[dors, dist]

*[dors, liq]

*[dors, apprx]

*[cont, nas]

*[dist, nas]

*[dist, liq]

*[dist, apprx]

*[nas, liq]

*[nas, apprx]

*[liq, apprx]

b. i-constraints [apprx]→[cont]

The constraints listed in example (25) above are those that are not violated; ev-ery other possible constraint is. From this list, we can make a few observations, which we will discuss below.

Place First, there is a number of c-constraints that ban segments with double articulations: *[lab, dors], *[lab, dist], *[dors, dist]. This is, of course, entirely expected given the feature definitions in (3.2). Furthermore, voiced dorsals and distributed coronals are banned (*[voice, dors], *[voice, dist]). Furthermore, distributed coronals are limited in their distribution in that they only occur in obstruents: *[dist, spread], *[dist, nas], *[dist, liq] and *[dist, apprx].

Manner The features [nasal], [liquid] and [approximant] cannot occur together, as per *[nas, liq], *[nas, apprx] and *[liq, apprx]. Liquids are always placeless:

*[lab, liq], *[dors, liq]. Furthermore, there is no dorsal glide (*[dors, apprx]) and nasals are non-continuants (*[cont, nas]). The only i-constraint that is not violated by the inventory of Dutch, [apprx]→[cont], expresses that glides are always continuant, or, as stated explicitly by Itˆo et al. (1995), glides are non-contrastively continuant. This constraint also illustrates the necessity of i-constraints in a system with only monovalent features: there is no element that expresses non-continuancy. If there were, for example, a feature [-continuant]

or [stop], the constraint [apprx]→[cont] could be replaced by a constraint such as *[apprx, stop].

Laryngeal The feature [voice] does not occur with any of the manner fea-tures, barring [continuant]: *[voice, nas], *[voice, liq], *[voice, apprx]. This is commensurate with the observation that sonorants are inherently – rather then contrastively – voiced.

A number of these observations reflect cross-linguistic generalisations, where-as others address co-occurrence restrictions particular to Dutch. It is important to note that there is no formal difference in Feature Co-occurrence Constraint Theory; as we will see in the next chapter, all constraints are posited and ranked by the learner. This seems a desirable feature of the theory: no substance-related generalisations need to be hard-wired in UG. On the other hand, constraints are posited that rule out phonetically implausible constellations, effectively repeat-ing phonetic effects in the grammar. Furthermore, if any of these typological generalisations do indeed reflect hard universals, the theory is unable to express this – at least, that is, by way of Feature Co-occurrence Constraints.

The list in (25) is generated by an automated procedure, ensuring that transparency in the procedure is maximal. In what follows, the steps of the procedure are explained in some detail. It should be noted that the same pro-cedure is used for all constraint lists reported in chapter 4.

The algorithm relies on two tables: one listing the segments present in the inventory, the other indicating for each segment its constituent features in a matrix– essentially as in table (3.2). Based on the features that are active,¹ a list of all possible feature combinations is generated. Every entry on the list represents a possible segment, and hence the task of the Feature Co-occurrence Constraints is to divide the list into two groups: legal segments and illegal segments. The FCCs are also generated based on this feature list. The con-straints may be seen as templates, which are populated by features in actual grammars. For each combination of two features, then, one c-constraint and two i-constraints are generated; the difference being that the former is symmetrical, whereas the latter are not.

The next step is to generate a table listing all features as column headers and row headers. Regular table cells are then filled: “1” for legal combinations,

“0” for illegal combinations, and “–” for those cells in the diagonal axis where row header and column header are identical. An example of such a table is given in table (3.3). As every “0” indicates an illegal feature combination, we can read the column header and the row header (both features), and list their combinations as a constraint banning illegal combinations; in other words, a c-constraint that is not violated. By going over the entire matrix, we can separate

1In chapter 4, where the development of the segment inventory is investigated, we will encounter many developmental stages at which not all of the features are active. Naturally, this does not hold for adult Dutch, as we will assume that all features are active. On the matter of the acquisition of features, please see section 2.3 above.

the violated c-constraints from the c-constraints that are not violated.² [cont] [nas] [apprx] [liq] [voice] [dist] [lab] [dors]

[cont] – 0 1 1 1 1 1 1

[nas] 0 – 0 0 0 0 1 1

[apprx] 1 0 – 0 0 0 1 0

[liq] 1 0 0 – 0 0 0 0

[voice] 1 0 0 0 – 0 1 0

[dist] 1 0 0 0 0 – 0 0

[lab] 1 1 1 0 1 0 – 0

[dors] 1 1 0 0 0 0 0 –

Table 3.3: Legal and illegal feature combinations in Dutch

Splicing the list of i-constraints involves slightly more. In contrast to c-constraints, i-constraints ([F]→[G]) deal with feature combinations that are legal, but only in a restricted way: one feature cannot occur without the other.

Hence, with respect to table (3.3), we are interested in the cells listing “1”. For each of these cells, every possible segment is checked. If [F] (row header) is not in that segment, it is ignored. If [F] is present, the segment is then checked for the presence of [G] (column header). If the latter requirement ([G] is present) is true for all segments that satisfy the former requirement ([F] is present), the i-constraint [F]→[G] is not violated; if there is at least one segment which contains [F] but not [G], F→[G] is violated.

This procedure yields two lists of constraints: violated constraints and sat-isfied constraints. To ensure whether the constraints do indeed ban every illegal segment and allow all legal segments to surface, a checking procedure is built into the algorithm. This procedure makes visible any overpredicted or under-predicted segment.

The checking procedure works by taking the list of all possible segments, dividing them into a list of segments that are legal by virtue of the constraint set as derived by the procedure described above, and a list of illegal segments.

The list of legal segments is then compared to the list of attested segments.

Any segment that is unattested but legal is flagged as ‘overpredicted’, whereas any segment that is attested but illegal is marked ‘underpredicted’. The list of possible segments is the same as the one generated in the first step of the algorithm; it is a list of feature bundles.

For every constraint that is unviolated, the two features it refers to are listed (F and G). Every segment in the array of possible segments is then checked for the presence of [F]. If it contains [F], the algorithm proceeds to look for [G] in that same segment. If both are found, the segment is deemed illegal by virtue

2The matrix being symmetrical, each c-constraint is generated twice. The excess con-straints are naturally discarded.

of the constraint *[FG]. If every segment has been checked, the next constraint (e.g., *[HI]) is selected and the procedure is repeated. This yields lists of legal and illegal segments as determined by c-constraints only, so that it is necessary to check again in order to add the effect of the i-constraints.

Again, the two features in the first unviolated i-constraint listed ([F]→[G]) are extracted. Every possible segment is then checked for the presence of [F], and, if [F] is found, for the presence of [G]. If neither or both of the criteria are met, the segment is deemed legal with respect to [F]→[G], and the algorithm moves to the next segment. However, if [F] is found but not [G], the segment is marked illegal. If every segment has been checked, the algorithm proceeds to the next constraint ([H]→[I]).

Given the inventory of Dutch as given in table (3.1), and the feature speci-fication as given in table (3.2), the algorithm yields the constraints in (25) as unviolated. More importantly, no segments are under- or overpredicted, indicat-ing that the procedure is valid, and that the feature specifications are plausible at the very least. In section 3.4, we will go deeper into the choices that were made to arrive at this particular feature set and feature specifications; we will see that adopting a Feature Co-occurrence Constraint methodology to derive the inventory has some significant implications for feature theory. In this light, it is important to note again that FCCs in one form or another are ubiquitous in the OT literature, but certainly also in other theories. Before turning to a discussion of features, however, it is necessary to further explain and motivate the choice and design of the two types of Feature Co-occurrence Constraint.