6 Verse

Contenu

This module is intended for use when encoding texts which are entirely or predominantly in verse, and for which the elements for encoding verse structure already provided by the core module are inadequate.

The tags described in section 3.12.1 Core Tags for Verse include elements for the encoding of verse lines and line groups such as stanzas: these are available for any TEI document, irrespective of the module it uses. Like the modules for prose and for drama, the module for verse additionally makes use of the module defined in chapter 4 Default Text Structure to define the basic formal structure of a text, in terms of front, body and back elements and the text-division elements into which these may be subdivided.

The module for verse extends the facilities provided by these modules in the following ways:

6.1 Structural Divisions of Verse Texts

Like other kinds of text, texts written in verse may be of widely differing lengths and structures. A complete poem, no matter how short, may be treated as a free-standing text, and encoded in the same way as a distinct prose text. A group of poems functioning as a single unit may be encoded either as a group or as a text, depending on the encoder's view of the text. For further discussion, including an example encoding for a verse anthology, see chapter 4 Default Text Structure.

Many poems consist only of ungrouped lines. This short poem by Emily Dickinson is a simple case:
<text>
 <front>
  <head>1755</head>
 </front>
 <body>
  <l>To make a prairie it takes a clover and one bee,</l>
  <l>One clover, and a bee,</l>
  <l>And revery.</l>
  <l>The revery alone will do,</l>
  <l>If bees are few.</l>
 </body>
</text>
Often, however, lines are grouped, formally or informally, into stanzas, verse paragraphs, etc. The lg element defined in the core tag set (in section 3.12.1 Core Tags for Verse) may be used for all such groupings. It may thus serve for informal groupings of lines such as those of the following example from Allen Ginsberg:
<text>
 <body>
  <head>My Alba</head>
  <lg>
   <l>Now that I've wasted</l>
   <l>five years in Manhattan</l>
   <l>life decaying</l>
   <l>talent a blank</l>
  </lg>
  <lg>
   <l>talking disconnected</l>
   <l>patient and mental</l>
   <l>sliderule and number</l>
   <l>machine on a desk</l>
  </lg>
 </body>
</text>
It may also be used to mark the verse paragraphs into which longer poems are often divided, as in the following example from Samuel Taylor Coleridge's Frost at Midnight:
<lg>
 <l>The Frost performs its secret ministry,</l>
 <l>Unhelped by any wind. ...</l>
 <l>Whose puny flaps and freaks the idling Spirit</l>
 <l>By its own moods interprets, every where</l>
 <l>Echo or mirror seeking of itself,</l>
 <l part="I">And makes a toy of Thought.</l>
</lg>
<lg>
 <l part="F">But O! how oft,</l>
 <l>How oft, at school, with most believing mind</l>
 <l>Presageful, have I gazed upon the bars,</l>
 <l>To watch that fluttering <hi>stranger</hi>! ... </l>
</lg>
<lg>
 <l>Dear Babe, that sleepest cradled by my side,</l>
</lg>
Note, in the above example, the use of the part attribute on the l element, where a verse line is broken between two line groups, as discussed in section 3.12.1 Core Tags for Verse.
Most typically, however, the lg element is used to mark the highly regular line groups which characterize stanzaic and similar verse forms, as in the following example from Chaucer:
<lg>
 <l>Sire Thopas was a doghty swayn;</l>
 <l>White was his face as payndemayn,</l>
 <l>His lippes rede as rose;</l>
 <l>His rode is lyk scarlet in grayn,</l>
 <l>And I yow telle in good certayn,</l>
 <l>He hadde a semely nose.</l>
</lg>
<lg>
 <l>His heer, his ber was lyk saffroun,</l>
 <l>That to his girdel raughte adoun;</l>
</lg>
Like other text-division elements, lg elements may be nested hierarchically. For example, one particularly common English stanzaic form consists of a quatrain or sestet followed by a couplet. The lg element may be used to encode both the stanza and its components, as in the following example from Byron:
<lg type="stanza">
 <lg type="sestet">
  <l>In the first year of Freedom's second dawn</l>
  <l>Died George the Third; although no tyrant, one</l>
  <l>Who shielded tyrants, till each sense withdrawn</l>
  <l>Left him nor mental nor external sun:</l>
  <l>A better farmer ne'er brushed dew from lawn,</l>
  <l>A worse king never left a realm undone!</l>
 </lg>
 <lg type="couplet">
  <l>He died — but left his subjects still behind,</l>
  <l>One half as mad — and t'other no less blind.</l>
 </lg>
</lg>

Note the use of the type attribute to name the type of unit encoded by the lg element; this attribute is common to all members of the att.divLike class (see section 4.1.1 Un-numbered Divisions).23 ‘Sestet’ and ‘couplet’ might conceivably also be used as the values of the rhyme attribute in an analysis of rhyme scheme, for which see below, section 6.3 Rhyme and Metrical Analysis. The type attribute is intended solely for conventional names of different classes of text block; the met attribute is intended for systematic metrical analysis.

As a further example, consider the Shakespearean sonnet. This may be divided into two parts: a concluding couplet, and a body of twelve lines, itself subdivided into three quatrains:
<text>
 <body>
  <lg>
   <lg type="quatrain">
    <l>My Mistres eyes are nothing like the Sunne,</l>
    <l>Currall is farre more red, then her lips red</l>
    <l>If snow be white, why then her brests are dun:</l>
    <l>If haires be wiers, black wiers grown on her head:</l>
   </lg>
   <lg type="quatrain">
    <l>I have seene Roses damaskt, red and white,</l>
    <l>But no such Roses see I in her cheekes,</l>
    <l>And in some perfumes is there more delight,</l>
    <l>Then in the breath that from my Mistres reekes.</l>
   </lg>
   <lg type="quatrain">
    <l>I love to heare her speake, yet well I know,</l>
    <l>That Musicke hath a farre more pleasing sound:</l>
    <l>I graunt I never saw a goddesse goe,</l>
    <l>My Mistres when shee walkes treads on the ground.</l>
   </lg>
  </lg>
  <lg type="couplet">
   <l>And yet by heaven I think my love as rare,</l>
   <l>As any she beli'd with false compare.</l>
  </lg>
 </body>
</text>

Particularly lengthy poetic texts are often subdivided into units larger than stanzas or paragraphs, which may themselves be subdivided. Spenser's Faery Queene, for example, consists of twelve ‘books’ each of which contains a prologue followed by twelve ‘cantos’. Each prologue and each canto consists of nine-line ‘stanzas’, each of which follows the same regular pattern. Other examples in the same tradition are easy to find.

Large structures of this kind are most conveniently represented by div or div1 elements, as described in section 4.1 Divisions of the Body. Thus the start of the Faerie Queene might be encoded as follows:
<body>
 <div n="I" type="book">
  <div n="1" type="canto">
   <lg n="I.1.1" type="stanza">
    <l>A Gentle Knight was pricking on the plain</l>
    <l>Y cladd in mightie armes and silver shielde,</l>
   </lg>
  </div>
 </div>
</body>
The encoder must choose at which point in the hierarchy of structural units to introduce lg elements rather than a yet smaller div element: it would (for example) also be possible to encode the above example as follows:
<body>
 <div n="I" type="book">
  <div n="I.1" type="canto">
   <div n="I.1.1" type="stanza">
    <l>A gentle knight was pricking on the plain</l>
    <l>Ycladd in mightie armes and silver shielde,</l>
   </div>
  </div>
 </div>
</body>

One reason for using div rather than lg elements is that the former may contain non-metrical elements, such as epigraphs or dedications and other members of the model.divTop class, whereas lg elements may contain only headings or metrical lines.

6.2 Components of the Verse Line

It is often convenient for various kinds of analysis to encode subdivisions of verse lines. The general purpose seg element defined in the tag set for segmentation and alignment (section 16.3 Blocks, Segments, and Anchors) is provided for this purpose:
  • seg (segment quelconque) contient une unité de texte quelconque de niveau ‘segment’.

To use this element together with the module for verse, the module for segmentation and alignment must also be enabled as further described in section 1.2 Defining a TEI Schema.

In Old and Middle English alliterative verse, individual verse lines are typically split into half lines. The seg element may be used to mark these explicitly, as in the following example from Langland's Piers Plowman:
<l>
 <seg>In a somer seson,</seg>
 <seg>whan softe was the sonne,</seg>
</l>
<l>
 <seg>I shoop me into shroudes</seg>
 <seg>as I a sheep were,</seg>
</l>
<l>
 <seg>In habite as an heremite </seg>
 <seg>unholy of werkes,</seg>
</l>
<l>
 <seg>Went wide in this world </seg>
 <seg>wondres to here.</seg>
</l>
The seg element can be nested hierarchically, in the same way as the lg element, down to whatever level of detailed structure is required. In the following example, the line has been divided into feet, each of which has been further subdivided into syllables.24
<l>
 <seg type="foot">
  <seg type="syll">Ar</seg>
  <seg type="syll">ma </seg>
  <seg type="syll">vi</seg>
 </seg>
 <seg type="foot">
  <seg type="syll">rum</seg>
  <seg type="syll">que </seg>
  <seg type="syll">ca</seg>
 </seg>
 <seg type="foot">
  <seg type="syll">no </seg>
  <seg type="syll">Tro</seg>
 </seg>
 <seg type="foot">
  <seg type="syll">iae </seg>
  <seg type="syll">qui </seg>
 </seg>
 <seg type="foot">
  <seg type="syll">pri</seg>
  <seg type="syll">mus </seg>
  <seg type="syll">ab </seg>
 </seg>
 <seg type="foot">
  <seg type="syll">or</seg>
  <seg type="syll">is </seg>
 </seg>
</l>

The seg element may be used to identify any subcomponent of a line which has content; its type attribute may characterize such units in any way appropriate to the needs of the encoder. For the specific case of labeling each foot with its formal type (‘dactyl’, ‘spondee’, etc.), and each syllable with its metrical or prosodic status (syllables bearing primary or secondary stress, long syllables, short syllables), however, the specialized attributes met and real are defined, which provide a more systematic framework than the type attribute; see section 6.3 Rhyme and Metrical Analysis below.

In classical verse, a hexameter like that above may also be formally divided into two cola or ‘hemistiches’. This example provides a typical case, in that the boundary of the first colon falls in the middle of one of the feet (between the syllables ‘no’ and ‘Tro’). If both kinds of segmentation are required, the part attribute might be used to mark the overlapping structure as follows.
<l>
 <seg type="hemistich">
  <seg type="foot">
   <seg type="syll">Ar</seg>
   <seg type="syll">ma </seg>
   <seg type="syll">vi</seg>
  </seg>
  <seg type="foot">
   <seg type="syll">rum</seg>
   <seg type="syll">que </seg>
   <seg type="syll">ca</seg>
  </seg>
  <seg type="foot" part="I">
   <seg type="syll">no </seg>
  </seg>
 </seg>
 <seg type="hemistich">
  <seg type="foot" part="F">
   <seg type="syll">Tro</seg>
  </seg>
  <seg type="foot">
   <seg type="syll">iae </seg>
   <seg type="syll">qui </seg>
  </seg>
 </seg>
</l>
Instead of using the part attribute on the seg element, it might be simpler just to mark the point at which the caesura occurs. An additional element is provided for analyses of this kind, in which what is to be marked are points ‘between the words’, which have some significance within a verse line:
  • caesura/ signale une coupe rythmique à l'intérieur d'un vers.
In classical prosody, the caesura, which occurs within a foot, is distinguished from a diaeresis, which occurs on a foot boundary (not to be confused with the division of a diphthong into two syllables, or the diacritic symbol used to indicate such division, each of which is also termed diaeresis). This distinction is rarely made nowadays, the term caesura being used for any division irrespective of foot boundaries. No special-purpose <diaeresis> element is therefore provided.
As an example of the caesura element, we refer again to the example from Langland. An encoder might choose simply to record the location of the caesura within each line, rather than encoding each half-line as a segment in its own right, as follows:
<l>In a somer seson, <caesura/> whan softe was the sonne, </l>
<l>I shoop me into shroudes <caesura/> as I a sheep were, </l>
<l>In habite as an heremite <caesura/> unholy of werkes, </l>
<l>Went wide in this world <caesura/> wondres to here. </l>
Logically, the opposite of caesura might be considered to be enjambement. When the verse module is included in a schema, an additional class called att.enjamb is defined as follows:
  • att.enjamb ( enjambement) regroupe les éléments portant l'attribut enjamb
    enjamb ( enjambement) indique que la fin d'un vers est marqué par un enjambement.
The following lines demonstrate the use of the enjamb attribute to mark places where there is a discrepancy between the boundaries of the l elements and the syntactic structure of the verse (a discrepancy of some significance in some schools of verse):
<l enjamb="y">Un astrologue, un jour, se laissa choir</l>
<l>Au fond d'un puits.</l>

6.3 Rhyme and Metrical Analysis

When the module for verse is in use, the following additional attributes are available to record information about rhyme and metrical form:
  • att.metrical définit un ensemble d'attributs que certains éléments peuvent utiliser pour représenter de l'information métrique.
    met (structure métrique, canonique) contient un encodage spécifié par l'utilisateur pour la structure métrique conventionnelle de l'élément.
    real (structure métrique réelle) contient un encodage, spécifié par l'utilisateur, de la réalisation effective de la structure métrique conventionnelle applicable à l'élément.
    rhyme (schéma rimique) spécifie quel schéma de rimes a été appliqué à un groupe de lignes versifiées.

These attributes may be attached to the lg element, or to the higher-level text-division elements div, div1, etc. In general, the attributes should be specified at the highest level possible; they may not however be specifiable at the highest level if some of the subdivisions of a text are in prose and others in verse. All these attributes may also be attached to the l and seg elements, but the default notation for the rhyme attribute has no defined meaning when specified on l or seg. The value for these attributes may take any form desired by the encoder, but the nature of the notation used will determine how well the attribute values can be processed by automatic means.

The primary function of the metrical attributes is to encode the conventional metrical or rhyming structure within which the poet is working, rather than the actual prosodic realization of each line; the latter can be recorded using the real attribute, as further discussed below. A simple mechanism is also provided for recording the actual realization of a rhyme pattern; see 6.4 Rhyme.

6.3.1 Sample Metrical Analyses

As a simple example of the use of these attributes, consider the following lines from Pope's Essay on Criticism:
<div
  type="book"
  n="1"
  met="-+|-+|-+|-+|-+/"
  rhyme="aa">
 <lg n="1" type="paragraph">
  <l>'Tis hard to say, if greater Want of Skill</l>
  <l>Appear in <hi>Writing</hi> or in <hi>Judging</hi> ill;</l>
  <l>But, of the two, less dang'rous is th'Offence,</l>
  <l>To tire our <hi>Patience</hi>, than mis-lead our <hi>Sense</hi>:</l>
 </lg>
