This chapter describes methods for encoding textual content with MEI. It is divided into section: One part deals with 9.1 Text Structures in MEI, the other with 9.2 Text in MEI. While the first covers structures of textual documents such as front matter or back matter, 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 3 Metadata in MEI. However, they should not be confused with the elements from the 8 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 2.1.2.2 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>
</mdiv><section>
<!-- Score of Franz Liszt's "Sonetto 104 del Petrarca -->
</section><div>
</score><!-- Text of Francesco Petrarca's Sonett n. 104. -->
<lg>
</div><l>L'aspectata vertù, che 'n voi fioriva</l>
<l>quando Amor cominciò darvi bataglia,</l>
<!-- ... -->
</lg>
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">
</front><head>Prefazione</head>
<!-- text -->
</div>
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/>
</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 3.2 Structure of the MEI Header, 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 3.7.1.2 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>
</div><!-- Dedicatory text -->
</p><div type="preface">
</front><head>
Preface
</head>
<p>
<!-- paragraph 1 -->
</p><p>
<!-- paragraph 2 -->
</p><!-- additional material -->
</div>
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 9.2.4 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 13.2 Linking from MEI.)
<div type="contents">
<head>
Contents
</head>
<list form="ordered">
</div><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
</list><ptr target="#song6"/>
</li>
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">
</back><head>
Index
</head>
<list type="index">
</div><li>a2, a3, etc., 175-176</li>
<li>Abbreviations, 3
<list type="index">
</li><li>Percussion, 205-213</li>
<li>Strings, 307</li>
</list><li>Afterbeats, 77</li>
</list>
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 8.1 Vocal Text and 2.2.5.1 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 3.2 Structure of the MEI Header):
<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 9.1.2 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>
</front><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>
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 rend element can accept glyph.auth and glyph.uri attributes, which provide encoders with the ability to specify an external authority for Unicode codepoints in the textual content. Only the text content that should be rendered using SMuFL code points should go inside the rend element when using glyph.auth and glyph.uri.
<rend>
This is what a G clef looks like:
<rend glyph.auth="smufl"></rend>
</rend>
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 availability 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">
</p><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>
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>Triosonate
<lb/>Standardbes.
</td><td>Triosonate für
<lb/>Orgel (Bach)
</td><td>Sonate mit obl.
<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/>(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/>
</tr><tr>
<td>harmonische Füllung</td>
<td>Cembalo r.H.</td>
<td/>
<td/>
<td/>
<td>Bratsche</td>
<td>Bratsche</td>
</tr><tr>
</table><td>Bass-Stimme</td>
<td>Cello</td>
<td>Orgel Pedal</td>
<td>Cello</td>
<td>Cello</td>
<td>Cello</td>
<td>Cello</td>
</tr>
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>3. Platten</td>
<td>3. Reihen</td>
<td/>
</tr><tr>
</table><td/>
<td>4. Gefäße</td>
<td/>
<td/>
</tr>
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>3. Platten</td>
<td>3. Reihen</td>
<td/>
</tr><tr>
</table><td/>
<td>4. Gefäße</td>
<td/>
<td/>
</tr>
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><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>
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>
</mdiv><section>
<!-- Score of Franz Liszt's "Sonetto 104 del Petrarca" -->
</section><div>
</score><!-- Text of Francesco Petrarca's Sonett n. 104. -->
<lg>
</div><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>
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>
</p><date>March 1, 1812</date>-
<date>March 21, 1812</date>
</date>
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>
</p><addrLine>Warburger Straße 100</addrLine>
<addrLine>33098 Paderborn</addrLine>
<addrLine>Germany</addrLine>
</address>
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: - identification of the bibliographic entity and those responsible for its intellectual content - publication and distribution data for the bibliographic entity - description of the physical characteristics of the item - annotation of the bibliographic citation and additional details regarding the item’s intellectual content
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><bibl xml:id="shared.bibl_d1e380372">
</relatedItem><title>CNB</title>
<biblScope>V/210</biblScope>
</bibl>
Please consult 9.2.8 Names and 9.2.9 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><bibl xml:id="shared.bibl_d1e380372">
</relatedItem><title>CNB</title>
<biblScope>V/210</biblScope>
</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 3.5 Functional Requirements for Bibliographic Records (FRBR); see 3.5.4 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"/>
<!-- elsewhere in the document: -->
<annot plist="#shared.someInterestingNote">
<!-- additional information about this note -->
</annot>