Discussions on Music

From the Musical Album Documentation:

"There should be no “various artists” pseudo-artist in Freebase; multi-artist compilations should simply have no value for this property."

Seeing as some of the Written Works properties will rarely if ever apply to lyrics, why not just delegate what properties are needed and useful to join Composition?

I'm against co-typing song lyrics as Written Works because that would make lyricists Authors, a type that would in turn get so diluted in Freebase to the point where Bernie Taupin may just outrank The Bard in terms of literary contribution!

Apparently not. ;)

Thanks, Chris.

I can see the appeal of it. But I do share Faye's concern that doing so would dilute the meaning of the already somewhat dilute Author type -- seeing songs listed among the various novels, plays, poems, essays, articles, PhD theses and whatnot will probably be confusing to some people. 

I can think of at least one practical issue with cotyping them: what to do with poems that have been turned into songs like Blakes "And did those feet in ancient time" which was used as the lyrics for the hymn Jerusalem by Hubert Parry.  Would Blake be the author of both the poem and the composition? That would seem weird, but merging the poem and composition also seems very strange, and wouldn't always work -- there have been multiple musical versions of Kipling's A Pict Song, for example.

Once again, the slippery nature of reality comes into stark conflict with Freebase’s objective model. The lyrics to a song really should be their own, discrete object, and could then be shared by multiple musical settings.

I also considered a new co-type as a compromise. However, one can argue that some musical works without lyrics per se still have language, as they may use words as musical components, and they can certainly have subjects without words. So I will just add these two properties to Composition and have done.

Re slippery nature of reality:  Too true. The same problem really pertains to screenplays (teleplays, radioplays), alas.

Re subjects: Subjects are going to be globally improved at some point in the nearish future, but I can simply reciprocate the link for now.

Re futility: Yipes! Sheet music makes the whole model very interesting. Maybe we need a type for sheet music (or scores, or whatever the best generic term is) that includes Written Work, and also links to the composition(s) involved.

That is a bit odd. The description explicitly says that a soundtrack is for either a film or tv show, but the property is only for film. It seems to me that the options are:

1. add a "TV show" property to soundtrack
2. create separate types for Film soundtrack and TV soundtrack
3. completely generalize the soundtrack type, and create a new type "Media with soundtrack" that will link to it (instead of Film)

Yup, 3, generic soundtrack with enumerated soundtrack types would be my favorite, or 1.

TV/Film/Game/Boardgame/Advertisements...

Well, my first question is, which music festival?

 Is the music festival actually a recurring event?  If so, it should be typed as such, and *not* as event.  The instances should be eg. "2009 music festival", "2008 music festival", "2007 music festival", etc.

Hi.

Just a few examples: 

http://www.freebase.com/view/en/wacken_open_air

http://www.freebase.com/view/en/rock_am_ring

http://www.freebase.com/view/en/wave_gotik_treffen

http://www.freebase.com/view/en/download_festival

and so on... 

The problem is that anything that is a "Musical Festival" automatically gets an "Event" too on creation. But I just read the "Lassie is an actor but *not* a Person" example in the help section. I think the same idea applies here... And I agree with you that the festival itself should not be an event and the (annual) instances should be one. 

Thomas,

Thanks for all the great work on music festivals.  I joined your Woodstock base and will add some data - unfortunately I'm not familiar with the German festivals, so I can't help as much there.

The automatic cotyping of all music festivals as event is based on the fact that many festivals are one-time events (e.g., Live Aid, Woodstock), but one can always remove inappropriate types.  If you'd like to clean up these (or other) topics, please select "remove type" from the "more options" drag-down menu under Event.

Thanks so much for your interest in Freebase, and please keep making good suggestions!
Mike

Hi Mike,

thanks for your help. 

As soon as I find the time I will clean the recurring festivals I am aware of and add the yearly instances where it is useful.

I think I will be a regular visitor and contributor to freebase. It's a pretty cool system. :D 

And thanks for joining my base. I'm just in the state of exploring the views' capabilities. Sure there is room for many more interesting lists and galleries.

Thomas 

i'm thrown by the event cotype too. over at Conferences and Conventions we distinguish between a conference event and a series with th schema, i dont see why that woldnt work here.

also, why not cotype Performance , Crowd event or something?

I'm in the camp that says if a type has no properties it should be typed  higher in the ontology.  maybe we should consider this.

Performance is outta whack too. i got some time tonight. i'm gonna try to outdo them

check out the fun base!!

everything you've always wanted!

Why does this type have to provide any properties? Wouldn't it be sufficient to use it as "boolean tag". Because for human editors it is pretty obvious when to apply this type.

I mean there are two possibilities: A single event that is a festival and a recurring event that is a festival (in that case the instances should not be "tagged" as festival). So retrieving the festival title and other related information would require a more complex query... But the festival type would "gracefully degrade" while still adding the information: Is this a so called festival or not?

