This document describes the schema of the Classical Music Index (CMI).

The goal of CMI - and hence of this schema - is to help people find and discover classical music: old and new, well-known and obscure. CMI is not meant to store detailed musicological metadata beyond what might be useful for these purposes. When we discuss issues like what 'instrument' means (see below) our goal is not to make editorial judgements, but to anticipate the needs to people looking for music.

CMI is seeded with Mediawik-format data from IMSLP, and its schema is influenced by the structure of IMSLP's data. But CMI doesn't try to including everything in IMSLP, and it also includes things like concerts that are not present in IMSLP.

The CMI schema involves a number of 'classes'. Each class has a set of 'attributes', some of which can refer to items (of the same class or other classes).

Classes have names like 'composition'. To avoid confusion, when we refer to a class we use capitalized boldface, e.g. Composition. Otherwise we just mean the (possibly vaguely defined) word, e.g. 'composition'.

What's a composition?

The central class in CMI is Composition. An entry can represent:

• A single piece, suite, or sonata.
• A section of a 'parent' composition. (e.g. a movement of a symphony, or piece in a suite).
• An arrangement of another composition.

The 'parent' link allows potentially arbitrary levels of hierarchy. This raises the question of what should be considered a 'composition'. In general, our principle is:

A composition is something that could plausibly be played as a unit.

Let's look at some examples.

Sections of compositions

How should we handle subdivision? For example, if a composition consists of 30 variations, should we treat each one as a Composition?

In general, yes. Because:

• A listener might love some variations and hate others, and should be able rate them separately.
• A performer might perform or record a subset of the variations.
• There might be an arrangement of a single variation.
• Each variation might have its own key and tempo marking; we need a place to store these.

The easiest way to accomplish these goals is to model each variation as a Composition.

On the other hand, a Minuet might contain a Trio. We don't represent the Trio as a Composition because it wouldn't be played separately from the Minuet.

Some compositions have a more complex structure:

• An opera might consist of an overture and several acts, each with several scenes, each with several arias or choruses.
• Bach's Christmas Oratorio consists of 6 days, each with a title and several songs.
• Brahms' Paganini Variations consists of two 'volumes'; the variations within each volume are numbered starting from one.

We could represent these structures as hierarchies of Compositions, and for some applications of CMI (like generating a program for a concert) this might be useful. But for simplicity we don't do this.

Collections of compositions

Compositions can be collected in various ways. Should a collection be treated as a Composition? Examples:

• Grieg's Lyric Pieces Book I (op. 12) and each of its components ('Arietta' etc.) are Compositions. But the set of all 10 books of Lyric Pieces is not a Composition; it's not intended to be performed as a unit.
• Similarly, "Beethoven's 32 piano sonatas" and "Bach's English Suites" are not Compositions.
• Brahms' "Intermezzi op. 118" is a Composition; it's intended to be played as a unit.
• A composer might publish several sonatas under a single Opus number. This group would not be a Composition.

In summary:

• CMI uses at most two levels of hierarchy: top-level compositions and (possibly) their bottom-level components.
• An arrangement of a composition or sub-composition is represented as a separate Composition.

Versions of compositions

Some compositions were significantly revised after their first publication. If this involved adding or removing sections, then the revision is a separate Composition. Otherwise whether to separate it is a judgement call: e.g. is the revision sufficiently different that someone might rate it differently than the original?

Relation to Scores

CMI has another class called Score, representing published scores (physical or digital). Compositions should not be confused with Scores:

• "Dover's Beethoven Piano Sonatas volume one" is a Score, but it doesn't have a corresponding Composition; rather, it contains 16 Compositions (the individual sonatas).
• A given Composition may not have a corresponding Score in CMI. Or it may have many.

What's a score?

