History:Release Handling Philosophy Proposal

This is a proposal that is an alternative solution for some problems the proposal ReleaseGroups tries to solve. I'll give some definitions that are oppositional to the definitions in ReleaseGroups and show why I think ReleaseGroups is not the correct way to solve the problems we have with albums. Also this includes a slightly change in the MusicBrainzPhilosophy of WhatDefinesAnUniqueAlbum.

Definitions

Here are some terms used in this proposal:

• Album: The abstract idea of an album. One album can be released in multiple forms: on multiple media formats, with different track listings, as re-release, remaster, re-recording, live version, unplugged version, ... but it still falls under the same idea of the abstract album. One could collect all these versions in an AlbumGroup. This is what is proposed in ReleaseGroups. An album is there called release. But I think this is not what the music industry calls it.
• Edition: One edition or version of an album. Like "original edition", "basic edition", "limited edition", "special edition", "gold edition", "live edition" and so on and so forth.
• Release: The actual release of a certain version of an album at a certain release date. All info concerning one release is to be stored in a ReleaseDataSet.
• AlbumEntity: This is the way we store albums in the database. And album entity combines the abstract idea of an album with a certain release in a way that an abstract album idea will be listed multiple times in the discography.

The basic idea...

...of this proposal is: keep AlbumEntities mostly as before. Don't separate the abstract idea of an album from one actual release or data-set but change the guidelines a little bit.

So we go on saying: in the MB understanding of an album different characteristics of an abstract album idea mean different AlbumEntities. But: more tolerant (but precise) guidelines for repeating identical track listings.

That means: a single released alone and the same single released in a BoxSet = different AlbumEntities because of different AlbumTitles.

Also: allow "Special Edition", "Gold Edition", ... as legal SubTitles if they are printed on the cover. This automatically leads to them being allowed as duplicates. Example: Apocalyptica's album Cult was released in two editions: in 2000 as a normal 1-disc album and in 2001 as a 2-disc album with disc 1 being identical to the previously released 1-disc album. The 2001 edition has "Special Edition" printed on the cover. So what is now "Cult" and "Cult (bonus disc)" would then become "Cult", "Cult: Special Edition (disc 1)" and "Cult: Special Edition (disc 2)".

This can only be done if we allow DiscIDs to be added to multiple nearly identical albums.

Smaller differences which don't justify extra AlbumEntities are expressed through different ReleaseDataSets of one album. For this reason the current release data is to be extended. So: "AlbumTitle (Re-Release 2004)" will be stored with an extra ReleaseDataSet under the original AlbumEntity if it doesn't have a different track listing and the track times only differ slightly.

Why not release groups?

The ReleaseGroups proposal was written among others to solve the problem of BoxSets but it does not solve it. Example: you have a single being released alone in different versions and one of these versions released in a BoxSet. With ReleaseGroups you sort this single under a group which combines the different versions of the single. But also you want the single released in the BoxSet being grouped in this BoxSet. So there is an overlapping of the groups.

I think now that we have AdvancedRelationships we don't need groups. We can:

• link different re-releases of an AlbumEntity to the original release.
• link remasters to the original release.

So why not also use the PowerOfAR for doing the rest? Something like...

• "is in (box) set with" (perhaps better to think of a link form to just link to the first disc)
• "Single is taken from Album"
• "is re-recording of"
• "is special edition of" (for different versions released at the same or nearly the same day)
• "is [official released] translation/transliteration of"

The rest is then only a question of displaying the info. We have redundancy with release dates of multiple discs selled in one set. We have redundancy with links to reviews which only write about an abstract album but not one single release (but some do!). We have redundancy with Wikipedia articles about abstract albums. We have redundancy with links to Discogs entries which span multiple discs. And we have the same for artists (PerformanceName, LegalName). I think all this can be solved with AR and some work on the displaying interface. How to do this I explain in DisplayInheritance.

Discussion

Hmm, I still feel that an AdvancedEntity (in your case AlbumGroup) would make a lot of sense here. This way you could link the album entities to the group and not to the first released album. --DonRedman

---

| Original author: Shepard