But the included event type should be removed a.s.a.p. :D

Another value of having "Music Festival" is discoverability.  That's the way users think of these things.  Just now I was looking for "Arts Festival" or just "Festival" which don't appear to exist (although there are independent duplicate Festival types in both the Ottawa and Vancouver bases as well as a Ballet Festival). 

Using just Recurring Event seems like a very generic way of encoding these things.  I'd love to see Festivals more fully fleshed out.

wanna help out over here?

i'd personally like to see recurring event fleshed out. 'type of', and 'geographical scope' .

Hey, welcome back.

I guess I'm confused about what the disambiguation flag actually controls.  The help says "use this option when you want the property to appear along with the display name in a list."  What kinds of lists do disambiguators appear in?  What appears in the auto complete dialog?  Is it just the aliases?

The tracks I was looking at were those for Pearl Necklace.  Since they appear on a bunch of different compilation albums, I presume that at least some of them are the same recording, even though the lengths vary by a few thousandths of a second.  I'm not a big enough ZZ Top fan to care about sorting them out, but was more concerned with the general schema issue.

As an aside, is it right that Unfinished Sympathy is both a song and a track?  Shouldn't they be two different topics?

The main thing disambiguators do is create multiple columns for a property on the topic page (so, looking at a musical track, the property "Appears on" expects a musical album, and additionally displays the disambiguators Artist, Release Date, and Release Type). They're also used to determine which fields can be imported using the list importer, and probably some other things that I can't remember right now.

AFAIK, the name, aliases, types, description, and image appear in the autocomplete.  Adding disambiguators to it might be a good idea; I'll create a feature request for it.

Most tracks were imported from MusicBrainz, and were merged based on an analysis of their audio thumbprints, is my understanding. 

Pasting my response from the data-modeling maling list:

The performance role (which could perhaps have a better name) is used for connecting musicians to groups or recordings.

John Bohnam ---drums--> Led Zeppelin
Robert Plant ---lead vocals--> Led Zeppelin

The thing in the middle of the arrow is a performance role.  Performance roles can be musical instruments, vocal ranges, ensemble roles like orchestra, chorus, or string quintet, conducting, etc.

Suggestions for a better name for that role are welcome.

Is that clearer?

[end paste]

I also see, however, that part of your issue was driven by the use of Bass guitar as a performance role rather than Bassist. The primary reason for this is that MusicBrainz has an ontology of musical instruments that it uses to model group membership roles and recording contributions. If we are to harvest that information (which we don’t currently do) then keeping that correlation is necessary. Without a connection between instrument and person-who-plays-instrument, we won’t be able to map Bass guitar contributions to Bassist; it is easier just to keep the instruments themselves as the roles.

Many abums list contributions in terms of the person—guitarist, drummer, etc.—but just as many others list the instruments themselves—guitar,drums, etc. We should try to be consistent, but given that many instruments don’t have performer-role equivalents, and vocal ranges are referred to identically (I have never heard of a sopranoist), it seems easier to keep the role on the instrument.

Pasting part of my response to your response:

I took "musical performance role" as an implication that the instrument is a musician is because "Musical instrument" doesn't make sense as the "Musical performance role" of "Musical group membership". For example, Jimbo Wallace is the bassist (general) or double bassist (specific) of the group Reverend Horton Heat. He is an instrumentalist who plays the double bass as part of the group. The current schema jumps over the role (profession/hobby) to link straight to the instrument but calls the instrument the role. That means that the role needs to be inferred from the instrument. As I'm drilling deeper into the reasoning for this modeling approach it's starting to make sense (e.g., specificity of double bass instrument is preferred over the generality of bassist role). However, it was not intuitive and 77 instances of "Bassist" as a musical performance role added by a handful of users and mw_template_bot is supporting evidence. Perhaps changing the name of "Musical performance role" would be all that is needed but the new name should imply an instrument/activity topic rather than a role/profession/hobby. Besides changing the name of "Musical performance role", it might be useful to add "Musician" as an incompatible type of whatever name "Musical performance role" is given. An "Instrumentalist" type that links the instrument to the profession might also be helpful for finding the professions currently linked as "Musical performance roles" and correcting the data given the current schema.

[end paste]

An "Instrumentalist" type might also be useful as a converter when importing data that list contributions in terms of the person.

Er… when I go looking for linky things, sometimes sentence fragments.

Filtering the query… is not too difficult. There.

The link on Track was hidden and unused because we weren’t sure it really belonged on the track.

On sandbox, I have removed it from Musical Track and recreated it on Composition instead. Two recordings of the same composition ought to have the same lyrics; one could make a very good case that if the lyrics are different, then one is talking about a different arrangement of the composition, at the least.

