1 Shared Elements, Models, and Attributes

This chapter describes the elements, models, and attributes that are part of the MEI.shared module. The shared module contains declarations that are common to two or more other modules.

1.1 Structural Elements

1.1.1 Document Elements

The following elements are available for the representation of the outermost structure of an MEI document:

  • meiContains a single MEI-conformant document, consisting of an MEI header and a musical text, either in isolation or as part of an meiCorpus element.
  • meiversion Specifies a generic MEI version label.
  • meiCorpus(MEI corpus) – A group of related MEI documents, consisting of a header for the group, and one or more <mei> elements, each with its own complete header.
  • meiHead(MEI header) – Supplies the descriptive and declarative metadata prefixed to every MEI-conformant text.
  • musicContains a single musical text of any kind, whether unitary or composite, for example, an etude, opera, song cycle, symphony, or anthology of piano solos.

A typical MEI document contains an mei element, which in turn contains metadata, represented by an meiHead element, and the musical text itself, represented by a music element. The meiHead element, formally declared in the MEI.header module, is described in chapter 2 The MEI Header.

Other variations on this basic form are also available for the representation of a:

  • collection of related MEI-encoded texts, each with its own metadata, known as a corpus
  • document that contain only metadata, known as an independent or stand-alone header
  • music notation markup without metadata, typically intended to be embedded within another kind of markup, such as TEI

Further information regarding the organization and encoding of music corpora is given in chapter 9 Musical Corpora. Stand-alone headers are more fully described in chapter 2.7 Independent Headers.

Inclusion of MEI encodings (partial or complete) inside Text Encoding Initiative (TEI) documents is covered in the TEI Guidelines at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FT.html#FTNM and by the TEI Music Special Interest Group at http://www.tei-c.org/SIG/Music/twm/index.html.

1.1.2 Music Element

MEI texts may be regarded either as unitary; that is, forming an organic whole, or as composite; that is, consisting of several components which are in some important sense independent of each other. The distinction is not always entirely obvious. For example, a collection of songs might be regarded as a single item in some circumstances, or as a number of distinct items in others. In such borderline cases, the encoder must choose whether to treat the text as unitary or composite; each option may have advantages and disadvantages.

Whether unitary or composite, the musical text is marked with the music tag and may contain front matter, a body, and back matter. In unitary texts, the body is tagged using the body element; in composite texts, however, where the textual body consists of a series of subordinate musical texts or other groups, it is tagged with the group element. The overall structure of any musical text, unitary or composite, is thus defined by the following elements:

  • front(front matter) – Bundles prefatory text found before the start of the musical text.
  • bodyContains the whole of a single musical text, excluding any front or back matter.
  • groupContains a composite musical text, grouping together a sequence of distinct musical texts (or groups of such musical texts) which are regarded as a unit for some purpose, for example, the collected works of a composer.
  • back(back matter) – Contains any appendixes, advertisements, indexes, etc. following the main body of a musical text.

Critical editions and collections of works often contain extensive text, such as a title page, table of contents, an introductory essay, commentary, biographical sketch, index, etc. These textual items may appear in either the front or back elements. The front and back elements, available only when the MEI.text module is activated, are described more fully in chapter 21 Text in MEI.

The overall structure of a single musical text is:

<mei>
<meiHead>
<!-- metadata goes here -->
</meiHead>
<music>
<front>
<!-- front matter of text, if any, goes here -->
</front>
<body>
<!-- body of text goes here -->
</body>
<back>
<!-- back matter of text, if any, goes here -->
</back>
</music>
</mei>

The top-level structure of a composite musical text made up of two unitary musical texts is:

<mei>
<meiHead>
<!-- metadata for the composite musical text -->
</meiHead>
<music>
<front>
<!-- front matter for composite musical text -->
</front>
<group>
<music>
<front>
<!-- front matter of first unitary musical text, if any -->
</front>
<body>
<!-- body of first unitary musical text -->
</body>
<back>
<!-- back matter of first unitary musical text, if any -->
</back>
</music>
<music>
<body>
<!-- body of second unitary musical text -->
</body>
</music>
</group>
<back>
<!-- back matter for composite musical text, if any -->
</back>
</music>
</mei>

