Discussions on Musical Artist

Hi Jeff, I replied to your other post. The schema is set up in exactly the same way for both types (as a mediator with uniqueness/disambiguator type hints), and that's why data entry is restricted the way it is through Freebase. Take a look at the schema for Music Group Membership (link below), for example. Open up each property and see how it's set up. You can also click on the topics (the long string of characters in the topic name is the guid) to see what a mediator looks like.

http://www.freebase.com/view/schema?id=%2Fmusic%2Fgroup_membership

HTH.

Good point, Jeff. There used to be a reason why we didn’t want to have multiple roles on a compound value or mediator, but that reason has gone away. Accordingly, we’ve relaxed the restriction on the role played by an artist in a group.
However, the UI will still only show the first role as a disambiguator. For example, take a look at The Police; Sting is now modeled as the lead singer and the bassist. However, when you look at The Police, you’ll only see that he’s the lead singer; you have to View the compound value to actually see that he’s the bassist as well.

Hi Faye, thanks for the quick replies on both posts! It's interesting to know why this works as it does.

What do you think the ideal is here? There are some musicians who play so many roles, we could easily end up with types like "keyboardist, vocalist, percussionist, accordionist"...which of course would be distinct from "keyboardist, vocalist, accordionist, percussionist". I could imagine this getting out of hand quickly.

(Without knowing what the pain/unintended consequences of changing the constraint are) changing this constraint sounds like an interesting possibility. I'd love to know more about the pluses and minuses of changing the design to allow for multiple roles.

If that turns out to be unworkable...do we want to encourage roles that are lists ("keyboardist, vocalist, percussionist, accordionist")? A catchall role ("multiple")? Or something else?

We hope to fix this UI limitation in an upcoming release. In the meantime - you can also add multiple roles by going through the view link (roll your mouse over the band member and select 'view' -- from there you can add multiple roles) - once the UI is fixed, the multiple roles will appear separated by commas.

Thanks faye, crism, and danm!

The songs composed property has been moved to songwriter. Hope that helps!

I’m not entirely sure if you’re objecting to the musical artist type itself or just some of its properties. The artist type itself is pretty solid; it’s industry terminology to talk of “recording artists” and we definitely need the notion of “an entity who performs and/or records music.”
The labels for those properties are still evolving, though, and I’m not completely happy with them yet. For instance, sometimes an entire group plays on someone else’s album, though usually it’s just one person. I do agree that the band-related properties (origin, members) could be moved to a band type. This is worth thinking about.

Hi,

I think my biggest gripe is that last point. Got no problems with musical artist, just having stuff lumped in with them that should be on a more specific type!

wbecker, i think your suggestion is spot on, and i've been thinking about this too. we did the music domain before we had the "included types" feature so we did our best to create a catch-all. but you're right, its confusing and doesn't really work all that well. now that we have the included types, we're looking at moving the members property over to a musical group type, which i think is the only property that doesn't really make so much sense. i think this'll be done in the next few weeks. hope this helps, and sorry for taking so long to get back to you on this!

oh, and i was just told that this change has been made on sandbox.freebase.com so you can have a look and feel free to comment.

Funny you should mention that. Take a look at most of the music instances; you’ll find that our database was populated with MusicBrainz data. We also just participated in MusicBrainz Summit 8 to talk about the next-generation MusicBrainz data model and are converging our data model with theirs (though with a slightly different focus).
The “needle-dropping bamboo” model was killed at that meeting, BTW, in favor of the “symmetric bridges of London.” (-:

Chris, it seems like we should model this like 'sibling' on person or 'adjoining' on location -- I know the case can be made that assertions should be made in one direction in this case, but I don't think that's what people expect.

OK... I found the "merge with another topic" menu item... :-)

Not a bad idea.

It’s a kind of denormalization, though; when there are dates, you can tell who was a member of the group at its earliest dates.

When we run into a denormalization issue, what usually makes the difference is the use cases. Is there something particular you want to do with founders? Is it just something that would be cool to see? How hard is it to find founders without it?

You are right that this belongs on Musical Group rather than Musical Artist, though. The dates you mention are the start and end of musical careers; it applies to individuals as well as to groups (though, unlike groups, the individuals exist before and sometimes after their careers).