Music modelling

Music modelling: Conductor - Conducting

2008-09-23T21:10:42.0000Z

Let's do the simple stuff for now: Turn "Opera Conductor" into just "Conductor", and add a new property for "Ensembles Conducted" (or words to that effect), which would be a date-mediated property. We'll have to tackle performances at some point, but we should fix the stuff that's actually wrong now.

Music modelling: Conductor - Conducting

2008-09-19T16:55:40.0017Z

The other outstanding question in my mind is what should the properties of Musical Performance be, and how do we distinguish individual performances from series (a one-night concert vs. a weeks-long opera production)? Also, are we talking about a "Conducted Performance" type or a general performance type that can be used for all musical artists/groups -- the issue for The Beatles is relevant here, as well.

Music modelling: Conductor - Conducting

2008-09-19T05:33:25.0012Z

I think there are two properties appropriate here. One is a generalization of “Operas Conducted”: it should be called something like “Significant performances conducted.” This would capture the opera productions conducted (which is really what “Operas Conducted” is talking about) as well as other significant performances, like premières of symphonies and such. The other would be “Ensembles conducted,” and would point to the orchestras, jazz bands, choruses, etc., that the person had led. That would be a CVT with dates.

The outstanding question, to my mind then, is what is the expected type for “Ensembles conducted”?It would seem a bit weird to have a blank “Conductor” property waiting to be filled in on Nirvana, the Beatles, etc. Should we have an “Ensemble” or “Conducted ensemble” type with “Musical group” as an included type?

Music modelling: Conductor - Conducting

2008-09-19T02:56:05.0000Z

Let us start with a simple model at the beginning, so that we can go on with work on ANY conductor. We can have a Conductor type with the property Orchestras/Ensembles conducted (to include choruses, chamber music emsembles, etc.). Later we can develop other properties, when we get some good ideas. "When" and "How" conductors work sounds a bit like trivia to me, but we can list even that with moderation. Two-three important orchestras in the life of every conductor should be enough, don't you think?

Music modelling: Conductor - Conducting

2008-09-17T21:54:16.0024Z

Gordon, if I understand you correctly, you're proposing "Conductors" properties on Musical Group and Musical Track to link to the CVTs you're proposing? Since only a minority (even though it would definitely be a sizable minority) of groups/recordings could have a value for this property, it seems like overkill. I'd favor co-typing a Conductor type with Musical Artist to capture that information (assuming we determine that we need a Conductor type).

The question of performances conducted is another kettle of fish entirely; to my knowledge, we haven't attempted this (outside of opera, which only attempts to capture the conductor and singers) at all.

Music modelling: Conductor - Conducting

2008-09-17T19:10:57.0012Z

Definitely in the classical orchestral world, the conductor is probably one of the most important roles, sometimes overshadowing that of the composer (Leopold Stokowski is a classic example of a conductor who would alter/rearrange/adapt scores to suit the performance and/or ensemble). Stan Kenton and Nelson Riddle in the Jazz/Vocal Pop music world, they are just as important as the artists they worked with. In opera, orchestras, & small ensembles, the role of the conductor is usually pretty much the same.

So I vote for some sort CVT that captures something of the time spent with, performances conducted, recordings made with an ensemble of any size/nature

Music modelling: Conductor - Conducting

2008-09-17T18:46:07.0012Z

...then make them ALL conductors. The minute one takes the baton in the hand, one becomes a conductor, no matter what kind of ensemble/orchestra one leads, big or small. Certainly that there are opera conductors (Mutti, Levine) but that is only a speciality of the conductor. In essence, they are all conductors so we can get rid, at least, of this confusion...

Music modelling: Conductor - Conducting

2008-09-17T18:27:15.0017Z

[posted to the data-modeling mailing list]

When Jeff created the Opera domain, he created a Conductor type to represent the conductor of an operatic production.

When I created the Music domain, I treated conductor as a performance role within a group, no different than the third violinist.

Now we have a Conductor with only the Operas Conducted property, which makes it look weird when talking about orchestra conductors. We also have a Performance Role that various people hold within Musical Groups.

We should reconcile this one way or the other. Opinions about which way is preferable? Please make your responses in that Music Modeling Interest Group thread so that there will be an easily visible record for future Freebase users.

Music modelling: Conductor - Conducting

2008-09-16T06:32:32.0012Z

Cris, in music, after the composer who is THE most important person of all, the conductor comes next.He is a CONDUCTOR (like composer/singer/professor/etc. and NOT conducting, conducting is an activity. This is a big difference! You become a conductor yourself when conducting, and cannot define yourself as a member of some group, or conducting some people, and so on. There is a whole row of conductors out there starting with Felix Mendelssohn who would go up the wall if you would say that they are not conductors but conducting!! There is no difference between opera/jazzband/whatever conductors, they are ALL conductors so we do not need to take THAT into consideration, just develop one conductor type. We usually talk about "Opera conductors" because Opera and Ballet are such spectacular things with big audiences, major productions, etc., but practically there is no difference whatsoever between an opera conductor and other conductors.

Orchestra - Ensemble, call it as you wish, I personally think that the Berlin Philharmonic Orchestra or the New York Philharmonic Orchestra are ORCHESTRAS and not ensembles, but again, an ensemble is an orchestra no matter how big or small it is. This is not a question of size but what the thing IS!

Hence, we have now a conductor who conducts orchestras. He does that sometimes on a more permanent base and sometimes (as you say) as a guest conductor. I am no expert on modelling and cannot help you there but I strongly believe that we should not fill the database with trivia! So you can think now how to present this as a type. Put something on paper and please let me know before you put it in the computer. Let us discuss this by email, (Kirrily/Jeff/Dan and others have my address)...

Music modelling: Conductor - Conducting

2008-09-16T04:40:56.0012Z

I agree that this is information that it is good to model.

First, is the current model insufficient? For example, I’ve added Gustav Mahler as the conductor of the VPO (on sandbox) using the membership and rôle of the musical group. (Or, for that matter, see also myself with respect to the Brown University Band.) This would be my preference; I do not believe Conductor really needs a type of its own.

Second, if we do indeed need a Conductor type, what should its properties be? I would favor “Ensembles conducted” over a property for orchestras; there are significant wind ensembles, choruses, and marching bands that should not be orphaned.

Also, how do we model guest conductors? Looking at the VPO, I learned that they haven’t had a regular conductor since 1933, but they have had notable guest conductors throughout that time. Do we simply state that Maazel conducted the VPO at some point? Or should we model the dates?

Finally, note that musical recordings have the rôles of the participants modeled, so conductors can easily be described on particular recordings. Something similar could be done for live performances; in fact, this is what the Opera domain does, which is where this type originated. We could model significant live performances and the rôles played by different people in them.

What do you think about all this?

Music modelling: Classical works

2008-05-22T19:53:02.0007Z

This is an interesting start, simonhill.

The Opera domain was done as its own project; the Opera type should probably be refactored to include Composition (and similarly Opera Composer should include Composer.

Some technical notes on your types:

The catalog abbreviation and opus number should be text (or even machine-readable strings), not Topics; making D (the topic about the fourth letter of the English alphabet) the abbreviation for Schubert’s catalog is a bit strange, likewise for the number 1.
The expected types for other properties could also be adjusted; the “composer” property should expect Composer, “musicologist” should expect Person, or ideally, a new Musicologist type.
I would also have your composition include the Composition from the Music domain to make it easier to see what properties are already present and which need to be added. Is a discrete “title” really needed, in addition to the name of the topic?

Thanks for getting this started.

Music modelling: Classical works

2008-05-21T08:10:43.0005Z

I have a lot of classical music data (composers and their works, with opus numbers and catlog numbers etc.) which I'd be happy to load up.

However, I note that there are some issues around the schema in this area; e.g. there separate entities for composition and opera. (Surely, this can't be correct - an opera is a type of composition), there is no provision for opus numbers, catolog numbers etc.

Is anyone working in this area? Anyone have any recommendations for a good, practical way forward?

Music modelling: Date and place of recording tracks

2008-04-17T17:44:40.0007Z

definitely interesting data. i endorse the simple model. putting the onus on the developer to deduce some obvious questions seems reasonable:

Did trackA originate from the same session as trackB (by the same artist)? If the location is the same and the date is close (say to the month) then True

Seems easy enough.

Music modelling: Date and place of recording tracks

2008-04-17T06:11:03.0007Z

I understand now, Robert. That is kind of the crux of the question; we could be more pedantic and expicitly model masters and/or recording sessions which underlie tracks. That would be a more robust and thorough model, but it would also complicate actual use. Al’s opinion is that the track level is sufficient for now, and as he is more likely to use this than I am, I am inclined to go with that, as we can always garden out an implicit session from a track later on.

Music modelling: Date and place of recording tracks

2008-04-17T05:57:39.0007Z

I'm sorry. I asked my question badly. If you are attaching recording-session specific data to a track, would the track be the "definitive" version of that recording, or would there be other instances of tracks that represent that same recording? In other words, would people be able to find the session data if there are many representations of the recording?

Music modelling: Date and place of recording tracks

2008-04-16T01:00:32.0007Z

A Musical Track should be a bit of recorded sound expicitly instantiated somewhere, whether it’s in a file, on a disc, or on a tape. Some tracks will come from single recording sessions, others will be mixed from multiple sessions, and sample-based tracks might not ever have been really “recorded” at all, at least not by the credited artist.

Music modelling: Date and place of recording tracks

2008-04-15T23:45:19.0007Z

How abstract is "track" now? That is, how often will there be tracks in freebase that are copies of a specific recording session?

Music modelling: Release label, catalogue ID, and format

2008-04-15T23:43:02.0000Z

I believe your analysis is right, Jeff, and I agree that it is easier to keep the format, the physical medium, on the release event. It also harmonizes better with the MusicBrainz data. Now I just need to see if it makes anyone else cranky. (-:

Music modelling: Date and place of recording tracks

2008-04-15T21:09:43.0007Z

This works for me.

Music modelling: Release label, catalogue ID, and format

2008-04-15T21:08:36.0000Z

To get this straight:

If we put the format on "release event", a "musical album" would only have multiple "musical releases" if the releases had different tracks (either because they were remastered or because releases have different track listings).

If we put the release format on "musical release" instead, then the US, UK, and Japanese CD releases of an album would all be one "musical release", and the simultaneous US, UK, and Japanese LP releases (from the same respective labels) would be different "musical releases".

Is that right? If so, I think the first one is probably better -- the second one seems confusing to me.

Music modelling: Release label, catalogue ID, and format

2008-04-15T02:18:04.0000Z

And should the release format (78, 45, LP, EP, 8-track, cassette, cassingle, CD, CD-single) be on this release event CVT? That mimics the MusicBrainz model, but if that’s not what we want to do, we could put the format on the release itself and force multi-format releases to split.

Music modelling: Date and place of recording tracks

2008-04-15T02:15:02.0000Z

I have modeled these on sandbox. I hedged; the two properties do not use a CVT and have singular names, but they are non-unique. If there is significant user confusion or demand for more complex models, we can always promote the existing values to use a CVT.

Music modelling: Release label, catalogue ID, and format

2008-04-15T01:18:22.0007Z

I have modeled a release event on sandbox. I’m not keen on the name—I picked it for the release rather than the label/catalog association—but please let me know if you like the model and/or if you have a better suggestion for the name.

Music modelling: Date and place of recording tracks

2008-04-15T00:37:11.0000Z

This sounds like fun data to me. Good cocktail party discussion. How about using "Place of recording" because this might differ from where it was engineered or mastered. The location property could be added as a CVT with date and permitted to hold multiple entries for instances when multiple takes are included on a single track (an option that probably won't be used that much).

Music modelling: Date and place of recording tracks

2008-04-14T19:33:20.0007Z

I think date and location are good properties for tracks in general; I don't have a strong opinion about the depth of the model, though.

Music modelling: Date and place of recording tracks

2008-04-14T18:48:16.0000Z

Getting finer grained than track seems like overkill. I'd be happy with Place and Date on Track. How about on Album too? Most albums are recorded in the same place, and most live albums are recorded at the same time.

Music modelling: Track contributions

2008-04-14T18:43:29.0007Z

Very nice. You may want to remove /common/topic as an included type.

Music modelling: Track contributions

2008-04-14T18:14:06.0007Z

I like it.

Music modelling: Release label, catalogue ID, and format

2008-04-14T18:11:26.0000Z

The current model doesn't currently support the MusicBrainz's model, either, since we don't correllate release date to label. I had assumed that each label/date/format combination constituted a different "musical release" already. Obviously, a CVT would simplify this somewhat, if we wanted to assert that a "musical release" only implied that the tracks were the same, regardless of when/where/how/by whom it was released.

The one possible issus I see with this would be the "credited as" property, which would most likely differ on foreign releases. But I don't have any good ideas about dealing with the MB IDs.

Music modelling: Release label, catalogue ID, and format

2008-04-12T04:10:02.0012Z

Right now, a release is linked with its label (or labels). However, the catalogue number and format is not given.

If we add this information, it will mean a new compound value type, since the catalogue number has to be associated with the label and format. See MusicBrainz’s record for Sgt. Pepper’s Lonely Hearts Club Band for an example of how this would be modeled.

Is this too complex? Should a so-called “release” with multiple formats be forced to split into multiple releases? If so, what happens to the MusicBrainz-correlating IDs, since MusicBrainz is not so careful?

Music modelling: Track contributions

2008-04-12T04:05:36.0012Z

Right now, one can model contributions by an artist who isn’t the primary recording artist on the album level, but there is no way to capture equivalent information at the track level. I have modeled a proposal on sandbox; please check it out and comment in this thread.

Music modelling: Changing the name of the Musical Artist "Songs" property

2008-04-12T04:02:19.0007Z

This is done; “Tracks Recorded.” I don’t like “Other tracks” since it can be used just fine for tracks on albums by that artist. However, the key has remained unchanged lo these many years, so this is negotiable.

Music modelling: Changing the name of the Musical Artist "Songs" property

2008-03-07T23:04:07.0012Z

The "Songs" property on Musical Artist is confusing as it points to tracks (not songs) and it doesn't include all tracks an artist has made. In most cases, this property only includes tracks on compilations. At some point, it may contain all tracks, but for now this is confusing.

I suggest we rename this to "Other tracks".

Music modelling: Composition: Uses Melody From and Uses Chord Changes From

2008-03-07T03:57:57.0012Z

It’s been proposed, and experimented with briefly, to add two new pairs of properties to Composition: “Uses Melody From”/“Melody Used By” and “Uses Chord Changes From”/“Chord Changes Used By.” Trivial examples are “The Star-Spangled Banner” uses the melody from “The Anacreontick Song,” and half of the jazz tunes in the world use chord changes from “I Got Rhythm.” Thoughts on either the structure or the property names?

Music modelling: Pseudonyms going away

2008-03-07T03:53:52.0007Z

This happened. One interesting side-effect is that many artists are currently named by their legal names instead of their better-known performance names. If you run across, them, please do change them. We will be running a gardening sweep later to attempt to determine their best-known names (based on the Creative Work credits), but some human input certainly wouldn’t hurt.

Music modelling: Pseudonyms going away

2008-01-28T21:57:06.0012Z

As posted on the data modeling mailing list, the Pseudonym type is going away. A new type, Creative Work, is being used to capture the literal credit on Musical Releases, but the artist relationship will connect to the actual artist, regardless of name.

Music modelling: MusicBrainz data updated

2007-12-20T21:15:29.0005Z

Artist, album, and release information has been updated from MusicBrainz. It’s not detailed yet, but the objects should all be there, labeled and connected correctly. See any problems? Let me know, please!

Music modelling: Albums vs. Releases

2007-11-30T01:16:48.0007Z

This operation is done. Every album for which we have any release information from MusicBrainz should now have at least one explicit release.

Music modelling: Albums vs. Releases

2007-11-28T23:44:59.0043Z

I am not sure I am completely following all the abstract jargon here, being elbows-deep in concrete instances. (-: This process is running on the production system right now, and will complete tonight. What it means is that (effectively) every album will have at least one release. Each album will have a set of tracks; those tracks will be the same as the track listing for the first known release.

As for abstract tracks, this is what the notion of Song and Composition are intended to address. MusicBrainz’ next-generation schema will have a notion of mix, recording, arrangement, and composition, for users that want to get to that level of detail, but I think that (for now, at least) that is beyond the scope of Freebase. I could be persuaded otherwise, but part of that persuasion would have to be a large cadre of users prepared to enter that data manually, as it’s not readily available anywhere that I’m aware of.

Music modelling: Albums vs. Releases

2007-11-26T18:53:23.0007Z

I would definitely prefer that same level of abstraction on the track level.

The only reason why I hesitate at the idea of a definitive release, as its much more likely that "releases" will be added to a group of tracks than another track will be added to a release. Wouldn't it make more sense to populate albums based on the tracks, or "recorded works" and not the other way around? A definitive "recording body" ? Releases tend not to share much meta-data with the first album other than information that really could come from the track meta-data anyway. They often have different mastering engineers, release dates, formats, and sometimes even labels.

For one manifestation to be denormalized as a convenience, it should conveniently have meta-data that we are most likely going to use. Since its the track meta-data that tends to re-appear and not the details of any one initial release, it seems to me it's worth bringing track information up for convenience instead of repeating album meta-data.

Music modelling: Albums vs. Releases

2007-11-24T19:58:16.0007Z

Adam -- Chris is picking a release that might be considered as the "definitive" release and denormalizing the tracks and other data to the properties on the Album. This is done as a convenience to someone writing an application who's not interested in sifting through the various releases to find a track listing when building a simple application.

To clarify: The new Album type is a collection of manifestations, where one manifestation is denormalized as a convenience. Even though this information suggests that it's a particular release, the Album should still be used in an abstract way. If you want to attach the Album to a DVD, you can.

I'm beginning to wonder, however, if instead of tracks, an Album should point to "recorded works", which are abstract in the same way.

Music modelling: Albums vs. Releases

2007-11-19T23:44:56.0007Z

I guess what I'm getting at is why must we associate the "meta-album" with a physical album? I would think that all meta-information should be tied to releases of cd's but have the "album" be just a node. I say this because then DVD's about the album could also be tied to this node, as well as the artist- without having to incorrectly state that a particular actual release is the official manifestation of the recorded experience.

For looking up information about a track, if you have a live album, and there is DVD of that recording in video form, shouldn't we be able to find that connection through Freebase? Wouldn't that connection be easier if "album" was a collection of manifestations, instead of having an official manifestation with many releases related to it? What is gained by associating a recorded experience with an official version of it, especially if that experience may not live completely in the auditory domain?

Music modelling: Albums vs. Releases

2007-11-19T02:26:24.0007Z

Adam, this is, as Robert suggests, where we’re headed. The missing use case is the one where I slap a piece of plastic into my computer’s drive and want to look it up, or I have an audio file that I ripped a long time ago or which I bought on-line, and which I want to look up. (I am not proposing that Freebase should be the lookup service, but having found an identifier from MusicBrainz, how much information can I then glean from Freebase?) In that case, I need a database of separate, distinct tracks and releases. Now, we could aggregate all the relevant MusicBrainz identifiers onto the relevant albums, but I would like to know whether this is the shorter American mix or the longer UK mix, or whether it’s the lousy initial CD release or the gold-remastered high-quality later release.

As far as track identity, which you touch on, the idea is that truly identical tracks—such as if the single version is the exact same mix as the album—then the track should really be a single entity in Freebase. But if it’s been remastered (dance mix, short version, etc.) then it should be a different track. It should, however, be the same composition; I look forward to the point where we can get that rich information.

Music modelling: Albums vs. Releases

2007-11-16T03:26:39.0000Z

I'm a bit confused. Isn't what you're proposing pretty much the same as what Chris was proposing? That there is a more abstract "album" that would contain the human-friendly meta-information and that there would be aggregations of releases that were very similar?

Music modelling: Albums vs. Releases

2007-11-15T00:42:28.0007Z

I really do wonder about this album modeling issue. I understand why you went with it to begin with, but I think there is a simpler way to model this.

If you consider each album as a collection of track recordings, you can bypass all the complexities of releases and different versions. When you consider the use case, most people want to associate ties between listening experiences. That experience is dictated by the recording, not the metadata associated with the album.

singles can be tied to relevant tracks
7inch singles are versions of 7 tracks
12 inch singles are versions of the same 7 tracks
Promo releases of an album, that were released, then recalled, then re-released under a different mastering engineer, are still the same 7 tracks.

This would allow one to infer a "meta-album" between multiple releases. If you have 6 different releases, but the tracks are exactly the same, you can infer that this collection is one consistent "album" regardless of how many forms it has. To work backwards from the album adds a lot of complexity.

If a promo release has different tracks than the "official" release, why are they grouped together? In a purchase decision, these are separate products, even if they have similar components.

To solve the cluttered discography issue, you can set a view for simliarity. If more than 70% of the tracks are simliar, view as one meta-release.

I only suggest this because why would someone want to find their way back to the album through the tracks, if the tracks do not contain any of the "fun" information?

Music modelling: Albums vs. Releases

2007-11-13T19:54:47.0007Z

I think you definitely want "running time" on the release. As to whether it should be on the album as well, I'm a little torn. I agree with Chris that it's potentially useful to have it attached to the album, but given that the model is moving in the direction of more abstraction at the album level, it may not make sense to have it there.

I think this is one of those cases where inherited properties ("transitive properties"? what were we calling them?) would be handy, e.g. "the running time of a release is the running time of the album unless a value exists for the release"

Music modelling: Albums vs. Releases

2007-11-13T18:06:38.0007Z

Re producers: one possibility would be to model producer at the track level, which would eliminate the ambiguity (but which is also much harder information to come by).