1.1.2.1 Grouped Texts

The group element may be used to represent a collection of independent musical texts which is to be regarded as a single unit for processing or other purposes. It is provided to simplify the encoding of collections, anthologies, and cyclic works. It can also be used to record the potentially complex internal structure of corpora, covered more fully in chapter 9 Musical Corpora.

  • groupContains a composite musical text, grouping together a sequence of distinct musical texts (or groups of such musical texts) which are regarded as a unit for some purpose, for example, the collected works of a composer.

Examples of composite texts which may be represented using the group element include anthologies and other collections. The presence of common front matter referring to the whole collection, possibly in addition to front matter relating to each individual musical text, is a good indication that a given musical text might usefully be encoded in this way.

For example, the overall structure of a collection of songs might be encoded as follows:

<music>
<group>
<music>
<!-- song 1 -->
</music>
<music>
<!-- song 2 -->
</music>
<!-- additional songs here -->
</group>
</music>

A group of musical texts may contain other unitary and grouped texts:

<music>
<group>
<music>
<!-- song 1 -->
</music>
<group>
<!-- songs sharing one or more characteristics, treated as a group -->
<music>
<!-- song 2 -->
</music>
<music>
<!-- song 3 -->
</music>
</group>
</group>
</music>

The group element may be used to encode any kind of collection in which the constituents are regarded by the encoder as works in their own right, such as ad hoc single- or multiple-composer collections or anthologies of works not originally conceived of as a single composition.

1.1.2.2 Divisions of the Body

This section describes sub-division of the body of a musical text. Front and back matter are described in chapter 21 Text in MEI.

The body of a unitary musical text may contain one or more discrete, linear segments. The names commonly used for these structural subdivisions vary with the genre, style, and time period of the music, or even at the whim of the author, editor, or publisher. For example, a major subdivision of a symphony is generally referred to as a ‘movement’. An opera, on the other hand, is usually organized into ‘acts’ and then further by ‘scenes’. All such divisions are treated as occurrences of the same neutrally-named element, with a type attribute used to categorize them independently of their hierarchic level.

The following element is used to identify musical subdivisions. As a member of the class att.typed, the mdiv element has attributes which can be used to classify it according to a two-tier hierarchy.

  • mdiv(musical division) – Contains a subdivision of the body of a musical text.
  • type Characterizes the element in some sense, using any convenient classification scheme or typology.
    subtype Provide any sub-classification for the element, additional to that given by its type attribute.

To accommodate "divisions within divisions", an mdiv element may contain additional mdiv sub-elements nested to any level required. For example, the encoding of a multi-movement work, such as a symphony, frequently have the following structure:

<body>
<mdiv type= "symphony">
<mdiv n= "1" type= "movement">
<!-- contents of mvt 1 -->
</mdiv>
<mdiv n= "2" type= "movement">
<!-- contents of mvt 2 -->
</mdiv>
<mdiv n= "3" type= "movement">
<!-- contents of mvt 3 -->
</mdiv>
<mdiv n= "4" type= "movement">
<!-- contents of mvt 4 -->
</mdiv>
</mdiv>
</body>

while dramatic works, such as Verdi's opera, Il Trovatore, often exhibit a more deeply-nested structure:

