I was adding to Human Extinction as subject for films and some literature/poems
I would like to add the few tv programs that deal with such a cheerful subject matter like Life After People.
(Or maybe we should just have a media commons type for subject matter of a show or series in TV as well as for songs/compositions. Or just add subject to all the arts that are missing subjects)
Oh, yes, this should be posted as a suggestion in Media Commons as well.
Yeah, Jeff and I were talking about this just the other day. There is a proliferation of "X subject" types out there: book subject, film subject, video game subject, visual art subject, etc. I don't know whether we can combine them all or whether we want to or what, but it seems worth thinking about.
I definitly vote for merging all media into a generic media commons property, or at least merge the types for Art Subject, Film Subject, Written Work Subject into a single Media Subject type and still keep the properties for Film Subject, Art Subject, Book Subject for the Film, Artwork and Written Work types.
Merging all the "subject" types into one giant "subject" type, with properties for each expected type would probably work. (If we kept all the old keys around, the change might even be transparent to API users.) One caveat is that non-commons types expecting a subject would still need Foo Subject types if they wanted the properties to be reciprocated; these types would then have to be merged with Media Subject, rather than simply moved to a new domain, if they were promoted.
Did we ever really resolve this?
It's still just a thought, a good one I think.
I'd like to get some more opinions on this, since there are several type structures with a similar pattern (genres being the main one), so I'm going to ask the data-modelers' list.
Hi.
If there is a certain "Music Festival" that is a "Recurring event" (what is fine according to the description), then would it be useful to fill in the "Instance of recurring event" property of the "Event" type to be a self reference?
I understand that there could (or should?) be entries for each single festival (1st, 2nd,... or maybe with the year in the title) as "Event" and that they direct to the general main "Recurring event".
But since this is a Festival too, it has also the Event-Type. Should (or can) this type be removed from the main festival Entry without breaking any integrity?
I hope this makes all any sense.. .:D
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.
I agree; this type is being used for two different things, which is both confusing and not very useful. There are types for concerts and concert tours that should be moved to the music commons Real Soon Now that might need to integrate with this in some way, too. They seem to be in a draft domain so I can't link to them at the moment.
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!
this type should be deleted. it is responsible for creating a big mess with event/recurring event.
At the very least, Event should be removed as an included type. But unless anyone else has suggestions for properties of "Music Festival" that aren't already covered by Event, Recurring Event, Concert, or Concert Tour, I'd tend to agree that we could delete it.
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
I've removed "event" as an included type. I don't have a strong feeling about this type, one way or another (I've gone back and forth in my mind a couple tiems since my last post). I do see efi's point that there is some value in being able tell whether something is a "festival" as opposed to other type of concert.
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' .
hello, me and hostilefork are working on importing a large amount of music video information, can you reciprocate the music video property?
cheers
Great idea for a type! We don't typically reciprocate non-commons types from commons types, but I think a Music Video type would be a great candidate for eventual promotion. If you want a reciprocal link in the meantime, you can always create a new "Song" type in your base that would include the commons "composition" (or "song") type.
Is a track unique to the album that it appears on (as the description seems to imply) or can it appear on multiple albums as long as it is the same recording (as implied by the fact that the schema doesn't have the album property marked as unique)?
I originally was going to suggest that musical album be made a disambiguator, but it might depend on the answer to the above question. Either way, additional disambiguation information is needed to be able to pick out popular tracks from a list. since they generally have no description, so all you see is the name and the type, which is the same for all of them.
A track can appear on multiple albums if it's the same recording (see Unfinished Sympathy). Recording artist is currently a disambiguator, which should help some. There are lots of non-unique disambiguators kicking around the schemata, so adding album would certainly be possible. But if you're talking about finding them in the autocomplete menu, adding disambiguators won't help -- they don't appear in the autocomplete flyout.
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.
Song vs. track: generally speaking, I believe so. But the Musical Track Documentation also mentions that "if this is the definitive or only recording of a song, it isn’t necessary to create a separate topic for the song", so I believe that some tracks and songs have the same topic.Aforementioned request is CLI-7869
Why is the Brand field linked to a company? I find this confusing.
I would think that the guitar Type would follow the following: there's a specific guitar (Eddie Van Halen's original red/white guitar), guitar make/model (Ibanez JEM777), guitar brand (Ibanez or Ibanez JEM..not sure how far to go with these), then manufacturer (Hoshino Gakki makes Ibanez guitars).
I'm not an expert, so not sure where make/model/brand lines are drawn (let alone color like Ibanez JEM777LNG), but I know enough about guitars to know there's a difference between the brand like Ibanez and the company that owns the brand (who also owns Tama Drums).
Looking at Little Earthquakes both on Wikipedia and on MusicBrainz, I see that different producers and engineers were used for different recording sessions. I would like to add producer and engineer properties to Musical Track; any objection?
Hi.
I think it would be great to have some properties for "Music Festival".
I suggest a list of "Musical Artists" called "Line-Up". In most cases it's not important who played when on which stage/location, so an intermediate type "Festival Occurence" or sth. would be possible but not too useful. But a list of performers would be cool.
Some Festivals also have "Headliners" - The bands whose logos are mostly shown separately on flyers while the others are just listed. But I fear that this would be a too controversial property, because the definition is too vague. And it could in most vases be covered by filtering the most popular (however this is expressed) artists from the line-up. Also it would be necessary to make clear whether headliners are to be inclided or excluded in the "line-up". (I'd say they have to be included...)
Since artists and their albums can be tagged with genres, it would also be cool to have a "Main Genre(s)" property. But again, this could somehow be found out by querying the line-up.
Some other thoughts are to include some boolean properties, if the entry is a "free" festival such as the "Altamont Speedway Festival" or for example if a festival is organized for Charity (or maybe for which group or organization). But I'm not sure how often these properties would be used.
So much for my suggestions. They are pretty raw thoughts at the oment, so please discuss them with me.
Thanks for reading.
Thomas
Would a "subjects" property be useful or interesting? I'm thinking partly of all the location-based bases being created, so that they could easily include songs about Halifax, songs about New York, and for that matter, songs about rainbows.
Hi, I created a list of the worlds best-selling musical artists on Sandbox
Do you think this list would be useful? Should I move it to www.freebase.com?
Hey everybody,
I'm undertaking a base-building experiement with sanfranciscoscene.freebase.com. It's intended as a companion to my SFScene blog where I write about the San Francisco dance music scene, focusing on underground/techno events and the people who participate in them. What I want to do is set up a base of factual information, and then have links in from topics to reviews and other information that's on SFScene.blogspot.com. I originally got interested in writing the blog because there wasn't any real chronicle of what's going on in this scene, and putting info in Freebase is a way of capturing factual, historical information that may be of some interest later.
There are four main types of information I'm trying to capture, in roughly expanding order: DJs, DJ collectives, Events, and Event Locations. Some of the data modeling is a little tricky, because I want to capure, for example, locations that are businesses (like The Endup), and those that are "underground." I also want to have one event category, but have it be flexible enough to include recurring club events and one-offs.
I've started filling in some information just to see how well the models work, and so far I think it's pretty good, but I wanted to see if any of you all had further ideas/suggestions. In the new year I'll publicize it on the blog and see if I can get a data mob going to fill in more of the details (I know that many of the people I write about read the blog, and if I tell them there's a place where they can go enter information that will help publicize what they're doing, I'm sure they'll want to contribute). So have a look let me know what you think.
Title says it all. A musician plays an instrument, s/he is not that instrument. Musical instrument could have a musical performance property that links to a person/group/role type but having "Musical performance role" as an included type of "Musical instrument" doesn't make sense. The people are performers, not the instrument.
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.
Would it be interesting to have a property that captures what the name of group was inspired by/based upon?
I know user Skud has a named type, but it seems quite interesting relationship for musical groups. It's a common question brought up in many an interview article and lists within entertainment sites. Small example: Bands named after places.
I would rather just promote Kirrily’s type to the commons. Filtering the query for instances of Musical Group that are also Namesakes, and checking that their Name sources are also Locations, or instances of People that have the profession of Agrarian.
Er… when I go looking for linky things, sometimes sentence fragments.
Filtering the query… is not too difficult. There.
He is not a musical artist and did not make albums or record tracks :P Those should be move elsewhere (to their performers, ideally)
This is a pervasive problem with composers. Classical albums are typically credited to their composers, not their performers, and so when we import music databases, we inherit that problem. A project to clean that up is in the works, but is probably some time off.
Ah, that makes sense. I'd be willing to help with such a project if it was open to the public.
Hello... I am trying to implement a system by which the lyrics for a song are downloaded from LyricsWiki via their API. It would help if the lyrics web link were not suppressed in the schema. That way, the assocation could be made from within Freebase. As it is, I must maintain a separate table mapping Freebase IDs (artists, songs) to the names given by LyricsWiki, and that's not fun!
So would it be possible to expose this field? I know that there is probably some contention in terms of which website be the "official" lyrics link, but if multiple links were allowed I would merely pick out the LyricsWiki link from that set...
Tx...
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.
So a very popular trend in music in the past decade has been artists reworking pop/rock standards (like Paul Anka's swinging big band version of Smells Like Teen Spirit) as cover songs (tributes).
I would love to capture the relationship between source and covered version (sort of like adaptation in the media commons (should it be part of that type? Though I'd like to have a property that characterized the type of cover this is: identical?, revised, radical, language (english version of a foriegn language version), etc.
I guess another related property to consider would could be sampled song for samples as used in dance, rap/hip hop, mashups.
I hadn't seen Chris's post when I wrote my last one. I wonder if it's possible, though, with the current composition/arrangement types, to assert "cover-songness". A cover song, I as understand the term, is necessarily of a pop song (otherwise, a majority of classical, stage musical, opera, and folk recordings, and a great many jazz recordings, would be considered covers, which they aren't). Or in other words, I don't think that Jimi Hendrix's recording of the Star Spangled Banner would really be considered a cover, any more than one by Kate Smith be.
can we add dates for when a work was composed (start, end)? i'd like to start building timeline visualizations of this. this is particularly applicable to classical music but could be generally useful. for instance a timeline of brahms's symphonys (it took him ~14 years to write it because he felt so pressured coming after beethoven's 9th).
secondly - place composed (probably non unique) would be interesting for mapping the works composed. for example - dvorak's new world symphony and american string quartet, and mapping liszt's travels. in general there's quite a lot of data on location composed particularly for classical music that we could easily structure.
thirdly - and this is more complicated, at least for classical music, we should capture the catalog ID - which for many composers is an opus, number combination, but for mozart it was K for Ludwig Ritter von Köchel and haydn and bach also had their own thing.
fourthly - we should also capture key for classical compositions.
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.
Yes, I see your point, but it looks UGLY. Is there a way, then, of getting rid of the "Songwriter" from the page? If we cannot use it, it is better not to have it there at all. Why keep useless things? Please have a look at Cage, his page could look REALLY good if it was not for these 2 empty boxes.
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.
Cris,
we need the "Concert Hall" Type and a list of concert halls, please. There are practically hundreds of them in the world
A composer writes MORE than songs, e.g. symphonies, tone poems, chamber music, etc. There is no way one can mix these with songs together. Can we, please, have a special property for this?
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 there, I'm working with someone who is trying to use Freebase as a semi-official database of their catalog. But one thing that seems to be missing is a place to put an album's catalog ID from the publisher (Kind of how books have "Book Edition"... with ISBN#s)
http://www.freebase.com/discuss/threads/guid/9202a8c04000641f80000000058694f9?domain=/book
Is there any place to put this information on an album?
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.
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.
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.
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.
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).
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.
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?
