Title: A Declarative Framework for Modeling Pronunciation and Rhyme

Author: David Dubin
Author: David J. Birnbaum
Statement of responsibility:
Marked up by Martin Holmes
Patricia Baer
Marked up to be included in the ACH/ALLC 2005 Conference Abstracts book.
Source(s):
None
Text classification:
Keywords:
paper
Keywords:
  • poetry
  • Logic Programming
  • design considerations
  • MDH: Created from John Bradley's XML March 2005
  • MDH: Marked up April 2005
  • MDH: Merged changes from author's proofreading 28 April 2005
  • MDH: PGL's editorial revisions merged 17 May 2005

A Declarative Framework for Modeling Pronunciation and Rhyme

David Dubin    ddubin@uiuc.edu

University of Illinois

David J. Birnbaum    djbpitt+@pitt.edu

University of Pittsburgh

Encoding standards such as TEI give scholars a great deal of flexibility in annotating texts to meet the particular needs of a study or project. Researchers necessarily make choices about which features of a text to highlight, what kinds of additional information to add, and what facts are left to be inferred from other sources of evidence apart from markup.
Among the factors to be considered in designing or adopting text encoding procedures are the prospects for:
This paper discusses considerations motivating the ongoing design of a software framework for analysis of rhyming schemes in 19th century Russian poetry. At its simplest, the application receives as input poems marked up like the example in Figure 1 and produces output like the following:
?- run('poem.xml').
Line 001 rhymes with Line 003
Line 002 rhymes with Line 004
Line 003 rhymes with Line 001
Line 004 rhymes with Line 002
<POEM OPID="S1.100" LINESPAN="1-4"
COLPAGE="1.261" YEAR="1817"
MASCRHYME="2" FEMRHYME="2"
OTHERRHYME="0" MASCUNRHYME="0"
FEMUNRHYME="0" OTHERUNRHYME="0"
NOENDWORD="0" COL13="2.75">
<TITLE>Надпись на стене больницы</TITLE>
<LINE LINENO="001">Вот здесь лежит
больной студ<STRESS>е</STRESS>нт;</LINE>
<LINE LINENO="002">Его судьба
неумол<STRESS>и</STRESS>ма.</LINE>
<LINE LINENO="003">Несите прочь
медикам<STRESS>е</STRESS>нт:</LINE>
<LINE LINENO="004">Болезнь любви
неизлеч<STRESS>и</STRESS>ма!</LINE>
</POEM>
Figure 1
Programs producing output such as the example above could be written in any of a variety of different programming languages. They might employ different strategies for integrating linguistic and orthographic processing rules with evidence encoded more directly using markup. For example, we discuss an earlier approach to the current project in Adams & Birnbaum. Our current implementation, however, is written in Prolog as an application of the BECHAMEL system for markup semantics analysis (Dubin et al.). The motivation for this choice was our wish to plan from the beginning for extensions to other encoding schemes and generalization to other kinds of analysis.
Prolog is a declarative language of rules and assertions, and BECHAMEL is a collection of predicates supporting the declaration of object classes, properties, relations among objects, and the execution of inference rules based on information extracted from XML documents. An example of a Prolog clause is shown below: it is part of our application's logic for determining that two sequences of phonemes at the ends of a pair of orthographic lines all agree with each other (i.e., that the sounds at the end of the lines rhyme with each other).
all_agree(P1,P2) :- agree(P1,P2),
/* P1 is written using C1 */
relation_applies(written,[P1,C1]),
relation_applies(written,[P2,C2]),
/* C3 follows C1 */
relation_applies(follows,[C1,C3]),
relation_applies(follows,[C2,C4]),
relation_applies(written,[P3,C3]),
relation_applies(written,[P4,C4]),
all_agree(P3,P4).
In the clause, P1, P2, P3, and P4 are variables representing phoneme objects, and C1, C2,C3, and C4 are variables representing character objects. The predicate all_agree(P1,P2) will be satisfied if each of the predicates following the implication sign can be satisfied. The logic of the clause can be read as follows:
Phonemes P1 and P2 'all agree' if phonemes P1-P4 are written using characters C1-C4, respectively, if C3 follows C1 in the orthographic line, if C4 follows C2 in the line, if P1 and P2 'agree' and if P3 and P4 'all agree.'
This clause is one of several in a recursive rule that attempts to match up corresponding phonemes in rhyming lines, starting from the line's stressed vowel.
A major advantage of Prolog's declarative approach is the flexibility to define logic for separate cases in separate clauses for the same rule. For example, in the clause shown above, it is presupposed that in both lines there will be a simple one-to-one mapping from characters in sequence to phonemes. But accommodating more complex cases need not complicate the expression of the simple case: if the simpler clause cannot be satisfied then Prolog's inference engine will search for a different clause of the same rule that can be satisfied.
Reasoning about poems like the one in the example above requires that we model their contents at both a phonemic and orthographic level. The rules for Russian pronunciation include not only the way that particular vowels and consonants sound, but also how those phonemes are cued by the way the text is written (as with, for example, the palatalizing effect of the soft sign and the soft vowel letters). The BECHAMEL system's definition predicates for object classes, properties, and relations gives us the ability to model each of these levels with declarations such as the following:
/* There are things called phonemes */
declare_class(phoneme).
/* There are things called vowels */
declare_class(vowel).
declare_class(consonant).
/* vowels are a kind of phoneme */
declare_subclass(vowel,phoneme).
declare_subclass(consonant,phoneme).
/* vowels may be stressed or not */
declare_property(vowel,stress,atom).
declare_property(consonant,palatalized,atom),
declare_relation(written, [phoneme, letter]),
declare_class(character),
declare_property(character,id,atom),
declare_property(character,palatalizing,atom),
In our approach, the phonemic properties of vowels and consonants are distinct from the orthographic properties of characters, written words, and lines. But it can occasionally be convenient for users to ignore these distinctions, particularly in comparing different proposed models for the same data. We therefore aim to let the models govern as much processing of our raw data as possible. For example, both phonemic and orthographic properties of letters are recorded in a data file using the same predicate as shown below:
alph_table(1083,id,u043B).
alph_table(1083,name,el).
alph_table(1083,charclass,consonant).
alph_table(1083,case,lower).
alph_table(1083,voicing,voiced).
alph_table(1083,place,alveolar).
alph_table(1083,manner,liquid).
In this example, id, name, case, and charclass are all properties of characters, while voicing, place, and manner are phonemic properties. As individual characters and phonemes are instantiated, they acquire only those properties that are appropriate for their class. This is accomplished through general-purpose rules that match on the basis of our property declarations. So if we were to decide (for example) that name should be a property of the phoneme rather than the character, we need only change the declaration, and the property value recorded in the data file would be assigned to phoneme objects rather than character objects.
BECHAMEL supports superclass and subclass relations, which allows us to declare that vowels and consonants are subclasses of phoneme, and that letters, marks, and spaces are subclasses of character. Since the conventional superclass/subclass relation can prove awkward in some situations, BECHAMEL includes class declaration expressions similar to those found in ontology languages such as OWL (W3C).
For example, place and manner of articulation in consonants may be used to describe classes of phonemes, not merely features of them (the class of stops, the class of velar consonants, etc.). It would be awkward to declare each consonant as a subclass of both its place and manner of articulation. Instead we use a BECHAMEL predicate that permits us to declare membership in a class based on the value assigned to a particular property:
declare_propclass(alveolar,place,alveolar).
declare_propclass(velar,place,velar).
declare_propclass(glottal,place,glottal).
declare_propclass(glide,manner,glide).
declare_propclass(liquid,manner,liquid).
declare_propclass(nasal,manner,nasal).
An alveolar, therefore, is anything that takes the value alveolar on its place property, a nasal anything that takes nasal for its manner property, and so on. These class identities are in addition to the one that instantiated the object. A related feature of BECHAMEL is the ability to define class membership based on a Boolean expression. The following example declares that an obstruent is either a stop, a fricative, or an affricate:
declare_boolean(obstruent,or(stop,
or(fricative,affricate))).
All of these features are employed with the aim of making our understandings, models, and simplifications regarding the rules of Russian pronunciation as clear and as explicit as possible. We express them in the form of declarative rules so as not to entangle implementation details of our code with aspects of our model that should be open to criticism, revision, and extension. For example, our rule governing the devoicing of word-final obstruents states that if an obstruent O is written with word-final letter L, then O should take a value of voiceless on its voicing property (unless it already has that property value):
mrule2 :- isa(O, obstruent),
relation_applies(written,[O,L]),
property_applies(L,wordfinal,true),
not(property_applies(O,voicing,voiceless)),
apply_property(O,voicing,voiceless),!.
Taking this approach, even a limited application, such as determining which lines of a poem rhyme, requires a large number of these declarations and rules; there is a very real sense in which we are doing it 'the hard way'. But as a result our application-specific code is only about seven percent of the size of the supporting declarations and rules. In addition to strengthening our confidence in our framework's potential for generalization, the demands of our approach have been a helpful modeling exercise in their own right.

Bibliography