<body>
<mdiv type= "opera">
<mdiv n= "I" type= "act">
<mdiv n= "1" type= "scene">
<!-- contents of act I, sc. 1 -->
</mdiv>
<mdiv n= "2" type= "scene">
<!-- contents of act I, sc. 2-->
</mdiv>
<mdiv n= "3" type= "scene">
<!-- contents of act I, sc. 3 -->
</mdiv>
</mdiv>
<mdiv n= "II" type= "act">
<mdiv n= "1" type= "scene">
<!-- contents of act II, sc. 1 -->
</mdiv>
<mdiv n= "2" type= "scene">
<!-- contents of act II, sc. 2 -->
</mdiv>
<mdiv n= "3" type= "scene">
<!-- contents of act II, sc. 3 -->
</mdiv>
<mdiv n= "4" type= "scene">
<!-- contents of act II, sc. 4 -->
</mdiv>
<mdiv n= "5" type= "scene">
<!-- contents of act II, sc. 5 -->
</mdiv>
</mdiv>
<mdiv n= "III" type= "act">
<mdiv n= "1" type= "scene">
<!-- contents of act III, sc. 1 -->
</mdiv>
<mdiv n= "2" type= "scene">
<!-- contents of act III, sc. 2 -->
</mdiv>
<mdiv n= "3" type= "scene">
<!-- contents of act III, sc. 3 -->
</mdiv>
</mdiv>
<mdiv n= "IV" type= "act">
<mdiv n= "1" type= "scene">
<!-- contents of act IV, sc. 1 -->
</mdiv>
<mdiv n= "2" type= "scene">
<!-- contents of act IV, sc. 2 -->
</mdiv>
<mdiv n= "3" type= "scene">
<!-- contents of act IV, sc. 3 -->
</mdiv>
</mdiv>
</mdiv>
</body>

Conventionally, in performance the musical structures represented by mdiv elements are separated by pauses; however, attacca, attacca subito, seque, or similar terms are sometimes used at the end of an mdiv to indicate that the next mdiv should begin immediately after the conclusion of the current one. These terms have no effect, however, on the logical segmentation of musical content using mdiv elements.

1.1.2.3 Content of Musical Divisions

The mdiv element may contain one or both of two possible views: score and parts.

  • scoreFull score view of the musical content.
  • partsProvides a container for performers' parts.

The score element represents notation in which all the parts of an ensemble are arranged on vertically aligned staves, while the parts element collects the individually notated parts for each performer or group of performers. The explicit encoding of these two ‘views’ is necessary because it is not always possible or desirable to automatically derive one view from the other. In addition, separating scores and parts can eliminate a great deal of markup complexity.

<body>
<mdiv n= "1" type= "movement">
<score>
<!-- markup of score goes here -->
</score>
<parts>
<!-- markup of performers’ parts goes here -->
</parts>
</mdiv>
<!-- additional movements go here -->
</body>

The score and parts elements may also be employed to accommodate different methods of organizing the markup – with no particular presentation implied. In this case, software may render a collection of parts as a score or a score as a collection of parts.

Within the collective parts element, notation for a single performer is represented by the part element:

  • partAn alternative visual rendition of the score from the point of view of a particular performer (or group of performers).

A part is effectively a small-scale score, allowing all the encoding features of a full score, such as multiple staves, performance directives, and so on. A group of part element is useful for encoding performing parts when there is no score, such as in early music part books; when the parts have non-aligning bar lines; when different layout features, such as page turns, are needed for the score and parts; or for accommodating software that requires part-by-part encoding.

Please note that part elements in MEI are not an indication of voice leading or staff grouping. Voice leading can be encoded using the next attribute, available on all the members of the model.eventLike class. The staffGrp element handles grouping of staves in the score context.

<parts>
<part label= "Violin 1">
<!-- first performer’s part -->
</part>
<part label= "Violin 2">
<!-- second performer’s part -->
</part>
<!-- additional performers’ parts -->
</parts>

In both score and part views, the scoreDef element is used to describe logical characteristics of the encoded music, such as key signature, the sounding key (as opposed to the notated key signature), meter, etc., and visual features, such as page size, staff groupings and display labels, etc. The staffGrp elements within scoreDef and the order of staffDef elements inside staffGrp should follow the score order of the source for the encoding.

A part or score may be further divided into linear segments called "sections".

  • sectionSegment of music data.

section elements are often used as a scoping mechanism for clef signs, key and meter signatures, as well as metronome, tempo, and expression markings. Using section elements can help to minimize the need for backward scanning to establish context when the starting point for access is not at the beginning of the score. section elements may also be used for other user-defined, i.e., analytical or editorial, purposes and may therefore be arbitrarily nested to any desired level.

The ending element shares the same model as the section element. Unlike section, however, it may not be recursively nested.

  • endingAlternative ending for a repeated passage of music; i.e., prima volta, seconda volta, etc.

