History:Album Rework Proposal
|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.|
- 1 Introduction
- 2 Entity Types
- 3 Linking
- 4 Examples
- 5 Consequences
- 6 Outlook
- 7 Comments
This is my second try for an alternative/extending proposal to ReleaseGroups. I've given up some of the ideas in ReleaseHandlingPhilosophy (my first try) and steadily developed my ideas in ReleaseDataSet. But now I think I got the final idea. So here's what I think in one page (as requested ;) )...
The motivation of this proposal is to be able to render every existing case of albums with it intuitively and non-redundant but still keeping it easy to use. The first is achieved by splitting albums into several entity types which can be re-used and combined/linked. The latter is the challenge of the GUI.
There are several entity types for describing an album. I use the term "entity" here as in AdvancedEntities. They all can be part of an AdvancedRelationship (well, I don't know how much sense this makes for physical media yet...).
A release is what you buy. It is released at a certain date in certain regions (sometimes also on different days in the regions) and unique identified by code number systems like the EAN, catalogue numbers, etc. A release can contain several albums. It is mostly equal to what I have described in ReleaseDataSet (except the different attributes described in ReleaseTypeRestructuringProposal are now spread over the entity types and this entity is more independent from albums).
The following is a technical description, so ignore it if you want. ;)
- Parameters: title, (labelid, (cat#))*, (date, (region))+, (codesystem, code)*, status, packing, annotation (with backlog)
- title only contains text like "Limited Edition", "Re-Issue", "Gold Edition", ... (not the title of the released album(s)! they are stored in the linked albums)
- status is one of: Official | Commercial | Bootleg | Promotional (so the release status values in ReleaseTypeRestructuringProposal)
- packing is one of: jewel case | digipak | ...
- annotation can contain detailed info about packing & shape, bonus stuff (stickers, autographs), mediums that could not be entered into the db and what not.
The AlbumEntity holds one unique set of titles of one physical media, that is: the album title and links to TrackEntities (in a certain order) which then store their title and duration and so on. That means:
- Different album title -> different AlbumEntity
- Different amount of tracks -> different AlbumEntity
- Different track titles or durations -> different AlbumEntity
And again the parameter listing:
- title, type, tracklisting, language, encoding, annotation (with backlog)
With type being mostly the main types in ReleaseTypeRestructuringProposal. Multiple can be selected.
This is the container for what was the DiscID and CD TOC before. It holds:
- TOC, disc id, type
- TOC & disc id is normally for CD media only, perhaps we can create identifiers for other media types in the future.
- type is one of the physical media types described in ReleaseTypeRestructuringProposal except digital media! Web albums simply don't get a physical media entity attached to them.
The BoxEntity is used for linking albums contained in multi-disc-release together in a certain order. This applies only for releases which don't go under "one main album + bonus disc" but which are several discs which require an ordering.
Also: you can nest boxes into one another. So for these box sets which were (box 2, disc 3) before you would have one main Box, then sub boxes and then the albums.
Note: boxes cannot only contain albums released together in one release. We also could store those singles that have disc numbers although they weren't released together (which often is done in the UK) in one box - the difference is that they all link to their own release.
- Parameters: title, annotation (with backlog)
The title holds the title of the whole box. If the albums in it have no own title (what we had in "(disc 1: Blah Blah)" before) then they simply have an empty title field.
This is a set of albums that describe the same abstract album idea, like: different versions with bonus tracks, re-releases that differ somehow, transliterations/transcriptions/translations, remasters, but not re-recordings!
The purpose of this is to make linking with AdvancedRelationships easier. It is one of the meta groups described in AdvancedEntity. You could for example make an AdvancedRelationship to an AlbumGroup like "has ... performed by" which then is a statement about all contained albums.
- Parameters: title, annotation (with backlog)
These are the entities so far. But the most complex part is the linking which unfolds the full potential of the entities. I divide that into linking by database IDs and linking with AdvancedRelationships.
First there are some problems that arise through the many different cases there are with releases. I identified the following:
- One release can contain several albums
- One album can contain several releases, or: a release can contain an album that was released before, which leads to:
- One physical media (even with the same CD TOC) can be contained in several releases
- But they cannot simply be referenced to from the release because the release is about several albums, so there needs to be a way to link them to album and release together
- One album can contain several physical media identifiers (because it is an abstract title listing independent from different pressings of the physical media)
- Info is not always complete - we can have an album without physical media and release attached or we can have just the physical media attached or just the release or both
- Web albums don't even have a physical media to be attached
- If an album was released alone and in a box together with others you need to attach the release to the box too or it is not clear if the release is about the box or the single album
I'm no expert in databases but I found the following linking schema doing the job. If you think it can be simplified at some positions tell me and I (hopefully) can show you a case where this doesn't work. :)
Linking Album, Physical Media and Release: Table
album_pm_release with columns
album, pm, release as references with all rows being pairwise diverse and (album, pm, release) = (x,y,z)|(x,y,_)|(x,_,z) but not (x,_,_).
Linking Box and Release: One box can have several releases. One release can be about several boxes (only if there are transliterated/transcripted/translated versions of the box). Also you need to link the release to the box and not only to the albums to have it clearly identified. So we have table
box_release with columns
box, release as references.
Linking Box and Album: The linking needs to be ordered by numbers. So: Table
box_album with columns
box, number, album.
Same for linking Box to contained sub boxes: Table
box_box with columns
box, number, subbox.
And finally linking AlbumGroup, Album: Table
albumgroup_album with columns
- How to handle two-sided vinyl?
- What about those DualDiscs (a disc with one side being a CD, one side being a DVD)? Handling them as one media leads to problems with tracklistings.
All the new entities allow a wide new field for AdvancedRelationshipType
s. But also for the old ones I can think of some new types that might come in handy:
- album is transliteration of album
- album is transcription of album
- album is translation of album
- album is taken from album (which links singles to their albums)
- I don't think transcription really fits here. Translation covers one language to another language and transliteration covers one script to another script. --Nikki
And an important change: Discogs URLs being about releases and not albums should only be allowed linking to Release entities. Though moving them there is tricky...
I will now apply this model to several example cases so that you see what I mean.
Example 1: bonus disc
Apocalyptica's Cult is a good example for bonus discs. It was first released as one disc. Then later this disc was released again together with a bonus disc as "Special Edition". Though we only have two albums in the database: "Cult" and "Cult (bonus disc)" and it's not obvious what was released when with what.
So take a look at a picture of how this model would look like with the new schema.
Example 2: Box with named discs
The model looks quite obvious, eh? :)
Example 3: Box with unnamed discs
In the model the individual albums wouldn't have titles. Thus only showing them inside the box makes sense.
Example 4: Separate albums released again together
Bonus discs are not the only case where there is no clear disc number ordering in multi disc releases and though no box entity needed. Anathema first released The Crestfallen EP, then Serenades and then both together in one release but without disc numbering (as you can see on the covers).
See the model which also shows how the Discogs links are related to it being about releases and not albums.
Example 5: Transliteration
Different title listings, equal release & disc id. So why not share those both values? :) And Picard could - when doing a lookup for the disc id - use user preferences for language/script to select one title listing.
Example 6: Multiple releases
- EU: Normal Edition (1 CD), Deluxe Edition (1 SACD)
- US: Normal Edition (1 CD), Deluxe Edition (1 CD + 1 DVD)
where all the normal CDs would share the same disc id although they were released in different packagings and by different labels!
The model for that.
Both albums and releases are equally important. Thus they should be presented equally. The discography of an artist becomes a tricky thing with this.. Only list the albums? Let the user choose whether to display albums or releases? For releases this is complicated as they don't store the album title, so what to display? At least there have to be search interfaces for the code systems identifying releases. A discography only showing albums has to take into account to show albums in album groups and boxes. Also an album released outside a box has to be listed again eventually.
Each entity type needs its own view. Those views have to differ so that it is a clear cut for the user what she/he is looking at ("Oh so this is a release! Maybe I should look at the album!"). The view for releases list all detailed data and a list of all connected albums / boxes. The view for albums has a list of all connected releases (together with attached physical media) but only shows basic info about them.
For the tagger
This is the next mess :-/
The protocol will change non-backwards-compatible. The album identification process goes: first identify the album, then select a release (not to speak of boxes). The CD lookup will get just an album as result or an album and a release (or several releases - or even several albums like the transliterated version in the example).
Separating box title from album title is a good thing for correctness in the db but players not making much use of ID3 info and having weakness in separating different albums with identical names won't like that. So there needs to be a way to "flatten" the data again - like building the album title like the user prefers it. I'm thinking about some sort of TaggerScript which (after the identification process is done) does the job of the tagging process and provides easy means for the user to let his preferences influence the tagging data.
For style guidelines
This is what you will like!
- Drop DiscNumberStyle, eventually BoxSetNameStyle
- Create new style guidelines for the type attributes, for how to connect the entities (like don't use boxes for bonus disc releases) and for the allowed contents of the release title field.
After this is done for albums we can go one with artists and tracks.. AlbumGroup
s being meta entities for different versions of albums which make AR linking easier are just one thing. For tracks we can have songs as meta entities grouping all tracks being about the same abstract idea of a song / one (modified) recording of a song. See TrackGrouping for details.
That was it! Still here? hehe..
Shepard, hasn't this been superceeded by NGS? If so, should it still be, or should it be moved to Historical / removed? -- BrianSchweitzer 20:32, 20 August 2007 (UTC)
- This is NGS. -- LukasLalinsky 20:55, 20 August 2007 (UTC)
- That's what I meant by superceeded - was looking at it from the perspective of wiki intertwingling. (There's no mention of NGS here, nor linkage between the pages, so this then appeared to be historical (pre-NGS) discussion, not the actual NGS itself.) Was wondering if it and the related needed to be marked historical, or intertwingled into the NGS page(s). DeleteWhenCooked -- BrianSchweitzer 23:53, 20 August 2007 (UTC)