Lingua::FeatureMatrix is a class for managing user-defined feature-sets. It provides an implementation of datafile parsing that is generic and useful for anyone defining feature sets of symbols.

If you haven't read the "Motivation" you might want to skip down to it.

Featuresets are a common way of describing phonetics problems, e.g. sound change behaviors, but may be useful to people solving other problems as well. (The included Letter class may, for example, be useful in writing ligature rules -- if you find this useful for some other application, please contact the author.)

Users must indicate what type of Eme they are working with. In fact, users will probably want to define their own. To do this, define a subclass of Lingua::FeatureMatrix::Eme and indicate that one as the eme parameter to the new() method call.

If you'd rather not follow through on all the details specified there, you can use one of the two stubby subclasses Phone and Letter provided in the examples/ directory of this distribution as a jumping-off point. They too are documented, and have a loose licensing condition for your unrestricted use (see the README).

You might want to begin by opening the phonematrix.dat file or the lettermatrix.dat file included in the examples directory of this distribution. These use the feature sets defined by Phone.pm and Letter.pm, sample Eme classes each also included in the same directory.

First, some basic terms that make up the underlying grammar of these datafiles:

a string of characters matching the /\S+/ regular expression. This is so widely accepting because of the large variety of phonetic representation schemes available. Leaving this agnostic allows users to use, e.g.:

Each line in the datafile should be considered an entire statement. You'll find that the datafiles are made up of four kinds of lines. Comments, Eme descriptions, Implicatures, and feature classes. Future versions of this module may include more types of lines.

All lines are insensitive to whitespace, except for a Comment line (which isn't a Comment at all unless there is no whitespace before the '#').

Any line beginning with a '#' is a comment, and the entire line is ignored. Note if the '#' is not the first character on a line, it is not ignored. This is the only place that whitespace is considered in this grammar.

It is acceptable, even encouraged, to "underspecify", that is, to specify only those features which are needed to distinguish each phone from its neighbors. If you do so, you will probably want to include extra implicatures though, since any Eme that does not have all its features specified after the implicatures are processed will invoke a carp, which can get irritating.

represents an Implicature. The left FEATURESET is called the implier and the right is called the implicant.

As a special case, the FEATURESETs involved may omit the [] if there is only one feature.

Implicatures allow the user to easily encode lots of different Emes by encoding general "common sense" ideas. For example:

( +stop => +cons )

This means that an Eme that is +stop should be marked +cons by implication. (If this isn't an obvious implication, you may need some phonology review, or you may be speaking Czech or Berber, and I can't help you much with either problem.)

Note that more than one feature may imply the same setting, even to the same Eme. This is acceptable:

( +fric => +cons )
( +stop => +cons )

Both of these will apply to the following Eme definition:

CH [ +fric +stop -voice ]

Implicatures are one-way, or else the following wouldn't work:

( -tense => +vow )
( +tense => +vow )

(The two implications above indicate that if tense is specified at all, then vow should be + by implication.)

An implicature need not set a single feature in the implicant, nor is it restricted to only one feature in the implier.

( +sib => [ -voice +cons ] )
( [ +vow +cons ] => [ +glide ] )

Note that some implicatures can point out that a certain field had better *not* be set (to either plus or minus); here we use the 'ungrammatical' * marker:

( +cons => *tense )
( +vow => [ *stop *fric ] )

The first example above indicates that if cons is true, then it is ungrammatical to specify a boolean value for tense, and the second indicates that if vow is true, then it is ungrammatical to specify stop or fric. Note that the *fric setting may not be correct in languages other than English; that's the point of putting all this in a configuration file.

Sometimes putting "obvious" things into implicatures can help catch silly mistakes in your eme definitions, especially when you can specify ungrammaticality:

Using a * value sets that feature of the Eme to be undef, rather than 1 or 0, which is Perl's way of indicating "neither false nor true, but the question is meaningless."

Note that for the time being, the implicatures are applied in the order that they are submitted to the system. Future editions may involve automatic ordering of the implicatures (see "Future Improvements").

Furthermore, I may want to be able to refer to "feature classes", that is, composite features like "affricate":

class AFF [ +stop +fric ]

(this example would match 'CH' but not 'S' or 'EH').

To complicate things further, the list of primitive features is linguistically controversial, the set of relevant classes varies from language to language, even if you agree on the theoretical primitives, and the choice of symbol set to represent the phoneme (IPA, Sampa, DARPA-bet, etc) is varied and political.

Thus, in the finest Perl sense, TMTOWTDI. The dimensions of flexibility provided are:

You, the user, define what you want to be the featureset by subclassing Lingua::FeatureMatrix::Eme, distributed with this module. An added side bonus is that you decide whether the base unit is a Phone or a Phoneme (or, for that matter, a SoundUnit or a Letter -- that subclass is your module, and the goal is to "[put] the focus not so much onto the problem to be solved, but rather onto the person trying to solve the problem." (see Larry Wall's talk on Perl and postmodernism http://kiev.wall.org/~larry/pm.html).

You, the user, define what the feature set is, and you define how the phones (er, emes) distribute among those features, using the best of Impatience -- use the existing linguistic typographic conventions, and this module takes care of constructing your objects for you. No translating among conventions for us (that wouldn't be Lazy!).

But let's go one step further. Languages include redundancy, and sometimes it's boring (and not Lazy) to have to specify yourself that something that is [+stop] is also [-vow +cons], especially if you have to specify this for every single [+stop] consonant.

So this module also introduces the concept of an implicature -- you can say, in simple, linguistically-familiar format, that

( [+stop] => [-vow +cons] )

and this will apply for all phones in the current dataset (unless I'm speaking Berber, where this isn't necessarily true...). It's also Lazy, because the module also does the work of letting me know whether I have forgotten to specify any of the features of a given phone: