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?
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:
Thanks for getting this started.
Fans of particular artists or genres tend to care about minutiæ of recordings, including the date and place of a recording.
One way to model this in Freebase would be to have two new properties on Musical Track: “Place,” expecting Location, and “Date,” with a Date/Time value.
Another way to model it would be to attempt to reflect the underlying recording which is mastered into a track. Multiple takes on different days may be reflected in a final track, for instance. This also makes modeling sampling possible.
Thoughts?
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.
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.
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).
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.
This works for me.
How abstract is "track" now? That is, how often will there be tracks in freebase that are copies of a specific recording session?
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.
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?
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.
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.
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?
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.
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.
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.
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.
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. (-:
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.
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".
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?
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.
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.
When we first imported music data, we made some data modeling decisions based on not wanting to over-stress the database. These considerations are no longer relevant.
One of those decisions was that we don’t have a clean division between albums and releases. We identify a group of releases as all being of the same album; we then pick one of those releases and designate it as the album. The other releases are then releases of that album, but the primary release is implicit, bound up with the album itself.
I’d like to change this, making the album explicit and separate from the release. The way this would happen is that every album would be duplicated; the new entity would be a release, and would be marked as the first release of the album. The MusicBrainz identification code—which is really tied to the release, not the album—would be migrated to the newly-created release.
Any comments?
Chris -- do you have a strawman schema for this to look at?
This would use the existing album and release schemata; this is a data modeling change only in how they are used.
This sounds right to me, and it's consistent with the way jeff is thinking about the book data. I expect it applies to other kinds of data as well.
This is implemented on sandbox; go poke around any album there, and see how it would look.
I think this works. I think there are some redundant fields between album and release: "release date", "running time", and "label". On the album type, I think "initial release date" is a useful property, otherwise I think these belong on release.
More thoughts. I've put in some of the 7" single releases for Billy Bragg's "Greetings to the New Brunette" on sandbox (this link will self-destruct tonight!). It was released in three countries, with occasionally different B sides, which is apprehended well by this model. However, it leaves me with a question about what to put in the "compositions" property on "album" -- just the A-side? the A-side and all B-sides? the A-side and B-side of the first release?
The other issue I saw is that that producer is credited differently in different countries -- John Porter and Kenny Jones in the UK and W. Germany, just John Porter in Spain. Do we have any sense of how common this is, or is this just a fluke? (Chances are that the producers are the same and it was some contractual thing/label screw-up that caused Jones to be dropped on one release, but that's just speculation.)
Jeff, please see the new thread on single modeling.
Now, as for the other questions Jeff raises: the “Compositions” property of Musical Album are really intended to address compositions that span tracks and are complete, such as a symphony recorded as an album. In this case, I wouldn’t bother with the compositions on the album, just on the tracks themselves. As for different producers; I would try to find out who actually produced the album and credit it correctly. My guess here would be that the UK/German release included one track produced by Porter and one by Jones, while the Spanish one included two tracks produced by Porter, or that the A side was by Porter and the Spanish label ignored the B side. But in this case, I would go for the more inclusive credit at the album level. We may need a producer property on Musical Release, though, as this might well come up with bonus tracks on a re-release or a remastered release.