crism

Music modelling: Conductor - Conducting

2008-09-23T21:10:42.0000Z

Let's do the simple stuff for now: Turn "Opera Conductor" into just "Conductor", and add a new property for "Ensembles Conducted" (or words to that effect), which would be a date-mediated property. We'll have to tackle performances at some point, but we should fix the stuff that's actually wrong now.

Music modelling: Conductor - Conducting

2008-09-19T16:55:40.0017Z

The other outstanding question in my mind is what should the properties of Musical Performance be, and how do we distinguish individual performances from series (a one-night concert vs. a weeks-long opera production)? Also, are we talking about a "Conducted Performance" type or a general performance type that can be used for all musical artists/groups -- the issue for The Beatles is relevant here, as well.

Music modelling: Conductor - Conducting

2008-09-19T05:33:25.0012Z

I think there are two properties appropriate here. One is a generalization of “Operas Conducted”: it should be called something like “Significant performances conducted.” This would capture the opera productions conducted (which is really what “Operas Conducted” is talking about) as well as other significant performances, like premières of symphonies and such. The other would be “Ensembles conducted,” and would point to the orchestras, jazz bands, choruses, etc., that the person had led. That would be a CVT with dates.

The outstanding question, to my mind then, is what is the expected type for “Ensembles conducted”?It would seem a bit weird to have a blank “Conductor” property waiting to be filled in on Nirvana, the Beatles, etc. Should we have an “Ensemble” or “Conducted ensemble” type with “Musical group” as an included type?

Music modelling: Conductor - Conducting

2008-09-19T02:56:05.0000Z

Let us start with a simple model at the beginning, so that we can go on with work on ANY conductor. We can have a Conductor type with the property Orchestras/Ensembles conducted (to include choruses, chamber music emsembles, etc.). Later we can develop other properties, when we get some good ideas. "When" and "How" conductors work sounds a bit like trivia to me, but we can list even that with moderation. Two-three important orchestras in the life of every conductor should be enough, don't you think?

Music modelling: Conductor - Conducting

2008-09-17T21:54:16.0024Z

Gordon, if I understand you correctly, you're proposing "Conductors" properties on Musical Group and Musical Track to link to the CVTs you're proposing? Since only a minority (even though it would definitely be a sizable minority) of groups/recordings could have a value for this property, it seems like overkill. I'd favor co-typing a Conductor type with Musical Artist to capture that information (assuming we determine that we need a Conductor type).

The question of performances conducted is another kettle of fish entirely; to my knowledge, we haven't attempted this (outside of opera, which only attempts to capture the conductor and singers) at all.

Music modelling: Conductor - Conducting

2008-09-17T19:10:57.0012Z

Definitely in the classical orchestral world, the conductor is probably one of the most important roles, sometimes overshadowing that of the composer (Leopold Stokowski is a classic example of a conductor who would alter/rearrange/adapt scores to suit the performance and/or ensemble). Stan Kenton and Nelson Riddle in the Jazz/Vocal Pop music world, they are just as important as the artists they worked with. In opera, orchestras, & small ensembles, the role of the conductor is usually pretty much the same.

So I vote for some sort CVT that captures something of the time spent with, performances conducted, recordings made with an ensemble of any size/nature

Music modelling: Conductor - Conducting

2008-09-17T18:46:07.0012Z

...then make them ALL conductors. The minute one takes the baton in the hand, one becomes a conductor, no matter what kind of ensemble/orchestra one leads, big or small. Certainly that there are opera conductors (Mutti, Levine) but that is only a speciality of the conductor. In essence, they are all conductors so we can get rid, at least, of this confusion...

Music modelling: Conductor - Conducting

2008-09-17T18:27:15.0017Z

[posted to the data-modeling mailing list]

When Jeff created the Opera domain, he created a Conductor type to represent the conductor of an operatic production.

When I created the Music domain, I treated conductor as a performance role within a group, no different than the third violinist.

Now we have a Conductor with only the Operas Conducted property, which makes it look weird when talking about orchestra conductors. We also have a Performance Role that various people hold within Musical Groups.