</div>

This text is written entirely in heroic couplets; each line is an iambic pentameter (which, using a common notation, can be described with the formula -+|-+|-+|-+|-+/, each - denoting a metrically unstressed syllable, each + a metrically stressed one, each | a foot boundary, and the / a line-end), and the couplets rhyme (which can be represented with the conventional formula aa).

Because both rhyme pattern and metrical form are consistent throughout the poem, they may be conveniently specified on the div element; the values given for the attributes will be inherited by any metrical unit contained within the div elements of this poem, and must be interpreted in the appropriate way.

Since the notation used in the met, real, and rhyme attributes is user-defined, no binding description can be given of its details or of how its interpretation must proceed. (A default notation is provided for the rhyme attribute, which however the encoder can replace with another; see section 6.4 Rhyme.) It is expected, however, that software should be able to support these attributes in useful ways; the more intelligent the software is, and the more knowledge of metrics is built into it, the better it will be able to support these attributes. In the extract given above, for example, the met and rhyme attribute values specified on the div element are inherited directly by the lg elements nested within it. Since the met value specifies the metrical form of a single verse line, the structure of the lg as a whole is understood to involve as many repetitions of the pattern as there are lines in the verse paragraph. The same attribute value, when inherited in turn by the l element, must be understood not to repeat. With sufficiently sophisticated software, segments within the line might even be understood as inheriting precisely that portion of the formula which applies to the segment in question; this will, however, be easier to accomplish for some languages than for others.

The rhyme attribute in this example uses the default notation to specify a rhyme scheme applicable only to pairs of lines. As elsewhere, the default notation for the rhyme attribute has no meaning for metrical units at the line level or below. In verse forms where line-internal rhyme is structurally significant, e.g. in some skaldic poetry, the default notation is incapable of expressing the required information, since the rhyme pattern may need to be specified for units smaller than the line. In such cases, a user-specified rhyme notation must be substituted for the default notation, or else the rhyme pattern must be described using some alternative method (e.g. by using the link mechanism described below).

The precise semantics of the met attribute and the inferences which software is expected or able to draw from it, are implementation-dependent; so are the semantics and processing of the rhyme attribute, when user-specified notations are used.

A formal definition of the significance of each component of the pattern given as the value of the met attribute may be provided in the metDecl element within the encodingDesc element in the TEI header (see section 6.5 Metrical Notation Declaration). The encoder is free to invent any notation appropriate to his or her analytic needs, provided that it is adequately documented in this element. The notation may define metrical components using invented or traditional names (such as ‘iamb’ or ‘hexameter’) or in terms of basic units such as codes for stressed or unstressed syllables, or a combination of the two.

The real (for ‘realization’) attribute may optionally be specified to indicate any deviation from the pattern defined by the met attribute which the encoder wishes to record. By default, the real attribute has the same value as the met attribute on the same element; it is only necessary to provide an explicit value when the realization differs in some way from the abstract metrical pattern. The tension between conventional metrical pattern and its realization may thus be recorded explicitly. For example, many readers of the above passage would stress the word ‘But’ at the beginning of the third line rather than the word ‘of’ following it, as the metrical pattern would normally require. This variation might be encoded as follows:
<l real="+-|-+|-+|-+|-+">But, of the two, ...</l>

Where the real attribute is used to over-ride the default or conventional metrical pattern, it applies only to the element on which it is specified. The default pattern for any subsequent lines is unaffected.

As it happens, this particular kind of variation is very common in the English iambic pentameter—it even has a name: trochaic substitution—an encoder might therefore choose to regard this not as an instance of a variant realization, but as an instance of a variant metrical form:
<l met="+-|-+|-+|-+|-+">But, of the two, ...</l>
Alternatively, a different metrical notation might be defined, in which this kind of variation was permitted throughout the text.
In choosing whether to over-ride a metrical specification in this way or by using the real attribute, the encoder is required to determine whether the change is a systematic or conventional one (as in this example) or an occasional variation, perhaps for local effect. In the following example, from Goethe's Auf dem See, the variation is a matter of local realization:
<lg
  type="chevy-chase-stanza"
  met="-+-+-+-+/-+-+-+"
  rhyme="ababcdcd">
 <l n="1"> Und frische Nahrung, neues Blut</l>
 <l n="2" real="+--+-+"> Saug' ich aus freier Welt;</l>
 <l n="3" real="+--+-+-+"> Wie ist Natur so hold und gut,</l>
 <l n="4" real="---+-+"> Die mich am Busen hält!</l>
 <l n="5"> Die Welle wieget unsern Kahn</l>
 <l n="6"> Im Rudertakt hinauf,</l>
 <l n="7"> Und Berge, wolkig himmelan,</l>
 <l n="8"> Begegnen unserm Lauf.</l>
</lg>
On the other hand, the famous inserted alexandrine in Pope's ‘Essay on Criticism’, might be encoded as follows:
<l n="356"> A needless alexandrine ends the song, </l>
<l n="357" met="-+|-+|-+|-+|-+|-+" real="++|-+|-+|+-|++|-+"> That, like a wounded snake, drags its slow length along.
</l>
Here the met attribute indicates that a different metrical convention (the alexandrine) is in force, while the real attribute indicates that there is a variation from that convention. As with many other aspects of metrical analysis, however, this is of necessity an entirely interpretive judgment.

6.3.2 Segment-Level versus Line-level Tagging

The examples given so far have encoded information about the realization of metrical conventions at the level of the whole verse-line. This has obvious advantages of simplicity, but the disadvantage that any deviation from metrical convention is not marked at its precise point of occurrence in the text. Greater precision may be achieved, but only at the cost of marking deviant metrical units explicitly. This may be done with the seg element, giving the variant realization as the value of the real attribute on that element. Using this method, the example given immediately above might be encoded as follows:
<l n="356"> A need<seg type="foot" n="2" real="--">less
   a</seg>lexandrine ends the song,</l>
<l n="357" met="-+|-+|-+|-+|-+|-+">
 <seg n="1" real="++"> That, like </seg> a wounded snake,
<seg n="4" real="+-"> drags its </seg>
 <seg n="5" real="++"> slow length </seg>
along.

</l>
The marking of the foot boundaries with the symbol | in the met attribute value of the l element allows the human reader, or a sufficiently intelligent software program, to isolate the correct portion of that attribute value as the default value for the same attribute on the seg elements for feet, namely -+. It is of course up to the encoder to decide whether or not to include the n attribute of seg here, and whether or not also to tag the feet in the line in which there is no deviation from the metrical convention. The ability of software to infer which foot is being marked, if not all are tagged, will depend heavily on the language of the text and the knowledge of prosody built into the software; the fuller and more explicit the markup, the easier it will be for software to handle it. It may prove useful, however, to mark metrical deviations in the manner shown, even if the available software is not sufficiently intelligent to scan lines without aid from the markup. Human readers who are interested in prosody may well be able to exploit the markup in useful ways even with less sophisticated software.
There are circumstances where it may also be useful to use the met attribute of seg. If we wish to identify the exact location of the different types of foot in the first line of Virgil's Aeneid, the text could be encoded as follows (for simplicity's sake the caesura has been omitted):
<l>
 <seg type="foot" met="+--">Arma vi</seg>
 <seg met="+--">rumque ca</seg>
 <seg met="++">no Tro</seg>
 <seg met="++">iae qui </seg>
 <seg met="+--">primus ab</seg>
 <seg met="++"> oris</seg>
</l>
An appropriate value of the met attribute might also be supplied on the enclosing div element, to indicate that each foot may be made up of a dactyl or a spondee, so that the values given here for met at the level of the foot may be considered a series of local variations on this fundamental pattern; in cases like this, of course, the local variations may also be considered aspects of realization rather than of convention, in which case the real attribute may be used instead of met, if desired.

6.3.3 Metrical Analysis of Stanzaic Verse

The method described above may be used to encode quite complex verse forms, for instance various kinds of fixed-form stanzas. Let us take one of Dante's canzoni, in which each stanza except the last has the same combination of eleven-syllable and seven-syllable lines, and the same rhyme scheme:
<div
  type="canzone"
  met="E/E/S/E/S/E/E/S/E/S/E/S/S/E/S/E/E/S/S/E/E"
  rhyme="abbcdaccbdceeffghhhgg">
 <lg n="1" type="stanza">
  <l n="1">Doglia mi reca nello core ardire</l>
 </lg>
</div>

Here the met attribute specifies a metrical pattern for each of the twenty-one lines making up a stanza of the canzone. Each stanza inherits this definition from the parent div element. The rhyme attribute specifies a rhyme scheme for each stanza, in the same way.

In the metrical notation used here, the letter E represents a line containing nine syllables which may or may not be metrically prominent, a tenth which is prominent and an optional non-prominent eleventh syllable. The letter ‘S’ is used to represent a line containing five syllables which may or may not be metrically prominent, a sixth which is prominent and an optional non-prominent seventh syllable. A suitable definition for this notation might be given by a metDecl element like the following:
<metDecl type="met" pattern="((E|S)/)+)">
 <metSym value="E" terminal="false">xxxxxxxxx+o</metSym>
 <metSym value="S" terminal="false">xxxxx+o</metSym>
 <metSym value="x">metrically prominent or non-prominent</metSym>
 <metSym value="+">metrically prominent</metSym>
 <metSym value="o">optional non prominent</metSym>
 <metSym value="/">line division</metSym>
</metDecl>
As noted above, the metrical pattern specified on the div applies to each lg (stanza) element contained within the div. In fact however, after seven stanzas of this type, there is a final stanza, known as a commiato or envoi, which follows a different metrical and rhyming scheme. The solution to this problem is simply to specify a new met attribute on the eighth stanza itself, which will override the default value inherited from parent div, as follows:
<div met=".....">
 <lg>
  <l> ... </l>
 </lg>
 <lg type="commiato" met="E/S/S/E/S/E/E/S/S/E/E" rhyme="abbccdeeedd">
  <l n="1">Canzone, presso di qui è une donna</l>
 </lg>
