History:Release Data Set Proposal: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
m (10 revision(s))
m (markup)
Line 3: Line 3:
[[Image:Attention.png]] '''Status:''' This document might contain [[Bad Terminology|BadTerminology]] or references to renamed entities because of the terminology change from Album to Release; Please revise --[[User:Keschte|Keschte]]
[[Image:Attention.png]] '''Status:''' This document might contain [[Bad Terminology|BadTerminology]] or references to renamed entities because of the terminology change from Album to Release; Please revise --[[User:Keschte|Keschte]]


As described in [[Release Handling Philosophy|ReleaseHandlingPhilosophy]] the release data of releases needs to be expanded. This is a proposal for replacing the current [[Release Event|ReleaseEvent]]<code><nowiki></nowiki></code>s, consisting of a date and a country, with a more detailed set of data, the ReleaseDataSet. It is part of the [[Release Rework|ReleaseRework]] process.
As described in [[Release Handling Philosophy|ReleaseHandlingPhilosophy]] the release data of releases needs to be expanded. This is a proposal for replacing the current [[Release Event|ReleaseEvent]]s, consisting of a date and a country, with a more detailed set of data, the ReleaseDataSet. It is part of the [[Release Rework|ReleaseRework]] process.


'''Please note:''' [[Image:Attention.png]] ''At the moment some people store such info in [[Release Annotation|ReleaseAnnotation]]<code><nowiki></nowiki></code>s. For a [[Proposed Style Guideline|ProposedStyleGuideline]] on how to do this in a standardized format see [[Release Annotation Style|ReleaseAnnotationStyle]].''
'''Please note:''' [[Image:Attention.png]] ''At the moment some people store such info in [[Release Annotation|ReleaseAnnotation]]s. For a [[Proposed Style Guideline|ProposedStyleGuideline]] on how to do this in a standardized format see [[Release Annotation Style|ReleaseAnnotationStyle]].''


==Attributes==
==Attributes==


One [[Release Entity|ReleaseEntity]] can have multiple ReleaseDataSet<code><nowiki></nowiki></code>s. One ReleaseDataSet stores the following fields:
One [[Release Entity|ReleaseEntity]] can have multiple ReleaseDataSets. One ReleaseDataSet stores the following fields:
* edition comment (text string; optional)
* edition comment (text string; optional)
* 0 or more [[Disc ID|DiscID]]s
* 0 or more [[Disc ID|DiscID]]s
Line 27: Line 27:
As you see [[Disc ID|DiscID]]s can be assigned to one actual release.
As you see [[Disc ID|DiscID]]s can be assigned to one actual release.


The edition comment identifies ReleaseDataSet<code><nowiki></nowiki></code>s 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.
The edition comment identifies ReleaseDataSets 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 [[Release Region Style|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.
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 [[Release Region Style|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.
Line 41: Line 41:
* Track listing
* Track listing
* an initial set of track times if imported from freedb
* an initial set of track times if imported from freedb
* a list of ReleaseDataSet<code><nowiki></nowiki></code>s including the set "Unidentified" (explanation below..)
* a list of [[ReleaseDataSet]]s including the set "Unidentified" (explanation below..)
* perhaps two fields for recording date and place (redundancy for later releases of the release solved with [[Display Inheritance|DisplayInheritance]])
* perhaps two fields for recording date and place (redundancy for later releases of the release solved with [[Display Inheritance|DisplayInheritance]])
* Language and encoding
* Language and encoding
Line 47: Line 47:
==Converting to this model==
==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 [[Disc ID|DiscID]]s are to be attatched to ReleaseDataSet<code><nowiki></nowiki></code>s how will this be done when converting?
If this will be implemented we need to make sure all the data can be converted to the new model. So if [[Disc ID|DiscID]]s are to be attatched to [[ReleaseDataSet]]s how will this be done when converting?


I therefore propose always having a ReleaseDataSet called "Unidentified" where all the [[Disc ID|DiscID]]s will be put first. They can then be moved to another set.
I therefore propose always having a ReleaseDataSet called "Unidentified" where all the [[Disc ID|DiscID]]s will be put first. They can then be moved to another set.

Revision as of 14:10, 18 March 2009

Template:NGSHeader

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 ReleaseDataSet. 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.

Attributes

One ReleaseEntity can have multiple ReleaseDataSets. One ReleaseDataSet 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 ReleaseDataSets 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 ReleaseDataSet 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 ReleaseDataSets 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 ReleaseDataSets how will this be done when converting?

I therefore propose always having a ReleaseDataSet 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 a page showing more details of a ReleaseDataSet 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

Discussion


| Original author: Shepard