Contact: Basic MEI file organization
An MEI file, like many other representations, has a "header + message" structure. This is a commonly-occurring structure because it effectively separates meta-data and data. In MEI these two parts of the file are called meihead and work. The meihead element contains meta-data about the encoded data found in the work element.
The header is modeled on the TEI teiHeader element and therefore has the same components as in TEI — filedesc, encodingdesc, profiledesc, and revisiondesc — plus an meiid element. The filedesc and meiid elements are required. Filedesc contains further sub-elements describing the electronic file itself and the sources from which it was drawn. The encodingdesc element documents the relationship between an electronic file and the source or sources from which it was derived. That is, it describes the purpose of the encoding and the methods used to create the file. A description of the non-bibliographic aspects of the creation of a work, that is, the languages and sub-languages used, the situation in which it was produced, e.g. the participants, setting, reception history, etc., is provided for by the profiledesc element and its children. The revisiondesc element provides a place to encode the revision history for the electronic file.
The work element of the MEI file contains the actual encoded content. MEI is agnostic regarding the definition of the term work — it is simply the thing being encoded. It can be a monophonic song or a complex symphony — the character of the work is encoded in the work element's components. The underlying assumption, however, is that the original work being encoded is or can be expressed in a written form. A musical work in MEI terms may be a collection of works, such as a printed collected edition or an electronic database of related works.
The work element allows front, music, and back components. Critical editions and collections of works often contain extensive text, such as a table of contents, an introduction, commentary, a biography, an index, etc. Accommodating this text within MEI gives control of the text as well as the notation markup to the encoder of the MEI instance and to the music markup community rather than the creators and maintainers of the text standard. In addition to front and back matter, MEI can also encode the introductory or explanatory text sometimes found between sections of a musical work.
The music element encodes the musical content of the work. It contains one or more discrete, linear segments, called mdiv ("musical division"). An mdiv is the highest-level indication of the structure of the composition. For example, a single mdiv indicates a single-movement work; however, when a musical work can be broken into several top-level segments, the music element may contain multiple mdiv elements. The mdiv element is a generic one which may be typed — a symphony, for example, usually consists of movements while operas are made up of acts. A part or score may be divided into linear segments or sections. Section elements often function as a scoping mechanism for clef signs, key and meter signatures, plus metronome, tempo, and expression markings. Their use also minimizes the need for backward scanning to establish context when the starting point for access is not at the beginning of the score. Section elements may also be used for other user-defined, i.e., analytical or editorial, purposes, and arbitrarily nested to any desired level. There is also an ending element, a specialized instance of section element that may not be recursively nested.
Also allowed within work is the facsimile element. Facsimile contains a representation of a written source in the form of a set of images rather than as transcribed or encoded text.
The mdiv element may contain one or both of two possible views. The score element contains a traditional, full open score while the parts element contains each performer's view of the work. Score and parts views are intended to accommodate different methods of organizing the markup — no particular presentation is implied, and software may render a collection of parts as a score or a score as a collection of parts. The explicit encoding of two views is necessary because it is not always possible to automatically derive one view from the other. In addition, separating scores and parts can eliminate a great deal of markup complexity.
A part element contains an individual performer's view of the score, effectively a mini-score requiring all the encoding features of a full score. The encoding of individual parts is practical when they do not share visual characteristics, such as typeface or page layout, with the full score. Part elements in MEI have little to do with voice leading, which can be encoded using the next attribute available on all event-type elements.
In both score and part views, the scoredef element and its sub-elements are used to describe logical characteristics of the encoded music, such as key signature, the "actual" key (as opposed to the notated key signature), meter, etc. and visual features, such as page size, staff groupings and labels, etc.
Within section elements several methods of organization are possible, depending upon the time period of the notation and the encoder's needs. For example, the default organization is measure-by- measure, with staff and layer sub-elements within measure. However, staff-by-staff organization is more appropriate for music without measures, e.g. mensural notation. Also, staff-by-staff organization might be preferable for reproduction of the visual layout of the music, while the measure-by-measure approach might be preferable for automated analysis.
Within the measure element, events, not symbols, are modeled. Events are the typical, timebased, discrete atoms of musical data, such as notes, chords, rests, etc. While events may have visual properties, modeling symbols places too much emphasis on presentational qualities and makes the markup less generally useful as a "music" markup standard. The list of elements comprising the event class and the attribute definitions they share are user-definable.
So-called "control events", such as dynamics, ties, phrase marks, pedal marks, etc., depend upon other events, such as notes or rests, for their existence. They often do not fit the principal hierarchy of sections, measures and staves. In addition, they cannot always be treated as properties of other events or forced to conform to the same markup hierarchy. Therefore, a second class of events exists in MEI for these musical elements. However, just as for the event class, the list of participants and the attributes they share are user-definable for control events. It should be noted that some event attributes are "propagated". That is, if not supplied, their values should be obtained from a previous event in the same measure. Other attributes are "implied"; that is, their values are contextual and may be supplied later, at the time of rendition, for example.
See the example of basic file structure.