</div>

Note that, in the same way as for the real attribute, over-riding of this kind does not affect subsequent elements at the same hierarchic level. Any lg element following the commiato above would be assumed to use the same metrical and rhyming scheme as the one preceding the commiato. Moreover, although it is quite regular (in the sense that the last stanza of each canzone is a commiato), the over-riding must be specified for each case.

6.4 Rhyme

The rhyme attribute is used to specify the rhyme pattern of a verse form. It should not be confused with the rhyme element, which is used to mark the actual rhyming word or words:
  • rhyme Marque la partie rimante d'une ligne métrique.

Like the met attribute, the rhyme attribute can be used with a user-specified notation documented by the metDecl element in the TEI header. Unlike met, however, the rhyme attribute has a default notation; if this default notation is used, no metDecl element need be given.

The default notation for rhyme offers the ability to record patterns of rhyming lines, using the traditional notation in which distinct letters stand for rhyming lines. For a work in rhyming couplets, like the Pope example above, the rhyme attribute simply specifies aa, indicating that pairs of adjacent lines rhyme with each other. For a slightly more complex scheme, applicable to groups of four lines, in which lines 1 and 3 rhyme, as do lines 2 and 4, this attribute would have the value abab. The traditional Spenserian stanza has the pattern ababbcbcc, indicating that within each nine line stanza, lines 1 and 3 rhyme with each other, as do lines 2, 4, 5 and 7, and lines 6, 8 and 9.

Non-rhyming lines within such a group may be represented using a hyphen or an x, as in the following example:
<lg rhyme="aa-a">
 <l>Why, all the Saints and Sages who discuss'd</l>
 <l>Of the Two Worlds so learnedly, are thrust</l>
 <l>Like foolish Prophets forth; their Words to Scorn</l>
 <l>Are scatter'd, and their Mouths are stopt with Dust. </l>
</lg>
The rhyme element may be used to mark the words (or parts of words) which rhyme according to a predefined pattern:
<lg type="couplet" rhyme="aa">
 <l>Outside in the distance a wildcat did <rhyme>growl</rhyme>
 </l>
 <l>Two riders were approaching and the wind began to <rhyme>howl</rhyme>
 </l>
</lg>
The label attribute is used to specify which parts of a rhyme scheme a given set of rhyming words represent:
<lg type="quatrain" rhyme="abab">
 <l>I wander thro' each charter'd <rhyme label="a">street</rhyme>,</l>
 <l>Near where the charter'd Thames does <rhyme label="b">flow</rhyme>,</l>
 <l>And mark in every face I <rhyme label="a">meet</rhyme>
 </l>
 <l>Marks of weakness, marks of <rhyme label="b">woe</rhyme>.</l>
</lg>
<lg rhyme="abab">
 <l>In every cry of every <rhyme label="a">Man</rhyme>
 </l>
 <l>In every Infant's cry of <rhyme label="b">fear</rhyme>,</l>
 <l>In every voice, in every <rhyme label="a">ban</rhyme>,</l>
 <l>The mind-forg'd manacles I <rhyme label="b">hear</rhyme>.</l>
</lg>

Within a given scope, all rhyme elements with the same value for their label attribute are assumed to rhyme with each other: thus, in the above example, the two rhymes labelled a in the first stanza rhyme with each other, but not necessarily with those labelled a in the second stanza. The scope is defined by the nearest ancestor element for which the rhyme attribute has been supplied.

The rhyme element can appear anywhere within a verse line, and not necessarily around a single word. It can thus be used to mark quite complex internal rhyming schemes, as in the following example:
<lg rhyme="ABCCBBA">
 <l>The sunlight on the <rhyme label="A">garden</rhyme>
 </l>
 <l>
  <rhyme label="A">Harden</rhyme>s and grows <rhyme label="B">cold</rhyme>,</l>
 <l>We cannot cage the <rhyme label="C">minute</rhyme>
 </l>
 <l>Wi<rhyme label="C">thin it</rhyme>s nets of <rhyme label="B">gold</rhyme>
 </l>
 <l>When all is <rhyme label="B">told</rhyme>
 </l>
 <l>We cannot beg for <rhyme label="A">pardon</rhyme>.</l>
</lg>

This mechanism, although reasonably simple for simple cases, may not be appropriate for more complex applications. In general, rhyme may be considered as a special form of ‘correspondence’, and hence encoded using the mechanisms defined for that purpose in section 16.4 Correspondence and Alignment. Similar considerations apply to other metrical features such as alliteration or assonance.

