Possible segment types -
some hints for an alternative approach

Positive conditions

This page assumes that you have experimented with using negative conditions to express feature co-occurrence restrictions within segments and goes on to provide some suggestions for developing an alternative system based on positive conditions.

For the sake of comparison, the procedures on this occasion are aimed at directly building possible bundles rather than filtering out illegitimate ones derived from a random bundle generator. An advantage of this technique is that the same system can be used to build either partially specified feature bundles representing phonemes or fully specified bundles representing (allo)phones. The filter based approach, by contrast, needs a radical modification (see below) to cope with this distinction.

Expressing the conditions

Let us suppose - to start you off - that co-occurrence conditions can be expressed in English in the following ways -the particular conditions are simply illustrative:
  1. If the bundle contains no features then choose and add in either [+syll] or [-syll]

  2. If the bundle contains [-cont -nasal] then choose and add in either [+voice] or [-voice]

  3. If the bundle already contains [+syll] then add in [+son +voice -str]
Condition 1 - or some equivalent 'first' condition based on the presence of an empty bundle - is needed if we are to build feature bundles from scratch. If you like, you can interpret this 'first' condition as saying: Segments may be either vowels or consonants.

Conditions 1 and 2 differ from condition 3 in their treatment of the features to be added. The first two conditions allow a choice in the values associated with the additional feature(s), whereas condition 3 strictly determines the selection. This difference in condition type directly reflects the difference in the status of the features involved. Where a choice in feature value is possible, the distinction between values can be used to carry a meaning difference - i.e. the difference is distinctive. Where no choice is possible - in other words, where the feature value is predictable - we would say that the feature is non-distinctive. It follows that a control regime restricted to conditions of type 1 and 2 will build feature bundles containing only distinctive features which hence represent phonemes. On the other hand, conditions of type 3 - typically called redundancy rules when used to extend the phonemic representation with additional predictable features - create bundles which represent phones or allophones.

Implementing the conditions

In Logo, both condition types can be handled in the same general fashion by implementing each as a two-element list. The first element identifies a structural description which is to be matched against the bundle currently being constructed. The second element lists the choices of additional features which are to be inserted if the current bundle matches the structural description. Where the second sub-list contains a single element, there is, of course, no real choice.

Using SPE based features with @ and ! as values, Condition 1, above, would thus look like this:

	[ [ ]   [ [@syll]  [!syll] ]  ]

Condition 2 would look like this:

	[ [ !cont !nasal ]   [ [@voice]  [!voice] ]  ]

and Condition 3 like this:

	[  [@syll]  [ [@son @voice !str] ] ] 

Developing an interpreter

Making an initial stab at a procedure to interpret such conditions, you might consider using: Pickrandom will do its job well enough, though as anticipated, in the case of Condition 2, it will pointlessly pick an element from a one element list.

On the other hand, subset?, as normally defined, will face a problem with the first condition because the empty list is a subset of every list. Subset? cannot therefore be relied on to identify only those bundles which are completely empty.

Since you will no doubt hold all of the conditions in one super-list (called, for example, :conditions), you might get around the problem by putting Condition 1 in position 1 and by arranging things so that the only time it can be used is at the very start of the bundle-building process. But you might usefully think about whether the set of conditions should be ordered anyway. If you decide against, could you perhaps instead define a new predicate match? in order to circumvent the problem? (This predicate might, of course, itself use subset? to do some of its work.)

An alternative interpreter for removing redundant features.

As we noted, the segment filter based on negative conditions outputs only fully specified segments. As it stands, in other words, it cannot generate partially specified phoneme bundles. What is interesting to see now is that the conditions are of course neutral with respect to their use either in filling in or removing predictable features. With a different interpreter (and only a minor change in the rule format) they can also be used as the control structures for eliminating redundant features from pre-existing fully specified matrices. Look here for a 'phonemicizer' which implements this idea.

And finally . . .

Now is a good time consider whether a segment building mechanism based on positive conditions is more appropriate for the treatment of segment internal feature co-occurrence restrictions than a filter system based on negative conditions? If you prefer a more specific question, then ask yourself in which of the two ways it is easiest (or maybe even possible) to write a description of the segment types of some language of your choice? There is, naturally, always the option to argue that these questions are simply misplaced.



Ron Brasington
Department of Linguistic Science
The University of Reading
Reading
UK

E-mail: ron.brasington@rdg.ac.uk