Difference between revisions of "MusicBrainz XML Meta Data"

From MusicBrainz Wiki
(starting as a rip-off from the XMLWebService page (Imported from MoinMoin))
((Imported from MoinMoin))
(No difference)

Revision as of 19:40, 5 May 2006

The MusicBrainz XML Metadata Format

Attention.png Status: Beta testing in progress. Feel free to improve the documentation but don't change technical details.


The MusicBrainz XML Metadata Format (MMD) is an XML based document format to represent music metadata. It has been designed to be easy to read, powerful and extensible. MMD is the official successor of the old RDF-based metadata format, which was popular among semantic web enthusiasts, but didn't have much acceptance otherwise because of its perceived complexity.

The initial and predetermined use of MMD is in the MusicBrainz Web Service. However, it may be useful for other applications, too. Third party use and extensions to the format will be discussed later in this document.

TODO: At this point, there is not much documentation on it yet, but examples and a Relax NG schema are available via subversion:

svn co http://svn.musicbrainz.org/mmd-schema/trunk mmd-schema

This is also available via the trac source browser.

Bugs in the schema should be reported on the IRC channel or posted to mb-devel. Please note that we're not going to make major changes to the format, only remaining mistakes will be corrected.

IDs and Types

The IDs and types used in the XML format are URIs. To keep the transmission overhead low, all URIs in the MusicBrainz namespace may be used in their relative form. So if a track's fully qualified id is http://musicbrainz.org/track/d6118046-407d-4e06-a1ba-49c399a4c42f, it may be shortened to d6118046-407d-4e06-a1ba-49c399a4c42f in the XML. Note that this shortening is only allowed for URIs from the MusicBrainz namespace.

The following rules apply to create a fully qualified URI from a relative one:

  • The id attributes:
    • artist: http://musicbrainz.org/artist/relative URI
    • release: http://musicbrainz.org/release/relative URI
    • track: http://musicbrainz.org/track/relative URI
  • The type attributes:
    • artist: http://musicbrainz.org/ns/mmd-1.0#relative URI
    • release: http://musicbrainz.org/ns/mmd-1.0#relative URI (for each relative URI in the list)

Due to their large number, relations are in a namespace on their own to avoid clashes:

  • Various relation attributes:
    • type: http://musicbrainz.org/ns/rel-1.0#relative URI
    • attributes: http://musicbrainz.org/ns/rel-1.0#relative URI (for each relative URI in the list)

Note: Don't confuse the URIs, especially the id URIs with URLs. The URIs are just names, they should not be used to query data from the server. But they are in a permanent format which will always be valid and can easily be transformed to URLs. Example:

The following is an absolute, permanent MusicBrainz artist identifier which is the preferred representation. Shorter representations may be used for storing IDs in file tags or databases.


This one is a URL created from the URI above, using a simple transformation. It can be used to request data from the MusicBrainz server via the webservice. URLs may change over time, the URIs will not.


Using the XML format for other applications

The XML format format uses URIs for several IDs and types. The artist element, for example, has a type attribute which accepts a URI. Users of the format may use the URIs defined by MusicBrainz or use one from their own namespace. This example uses a definition from MusicBrainz:

    <artist id="c0b2500e-0cef-4130-869d-732b23ed9df5" type="http://musicbrainz.org/ns/mmd-1.0#Group"/>

If an application needs "Orchestra" as an artist type, a different namespace has to be used:

    <artist id="c0b2500e-0cef-4130-869d-732b23ed9df5" type="http://example.org/ext-7.2#Orchestra"/>

This method may be used in all places where the schema accepts an anyURI datatype. As mentioned earlier, there is a special rule for all URIs defined by MusicBrainz: They may be relative, as you can see in the examples above. The complete artist ids have the form http://musicbrainz.org/artist/c0b2500e-0cef-4130-869d-732b23ed9df5 and the type attribute in the first example could also be written as Group, without the namespace prefix.

To extend the format even further, the schema has several extension points (see def_extension) which allows adding arbitrary XML elements from a user-defined namespace. Using the mmd-namespace or no namespace at all is not permitted. There are no namespace restrictions inside that element, however, and unlimited nesting is possible, too.

If your private namespace is http://example.org/ext-9.1# and you want to add data from a rating system, for example, it could be coded like this:

<?xml version="1.0" encoding="UTF-8"?>
<metadata xmlns="http://musicbrainz.org/ns/mmd-1.0#" xmlns:ext="http://example.org/ext-9.1#">
    <track id="d6118046-407d-4e06-a1ba-49c399a4c42f">
        <title>Silent All These Years</title>
        <ext:rating value="9"/>

Even more complicated things, like nested tags are possible. Note that the em doesn't belong to the ext namespace.

<?xml version="1.0" encoding="UTF-8"?>
<metadata xmlns="http://musicbrainz.org/ns/mmd-1.0#" xmlns:ext="http://example.org/ext-9.1#">
    <track id="d6118046-407d-4e06-a1ba-49c399a4c42f">
        <title>Silent All These Years</title>
        <ext:annotation>This is a <em>very</em> nice song.</ext:annotation>

This is still valid according to the schema, but inside the extension elements, only well-formedness can be checked.


The MusicBrainz XML Metadata Format has been designed by Matthias Friedrich and Robert Kaye. Most of the schema as well as the test suite have been written by Matthias Friedrich.