To use the correspondence mechanisms to represent the complex rhyming pattern of the above example, each rhyme element must be given a unique identifier, as follows:
<lg rhyme="AB-BBA">
 <l>The sunlight on the <rhyme xml:id="V-A1">garden</rhyme>
 </l>
 <l>
  <rhyme xml:id="V-A2">Harden</rhyme>s and grows <rhyme xml:id="V-B1">cold,</rhyme>
 </l>
 <l>We cannot cage the <rhyme xml:id="V-C1">minute</rhyme>
 </l>
 <l>Wi<rhyme xml:id="V-C2">thin it</rhyme>s nets of <rhyme xml:id="V-B2">gold</rhyme>
 </l>
 <l>When all is <rhyme xml:id="V-B3">told</rhyme>
 </l>
 <l>We cannot beg for <rhyme xml:id="V-A3">pardon</rhyme>.</l>
</lg>
Now that each rhyming word, or part-word, has been tagged and allocated an arbitrary identifier, the general purpose link element may be used to indicate which of the rhyme elements share the same rhyme, as follows:
<linkGrp type="rhyme">
 <link target="#V-A1 #V-A2 #V-A3"/>
 <link target="#V-B1 #V-B2 #V-B3"/>
 <link target="#V-C1 #V-C2"/>
</linkGrp>

For further discussion of the link and linkGrp element, see section 16.4 Correspondence and Alignment.

The rhyme and caesura phrase level elements are made available by the model.lPart class when the module defined by this chapter is included in a schema.

6.5 Metrical Notation Declaration

