History:Release Data Set Proposal: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
(expanded it a little bit (Imported from MoinMoin))
 
m (CallerNo6 moved page Proposal:Release Data Set to History:Release Data Set Proposal: https://chatlogs.metabrainz.org/brainzbot/metabrainz/msg/3675767/)
 
(27 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{proposal_failed
As described in [[Album Handling Philosophy|AlbumHandlingPhilosophy]] the release data of albums needs to be expanded. This is a proposal for replacing the current [[Release Dates|ReleaseDates]], consisting of a date and a country, with a more detailed set of data, the ReleaseDataSet.
|status=Officially closed as Abandoned, March 24, 2010
|champion=None
|trac=
}}

[[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]]s, consisting of a date and a country, with a more detailed set of data, the Release Data Set. 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]]s. For a [[Proposed Style Guideline|ProposedStyleGuideline]] on how to do this in a standardized format see [[Release Annotation Style|ReleaseAnnotationStyle]].''


==Attributes==
==Attributes==


One [[Album Entity|AlbumEntity]] can have multiple ReleaseDataSet<code><nowiki></nowiki></code>s. They store the following fields:
One [[Release Entity|ReleaseEntity]] can have multiple Release Data Sets. One Release Data Set stores the following fields:
* edition comment (text string; optional)
* One or more [[Disc ID|DiscID]]s
* 0 or more [[Disc ID|DiscID]]s
* date
* One or more release event sets including:
* country (or [[Release Area|ReleaseArea]])
* label id
** Date
** Region (optional)
* distributor id
* [[Catalogue Number|CatalogueNumber]] (a text string)
* [[ASIN]]
* [[Barcode|BarCode]] (and [[Barcode|BarCode]] type like [[EAN]] or [[UPC]])
* [http://www.ifpi.org/isrc/ ISRC (International Standard Recording Code)]
* ...?


* 0 or more label sets:
Label id and distributor id refer to [[Label Entity|LabelEntities]] which are described in the [[Advanced Entity|AdvancedEntity]] proposal. If there are multiple labels mentioned on the cover choose the sub-division on the lowest level. Alternatively one ReleaseDataSet could also store a list of countries (and the respective release date) to avoid redundancy of the other stored fields (if one label released the disc in several countries under the same Cat#). Also often label and distributor have their own catalogue numbers.. so either add separate numbers for both or add separate ReleaseDataSet<code><nowiki></nowiki></code>s for every label mentioned on the cover - not very good I say as this lets one think they are different releases.
** [[Label Entity|LabelEntity]] ID (Label/Distributor reference)
** [[Release Catalog Number|ReleaseCatalogNumber]] (text string; optional)


* type, status, physical media as described in [[Release Type Restructuring Proposal|ReleaseTypeRestructuringProposal]]
The [[Album Entity|AlbumEntity]] then stores:
* Identification code list (adding an item is optional), including code systems like:
* The ID
** [[ASIN]]
* The name of the album
** [[Barcode|BarCode]] (no matter if [[EAN]] or [[Universal Product Code|UPC]] because [[Universal Product Code|UPC]] is a subset of [[EAN]])
* The artist ID

* The track listing
As you see [[Disc ID|DiscID]]s 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 [[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.

[[Label Entities|LabelEntities]] are described in the [[Advanced Entity|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 [[Release Entity|ReleaseEntity]] then stores:
* ID
* Name of the release
* Artist ID
* 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 Release Data Sets including the set "Unidentified" (explanation below..)
* perhaps two fields for recording date and place (redundancy for later releases of the album 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

As for release type, release status and the physical media proposed by [[User:mo|mo]] in [[Release Type Restructuring Proposal|ReleaseTypeRestructuringProposal]] I'm not yet sure where they belong..


==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 Release Data Sets 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 Release Data Set called "Unidentified" where all the [[Disc ID|DiscID]]s will be put first. They can then be moved to another set.


==Presenting the album==
==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.
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 album (like language/encoding). The set "Unidentified" comes first, then the other sets sorted by release date.
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 - country <line break> [[Label Name|LabelName]] ([[Distributor Name|DistributorName]]) <line break> more..." with "more" being a link to a page for more details) and on the right the list of [[Disc ID|DiscID]]s for this set (including to total running time and links to move/del the id).
On the left we have the most important info of the set (the title "Unidentified" or for the others "date - region <line break> [[Label Name|LabelName]] <line break> more..." with "more" being a link to a page for more details) and on the right the list of [[Disc ID|DiscID]]s for this set (including to total running time and links to move/del the id).


==Selecting the info important for the whole album==
==Selecting the info important for the whole release==


If we have multiple [[ASIN]]s then which cover should be displayed? If we have multiple [[Disc ID|DiscID]]s then which track times should be displayed?
If we have multiple [[ASIN]]s then which cover should be displayed? If we have multiple [[Disc ID|DiscID]]s then which track times should be displayed?
Line 51: Line 71:
If there are several [[ASIN]]s take the one from the earliest release date.
If there are several [[ASIN]]s take the one from the earliest release date.


==Extend request methods==
==See also==


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. [[ISRC]]s are meant to be stored on the CDs themselves so also the tagger could use them for lookups.
* [[Release Region Style|ReleaseRegionStyle]]
* [[Release Type Restructuring Proposal|ReleaseTypeRestructuringProposal]]


==Discussion==
==See also==


* [[Release Rework|ReleaseRework]]
----| Original author: Shepard
* [[Release Region Style|ReleaseRegionStyle]]
* [[Release Type Restructuring Proposal|ReleaseTypeRestructuringProposal]]


[[Category:To Be Reviewed]] [[Category:Discussion]] [[Category:Development]] [[Category:Proposal]]
[[Category:Discussion]] [[Category:Development]] [[Category:Proposal]]

Latest revision as of 19:14, 28 August 2016

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.

Attributes

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