@rob - sorry for writing a book.
IMO, this project, if it were to succeed, will require some good attention, so I would suggest we start real basic. Given a release, that I a consumer of music purchase, that attributes are important, and not only that, but why are they important. This can help develop relationships within the data. I think MB is quite good at physical media, but it is worth looking to see if maybe something could be tweaked or other. Digital releases are a true nightmare to attempt to catalog combined, meaning that we do not simply duplicate each stores separate catalogs as separate. Looking at those releases, I think we can start common:
- Artist for release
- Title of release
- The release event (as MB terms it)
- The core songs included + extras – meaning that the core is the common portion (if it applies) to all and the extra are bonus tracks or extra tracks that make them deluxe. The order is of no matter, just the content in common as sometimes deluxe does not order the core in the same as the standard.
Identification I believe is where the release object needs to be a child of release events by store. We can have a release (made of artist, tracks, title, ec) released by any number of stores, but the release itself on a descriptive level is the same. Once we have a child object, would can be applied to a release of all types and mediums (CD, digital, etc), we then define the specifics of the release, which for digital, is commonly the store’s release. I see it as similar to the BMG releases where the barcode is/was replaced by the BMG number, thus making it a different release, but the same in most all other ways.
So I might have a release object created, then go here to the parents:
1a. iTunes release ID
1b. iTunes store ID
2b. Store ID
We can then include on those parent release objects the details of the release like the bitrate, sample rate, container or anything else that described what that store released under its ID. When adding those attributes, I believe it wise to have the option (set true by default) to apply it to all recordings or not. This will normally be the case, but sometimes a release is not that way. There might be things like bonus tracks, videos, etc that have different attributes than the rest of the bunch.
Trying to keep this short (not really working), the same concepts apply for recordings. Forgive my likely misuse of terms as per MB, but follow the idea. We start with a work. We then get a performance of that work which is performed by a group of artists. We then use that performance as a recording to apply to releases, and when this is done, the ISRC is applied to the proper ISRC used for that recording on that release (This was the idea mentioned prior). So on and so on…
That is by no means a full plan for anything, just starting the idea. I also keep in mind complexity. As it stands, editors in MB do a lot of things wrong, and I mean that without judgment. When I first made edits they were a mess. Compare them to now (after many auto editors knocked me around :)), they are better. But still, my edits are not as complete as they could be, and still I am sure there are mistakes made, sometimes inadvertent and sometimes out of ignorance I am actually making a mistake. I also look at databases like Wikipedia and I am amazed at how much editor time is spent reversing other editor’s edits. That is why I think a more object orientated approach could be better. If someone wants to just add a list of recordings, they can do so. I can add release A, from artist B, containing these 10 recordings. I need not specify more, someone else can always create parents from it to show the attributes of the specific release.
Then you could have a set of moderation, which I believe is loosely there right now. You could have editors that watch for releases added with no parents and add one or many, etc. and even have editors that watch specifically for things like store releases to glance over the data entered. There is one auto editor who comes to mind for me that does/did this with release labels. I would have a good feeling knowing that an editor like that was watching over edits being made including my own. This means not that one verifies each and every thing, just that the obvious is looked for and all gets an even random once over.
The last item I wanted to add before completing the novel is references. References are an important part of a release and a very difficult one at that. Is Discogs a valid reference, is Wikipedia a valid reference, etc? Well it all depends on what their reference is. I could literally go to Discogs and say that Drake’s real name is mine, then go to MB and use that reference to say the same. Also, I believe that references should have the ability to be applied to specific aspects. For example, I might use a digital reference for a CD release. Example of this might be to list performers. I then mark this as a reference for performers, thus others can ignore that it is the wrong release medium. References are sometimes hard to find, but I think that all references (assuming we speak of valid ones) are valid.
EDIT: I failed to address the making sure credits are applied appropriately. With the creation of the more detailed objects, MB can quickly show what artists, performers, engineers, studios, etc are involved in what. This can apply from the work, the recording, etc all the way to the store it was sold on.