Who receives the artist credit of classical Recordings: a performer or a composer?

[jflory]

Hi all,

I wanted to open a discussion about whether the privileged “artist” field in classical works should be attributed to a performer or a composer, and why.

I believe the artist credit should be left to the performer of a piece. I was thinking about this working with @reosarevok on a new release this week. In this case, a living artist released an album featuring Recordings of mostly 20th century composers.

In each Recording, the artist credit is given to the composer. I believe this is inaccurate for the following reasons:

1. Harder to query unique performances: Given that Artist credit is highly visible metadata, a composer receives credit for Recordings they did not actually record (contradicts other examples in MB, see below)
2. Less visibility for performer: Disservice to performer with visibility in music listening services (e.g. ListenBrainz / Last.fm); performer name never appears in those services
3. Duplicates attribution credit in a Work: If correctly attributed, the composer already receives attribution as composer of a Work

This contradicts other examples in the MB database I found with Recordings, like Queen’s Bohemian Rhapsody. Even though the original Work is written, composed, and performed by Queen and its group members, Pentatonix and Panic! At the Disco receive Artist credits here. Is there a reason why Recordings of compositions should be treated differently?

I would like to suggest a style change where performers receive the Artist credit for Recordings of compositions they perform. For Recordings, I think they should reflect the person responsible for the actual recording of the Work. The composer should receive attribution as composer in the greater Work. I believe this reflects intention when querying the database for an artist and also is a subtle (but helpful) discoverability boost for performers in music listening service sites (e.g. ListenBrainz).

Anyone else have thoughts on this? Does my feedback and suggestion make sense? Curious what others think about this.

Edit: This was discussed in a different way previously in this thread:

Classical releases vs. non-classical artists

https://musicbrainz.org/edit/53868774 Looking at the Björk discography I noticed an album called “Distant Light”. I thought it might be an official Björk album I hadn’t heard of but it is actually a tribute, with four Björk covers and a few “covers” from other artists. Since this is a classical release this album is credited to Björk as a composer, and now appears between her other albums as a Björk album, which it isn’t, except the classical guidelines say this is what a composer should be cr…

[IvanDobsky]

A problem I see is how other people use the MB data, and have done for decades, outside of the MB website itself.

Some people are deep into their classical and want to see the tiny little details. These are available now with extra database lookups.

Other people are just partial users of classical and just see the 1812 Overture as something by Tchaikovsky.

Changing that Artist field would have a major effect on the majority of external users of the data and how they have expected to see it for many years.

Does it not make more sense to have alternate views available? Change what is visible on the website? This is a Relational Database so there should be a way of producing (a choice of) alternate views for Classical. That way you don’t cause potential uproar from the outsite world by changing the historic meaning of “Artist”.

[CatQuest]

@IvanDobsky

Does it not make more sense to have alternate views available? Change what is visible on the website? This is a Relational Database so there should be a way of producing (a choice of) alternate views for Classical.

Actually this is a great idea (and one which sounds similar to a idea I myself had aaages ago :‌D)

Basically different users use and look at the DB in different ways. Having several “views” will be highly beneficial for the different “artist-types” that exist.
Not just for “classical” composers either, but for things like remixers and dj’s, people who predominantly re-imagine other people’s work, musicals and dance-theatre and things like characters that are performed (sometimes by several people) are all types of artists that might fit less good in the usual “artist page” we have today.

[IvanDobsky]

@CatQuest - I do love your official title.

Expanding of choices of views could help so many other areas too. Audio books, Audio Plays, and all those other kinds of things that don’t fit an model built around limited MP3 tags.

Don’t break past use - instead use as an excuse to expand to a more flexible future.

[CatQuest]

@jflory

I would like to suggest a style change where performers receive the Artist credit for Recordings of compositions they perform . For Recordings, I think they should reflect the person responsible for the actual recording of the Work.

hmm. re-reading this. I do believe this is actually official practice? @reosarevok

for the tracklist, now that’s a different thing…
I believe the “tracklist credited to composer” was (and is) a compromise to cater to “the other view” as per Ivan’s post.

[jflory]

Hi @IvanDobsky and @CatQuest, thanks for your feedback.

@IvanDobsky

A problem I see is how other people use the MB data, and have done for decades, outside of the MB website itself.

@IvanDobsky

Some people are deep into their classical

@IvanDobsky

Other people are just partial users of classical

@CatQuest

Basically different users use and look at the DB in different ways.

I understand that changes to established ways of doing something are disruptive. Are there supporting data or metrics about external use of MB data? Or could you give an informed guess on the different needs/requirements of these types of people? Who are they and why do their ways of working with data differ?

I am newer to the community and not aware of the broader external uses of MB data, but curious to learn more.

@IvanDobsky

Changing that Artist field would have a major effect on the majority of external users of the data and how they have expected to see it for many years.

I recently found the classical portal in the Style Docs. Classical docs are tough to find since the other editing docs offer few disclaimers that classical works have unique sets of rules. A new contributor does not easily learn the difference when editing. Does this risk a bigger impact of inconsistent data across the community of editors?

In the past seven days, 1,254 editors made at least one edit to MB. Since there are not 1,000 people engaging in these conversations, I assume many editors do not follow IRC/forums discussions often, but I assume many look at the Style docs (and may also overlook parts they didn’t know apply to them).

Could the documented distinctions between classical music and all other music be more discoverable in the MB interface? Other than genre tags, is there an effective way at querying both sets of data separately from each other?

I personally believe separating the two sets of data creates two different databases, each with incompatible ways of querying data. From a DBA perspective, it is harder to normalize a database with an updated definition, compared to ensuring all data consistently meets a normalized definition of a data field decided during database design. I think there is a valid argument for standardizing behind one common definition for things like artist credits, and providing one supported method at querying all MB data.

