Discussions on Composition

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.

Been thinkin about the right way to handle place and dates of composition.

I think the creation of any work of art (including theater, film, visual art, whatever) should be considered a /project/project with the /music/composition being the /project/project_focus. This allows for multiple roles for collaborative works as well as start/end dates for each role and subsection. I would go as far to say that every major work of art should have a property that points to the project of it's creation.

I've been trying to figure out if a creative process deserves to be a child class of /project/project, but I can't think of a compelling reason.

Now, location isn't so much a property of a composition as it is a property of the composer (or author or sculptor) at the time of their participation in the /project/project. So map Liszt's travels in his own /person/person/places_lived cvt and then you can implicitly figure out where he was when he was involved in the /project/project focusing on each piece. This would require a more detailed places_lived field than most artists currently have, but I think that's a good thing.

Personally, I would think that the sequence number between parent and child would be best from as user point-of-view.

Would it be done by a CVT?

I'm happy to help in any way I can but don't have the knowledge or access.Is it something someone whom has the right access and knowledge might be able to do reasonably soon?

Simon

Crism : all I need to do is order the property values - although I can't be sure what order they will be added in.

How can I order the property values, then?

Simon

Ths only resevation wth that is that you can't see if anything is missing, as you can in a list of items labeled, e.g.:

1, 2, 4

Also, it would be fine for complete input directly into Freebase - but what about data fed by programatically?

For the record - MQL allows an index to be specified when loading into list.

See : http://www.freebase.com/docs/mql/ch05.html#writingsets

I don't recall exactly why the property is on Musical Track. I think part of the issue is that lyrics can vary from track to track, and not just in live performance -- Otis Redding's version of "(I Can't Get No) Satisfaction" has fewer verses than the Rolling Stones'; Kirsty MacColl's version of "A New England" has an extra verse from Billy Bragg's original; etc. But arguably the property doesn't make a whole lot of sense now, since the way weblinks work has been pretty heavily redone, and something like "lyrics website" could be handled using a category now.

(Random piece of trivia: apparently the reason that there are lyrics for the Star Trek theme is that Gene Roddenberry wrote them -- with no intention of their being sung on the show -- in order to secure 50% of the royalties for the theme.)

Great. I see it in the schema!

Is there something special about it?

I can't see in any views of composition, or in the list of composition properties, i can add to views.

Should I be able to populate a web-link through MQL?

{ "create": "unless_exists", "type": "/music/composition", "name": "Das Mädchen aus der Fremde", "lyrics_website": [{ "connect": "insert", "uri": "http://www.recmusic.org/lieder/get_text.html?TextId=14506" }] }

Gives a "Can't locate this clause - cannot continue" error. Maybe the MQL interface can't see the property?

Simon

Looks to me like you want one of "create": "unless_exists" or "connect": "insert", not both.

I tried to test this on sandbox, but got hit by FREEBASE-2006...

Also, I hope to add some other web-links for (e.g.) score. The "lyrics_website" links is a multiple property; oughtn't it to be more correctly called "web_links", as a link for be could be anything related to a composition. E,g, for 'Der Ring des Nibelungen':

scores: http://imslp.org/wiki/Das_Rheingold,_WWV_86A_%28Wagner,_Richard%29 http://imslp.org/wiki/Die_Walk%C3%BCre,_WWV_86B_%28Wagner,_Richard%29 http://imslp.org/wiki/Siegfried,_WWV_86C_%28Wagner,_Richard%29 http://imslp.org/wiki/G%C3%B6tterd%C3%A4mmerung,_WWV_86D_%28Wagner,_Richard%29

words: http://imslp.or/wiki/Der_Ring_des_Nibelungen,_WWV_86_%28Wagner,_Richard%29

art: http://www.artpassions.net/rackham/wagner_ring.html

analysis: http://www.trell.org/wagner/motifs.html

I, too, support adding date and place of first performance.

The properties are easily added and would be very useful for all types of music - not just western classical.

I think you've had some good starts on this previously, actually. A music catalog type, with properties for composer and composition, each of which linked to a Cataloged Composer and Cataloged Composition type, would do the trick, at least for catalogs.

Opus is interesting and presents two problems. The first is what type the property should go on. (A new type for "classical composition" maybe? Or perhaps the commons Composition type, even though a minority of instances will have any value for that property?) The next is how to model it: A simple integer won't do, since some works can have numbers like "Opus 76 No. 1".

Thanks - I'm back on the case with this and have made a new type 'cataloged composition' , to try out various approached as a prototype for the eventual real solution:

http://www.freebase.com/type/schema/user/simonhill/default_domain/cataloged_composition

I'm populating by hand with the various opus/catalog numbers cases.

My current thinking is that 'opus number' should be unique property of either 'composition' or a separate 'cataloged composition' type (as Freebase prefers, on account of its sparseness).

I am not aware of any piece that has more than 1 opus number easily disproved by example - anyone?) and, similarly believe opus numbers should be unique within a composer (other than 'ohne opus' (=without opus) ) .

A bit of validation on opus number (form {I have a good regexp for this) and uniqueness) and I think that one would be sorted. I'm happy to do it but what Freebase tools should I use to set up the validation?

Regards,

Simon

(Catalog numbers on compositions seem more complex but build on the 'opus solution' for form and uniqueness, so will be a later step).

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’s a good question, Joe. A particular recording of a traditional tune is likely a recording of an arrangement of the tune, true. But one might still want to discuss a folk song in its own right, and there is a difference between the lack of a composer assertion and the positive assertion that the tune is traditional.

I don’t know what the right answer is. Should there be a Boolean property for traditional compositions? Should we do what every other database does and create a pseudo-composer named Traditional?

Do you want to start a discussion on the Music Modeling Interest Group or possibly the data modeling mailing list? 

Welcome!

Unfortunately—as you probably know from using MusicBrainz and other databases—classical music is not generally well-modeled. We have it on our to-do list, but just plain haven’t gotten to it yet.

You can help us out, though! First, check out and join the Music Modeling Interest Group; start a conversation or three there.

Second, you can model the features you feel are missing in your own personal domain. Then post about them on the interest group or on the data modeling mailing list, and once there’s agreement, we can easily promote them to the music domain.

Thanks!