MusicBrainz Summit 12

As CompMusic we had some features that would like to see added to MusicBrainz to make it easier for us to store relevant music information for the project. One feature of MusicBrainz is to take the standard model of Artists, Albums, and Recordings, and augment the information with relationships. These relationships take two entities in the MusicBrainz ecosystem (for example, a recording and an artist) and define a link between them. For example, an existing relationship in the music that we have added as part of the CompMusic collections is “S Venkataraman plays tambura on a recording of Raghu Nayaka.”

 

There is a community process to add new instruments to the list of recognized instruments, including the need to show two releases (albums) which show the instrument being used on that release. The MusicBrainz team helpfully waived this requirement for us and helped us add about 15 new instruments. Currently in MusicBrainz the list of instruments is described as a static tree of instruments. This tree has some shortcomings, especially when the same instrument is called by a different name in a different culture or fits in a different part of the tree depending on how it is played (e.g., there is a different entry for bowed violin and plucked violin). As CompMusic we proposed turning instruments into first level entities in the MusicBrainz database. This means exposing a unique identifier for each instrument. By using an identifier to refer to an instrument instead of a name, the name can be translated depending on the culture and we can develop an instrument ontology that makes sense within the context of the musical culture that we are working on.

 

There is some factual information about music that cannot be stored in the MusicBrainz database. For example, in CompMusic we want to use some composition-related features (like the Raaga or Raga and Taala or Tala in Carnatic and Hindustani music, respectively, and Makam and Usul in Makam music of Turkey) that do not change regardless of who performs that composition. This information cannot currently be stored in MusicBrainz. There is a mechanism for adding these types of attributes to entities in MusicBrainz, but it requires a completely new release of the musicbrainz server and database, which inconveniences all musicbrainz customers. These releases only typically happen twice a year, so if we missed something it would be a long wait to correct it. We proposed to add a concept of “Dynamic attributes”, which lets new definition terms and values to be added to the database by a site administrator without needing to release a new version of the MusicBrainz database. This feature will help CompMusic, with our culture-specific attributes, but will also help the rest of the MusicBrainz community who have been asking for a feature like this (Dynamic attributes) for years.

 

The changes to these two features of MusicBrainz will be developed by the CompMusic team, in collaboration with the MusicBrainz developers. The deadline to complete them is by the next “schema change release” (release that changes the database structure) in May 2013. Once these changes are complete we will be able to add missing data to the CompMusic collection, and other MusicBrainz editors will be able to add another level of data to existing information in the MusicBrainz database.

 

The summit was a good chance to meet a bunch of people who are all passionate about music and music metadata. It’s good to see that the future of an open database of all music written and recorded is in good hands!

 

 

(Alastair Porter, Mohamed Sordo)