History:Next Generation Schema/Usage Case

From MusicBrainz Wiki

Usage Case for the Next Generation Schema "Nadelnder Bambus"

This page gives two usage cases for the NextGenerationSchema (as described in the ObjectModel). It helps to understand what NGS can do -- something which is not obvious just from looking at the graph of the ObjectModel. It came about in a thread on the UsersMailingList. in this post DonRedman replied to ChrisBrandsen (that's why it says "I" and "You").

Short Summary

I describe two usage cases of the NextGenerationSchema in detail (ripping a CD and tagging files) and try to show that NGS is able to do exactly what Chris wants MB to do. These examples make the very abstract ObjectModel more concrete and give explanations for some design decisions made on the last MB summit. Finally I explain why it is important to keep remasters apart.

The Mail

Chris, I think you are missing a point of what NGS can do. I believe that if you understand that aspect, you will not argue that fiercely against NGS. I might be wrong, in which case I really want to understand your criticism, because then I have misunderstood you.

IIUC you want to be able to tag an album against a standardized tracklist with standardized track titles and album titles. You want this data to be stored in MB in a practical and maintainable way.

NGS will allow you to do exactly that! I will show that for MP3s and for CDs.

Please take a look at the illustation on ObjectModel and follow along.

  • (A) Say you have a CD that you want to rip on your computer. You put it in your drive and rip it with a fantastical NGS-MB enabled Ripper called Jack. Jack the Ripper gets the DiscID and looks it up in MB. It finds a ObjectModel/TOCObject.

This toc links to a ObjectModel/MediumObject, which belongs to exacly one ObjectModel/ReleaseObject which belongs to exactly one ObjectModel/AlbumObject. Since you set your preferences to "use standardized titles", Jack's tagging engine will use the title of that ObjectModel/AlbumObject, not the title of the ObjectModel/ReleaseObject. Now to the tracks. the ObjectModel/MediumObject is nothing but the tracklisting which owns a list of ObjectModel/TrackObjects. Those tracks have titles (what is on the cover), but for each ObjectModel/TrackObject Jack will look for the (exactly one) ObjectModel/MasterObject that this track belongs to. It will use this ObjectModel/MasterObject's title and not the one from the ObjectModel/TrackObject.

So you get exactly what you want. You were not even bothered to look at all the different releases that are in NGS-MB. The only case in which you would have to choose, would be if there were different releases to the same TOC. But even in this case, Jack could perform all the steps above and only present you a choice if the resulting 'standardized' albums would differ.

  • (B) Say you bought a couple of files from an online music store. You want to tag them as 'standardized' as possible. You fire up Picard and feed it the files. Picard querries MB with a combined Text and PUID querry and gets set of ObjectModel/FingerprintObjects. Ideally there is one ObjectModel/MasterObject to each ObjectModel/FingerprintObject. Exceptions are real PUID collisions (which are yet unheard of), or entries which have not been 'standardized' enough, or wrong PUID-to-Master relationships ([*] we'll come back to this third point later).

Now Picard asks MB to find the ObjectModel/MediumObject which has the closest match to this set of ObjectModel/MasterObjects. This is a fuzzy search that goes via the ObjectModel/TrackObject entities. According to your preferences it will present you this match (and maybe some close alternatives) by using the 'stadardized' track and release titles from the corresponding ObjectModel/AlbumObject and ObjectModel/MasterObjects, which it got using the process described under (A); not from the corresponding ObjectModel/ReleaseObject and ObjectModel/TrackObjects.

Now suppose you are tagging against a *remaster*. In the worst case for you the titles of the ObjectModel/MasterObjects might reflect this. You could then select an option "standardize even more" and Picard would look up the titles of the corresponding ObjectModel/CompositionObject objects.

Again you got what you wanted with a minimum of hazzle. All the complicated structure between the ObjectModel/AlbumObject and the ObjectModel/MasterObject (or even ObjectModel/CompositionObject) is used by algorithms, but not by you.

  • (C) Did you note that I have left out the artist completely? This is because the relation between the ObjectModel/ArtistObject and the ObjectModel/Release ArtistObject is a bit more complicated. All relationships to the ObjectModel/ArtistObject have attributes (so technically speaking there need to be objects in between them in the graphic). These attributes specify how to compose a single artist for your tags from the multiple ObjectModel/ArtistObjects in the Database.

So, if you do not want your album attributed to "Bubb featuring the GREAT BlaBla" (as on the cover), Jack or Picard would issue another query to MB which would yield: ObjectModel/Release ArtistObject "Bubb featuring the GREAT BlaBla" has {primary} member ObjectModel/ArtistObject "Blubb" ObjectModel/Release ArtistObject "Bubb featuring the GREAT BlaBla" has {featuring} member ObjectModel/ArtistObject "Blabla" from which you can construct the tagging artist "Blubb (feat. Blabla)" using the default algorithm, or "Blubb" using a 'standardizing' algorithm.

Or in the vertical 'album' Bamboo: ObjectModel/AlbumObject "Zoink" is a {main} entry of the discography of "Blubb" ObjectModel/AlbumObject "Zoink" is a {secondary} entry of the discography of "Blabla" from which you can construct the tagging artist "Blubb (feat. Blabla)" using the default algorithm, or "Blubb" using a 'standardizing' algorithm.

Or in the horizontal 'song' bamboo: ObjectModel/CompositionObject "Zip zap zarap" was composed by ObjectModel/ArtistObject "Bertram Blubb" ObjectModel/RecordingObject "Zip zap zarap" has {guitar} {primarily} performed by ObjectModel/ArtistObject "Blubb" ObjectModel/RecordingObject "Zip zap zarap" has {vocals} {secondarily} performed by ObjectModel/ArtistObject "Blubb" ObjectModel/RecordingObject "Zip zap zarap" has {keyboards} {additionally} performed by ObjectModel/ArtistObject "Bert" from which you can construct the tagging artists "Blubb (feat. Blabla)" using the default "Popular Music" algorithm, or "Blubb" using a 'standardizing' "Popular Music" algorithm, or "Bertram Blubb" using the "Classical Music" algorithm.

Are you still with me?

It is our fault that we never provided such usage cases of Nadelnder Bambus after the summit. So it is no wonder that it was so abstract. My question is: Does this solve what you want MB to be good for?

I have not discussed the maintenance aspect at all, because this mail is already getting too long. The main thing to keep in mind here is that the UI will do the same queries between the vertical and horizontal bamboo all the time. Note that (a) this is the reason why the relations *have to* be 1:n. This makes them fast compared to n:m relations. (b) while the current UI presents you all relations in the current db schema, the UI for NGS will *use* these relations and present you with the aspect you want to see.

[*] Now back to the note above, and then I'll stop. Above I wrote: One pssible reason for there to be more than one ObjectModel/MasterObject to each ObjectModel/FingerprintObject are wrong PUID-to-Master relationships.

An example of such errors would be if the PUID of a remastered track would be related to the original ObjectModel/MasterObject instead of the ObjectModel/MasterObject representing the remaster. And as far as I remember that was the reason for the guideline we are discussing.

Of course currently the problem is not really visible and does not make a difference. But since PUIDs are no textual and easily verifiable data, these errors cannot be easily corrected. This is what I meant when I said that we are losing information. If you associate the master PUID and the remaster PUID to the same track (in the current schema). How will you ever be able to pull them apart again?

I realize that this is arguing with the future agains the present. On the one hand, identical Masters are a nuisance *now*. They clutter up the album listing. On the other hand, we also have PUIDs *now* and they are relatively unique. Merging tracks that *legitimately* have different PUIDs now, creates wrong information in the database that will be extremey hard to correct. MB has grown out of the shoes of *only* being a tagging resource. Entering wrong information just for tagging is the wrong way to go.

I hope that I could convince you that NGS will be an even better tagging ressource than what we have now, and much more. I know we have a problem now, and it is not only related to remasters but also to box sets etc. We need an album grouping object, and we need it soon. From a completely unreleated mail I got a hint that Keschte might have this on his radar. That gives some hope...