A Score is a graphical representation of a collection of pieces (e.g. Beethoven's sonatas vol. 1) or a single piece., or a file from which such representations can be generated.

If the composition is for multiple instruments, the score might have separate parts for each instrument. The Score represents the whole collection.

A Score might be

• A physical (paper) entity. CMI is concerned with scores that are available somehow (purchase, library loan).
• A virtual score, e.g. a PDF, MuseScore file, or Lilypond file.

Describing instrumentation

A composition's 'instrumentation' is the set of instruments or voices normally used to perform it. This is described by two classes: Instrument represents instruments (piano, violin, etc.) and Instrumentation represents a list of (count, instrument) pairs: for example, '1 piano and 3 violins'.

Each Composition has one or more Instrumentations. If a piece is for a solo instrument, the Instrumentation is a singleton, e.g. '1 piano'. There are infinitely many possible instrumentations; the Instrumentation class includes only those that are used in at least one Composition.

It's not always clear what should be considered an Instrument. The main criterion (see above) is: what will help musicians find music most easily? Some cases:

• An instrument played a particular way, (e.g. 'Piano 4-hands' or 'Piano left hand') is an Instrument.
• Each member of an instrument family is an Instrument: 'tenor saxophone' is an Instrument, and so is 'saxophone': an unspecified saxophone.
• Similarly, 'voice', 'soprano', 'mezzosoprano', are Instruments. (Note: If a composition has a vocal part, we might specify the pitch range, but for now we don't do this).
• A historical version of an instrument is an Instrument; for example, 'Baroque violin'.

Instrument hierarchy

There is an inclusion relationship ⊂ between Instruments:

• Baroque violin ⊂ Violin
• Female Chorus ⊂ Chorus
• coloratura soprano ⊂ soprano ⊂ female singer ⊂ singer

CMI currently doesn't model this relationship. Doing so might be useful, but it would add complexity. In particular, we'd need to address the question: if a user searches for music for soprano, should we show them music for specializations (like coloratura soprano)? For generalizations (like female singer)?

Locations

In CMI composers can be linked to the countries where they lived, and concerts can be linked to the city where they took place. We want to let users search for music from, say, Southeast Asia, or from New York City.

Hence we need a way of representing a hierarchy of locations. This is done using two classes. Location type has items continent, subcontinent, country, province, city. These have an implicit containment relationship: a city is in a province, and a province is in a country.

Entries can be entities that no longer exist (like Bohemia) or that used to be a different type (e.g. Venice used to be a country).

The Location class represents geopolitical entities. Each item can be linked to a 'parent' item at a higher level of the hierarchy. For example, the parent of 'Germany' (country) might be 'Europe' (continent).

Each item has a name, and the (name, parent) combination must be unique. This means, for example, that the parent of 'Springfield' must be e.g. the province 'Illinois', not the country 'United States', since there are many Springfields in the United States.

CMI's search features take hierarchy into account. For example, if you search for East Asia, you'll get items that are linked to Tokyo (because Tokyo is in Japan, and Japan is in East Asia).

The attributes of Location include two versions of the location name:

• Place name, e.g. 'Denmark'
• Adjective, e.g. 'Danish'.

Note: you'd think that a location database of this sort already exists. I was unable to find one.

Period

IMSLP has a notion of 'period': Baroque, Classical, Romantic, etc. CMI includes this data, but de-emphasizes it. 'Period' is a misnomer: these terms are actually styles or genres, they're useful only for Western music, and they're subjective. On the other hand, users might want to include these as search criteria. It might be more useful to have a system of 'tags'.

Race and ethnicity

The idea of distinct races seems outdated. But it's likely that some users will want to search for music by black composers, or to study the racial breakdown of concerts.

To avoid going down rabbit holes, CMI uses the list on U.S. government forms: American Indian, Asian, Black, Hispanic, Pacific Islander, and White. This is a bit odd - 'Hispanic' is an ethnicity, not a race - but there it is. People can be linked to zero or more of these, and you can search on them.

CMI classes

Implementation notes

• The CMI schema is implemented as a relational database using MySQL. The scheme could be implemented in RDF and SparQL, and the data could be exported in other forms (JSON, XML).
• The design tries to be orthogonal: it avoids duplicated data, and tables don't contain data that could be inferred from other tables. This could potentially cause performance problems: queries involving elaborate joins might be slow. We could solve this using separate search mechanisms, e.g. in-memory scan of a flattened data structure.
• Some attributes are lists of links to other items. These lists are ordered (though in some cases the ordering is irrelevant). They are implemented as a JSON field containing the IDs of the linked items. MySQL and MariaDB support this and let you query against the IDs; MySQL supports 'multi-value' indices so that these queries are fast.
• Text fields are Unicode (UTF-8). Person names and non-English strings are spelled with diacritical marks.
• The schema must deal with things like:
  • Multiple people with the same name.
  • Names that are spelled differently in different languages.
  • People with multiple names (aliases).
  • People whose names change over time, e.g. because of marriage.
  ... and similar issues for the names of compositions and other item types.
• Text fields are tagged with their language. There's a provision for translations to other languages (using external tables) and an indication of the original language where appropriate. Perhaps users can select a 'preferred' language, determining how names are displayed to them ('Trois Nouvelles Études' or 'Three New Etudes', 'Skrjiabin' or 'Scriabin', 'Germany' or 'Deutschland') and how their search terms are interpreted.
• Where there's hierarchy (e.g. movements within a composition) the children inherit the parent's attributes but in some cases can override them.
• All items have a notion of editorial 'vetting'. Unvetted means either
  • the item itself is unvetted, or
  • the item is an unvetted edit of a (possibly vetted) item.
  Unvetted items have a description of the change and who made it. The DB stores a history of edits.
• All items have a notion of 'forwarding': items A and B were found to refer to the same thing; item A is now authoritative.
• All items have an associated message list for discussion of edits. There's a scheme (not described here) for editors to register interest in an item and get notified when it's edited.
• Tables for which there are other data sources (country, language, person) include IDs from those sources.
• There could be various other item types; for example:
  • Information about the use of recordings in movies.
  • Information about 'festivals': groups of concerts, with an organizer.

Picture

A diagram of some of the tables and their relationships. An arrow means items in one table link to items in another.