This chapter describes methods for encoding textual content with MEI. It is divided into section: One part deals with Text Structures in MEI, the other with Text in MEI. While the first covers structures of textual documents such as front- and backmatter, the latter describes how to mark up features and various entities within a text, such as names, tables or quotes. These features may appear both within data (a figure scribbled as marginal annotation into a score by a bored second violin…) and metadata (a number of dates within a text about the creation of a work). Accordingly, many of the elements and models explained in this chapter are used to encode Metadata in MEI. However, they should not be confused with the elements from the Lyrics and Performance Directions chapter, which deals with performed text in MEI.
Most of the elements described here take inspiration from encoding formats that deal primarily with text, such as HTML and the Text Encoding Initiative (TEI). These elements are provided to encode relatively basic textual information. For deeper encoding of text, these Guidelines recommend consideration of other text-specific encoding formats with embedded MEI markup.
This chapter focuses on the text that accompanies the score, i.e., paratext (prefatory material, back matter, appendices, etc.).
Text can be organized in different parts, for example in chapters or sections. The div element is used to encode such structural divisions.
For example, printed scores, before the actual notation, can have text that can be organized in multiple sections (e.g. a preface, a critical report, performance instructions, etc. for which see the following sections); each of these sections should be identified by a different div element. Text might also occur in between music sections (see Content of Musical Divisions), for example in a collection of romantic piano works, a few pieces might be preceded or followed by poetry. Such text should be encoded with the div element, as demonstrated in the following example:
<mdiv>
<score>
<section>
<!-- Score of Franz Liszt’s "Sonetto 104 del Petrarca -->
</section>
<div>
<!-- Text of Francesco Petrarca’s Sonett n. 104. -->
<lg>
<l>L'aspectata vertù, che 'n voi fioriva</l>
<l>quando Amor cominciò darvi bataglia,</l>
<!-- ... -->
</lg>
</div>
</score>
</mdiv>Textual divisions may have titles or other forms of introductory material, which are encoded with the head element.
The following example shows the encoding of a preface translated into three different languages, each with a different heading:
<front>
<div xml:lang="en">
<head>Preface</head>
<!-- text -->
</div>
<div xml:lang="de">
<head>Vorwort</head>
<!-- text -->
</div>
<div xml:lang="it">
<head>Prefazione</head>
<!-- text -->
</div>
</front>Having said that div identifies any structural organization of text, it is often helpful to distinguish the typology of division. The @type attribute can be used for this purpose.
@type may contain any number of space-separated tags describing the nature of the div (or, in fact, any other element). The following example shows the use of @type (in combination with @n) to indicate three prefaces in English, German and Italian are columns on the same page.
<front>
<div n="1" type="column" xml:lang="en">
<head>
Preface
</head>
<!-- text -->
</div>
<div n="2" type="column" xml:lang="de">
<head>Vorwort</head>
<!-- text -->
</div>
<div n="3" type="column" xml:lang="it">
<head>Prefazione</head>
<!-- text -->
</div>
<pb></pb>
</front>This section introduces paratextual material, such as title pages, prefaces, indexes and other text that precedes or follows the actual score.
By ‘front matter’ these Guidelines mean distinct sections of a text (usually, but not necessarily, a printed one), prefixed to it by way of introduction or identification as a part of its production. Features such as title pages or prefaces are clear examples; a less definite case might be the prologue attached to a dramatic work. The front matter of an encoded text should not be confused with the MEI header described in chapter , which provides metadata for the entire file.
An encoder may choose simply to ignore the front matter in a text, if the original presentation of the work is of no interest. No specific tags are provided for the various kinds of subdivision which may appear within front matter: instead, generic div (“division”) elements may be used, which should not be confused with mdiv (“musical division”) elements. The following suggested values for the @type attribute may be used to distinguish various kinds of division characteristic of front matter:
‘preface’: A foreword or preface addressed to the reader in which the author or publisher explains the content, purpose, or origin of the text.
‘ack’: A formal declaration of acknowledgement by the author in which persons and institutions are thanked for their part in the creation of a text.
‘dedication’: A formal offering or dedication of a text to one or more persons or institutions by the author.
‘abstract’: A summary of the content of a text as continuous prose.
‘contents’: A table of contents, specifying the structure of a work and listing its constituents. The list element should be used to mark its structure.
‘frontispiece’: A pictorial frontispiece, possibly including some text.
The following extended example demonstrates how various parts of the front matter of a text may be encoded. The front part begins with a title page, which is presented in section Title Pages, below. This is followed by a dedication and a preface, each of which is encoded as a distinct div:
<front>
<titlePage>
<!-- transcription of title page -->
</titlePage>
<div type="dedication">
<p>
<!-- Dedicatory text -->
</p>
</div>
<div type="preface">
<head>
Preface
</head>
<p>
<!-- paragraph 1 -->
</p>
<p>
<!-- paragraph 2 -->
</p>
<!-- additional material -->
</div>
</front>The front matter concludes with another div element, shown in the next example, this time containing a table of contents, which contains a list element (as described in chapter Lists). Note the use of the ptr element to provide page-references: the implication here is that the target identifiers (song1, song2, etc.) will correspond with identifiers used for the mdiv elements containing the individual songs. (For a description of the ptr element, see chapter Pointers and References.)
<div type="contents">
<head>
Contents
</head>
<list form="ordered">
<li>On Wenlock Edge
<ptr target="#song1"/>
</li>
<li>From Far, From Eve and Morning
<ptr target="#song2"/>
</li>
<li>Is My Team Ploughing?
<ptr target="#song3"/>
</li>
<li>Oh, When I Was In Love With You
<ptr target="#song4"/>
</li>
<li>Bredon Hill
<ptr target="#song5"/>
</li>
<li>Clun
<ptr target="#song6"/>
</li>
</list>
</div>Alternatively, the pointers in the table of contents might link to the page breaks at which a song begins, assuming that these have been included in the markup:
<list form="ordered">
<li>On Wenlock Edge
<ref target="#song1-p1">1</ref>
</li>
<li>From Far, From Eve and Morning
<ref target="#song2-p15">15</ref>
</li>
<!-- .... -->
</list>
<!-- Later in the document -->
<mdiv type="song">
<pb xml:id="song1-p1"/>
<!-- .... -->
</mdiv>
<mdiv type="song">
<pb xml:id="song2-p15"/>
<!-- .... -->
</mdiv>
<!-- .... -->Conventions vary as to which elements are grouped as back matter and which as front. For example, some books place the table of contents at the front, and others at the back. For this reason, the content models of the front and back elements are identical.
The following suggested values may be used for the @type attribute on all division elements, in order to distinguish various kinds of divisions characteristic of back matter:
‘appendix’: An ancillary self-contained section of a work, often providing additional but in some sense extra-canonical text.
‘glossary’: A list of terms associated with definition texts (‘glosses’).
‘notes’: A section in which textual notes are gathered together.
‘bibliography’: A list of bibliographic citations.
‘index’: Any form of index to the work.
‘colophon’: A statement appearing at the end of a book describing the conditions of its physical production.
No additional elements are proposed for the encoding of back matter at present. Some characteristic examples follow; first, an index (for the case in which a printed index is of sufficient interest to merit transcription):
<back>
<div type="index">
<head>
Index
</head>
<list type="index">
<li>a2, a3, etc., 175-176</li>
<li>Abbreviations, 3
<list type="index">
<li>Percussion, 205-213</li>
<li>Strings, 307</li>
</list>
</li>
<li>Afterbeats, 77</li>
</list>
</div>
</back>Note that if the page breaks in the original source have also been explicitly encoded, and given identifiers, the references to them in the above index can more usefully be recorded as links. For example, assuming that the encoding of page 77 of the original source starts like this:
<pb xml:id="text.P77"/>then the last item above might be encoded more usefully in the following form:
<li>Afterbeats,
<ref target="#text.P77">77</ref>
</li>This chapter describes methods for encoding textual content with MEI. Textual information on scores has several different uses, although some text is closer to music notation than other kinds. For example, tempo marks, directives and lyrics are directly related to the functionality of the notated music and are, therefore, described in other chapters (see for example Vocal Text and Text Directives).
Most of the elements described here take inspiration from encoding formats that deal primarily with text, such as HTML and the Text Encoding Initiative (TEI). These elements are provided to encode relatively basic textual information. For deeper encoding of text, these Guidelines recommend consideration of other text-specific encoding formats with embedded MEI markup.
Paragraphs are fundamental to prose text and typically group one or more sentences that form a logical passage. Usually, it is typographically distinct; that is, it usually begins on a new line and the first letter of the content is often indented, enlarged, or both. This element has a similar meaning as the corresponding elements in Encoded Archival Description (EAD), Text Encoding Initiative (TEI), and HTML.
A paragraph is encoded with the p element:
Prose text is used for several different purposes within a MEI document, therefore p can occur in many situations. For example, it may be used within metadata elements (see ):
<samplingDecl>
<p>The encoding contains only the first 5 measures.</p>
</samplingDecl>Alternatively, paragraphs may be part of the document contents (and therefore encoded within music), either as Paratext or within the music notation. In these cases, a paragraph will likely be contained by a div or other elements containing prose (e.g. annot, figDesc, etc.).
The following example shows a paragraph in a preface section:
<front>
<div>
<head>
The Preludes<lb/>
Symphonic Poem No.3 by F. Liszt.
</head>
<p>What else is our life but a series of preludes to that unknown Hymn, the first and
solemn note of which is intoned by Death?
</p>
</div>
</front>Sometimes, it is desirable to capture the typographical qualities of a word or phrase without assigning it a special meaning. For this purpose, MEI offers the rend element, similar to TEI’s hi element. Using CSS-like values, its @rend attribute can be used to specify many typographic features, such as font style, font variants, and relative font size and weight. In addition, text decoration, direction, and enclosing ‘boxes’ may be captured. While @rend is used to record relative font size and weight, absolute values for these qualities (measured in printer’s points) should be specified using the @fontsize and @fontweight attributes. In addition to commonly found typographical qualities, MEI provides the @altrend attribute for the capture of additional, user-defined rendition information.
The fig element groups elements representing or containing graphic information such as an illustration or figure. This element is modelled on the figure element in the Text Encoding Initiative (TEI). The fig element is used to contain images, captions, and textual descriptions of the pictures. The images themselves are specified using the graphic element, whose @target attribute provides the location of an image. For example:
<fig>
<graphic target="../samples/snippets/mei2012-30shortexamples/beam-grace/grace-300.png"/>
</fig>The graphic element may occur multiple times within the markup of the figure in order to indicate the availablity of different image formats or resolutions:
<fig>
<graphic target="../samples/snippets/mei2012-30shortexamples/beam-grace/grace-72.png"/>
<graphic target="../samples/snippets/mei2012-30shortexamples/beam-grace/grace-300.png"/>
<graphic target="../samples/snippets/mei2012-30shortexamples/beam-grace/grace-600.png"/>
</fig>The element caption may be used to transcribe (or supply) a title or descriptive heading for the graphic itself, as in the following example:
<fig>
<caption>Grace notes</caption>
<graphic target="../samples/snippets/mei2012-30shortexamples/beam-grace/grace-300.png"/>
</fig>The figure description ( figDesc) element usually contains a brief prose description of the appearance or content of a graphic figure, for use when documenting an image, perhaps without displaying it. This element is intended for use as an alternative to the content of its parent fig element; for example, for display when the equipment in use cannot display graphic images. It may also be used for indexing or documentary purposes, in which case best practice suggests the use of controlled vocabulary terms.
<fig>
<graphic target="emblem1.png"/>
<caption>Emblemi d'Amore</caption>
<figDesc>A pair of naked winged cupids, each holding a flaming torch, in a rural setting.</figDesc>
</fig>Occasionally, a figure description may have a complex structure. In this case, one or more textual component elements ( p [paragraph], table, list, quote, or lg [linegroup]) may be used to model the internal structure of the description:
<fig>
<caption>Grace notes</caption>
<figDesc>
<p>The example shows grace notes within beams ...</p>
<p>This illustration was created by ...</p>
</figDesc>
<graphic target="../samples/snippets/mei2012-30shortexamples/beam-grace/grace-300.png"/>
</fig>The graphic element indicates the location of an inline graphic, illustration, or figure. As noted above, there exists a wide variety of different graphics formats, and the following list is in no way exhaustive. Moreover, inclusion of any format in this list should not be taken as indicating endorsement by the MEI of this format or any products associated with it. Some of the formats listed here are proprietary to a greater or lesser extent and cannot therefore be regarded as standards in any meaningful sense. They are, however, widely used by many different vendors. The following formats are widely used at the present time, and are likely to remain supported by more than one vendor’s software:
Brief descriptions of all the above are given below. Where possible, current addresses or other contact information are shown for the originator of each format. Many formal standards, especially those promulgated by the ISO and many related national organizations (ANSI, DIN, BSI, and many more), are available from those national organizations. Addresses may be found in any standard organizational directory for the country in question.
SVG: Scalable Vector Graphics format: SVG is a language for describing two-dimensional vector and mixed vector or raster graphics in XML. It is defined by the Scalable Vector Graphics (SVG) 1.0 Specification, W3C Recommendation, 04 September 2001, available at http://www.w3.org/TR/2001/REC-SVG-20010904/.
PICT: Macintosh drawing format: This format is universally supported on Macintosh (tm) systems, and readable by a limited range of software for other systems. Documentation is available from Apple Computer, Cupertino, California USA.
CGM: Computer Graphics Metafile: This vector graphics format is specified by an ISO standard, ISO 8632:1987, amended in 1990. It defines binary, character, and plain-text encodings; the non-binary forms are safer for blind interchange, especially over networks. Documentation is available from ISO and from its member national bodies, such as AFNOR, ANSI, BSI, DIN, JIS, etc.
PNG: Portable Network Graphics format: PNG is a non-proprietary raster format currently widely available. It provides an extensible file format for the losslessly compressed storage of raster images. Indexed-color, grayscale, and true-color images are supported, plus an optional alpha channel. Sample depths range from 1 to 16 bits. It is defined by IETF RFC 2083, March 1997.
TIFF: Tagged Image File Format: Currently the most widely supported raster image format, especially for black and white images, TIFF is also one of the few formats commonly supported on more than one operating system. The drawback to TIFF is that it actually is a wrapper for several formats, and some TIFF-supporting software does not support all variants. TIFF files may use LZW, CCITT Group 4, or PackBits compression methods, or may use no compression at all. Also, TIFF files may be monochrome, greyscale, or polychromatic. All such options should be specified in prose at the end of the encodingDesc section of the MEI header for any document including TIFF images. TIFF is owned by Aldus Corporation. Documentation on TIFF is available from the owner at Craigcook Castle, Craigcook Road, Edinburgh EH4 3UH, Scotland, or 411 First Avenue South, Seattle, Washington 98104 USA.
GIF: Graphics Interchange Format: Raster images are widely available in this form, which was created by CompuServe Information Services, but has by now been implemented for many other systems as well. Documentation is copyright by, and is available from, CompuServe Incorporated, Graphics Technology Department, 5000 Arlington Center Boulevard, Columbus, Ohio 43220 USA.
PBM: Portable Bit Map: PBM files are easy to process, eschewing all compression in favor of transparency of file format. PBM files can, of course, be compressed by generic file-compression tools for storage and transfer. Public domain software exists which will convert many other formats to and from PBM. Documentation of PBM is copyright by Jeff Poskanzer, and is available widely on the Internet.
PCX: IBM PC raster format: This format is used by most IBM PC paint programs, and supports both monochrome and polychromatic images. Documentation is available from ZSoft Corporation, Technical Support Department, ATTN: Technical Reference Manual, 450 Franklin Rd. Suite 100, Marietta, GA 30067 USA.
BMP: Microsoft bitmap format: This format is the standard raster format for computer using Microsoft Windows (tm) or Presentation Manager (tm). Documentation is available from Microsoft Corporation.
JPEG: Joint Photographic Experts Group: This format is sponsored by CCITT and by ISO. It is ISO/IEC Draft International Standard 10918-1, and CCITT T.81. It handles monochrome and polychromatic images with a variety of compression techniques. JPEG per se, like CCITT Group IV, must be encapsulated before transmission; this can be done via TIFF, or via the JPEG File Interchange Format (JFIF), as commonly done for Internet delivery.
Photo-CD: Kodak Photo Compact Disk format: This format was introduced by Kodak for rasterizing photographs and storing them on CD-ROMs (about one hundred 35mm file images fit on one disk), for display on televisions or CD-I systems. Information on Photo-CD is available from Kodak Limited, Research and Development, Headstone Drive, Harrow, Middlesex HA1 4TY, UK.
When a text contains lists, they can be encoded with the following elements:
The list element can identify any kind of list; the @form attribute can be used to specify whether the list is ordered, unordered etc. Each item in the list is encoded with the li element. The @n can be used to record a label for a list item, as in the following example:
<p>The modulation follows the following steps:
<list form="ordered">
<li n="1">C major</li>
<li n="2">A minor</li>
<li n="3">D major seventh</li>
<li n="4">G major</li>
</list>
</p>Occasionally, lists have headers or titles, which can be encoded with head:
<list>
<head>
Ornaments in different languages
</head>
<li n="English" xml:lang="en">Turn</li>
<li n="Italian" xml:lang="it">Gruppetto</li>
<li n="French" xml:lang="fr">Gruppetto</li>
<li n="German" xml:lang="de">Doppelschlag</li>
</list>The element table contains text displayed in tabular form, i.e., in rows and columns. A table is the least ‘graphic’ of the elements discussed in this chapter. Almost any text structure can be presented as a series of rows and columns: one might, for example, choose to show a glossary or other form of list in tabular form, without necessarily regarding it as a table. When tabular presentation is regarded as of less intrinsic importance, it is correspondingly simpler to encode descriptive or functional information about the contents of the table, for example to identify one cell as containing a name and another as containing a date, though the two methods may be combined.
The table element may appear both within other components (such as paragraphs), or between them, provided that the module defined in this chapter has been enabled. It is to a large extent arbitrary whether a table should be regarded as a series of rows or as a series of columns. For compatibility with currently available systems, however, these Guidelines require a row-by-row description of a table.
While rows and columns are always encoded in top-to-bottom, left-to-right order, formatting properties such as those provided by CSS may be used to specify that they should be displayed differently.
The tr (table row) element is a formatting element that contains one or more td or th elements (cells) in a table. A cell is the intersection of a row and a column. The precise rendition of the table and its cells should be specified in a style steet.
<table>
<tr>
<th colspan="7">Besetzungen der Triosonate und ihrer Nachfolger</th>
</tr>
<tr>
<td></td>
<td>Triosonate
<lb></lb>Standardbes.
</td>
<td>Triosonate für
<lb></lb>Orgel (Bach)
</td>
<td>Sonate mit obl.
<lb></lb>Cembalo (Bach)
</td>
<td>Klaviertrio</td>
<td>Streichquartett</td>
<td>Streichtrio</td>
</tr>
<tr>
<td>1. Oberstimme</td>
<td>1. Violine</td>
<td>Orgel r.H.</td>
<td>Violine
<lb></lb>(Flöte, Gambe)
</td>
<td>Violine</td>
<td>1. Violine</td>
<td>1. Violine</td>
</tr>
<tr>
<td>2. Oberstimme</td>
<td>2. Violine</td>
<td>Orgel l.H.</td>
<td>Cembalo r.H.</td>
<td>Klavier r.H.</td>
<td>2. Violine</td>
<td></td>
</tr>
<tr>
<td>harmonische Füllung</td>
<td>Cembalo r.H.</td>
<td></td>
<td></td>
<td></td>
<td>Bratsche</td>
<td>Bratsche</td>
</tr>
<tr>
<td>Bass-Stimme</td>
<td>Cello</td>
<td>Orgel Pedal</td>
<td>Cello</td>
<td>Cello</td>
<td>Cello</td>
<td>Cello</td>
</tr>
</table>The td (table data) element designates a table cell that contains data as opposed to a cell that contains column or row heading information. The @colspan and @rowspan attributes provide tabular rendering information. They indicate that a particular cell or row of a table spans more than one row or column.
<table>
<tr>
<td colspan="2" rowspan="2">unmittelbares Schlagen</td>
<td colspan="2" rowspan="2">mittelbares Schlagen</td>
</tr>
<tr>
<td>Gegenschlag</td>
<td>Aufschlag</td>
<td>Schütteln</td>
<td>Schrapen</td>
</tr>
<tr>
<td>1. Stäbe</td>
<td>1. Stäbe</td>
<td>1. Rahmen</td>
<td>1. Raspeln</td>
</tr>
<tr>
<td>2. Platten</td>
<td>2. Röhren</td>
<td>2. Gefäße</td>
<td>2. Räder</td>
</tr>
<tr>
<td></td>
<td>3. Platten</td>
<td>3. Reihen</td>
<td></td>
</tr>
<tr>
<td></td>
<td>4. Gefäße</td>
<td></td>
<td></td>
</tr>
</table>The th (table header) element designates a table cell containing column or row heading information as opposed to one containing data. The @colspan and @rowspan attributes tabular display rendering information. They indicate that a particular cell or row of a table spans more than one row or column.
<table>
<tr>
<th colspan="4">Systematische Einteilung der Idiophone</th>
</tr>
<tr>
<td colspan="2">unmittelbares Schlagen</td>
<td colspan="2">mittelbares Schlagen</td>
</tr>
<tr>
<td>Gegenschlag</td>
<td>Aufschlag</td>
<td>Schütteln</td>
<td>Schrapen</td>
</tr>
<tr>
<td>1. Stäbe</td>
<td>1. Stäbe</td>
<td>1. Rahmen</td>
<td>1. Raspeln</td>
</tr>
<tr>
<td>2. Platten</td>
<td>2. Röhren</td>
<td>2. Gefäße</td>
<td>2. Räder</td>
</tr>
<tr>
<td></td>
<td>3. Platten</td>
<td>3. Reihen</td>
<td></td>
</tr>
<tr>
<td></td>
<td>4. Gefäße</td>
<td></td>
<td></td>
</tr>
</table>It is common, in many types of texts, to find quotations. A quotation is typically attributed to another text other than the one being encoded. Often, the quoted material is typographically distinct from the surrounding text; i.e., surrounded by so-called ‘quote marks’ or rendered as a separate block of text. The quote element is used to mark this function:
The following examples show the use of quote.
<p>Hugh MacDonald has argued that Liszt’s Symphonic Poems were meant to
<quote>display the traditional logic of symphonic thought</quote>.
</p><p>The majority of the works represented in this catalogue were purchased in Paris and
London between 1928 and 1934. After graduating from Harvard in 1924, Mackay-Smith
spent several years in Europe:
<quote>
<p>I bought my first early music from Harold Reeves in London in the summer of 1928 when
I was able to acquire virtually all the 18th century editions, particularly of trio
music, which he then had in stock, going back not only through his current but also
through earlier catalogues, picking out numbers which remained unsold. It is almost
a shame today to think of the prices at which such things were then available, one
or two pounds apiece.
</p>
</quote>
</p>This lg (line group) element is used generically to encode any section of text that is organized as a group of lines. Following the recommendations of the Text Encoding Initiative, it is recommended to use it, along with the following elements, for marking up poetry:
Because lg groups verses, it can be used to encode additional stanzas not integrated into the music notation. In addition, it is common for a poem to include a title or a header, as is demonstrated by the following example:
<mdiv>
<score>
<section>
<!-- Score of Franz Liszt’s "Sonetto 104 del Petrarca" -->
</section>
<div>
<!-- Text of Francesco Petrarca’s Sonett n. 104. -->
<lg>
<head>
Sonetto 104
</head>
<l>L'aspectata vertù, che 'n voi fioriva</l>
<l>quando Amor cominciò darvi bataglia,</l>
<l>produce or frutto, che quel fiore aguaglia,</l>
<l>et che mia speme fa venire a riva.</l>
<!-- ... -->
</lg>
</div>
</score>
</mdiv>This chapter describes the MEI module used for the encoding of names (names of persons or corporations/organizations) or descriptive phrases for styles, periods or geographical indications.
The chapter begins by discussing the elements provided for the encoding of names ( name) in general and finishes by addressing more specific elements for corporate names ( corpName), geographic names ( geogName), period names ( periodName), personal names ( persName) and style names ( styleName). In general it is recommended to use standardized forms of proper nouns and to record the names and web-accessible locations of the controlled vocabularies used. There are several commonly-referenced authority files, especially for geographical, organizational and personal names, such as the Gemeinsame Normdatei (GND), the Library of Congress Authorities, the Getty Thesaurus of Geographic Names (TGN), and the MARC code list for relators. Recommendations on which standards could be used can be found in the descriptions of the individual elements.
The basic element for capturing names and is defined in the shared module:
The name element contains the name of an entity that is difficult to tag more specifically as a corpName, geogName, persName, or title. The name element may be used in place of the more specific elements when it is not known what kind of name is being described or when a high degree of precision is not necessary. For example, the name element might be used when it is not clear whether the name “Bach” refers to a person or a geographic feature. When name parts are needed, use name sub-elements. The recommended values for the @type attribute are:
‘pers’: a personal name
‘corp’: the name of a corporate entity
‘place’: a geographic name
‘process’: the name of a process or mechanical agent
Examples of the use of the @type attribute within the name element:
<p>
<name type="pers">Henry VIII, King of England</name>
<name type="corp">The Beatles</name>
<name type="place">Orbach</name>
<name type="process">OMR software</name>
</p>The date sub-element is available within name in order to record any dates associated with the name, for example, creation and dissolution in the case of a corporate entity or place or birth and death dates in the case of an individual. The name of the list from which a controlled value is taken, such as the Library of Congress Name Authority File (LCNAF), may be recorded using the @auth attribute.
In addition to the generic name and date elements provided by the shared module, the namesDates module provides for the markup of the specialized cases described below.
Corporate names are non-personal names which refer to structured bodies of one or more persons that act as a single entity. Typical examples include associations, businesses, projects or institutions (e.g., ‘the Royal College of Music’ or ‘the BBC’), but political factions or other groupings where these are regarded as forming a single agency. Organization names typically include some type of indicator or pattern or words that help identify them as non-personal names.
The corpName element is frequently used within the of an MEI document. It is typically found in the respStmt element:
<respStmt>
<corpName>Library of Congress</corpName>
</respStmt>It may also be used wherever it is necessary to mark a corporate name, for example when a corporation is responsible for a certain event in the history of a musical work:
<history>
<eventList>
<event>
<p>First performance by
<corpName>The Boston Symphony Orchestra</corpName>,
<date>October 22, 1881</date>.
</p>
</event>
</eventList>
</history>When it is necessary to provide structure for a name, the separate parts of the name may be encoded in corpName sub-elements, for example:
<corpName>Federal Research Division,
<corpName>Library of Congress</corpName>
</corpName>Standard designations for corporate bodies can be taken from a controlled vocabulary, such as the Gemeinsame Normdatei (GND). If a controlled value is used, the list from which it is taken should be recorded. In this case, the following attributes are particularly relevant:
Geographic names are proper noun designations for places (e.g., Baltimore, Maryland), natural features (e.g., Black Forest) or political jurisdictions (e.g., Quartier Latin, Paris).
The element can be used, e.g., to label geographical names in titles:
<title>
<geogName>Bohemia</geogName>: Folk Songs
</title><title>Music in the
<geogName>German Democratic Republic</geogName>
</title>Geographic name sub-parts may be encoded in geogName sub-elements. For example:
<p>
<geogName>
<geogName>Baltimore</geogName>,
<geogName>Maryland</geogName>
</geogName>
<geogName>
<geogName>French Quarter</geogName>,
<geogName>New Orleans</geogName>,
<geogName>Louisiana</geogName>
</geogName>
</p>Alternatively, geographic name sub-parts may be encoded using the following more specific elements:
In contrast to the way addrLine is used to mark the physical arrangement of the parts of an address, these elements can be used to mark the semantic components of an address. For example:
<address>
<street>21 Jump Street</street>
<settlement>My Town</settlement>
<region>My Prefecture</region>
<region>My Province</region>
<country>My Country</country>
<postCode>A123B456C</postCode>
</address>They may also be used to identify place name components within textual content:
<annot>Holmes and Watson live at
<street>
<num>221</num>Baker St.
</street>in
<settlement>London</settlement>,
<country>England</country>.
</annot><list>
<head>
Oh, the places I want to go
</head>
<li>
<settlement>London</settlement>
</li>
<li>
<country>France</country>
</li>
<li>
<region>Napa Valley</region>
</li>
</list>To enable localization of an organization, or to specify names of places with identical names, the use of controlled vocabulary is recommend for names of administrative divisions, such as cities, states, and countries. In this case, the following attributes are particularly relevant:
The encoder may use these attributes in combination. In case of the German city of Frankfurt, for example, a clarification whether Frankfurt am Main or Frankfurt an der Oder is meant can be achieved by referring to the ID of the TGN entry:
<!-- Frankfurt am Main -->
<geogName authURI="www.getty.edu/research/tools/vocabularies/tgn" authority="TGN" codedval="7005293">Frankfurt</geogName>
<!-- Frankfurt an der Oder -->
<geogName authURI="www.getty.edu/research/tools/vocabularies/tgn" authority="TGN" codedval="7005972">Frankfurt</geogName>The names of places given within addresses can be marked with geogName elements, for example:
<p>
<corpName authURI="http://d-nb.info/gnd" authority="GND" codedval="2007744-0">German Research Foundation</corpName>
<address>
<addrLine>Kennedyallee 40</addrLine>
<addrLine>53175
<geogName authURI="www.getty.edu/research/tools/vocabularies/tgn" authority="TGN" codedval="7005090">Bonn</geogName>
</addrLine>
<addrLine>
<geogName authURI="www.getty.edu/research/tools/vocabularies/tgn" authority="TGN" codedval="7000084">Germany</geogName>
</addrLine>
</address>
</p>The periodName element is for names which describe a particular period of time, for example, those which characterize obvious similarities in style, such as ‘Baroque’ or ‘3rd Style Period’:
<periodName>Baroque</periodName>The date sub-element is available within periodName in order to record any dates associated with the name that should be captured in the text, for example, start and end dates of the named period:
<periodName>Baroque (
<date>1600</date>-
<date>1750</date>)
</periodName>Recording start and end points of a certain period using the @startdate and @enddate attributes may prove to be better for machine processing:
<periodName enddate="1750" startdate="1600">Baroque</periodName>If a controlled value is used, the list from which it is taken should be recorded. In this case the following attributes are relevant:
Personal names within an MEI document may simply be marked with the persName element containing a proper noun or proper noun phrase referring to an individual. For example:
<sourceDesc>
<source>
<titleStmt>
<title>Im wunderschönen Monat Mai</title>
<respStmt>
<persName role="composer">Robert Schumann</persName>
</respStmt>
</titleStmt>
</source>
</sourceDesc>Apart from the composer or originator of a musical work, there could be many other persons involved in the genesis of a musical work, such as librettists, lyricists, arrangers, editors, transcribers, printers, publishers, etc. In addition, sometimes a single individual may have multiple functions with regard to a musical work, e.g. composer and librettist. The @role attribute on persName may be used to capture a person’s responsibility. For example:
<persName role="arranger">Wolfgang Amadeus Mozart</persName><persName role="lyricist">Heinrich Heine</persName>The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role.
Personal names often consist of several components, such as given names, surnames, inherited or life-time titles of nobility, honorific or academic prefixes, military ranks, and other traditional descriptive phrases. These components can be marked using persName sub-elements, the function of which may be indicated using the @type attribute with the following values:
‘forename’: contains a forename, given or baptismal name.
‘surname’: a family (inherited) name, as opposed to a given, baptismal, or nick name.
‘rolename’: contains a name component which indicates that the referent has a particular role or position in society, such as an official title or rank.
‘addname’ (additional name): contains an additional name component, such as a nickname, epithet, or alias, or any other descriptive phrase used within a personal name.
‘namelink’ (name link): contains a connecting phrase or link used within a name but not regarded as part of it, such as van der or of.
‘genname’ (generational name): contains a name component used to distinguish otherwise similar names on the basis of the relative ages or generations of the persons named.
However, the recommended practice is to employ the following sub-elements provided by the namesDates module:
For example,
<persName>
<foreName>Rob</foreName>
<addName>The Bold</addName>
<famName>Stark</famName>
<genName>I</genName>
<nameLink>of</nameLink>
<geogName>Winterfell</geogName>
<roleName>King in the North</roleName>
</persName>In the case of individuals with more than one forename, it is often sufficient to place all given names within a single foreName element:
<persName>
<famName>Mozart</famName>,
<foreName>Johannes Chrysostomus Wolfgangus Theophilus</foreName>
</persName>However, the advantage of marking names with specific name part elements instead of nested persName elements, is that it becomes possible to use the @type attribute to distinguish between multiple instances of the same generic name component. The following example indicates the function of each of the given names of Wolfgang Mozart:
<persName>
<famName>Mozart</famName>,
<foreName type="baptismal">Johannes</foreName>
<foreName type="baptismal">Chrysostomus</foreName>
<foreName type="familiar">Wolfgangus</foreName>
<foreName type="baptismal">Theophilus</foreName>
</persName>The use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended for names, especially those occurring within the metadata header. When a controlled value is used, information about the the value should be recorded. The following attributes are provided for this purpose:
For maximal machine-processability, these three attributes may be used in combination. For example:
<persName authURI="http://d-nb.info/gnd" authority="GND" codedval="118584596" role="composer">Wolfgang Amadeus Mozart</persName>Music can be divided into different styles, genres, and forms. The term style denotes a mode of expression, or more particularly, the manner in which a work of art is executed:
“In the discussion of music, which is orientated towards relationships rather than meanings, the term raises special difficulties; it may be used to denote music characterized of an individual composer, of a period, of a geographical area or center, or of a society or social function. For the aesthetician style concerns surface or appearance, though in music appearance and essence are ultimately inseparable. For the historian a style is a distinguishing and ordering concept, both consistent of and denoting generalities; he or she groups examples of music according to similarities between them.” (Source: “Style”, Grove Music Online, accessed: April 27, 2012)
The name of a musical style can be marked by the styleName element, for example:
<styleName>bebop</styleName>It may be, e.g., used for recording a style name within a title:
<title>La voix du
<styleName>bebop</styleName>
</title>or to record a style of a certain epoch by using the styleName sub-element:
<periodName>Modern
<styleName>Jazz</styleName>
</periodName>Musical forms and genres must be distinguished from musical style. Form and genre are typically indicated using the classification element, described in chapter Classification.
The name element may be used to mark up portions of a text that function as name.
The name element is intended for generic applications and may be used to identify any named entity, such as a person, item, application, place, etc. Sometimes, however, a more specific encoding is desired, identifying the type of entity by using dedicated elements. MEI offers an (optional) module for this, which provides such elements for various types of names.
The date element may be used to mark up portions of a text that denote a date.
The element date contains a date in any format, including a date range. A date range may be expressed as textual content or, when intervening punctuation is present, as a combination of date sub-elements and text.
<p>
<date>5/3/05</date>
<date>May 30, 2012</date>
<date>March 1-21, 1812</date>
<date>
<date>March 1, 1812</date>-
<date>March 21, 1812</date>
</date>
</p>To be more specific about the date, the attributes in the att.datable and att.calendared classes can be used:
In the following example, the ambiguous date text “5/3/05” is resolved using the @isodate attribute:
<p>
<date isodate="1905-05-03">5/3/05</date>
<date isodate="2005-03-05">5/3/05</date>
</p>The num element may be used to identify any numeric information in a text. The @unit may be used to specify the unit of measurement.
This element is useful when it is necessary to provide specific information about numeric data, such as the unit of measurement or the kind of quantity described, or when it should be displayed in a special manner.
Addresses may be encoded using the address element, which itself may hold an arbitrary number of addrLine elements.
It is important to note that the address element does not hold a reference to the person or organization whose address is specified. This must be provided in a separate element, as in the following example:
<p>
<corpName>Universität Paderborn</corpName>
<address>
<addrLine>Warburger Straße 100</addrLine>
<addrLine>33098 Paderborn</addrLine>
<addrLine>Germany</addrLine>
</address>
</p>The following element is used in the encoding of bibliographic citations and references:
The bibl element may contain a mix of text and more specific elements, including the following:
These elements fall into the following categories:
The elements title, edition, series, and identifier fall into the first category as do the elements arranger, author, composer, librettist, lyricist, funder, sponsor, and respStmt. The respStmt element is provided for marking responsibility roles that cannot be recorded using more specific elements. The biblScope element also carries information of an identifying nature.
The identifier for a given item may be an International Standard Book/Music Number, Library of Congress Control Number, a publisher’s or plate number, a personal identification number, an entry in a bibliography or catalog, etc.
To classify the title according to some convenient typology, the @type attribute may be used. Sample values include: main (main title), subordinate (subtitle, title of part), abbreviated (abbreviated form of title), alternative (alternate title by which the work is also known), translated (translated form of title), uniform (collective title). The @type attribute is provided for convenience in analysing titles and processing them according to their type; where such specialized processing is not necessary, there is no need for such analysis, and the entire title, including subtitles and any parallel titles, may be enclosed within a single title element. Title parts may be encoded in title sub-elements. The name of the list from which a controlled value is taken may be recorded using the @authority attribute.
Publication and distribution data may be captured using pubPlace, publisher, distributor, and date elements directly inside bibl when the citation is unstructured. However, these elements should be grouped within imprint whenever practical.
The physical characteristics of the cited item may be described using the extent element.
Annotation of the bibliographic citation and the provision of other pertinent details are addressed by several elements. Commentary on the bibliographic item or citation is accommodated by the annot and creation elements. The annot element is provided for generic comments, while creation is intended to hold information about the context of the creation of the cited item. Terms by which the bibliographic item can be classified may be placed in genre. For letters and other correspondence, recipient captures the name of the person or organization to whom the item was addressed. The natural language(s) of the item may be recorded in one or more textLang elements. Finally, a holding institution may be documented using the repository element directly within bibl, but physLoc should be used whenever possible as a grouping mechanism for location and shelfmark information. To identify sub-units of the holding institution, repository sub-elements may be used. The name of the list from which a controlled value for the agency name is taken may be recorded using the @authority attribute.
When supplied with a @target attribute, bibl may function as a hypertext reference to an external electronic resource. In addition, other related bibliographic items may be described or referenced using the relatedItem element.
<bibl>
<genre>letter</genre>
<author>Carl Nielsen</author>
<recipient>Gustav Hetsch</recipient>
<creation>
<date isodate="1915-04-08">1915-04-08</date>
</creation>
<physLoc>
<repository>
<identifier auth.uri="http://www.rism.info/" auth="RISM">DK-Kk</identifier>
</repository>
<identifier>CNA IAc</identifier>
</physLoc>
<relatedItem rel="host">
<bibl xml:id="shared.bibl_d1e380372">
<title>CNB</title>
<biblScope>V/210</biblScope>
</bibl>
</relatedItem>
</bibl>Please consult Names and Dates for more information about recording the names and dates frequently found in bibliographic citations.
In some situations it is necessary to provide references from one bibliographic item to another. For these situations, MEI offers the relatedItem element. A relatedItem may be used inside of bibl, and may either point to a different entity using its @target attribute, or may hold the related item as a child.
<bibl>
<genre>letter</genre>
<author>Carl Nielsen</author>
<recipient>Gustav Hetsch</recipient>
<creation>
<date isodate="1915-04-08">1915-04-08</date>
</creation>
<physLoc>
<repository>
<identifier auth.uri="http://www.rism.info/" auth="RISM">DK-Kk</identifier>
</repository>
<identifier>CNA IAc</identifier>
</physLoc>
<relatedItem rel="host">
<bibl xml:id="shared.bibl_d1e380372">
<title>CNB</title>
<biblScope>V/210</biblScope>
</bibl>
</relatedItem>
</bibl>In this example, the nested relatedItem / bibl provides information about the ‘container’ where the outer bibl may be found. The kind of relation is expressed using the @rel attribute. It describes the relationship of the child bibl to the relatedItem’s parent bibl.
In these relations, the subject is always the relatedItem, and the object is always the parent of the relatedItem. Thus, a value of @rel=”preceding” indicates that the resource described within the relatedItem (or referenced by its @target attribute) precedes the bibl containing the relatedItem. Following MODS, both values of “preceding” and “succeeding” indicate a temporal order.
It is important not to confuse relatedItem with the concepts of Functional Requirements for Bibliographic Records (FRBR); see RelatedItem vs. FRBR.
Annotations are one of the most versatile features of MEI. They are provided using the annot element.
This element may be contained by a wide range of other elements and may contain a large number of other elements. While this offers great flexibility in addressing the wide variety of textual features that might occur within an annotation, it may lead to markup that cannot be effectively processed mechanistically.
In all cases, annot provides a comment upon a feature of the encoding, but never contains textual transcription. Depending on its context, an annotation will deal with either its parent element, or, more usually, with the element(s) specified in its @plist attribute. This attribute uses URI references to link to one or more other elements using their @xml:id attribute values, as in the following example:
<note xml:id="shared.someInterestingNote"></note>
<!-- elsewhere in the document: -->
<annot plist="#shared.someInterestingNote">
<!-- additional information about this note -->
</annot>9.1. Text Structures 9.1.1. Organizing Text into Divisions 9.1.2. Paratext 9.2. Text in MEI 9.2.1. Paragraphs 9.2.2. Text Rendition 9.2.3. Figures 9.2.4. Lists 9.2.5. Tables 9.2.6. Quotation 9.2.7. Poetry 9.2.8. Names 9.2.9. Dates 9.2.10. Numbers 9.2.11. Addresses 9.2.12. Bibliographic Citations and References 9.2.13. Annotations