We should reconcile this one way or the other. Opinions about which way is preferable? Please make your responses in that Music Modeling Interest Group thread so that there will be an easily visible record for future Freebase users.

Music modelling: Conductor - Conducting

2008-09-16T06:32:32.0012Z

Cris, in music, after the composer who is THE most important person of all, the conductor comes next.He is a CONDUCTOR (like composer/singer/professor/etc. and NOT conducting, conducting is an activity. This is a big difference! You become a conductor yourself when conducting, and cannot define yourself as a member of some group, or conducting some people, and so on. There is a whole row of conductors out there starting with Felix Mendelssohn who would go up the wall if you would say that they are not conductors but conducting!! There is no difference between opera/jazzband/whatever conductors, they are ALL conductors so we do not need to take THAT into consideration, just develop one conductor type. We usually talk about "Opera conductors" because Opera and Ballet are such spectacular things with big audiences, major productions, etc., but practically there is no difference whatsoever between an opera conductor and other conductors.

Orchestra - Ensemble, call it as you wish, I personally think that the Berlin Philharmonic Orchestra or the New York Philharmonic Orchestra are ORCHESTRAS and not ensembles, but again, an ensemble is an orchestra no matter how big or small it is. This is not a question of size but what the thing IS!

Hence, we have now a conductor who conducts orchestras. He does that sometimes on a more permanent base and sometimes (as you say) as a guest conductor. I am no expert on modelling and cannot help you there but I strongly believe that we should not fill the database with trivia! So you can think now how to present this as a type. Put something on paper and please let me know before you put it in the computer. Let us discuss this by email, (Kirrily/Jeff/Dan and others have my address)...

Music modelling: Conductor - Conducting

2008-09-16T04:40:56.0012Z

I agree that this is information that it is good to model.

First, is the current model insufficient? For example, I’ve added Gustav Mahler as the conductor of the VPO (on sandbox) using the membership and rôle of the musical group. (Or, for that matter, see also myself with respect to the Brown University Band.) This would be my preference; I do not believe Conductor really needs a type of its own.

Second, if we do indeed need a Conductor type, what should its properties be? I would favor “Ensembles conducted” over a property for orchestras; there are significant wind ensembles, choruses, and marching bands that should not be orphaned.

Also, how do we model guest conductors? Looking at the VPO, I learned that they haven’t had a regular conductor since 1933, but they have had notable guest conductors throughout that time. Do we simply state that Maazel conducted the VPO at some point? Or should we model the dates?

Finally, note that musical recordings have the rôles of the participants modeled, so conductors can easily be described on particular recordings. Something similar could be done for live performances; in fact, this is what the Opera domain does, which is where this type originated. We could model significant live performances and the rôles played by different people in them.

What do you think about all this?

Composition: dates and location of composition

2008-09-08T22:02:15.0012Z

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.

Composition: dates and location of composition

2008-09-08T17:25:56.0012Z

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.

Composition: dates and location of composition

2008-09-06T18:19:09.0012Z

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.

Composition: dates and location of composition

2008-09-06T18:14:53.0018Z

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.

crism: Wrong banner

2008-08-21T02:04:17.0012Z

Thank you

crism: Wrong banner

2008-08-21T01:55:19.0012Z

Thank you

carmenmfenn1

crism: Wrong banner

2008-08-20T21:42:28.0012Z

Jeff, my dear, the merge took place today and cheunger removed the delete flag manually!! Now I can breathe again and thank you all for the speedy action. It would have been a catastrophy to loose all that work...

carmenmfenn1

crism: Wrong banner

2008-08-20T21:37:16.0012Z

It will take a long time for this item to come up in the queue of merge/delete tasks (there are several hundred ahead of it), so this flag won't be cleared for awhile. But it won't be deleted; don't worry.

crism: Wrong banner

2008-08-20T21:36:17.0013Z

THANK YOU and be blessed!

carmenmfenn1

crism: Wrong banner

2008-08-20T21:33:40.0012Z

Hi Carmen,

This is probably an artifact of the merge. When the topics were merged, the delete flag was also merged. I've already filed a bug regarding this and in a future release, the flags should be reset after a merge. I've gone ahead and manually removed the flag.

crism: Wrong banner

2008-08-20T21:30:18.0012Z

EXACTLY!!

I hope you can stop this, I worry my head off .

carmenmfenn1

crism: Wrong banner

2008-08-20T21:27:05.0012Z

It looks like the bad topic got merged into the good topic, and the "delete" flag got merged along with it. This is clearly a bug -- thanks for bringing it to our attention!

crism: Wrong banner

2008-08-20T20:48:55.0017Z

Good morning, Cris

long ago I flagged the duplicate Lorenzo Ferrero with Merge or Delete. Today after the merge, the Delete banner appeared on the GOOD page. Please have a look, as it was never meant to be like this, the actual page is not for deletion! Thank you,

carmenmfenn1

Transit Stop: Date opened property

2008-08-08T18:52:21.0018Z

A date opened property could be useful and would be easily mapped from wikipedia infoboxes. For ideas of other properties, look at the Wikipedia infobox:

http://en.wikipedia.org/wiki/Template:Infobox_Station

crism: Test

2008-08-02T16:12:06.0012Z

Um… you’re welcome? I’m not really sure what I did, though. Or am supposed to do?...

crism: Test

2008-08-02T14:36:39.0012Z

http://www.computescotland.com/1501.php

Thanks for giving me some IT type link for Jura.

Best,

Gail

Distilled Spirits: Spirit brands

2008-07-11T14:36:48.0012Z

In attempting to migrate instances of the now-obsolete Whisky type to distilled and blended spirits, I am running into a frequent problem. Some of the so-called whiskies were actually distilleries or blenders, and those are easily handled. However, many of them, particularly bourbons, but also blended Scotches, are actually imprints or brands; they are not single spirits, but neither are they distillers, bottlers, or blenders. How important are brands to represent? What model is appropriate?

Composition: Date Created

2008-06-25T17:11:53.0012Z

Good suggestions. I’ve made these changes over on sandbox for comment; I’ll recreate them here if folks like them.

Composition: Date Created

2008-06-25T11:09:10.0015Z

Could we have a Date Created (type Date/Time) property?

Also a First Played (type Date/Time) property would be good. Possibly extend this to a compound type including a first played (type Location) property?

Composition: Traditional compositions

2008-05-28T03:55:57.0000Z

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?

Transit Stop: "Terminus for lines" property

2008-05-27T21:38:29.0007Z

I would say that a terminus should also be a stop. It's probably better if we make it explicit, so that people can query against a single property to find all stops on a line, rather than having to query both stops and terminuses (termini?).

Musical Group: Ex-Members Property

2008-05-27T17:12:40.0000Z

Band membership has a beginning and end date; former members should have an end date, although it's true that in many cases Freebase won't have that data. But, in my opinion, splitting the membership roster into separate properties for current and former members would cause a bigger problem for cases where we don't know a musician's status -- it forces us to arbitrarily make an assertion (current or former) when we lack the knowledge to make that assertion. At least with the current model, you can say that someone was or is in a band when you don't know the current line-up.

I think the current model will be a little clearer if we get the ability to store the notion of "current" or "present" in date fields.

Transit Stop: "Terminus for lines" property

2008-05-27T01:15:49.0007Z

It's not totally clear to me whether a thing which is a terminus for a line should also be marked as a stop on that line, or if the fact that it's a terminus implies that it's a stop on the same line.

Transit Stop: Add "address" property

2008-05-26T19:25:14.0012Z

In the US, at least, rail stops generally have street addresses and some times phone numbers (see http://www.metrarail.com/Sched/cnw_n/cnwn.shtml for example). Adding addresses would be valuable, especially as more bots geocode addresses.

Composition: Traditional compositions

2008-05-26T15:41:21.0012Z

Is there a preferred way to indicate that a piece is generally credited as "traditional" (often with an arranger credit)? It's clear that imported data sometimes perpetuates "Trad" as a composer.

I suppose using "Arrangement" and leaving "Composer" blank is the best alternative?

Musical Group: Ex-Members Property

2008-05-24T23:16:37.0012Z

Wouldn't it make since to have an Ex-Members property?

Music modelling: Classical works

2008-05-22T19:53:02.0007Z

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:

The catalog abbreviation and opus number should be text (or even machine-readable strings), not Topics; making D (the topic about the fourth letter of the English alphabet) the abbreviation for Schubert’s catalog is a bit strange, likewise for the number 1.
The expected types for other properties could also be adjusted; the “composer” property should expect Composer, “musicologist” should expect Person, or ideally, a new Musicologist type.
I would also have your composition include the Composition from the Music domain to make it easier to see what properties are already present and which need to be added. Is a discrete “title” really needed, in addition to the name of the topic?

Thanks for getting this started.

Music modelling: Classical works

2008-05-21T08:10:43.0005Z

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?

crism: Test

2007-11-20T02:13:29.0129Z

Is this thing on?

crism: World Factbook Data for Countries

2007-09-04T07:16:16.0000Z

Excellent news, I was just worried that it had gone quiet.

I can see that particularly for countries, there could be almost unending statistics which would make the page very busy. Different levels of view seem like a good way of approaching this. Maybe each user could specify which properties they'd like to see on a page, and there could be groups of properties defined as well, so by default only the "overview" properties would be shown.

As I was making various edits, I thought it would be nice when adding a value to be able to also indicate the source of the data, (and possibly to accomodate multiple values from different sources). e.g. the total area of a country is not as well defined as you might think and there are a variety of different sources which give different values for the areas. This is common for many properties, and it'd be nice for any property to be able to say where the data is from.

crism: World Factbook Data for Countries

2007-09-04T05:22:50.0007Z

Ήο Κυβερνήτικος! The Factbook data exposed a whole raft of interesting issues with which we’ve been dealing before returning to it. This includes support for units of measurements in properties, time-variant values, and just some general user interface design issues (as adding three dozen properties really changes the look of a page). Stay tuned, though!

crism: World Factbook Data for Countries

2007-09-03T18:47:27.0005Z

I notice that you mentioned that you'd added the world factbook data to the sandbox sometime ago, but it hasn't made it into the nonsandbox version. Are you still working on it?

crism: "Deaths in [date]" topics

2007-07-24T19:22:46.0000Z

Thanks for getting back. In fact, since they're basically lists: should the topics be there at all? Presumably there's a case for flagging them for deletion (since like wikipedia 'Lists of X' pages in general) whatever information they contain would only replicate some query (here, about deceased people & their date of death).

crism: "Deaths in [date]" topics

2007-07-24T19:07:54.0007Z

Hi, dsp13. That type was added by a script I ran, when date of death was moved from Person to the new Deceased Person. I had no intention of asserting personhood of any topic touched by that script, so by all means remove the person types from those topics as you find them. Thanks!

crism: "Deaths in [date]" topics

2007-07-24T18:09:13.0004Z

Chris, I notice you've added the type "deceased person" to these topics; my intuition was that since the topics were lists of people rather than people, they shouldn't be typed "person" at all. But since you seemed to be acting with purpose, I stopped my reflex deletion of the type to raise the query with you!

crism: language

2007-05-29T21:22:59.0011Z

What happened to your comments on my language types? Lost to the void it seems. Is this a discussion bug or a sinister plot?

Transit Stop: "Terminus for lines" property

2007-05-15T01:50:00.0006Z

The terminus is the end of the line. This isn’t necessarily clear from the list of stops, especially if the list of stops is incomplete.
The way to find transfers is that a stop is connected to multiple lines; perhaps the lines should be disambiguators for the stop, so they show up easily?
Next and previous can be inferred from the list of stops if they’re ordered, but that’s something of a big if. However, I’m not entirely sanguine about explicit next and previous links either (see also albums, comic issues, TV episodes…). More discussion is welcome.

Transit Stop: "Terminus for lines" property

2007-05-13T00:40:36.0012Z

Is this property same as "transfer to lines". I would like to enter what lines you can transfer to from a Transit Stop.

Also, I think it would be valuable to enter what the "next" or "previous" stops from a Transit Stop along a Transit Line