The most common (non-analytical, non-editorial) use of section and ending elements is illustrated below:

<music>
<body>
<mdiv>
<score>
<section>
<!-- section one to be repeated -->
</section>
<ending n= "1">
<!-- 1st ending -->
</ending>
<ending n= "2">
<!-- 2nd ending -->
</ending>
<section>
<!-- next section -->
</section>
</score>
</mdiv>
</body>
</music>

Within section elements, several methods of organization are possible, depending upon the notational style of the source material and the encoder's needs. For example, when the MEI.cmn module is used, the default organization is measure-by-measure, with staff and layer sub-elements within each measure. Further discussion of CMN notation is continued in chapter 4 Common Music Notation.

However, staff-by-staff organization is more appropriate for music without measures and is provided when either the MEI.mensural or MEI.neumes module is employed. Coverage of mensural notation is provided in chapter 5 Mensural Notation, while 6 Neume Notation describes neumatic notation.

It must be noted that, when both the MEI.cmn and MEI.mensural modules are available, it is possible to encode CMN notation without using measure elements; that is, staff-by-staff organization may be used and the ends of measures marked using barLine elements.

In certain circumstances, this approach may be preferable for reproduction of the visual layout of the music. However, the simultaneous use of the measure and barLine elements may lead to confusion and should be avoided.

Typically, MEI follows the order of sections as they appear in the document being encoded. When performance requires a different order, for instance in the case of D.C. and D.S. directives, the following element may be used to define the performance order.

  • expansionIndicates how a section may be programmatically expanded into its 'through-composed' form.

In the following example, expansion is used to indicate how the notated sections should be ordered in a "through-composed" rendition, for example for machine performance or analysis. The plist attribute contains an ordered list of identifiers of descendant section, ending, lem, or rdg elements. The sequence of values in the plist attribute indicates that the section labelled 'A' comes first, then the section labelled 'B', followed by the 'A' section again. This mechanism must be specified independently of any textual directives, such as "Da capo" or "D.S. al Fine", that may be present in the document.

<music>
<body>
<mdiv>
<score>
<section>
<expansion plist= "#shared.A #shared.B #shared.A"/>
<section xml:id= "shared.A">
<!-- "A" section -->
</section>
<section xml:id= "shared.B">
<!-- "B" section -->
</section>
</section>
</score>
</mdiv>
</body>
</music>

1.2 Shared Musical Elements

This section lists the elements defined in the shared module that are available within the music element.

1.2.1 Score and Parts

The following elements are provided for the capture of scores and parts:

  • scoreFull score view of the musical content.
  • partsProvides a container for performers' parts.
  • partAn alternative visual rendition of the score from the point of view of a particular performer (or group of performers).
  • scoreDef(score definition) – Container for score meta-information.
  • staffDef(staff definition) – Container for staff meta-information.
  • layerDef(layer definition) – Container for layer meta-information.
  • staffGrp(staff group) – A group of bracketed or braced staves.
  • grpSym(group symbol) – A brace or bracket used to group two or more staves of a score or part.
  • labelA container for text that identifies the feature to which it is attached.
  • clefIndication of the exact location of a particular note on the staff and, therefore, the other notes as well.
  • clefGrp(clef group) – A set of simultaneously-occurring clefs.
  • keySig(key signature) – Written key signature.
  • keyAccid(key accidental) – Accidental in a key signature.

The character of elements specifying one or more score or staff parameters, such as meter and key signature, clefs, etc., is that of a milestone; that is, they affect all subsequent material until a following redefinition. A scoreDef element, which may affect more than just one staff, is allowed only within score, part and section elements, whereas staffDef is allowed only within staffGrp, staff and layer. A staffDef nested inside a staff must bear the same value for its n attribute as its parent staff and may thus not affect other staves.

The actual use of these elements depends on the repertoire and historical context of the source material. For details on their use in Common Western Notation, please refer to chapter 4.1.2 Defining Score Parameters for CMN.

1.2.2 Staves and Layers

