History:Object Model / Album Group

Group of Objects Describing Albums

This group is part of the ObjectModel.

Since we have not identified the different objects that form this croup, Shepard proposed that we try to sum things upon one page first, and then create pages for each object (a bit like it happened on TrackGrouping).

So here is DonRedman's first go at this. It is written explicitly to be worked over by anyone who cares. The links are proposals only.

Hierarchy of Objects

Again as in TrackGrouping, let's start from the top:

Album Idea

There is an object that I would call an ../AlbumIdeaObject. When we say "Dark Side of the Moon" by Pink Floyd, we mean that idea. We do not mean a specific album.

Album

The specific ../AlbumObject is the next layer. But if we look at this in detail, it is pretty difficult to define it:

• An ../AlbumObject is "touchable" there is a box or sleeve that you can hold in your hand. We are, however, obviously not talking about one specific thing that you can hold in your hand. If you and I buy "Dark Side of the Moon" in the same record store, we have the same ../AlbumObject, although each of us has a different box in his hand.
• So at which point does an album become a different album? This largely depends on the way we define the layers below. for now we should note that this is problematic, has to be kept in mind, and we will have to come back to this issue later.

Actually you will see that we encounter many difficulties defining the album. Furthermore all the required grouping can proably be done with the ../AlbumIdeaObject, the ../ReleaseObject and the ../DiscObject. so we might scrap this object from the model alltogether. (this was suggested by LukasLalinsky.

Release

One layer below (beside, above, or even instead?) the album is the ../ReleaseObject. A release differs from an album, in that is has been released at a specific date in specific countires, by a specific label. In what does it differ from an album? Well, if the same album gets re-released, then we deal with the same album but a different release. The question here is again: What is "the same album"?

• If nothing changes except the EAN code, is it the same album? If we say no, thenthe definition is really simple.
• If the title stays the same, but the cover differs slightly, is it the same album?
• If the tracklisting or the actual audio changes (e.g. a remaster), it should be considered a different album.

So we retain: The boundary between the album and the release is pretty wobbly. Furthermore it seems to be difficult to descibe the relationships between a ../ReleaseObject and an ../AlbumObject, before we have defined the boundary of an album.

Disc

There is one object which we have forgotten in most previous attempts, which is however realy obvious if you look at things analytically: An ../AlbumObject has one ore more ../DiscObjects.

If we understand disc in a very broad sense, then this includes the sides of a record, or of a tape. The important thing here is that it is not the album that has a track listing, but the disc. A track is addressed like this: Album "Bitches Brew", disc 2, track 3. Or Album "Bitches Brew", Side C, track 1.

• Note that if the disc number is a property of the disc (and this really makes sense), then a ../DiscObject belongs to ecactly one ../AlbumObject.
• Furthermore, if we take into account the way we have defined the ../TrackObject, then the same logic applies to tracks. Therefore an ../DiscObject owns 1 to many ../TrackObjects and a ../TrackObject belongs to exactly one ../DiscObject. This is neat, because now we know where a TrackTitle like "What the F**k (album version)" belongs: It is a property of the ../TrackObject. This specific title only makes sense within the context of this disc (and this album). The general title of a "track" (in this case "What the F**k"), is not a property of the ../TrackObject, but of the ../MasterObject^[1]

This means that we have defined a disc object as a set. Using this approach, the disc is not necessarily something touchable. Since we have decided to be overly specific, we will define a disc as being the ordered set of specific tracks. This is a completely abstract and virtual object. The touchable thing comes below.

Note that the name of this object might be badly chosen. If we want to emphasize its abstract nature, we should probably call it ../TrackSetObject.

Medium

A ../MediumObject^[2] should describe a physical medium that you can hold in your hand. Let us ignore MP3 files for one minute and buld this up with the idea of a CD. then we can see if this is applicable to other formats of storing music.

If you and I both have a CD in our hand, how can we determine if we have the same medium, disc and album?

Medium

We insert our CD into our CD-ROM drive and let the PicardTagger calculate a DiscID. If it yields the same ID, then we have the same ../MediumObject, if it yields different ones, we have different media.

Disc

OK, now we have two different media, but they could be the same discs nonetheless. According to our present difinition of a ../DiscObject as a set that owns tracks we could now compare our tracklisting and the specific track titles. Furthermore a ../TrackObject is a pressing of exaclty one ../MasterObject, therfore we have to compare the track lengths and their audio fingerprint, too. If all of these are the same, then we declare our two CDs to be the same ../DiscObject.

Album

Now things get interesting, so let's give this a section of its own:

Defining the AlbumObject

We have now followed all layers down to the physical Medium. We still do not know how exactly to define the ../AlbumObject.

DonRedman says:

• Since I have lost track of all the different proposals in AlbumRework ReleaseTypeRestructuringProposal, ReleaseDataSet, and ReleaseRegionStyle, I am leaving this to Shepard. I am not even sure, that he agrees with the above distinctions. The only thing in the above I am definite about is the album--disc--track relationships. Grouping of identical ../TrackObjects should happen via the ../MasterObject, not below. Perhaps a similar model can be applied to albums? This would mean that the ../AlbumObject could be defined in a very restrictive way and all the grouping would happen via the ../AlbumIdeaObject. Finally I have to admit that I did not understand the relationship between the ../AlbumObject and the ../ReleaseObject. Different people seem to understand different things. Shepard, can you live with my naming and tentative definition of these objects? Can you enhance and expand this? Or is your concept drastically different? In that case it might be better you write an ../AlbumGroup2 and we compare them.

LukasLalinsky says:

• I still don't understand why do we need both album and Release, i think it's whole a bit over-engineered ... This is my point of view: album can have different releases, release can have many discs (or tapes, etc.) and that's all ... Album is something abstract, release is what i can buy and identify by label&catalog number

Fuchs adds:

• The need for different Album and Release objects has been rendered obsolete IMO. The summit results suggest a ../ReleaseObject below ../AlbumIdea which can have more than one ../ReleaseEventObject that represents the non-shared data of different instances of a ../ReleaseObject (meaning release dates, regions, barcodes etc.). ../ReleaseEventObject is not below nor above nor in any way part of the album chain, it's just attached to ../ReleaseObjects. Am I right?