However, most lyrics Web sites do index by recording artist, so maybe this doesn’t work. What do you think?

As for external keys: that is something that Freebase is particularly good at. You can make a LyricsWiki namespace (e.g. /user/metaeducation/lyricswiki) and add keys to artists and compositions within that namespace. You can also make a URI template that automatically generates Web links from those keys; take a look at how the IMDb links for actors are constructed.

and some more ideas:

to whom the composition was dedicated is often interesting.

who (person, or sometimes entity such as the san francisco opera) commisioned the work is also often interesting.

location, date, and performer of the premeir is also often interesting.

As with most good user suggestions, I will say: Go try it out!

The question of catalog keys is easiest. Go make /user/arielb/koechel, and create an enumerated property for a Mozart composition type. Other notable catalogs (Schickele) can be similarly modeled. Opus numbers could be a machine-readable string, but probably on a Classical composition type; other compositions do not tend to have those.

The key, dedication, commission, première, all seem like good properties for classical compositions as well.

The date and place of composition is an interesting challenge, an example of a frequent modeling challenge in Freebase. Representing this information complicates the model when done properly; one really wants the composer-composition relationship to be a CVT. However, most compositions don’t have this information readily available, making it an unnecessary composition. Would it be acceptable to have the date(s) and place of composition simply depending from the composition itself? That would mean, for example, that one could not correctly describe compositions begun by one composer and completed by another.

ok - i'll look into the catalog numbers seperately in a classical music domain once i get around to it.

i set up a user domain for dedications (Dedicated Work).  I think this could be generally useful (applied to literature and what not) and does not need to be directly tied to composition.

Place of composition should likely be non unique since there are numerous instances where the composer travelled while writing the piece.  I think for modeling place composed similar to places lived is sufficient.  Similarly, capturing a start and end date is also likely sufficient.  Modelling compositions begun by one composer and finished by others is basically just hard (see this example) and happens infrequently enough that i think if someone cared enough they could break out the variant completions into seperate compositions.  but for simplicity's sake, i think just having a date begun, date completed pair on the composition itself would help capture lots of useful data.

He has the Songwriter type, which as I said before is a shorthand for both Composer and Lyricist. Songwriter has no properties of its own.

He also has the Composer type with several “Works Composed” already entered. You can add to that list.

Good morning, Cris, did you see my 3 wonderful philosophers on the front page today??

Sure, I can do that, but it is not nice to have empty spaces on the page. Look at Cage, please, what is the use of the "Songwriter" "Lyricist" boxes if we cannot put anything in them? It simply does not look good. Cage wrote songs...

The Lyricist type has the property “Lyrics Written.”

Some types, like Songwriter, are only used to classify topics, and have no properties of their own. We generally try to avoid them, but Songwriter was added to the system early on.

As I said in our earlier discussion, the notion of which compositions are songs and which are not is too subjective to easily divide. Many people regard Cage as a cutting-edge composer, and would consider calling his compositions “songs” dismissive. Rather than provoke edit wars, it is simpler to regard all musical compositions equally in Freebase.

With over 3,000 songwriters in Freebase, I do not see the utility in removing it. And when someone is a songwriter, why not say so?

The UI could use some improvement for property-less types. That is not a good reason to remove a correct assertion, however.

Hey, this is fantastic! The truth is we need BOTH. There are composers who only write songs, for them is it good to have the "Songs composed" property.

Others write all sorts of things and for them we need the "Works composed."

One should have the choice between the two alternatives, use the one which is needed and let the other one obscured  

I did not mean to separate the songs from the works "within" the same composer! I wanted to keep Billy Joel and Schubert separately!!

"Songs composed" = Billy

"Works composed" = Schubert   

That's why we need both categories 

Alright, I see your point. So what do we have now?

Songwriter with Songs composed and

Composer with Works composed ?

If so, then everything is fine 

Hi crism...

 Oh my.  I'd found Musical Release but didn't go that far into "Release Event"...that's definitely pretty deep to have to go to put the catalog #.  :)

Part of the goal is to let obsessive fans get in there and do the work of completing the catalog.  But I'll have to get creative with the queries if it's this far away from "album"...

So if I'm going to be doing that: why is Artist on both Musical Album and Musical Release?  Should it be allowed to change?  If the artist is not the same, then wouldn't it have to be considered a new album?  (If I re-recorded Sgt. Peppers, it shouldn't be considered a release of that album, should it?)

The Release Event  is a compound value type; the label and catalog number show up as apparent properties of Musical Release. The exact structure is only an issue if using the API.

The artist can change on reissues. For example, there is a single Billy Joel-branded release of what is actually two albums by two bands that he was in before he started his solo career. Same exact recordings, but different packaging and crediting. You are right that a re-recording is a new album.

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.

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.

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.