The elements below are used to capture the logical organization of musical notation:

  • staffA group of equidistant horizontal lines on which notes are placed in order to represent pitch or a grouping element for individual 'strands' of notes, rests, etc. that may or may not actually be rendered on staff lines; that is, both diastematic and non-diastematic signs.
  • layerAn independent stream of events on a staff.

The actual use of the staff and layer elements depends on the repertoire and historical context of the source material. For details on their use in Common Western Notation, please refer to chapter 4.1.1 The Role of the Measure Element. For mensural notation, see chapter 5.5 Music Data Organization, and for neumatic notation, chapter 6 Neume Notation.

1.2.3 Basic Music Events

The basic features of music notation are represented by the following elements:

  • noteA single pitched event.
  • chordA simultaneous sounding of two or more notes in the same layer *with the same duration*.
  • restA non-sounding event found in the source being transcribed.

The characteristics of stems on notes and chords are indicated by means of attributes found in the att.stems class.

  • stem.dir Describes the direction of a stem.
    stem.len Encodes the stem length.
    stem.mod Encodes any stem "modifiers"; that is, symbols rendered on the stem, such as tremolo or Sprechstimme indicators.
    stem.pos Records the position of the stem in relation to the note head(s).
    stem.x Records the output x coordinate of the stem's attachment point.
    stem.y Records the output y coordinate of the stem's attachment point.

1.2.4 Other "Events"

Because they can occur in the context of a stream of events on the staff, some elements which are used in other contexts are also treated as events. For example, in addition to being used to define the initial clef of a staff, the clef element can also be used to indicate a clef change.

1.2.4.1 Key Signatures and Clefs

Key signatures and clefs as well as intra-staff changes to these musical parameters are treated as events.

  • keySig(key signature) – Written key signature.
  • keyAccid(key accidental) – Accidental in a key signature.
  • clefIndication of the exact location of a particular note on the staff and, therefore, the other notes as well.
  • clefGrp(clef group) – A set of simultaneously-occurring clefs.

1.2.4.2 Bar Lines and Custos Signs

Measure separators, i.e., bar lines, and custos signs are also considered to be events.

  • barLineVertical line drawn through one or more staves that divides musical notation into metrical units.
  • custosSymbol placed at the end of a line of music to indicate the first note of the next line. Sometimes called a "direct".

1.2.4.3 Accidentals, Articulation Symbols, Augmentation Dots, and Custos Signs

The following elements are regarded as events primarily because they sometimes occur independently of any associated notes, rests, or chords, especially in mensural and neume repertoires.

  • accid(accidental) – Records a temporary alteration to the pitch of a note.
  • artic(articulation) – An indication of how to play a note or chord.
  • dotDot of augmentation or division.

1.2.4.4 Lyric Syllables

The syl element is used to mark a word or portion of a word that is to be vocally performed. A fuller description of its use is provided in chapter 15.1 Lyric Syllables.

  • syl(syllable) – Individual lyric syllable.

1.2.4.5 Event Spacing

The following elements provide control over the horizontal spacing of notational events, such as notes, chords, rests, etc.:

  • spaceA placeholder used to fill an incomplete measure, layer, etc. most often so that the combined duration of the events equals the number of beats in the measure.
  • num Amount of "padding" to be added, in interline units; that is, in units of 1/2 the distance between adjacent staff lines.

In this context, the term ‘space’ is used to mean whitespace that is required to meaningfully align multiple voices in a multi-voice texture. In DARMS these were referred to as ‘push codes’. The space element is most often used when a new voice appears on a staff mid-measure.

The space element may also be used to align material that crosses staves.

‘Space’ can be thought of as another kind of event. In fact, some refer to this concept as an ‘invisible rest’.

While ‘space’ is meaningful, ‘padding’ is non-essential whitespace that is used to shift the position of the events which follow.

The pad element is provided in order to capture software-dependent placement information when it is desirable to do so. Unless the MEI file will be used as an intermediate file format, this is usually not necessary.

1.2.5 Expression Marks

Expression marks are instructions in the form of words, abbreviations, or symbols that convey aspects of performance that cannot be expressed purely through the musical notation.

