History:Object Model

Status: This page needs to be updated to reflect the results of the MusicBrainzSummit7

This page and its subpages form a document that tries to describe the reality that MusicBrainz deals with as abstract /Objects with Properties and /Relationships. This document is not about a database schema. Its purpose is to understand what we are dealing with. Of course, this effort is strongly related to the creation of a NextGenerationSchema.

This document is written in the form of CollectiveWe, and you are invited to BeBold and write things like "we seem to (dis)agree" or "we have forgotten an important aspect...". This should avoid lengthy threaded discussions.

Definitions

When talking about object definitions we need a well defined language. Here are the most important ones:

• /Object

• An object is a "thing" in the object model. It does not have to be physical, but it needs boundaries that define what is and what is not an object of this class. Each object class has a SubPage of its own of the form /ThisObject. From the perspective of OO programming we are actually talking about object classes, but it is tedious to always say "an object of the xy class".
  • Note that AdvancedRelationships are objects in the ObjectModel, since they have properties. An object-relationship cannot have properties.

• /Relationship

• A relationship is what links two objects together. This is not a relation as in relational database. So please do not talk about 1:n or n:m relations. A relationship has two such pairs. E.g. An AObject can own 0--many BObjects. A BObject is owned by 0--1 AObjects.

• /Group

• A group (as in TrackGrouping) is a an aspect of the reality MusicBrainz deals with. It groups all objects that represent this aspect. Currently there are three such groups: /ArtistGroup, /AlbumGroup and /SongGroup. They help to get an overview.

• /Entity

• An entity is an actual element of the database schema. While this document is not about entities, we might want to talk about them nonetheless. E.g. which objects should be merged into one entity?

These were the most important. The rest is for later.

The Object Model

The actual object model currently consists of the following elements:

• /ArtistGroup, or "diagonal bamboo":

• This is a refinement of /ArtistThoughts

• • /ArtistObject
  • /ReleaseArtistObject

• I propose renaming this to /ArtistLabelObject as a ReleaseArtist is something different now --Shepard
  • Why, is a ReleaseArtist not exactly what we are talking about? "the Artist that appears in the 'artist' field of a Release. There can only be one release artist for each release" (citing ReleaseArtist). The difference is that under NadelnderBambus a release additionally belongs to an album which has one or more 'AlbumArtists', and that the 'ReleaseArtist' is related to the Artists is is composed of. IMO the name is still ok. --DonRedman
    • ReleaseArtist now means the artist of a release object. What was meant here was "a label for the artist name how it is written on releases". This is especially different since it will be linked to release objects _and_ track objects! --Shepard I think I can explain this better: it is about the role of the object. At the moment we have that an Artist object is called ReleaseArtist when it is linked to a Release object and TrackArtist when it is linked to a Track object. In NGS an ArtistLabel would be called ReleaseArtist when it is linked to a Release object and TrackArtist when it is linked to a Track object. So if you say ArtistLabel == ReleaseArtist that would be the same as saying Artist == ReleaseArtist. --Shepard
      • OK, I got it. But ArtistLabel ist a terrible term. "Label" is something else in musical contexts. Using this only makes things worse IMO. I would not mind too much how the terminology of the object model fits with the current terminology. IIRC the alternative name we had on MusicBrainzSummit7 was /AttributedArtist. Does that help? --DonRedman

• /AlbumGroup, or "vertical bamboo":

• Based on ReleaseHandlingPhilosophy, AlbumRework, ReleaseGroups etc.

• • /AlbumObject
  • /ReleaseObject
    • /ReleaseEventObject

• • /MediumObject
    • /TOCObject

• • /TrackObject

• /SongGroup, or "horizontal bamboo":

• This is mostly based on TrackGrouping. There are also some thoughts about /RepresentingRemixes
  • /SongObject (not part of the NextGenerationSchema)
  • /CompositionObject
  • /RecordingObject
  • /MixObject
  • /MasterObject
  • * /FingerprintObject
  • /TrackObject (yes, that one is in both groups)

• The "pins" (these are not included in the graphic yet, sorry):
  • /ReleaseTitleObject (inbetween /ReleaseObject and /ReleaseArtistObject)
  • /MediumTitleObject (of the /MediumObject)
  • /TrackTitleObject (inbetween /TrackObject and /ReleaseArtistObject)
  • and additionally
    • /UberTitleObject and
    • /SubTitleObject

The following graphic describes the ObjectModel as refined on the summit (code-named "NadelnderBambus"). Note that the names have changed and might change again. Sorry for that:

See the attachments page for some older graphs.

Examples

Now that we have completed a first stab at the objects, we need to check whether they actually fit the reality. Big thanks to everybody who contributed to this list in the Next Generation Database Schema thread on the UsersMailingList.

1. /FelaITTExample, showing an release that is a merge of two previously released releases, and a track that is a merge of two previously separated tracks.
2. /GiantXmasExample, showing a Japanes one-time project as ReleaseArtist.
3. /ShuujiAndAkiraExample, showing different ReleaseArtist and TrackArtists plus confusing aliases and PerformanceNames.
4. /TerraRevolutionExample, showing one release with a single track being a megamix of another release.
5. /PartyPeopleExample, showing an release containing one track being a megamix of all other tracks.
6. /CassetteboyExample, showing an artist who changes his performance name for every track.
7. /RunTimeAllStarsExample, showing varying and vague artist collaboration that had only this one release.
8. /AhhcoExample, showing one track by another artist on a single artist release.
9. /ElectricLightOrchestraExample, showing an release that has a different name in one country
10. /AngeldustExample, showing two releases with exact same content, but released under different artist and title.
11. /ChantsMagnetiquesExample , showing two localized variants onf one release.
12. /DonSebskyExample, showing the case of a Jazz composer.
13. TracksWithMultipleArtists contains an example of its own, showing tracks that consist of more than one song by more than one artist
14. /QueenPlatinumCollectionExample, showing releases that were re-released as a box set without remastering.
15. /GylleneTiderExample, showing releases that were re-released as a box set without remastering, and later as single remastered releases.
16. /JesusChristSuperstarExample, which has tracks containing two songs and poses a challenge to the TrackGroup and AR.
17. /DepecheModeRemixesExample, showing identical discs on different releases and other problems.