@CatQuest

hmm. re-reading this. I do believe this is actually official practice? @reosarevok

for the tracklist, now that’s a different thing…
I believe the “tracklist credited to composer” was (and is) a compromise to cater to “the other view” as per Ivan’s post.

I misunderstood. The Recording artist credit does not change. It is only the Tracklist in the Release. This might partially address my reason #1 above, but it does not address reasons #2 and #3.

The difference was not obvious to me even now.

[Jim_DeLaHunt]

Hi, @jflory Justin:

Welcome to MusicBrainz. Thank you for contributing your efforts to improving this data collection, and thank you for opening a thoughtful discussion in this forum.

@jflory

In each Recording, the artist credit is given to the composer. The Recording Artist is credit given to the performer.

I’d rephrase that as, in each Track within a classical music Release, the Track Artist credit is given to the composer. See the (hard-to-discover) style guideline Style / Classical / Recording / Artist.

@jflory

This contradicts other examples in the MB database I found with Recordings, like Queen’s Bohemian Rhapsody …. Is there a reason why Recordings of compositions should be treated differently?

Given that we are talking about Track Artist here, you are correct that the rules for a classical music release are different than those for general western popular music. See the (hard-to-understand-also) Style / Classical / Track / Artist.

Can we agree on a few things up front?

1. This discussion has happened before. In exhausting detail. Over years. It is a new area to you, because you are new to data curation at Musicbrainz. But for many of the other participants, it is well-trod ground.

2. Different people want different things from the MusicBrainz data. As @CatQuest put it:

@CatQuest

Basically different users use and look at the DB in different ways. Having several “views” will be highly beneficial for the different “artist-types” that exist.

3. Within the great diversity of users and uses of this DB, the classical music users are a big segment with requirements that differ significantly from the median user. Those users have different opinions (compared to users focussed on mainstream Western pop music) on the relative importance of composer vs performer, and of composition vs recording of performance, in describing a Release.

4. So, over MB’s history, variant Style Guidelines have been worked out for “classical” Releases. These variant “Classical Style” guidelines fit the opinions of the classical music user segment better for “classical” Releases, and the mainstream Style guidelines fit the opinions of the mainstream user better for mainstream Western pop music Releases. Essentially, the classical music user segment got special treatment, compared to those interested in remixes, DJs, audio books, audio plays, etc.

I’m one of the classical music users, and one of the participants in the extensive debates about style guidelines over the years. What do I think about the questions you raise?

My first take is that Artist fields (be they for Release, Track, or Recording) are terribly crude and limited as data structures. They aren’t up to the demands we would put on them. We shouldn’t put much effort into fine-tuning how they behave. Relationships are the mechanism to build on. Thus, I agree with @IvanDobsky:

@IvanDobsky

Don’t break past use - instead use as an excuse to expand to a more flexible future.

Second, your criticism about “harder to query unique performances” and “less visibility in music listening services” are really criticisms of the limitations on query UIs, and music listening services. They put too much focus on these crude Artists data structures, and don’t take advantage of the richness of the Relationships. Yes, it’s harder to query Relationships, and the resulting data is complex. That is the complexity of music metadata. Don’t dumb down the data, smarten up the consumer.

Finally, I agree with your critique about discoverability and complexity:

@jflory

Classical docs are tough to find since the other editing docs offer few disclaimers that classical works have unique sets of rules. A new contributor does not easily learn the difference when editing. Does this risk a bigger impact of inconsistent data across the community of editors?

Those docs are better than they used to be, and they should become better still. Yes, they are hard to learn. Yes, our data is inconsistent as a result. Yes, this imposes a workload to clean up the inconsistent data. But it is better than alternatives, like crude and inadequate data structures and styles. You have a special gift in this discussion, that you are seeing the shortcomings of MusicBrainz with fresh eyes. Please say what you are seeing, and help come up with specific, actionable suggestions for improvement. But be prepared to discover that simple solutions may not be adequate, because music metadata is complex.

Welcome to MusicBrainz, and thanks for your help!

[mmirG]

@Jim_DeLaHunt

You have a special gift in this discussion, that you are seeing the shortcomings of MusicBrainz with fresh eyes. Please say what you are seeing, and help come up with specific, actionable suggestions for improvement. But be prepared to discover that simple solutions may not be adequate, because music metadata is complex.

jflory, what Jim has written here is very accurate.
You write clearly and without acrimony.
And you’ve got new eyes.

Let us know where you see problems in the user interface - maybe there are ways that the current very steep and prolonged learning curve can be flattened and/or shortened?

And an easier initial experience will lead to more new users continuing to edit Musicbrainz rather than giving up and finding something less frustrating to do.

[jflory]

@Jim_DeLaHunt @mmirG Hi, you both raised a lot of great points and helped me understand the deeper context of Classical music in MB. I agree with you that my original proposal is not the right way. It is on my list to reply with other ideas, but I will unpack the 2019 MeB Summit first and factor some of that into my counterproposal. I’ll reply sometime in October.

Also, some of this might be influenced by the on-going MusicBrainz docs discussion! Please share feedback there if you have constructive feedback or ideas about docs:

Documentation roadmap: How do we build related docs together? What does it look like?

Hi folks! Previously in the Summit, we talked about docs and how to better integrate existing documentation into our code bases and lower the contribution bar of editing docs for the wider community. So, while the Summit is on-going, I put together a proof-of-concept of how inter-linked Sphinx documentation repos could work. This also comes from an infrastructure POV, how do we assemble and present those pieces in a clean and simple way to the community? To demonstrate this, I created three Gi…