1.2.5.1 Text Directives

All of the following elements can be considered text directives; however, MEI uses the dir element specifically for words, abbreviations, numbers, or symbols specifying or suggesting the manner of performance that are not encoded elsewhere using the more specific elements of tempo and dynam.

  • dir(directive) – An instruction expressed as a combination of text and symbols — such as segno and coda symbols, fermatas over a bar line, etc., typically above, below, or between staves, but not on the staff — that is not encoded elsewhere in more specific elements, like <tempo> or <dynam>.

Examples of directives include text strings such as 'affettuoso', fingering numbers, or music symbols such as segno and coda symbols or fermatas over a bar line. Directives can be control elements. That is, they can linked via their attributes to other events. The starting point of the directive may be indicated by either a tstamp, tstamp.ges, tstamp.real or startid attribute, while the ending point may be recorded by either a tstamp2, dur, dur.ges or endid attribute. It is a semantic error not to specify a starting point attribute.

1.2.5.2 Tempo

Tempo marks are indications through words, abbreviations, or specific metronome settings of the speed at which a piece of music is to be performed. Both instantaneous and continuous tempo markings may be encoded using this element.

  • tempoText and symbols descriptive of tempo, mood, or style, e.g., "allarg.", "a tempo", "cantabile", "Moderato", "♩=60", "Moderato ♩ =60").

1.2.5.3 Dynamics

Dynamics, or dynamic marks, are terms, abbreviations, and symbols that indicate the specific degrees of volume of a note, phrase, or section of music, e.g., "piano", "forte". Transitions from one volume level to another, e.g., "crescendo", "diminuendo", are also specified through dynamic marks.

  • dynam(dynamic) – Indication of the volume of a note, phrase, or section of music.

1.2.5.4 Phrase Marks

Phrase marks are curved lines placed over or under notes to delineate short sections of a work that represent a unified melodic idea, analogous to a phrase in literature.

  • phraseIndication of 1) a "unified melodic idea" or 2) performance technique.
  • slurIndication of 1) a "unified melodic idea" or 2) performance technique.

MEI maintains a distinction between phrase marks and slurs, the latter being curved lines over or under a sequence of notes indicating they are to be performed using a particular playing/singing technique, notes that should be taken in a single breath by wind instruments or played by string instruments using a single stroke of the bow. Often, a slur also indicates that the affected notes should be played in a legato manner.

Even so, it is common for both of these concepts to be referred to generically as "slurs". Therefore, unless one is encoding music from a repertoire in which this distinction is important, the slur element should be preferred over phrase.

1.2.5.5 Ornaments

Ornaments are formulae of embellishment that can be realized by adding supplementary notes to one or more notes of the melody.

  • ornamAn element indicating an ornament that is not a mordent, turn, or trill.

MEI provides a generic element for encoding an ornament symbol that is not a mordent, turn, or trill. For those common CMN ornaments, please refer to 8 Common Music Notation Ornaments.

Ornaments can be represented as textual strings (e.g. with a Unicode symbol) or with a user defined symbol. Ornaments can be control elements. That is, they be can linked via their attributes to other events. It is a semantic error not to specify a starting point attribute with either tstamp or startid.

1.3 Shared Textual Elements

This section lists elements declared in the shared module that pertain to the encoding of prose.

1.3.1 Paragraphs

A paragraph is a structural unit of a larger text. 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.

  • p(paragraph) – One or more text phrases that form a logical prose passage.

In MEI, a p is used in many different situations, including transcriptional use within a titlePage or descriptive purposes as in a changeDesc.

1.3.2 Text Rendition

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 printers points) should be specified using the fontsize and fontweight attibutes. In addition to commonly found typographical qualities, MEI provides the altrend attribute for the capture of additional, user-defined rendition information.

  • rend(render) – A formatting element indicating special visual rendering, e.g., bold or italicized, of a text word or phrase.
  • rend Captures the appearance of the element's contents using MEI-defined descriptors.
    altrend Used to extend the values of the rend attribute.
    fontname Holds the name of a font.
    fontsize Indicates the size of a font expressed in printers' points, i.e., 1/72nd of an inch, relative terms, e.g., "small", "larger", etc., or percentage values relative to "normal" size, e.g., "125%".
    fontstyle Records the style of a font, i.e, italic, oblique, or normal.
    fontweight Used to indicate bold type.

