I just noticed that "drum" is typed "Musical performance role" which seems to be a very confusing name. Shouldn't the type be "musical instrument"?
I just noticed that "drum" is typed "Musical performance role" which seems to be a very confusing name. Shouldn't the type be "musical instrument"?
Musical instrument includes Musical Performance Role, and drum is both. The reason for the co-typing is so that an artist in a band can have the roles of lead vocals and bass guitar, without having to have separate properties for each.
For mw's consideration:
I've created a type in my personal domain called "Musician" which includes types "Person" and "Musical Artist." This type requires that its topics be individual persons, but we can also provide greater detail about their personal identity. Individuals can also be tied to the instruments they play (a property I've also added). Let me know what you think.
This is interesting, Cedric, and it seems useful. The instrument played property is definitely more helpful here than on Musical Artist. What other properties did you have in mind?
I changed my mind… “Instruments Played” and “Vocal Range” are now properties of Musical Artist, reciprocated by the Musical instrument and Musical vocal types. I have migrated the few instances you had in Musician to these types. Thanks for the very useful suggestion.
It would be useful to have a type for music theory to identify definitions of music terminology, analytical methods, etc.
and shouldn't there be a "type" "Music," so that subparts, such as the music theory topic, can be related to the domain?
Thanks for the suggestion, Ron. Generally, a type is something that an instance can be, well, an instance of. So I think you’re onto something interesting here, but maybe not those specific types. What would it mean to be a Music? I think more specific types are in order; an analytical method would be a good example, as would things like the Musical scale and Musical chord which we already have.
I would suggest that you try prototyping types based on instances that seem to need them, to you, and see what properties they need. For example, on finding an analytical method, create a type, make the particular method an instance thereof, and see what properties are needed to flesh it out.
Thanks.
If you care about data in the music domain, please take a moment to look at it
on sandbox
.
The main change here is the new
Composition
type, which has
Composer
,
Lyricist,/i>, and
Recorded Versions
properties. A
Song
is now just a kind of
Composition
(by way of an included type).
A composition can include another composition—so a symphony might include its movements, a rock opera can include its songs, an operatic cycle can include its operas. These different semantically-meaningful types can be added as the data is fleshed out.
This would affect a couple of other domains, too; a musical would be both a
Play
and a
Composition
, with the composer and lyricist using the
Composition
properties, and with its songs being compositions themselves included in the larger work; similarly for operas. (I do realize that there is a connotative difference between a librettist and a lyricist, but that is more a matter of era than anything else; which does
Tommy
have?)
Another new type is
Arrangement
, which is, like
Song
, itself a
Composition
, but which is also an arrangement of some other composition. This allows us to distinguish between covers of Jimi Hendrix’s “All Along the Watchtower” and Bob Dylan’s.
I am posting this same message to the developers’ mailing list; please reply with comments here.
The changes described above have now been made on the main Freebase site. I couldn’t find any Freebase applications that used these properties, but please let us know if anything breaks.
One addition to these changes is that a
Composition
may be recorded as a
Musical Album
(
e.g.
, a symphony that shows up as multiple tracks on the album).
Should we be flagging multiple disc entires for merging?
Example: 2 topics currently exist as "Musical Album":
Grateful Dead / Steal Your Face (disc 1)
Grateful Dead / Steal Your Face (disc 2)
Now, in my mind, this is one album. It's initial release was 2 vinyl discs, but I think it should reside in one topic.
Opinions?
Currently, the discs should be kept separate. This is confusing, it’s true, but given the currently model of only Musical Album and Musical Release , it’s the best option. However, we will be incorporating the next-generation MusicBrainz model of having “packages” that may contain other packages, e.g. a two-disc release that contains two discs, each of which has a track list. The details of implementing that model in Freebase are still being worked out, however.
Chris, I saw the email about the proposed "Multipart Album", and to be honest, I think it's not the right approach at all. The whole "multipart" thing is actually a feature of a release, not of an album. Think about Springsteen's live album "1975-85". It was released as a 5-LP vinyl set, and also as a 3-CD set. Albums that were originally released as 2-LP sets were later released as single CDs. Or, to use an incredibly esoteric example, Joe Jackson's "I'm the Man" album was released as a single vinyl album, and also as a boxed set of 6 45rpm singles. Don't box yourself into the idea that the Music domain is only for creating CD discographies. That was MusicBrainz' mistake.
Thanks for the feedback. Don’t forget about the Musical Release type, though. In your Springsteen example, the 5-LP set would be a Multipart Album with five parts. The 3-CD set would be a Musical Release, a release of the 5-LP album. We most likely need a multipart release to correspond with Multipart Album for cases like this. Similarly, I’m the Man would be a Musical Album with a multipart release consisting of 6 parts. (FWIW, MusicBrainz isn’t locked into CDs, either; it’s just that most of their data comes from people putting things into their computers, which means almost entirely CDs. Their next-generation schema is going to be much more flexible on this point, and I’m trying to anticipate it here.)
OK—take a look at /music/package on sandbox and see what you think. It will take a little bit for me to populate some sample data, but the idea is that an album like The Wall would have a track list as well as packages (discs) that contain specific tracks. This can also model LP or cassette sides. The Joe Jackson album would have one release with 2 LP sides, and another release with 6 45s (or even 12 45 sides). This is much more analogous to the next-generation MusicBrainz approach as well.
For most single-disc CD albums, the packages could be implicit, or could be co-typed with the album, or made explicit separate topics, depending on how pedantic or thorough fans of the artist want to be.
An album is sometimes released with additional tracks later; we consider that a release of the album rather than a new album. So here’s an interesting question: when a particular song is released as a single in different variants (that is, with different other songs), are those different albums, or are they different releases of the same album?
As a concrete example, Jethro Tull’s song “Said She Was a Dancer,” from
Crest of a Knave
, was released as a 7" single with “Dogs in the Midwinter” as the B side, as a 7" single with “The Waking Edge” as the B side, as a cassingle with both songs, and as a 12" single with “Dogs in the Midwinter,” “Down at the End of Your Road,” and “Too Many Too.” Do we create a single album with three alternate releases, or four separate albums with different track lists?
I'd vote for alternate releases in cases like that, where they would all be considered "single" releases of "Said She Was a Dancer". In general, if a short-form release doesn't have its own title independent of the A-song being released, it goes in as one of the single releases of that song.
To facilitate this (and for other reasons), I would like to suggest that one of the attributes of the "Musical Release" object be Format, where the choices for format would be things like "12-inch vinyl, 33 1/3 rpm", "Compact Disc", "Cassette", "8-track tape", etc.
Other attributes that belong in Musical Release are Catalog Number and Mono/Stereo/Quad.
Just a formatting design suggestion for the descriptions of the Domain/Types.
The bolded 'Properties' and on this page 'Types' should have more clear line spaces above than below.
Ex.
the Music domain. Some such have been inappropriately imported where they were not tagged correctly in MusicBrainz; please report these or un-type them as Musical Albums or their performers or authors as Musical Artists.
Types
Musical Artists are bands or individuals who perform or record Musical Albums or Musical Tracks. An artist may be a Musical Group Member and have a Musical Group Membership connecting them to another Musical Artist.
Any thoughts about organizing and adding classical music-specific typing? Typically, the work or composition is used as a primary organizing principle rather than songs, tracks, albums etc. And song has a specific connotation in classical music versus its broader meaning in popular music. The songs listed for say, composer John Adams, are not songs in the technical sense.
Having said that, I don't know of a readily available data source that could be used to populate such a scheme. I suppose Wikipedia has lists of compositions by composer.
Lots of thoughts about this! Traditionally, the primary artist of a classical work is the composer, with the performer secondary, but this was necessitated by space on the spine of an LP or CD, and the necessity of a store shelving an album in a single place. Later, databases and music players only had an “artist” field to fill with a singular value.
Freebase definitely enables a much richer ontology, but getting it right will take a bit of thought. Please share any of your thoughts here or on the developers mailing list. We will also be getting together with some folks from MusicBrainz and other interested parties to grovel over the concepts of music representation within the next month, and you should see some interesting developments on Freebase resulting from that.
Need to also recognize that many classical works are really sets of works (movements), for example, a Concerto typically has three movements (fast, slow, fast). "Song" has always been problematic for almost anything except American popular/folk music.
I think it is necessary to think of multiple artists associated with a particular work, rather than a primary or secondary artist. The composer is the artist who produces the composition as a concept recorded on some medium, usually paper, the performer or performers realize that conception. Each performance is a different work, this is true in most music, but is the central point in classical music. So for example, to tie both comments together, think of a performance of "The Goldberg Variations" of J.S. Bach, versus the same work performed by Daniel Barenbohm. (very different) In some circumstances, we want to think of Bach as the primary and in others either Gould or Barenbohm.
There is no question that the current ontologies for music are seriously flawed.
Al, check out the Composition type, which can include or be part of another composition. Does this help? We can also get more detailed, making a concerto, a symphony, a sonata, all separate types, including Composition and having movements as their parts. There is also an Arrangement for distinguishing significantly different takes on the same composition.
This is very important to have "works" with subparts. I've spent some time editing Harry Partch compositions as a practice exercise and the works still show up on the homepage as "Songs composed" and the subparts list as independent works. In order for this to work accurately for this type of music, this categorization will definitely need to be fixed. It would also seem that some relationality would be useful, as well, since when doing this work I have to re-enter a lot of information for each piece, esp. the composer name, etc. Shouldn't the database be able to pull in this info for me?
Good point, Ron. This is directly analogous to the problem with albums and tracks; tracks aren’t directly credited if they are on an album entirely by the same artist. There’s a tension between redundant data and confusing lacunæ that we need to resolve.
It would be nice to have a way to be able to say “this property instance gets its apparent value from this other property instance by these rules, unless someone gives a (different) specific value.” However, the best way to say that—or even if there’s a good way to say that—is something we’re still figuring out.
In the meantime, I would suggest not giving composer information for sub-compositions (movements, etc.); even if we don’t figure out how to do inherited property values, it will be straightforward to automagically add composer information to all sub-compositions.
Is there any way to link to multiple topics under one heading? Like, if you had a "Venues Played" subtopic could it link to 'Public Arenas,' 'National Parks,' and 'Artist Tours,' or does each one have to have its own subtopic?
If by subtopics, you mean topics of different types, the answer is no. We looked at supporting that but it makes things pretty complicated. That said, you can type any topic with a type called 'Musical venue', so your instances of 'public arenas', 'national parks', etc... would simply have multiple types associated. For instance: Madison Square Garden might be a 'Sports Facility' but also a 'Musical Venue'. Make sense?