When the module defined in this chapter is included in a schema, a specialized element is optionally available in the encodingDesc element of the TEI Header to document the metrical notation used in marking up a text.
  • metDecl (déclaration sur la métrique) documente la notation utilisée pour noter un modèle métrique lorsque celui-ci est spécifié comme la valeur des attributs met , real, ou rhyme, qui s’appliquent à tout élément de la structure d’un texte versifié (par exemple lg, l, ou seg).
    pattern (modèle d'expression régulière) indique une expression régulière définissant toute valeur permise dans cette notation.
  • metSym (Symbole de notation métrique.) documente le sens propre à un caractère particulier ou à une suite de caractères dans une notation métrique, exprimés soit explicitement, soit dans les termes d’autres éléments inclus dans le même élément metDecl.
    valueindique le caractère ou l'ordre des caractères documentés.
    terminalindique si le symbole est défini à l’aide d’autres symboles, (l'attribut terminal a pour valeur false), ou rédigé en texte libre, (l'attribut terminal a pour valeur true).
As with other components of the header, metrical notation may be specified either formally or informally. In a formal specification, every symbol used in the metrical notation must be documented by a corresponding metSym element; in an informal one, only a brief prose description of the way in which the notation is used need be given. In either case, the optional pattern attribute may be used to supply a regular expression which a processor can use to validate expressions in the intended notation. The following constraints apply:
  • if pattern is supplied, any notation used which does not conform to it should be regarded as invalid
  • if any metSym is defined, then any notation using undefined symbols should be regarded as invalid
  • if both pattern and symbol are defined, then every symbol appearing explicitly within pattern must be defined
  • symbols which are not matched by pattern may be defined within a metDecl element
As a simple example, consider the case of the notation in which metrical prominence, metrical feet, and line boundaries are all to be encoded. Legal specifications in this notation may be written for any sequence of metrically prominent or non-prominent features, optionally separated by foot or metrical line boundaries at arbitrary points. Assuming that the symbol 1 is used for metrical prominence, 0 for non-prominence, | for foot boundary and / for line boundary, then the following declaration achieves this object:
<metDecl pattern="((1|0)+\|?/?)*">
 <metSym value="1">metrical prominence</metSym>
 <metSym value="0">metrical non-prominence</metSym>
 <metSym value="|">foot boundary</metSym>
 <metSym value="/">metrical line boundary</metSym>
</metDecl>
The same notation might also be specified less formally, as follows:
<metDecl>
 <p>Metrically prominent syllables are marked '1' and other
   syllables '0'. Foot divisions are marked by a vertical bar,
   and line divisions with a solidus.</p>
 <p>This notation may be applied to any metrical unit, of any
   size (including, for example, individual feet as well as
   groups of lines).</p>
</metDecl>
Note that in this case, because the pattern attribute has not been supplied, no processor can validate met attribute values within the text which use this metrical notation.
For more complex cases, it will often be more convenient to define a notation incrementally. The terminal attribute should be used to indicate for a given symbol whether or not it may be re-defined in terms of other symbols used within the same notation. For example, here is a notation for encoding classical metres, in which symbols are provided for the most common types of foot. These symbols are themselves documented within the same notation, in terms of more primitive long and short syllables:
<metDecl pattern="[DTIS3A]+">
 <metSym n="dactyl" value="D" terminal="false">-oo</metSym>
 <metSym n="trochee" value="T" terminal="false">-o</metSym>
 <metSym n="iamb" value="I" terminal="false">o-</metSym>
 <metSym n="spondee" value="S" terminal="false">--</metSym>
 <metSym n="tribrach" value="3" terminal="false">ooo</metSym>
 <metSym n="anapaest" value="A" terminal="false">oo-</metSym>
 <metSym value="o">short syllable</metSym>
 <metSym value="-">long syllable</metSym>
</metDecl>
Note here the use of the global n attribute to supply an additional name for the symbols being documented.

Where an encoder wishes to use more than one different pattern for metrical notation, multiple metDecl elements may be included in the encodingDesc, each supplied with an xml:id. The decls attribute may be used in the text of the document to specify which metDecl is in force at a particular point in the text. In this example, two metDecls are defined in the header, one with an English verse pattern and one with a French pattern. In the body of the document, there are two div elements, one declaring the English pattern and one the French:

<encodingDesc>
<!-- ... -->
 <metDecl xml:id="md_en" type="met" pattern="((SU|US)USUSUSUS/)">
  <metSym value="S">stressed syllable</metSym>
  <metSym value="U">unstressed syllable</metSym>
  <metSym value="/">metrical line boundary</metSym>
 </metDecl>
 <metDecl xml:id="md_fr" type="met" pattern="(AAAAAT\|AAAAT(A)?)">
  <metSym value="T">syllabe tonique</metSym>
  <metSym value="A">syllabe atone</metSym>
  <metSym value="|">pause métrique</metSym>
 </metDecl>
<!-- ... -->
</encodingDesc>
<!-- ... -->
<body>
 <div decls="#md_en">
  <lg>
   <l>
<!-- ... -->
   </l>
<!-- ... -->
  </lg>
 </div>
 <div decls="md_fr">
  <lg>
   <l>
<!-- ... -->
   </l>
<!-- ... -->
  </lg>
 </div>
</body>

6.6 Encoding Procedures for Other Verse Features

A number of procedures that may be of particular concern to encoders of verse texts are dealt with elsewhere in these guidelines. Some aspects of layout and physical appearance, especially important in the case of free verse, are dealt with in chapter 11 Representation of Primary Sources. Some initial recommendations for the encoding of phonetic or prosodic transcripts, which may be helpful in the analysis of sound structures in poetry, are to be found in chapter 8 Transcriptions of Speech; it may also be found convenient to use standard entity names (those proposed for the International Phonetic Alphabet suggest themselves) to mark positions of suprasegmentals such as primary and secondary stress, or other aspects of accentual structure.

As already indicated, chapter 16 Linking, Segmentation, and Alignment contains much which will be found useful for the aligning of multiple levels of commentary and structure within verse analysis. Encoders of verse (as of other types of literary text) will frequently wish to attach identifying labels to portions of text that are not part of a system of hierarchical divisions, may overlap with one another, and/or may be discontinuous; for instance passages associated with particular characters, themes, images, allusions, topoi, styles, or modes of narration. Much of the computerized analysis of verse seems likely to require dividing texts up into blocks in this way. The span element discussed in 17.3 Spans and Interpretations provides the means for doing this. Finally, the procedures for the tagging of feature structures, described in chapter 18 Feature Structures, provide a powerful means of encoding a wide variety of aspects of verse literature, including not only the metrical structures discussed above, but also such stylistic and rhetorical features as metaphor.

For other features it must for the time being be left to encoders to devise their own terminology. Elements such as <metaphor tenor="..." vehicle="..."> ... </metaphor> might well suggest themselves; but given the problems of definition involved, and the great richness of modern metaphor theory, it is clear that any such format, if predefined by these Guidelines, would have seemed objectionable to some and excessively restrictive to many. Leaving the choice of tagging terminology to individual encoders carries with it one vital corollary, however: the encoder must be utterly explicit, in the TEI header, about the methods of tagging used and the criteria and definitions on which they rest. Where no formal elements are currently proposed, such information may readily be given as simple prose description within the encodingDesc element defined in section 2.3 The Encoding Description.

6.7 Module for Verse

The module described in this chapter makes available the following components:
Module verse: Poésie
The selection and combination of modules to form a TEI schema is described in 1.2 Defining a TEI Schema.
↑ TEI P5 Guidelines « 5 Representation of Non-standard Characters and Glyphs » 7 Performance Texts
Notes
23
For discussion of other attributes of this class, see 4.1.4 Partial and Composite Divisions.
↵
24
As elsewhere in these Guidelines, this example has been formatted for clarity of exposition rather than correct display. Note in particular that whether an XML processor retains whitespace within the seg element or not (this can be configured by means of the xml:space attribute) this example will still require additional processing, since white space should be retained for the lower level seg elements (those of type syll) but not for the higher level one (those of type foot).
↵

[English] [Deutsch] [Español] [Italiano] [Français] [日本語] [한국어] [中文]

TEI Consortium | Commentaires

TEI material can be licensed differently depending on the use you intend to make of it. Hence it is made available under both the CC+BY and BSD-2 licences. The CC+BY licence is generally appropriate for usages which treat TEI content as data or documentation. The BSD-2 licence is generally appropriate for usage of TEI content in a software environment. For further information or clarification, please contact the TEI Consortium.

  1. http://creativecommons.org/licenses/by/3.0/
  2. http://www.opensource.org/licenses/BSD-2-Clause

TEI Guidelines Version 2.1.0. Last updated on 17th June 2012. This page generated on 2012-06-18T16:38:45Z