1.3.3 Transcription of Titlepages

A specialized element is furnished for the capture of titlepage information.

  • titlePageContains a transcription of the title page of a text.

The titlePage element, modelled after a similar element in Encoded Archival Description (EAD), may occur within the textual matter preceding or following the musical content of the encoding. Since a diplomatic transcription of the titlepage is often necessary to accurately identify musical material contained within a source, titlePage may also be used within the metadata header as a child of the physDesc element.

1.3.4 Names, Dates, Numbers, Abbreviations, and Addresses

1.3.4.1 Names and Dates

The name and date elements may be used to mark up portions of a text that function as names or dates.

  • nameProper noun or noun phrase.
  • dateA string identifying a point in time or the time period between two such points.

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. The namesDates module documented in 17 Names and Dates offers the more specific elements persName, corpName and geogName.

1.3.4.2 Numbers

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.

  • num(number) – Numeric information in any form.
  • unit Indicates 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 quanity described, or when it should be displayed in a special manner.

1.3.4.3 Addresses

Addresses may be encoded using the address element, which itself may hold an arbitrary number of addrLine elements.

  • addressContains a postal address, for example of a publisher, an organization, or an individual.
  • addrLine(address line) – Single line of a postal address.

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>

1.3.5 Annotations

Annotations are one of the most versatile features of MEI. They are provided using the annot element.

  • annot(annotation) – Provides a short statement explaining the text or indicating the basis for an assertion.

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>

1.3.6 Bibliographic Citations and References

The following element is used in the encoding of bibliographic citations and references:

  • bibl(bibliographic reference) – Provides a loosely-structured bibliographic citation in which the sub-components may or may not be explicitly marked.

The bibl element may contain a mix of text and more specific elements, including the following:

  • annot(annotation) – Provides a short statement explaining the text or indicating the basis for an assertion.
  • arrangerA person or organization who transcribes a musical composition, usually for a different medium from that of the original; in an arrangement the musical substance remains essentially unchanged.
  • authorThe name of the creator of the intellectual content of a non-musical, literary work.
  • biblScope(scope of citation) – Defines the scope of a bibliographic reference, for example as a list of page numbers, or a named subdivision of a larger work.
  • composerThe name of the creator of the intellectual content of a musical work.
  • creationNon-bibliographic details of the creation of an intellectual entity, in narrative form, such as the date, place, and circumstances of its composition. More detailed information may be captured within the history element.
  • dateA string identifying a point in time or the time period between two such points.
  • distributorPerson or agency, other than a publisher, from which access (including electronic access) to a bibliographic entity may be obtained.
  • edition(edition designation) – A word or text phrase that indicates a difference in either content or form between the item being described and a related item previously issued by the same publisher/distributor (e.g. 2nd edition, version 2.0, etc.), or simultaneously issued by either the same publisher/distributor or another publisher/distributor (e.g. large print edition, British edition, etc.).
  • editorThe name of the individual(s), institution(s) or organization(s) acting in an editorial capacity.
  • extentUsed to express size in terms other than physical dimensions, such as number of pages, number of records in file, number of bytes, performance duration for music, audio recordings and visual projections, etc.
  • funderNames of individuals, institutions, or organizations responsible for funding. Funders provide financial support for a project; they are distinct from sponsors, who provide intellectual support and authority.
  • genreTerm or terms that designate a category characterizing a particular style, form, or content.
  • identifierAn alpha-numeric string that establishes the identity of the described material.
  • imprintInformation relating to the publication or distribution of a bibliographic item.
  • librettistPerson or organization who is a writer of the text of an opera, oratorio, etc.
  • lyricistPerson or organization who is a writer of the text of a song.
  • physLoc(physical location) – Groups information about the current physical location of a bibliographic item, such as the repository in which it is located and its shelf mark(s), and its previous locations.
  • publisherName of the organization responsible for the publication of a bibliographic item.
  • pubPlace(publication place) – Name of the place where a bibliographic item was published.
  • recipientThe name of the individual(s), institution(s) or organization(s) receiving correspondence.
  • relatedItem(related item) – Contains or references another bibliographic item which is related to the present one.
  • repositoryInstitution, agency, or individual which holds a bibliographic item.
  • respStmt(responsibility statement) – Names one or more individuals, groups, or in rare cases, mechanical processes, responsible for creation or realization of the intellectual or artistic content.
  • seriesContains information about the serial publication in which a bibliographic item has appeared.
  • sponsorNames of sponsoring individuals, organizations or institutions. Sponsors give their intellectual authority to a project; they are to be distinguished from funders, who provide the funding but do not necessarily take intellectual responsibility.
  • textLang(text language) – Identifies the languages and writing systems within the work described by a bibliographic description, not the language of the description.
  • titleTitle of a bibliographic entity.

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 authURI= "http://www.rism.info/" authority= "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 1.3.4 Names, Dates, Numbers, Abbreviations, and Addresses and 17 Names and Dates for more information about recording the names and dates frequently found in bibliographic citations.

1.3.7 Related Items

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 authURI= "http://www.rism.info/" authority= "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.

  • rel Describes the relationship between the <relatedItem> and the resource described in the parent element, i.e., <bibl>, <source> or <relatedItem>. The values are based on MODS version 3.4. The subject of these relations is always the <relatedItem>, and the object is always the parent of the <relatedItem>. "preceding" and "succeeding" indicate temporal order.

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 FRBR; see 2.9 RelatedItem vs. FRBR.

1.4 Common Attributes

The following attributes, provided by the att.common attribute class, are available on nearly all elements in an MEI encoding. They provide the means to identify, label, and access elements in MEI-encoded files.

  • xml:id Regularizes the naming of an element and thus facilitates building links between it and other resources. Each id attribute within a document must have a unique value.
    label Provides a name or label for an element. The value may be any string.
    n Provides a number-like designation for an element.
    xml:base Provides a base URI reference with which applications can resolve relative URI references into absolute URI references.

The value of the xml:id attribute serves as an identifier for an element and its content. Its value must be unique in the context of the current document and must conform to the definition of an XML Name provided by the W3C Recommendation at http://www.w3.org/TR/xml/#NT-Name. Suggestions for constructing an ID value can be found at http://www.w3.org/TR/xml/#sec-suggested-names.

The xml:id attribute may take values similar to the following:

<!-- The following are all valid IDs. -->
<note xml:id= "n1"/>
<note xml:id= "_n1"/>
<note xml:id= "thisIsMyFavoriteNote"/>
<note xml:id= "shared.thisIsMyFavoriteNote"/>

This is an example of an incorrectly-formulated xml:id value:

<!-- xml:id not valid as IDs are not allowed to start with a number. -->
<note xml:id= "1"/>

The label and n attributes both serve a labeling function; however, they differ in the values they allow. The n attribute must be a single token, while label may contain a string value that includes spaces. This makes label useful for the capture of free-text labels, but a name or number specified with n may be easier to process.

<!-- Example of a @label containing whitespace: -->
<mdiv label= "Allegro moderato"> </mdiv>
<!-- Example of a processable @n attribute: -->
<measure n= "42">
<!--…-->
</measure>

When a reference to an external entity is not a complete URI, the xml:base attribute can record a value against which it can be resolved into a complete, or absolute, location.

<graphic target= "myImage.jpg" xml:base= "http://www.mySite.org/images/"/>

The value of xml:base can be inherited from an ancestor. In the following example, the values of the graphic elements' target attribute can be completed by the xml:base value specified for the facsimile element:

<facsimile xml:base= "http://www.mySite.org/images/">
<surface>
<graphic target= "myImage.jpg"/>
<graphic target= "myImage.tif"/>
</surface>
</facsimile>

See http://www.w3.org/TR/xmlbase/ for more details on xml:base.