History:Object Model: Difference between revisions
(typo's (DonRedman was in a hurry ;)) (Imported from MoinMoin)) |
(aded graph (Imported from MoinMoin)) |
||
| Line 35: | Line 35: | ||
</ul> |
</ul> |
||
* [[Object Model/Track Group|/TrackGroup]] |
* [[Object Model/Track Group|/TrackGroup]] |
||
<ul><li style="list-style-type:none">This is mostly based on [[Track Grouping|TrackGrouping]] |
<ul><li style="list-style-type:none">This is mostly based on [[Track Grouping|TrackGrouping]]. There are also some thoughts about [[Object Model/Representing Remixes|/RepresentingRemixes]] |
||
* [[Object Model/Song Object|/SongObject]] |
* [[Object Model/Song Object|/SongObject]] |
||
* [[Object Model/Composition Object|/CompositionObject]] |
* [[Object Model/Composition Object|/CompositionObject]] |
||
| Line 44: | Line 44: | ||
* [[Object Model/Track Object|/TrackObject]] |
* [[Object Model/Track Object|/TrackObject]] |
||
</ul> |
</ul> |
||
There is a graph that shows the overall structure of this model. It is not complete, nor perfect nor anything but an orientation, but here it is: [[Media:ObjectModel_0_1.png|ObjectModel v0.1]] (and the corresoponding [[Media:ObjectModel_0_1.graph|dot source v0.1]]). |
|||
==Examples== |
==Examples== |
||
Revision as of 00:56, 22 November 2005
MusicBrainz Object Model
Status: 
This page NeedsIntertwingling
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. Those should better happen on the ExpertsMailingList.
Definitions
When talking about object definitions we need a well defined language. Here are the most important ones:
- 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.
- 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.
- 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 /TrackGroup. They help to get an overview.
- 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:
There is no new model yet but only some dumped ideas about artist linking, multiple artists and other stuff which is to be worked into this model: /ArtistThoughts
- God, we don't know yet. This is a terribly complicated area. See AlbumHandlingPhilosophy, AlbumRework, ReleaseGroups and all the others.
- This is mostly based on TrackGrouping. There are also some thoughts about /RepresentingRemixes
There is a graph that shows the overall structure of this model. It is not complete, nor perfect nor anything but an orientation, but here it is: ObjectModel v0.1 (and the corresoponding dot source v0.1).
Examples
When we haave completed a first stab at the objects, we need to check whether they actually fit the reality. We will need a diverse set of examples for this:
