Many institutions and individuals assisted in the preparation of these Guidelines and in the overall development of the Music Encoding Initiative framework and community.

Grateful acknowledgment is given to the following institutions for their generous contributions: the Akademie der Wissenschaften und der Literatur (AdW) in Mainz for serving as hosting institution for the MEI Community, and the National Endowment for the Humanities (NEH) and the Deutsche Forschungsgemeinschaft (DFG) for their joint financial support of the MEI project in its early stages. We thank several institutions that hosted Music Encoding Conferences or other MEI-related meetings in the past: The AdW Mainz, the University of Virginia Library, the Biblioteca Umanistica of the Università degli Studi Firenze, McGill University Montréal, the Centre d’études supérieures de la Renaissance Tours, the Maryland Institute for Technology in the Humanities (MITH) in College Park, the Oxford e-Research Centre, the Universität Paderborn and the Österreichische Akademie der Wissenschaften Wien in conjunction with the Universität Wien and the Mozarteum Salzburg. We also thank all other institutions that allow their researchers to invest time into both the community and the encoding framework. It is their interest that makes MEI an incredible platform for interchange and scholarly progress.

The Text Encoding Initiative is also owed a special debt of gratitude. In addition to providing much of the inspiration for MEI, the TEI organization supplied funding for the MEI Technical Group in its efforts to adopt ODD. The editors of these Guidelines are grateful for those of the TEI, which provided a stellar exemplar and from which we have borrowed shamelessly.

MEI has been a community-driven effort for more than a decade, and many individuals have provided significant and much-appreciated commitments of time and energy to the development of MEI: Nikolaos Beer; Vincent Besson; Benjamin W. Bohl; Margrethe Bue; Donald Byrd; Irmlind Capelle; Tim Crawford; David A. Day; Giuliano Di Bacco; Norbert Dubowy; Richard Freedman; Ichiro Fujinaga; Andrew Hankinson; Maja Hartwig; Kristin Herold; Franz Kelnreiter; Johannes Kepper; Robert Klugseder; Zoltán Kőmíves; David Lewis; Urs Liska; Elsa De Luca; Erin Mayhood; Stefan Morent; Stefan Münnich; Markus Neuwirth; Kevin Page; Daniel Pitti; Laurent Pugin; Klaus Rettinghaus; Kristina Richts; Daniel Röwenstrunk; Perry Roland; Craig Sapp; Agnes Seipelt; Eleanor Selfridge-Field; Christine Siegert; Peter Stadler; Axel Teich Geertinger; Martha Thomae; Joachim Veit; Raffaele Viglianti; Thomas Weber; and Sonia Wronkowska.

Thanks to Bernhard R. Appel; Richard Chesser; Morgan Cundiff; J. Stephen Downie; Oliver Huck; Fotis Jannidis; John Rink; Federica Riva; Frans Wiering and Barbara Wiermann for providing expertise on a wide range of topics related to music notation modelling.

Also thanks to Syd Bauman, Terry Catapano, and Sebastian Rahtz for their invaluable problem-solving assistance during the development of the 2010 RNG schema. Thanks to Sebastian Rahtz and James Cummings of the Text Encoding Initiative (TEI) for their help with making ODD work with MEI, their assistance in more closely aligning MEI and TEI, and their quick responses to questions and Roma bug reports.

Finally, the members of the Music Encoding Initiative would like to thank Perry Roland for his foresight, engagement and dedication in laying the foundations of this initiative.

Release 5.0 of MEI focuses primarily on the guidelines, development infrastructure, and consistency, with only limited changes to the specifications. Perhaps the most important additions are the introduction of the MEI Basic customization, and the availability of an auto-generated PDF version of the Guidelines (see below for more details on both). The Release Managers for MEI 5.0 were the Technical Co-Chairs, Benjamin W. Bohl and Stefan Münnich.

