History:Release Data Set Proposal

From MusicBrainz Wiki
Status: This page describes a failed proposal. It is not official, and should only be used, if at all, as the basis for a new proposal.

Proposal number: RFC-Unassigned
Champion: None
Status: Failed, due to Officially closed as Abandoned, March 24, 2010
This proposal was not tracked in Trac.

Attention.png Status: This document might contain BadTerminology or references to renamed entities because of the terminology change from Album to Release; Please revise --Keschte

As described in ReleaseHandlingPhilosophy the release data of releases needs to be expanded. This is a proposal for replacing the current ReleaseEvents, consisting of a date and a country, with a more detailed set of data, the Release Data Set. It is part of the ReleaseRework process.

Please note: Attention.png At the moment some people store such info in ReleaseAnnotations. For a ProposedStyleGuideline on how to do this in a standardized format see ReleaseAnnotationStyle.


One ReleaseEntity can have multiple Release Data Sets. One Release Data Set stores the following fields:

  • edition comment (text string; optional)
  • 0 or more DiscIDs
  • One or more release event sets including:
    • Date
    • Region (optional)

As you see DiscIDs can be assigned to one actual release.

The edition comment identifies Release Data Sets for releases which have special sub titles given ("Limited Edition", "Gold Edition", "Remaster" aso.) or need some other release description which cannot be expressed through the other attributes (for example packing like "slimcase" or "digipack") - it would need a style guideline for the allowed content.

Release dates do not necessarily need to store a country. Also country is now replaced by region which also contains Europe, worldwide and such (see ReleaseRegionStyle). Allowing more than one of those date/region sets makes it possible to list multiple countries (with possibly different dates) for the same piece of media.

LabelEntities are described in the AdvancedEntity proposal. The Release Data Set only stores the reference to the entry in a special label table. The set can handle multiple label references if there is more than one label (or the distributor) mentioned on the cover. Also it can optionally store a catalogue identifier for each of them as often the label and the distributor have their own catalgoue identifiers for the same release.

The identification code list allows codes for different identification systems to be entered. The list of possible code systems can be maintained like the link types for flexibility, including attributes: code system name (like "ASIN"), allow multiple (if the code system can be used more than one time for a release, like Amazon sometimes has multiple numbers for the same release) and a URL-format which allows linking to the resource using the code number in it. The user choses to add a code number, selects one system from the list to add and enters the code number.

The ReleaseEntity then stores:

  • ID
  • Name of the release
  • Artist ID
  • Track listing
  • an initial set of track times if imported from freedb
  • a list of Release Data Sets including the set "Unidentified" (explanation below..)
  • perhaps two fields for recording date and place (redundancy for later releases of the release solved with DisplayInheritance)
  • Language and encoding

Converting to this model

If this will be implemented we need to make sure all the data can be converted to the new model. So if DiscIDs are to be attatched to Release Data Sets how will this be done when converting?

I therefore propose always having a Release Data Set called "Unidentified" where all the DiscIDs will be put first. They can then be moved to another set.

Presenting the release

This is rather much information so I propose showing only the most important bits and link to a page showing more details of a Release Data Set which also allows to edit it.

The sets are shown below the track listing and the fields which belong to the whole release (like language/encoding). The set "Unidentified" comes first, then the other sets sorted by (lowest) release date.

On the left we have the most important info of the set (the title "Unidentified" or for the others "date - region <line break> LabelName <line break> more..." with "more" being a link to a page for more details) and on the right the list of DiscIDs for this set (including to total running time and links to move/del the id).

Selecting the info important for the whole release

If we have multiple ASINs then which cover should be displayed? If we have multiple DiscIDs then which track times should be displayed?

If there is no DiscID take the track times from freedb (if none are present display ?:??). Otherwise take the arithmetic mean of the times in the DiscIDs (or first prefer the ids stored under the earliest release date).

If there are several ASINs take the one from the earliest release date.

Extend request methods

Storing all those additional identifiers is nice for completeness - but it gets really usefull if one could do album lookups on base of them - just like with the disc ids. So after implementing this proposal both the RDF request methods and the search pages have to be extended. ISRCs are meant to be stored on the CDs themselves so also the tagger could use them for lookups.

See also