A music notation document is one that contains music notation; that is, any one of a number of "visual analogues of musical sound, either as a record of sound heard or imagined, or as a set of visual instructions for performers." (Ian D. Bent, et al. "Notation." Grove Music Online. Oxford Music Online. 25 May 2010. http://www.oxfordmusiconline.com/subscriber/article/grove/music/20114.) However, MEI’s understanding is more inclusive than this restrictive definition, i.e., Braille certainly qualifies as music notation documents.

The encoding scheme permits both the creation of new music notation documents and the conversion of existing ones from print and other electronic formats. However, conversion of existing documents may require revisions in content or rearrangement of information.

MEI may be used to encode both primary sources of music notation, such as an autograph or published score, and secondary sources, such as a scholarly edition based on one or more primary sources. The format encompasses both use cases, and the encoder must choose the elements and attributes most appropriate in each case. These Guidelines aim to provide guidance on that task.

As an encoded representation of one or more music notation documents, an MEI file may be employed as a surrogate for the original materials.

Although the encoding scheme does not define or prescribe intellectual content for music notation documents, it does define content designation and is intended to be used with available data content standards. MEI identifies the essential data elements within music notation documents and establishes codes and conventions necessary for capturing and distinguishing information within those elements for future action or manipulation. While there are a few elements that ought to appear in any MEI document, various intellectual, technical, and economic factors influence the level of detail of analysis and encoding actually undertaken. Taking this into consideration, the encoding scheme is designed with a minimum of required elements and allows for progressively more detailed levels of description as desired.

The encoding scheme preserves and enhances the current functionality of existing music notation documents. It permits identification of document structures and content that support description, navigation, analysis, and online and print presentation.

The encoding scheme is intended to facilitate interchange between notational tools. It aims to assist in the creation of more effective and consistent encoding, encourage the creation of cooperatively-created and widely available databases of music notation documents, and permit the reuse of encoded data for multiple output purposes. It will also ensure that machine-readable music notation documents will outlive changing hardware and software environments because they are based on a platform-independent standard.

The encoding scheme is based on eXtensible Markup Language (XML), a text-based format for representing structured information. It is expressed as a One Document Does-it-all (ODD) document. For more information on ODD, please refer to .

Related or complementary standards, such as the Text Encoding Initiative (TEI) Guidelines for Electronic Text Encoding and Interchange, the Encoded Archival Description (EAD), MARC 21 Format for Bibliographic Data, existing notation encoding schemes, etc. have been consulted and employed as appropriate. For example, the data model includes a header that is comparable to the TEI header, and TEI and EAD naming conventions and tag structures have been used whenever feasible. However, while some feature names are similar, or even the same, it is important to recognize that MEI and TEI have different semantic scope. Obviously, a note element in MEI does not carry the same meaning as the element of the same name in TEI. Perhaps less obviously, a phrase in music notation is unrelated to a textual phrase.

With respect to metadata, MEI recognizes the close relationship between the metadata content found in the MEI header and that of catalog records, authority records, and finding aids. Therefore MEI provides ways of indicating in the encoding the corresponding fields of other metadata standards.

To ensure broad international and multi-repertoire application of MEI, existing musical terminology was used in building the data model where practical. When appropriate, a more neutral terminology was used to facilitate sharing of concepts and thus stressing the commonalities between different repertoires. Finally, extensive use of attributes and clearly-defined classification mechanisms in the schema permits the refinement of element meanings within specific musical, geographic, or temporal contexts.

The Music Encoding Initiative Community has given itself By-laws, which regulate all essential properties and procedures. The community elects a Board, which in turn governs and represents the community. The Board consists of nine elected members, with three seats standing for election for three year terms each year. Everyone registered to the MEI-L mailing list is eligible to vote for the Board.

In addition to the Board, there is a Technical Team, which is open for anyone interested to work on the maintenance and improvement of MEI itself. The Technical team will assist Interest Groups and other interested community members in an advisory capacity on how to further develop MEI for both existing and new fields of application.

The term "music" has many different notions, ranging from audible sounds over written performance instructions or transcriptions of such events to conceptual rulesets that establish different theories of what music is, and what is allowed in music. In 1965, Milton Babbitt distinguished between graphemic, acoustic and auditory aspects of music (Babbitt, Milton: The Use of Computers in Musicological Research, in: Perspectives of New Music 3/2 (1965), p. 76).

Various music encoding formats took up this distinction, most notably SMDL, the Standard Music Description Language (ISO/IEC DIS 10743). While the format itself was hardly ever used for its impractical implementation details, parts of its design certainly influenced the development of other formats, including MEI. In a documentation draft (http://xml.coverpages.org/smdl10743-pdf.gz, p.5), SMDL identifies four different musical domains:

On a generic level, MEI follows the same definition, and it definitely shares the same terminology. However, not all four domains are available throughout the MEI schema, and quite frequently, two domains fall together in MEI. Very often, MEI prioritizes the visual domain over the gestural domain by (partly) conflating the logical and the visual domains. For example, MEI utilizes the pname (pitch name) attribute on notes to capture the written pitch of a note, whereas the sounding pitch may be described with the pname.ges attribute. Here, the logical and visual domains go without a special indication, whereas the gestural domain is identified by a special suffix. However, in case of transposing instruments, additional markup (namely the attributes trans.diat and trans.semi from MEI’s attribute class att.staffDef.log) will create a distinction between the logical and visual domain (see chapter ). In that case, pname will be restricted to the visual domain, while the logical aforementioned attributes provide additional information for the logical domain.

Even though the technical implementation of MEI prioritizes the visual domain to some degree, this does not mean that any given encoding has to provide visual information. MEI takes no assumption on what data is required: While an OMR project (optical music recognition) may generate strictly visually oriented data only, another project focussed on audio transcriptions may generate gestural data only. A third project could integrate both approaches.

In order to avoid ambiguous encodings, MEI is very strict and specific on the scope of its individual markup elements. For an encoder, the suffixes mentioned above provide clear hints on which domain is addressed by specific markup: Many attributes carry a suffixed .log (logical), .ges (gestural), .vis (visual), or .anl (analytical) in their name. In addition, the internal structure of MEI heavily relies on those different domains. When customizing MEI (see chapter ), it is possible to turn off either visual or gestural domain encoding completely. That way, MEI allows to address the four most eminent musical domains specifically and independent of each other.

MEI differentiates between two essential aspects of music notation: Events and ControlEvents. There are other examples for such a separation of concerns with regard to music. In Greg’s Copy-Text Theory (W.W. Greg: The Rationale of Copy-Text, 1950), a distinction between primary and secondary text is made; similar attempts have been made for music specifically.

In MEI, elements describing the basic musical text are referred to as Events. They are the building blocks for the stream of music – mostly those are notes, rests, and chords. In contrast, ControlEvents make no independent contribution to that flow of music. Instead, they provide additional information about the encoded Events, they control their performance. Examples for such ControlEvents are dynamic markings, tempos indications, or performance directives. Depending on the encoding strategy used, slurs and ties often also fall into this category (they may be encoded as attributes instead, in which case they become a property of the basic events). Simply put, Events describe what needs to be performed, and ControlEvents indicate how it needs to be performed. In (-based) MEI, Events are nested inside a layer element, while ControlEvents are direct children of the first measure they apply to, following all staff elements there. These structural differences result in different markup concepts. As Events are encoded inside layers, their semantic position inside the encoded work can be derived from their structural position – the measure, staff and layer they're nested in, and within that layer by their position inside the sequence of all layer children. As mentioned above, it is highly recommended to encode ControlEvents inside the first measure they apply to, but they still require references to the actual events they apply to. There are two common concepts to provide such a connection, both of which offering specific benefits and drawbacks. A technically very stable connection between ControlEvents and Events can be established by using pointers. In this case, all events that need to be referenced need an xml:id attribute, which holds a globally unique identifier for this very element. The referencing controlevent then uses a startid and, if necessary, endid attribute to create a link to where in the stream of music it is supposed to start or end.

In the example above, the dynam element references the second quarter in the given measure. Additional attributes like place may be used to describe the position of the forte indication within the score. A hairpin element may use the endid attribute to indicate the duration of the hairpin using the same mechanism as above.

A ControlEvent encoded like above will be strictly tied to the referenced Events – if their position inside the XML document changes for whatever reason, they will keep that connection. This means that the semantic position to which they are bound may change without affecting the binding. An example could be an inserted additional note in front – the dynamic marking would not start on the second quarter, but perhaps on the third instead.

As this behavior may not be desired in all cases, an alternative binding between ControlEvents and Events is possible, relying on timestamps instead. This mechanism is illustrated in the following example:

Here, no xml:id is required on notes. Instead, the dynam element uses the staff and layer attributes to indicate to which set of events the following tstamp attribute refers to.

This mechanism actually depends on what has been only recommended above: placing the controlevent inside the measure where it starts. The startid reference mechanism would work equally well if all controlevents where positioned in the very first or last measure, or actually even inside a separate file. The tstamp references however would not, they depend on correct placement of the controlevents inside the XML tree. For consistency, it is therefore recommended to always use this placement.

The benefit of this concept is that controlevents are tied to a semantic position, but not necessarily to a given XML element. The forte may still be placed on the second quarter, even though the composer may have replaced that quarter G4 with a different pitch and / or duration. Actually, it is not required that an Event can be found at the position indicated by a timestamp. This may be useful to encode a slur ending at an arbitrary position between two events, or dynam markings spread across otherwise empty measures.

If the ending of a ControlEvent shall be given by timestamp, the tstamp2 attribute is used.

Because of potential inconsistencies, an encoding should not offer both startid and tstamp or endid and tstamp2. Though not being recommendable, it is possible to mix startid with tstamp2 and tstamp with endid. In general, it is easier for software to process startid and endid. When no other arguments apply, using xml:id-based pointers is therefore the most common way to connect ControlEvents with Events.

The details on how timestamps are calculated and used in MEI are given in .

In MEI, timestamps are treated in a slightly simplified way: they have no notion of beat. Instead, timestamps rely solely on the numbers given in the meter signature. In a measure of 4/4, timestamps will range from 1 to 4. The second eighth note will be 1.5 in this case. If the same measure would be given in 2/2, it would be 1.25 instead.

At this point, MEI uses real numbers only to express timestamps. In case of (nested or complex) tuplets, this solution is inferior to fractions because of rounding errors. It is envisioned to introduce a fraction-based value for timestamps in a future revision of MEI. For now, it is recommended to round the fractional part of the number to no more than five digits to avoid such problems.

Durations may also be expressed based on timestamps. In this case, the values are a combination of the count of measures that need to be moved forward to reach the measure in which an encoded feature ends, and the timestamp within that measure.

The following example contains a number of slur examples illustrating durations expressed by timestamps.

Sometimes, timestamps are used to indicate positions where no music Events are located (see ). Therefore, the allowed range of timestamps stretches from 0 to the current meter count + 1. By definition, a timestamp of 1 indicates the position of the left bar line, while a timestamp of 5 (in case of a 4/4 meter) indicates the right bar line. This makes it possible to encode open-ended slurs in a graphical way. However, it should be kept in mind that such timestamps may not be converted to startid and endid, and not every application may be able to render them correctly, even though they are perfectly valid MEI, and sometimes are necessary to faithfully transcribe a source.

MEI is an encoding framework, not a data format. This means that MEI provides recommendations for encoding music documents, but it depends on the encoder's needs and requirements to which features and solutions are appropriate to the task and should be used. MEI offers specific models for different notation types and music repertoires, but it is rarely advisable to use them all side by side in one encoding.

In order to use MEI, it is advised to use a restricted version of the schema, which will make it easier both for an encoder and a reader of the encoded files. MEI provides a number of pre-defined profiles, which focus on specific uses of MEI while still maintaining a great level of flexibility. For projects that need even better control over their data, it is highly recommended to create a more specific customized version of MEI (see chapter ). The following customizations are provided with every release of MEI:

The first three profiles provide good starting points to encode music from the respective repertoires. They may also serve as template for further, project-specific customizations. The latter two profiles target very specific use cases and should not be used by default.

In production, it is best to use a customized version of MEI, restricted to the very needs of a project. Such a custom schema will guide the encoders and will help to ensure consistency and data quality throughout a project’s files. A customization typically provides a subset of MEI’s encoding models (typically starting from one of the official profiles mentioned in chapter ), with only one solution for any given situation being allowed. The customization will help to reflect the scope of a project into its data: Only those aspects of music notation a project is interested in will be allowed, so that the absence of a specific information can not be misunderstood as an oversight of the encoders. Larger editorial projects like Complete Works editions typically use Editorial Guidelines (german: Editionsrichtlinien) for the same purposes: (internal) quality control and (external) documentation. In that sense, MEI customizations may serve as Editorial Guidelines in digital form.

MEI is implemented in ODD. ODD, or One Document Does-it-all, is another XML-based markup language developed and maintained by the TEI. TEI's documentation for ODD can be found in the TEI Guidelines chapter 22: Documentation Elements, chapter 23: Using the TEI, and the "Getting Started with P5 ODDs" document.

At this point, there is no specific documentation on how to customize MEI with ODD beyond the generic TEI documentation. However, the provided are based on ODD customizations, and may serve as starting point for further project-specific restrictions. They can be found at https://github.com/music-encoding/music-encoding/tree/v5.0/customizations. In addition, several projects have shared their customizations on GitHub, such as Freischütz Digital or Beethovens Werkstatt.

MEI provides a web service at http://custom.music-encoding.org which allows to compile such customizations against the MEI sources in order to generate RelaxNG schemata, which can be used for validation. More documentation on customizing MEI will be provided as time permits; until then, it is recommended to reach out to the MEI Community for additional assistance.

MEI defines four elements qualifying as root elements (i.e., the element containing everything else) of an MEI document; the most common of these are defined in the MEI.shared module:

The most straightforward – and probably the most common choice fitting most of the use cases when encoding music – is the mei element. It contains an meiHead element for capturing metadata and a music element for describing the musical text. A more detailed description of the application of music can be found in the course of this section (see ). If you want to learn more about the use of the meiHead element – formally declared in the MEI.header module – please visit the chapter in the section.

The below example shows the basic structure of an MEI file with mei as root element. Please be aware that this example still does not represent a valid MEI file:

The other potential root elements serve different use cases or purposes.

A document with music as root element provides music notation markup without metadata, and could serve embedding MEI within other kinds of markup, e.g., TEI (see ).

The below example shows the basic structure of an MEI file with music as root element. Basically this already represents a valid MEI file, although without any contents:

meiCorpus contains an meiHead element describing a collection of related MEI-encoded texts – known as a corpus – and an mei element for each text. Further information regarding the organization and encoding of music corpora is given in chapter .

The below example shows the basic structure of an MEI file with meiCorpus as root element. Please be aware that this example still does not represent a valid MEI file:

The meiHead element, formally declared in the MEI.header module, is described in chapter . A document with meiHead as root element only contains metadata and is also known as an independent or stand-alone header. Stand-alone headers are more fully described in chapter .

The below example shows the basic structure of an MEI file with meiHead as root element. Please be aware that this example still does not represent a valid MEI file:

The above examples all carry two attributes on their root elements. While the xmlns is a general feature of XML and not defined in MEI it is crucial for stating the fact that it is an MEI file you are dealing with. The second attribute is att.meiVersion.

Although not required the att.meiVersion attribute is important for defining a stable reference to a specific MEI-version used in the enclosed encoding, and thus is highly recommended on your root element.

As indicated above, the general place for encoding the musical text is the music element. MEI.shared offers two possible child elements:

While body holds the contents of a single musical text, group allows the textual body to consists of a series of (subordinate) musical texts or other e.g., 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 . Whether the musical text being encoded should be structured one way or the other is not to be decided here. 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.

There are several more possible child elements of the music element defined in other modules of MEI, such as front and back elements (defined in MEI.text module, cf. ), performance (defined in MEI.performance module, cf. ), genDesc (defined in MEI.genetic module, cf. ), facsimile (defined in MEI.facsimile module, cf. ).

Please be aware that the following examples still do not reflect valid MEI files as they are missing some required elements not defined in the MEI.shared module.

The basic structure of a unitary musical text:

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:

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

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.

This section introduces the elements that can be used to represent document layout features in MEI, be it for the sake of capturing an original source's layout when transcribing or setting up layout features in so called ‘born digital’ documents.

The pb element can be used to mark page beginnings. When transcribing an existing document the n attribute should be used to record the page number displayed in the source. It need not be an integer, e.g., 'iv', or 'p17-3'. The logical page number can be calculated by counting previous pb ancestor elements. When used in a score context, a page beginning implies an accompanying system beginning. This element is modelled on an element in the Text Encoding Initiative (TEI) standard.

Additional information can be provided on page beginnings. Ranging from a prose description of the page layout in pgDesc to defined headers and footers.

"Forme work" is the name for running elements (page headers and footers). Both pgHead and pgFoot have a func attribute that allows encoders to specify to which page(s) the forme work element applies. This includes alternating patterns.

Columned layout can be captured with the following elements:

In order to force a system break in the musical text sb can be used.

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 .

The MEI.shared module provides basic text structure elements.

A detailed description of their use and of other elements from the MEI.text module can be found in the corresponding chapter .

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

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 .

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

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 . For mensural notation, see chapter , and for neumatic notation, chapter .

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

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

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.

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.

The most general attributes that are very frequently encountered in MEI files are not even native MEI attributes but are coming from the basic definition of XML in the XML-namespace http://www.w3.org/XML/1998/namespace. MEI redefines some of them in the att.basic class.

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 xml: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:

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

At many locations in an MEI file one can reference internal or external references. E.g. the following example defines a graphic and references an external image (entity) by means of the target attribute:

When a reference to an external entity is not a complete URI it is resolved against the current base URI; if not defined by other means this would be the location of the current document. The above example consequently would mean, that the file `myImage.jpg` referenced from graphic resides at the same location (in the same folder) as the MEI-file.

The xml:base attribute may be used “to specify a base URI other than the base URI of the document or external entity.” (Marsch, Jonathan; Tobin, Richard: XML Base (Second Edition). W3C Recommendation 28 January 2009. online at: http://www.w3.org/TR/2009/REC-xmlbase-20090128/).

The value of xml:base can be inherited from an ancestor. This is relevant for resolving relative links or URIs within the document. A comprehensible use case can be illustrated by the following example: the values of the graphic elements' target attribute can be completed by the xml:base value specified for the ancestor facsimile element:

In order to determine an absolute URI, the base URIs of the element and all its ancestors (including the document node) have to be taken into account. In the above case the relative URIs of graphic/@target would consequently resolve to:

``` http://www.mySite.org/images/myImage.jpg http://www.mySite.org/images/myImage.tif ```

For more information on xml:base see: https://www.w3.org/TR/xmlbase/

The xml:id and xml:base attributes are especially important when it comes to linking document fragments to each other or to external entities. Many of the linking attributes are globally available in MEI through the att.common attribute class.

Yet there are other attributes from the XML-Namespace encountered in MEI files.

While xml:lang attribute may be used to encode the language of an element's contents, the xml:space attribute lets you define the handling of whitespace, i.e., whitespace being important content (preserve) or negligible (default). With the latter also being the default value if no xml:space attribute is present.

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.

For a detailed description of linking mechanisms used in MEI also see the section on .

The module described in this chapter makes available the following components:

The elements provided by the usersymbols module may be used in two ways:

For this purpose, it provides three elements as graphic primitives, line, curve and anchoredText. Anywhere these elements are allowed, the symbol element can be used as well. The symbol element facilitates the re-use of symbols that were defined by symbolDef elements.

The form attribute of the line element may take the following values:

These attribute values are only qualitative. Actual dash length and dot and dash spacing are implementation dependent.

The width attribute may take the following values:

These values are also qualitative, however, they are also relative. That is, 'narrow' is the default value, 'medium' is twice as wide as 'narrow', and 'wide' is twice as wide as 'medium'.

In addition to textual values, the width attribute may contain a numeric value and an optional unit, e.g., 2mm. If the unit value is not provided, MEI virtual units are presumed.

The same applies for curve elements with the lform and lwidth attributes from the att.lineRend.base class.

The startsym and endsym attributes name the symbol that may start and/or end a line, while startsymsize and endsymsize indicate the relative size of the symbol using a numeric value in the range from 1 to 9.

The usersymbols module does not currently support continuous composite lines or filled areas. As mentioned above, the rendition of lines is highly implementation dependent. Coordinate system transforms are restricted to scaling using scale.

The titleStmt element is to capture the title of an MEI file (within a fileDesc element) and the title of any of the relevant manifestations (sources) of the encoded work.

The title statement contains the title given to the electronic work, together with one or more optional statements of responsibility which identify the encoder, editor, author, compiler, or other parties responsible for it:

The title element contains the chief name of the electronic work. Its content takes the form considered appropriate by its creator. The element may be repeated, if the work has more than one title (perhaps in different languages). Where the electronic work is derived from an existing source text, it is strongly recommended that the title for the former should be derived from the latter, but clearly distinguishable from it, for example by the addition of a phrase such as ‘: an electronic transcription’ or ‘a digital edition’. This will distinguish the electronic work from the source text in citations and in catalogs, which contain descriptions of both types of material.

Other alternative titles or subtitles may be encoded in additional title elements with values in the type attribute that distinguish them from the chief title. Sample values for the type attribute 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 analyzing 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, as in the following example:

The electronic work will also have an external name (its ‘filename’ or ‘data set name’) or reference number on the computer system where it resides at any time. This name is likely to change frequently, as new copies of the file are made on the computer system. Its form is entirely dependent on the particular computer system in use and thus cannot always easily be transferred from one system to another. Moreover, a given work may be composed of many files. For these reasons, these Guidelines strongly recommend that such names should not be used as the title for any electronic work.

Helpful guidance on the formulation of useful descriptive titles in difficult cases may be found in the Anglo-American Cataloguing Rules (Gorman and Winkler, 1978, chapter 25) or in equivalent national-level bibliographical documentation.

It is important to keep in mind that the titleStmt element provides structured metadata. Preserving the exact rendition of a title page is possible using the titlePage element (see ).

The title of a work is given by using the title element directly, as many other child elements of titleStmt are available on work directly.

In scholarly work, attribution of responsibility is crucial. For this purpose, MEI offers the respStmt element, which is available in the following contexts:

At a minimum, the creator of the musical text and the creator of the file should be identified. If the bibliographic description is for a corpus, identify the creator of the corpus. Optionally also include the names of others involved in the transcription or elaboration of the text, sponsors, and funding agencies. The name of the person responsible for physical data input need not normally be recorded, unless that person is also intellectually responsible for some aspect of the creation of the file.

In traditional bibliographic practice, those with primary creative responsibility are given special prominence. MEI accommodates this approach by providing responsibility-role elements. For example:

Secondary intellectual responsibility in this case is encoded using respStmt. The respStmt element has two subcomponents: a name element identifying a responsible individual or organization, and a resp element indicating the nature of the responsibility. All names should be stated in the form in which the persons or bodies wish to be publicly cited. This will usually be the fullest form of the name, including first names. No specific recommendations are made at this time as to appropriate content for resp. However, it should make clear the nature of the responsibility.

This method of encoding facilitates exchange of bibliographic data with library catalogs and bibliographic databases as well as applications whose handling of bibliographic data is restricted to traditional responsibility roles. Additional information regarding these responsibility-role elements can be found in chapter .

When the MEI.namesdates module is enabled, two additional elements are also permitted within respStmt:

These elements allow for more precise identification of the entity associated with the name than is permitted by the simpler name element. The following example shows how a precise date range can be associated with a personal or corporate name.

For additional information about corporate and personal names, see chapter .

In addition to, or instead of the resp element, the role attribute on name, persName, and corpName may be used to capture the nature of responsibility. While resp accommodates capturing the wide variety of text that may occur in responsibility statements, use of the role attribute provides the possibility of recording a controlled value independently of the textual content of resp.

Values from the MARC relator code list (http://www.loc.gov/marc/relators/relacode.html) or term list (http://www.loc.gov/marc/relators/relaterm.html) are recommended for role, where applicable.

Where it is necessary to group responsibilities and names, multiple responsibility statements may be used. For example:

It is often desirable to mix primary and secondary intellectual responsibility information. Treating all intellectual roles the same way can allow literal transcription of existing responsibility statements and simplify programmatic processing. The following example demonstrates how a responsibility statement may be transcribed using interleaved resp and persName elements:

However, eliminating explanatory text and relying on standardized values for role, as in the following example, allows data creation and processing tools of the greatest simplicity.

The structure of the bibliographic description of a machine-readable or digital musical text resembles that of a book, an article, or other kinds of textual objects. The file description element of the MEI header has therefore been closely modelled on existing standards in library cataloging; it should thus provide enough information to allow users to give standard bibliographic references to the electronic text, and to allow catalogers to catalog it. Bibliographic citations occurring elsewhere in the header, and in the text itself, are derived from the same model.

The bibliographic description of an electronic musical text should be supplied by the mandatory fileDesc element:

The fileDesc element contains two mandatory and six optional elements, each of which is described in more detail below. These elements are listed below in the order in which they must occur within the fileDesc element.

A complete file description will resemble the following example:

The encodingDesc element is the second major subdivision of the MEI header. It specifies the methods and editorial principles which governed the transcription or encoding of the source material. Though not formally required, its use is highly recommended.

The encoding description may contain elements taken from the model.encodingPart class. By default, this class makes available the following elements:

Each of these elements is further described in the appropriate section below.

The final sub-element of the MEI header, the revisionDesc element, provides a detailed change log in which each change made to a text may be recorded. Its use is optional but highly recommended. It provides essential information for the administration of large numbers of files which are being updated, corrected, or otherwise modified as well as extremely useful documentation for files being passed from researcher to researcher or system to system. Without change logs, it is easy to confuse different versions of a file, or to remain unaware of small but important changes made in the file by some earlier link in the chain of distribution. No change should be made in any MEI-conformant file without corresponding entries being made in the change log.

The main purpose of the revision description is to record changes in the text to which a header is prefixed. However, it is recommended practice to include entries also for significant changes in the header itself (other than the revision description itself, of course). At the very least, an entry should be supplied indicating the date of creation of the header.

The log consists of a list of change elements, each of which contains a detailed description of the changes made. If a number is to be associated with one or more changes (for example, a revision number), the n attribute may be used to indicate it. The person responsible for the change and the date of the change may be indicated by the respStmt and date elements. The description of the change itself is contained within the changeDesc element, which can hold one or more paragraphs.

It is recommended to give changes in reverse chronological order, most recent first.

For example:

A slightly shorter form for recording changes is also available when a the date of the change can be described by a single date in a standard ISO form and when the name of the agent(s) responsible for the change, encoded elsewhere in the header, can be referred to by one or more URIs given in the resp attribute. For example:

With the FRBR module, MEI offers four elements corresponding to the FRBR "Group 1" entities:

The names of the MEI entities follow those of FRBR: the work element is a container for description at the FRBR "work" level, expression is for description at the FRBR "expression" level, manifestation contains "manifestation" level description, and item holds FRBR "item" level description. Please note: Until MEI 3.0.0, the source element in sourceDesc was used for manifestation-level descriptions.

The work element has an optional child element to hold the expression elements:

As expressionList is a container element for descriptions of different expressions of the same work, it may contain only

expression elements.

The content model of expression is similar to that of work. It does not, however, permit expressionList and audience elements. But it adds elements that aid identification and description of specific versions of a work:

Since expressions, like works, are abstractions, their titles are often nebulous. Usually, however, the title of an expression is the same as the work it represents. When the relationship between a work and an expression is encoded hierarchically, the expression’s title element may be omitted with the assumption that it will be inherited from the work. If no title is provided for an expression, distinguishing characteristics must be provided in other elements, such as perfMedium, as in the following example:

Programmatic concatenation of the work title and one or more characteristics of the expression can be used to provide identification for the expression. For example, the expressions above may be identified by "Pavane pour une infante défunte (piano)" and "Pavane pour une infante défunte (orchestra)". In some cases, it may be helpful to assign a descriptive title to the expression, as illustrated below. The carrier of the manifestation is often a good source of this kind of descriptive text.

The manifestationList and manifestation elements are discussed in section .

The itemList element provides functionality similar to that of expressionList; that is, it can be used to group descriptions of individual items (exemplars) of the parent source. Just like expressionList, which can only hold expression sub-components, itemList may only contain item elements.

Each of the four MEI elements corresponding to FRBR entities may contain a list of constituent parts. All four entities utilize the same element:

However, the child elements of a component group must be the same type as the group’s parent. This allows for a more detailed description than is possible using the core MEI contents element. For example, a work element’s componentList element can only contain work elements, etc. In this way, the componentList element may be employed to describe composite works, as in the example below:

This technique can also be applied when a single intellectual source is comprised of multiple physical parts. In the following example, the choral parts were published in four physically separate "signatures":

FRBR defines a number of terms that describe how the basic entities relate to each other. MEI provides the following elements for this purpose.

Each of the four FRBR entity equivalents – the work, expression, source, and item elements – allows a list of such relationship descriptions as its last child element. relationList provides a container for individual relation elements. The nature of the relationship must be specified by the rel attribute and the target of the relationship must be identified by the target attribute. The values allowed by rel follow those defined for FRBR at http://www.ifla.org/files/assets/cataloguing/frbr/frbr_2008.pdf.

Since relations are bidirectional, they may be defined on both entities involved, using pairs of oppositely-directed relation descriptors. The following FRBR relations are allowed in MEI as values of the relation element’s rel attribute (shown in pairs for clarity):

Some of these relationships are already implicitly expressed by the MEI structural model: FRBR defines an expression entity as a realization of a work, but as this relation is implied by the expressionList element’s child relationship to its parent work element, the hasRealization/isRealizationOf relation does not need to be explicitly declared. Likewise, it is not necessary to specify by means of relation elements that an item is an exemplar of the source described by its parent source element. This resembles the FRBR model, which allows 1:n relationships both between works and expressions, and between manifestations and items.

However, as FRBR allows n:n relations between expressions and manifestations (in MEI: sources), a hierarchical model based on the structure of XML is clearly insufficient to express all possible expression / manifestation combinations. It is therefore required to declare these relations explicitly. In FRBR terms, a manifestation / source is an embodiment of an expression.

Within the componentList element, the order of child elements implicitly describes a hasSuccessor/isSuccessorOf relationship between components, i.e., it defines a certain sequence such as the movements of a work. In other cases, relation elements may be needed to explicitly encode relationships not otherwise defined by encoding order or hierarchy. For instance, the hasReproduction/isReproductionOf relationship may be used to indicate that one source is a reprint of another.

Moreover, the use of componentList implicitly defines a hasPart/isPartOf relationship between the componentList element’s parent and its child elements. Using the relationList and relation elements to define their relationship, the four component works in the "Der Ring des Nibelungen" example above could alternatively be encoded as sibling work elements to the "Ring" work element.

Relations may also be used to point to external resources. For instance, each of the individual component works of the "Ring" could be encoded in separate files, with relations pointing to them.

In the file "ring.xml":

In the file "rheingold.xml":

MEI offers two related concepts for capturing relations between bibliographic items. The model of relatedItem, as described in chapter of these Guidelines, is derived from MODS v3.4 (see documentation here). Its purpose in MEI is to encode bibliographic references between mostly "secondary" material, like reviews, articles, and so on. It may be used to provide cross-references between information encoded in different places of the header.

However, relatedItem is less ideal for describing the relations between works, differing versions of these works, the sources in which those versions are transmitted, and where applicable the individual copies of a print. For these situations, it is strongly recommended to use the instead. This module is based on the Functional Requirements for Bibliographic Records, as specified by the IFLA. It allows a much finer description of relationships between such "primary" entities. For compatibility reasons, both models should not be confused or mixed under any circumstances.

The following elements provide minimal identifying information for the intellectual work:

The identifier and title values recorded here may or may not be the same as those assigned to published versions of the work. Fuller details are available in section .

The first few notes and/or words of a piece of music are often used for identification purposes, especially when the piece has only a generic title, such as "Sonata no. 3". They appear in catalogs of music and in tables of contents of printed music that include multiple works.

The following elements are provided for the inclusion of incipits:

The elements incipCode and incipText are available for the inclusion of coded incipits of music notation and textual incipits, respectively. The incipText element should contain only the initial performed text of the work, while incipCode may contain both words and music, depending on the capabilities of the scheme used to encode it. When both music and text are provided in incipCode, it may be helpful to repeat the text in incipText in order to provide easier access to only the text, for example, for indexing of the text without having to extract it from the coded incipit.

Both incipCode and incipText allow reference to an external file location via the target attribute and specification of the internet media type of the external file via the mimetype attribute.

An MEI-encoded incipit may be captured in a score sub-element.

In addition, graphic may be used as a sub-element of incip to include an image of an incipit.

To facilitate the capture of metadata associated with an incipit, MEI allows the following sub-elements within incip. The order of their presentation below follows the order in which they must appear in this context.

Usually, the metadata captured in this manner is rendered alongside or in lieu of a coded or graphical incipit. It may or may not serve in a work identification capacity, depending on whether the incipit is intended to represent the entire work or a segment of the work. For example, if an incipit is provided for each aria in an opera, then the metadata pertains only to the aria, not the entire work.

The attributes key, tempo, and meter are often helpful for identifying a musical work when it does not have a distinctive title.

The key element is used exclusively within bibliographic descriptions. Do not confuse this element with keySig, which is used within the body of an MEI file to record this data for musical notation. Likewise, meter should not be confused with the attributes used by staffDef and scoreDef to record meter-related data for notated music. The tempo element can be used here as well as in the body of an MEI document; however, its attributes other than xml:id, label, n, base, and lang are meaningless in the MEI header context, and therefore should be avoided within a work description. The mensuration element is available for the description of works in the mensural repertoire. When a work uses meter and mensural signs, both mensuration and meter elements may be used.

Additional information that aids the identification of the work may be encoded using otherChar.

The following components provide detailed information about the work’s context, including the circumstances of its creation, the languages used within it, high-level musical attributes, performing forces, etc.

The following elements are provided to capture the history of a musical work:

The creation element is intended to contain a brief, machine-processable statement of the circumstances of the work’s creation. Its content is limited to text and the date and geogName elements.

The history element is a container for additional non-bibliographic details relating to a work. It may use the eventList element to provide a list of key events in the creation and performance history of the work. The eventList element is comprised of event elements containing a brief description of the associated event, including dates and locations where the event took place. An event list may use the type attribute to distinguish between multiple event lists with different functions, such as a list of events in the compositional process and a list of performance dates.

Event lists and other text components, such as paragraphs, tables, lists, and text divisions (div) may be interleaved when an 'essay-like' work history is desired.

The event element permits either a text-centric or a data-centric model. The text-centric model is provided for prose descriptions, while the data-centric model accommodates event descriptions that consist of a collection of descriptive phrases. In the text-centric model, paragraphs, tables, and lists may be used. In the data-centric model, however, only certain phrase-level elements, may appear.

The langUsage element is used within the workList element to describe the languages, sublanguages, dialects, etc. represented within a work. It contains one or more language elements, each of which provides information about a single language.

A language element may be supplied for each different language used in a document. If used, its xml:id attribute should specify an appropriate language identifier. This is particularly important if extended language identifiers have been used as the value of xml:lang attributes elsewhere in the document.

Here is an example of the use of this element:

The following elements are available for description of a composition’s performing forces:

The perfMedium element provides the possibility of describing a work in terms of its medium of performance; that is, the performing forces required. In the case of a dramatic work, the dramatis personae and associated voice qualities may be enumerated using castList. The perfResList element describes the necessary instrumental and vocal resources.

The intended audience for the work and additional information about context for the work that is not captured in more specific elements elsewhere, such as history and its sub-components, may be recorded in the audience and context elements.

Often, it is helpful to identify an entity by listing its constituent parts. A simple description of the work’s content, such as may be found in a bibliographic record, can be given in single paragraph element:

Alternatively, a structured list of contents may be constructed using the contentItem element:

Each contentItem element may be preceded by an optional label:

To reference a contents list in an external location, use the target attribute:

To facilitate the creation of music catalogs based on MEI header information, contents may contain a heading:

The biblList element allows citation of bibliographic evidence supporting assertions made within other sub-components of the work description.

The notesStmt element may be used within the description of the musical work to capture information not accounted for by the other elements of the description.

Within work, the classification element is used to classify the work according to some classification scheme. More generally, classification may be used to classifiy any FRBR entity (work, expression, manifestation, or item). The following elements are provided for this purpose:

The termList element categorizes the parent entity by supplying a set of terms which may describe its topic or subject matter, its physical or intellectual form, date, etc. Each term is indicated by a term element. In some schemes, the order of items in the list is significant, for example, from major topic to minor; in others, the list has an organized substructure of its own. No recommendations are made here as to which method is to be preferred. Wherever possible, such terms should be taken from a recognized source. In its simplest form, the term element just contains a descriptive keyword.

The class attribute may be used on each term element to make reference to a classification scheme (declared in the classDecls element) from which it is drawn.

Alternatively, class may be used on termList when all the contained terms come from the same source.

When the FRBR (Functional Requirements for Bibliographic Records) module is available, the following elements may be used within work to describe relationships between the work being described and other works or between the work and expressions of it:

For more information about FRBR and the use of these elements, see chapter .

The acquisition element is a container for recording the process of the acquisition of an item by the holding institution. In comparison, provenance deals with the history of ownership or custodianship of an item. Both elements allow for the choice of either text or more structured information when formulating the specific encoding. It is recommended to make use of p elements when a text-centred encoding is favored and to use the eventList element for a more structured encoding. It is up to the encoder to decide where the information is most appropriate for the particular project or encoding purposes.

The exhibHist element contains descriptions of one or more public exhibitions of a bibliographic item. Often exhibitions include an additional description in the form of a tag for the public that accompanies the item on display. These descriptions may even be printed in a published exhibition catalogue, so the encoding may also include information about why the object was shown or what was significant about the exhibition. When formulating the encoding, it is at the discretion of the encoder whether to opt for text or more structured information. Text-centred encoding is made possible by p elements in exhibHist, among others. For more structured encodings, it is recommended to use the eventList element contained in exhibHist. In FRBR-based cataloging (see ), exhibHist is conceptually bound to the item-level. As an element it is not permitted at the work or expression level and only permitted at the manifestation level if the manifestation is a manifestation singleton.

The physLoc element encodes information related to, or associated with, the physical location of a bibliographic item. This includes, but is not limited to, the name of the holding institution, name or number of the building or room, or any shelfmarks, used for the purpose of retrieval. The level of detail or machine readability of the encoding is generally at the discretion of the encoder and may vary depending on the information available. The physLoc element may contain the following MEI elements:

The repository element contains a description of the institution or individual currently holding the bibliographic item. Its content is either prose or structured markup. The history element, on the other hand, is a container for additional non-bibliographic details regarding the physical location of an item. It may contain the elements acquisition, exhibHist or provenance, among others, to describe any events that coincided with a change of location, such as exhibitions, or change of custody.

The following example demonstrates how to structure detailed information about a repository (including the use of identifier):

Conservation activities are often necessary to ensure the long-term preservation and integrity of manuscripts or printed sources. These conservation activities might include interventions such as re-binding, restoration, or modifying paper chemistry. In MEI the treatHist element records any treatment history an item has undergone, and may even specify details of the individual treatment process. The treatHist element allows either text or structured information when formulating the specific encoding. It is recommended to make use of p elements when a text-centred encoding is favored and to use the eventList element for a more structured encoding. Like exhibHist, treatHist is conceptually bound to the item-level in FRBR-based encodings. The element is not permitted at the work or expression level and only permitted at the manifestation level, if the manifestation is a manifestation singleton.

Similar to the MEI treatHist element, the treatSched element is intended to hold records of conservation activities or treatments in regard to a bibliographic item. However, in contrast to treatHist, treatSched allows records of any anticipated activities, rather than simply a historical account of previous treatments. This might include any description indicating the quantity and frequency of the treatments. treatSched furthermore may also be used to indicate that no additions or treatments are to be expected. To that end, treatSched allows the option for either text or more structured information when formulating a specific encoding. It is at the discretion of the encoder to decide which specifics of the encoding are most appropriate.

Many libraries, repositories, research sites and related institutions collect bibliographic and documentary information about machine readable music documents without necessarily collecting the music documents themselves. Such institutions may thus want access to the header of an MEI document without its attached text in order to build catalogs, indexes and databases that can be used to locate relevant texts at remote locations, obtain full documentation about those texts, and learn how to obtain them. This section describes a set of practices by which the metadata headers of MEI documents can be encoded separately from those documents and exchanged as freestanding MEI documents. Headers exchanged independently of the documents they describe are called independent headers.

The following element is provided to accommodate non-MEI metadata:

The extMeta element may be contained by expression, item, manifestation, work and meiHead elements. It may include text and any number of well-formed XML fragments, XML comments, and CDATA sections, except for MEI markup, which is prohibited. The document element of each fragment must explicitly declare its namespace.

An MEI processor is not required to validate or otherwise process any markup within the extMeta element. Therefore, the extMeta element itself is the lowest level at which an association can be created between ‘foreign’ metadata and other MEI elements as described in section .

The MEI header allows for the provision of a very large amount of information concerning the text itself, its source, its encodings, and revisions of it, as well as a wealth of descriptive information, such as the languages it uses and the situation(s) in which it was produced, together with the setting and identity of participants within it. This diversity and richness reflects the diversity of uses to which it is envisaged that electronic texts conforming to these Guidelines will be put. It is emphatically not intended that all of the elements described above should be present in every MEI Header.

The amount of encoding in a header will depend both on the nature and the intended use of the text. At one extreme, an encoder may expect that the header will be needed only to provide a bibliographic identification of the text adequate to local needs. At the other, wishing to ensure that their texts can be used for the widest range of applications, encoders will want to document as explicitly as possible both bibliographic and descriptive information, in such a way that no prior or ancillary knowledge about the text is needed in order to process it. The header in such a case will be very full, approximating the kind of documentation often supplied in the form of a manual. Most texts will lie somewhere between these extremes; textual corpora in particular will tend more to the latter extreme. In the remainder of this section we demonstrate first the minimal, and then a commonly recommended, level of encoding for the bibliographic information held by the MEI header.

Supplying only the level of encoding required, the MEI header of a single text will look like the following example:

The only mandatory component of the MEI Header is the fileDesc element. Within this element, titleStmt and pubStmt are required constituents. Within the title statement, a title is required. Within the pubStmt, a publisher, distributor, or other agency responsible for the file is required.

While not formally required, additional information is recommended for a minimally effective header. For example, it is recommended that the person or corporate entity responsible for the creation of the encoding should be specified using respStmt within the titleStmt element. It is also recommended that information about the source, or sources, of the encoding be included. Each source element should contain at the least a loosely structured bibliographic citation that identifies the source used to construct the MEI file.

Furthermore, If the electronic transcription is a member of a series of publications, the series title and publisher should be included using the seriesStmt element. It is also common for cataloging records to include genre and/or form information, here represented by the MEI classification element.

We now present the same example header, expanded to include additionally recommended information, adequate for most bibliographic purposes, in particular to allow for the creation of an AACR2-conformant bibliographic record.

Mapping elements from the MEI metadata header to another descriptive system may help a repository harvest selected data from the MEI file to build a basic catalog record. For this purpose, the following attribute is provided on most elements occurring within meiHead:

The encoding system to which fields are mapped must be specified in analog. When possible, subfields as well as fields should be specified, e.g., subfields within MARC fields.

The term corpus may refer to any collection of musical data, although it is often reserved for collections which have been organized or collected with a particular end in view, generally to illustrate a particular characteristic of, or to demonstrate the variety found in, a group of related texts. The principal distinguishing characteristic of a corpus is that its components have been selected or structured according to some conscious set of design criteria.

In MEI, a corpus is regarded as a composite text because, although each discrete document in a corpus clearly has a claim to be considered as a text in its own right, it is also regarded as a subdivision of some larger object, if only for convenience of analysis. In corpora, the component samples are clearly distinct texts, but the systematic collection, standardized preparation, and common markup of the corpus often make it useful to treat the entire corpus as a unit, too. Corpora share a number of characteristics with other types of composite texts, including anthologies and collections. Most notably, different components of composite texts may exhibit different structural properties, thus potentially requiring elements from different MEI modules.

Aside from these high-level structural differences, and possibly differences of scale, the encoding of language corpora and the encoding of individual texts present identical sets of problems. Therefore, any of the encoding techniques and elements presented in other chapters of these Guidelines may therefore prove relevant to some aspect of corpus encoding and may be used in corpora.

Arguably, the most important element of the CMN module is the measure element. It is used as a structural unit inside section elements and acts as a container for ‘events’ from the model.eventLike class, such as notes, chords and rests as well as ‘control events’ from the model.controlEventLike class, such as slurs and indications of dynamics.

The following example demonstrates the use of the measure element:

A measure slices the flow of a score or part into chunks that normally comply with a duration determined by the meter defined within a preceding scoreDef or staffDef element. Each staff in the source material is represented by a staff element. As the order of the staff elements in the file does not have to reflect their order in the original document, to eliminate confusion they should always refer to a staffDef element, using either an n or def attribute. Whereas the def attribute uses the xs:anyURI datatype, the n value refers to the closest preceding staffDef or layerDef with the same value in its n attribute.

Each staff may hold a number of layer elements to reflect multiple ‘voices’. Just as with staff, the order of the layer elements in the file does not have to reflect their original order in the document, so they also possess n and def attributes for association with the appropriate layer definition.

Later in the file:

When encoding a score in CMN, MEI relies on the following elements from the module:

A scoreDef element is used to specify the common parameters of a score, e.g., key and meter. The most important attributes for this purpose are:

The following example describes a score in common time with 3 flats:

For encoding more complex time signatures, simple mathematical symbols such as asterisks and plus signs are allowed in meter.count.

Non-standard key signatures have to be encoded with a keySig element.

Other attributes allow the description of default page and system margins and fonts for text and music:

There are other attributes that allow the specification of many further details of a score. These are available from the element definitions accessible at scoreDef, staffDef, staffGrp and layerDef.

When content is provided for scoreDef, it must contain a staffGrp element. This element is used to gather individual staves and other staff groups. This is useful for collecting instrumental or vocal groups in a large score, such as woodwinds, brasses, etc., and for assigning a shared label to the group, using the label and labelAbbr subelements. The staffGrp element is also used for the two staves of a grand staff. The bar.thru attribute on staffGrp allows one to specify whether bar lines are drawn across the space between staves of that group or only on the staves themselves.

A staffDef element is used to describe an individual staff of a score or performer part. It bears most of the attributes described above. The label and labelAbbr subelements may be used for providing staff labels for the first and subsequent systems.

Every staffDef must have an n attribute with an integer as its value. The first occurrence of a staffDef with a given number must also indicate the number of staff lines via the lines attribute.

The order of staffDef elements within scoreDef follows the order of staves in the source document or planned rendering. The individual staff elements within a measure refer to these staffDef declarations using their own n attribute values. Therefore, the encoding order of staves within a measure does not have to mimic the order of the staffDef elements with scoreDef.

In addition to the parameters inherited from scoreDef, the following attributes are important for staffDef elements:

A staff with a tenor clef is encoded as in the following example:

In the case of transposing instruments, the key-related attributes described above may be used to override the written key expressed in the scoreDef element. As a basic principle, MEI always captures written pitches, so the trans.diat and trans.semi attributes may be used to indicate the number of diatonic steps and semitones to calculate sounded pitch from written pitch. The piccolo and E♭ clarinet staves in the example below utilize these attributes:

There are a number of additional elements that can be used as children of staffDef in order to describe additional features of the staff, such as the color of a clef or a key signature added in a different hand. These elements include:

With the exception of label, these elements may also occur within the flow of musical events captured in a layer, since they are members of model.eventLike. In the layer context they function as milestones and affect all following content assigned to the layer (even in subsequent measures) until their information is again overridden either by the same element bearing different information or a staffDef or scoreDef. In this context, it is also possible to combine them with the elements described in chapters and of these Guidelines.

Such flexibility as this may require close inspection of an encoding to retrieve the correct definitions for a given staff. As a general rule, the closest preceding and most specific element provides this information: For example, a keySig in the preceding measure is more relevant than a staffDef at the beginning of the section, which is more relevant than a scoreDef at the beginning of the score. However, a section-specific scoreDef that provides only information about the meter does not override the more specific information about key signature gathered from a staffDef for a transposing instrument.

Every staffDef may contain a number of layerDef elements, which may be used to establish default values for the distinct layers sharing one staff. MEI does not use the term ‘voice’ to describe these ‘musical threads’ because that term implies continuity across measure boundaries. Given the sometimes arbitrary relationships between these threads from measure to measure as well as across staves, MEI uses the more neutral term ‘layer’.

Usually clef, key, and meterSig apply to a whole staff.

In some rare cases one can find different meters in different layers, as seen in Maurice Ravel’s Oiseaux tristes.

In these cases it is necessary to encode each meterSig for the staff as child of the corresponding layerDef:

Sometimes it is necessary to re-define the parameters of a score or a staff. For example, a score may change keys, the number of staves, or use different layout settings. Likewise, a staff may change its clef, change the number of layers, or become invisible. To accommodate these changes, staffDef is allowed to occur in the following locations:

In addition, scoreDef is allowed to occur:

It is also possible to include scoreDef and staffDef in staves and layers when the MEI All schema is in use; however, this practice is not recommended for the CMN repertoire.

The following example shows how to change the key and meter signatures within a score. The keysig.cancelaccid attribute may be used to control the position of the cancellation accidentals of the key signature change, while the keysig.visible can be used to hide the key signature entirely.

MEI offers multiple ways of defining onsets and offsets of timed musical events such as notes and slurs. The most common and most musician-friendly approach to this is through the use of a combination of the attributes tstamp and dur, which are made available by the attribute classes att.timestamp.log (inherited by att.controlEvent) and att.timestamp2.log, both from the shared module.

The timestamp (tstamp) of a musical event is calculated in relation to the meter of the current measure and resembles the so-called ‘beat’ position. In a common time measure with four quarter notes, the timestamp of each quarter equals its beat position in the measure: The first quarter has a timestamp of 1, the second has a timestamp of 2, and so on. MEI defines the value of tstamp as a real number; the second eighth note position in a measure would thus be represented by the value of "1.5". The range of possible values is defined as starting with zero and ending with the number of metrical units in a measure (the ‘numerator’ in a time signature) + 1. This allows the capture of all graphical positions starting from the left bar line ('0') and ending with the right bar line of the measure ('5', in the case of 4/4 time).

For expressing durations, MEI offers the dur attribute. This attribute is described in section .

For ‘spanning’ elements like slurs, which are members of the model.controlEventLike class, it is often more intuitive to record two timestamps – one for the onset of the event and one for its termination. Because the termination of the event may be in a succeeding measure, the second timestamp (tstamp2) has a slightly different datatype than the one marking the initiation of the event. Its datatype is constrained to values following the formula "xm + y", where x is the number of full measures that this particular feature lasts (or the number of bar lines crossed) and y is the timestamp in the target measure where the feature ends. The timestamp is expressed using the same logic as described above. For example, a value of "0m+3" in 4/4 time indicates that the element bearing this attribute, a slur for example, ends on beat 3 of the same measure where it started. A value of "1m+1.5" would indicate an end on the second eighth note of the following measure. In 6/8 time, the value "2m+3" means that the feature ends two measures later on the third eighth note.

A very common feature of music from the CMN repertoire is the beaming of eighth or shorter notes. MEI provides two elements for the explicit encoding of features joined by beams.

Use of the beam element is straightforward. The beamed notes, rests, or chords are simply enclosed by the beam element:

Whereas in music notation every note value shorter than an eighth adds another beam (sometimes referred to as ‘secondary beams’), in MEI only one beam element is used, no matter the durations of the contained notes. The visual rendition of a set of beamed notes is presumed to be handled by rendering processes.

From the 19th century onwards, it became quite common to break secondary beams to increase readability of longer beamed passages. The optional breaksec attribute on notes and chords under the beam may be used to encode the breaking of secondary beams after the note or chord bearing the attribute. The value of breaksec indicates the number of continuous beams. For example:

In the music of the second half of the 20th century, it is quite common to indicate acceleration or deceleration using converging (feathered) beams as in the image below:

The encoding of such a beam is accomplished using the form attribute of the beam, which allows the following values:

The duration of notes, rests, or chords under a beam which carries the form attribute with a value of ‘acc’, ‘rit’, or ‘mixed’ must be treated specially. The first and last contained elements must specify a duration which matches the number of beams displayed at the point of these events. In the case of a ‘mixed’ beam, each event at the point of change in the number of secondary beams must carry a dur attribute. Beams like this may be encoded thusly:

Beams that connect events on different staves may be encoded in two different ways. First, a single-layer approach may be taken that treats the events lying under the beam as logically belonging to the same layer as the initial event but visually ‘displaced’ to an adjacent staff. In the example above from Moritz Moszkowski’s 12 Pianoforte Studies for the left hand, Op. 92, MoszWV 117 this method makes even from a semantic perspective perfect sense. It can be achieved with an additional staff attribute value that contradicts the ‘normal’ staff placement indicated by the n attribute of their ancestor staff.

In other contexts however, a staff-by-staff methodology may be employed in which the notes are encoded according to the staff on which they appear. This encoding style requires that each beam element account for the total time encompassed by the beam; that is, each beam must use one or more space elements to account for the time occupied by notes on the opposing staff. For example, the time used by the first two notes of the beam must be represented on staff number 1 and the time taken by the last two notes of the beam must be filled on staff number 2.

Downstream processing needs are the determining factor in the choice between the two alternative encoding methods.

Due to the potential problem of overlapping hierarchies, the beam element only allows the encoding of beams that do not cross bar lines. When beams cross bar lines, the use of the beamSpan element is required. Unlike beam, the beamSpan element does not contain the beamed notes as its children. Instead, it references the xml:id values of all affected notes in its plist attribute and denotes the initial and terminal notes of the beam using startid and endid attributes. This configuration allows beams to cross measure boundaries. The following example from Erwin Schulhoff’s Violin Sonata demonstrates a typical example of such hierarchy-crossing beams:

In addition to the explicit encoding of beams accommodated by the beam and beamSpan elements and the beam attribute, MEI allows for specification of default beaming behavior using the following attributes on scoreDef, staffDef, and layerDef:

The beam.group attribute can be used to set a default beaming pattern to be used when no beaming is indicated at the layer level. It must contain a comma-separated list of time values that add up to a measure in the current meter, e.g., 4,4,4,4 in 4/4 time indicates that each quarter note worth of shorter notes should be beamed together. Parentheses can be used to indicate sub-groupings of secondary beams. For example, (4.,4.,4.) in 9/8 meter indicates one primary beam per measure with secondary beams broken at each dotted quarter duration, while (4,4),(4,4) in 4/4 will result in a measure of 16th notes being rendered with a primary beam covering all the notes and secondary beams for each group of four 16th notes.

The beam.group attribute is available on scoreDef, staffDef, and layerDef elements, making it possible to set different beaming patterns for each of these. Also, the beaming pattern can be changed anywhere score parameters may be changed, for example, at the start of sections. This beaming "directive" can be overridden by using beam, beamSpan, or beam attributes as described above. If none of these beaming specifications is used, then no beaming is implied. Default beaming can be explicitly ‘turned off’ by setting beam.group to an empty string.

One of the most specific features of CMN is the use of ‘curved lines’ which connect notes. These lines are used to indicate various musical features, depending on their context.

A tie is a curved line connecting two notes of the same pitch. The purpose of a tie is to join the durations of both notes, so that the first note sounds for the combined duration. In other words, there is only one onset for both notes.

In MEI, ties can be encoded in different ways, depending on the level of detail that the encoder wants to preserve. The simplest solution is to use the tie attribute found on note and chord.

This attribute allows three values:

The scope of the tie attribute is the musical layer; that is, a tie started in one layer may only be ended by a subsequent musical event with a tie attribute with an m or t value in the same layer. The tie-terminating event may lie in the following measure.

When tie is used on chords, it functions as a shorthand indication for multiple tie markings; that is, a separate tie is drawn for every pitch in the chord that remains unchanged in the succeeding chord.

This is equivalent to the following, more verbose version:

A slur is a curved line that connects a group of notes of different pitch. It normally indicates that an instrument-specific performance technique should be applied to the affected notes. For example, in notation for winds, the notes should be played in one breath, while a single bow is indicated for string instruments.

In MEI, slurs may be encoded in a similar way to ties: note and chord bear a slur attribute that allows the commencement or ending of a slur at this element. The allowed values, however, are slightly different: The i, m or t are followed by a single digit in the range 1 to 6, as in the following example:

The reason for this difference is that slurs, unlike ties, may overlap, so that a second slur may start while the first slur is still ongoing. The digit indicates the level of nesting of slurs on the note; ‘1’ indicates no nesting, while ‘2’ indicates the existence of 2 slurs in which this note participates, and so on. In the example below, the second and third quarter notes lie under 2 slurs. The second note is covered by the slur that begins on the preceding note and by the one that it starts. The third note is affected by the slur that begins on note one and by the one that starts on note two.

To support analytical operations, slur may take on more than one value. For example, the example above may be more explicitly encoded as:

In this encoding, the notes in the beamed group are marked as participating in two slurs – one connecting just the beamed notes and one connecting the first and last notes of the layer. In ‘nested’ slurs like this, the function of the slurs is usually different. Here, the slur connecting the 8th notes indicates legato performance, while the longer slur functions as a phrase mark.

While ties are not normally allowed to cross layers or staves, slurs may. The following example demonstrates how cross-staff slurs may be encoded using the slur attribute:

Slurs and ties that cross system or page breaks are often split into two separate symbols for rendering. One slur or tie ends at the last bar line, another one starts at the beginning of the new system. MEI expects this to be the default rendering behavior, so that in situations like these, the regular tie or slur attributes are sufficient to describe both curved lines resulting from the split.

Sometimes, however, one of these two symbols is missing in the document, or the encoder wants to provide additional (often visual) information about the slur or tie. In these cases, using an attribute is not an adequate solution. Therefore, MEI offers dedicated tie and slur elements. A third element, phrase, is used to identify a unified melodic idea (in German: Phrasierungsbogen), whereas the slur element is used as a generic element for all curved lines (in German: Bogensetzung) except ties. All three elements have nearly identical models.

Another reason for using elements instead of attributes for ties, slurs, and phrase marks is that only elements may be combined with the functionality provided in chapters and of these Guidelines.

Although these elements are allowed within a layer to accommodate unmeasured notation, by convention in CMN they are normally placed inside measure, after the encoding of staves, alongside other so-called ‘control events’.

Obviously, to be complete the slur in the above example needs to be ‘attached’ to the notes somehow. The ‘vertical assignment’ can be indicated for the example above using the staff and layer attributes like so:

For the ‘horizontal assignment’, the encoder may choose between two different mechanisms. The first uses two timestamp attributes as described in section . The start and end points of the slur may be indicated thusly:

By using tstamp and tstamp2 attributes, the encoder denotes a rather loose connection – the slur (or tie) is attached to a certain position in the measure, not to a specific note or chord. If the encoder wants to specify a close connection to a particular event, the startid and endid attributes may be used instead. Here, the xml:ids of the first and last note of the slur are referenced. This mechanism also allows the crossing of layers and staves.

For human readability, it is recommended to encode slur, tie and phrase features in the measure where they begin; that is, in the measure that holds the element referenced by startid. On the other hand, for machine processability, it may be desirable to place slur, tie, and phrase elements in the measure where they end or even in the last measure regardless of their beginning and ending points in the music. This last option makes all references contained within these elements ‘back references’. Back references are necessary when using processing software that treats the encoded file as a stream; that is, programs that process the file without creating an in-memory representation of its contents.

When using the tie, slur or phrase elements, the curvature of the line may be described using the curvedir, bulge and bezier attributes. Whereas the first attribute allows only specification of the slur’s vertical placement, the others give increasingly more precise control of the curve.

If the encoder wishes to draw attention to the appearance of a slur or tie in a given source, the facs attribute may be used instead of (or in addition to) the curve description attributes to point to a graphic image or a zone within an image (see ).

Common Music Notation provides two different methodologies for expressing the volume of a note, phrase, section, etc. The first is a verbal instruction providing such information in human language, possibly in an abbreviated form. An example is the word piano, indicating a quiet volume, often abbreviated as p. In MEI, verbal instructions like this are encoded using the dynam element from the Shared module (see chapter ):

By convention, dynam elements, like slur and other elements belonging to the model.controlEventLike class, are encoded at the end of the measure to which they belong. This requires dynam to be assigned to a certain staff using the staff attribute, whose value refers to the target element’s n attribute. In the absence of other information, all layers within the staff are assumed to have the same dynamic marking.

However, when the layers of a staff have different dynamic indications, the layer attribute may be used to associate a dynamic marking with a particular layer:

A suitable MIDI value may be assigned to a dynamic marking using the val attribute:

The location of a dynamic marking in relation to a staff may be specified using the place attribute, which may be given as above, within, or below the staff:

Dynamics must also be associated with a particular time point in a measure, using the tstamp, or with a particular event, using the startid attribute. Linking a control event with measures and events is discussed in section :

Dynamics which do not have an explicit endpoint are often referred to as ‘instantaneous’. On the other hand, some dynamic directions indicate a continuous change that must have a defined end point. It is possible to specify the logical scope of continuous dynamic marks using the attributes tstamp2, dur, dur.ges, or endid. Additionally a corresponding ending value for MIDI output may be given in the val2 attribute.

To capture the fact that the crescendo in the example above continue until the first beat of the next measure, they may be marked:

Any combination of tstamp, startid, tstamp2, and endid attributes may be used to define the scope of a dynamic, although the tstamp and tstamp2 or the startid and endid combinations are the most logical combinations. For example, the following alternatives are all possibilities for encoding up a crescendo. The choice of attributes is often task or processor dependent.

All musical elements affected by the dynam may be explicitly specified using the plist attribute, which contains xml:id attribute value references:

It is recommended that the list of references in plist include all participants in the dynamic marking, including the first and last notes as in the preceding example, even though they are duplicated by startid and endid attributes.

In addition to verbal instructions, Common Music Notation uses graphical symbols to indicate ‘continuous’ dynamics. These crescendo and decrescendo (or diminuendo) symbols are encoded in MEI using the hairpin element. It also is a member of the model.controlEventLike class, which means it too is used just before the close of a measure element, following the encoding of all staves. The required attribute form specifies the direction of the symbol by taking one of two possible values: cres (growing louder) or dim (getting softer).

Marking the logical extent of hairpins is possible using the same attributes as for dynam.

The following example from Béla Bartók’s Mikrokosmos, Sz.107 shows a diminuendo between two staves that begins on the first beat (in the current measure) and ends on the first one in the penultimate measure. The duration is highlighted with a dashed line, which can be indicated with the extender attribute.

Tuplets indicate a localized change of meter; that is, a given duration in the regular meter is divided between a group of notes with irregular (according to the current meter) rhythmic values. The most common tuplet is a so-called ‘triplet’, in which three notes take the time normally occupied by two.

The relation of the tuplet to the underlying meter is specified using the num and numbase attributes, where num specifies the number of replacing notes and numbase specifies the number of notes of the same duration to be replaced. For example, when three eighth notes replace one quarter note in common time, num takes a value of "3", whereas numbase reads "2", because a quarter note in common time is normally divided into two eighths. When three quarters replace two in the same meter, numbase also reads "2". The combination of these attributes may be read as "3 in the time of 2" in either case.

The duration of the entire tuplet may be encoded using the usual ‘power of 2’ values, e.g., 1, 2, 4, etc., in the dur attribute if necessary.

Tuplets are often highlighted using brackets above or below the affected notes. The presence and position of these brackets can be encoded using the bracket.place (above / below) and bracket.visible (true / false) attributes.

Usually, however, tuplets are rendered with a bracket (bracket.visible="true") and a single number (num.format="count" and num.visible="true"), as seen in the example above. However, the number-to-numbase ratio may be provided in addition to, or in some cases as a replacement for, the bracket. The num.format attribute indicates whether a plain number (the value of num) or a ratio (comprised of num and numbase, e.g., "3:2") should be displayed and num.visible indicates the general presence of such a number.

Further visual control comes with the num.place and bracket.place attributes, that allow specific placement of the number and the bracket above or below the staff.

In addition to note elements, tuplet may contain other elements, such as rest or space, to match the content of a source document or an intended rendering. In particular, the beam element is allowed so that custom beaming may be indicated, e.g., a septuplet may be divided into a group of three plus a group of four notes.

The tuplet element may also be used for repetition of the same pitch; that is, a single note or chord may be the only content of the tuplet. In some cases, optical music recognition software may treat these instances as bowed tremolandi due to the knowledge of the complete semantics of the notation at the time of recognition. However, marking these as tuplets is the recommended practice.

In some situations, a tuplet is made up of events in different measures. As this raises the issue of non-concurrent hierarchies, it is not possible to encode such situations with the tuplet element described above. Therefore, MEI offers the tupletSpan element, which is member of the model.controlEventLike class. It is nested inside of measure, following all the measure’s staff children. It uses the same attributes as tuplet to describe tuplets, but instead of nesting all affected notes inside itself, it references the xml:id values of all affected notes in its plist attribute and the initial and terminal notes of the tuplet using startid and endid attributes. This configuration allows tuplets to cross beams or measure boundaries. The following example demonstrates a typical example of such hierarchy-crossing tuplets:

This section introduces elements and attributes which may hold CMN-specific performance instructions. The functionality described herein is related to the artic attribute and artic element introduced in . The following elements are relevant in this context:

CMN contains a number of symbols which are closely related to a specific instrument. MEI offers elements for three of these symbols, namely breath marks, harp pedal diagrams, and piano pedals.

The term ossia, Italian for "or", denotes an alternative for a certain passage which is provided by the composer without any preference of one alternative over another. An ossia often provides a simpler (easier to perform) version of the original content. Another frequent use case for ossia is the provision of indications about performance practice, such as an alternative version with ornamentation written out in full. In all cases, it is up to the performer to choose between the alternatives.

Most often an ossia is rendered above the main staff on a reduced-size staff. Sometimes, however, the alternate material occurs on the same staff as the primary text, but in a separate layer. In this case, the alternative material is usually rendered in small-sized notation on the normal-sized staff. For both situations, MEI offers the ossia element, which may be nested either inside measure to reflect an ossia on a separate staff, or inside staff to reflect an inline ossia in a separate layer. The following example demonstrates an ossia on a separate staff:

The example above demonstrates that only one of the two staff elements within ossia has an n attribute. This mechanism allows one to distinguish between the "regular" and the "alternative" content: The one bearing the n attribute goes in line with the preceding measure’s staff, the other one is printed in reduced size above. In this case, the vertical order of staves follows document order: The top-most staff is encoded as the first child, the lowest comes last. In combination with the presence of the n attribute, this allows the capture of multiple simultaneous ossia staves.

All staves within ossia, even the alternative ones without a direct reference, obey the definitions of the associated staffDef, which can be derived from the value of the n attribute. Alternatively, a separate staffDef may be given at the beginning of the contained layer element(s).

In case of an inline ossia, the whole setup of elements moves down one step in the hierarchy, as seen in the following example:

Cue notes are smaller notes that usually occur in an orchestral or vocal part and are not to be played or sung by the corresponding musician, but by other instruments or singers. Cue notes are used for orientation, i.e., to follow the music during longer pauses and to find the correct re-entry point more easily. In MEI the cue attribute is available to indicate such notes.

Most often cue notes occur in a group rather than one by one. This is because usually a whole layer of another part is inserted as a cue. Therefore, a complete layer can also be marked as cue.

If the voice from which the cue notes originate is also encoded, they should refer to their sounding counterpart with the corresp attribute.

Cue notes must not be confused with other small notes such as grace notes or fiorituras.

In CMN scores, there is often a large number of natural language instructions. Some of them concern the loudness and the speed of the performance, in which case MEI offers the elements dynam (described at ) and tempo. In other cases, however, they provide other instructions for the performer. Instead of providing separate elements for all possible types of such directions, MEI offers the generic dir element. Although this element is not CMN specific (it is defined in ), it is frequently used in this repertoire.

Repetition is a characteristic feature of music. Many musical forms rely on repetition (sometimes with modification) of distinct sections of the music. Repetition in this sense can be thought of as ‘structural’. At the same time, composers and engravers of music often use local symbols for repeating smaller portions of music instead of writing them in full more than once. In this case, the repetition is better defined as a species of abbreviation.

When encoding CMN, ornaments should be encoded within a measure, following the staff elements, and connected to events on the staff via attributes. The startid attribute is used to refer to the xml:id of the starting note. Additionally, if the ornament involves more than one events on the staff, the endid attribute can be used to anchor the ornament to a concluding event.

The following example demonstrates the encoding of a mordent over a middle C:

Alternatively, the relationship of an ornament to a note can be expressed in terms of beats with the attribute tstamp. If the ornament involves more than one event on the staff, the tstamp2 attribute can be used to indicate the ending time stamp, as is explained in section . These methods may also be utilized simultaneously.

The following example shows the use of tstamp for an ornament. Assuming that the following measure is in 2/2, the ornament (in this case, a mordent) is related to the note on the second beat.

The relationship between an ornament and the notes on staff must always be encoded. It is, in fact, a semantic error not to specify a starting event or time stamp for an ornament.

In their resolution, ornaments will involve auxiliary notes, which typically follow the key signature or the scale of the current key. When the ornament involves other chromatic auxiliaries, an accidental is expressed next to or above the ornament sign. The attributes accidlower and accidupper, available on all ornaments described in this chapter, can be used to record this accidental. The attribute values ‘upper’ and ‘lower’ indicate whether the accidental is associated with an upper or lower auxiliary note, not the position of the accidental sign.

A mordent is an ornament that involves an auxiliary note a step above or below the principal note. The presence of a mordent is encoded with the mordent element and its attributes:

It is recommended, but not required, to use the attribute form to encode the typology of mordents. Two common types are supported: those mordents that involve a note lower than the principal note, and those that involve a note higher than the principal note.

The attribute form accepts the following values:

The following example demonstrates the encoding of simple mordents:

Occasionally, mordents can be longer, employing five notes instead of three. The long attribute can be used to identify mordents of this type. The following example shows the encoding of a long mordent:

Trills are a type of ornament that consists of a rapid alternation of a note with one a semitone or tone above. A trill is encoded with the trill element and its attributes:

Trills in modern notation are usually expressed with the abbreviation "tr" above a note on the staff. Often the abbreviation is followed by a wavy line that indicates the length of the trill.

The following example demonstrates the encoding of simple trills:

It has been specified earlier that it is a semantic error not to encode a starting event or time stamp for an ornament. This starting point of a trill can be expressed with the startid attribute and/or with the tstamp attribute. Specifying the end point is not required, although the tstamp2 or endid attribute may be used to imply the use of a wavy line extender as shown in this example:

When giving an end point to trills, the extender attribute should also be added, to indicate the presence or absence of a line extender. Notice, that the note referenced in endid is not part of the trill itself, just like in glissandos.

Chromatic alterations of auxiliary notes are occasionally expressed on the staff using small notes enclosed in parentheses, as shown in the example below. However, the attribute accidupper is still to be used to encode the alteration. Display of the auxiliary note in this ‘cautionary’ manner is left to down-stream rendering processes.

Some trills may be introduced by a turn or followed by an inverted turn leading to the next note (see Le garzantine, Musica 2003, p. 911). In such cases, the trill is encoded as in previous examples and associated with the principal note. Starting or concluding turns are notated on the staff (in layer) as .

The following example, from a keyboard sonata by Joseph Haydn, shows a trill with concluding grace notes (called Nachschlag):

A turn is an ornament that typically consists of four notes: the upper neighbor of the principal note, the principal note, the lower neighbor, and the principal note again.

The presence of a turn is encoded with the turn element and its attributes:

It is recommended, but not required, to use the attribute form to encode the typology of the turn.

The attribute form accepts the following values:

The following example shows the encoding of a simple turn:

Turns can sometimes be performed after the principal note (usually on the second half of the beat, see Read 1979, p. 246) and leading to the following event. To indicate this, the turn symbol is typically written in between the principal note and the next. These kind of turns are encoded with the attribute delayed.

The following example from Beethoven’s piano sonata no. 1 in F minor, op. 2, no. 1, mvmt. 2 demonstrates the encoding of turns with the delayed attribute. Note that the tstamp attribute indicates the actual starting point in time, while startid points to the principal note.

CMN ornaments that are not mordents, trills, or turns can be encoded with a generic ornam.

This element allows the encoder to represent ornaments as textual strings (e.g., with a Unicode symbol) or with a user defined symbol. Chromatic auxiliaries can be represented with accidlower and accidupper. The ornam element can also be a control element. That is, it can be linked via its 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.

For example, Johann Sebastian Bach used non-standard ornaments in the Klavierbüchlein für Wilhelm Friedemann Bach:

The ornament for (5) doppelt-cadence could be encoded in the following way, by adopting the Unicode code-points defined by the SMuFL standard:

A resolution, or expansion of the ornament can be provided as discussed in below.

Particularly in baroque keyboard music, but also in the early classical period, various combinations of ornaments can be found. Despite being written vertically above the same note, they are to be performed in sequence.

The following example from Carl Philipp Emanuel Bach’s song Dorinde Wq 199/7 shows a turn followed by a inverted mordent:

When encoding the example above, both ornaments will be positioned above the same note. The encoded order of the elements, moreover, may correspond to the performed sequence, which in this example is top to bottom: first the turn, then the mordent. As every renderer deals differently with such combined ornaments it is best practice to encode the performed sequence additionally with next and prev attributes. The visual order can be specified globally with aboveorder in the preceding scoreDef.

In ternary mensurations, the ambiguity between the note shape and its actual duration requires specific attention. The rules of mensural notation can require the alteration or the imperfection of a note; that is, an increase or reduction in its performed duration. In these cases, if the encoding is intended to be used for more than just graphically representing the notation, encoding only the note shape by means of the dur attribute alone is insufficient. In that case, in addition to encoding the duration sign in the dur attribute, it is recommended to encode its performed duration in the dur.quality attribute. The dur.quality attribute specifies the length of a note according to the contextual rules of mensural notation. Its values, listed below, are adopted from the original Latin terms:

The last three values are to be used exclusively in Ars antiqua mensural notation, where maior and minor refer to types of semibreves, and duplex refers to a type of longa. Examples of each of these six values are presented below. In these examples, the ‘voice’ staff renders the notes in the code snippet, and the ‘reference’ staff, together with the dotted bar lines, are shown to help to visualize the relative values of the notes in the ‘voice’ staff.

The following example illustrates an alteration (the second brevis) in modus minor perfectus. Notice that the second brevis has doubled its regular value, it has been altered, unlike the first one.

It is possible to omit the dur.quality attribute in a note when the performed duration of the note is the default value provided by the mensuration. In this case, the longas are perfect, just as the mensuration (perfect modus minor) indicates. Therefore, the dur.quality attribute can be omitted for the two longas.

The following example illustrates an imperfection (the two longae) in modus minor perfectus with the same longa-brevis-brevis-longa sequence but with an additional dot of division between the two breves (see for more details). Notice that here the longae have been imperfected, unlike the previous example in which they kept the perfect value indicated by the mensuration.

The following example in modus minor imperfectus illustrates the use of a dot of augmentation following the longa (see for more details). Notice that the longa, which is supposed to be imperfect according to the mensuration, has a perfect value due to the augmentation dot.

Finally, the following example illustrates the dur.quality values related to the Ars antiqua style, for perfect modus, with the breve equivalents notated in the lower staff for reference (as in the previous examples).

Note: In Ars Antiqua, only the longa could be "perfecta" / "imperfecta" and the brevis could have a regular value ("recta") or be "altera". In the Ars nova, principles of imperfection and alteration were extended into the other note levels (brevis-semibrevis and semibrevis-minima). This means that the breves in Ars antiqua do not have a "perfecta" / "imperfecta" quality, and this is why there is no dur.quality attribute for the breves in the previous example. However, the brevis can have a ternary division (indicated by tempus="3"), being divided either into three (equal) minor semibreves or into a minor-maior pair of semibreves. The encoding also allows for the possibility of encoding a binary division of the breve in Ars antiqua notations: the indication tempus="2" indicates the breve is divided into two equal semibreves. This is why in this example with tempus="3", the semibreves do have a dur.quality attribute (with values minor or maior).

An alternative encoding---removing the dur.quality attributes for notes which lengths are not modified from their default values (i.e., the perfect long and the minor semibreves)---would be:

The conjunct use of the dur and dur.quality attributes is generally enough to encode the duration of a note—and, as indicated before, one could even remove dur.quality when its value is in agreement with the mensuration. However, there are cases (e.g., partial imperfection) where the values of dur.quality are not enough to provide the note’s duration.

In opposition to regular imperfection, which is caused by a note of the next smaller degree (e.g., a perfect brevis imperfected by a following/preceding semibrevis), partial imperfection is caused by a note of two or even three orders apart. As an example, consider an imperfect longa made up of two perfect breves. This longa can be ‘partially imperfected’ by a following/preceding semibrevis. This semibrevis causes part of the longa—one of its perfect breves—to be imperfected, taking away one-third of one of its two halves. In this case, the longa’s value changes from 6 semibreves (two perfect breves) into 5 semibreves. Partial imperfection is not supported by the dur.quality attribute—because there can be many cases of partial imperfection, as will be seen in the following examples. To encode a partial imperfection, the num and numbase pair of attributes are used instead. Given the change in the longa’s value from 6 semibreves to 5 semibreves, the corresponding attributes to encode this particular case of partial imperfection would be num="6" and numbase="5" as shown below in the code snippet and its rendering.

Partial imperfection can also happen from both sides of a note at once, as shown below:

An example of partial imperfection caused by a note three orders apart is given next. Here the longa is partially imperfected by a minima (instead of by a semibrevis).

In the next example, the longa is also imperfected by a minima. However, the num and numbase ratio is different from the example above because the default value of the longa here (18 minimas) is different from that of the previous example (12 minimas).

The following example illustrates a change in mensuration. In this case, the element mensur is used within the layer element, preceding the stream of notes affected by the new mensuration defined by it.

Sesquialtera is frequently used to change the mensuration. The effect of the sesquialtera on the mensuration can be encoded by using the tempus and prolatio attributes of mensur (for example, when changing the tempus to perfect, the effect can be encoded in tempus="3"). The actual sesquialtera can be encoded using num="3", numbase="2", and level to define the note level the sesquialtera is applied to (e.g., level="semibrevis").

It is common in Ars antiqua and some Ars nova pieces to have no mensuration signs. In this case, the mensuration—the division levels corresponding to modus maior, modus minor, tempus, and prolatio—is given by the context. The next example shows the incipit of a four-voice piece, Josquin’s Tu solus qui facis mirabilia, where only two of the voices (Cantus and Tenor) have a mensuration sign. The other two (Altus and Bassus) have no mensuration signs, and the mensura is given by the context. Therefore, while only the Cantus and the Tenor have attributes for encoding the mensuration sign (in this case, mensur.sign and mensur.slash), all four voices include attributes to encode the mensura (tempus and prolatio).

The division of the breve in Italian trecento notation can be encoded using the divisio attribute, which provides the values: ternaria, quaternaria, senariaimperf, senariaperf, octonaria, novenaria, duodenaria. The divisio attribute would usually replace the use of the tempus and prolatio set of attributes.

The signs for the Italian divisiones can be encoded in the sign or mensur.sign attribute (to be used with mensur or staffDef respectively), with the values: t for ternaria, q for quaternaria, si and i for senaria imperfecta, sp and p for senaria perfecta, oc for octonaria, n for novenaria, and d for duodenaria. And the additional values for senaria gallica, sg and g, and senaria ytalica, sy and y.

The notationtype attribute, part of the MEI module, can be used within the staffDef element to specify which dialect of mensural notation is in use.

At the moment, three values are in use for mensural notation:

The values of the notationtype attribute can indicate notation types other than mensural, such as common (Western) music notation, neume notation, and tablature.

The attribute notationsubtype can be used, together with the notationtype attribute, to provide more specificity regarding the type of notation encoded. This attribute can be used, for example, to specify if a piece in black mensural notation (notationtype="mensural.black") is written in Ars antiqua or Ars nova style. Currently, the values allowed in the notationsubtype attribute consist of any sequence of characters provided by the user.

Important: An element with a notationsubtype attribute must have a notationtype attribute.

The characteristics of a note’s stem can be encoded within the note element, using the attributes:

[include example (image and code) of a note with one stem that includes many of these attributes]

Sometimes notes have two stems. In this case, the stem element can be used as a child of note to define the individual characteristics of each stem with the following attributes:

[include example (image and code) of a note with two stems]

Plicas can be encoded using the plica element as a child of note. The direction of the plica, as well as its length, can be encoded using the following visual-domain attributes:

Dots of division and augmentation can be encoded by using the dot element (provided by the MEI.shared module). This element is meant to be used as a child of layer following the note or rest after which it appears in the original source.

Dots in mensural notation are not encoded as children of notes or rests, but rather as a sibling of these. They are also not encoded as attributes (the use of the dot attribute in a note or rest element is only acceptable in Common Music Notation, not mensural).

To indicate the nature of the dot (as a dot of division or augmentation), the dot element has an attribute form, which can take on the following values:

The actual effect of these dots (augmenting a note and making it perfect, or dividing a sequence of notes in different groupings by imperfecting some notes or altering others) is encoded with the dur.quality attribute of the correspoding note elements. Examples of the use of dots of division and augmentation can be found in the section.

[explain that accidentals are usually encoded as independent elements and that accid.ges can be used within notes]

[explain where/how coloration can be encoded]

[explain that there is a custos element available]

The following four elements are the fundamental components of the Neumes Module:

Neume notation can be thought of as "neumed text". Therefore, the syllable element provides high-level organization in this repertoire.

(syllable) – Individual lyric syllable.

Sign representing one or more musical pitches. As such, a neume consists of one or more nc element(s):

Sign representing a single pitched event, although the exact pitch may not be known. Examples of neume components are:

neume and nc are the most common elements used in the MEI Neumes module. In the following examples we can see how these elements are used to describe sung gestures of 1, 2, and 4 notes in square notation.

In addition to neume and nc the following elements are also frequently used in the MEI Neumes Module: custos, episema, hispanTick, liquescent, ncGrp, oriscus, quilisma, signifLet, strophicus. Note that nc, episema, hispanTick, and signifLet are neume elements. Instead oriscus, liquescent, quilisma, and strophicus are elements that must be part of a nc element. The custos is an element that is encoded inside the syl element. Furthermore, there are many other elements such as Editorial and Metadata elements that are not specific to Neumes and are not listed here.

custos: to indicate a symbol placed at the end of a line of music to indicate the first note of the next line. Sometimes called a "direct" (see MEI encoding of custos below).

mdiv: to indicate pause between neumes

episema: to indicate an episema (see MEI encoding of episema below).

hispanTick: to indicate Old Hispanic ticks (see MEI encoding of hispanTick below).

liquescent: to indicate a liquescent (see MEI encoding of liquescent neumes below).

ncGrp: to indicate multiple ncs.

oriscus: to indicate an oriscus.

quilisma: to indicate a quilisma (see MEI encoding of quilisma below).

signifLet: element indicates significative letter(s) attached to a neume or a nc (see MEI encoding of signifLet below).

strophicus: to indicate a strophicus

Nota bene: the following neume has a similar shape but the neumatic connection is not extended.

{true | false} if this nc is part of a ligature. See the encoding of the strophicus example, above.

Nota bene: in the last example we can read the exact pitch of the custos because the lozenged punctum (placed one step below the line) signals the lower note of the semitone E-F. This information, combined with the identification of the finalis of the piece, allows us to decipher the mode of this piece, that is the 4th.

Other articulation marks such as ictus, circulus, semicirculus, accentus, and other fonts in SMuFL can be encoded using: glyph.auth, glyph.name, glyph.num, and glyph.uri.

The following example illustrates the MEI encoding of the opening of Hildegarde’s “O Splendidissima Gemma” with the text “O splendidissima”. This example provides the basic MEI skeleton to have a valid MEI file and it may be used for reference for scholars willing to start encoding early music (and its text) in MEI. Information about the staff has been omitted for brevity, but it was originally encoded on a 5-line staff with two clefs, a “C” and a “F” on lines 5 and 3, respectively.

Samples of MEI of St Gall notation are taken from the winter volume of the so-called ”Hartker Antiphonary” CH-SGs Cod. Sang. 390.

Samples of MEI of Old Hispanic notation are taken from the ”León Antiphoner” E-L MS 8.

Samples of MEI of Aquitanian notation are taken from sources on the Portuguese Early Music Database.

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 ), 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:

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:

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.

This section introduces paratextual material, such as title pages, prefaces, indexes and other text that precedes or follows the actual score.

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 ):

Alternatively, paragraphs may be part of the document contents (and therefore encoded within music), either as 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:

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.

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:

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:

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:

Occasionally, lists have headers or titles, which can be encoded with head:

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.

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.

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:

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.

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:

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:

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.

Please consult and for more information about recording the names and dates frequently found in bibliographic citations.

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:

The relationships between event elements, such as note, chord, and rest, are the basic material of musical analysis; the attributes described below ensure a closed network of these relations and provide the opportunity to record data useful for common analytical tasks. In the context of a formal analysis, for instance, the attributes presented here can be useful in the capture information about the structure of a musical work.

MEI offers several attributes in the att.linking class for the description of basic relationships:

The att.alignment class also contains an attribute for describing temporal relationships:

These attributes accommodate the encoding of linkages between the element carrying the attribute and one or more other elements. All of them use URIs to establish the connection. While the examples below illustrate relationships between musical events, the use of the aforementioned attributes is not restricted to musical events. On the contrary, these attributes can be used to capture information about relations between any elements. Further information on this can be found in .

Using the attributes above makes it possible to create relationships between events, which are often widely-spaced in both encoded order and time. The attributes allow a large number of connections, enhancing the informational content, and therefore the potential usefulness, of the encoding.

The copyof attribute points to an element of which the current element is a copy. It can be used to repeat a note, for example, without encoding the whole note element again. The copy is a ‘deep’ one; that is, the copyof attribute copies all attributes and child elements which belong to the copied element, such as the dur and oct attributes of a copied note. The value of the copyof attribute must be a URI, which usually refers to an element in the current document. The following example demonstrates use of the copyof attribute:

In this example, the note in the second measure has exactly the same characteristics as the note in the first measure.

Using copyof is not limited to copying events. The copyof attribute can also be used to copy an entire measure or staff. When there are many repeated features, the use of the copyof greatly reduces encoding effort. The image and the following encoding of the beginning of Schubert’s Erlkönig illustrates the benefit of using the copyof attribute.

This example can be reduced further by using copyof inside the initial tuplet to represent the repeated chords:

While copyof signifies a duplicate copy of an element, the sameas indicates that the current element represents exactly the same entity as the one referenced in sameas. Use of sameas is used for describing the same entity from multiple perspectives, e.g., the same event in two layers.

While copyof and sameas have defined semantics, the corresp may be used to create user-defined relationships between elements. The example below demonstrates the encoding of a relationship between the third note and the fermata, even though the fermata is not placed directly above the note.

The corresp attribute only marks the correspondence between the current element and one or more other entities. To describe the nature of the correspondence, one must use annot.

The next and prev attributes point to elements which follow or precede the current element in some fashion other than that indicated by encoding order. The use of these attributes helps to avoid confusion in the sequence of events, for example, in voice leading across layers or staves, when the encoding reflects the physical arrangement of voices. In the second measure of the following example, the target of the next attribute occurs after the pointing element in time, but before it in encoding order:

This attribute may also be useful to clarify a sequence of entities which occurs across some form of interruption, in this case, notes before and after a system or page break where there is no custos or direct in the source:

A one-to-many relationship between the current element and the entities being referred to can be expressed by using a list of space-separated URIs in corresp.

The synch attribute points to an element that is synchronous with; that is, begins at the same moment in time, as the current element. It is useful when the encoding order differs from the order in which entities occur in time.

The when attribute may be used to indicate the point of occurrence of the feature bearing this attribute along a time line. Its value must be the ID of a when element. For more detailed information regarding the use of when, please see .

In addition to the common analytical attributes, the analysis module also offers other, more specific attributes on certain musical elements:

It is often helpful to record whether a given staff, layer, or measure obeys the meter established for it. The following attributes are provided for this purpose:

When used on staff or layer elements, the metcon attribute can be used to indicate if the duration of the contained events is equal to (c), less than (i), or greater than (o) that predicted by the time signature. When used on the measure element, metcon takes a boolean value, where true indicates conformance by all staff and layer descendants of the measure.

In the first example below, the layer, staff, and measure all match the prevailing meter. In the second example, however, the first layer does not comply with the meter, making the staff containing it and measure as a whole non-compliant. When there is a single layer or when all the layers on a staff agree with each other, metrical compliance can be indicated on the staff element. When, however, not all layers have the same value for metcon, then it is necessary to omit metcon at the staff level. The value of metcon on the measure level can usually be computed based on the values of its layer and staff sub-elements.

On the most basic level, chords in the musical text can be encoded using the chord element:

Additional information on the use of the chord element is available in and .

With only this kind of markup, harmonic information is implicit in the notes themselves. The elements and attributes of this module, however, provide for the encoding of explicit indications of harmony, such as chord symbols, tablature grids, figured bass signs, and the symbols of harmonic analysis like Roman numerals and their interpretation.

The following elements are defined in the critApp Module:

An app element always encapsulates the differences between varying sources. Therefore, it must contain at least two child elements. Possible child elements are lem and rdg, which use the same model, but have a different meaning: Whereas lem is used for prioritizing one alternative, a rdg has no such additional meaning and simply indicates a reading as found in one or more sources. Accordingly, lem is allowed only once in app, whereas rdg may appear as often as necessary.

The rdg (and lem) elements use the source attribute to point to one or more descriptions of the bibliographic sources containing the material they mark:

The seq attribute may be used on lem or rdg to record the sequence of a series of readings. In the following example, the material in source B is marked as sequential to (and perhaps derived from) the reading in source A:

If interested in modeling such dependencies between witnesses, using markup from is generally recommendable.

If a source has additional content that is not found in other sources, an empty rdg element may be used to indicate the lack of material in the other sources. In the following example, source 1 includes material that is not found in sources 2 and 3:

When working with a large number of sources, it might seem tedious to provide references for all sources. However, use of the rdg element without source is not recommended because such an encoding is not explicit and is therefore difficult to process.

The app element may be used to accommodate textual variation at nearly any point in a musical text. For example, it may be used to indicate minor differences such as stem directions:

or to indicate more significant differences, such as the insertion of extra measures:

However, the flexibility in the location of app places a burden on the encoder to ensure that the app, rdg, and lem elements are used correctly; that is, the content of every rdg and lem has to be a valid replacement for its parent app, even though this cannot be controlled effectively by the MEI schema.

In addition to its use for differentiation of the musical content of multiple sources, app may also be utilized to describe the layout of different scores, even when the musical content itself remains the same. An example of this is two sources that have the same content, but a different ordering of staves on which the content is written. By definition, the order of staves in MEI is described in and derived from the order of staffDef elements in scoreDef, not from the order of staff elements within a measure. The staff element in a measure points to its corresponding staffDef using the same value for n on both elements.

This rather loose mechanism makes it possible to point dynamically to the correct staff definition for a given source. The following example demonstrates how this can be accomplished for two sources, both presenting a two-staff score, but with differing staff order. No further app element is necessary within the measure to describe the alternative score order of the sources.

When unique values for n on layerDef and layer are provided, it is possible to reallocate layers in the same fashion as staves.

This mechanism may also be used to describe not only differing page orientations, formats and margins, but also clefs and keys.

The use of app in conjunction with staffDef illustrates the greater flexibility of connecting staff and staffDef by a shared n value. A technically more robust alternative to n would be to use the def attribute on staff, which points to the xml:id of a staffDef. However, this strong connection would be tied to one specific staffDef, and would not allow to pick one alternative out of an app.

In some situations, musical sources will agree at one level while differing at a lower level. For these cases, app elements may be nested to any level necessary. In the following example, there are three sources, two of which agree on the addition of a measure, but differ in the content of the added measure:

When nesting app elements, it is important that the value(s) in the child rdg element’s source attribute must be a strict subset of the ancestor rdg element’s source value.

MEI offers methods for marking abbreviations in prose, as in the following example:

or abbreviations in the music itself, as in the following example:

The generic type attribute may be used to classify the abbreviation according to a convenient typology. Sample values include:

This tag is the mirror image of the expan tag (not to be confused with the expansion element described in ). Both abbr and expan allow the encoder to transcribe an abbreviation and its expansion. In the case of abbr, the original is transcribed as the content of the element and the expansion as an attribute value, while expan reverses this. The choice between the two is up to the user. For example:

The abbr tag is not required; if appropriate, the encoder may transcribe abbreviations in the source text silently, without tagging them. If abbreviations are not transcribed directly but expanded silently, then the MEI header should indicate this is the case. The cert attribute signifies the degree of certainty ascribed to the expansion of the abbreviation. The expan attribute gives an expansion of the abbreviation. The resp attribute contains an ID reference to an element containing the name of the editor or transcriber responsible for supplying the expansion of the abbreviation.

When the content of the abbr or expan attributes requires additional markup, an attribute cannot be used. In this case, the abbreviated and expanded forms must be presented within elements. Furthermore, as alternatives to each other, the abbr and expan elements must be wrapped by the choice element, as described above. The previous example, where the 'o:' in 'pno:' is written as superscript, would be encoded as:

When the source material to be encoded is manifestly faulty, an encoder or transcriber may elect simply to correct it without comment, although for scholarly purposes it will often be more generally useful to record both the correction and the original state of the text. The elements described here enable all three approaches, and allows the last to be done in a way that makes it easy for software to present either the original or the correction.

The following examples show alternative treatment of the same material. The text to be encoded contains a chord (c4, e4, g4, a4), where c4, e4, and a4 are quarter notes, but g4 is incorrectly written as a half note.

An encoder may choose to silently correct the engraver’s error:

or the correction may be made explicit:

Alternatively, the encoder may simply record the typographic error without correcting it, either without comment or with a sic element to indicate the error is not a transcription error in the encoding:

If the encoder elects to record the original source text and provide a correction for the sake of transparency, both sic and corr may be used, wrapped in a choice element. The order of the sic and corr elements is not significant:

An indication of the person or agency responsible for the emendation can be provided as follows:

Here the resp attribute has been used to indicate responsibility for the correction. Its value (#editTrans.JK) is an example of the pointer values discussed in section . In this case, the resp attribute points to a name element within the metadata header, but any element might be indicated in this way, if the correction has been taken from some other source. The resp attribute is available for all elements which are members of the att.common class (through att.responsibility). The att.edit class makes available a cert attribute (through att.evidence), which may be used to indicate the degree of editorial confidence in a particular correction, as in the following example:

Where, as here, the correction takes the form of amending information present in the text being encoded, the encoder should use the corr element. Where the correction is present in the text being encoded, and consists of some combination of visible additions and deletions, the elements add and / or del should be used. For additional information on the use of add and del, see section . Where the correction takes the form of an addition of material not present in the original because of physical damage or illegibility, the supplied element may be used. Where the ‘correction’ is simply a matter of expanding abbreviated notation, the expan element may be used.

When the musical source makes extensive use of unusual symbol shapes or non-standard notation features, it may be desirable for a number of reasons to regularize it; that is, provide ‘standard’ or ‘regularized’ forms that are equivalent to the non-standard forms.

As with other such changes to the source text, the changes may be made silently (in which case the MEI header should still specify the types of silent changes made) or may be explicitly marked using the following elements:

Consider this traditional soprano clef appearing somewhere in the course of a musical piece:

An encoder may choose to preserve this original clef, but flag it as nonstandard from the perspective of current practice by using the orig element with no attributes specified, as follows:

Alternatively, the encoder may indicate that the clef has been modernized into a G-clef by using the reg element with no attributes specified, as follows:

As another alternative, the encoder may encode both the old and modernized shapes, so that applications may render both at the reader’s will:

As described above, the resp attribute may be used to specify the agent responsible for the regularization.

The following elements are used to indicate when single notational symbols have been omitted from, added to, or marked for deletion from, a musical text. Like the other editorial elements described in this chapter, they allow for a wide range of editorial practices:

Leaving aside temporary breaks, a compositional process is continuous: the composer’s writing operations have happened in a strict order, which could be specified if his working would have been filmed. However, this exact order is rarely ever recoverable from the surviving manuscripts, prints or other materials. Instead, relative statements can be made – the red pencil must have been written after the brown ink etc. Instead of a continuous movie, scholars are often only able to reconstruct a slide show, reflecting certain recoverable states of the composition. Very often, those states have a local range only – the order of two states on one page may be known, as is the order of two other states on a second page. This doesn't necessarily allow to identify the succession of all four states.

MEI utilizes the genDesc element to describe the recoverable genetic states of a work. It is nested inside music and may contain a number of genState elements.

A genetic description is used to bundle all known states of a work. The ordered attribute may be used to specify whether the order of child elements of the genDesc matches their temporal order, or if their temporal order is unknown. As genDesc may be self-nested, it is possible to specify the order of some states within a larger unordered set of genetic states, or to position a set of states with unknown temporal order in a larger ordered set.

In the above example, the temporal relation of states A, B and all of C is not known, but it is known that C1 precedes C2 and C3.

Even when the temporal order of a set of states is not fully recoverable, some arguments about relative chronology may be available. It is possible to encode these statements with the precision the editor feels comfortable with, utilizing the attributes next and prev (for immediate successors / predecessors), and precedes and follows (for relative successors / predecessors).

Genetic states can be further described by using any combination of the desc, date, and respStmt children of genState.

While the (relative) chronology of genetic states may be encoded using the genDesc element (see ), the textual operations they manifest in are encoded using the regular add, del, etc. elements are used (see ). However, for a genetic edition these elements are linked to their corresponding genState element using the state attribute.

In the example above, state X of the encoded work is established by the change from a C clef to a G clef. Other states preceding state X will read a C clef, while state X and succeeding states read a G clef. A genetic state of the work is constituted by performing all textual operations referencing that state, i.e., by carrying out all additions, deletions and restorations.

The instant attribute on del etc. allows to specify that corresponding modification has been carried out immediately after writing the original text, so that no separate genetic state has been established.

It is up to encoder to identify the appropriate level of granularity: In an ideal world, the writing or cancellation of a single note would constitute a new state. In practice, this level of detail isn't feasible, and the combination of multiple writing operations into larger logical operations seems inevitable. However, this may range from very large tasks (‘replacing the second movement of a symphony’) to very small ones (‘adding the slurs for the viola in measures 22 and 23’), depending on the intentions and scope of the encoding.

The arguments used to establish a chronological order of genetic states are sometimes found in external sources like letters, but very often they are to be found in the witnesses holding the musical text, even though they are typically not part of the text itself. Examples for such arguments are the writing medium, spacing, marginal notes, among others.

Some of these so-called ‘metatexts’ can be encoded using MEI, namely those that are written into the relevant sources. For this purpose, MEI offers the metaMark element, as known from the TEI.

A metaMark is provided as a ‘controlEvent’ (see ); as such, by convention, it should be encoded at the end of the measure where it first occurs. It is highly recommended to specify the function of the metaMark using its function attribute, which may take the following values:

Some metaMarks may have actual content, like marginal notes. This content may be transcribed inside the metaMark element. It also has a facs attribute to refer back to the corresponding sections of a facsimile.

It is important to keep in mind that metaMark elements do not encode the textual consequences they transport – this is an encoding of the sign, not of its meaning, which can be encoded in other elements like restore.

The above excerpt from a Beethoven manuscript holds a number of different metaMarks, some of which are encoded in the following examples:

The metaMark above captures the word ‘gut’ (good) Beethoven wrote below the red pencil, which indicates that the formerly deleted text of the two measures shown shall be kept.

This metaMark transcribes Beethoven’s marginal note explaining the same situation as above.

This third metaMark covers one of the letters Beethoven inserted to clarify the pitch of that given note.

In genetic editions, it may also be of interest to trace when pages are added and / or removed from manuscripts. The general information about pages can be encoded using the foliaDesc element, as described in . It is possible to wrap the elements used there, including patch and cutout with editorial markup like add and del. These elements can then be used to reference genState as described in .

This module makes available the following elements for encoding facsimiles:

These element are used to add a separate subtree to MEI, starting with the facsimile element inside music, as seen in the following example:

It is possible to have more than one facsimile element in this location. This is especially useful when multiple sources are encoded in the same file using the mechanisms described in chapter of these Guidelines. In this case, the decls (declarations) attribute of facsimile may be used to refer to a source defined in the document’s header, as seen in the following example:

When using the FRBR model (see ), it is equally possible to reference a manifestation element instead of source.

Within a facsimile element, each page of the source is represented by a surface element. Each surface may be assigned an identifying string utilizing the label attribute. In addition, it may encapsulate more detailed metadata about itself in a figDesc element. The coordinate space of the surface may be recorded in abstract terms in the ulx, uly, lrx, and lry attributes. For navigation purposes, surface has a startid attribute that accommodates pointing to the first object appearing on this particular writing surface.

Within surface elements, one may nest one or more graphic elements, each providing a reference to an image file that represents the writing surface. Multiple graphic elements are permitted in order to accommodate alternative versions (different resolutions or formats, for instance) of the surface image. In spite of changes in resolution or format, all images must contain the same content, i.e., the entire writing surface. A graphic may refer to a single page within a multi-page document, which is – at least for Adobe PDF documents – available through a #page=X suffix to the target attribute.

The preceding markup will provide the basis for most page-turning applications. Often, however, it is desirable to focus attention on particular areas of the graphical representation of the surface. The zone element fulfills this purpose:

The coordinates of each zone define a space relative to the coordinate space of its parent surface. Note that this is not necessarily the same coordinate space defined by the width and height attributes of the graphic that represents the surface. The zone coordinates in the preceding example do not represent regions within the graphic, but rather regions of the writing surface.

Because the coordinate space of a zone is defined relative to that of a surface, it is possible to provide multiple graphic elements and multiple zone elements within a single surface. In the following example, two different images representing the entire surface are provided alongside specification of two zones of interest within the surface:

A zone element may contain figDesc or graphic elements that provide detailed descriptive information about the zone and additional images, e.g., at a different/higher resolution, of the rectangle defined by the zone. The data objects contained within the zone may also be specified through the use of the data attribute, which contains ID references to one more elements in the content tree of the MEI file, such as a note, measure, etc.

Conversely, an element in the content may refer to the facsimile subtree using its facs attribute, which is made available by the att.facsimile attribute class. The last example could therefore be encoded with pointers in the other direction:

The pb element defined in the makes special use of the facs attribute, in that it does not point to a zone, but a surface element instead. A pb marks the beginning of a page, so it can be concluded that all elements in the content tree which are encoded between any two pb elements encode musical symbols written on the page (surface) referenced by the first of these two pb element’s facs attribute.

The encoding of facsimile elements is intended to support sequential display of page images. If an encoder wants to describe the physical setup of a source document, the foliaDesc element is more appropriate. The difference of both approaches, and how to combine them, is described in chapter .

The following elements are available to encode information about a recorded performance:

The performance element begins a subtree of the music element and appears alongside with, or instead of, body (described in ) and facsimile (described in ). A performance element represents one recorded performance event. As a performance may be recorded in multiple formats or by different personnel or using different equipment, the performance element may group one or more recordings of the event.

The decls attribute can be used to point to performance medium metadata for the performed work. See and for more details.

The recording element identifies a single recording event taking place within an absolute temporal space. The class att.mediaBounds contains attributes that can be used to define this space:

The avFile element identifies an external file associated with a recording act. In the simplest case, the recording element will contain one avFile element identifying a file that represents it. The target attribute contains the URI of the digital media file. Use of the mimetype attribute is recommended for the avFile element. Its value should be a valid MIME media type defined by the Internet Engineering Task Force in RFC 2046. It is also recommended that all avFile elements have a recording or clip parent which bears the begin, end, and betype attributes.

Sometimes, multiple digital files are created in order to provide greater flexibility in redistribution and playback capabilities. In this case, multiple avFile elements may occur, each with a different mimetype. Keep in mind, however, that each file still represents the complete temporal extent of the recording act in spite of the change of file format:

The clip element identifies a temporal segment of a recording act. In the following example, the clip begins two minutes into the timeframe of the recording and ends 20 seconds later:

Beyond these relatively simple uses, complex situations may occur that require equally complex markup. For example, a single performance may be represented by multiple digital media files. Because they have differing durations, the media files must be the result of separate recording acts, even if these recording acts took place at the same time:

A single performance may also be represented by multiple, sequential digital files, as when a complete work is recorded in several so-called ‘takes’. In this case, the files may be considered to be parts of a single recording act, the extent of which is the combined extent of the individual clips. For example, a series of clip elements may be used to identify each movement of a piece and give start and end times for the movements in relation to the overall temporal space of the complete work: