Generic work titles (guidelines for them?)

Generic work title is typically just the type of work with a number. Typical example would be “Violin Concerto no. 2”. Same work could be referred to as “Concerto for Violin no. 2” or “Concerto no. 2 for Violin and Orchestra”. There’s endless amount of variations in multiple languages but nothing changes the fact that it’s still the 2nd concerto for violin.

Generic work titles aren’t names. These are typically never used in their original format. If you look at concert programs, discographies, library databases and releases you typically don’t see them in original format (as on original manuscript). Thousands of letters have survived having composers themselves referring to their works as “5th Symphony” instead of “V. Symphony for Large Orchestra” as seen on manuscript. If letter is written in different language they also use translated aliases. Published score is typically having the title in different format as on original manuscript. If the format would be that important why would composers allow changing it and still continue publishing with the same company? Why the title often changes when the publisher changes? Same work could have the title in 6 formats. French publisher uses French titles, German publisher German titles, etc. Repeating myself: these aren’t names but generic titles.

Generic titles are typically standardized. Wikipedia, IMSLP and most of the databases have some naming conventions for them. Libraries typically standarize these by using local languages. For example all Finnish libraries standardize Mahler works by following this document. Like in Finland libraries typically keep names in their original language and translate generic titles.

There’s lately been some edits replacing English work titles with titles in composer’s native language. As long as MB system doesn’t fully support aliases (Swedish titles shown in Swedish version of MB, etc.) we are just making everything harder for our users. Default UI is in English so most of the editors enter this type of data in English. This data is also used by other services. For example BBC uses our work data. I hope they are somehow prepared for sudden language changes in generic titles.

If the title is in standardized form (like “Symphony no. 6”) you can easily search for it when you know what to search for. “Sechstre Symphonie für grosses Orchester” isn’t something you typically search for. Sure we support aliases but people have just been replacing the titles without adding any aliases. I give some value for original format and could consider adding a new alias type for it but see little benefit of forcing to use it as an primary title.

Like all the other services we should keep names in their original format (& language) but I propose that we would decide to use English for generic titles. Maybe some standardized format. There’s no benefit of entering titles in multiple languages when it doesn’t add any extra value.

There’s clear problems when using composer’s native language for generic titles. Why would we use German for the title if composer himself might have used English for it? Because he natively talks German? It’s actually harder to find composers who only used their native language for titles than the ones who didn’t. Even harder if we include modern composers. Before proposing a guideline for work titles I would like to see some feedback.

9 Likes

Very thoughtful and stimulating post! I have encountered numerous instances of gross inconsistencies which are downright annoying. For example, Tchaikovsky’s Sleeping Beauty has English names for all the parts but the top work is in Russian with Cyrillic script.
This issue has caused me quite a few problems with my Classical Extras plugin, which uses the MB work structure to provide a richer tagging capability than vanilla Picard. Inconsistent names look really odd when used together. My proposed solution for the plugin (beta of the new version to be released shortly, I hope) is to provide an option to use the primary alias for the chosen locale. In addition, users will be able to flag any work with ‘use_alias’, say, if additional optionality is needed. This is admittedly a work-round, but it seems to work.
One thing I noticed while doing this is that all alias edits can be applied automatically, even for primary aliases. While convenient on one level, this could cause problems if aliases become more frequently used and relied on - I can envisage ‘alias wars’ :rage:. On balance, I would think it better if voting was required for changes to primary aliases.
To return to the original point, some guidelines and greater consistency would be great. I haven’t been following the ‘clean-ups’ very closely, but I assume a consistent approach has been adopted for these?

4 Likes

Bravo! Very good observation, @ListMyCDs.com!

I will venture a step further to say that there are some implicit ideas common in MusicBrainz guidelines and participants, which I think are sometimes incorrect — especially for western art music, or “classical music”. The case of generic work titles is an example of these ideas being incorrect for these works.

It may seem that everything has a name, in the form of a specific sequence of words or characters in a specific language. I’ll argue that a lot of classical works do not have names in this sense. They have identifiers, “generic work titles” as @ListMyCDs.com put it. The identifier gives the type of the work, a sequence number, maybe a summary of the instruments, maybe an idea of the key; but all are language-independent abstract concepts. All are best rendered into the reader’s local language using the conventional terminology for those abstract concepts.

It may seem that each thing has only one best name . No, many things in life have multiple names, used by different people in different contexts. So too with classical music works. Mozart wrote an opera, to which he apparently gave a formal name Il dissoluto punito, ossia il Don Giovanni. Another person came up with an identifier, K. 527. In current North American reference, it’s perfectly fine to refer to this work as Don Giovanni. And MusicBrainz has standardised on the compound name, Il dissoluto punito, ossia il Don Giovanni, K. 527. Works have many names. It’s important for MusicBrainz to embrace this.

It may seem that the Artist is the only source of names. Maybe, for music composed and published recently, few hands were involved in the naming: perhaps the artist, their manager, the record label. In classical music, many works have had decades or centuries to marinade in the culture. Many hands have influenced how we name works. For instance, it was not Tchaikovsky, but a translator, who applied the name “Pathétique” to his Symphony No. 6. MusicBrainz correctly retains this mistranslation.

It may seem that it’s to apply the Artist Intent principle strictly for these names. I think the Artist Intent principle is good, especially for metadata where the artist made an intentional choice about text which we will put in our database. But note that Artist Intent is now phrased as “Artists sometimes choose to present names and titles in ways that deliberately contradict the rules”. It does not say, we will slavishly imitate every accident of the Artist’s wording. In fact, quite the opposite. We correct errors in MusicBrainz, except when the Artist deliberately chose to break the rules.

It may seem that a reference should be limited to one language. Normally in English language discourse, we render foreign phrases into English. But classical music in particular has a rich German, Italian, and French language cultural history. It’s quite normal in classical music discourse to code-switch among these languages. Note how in English and German, when naming Tchaikovsky’s Symphony No. 6, we switch to French for the word “Pathétique”. Conversely, it’s quite normal in classical music to render those language-independent references, e.g. “Type: Symphony, Number: 2” into the local language.

So, I think it would be good for MusicBrainz to:

  • embrace this understanding of some classical works having abstract, symbolic references, or “generic work titles”
  • have a robust mechanism for presenting each user with the desired language rendering of Work (and Track and Release) titles, so that a user can see the abstract, symbolic reference rendered in the customary words for their language
  • allow multiple customary names for things, with the user able to choose which name they prefer, in preference to having endless battles about which of several legitimate options MusicBrainz will exclude
  • have a place for culture-specific customary names, even when they differ from the Artist’s wording at the time
  • embrace the idea that some Titles (and Releases) will involve multiple languages, and stop insisting that there be only one answer to the question, “which language?”.

Easy? No. But essential to representing classical music well? Yes!

8 Likes

Just a quick comment, I think these have been referred to in Musicbrainz in the past as “descriptive titles”. I’m not sure if this phrase appears in the actual guide, but it seems like it might be helpful to have a common term for the concept.

3 Likes

Did anything come of this? The Works guidelines, as far as I can see, still don’t specify using English for Work titles.

There is a new edit that brought my attention to this.

The potential solution using aliases is available and not utilised in this case.

Editor could’ve used German Primary Alias and once voting is complete on the proper presentation in German (capitalisation especially) then we have a solution.

I agree with the original posters on a common name of work in a common language of the UI and locale specific common names as aliases, hopefully with one for a locale being a primary (shouldn’t we enforce aliases ALWAYS to have a primary ?).

Similar situation exists for the Artist and I use the English Primary Aliases for cyryclic alphabet like this one

marking one as Primary if does not exists, after all how do you select in a script which one to use ?

perhaps @reosarevok can comment ? Do we need more discussion or perhaps this topic does not have enough traction ?

My view of this is still “as long as the title is consistent, correct and sensible, it’s not too important what language it is in - that’s what aliases are for”. I mean, sure, it’d be a bit absurd to have all the Bach works in Russian, but having them in German or English seems equally valid to me. Maybe one day we’ll fix this by just not having one name but only aliases, but in the meantime it seems like the best thing is to not edit war about title languages but just ensure all aliases are there.

4 Likes

I’m coming here from this edit comment discussion.

Let me add one aspect. There are “language-aware” people like me who do not want to “see everything in English” or “see everything in German”, but who want to see the title in the composer’s native language. This cannot be achieved based on the data stock of the current alias system.

Therefore, it makes sense to put the titles in original language into the main entry. People who want everything in English can achieve that based on the alias system (provided that they are supported in a coherent way at some point…)

Precautionary answers to three potential objections:

  • “but I don’t want to see titles in cyrillic script” … This could be solved with appropriate UI options, for example
  1. always displaying a language-specific alias in disambiguation-style after the original main title or
  2. displaying the title in a language-specific alias in case that the main title is in an non-Latin alphabet.
  • “but there are composers/works without a clear native/original language, like Chopin (Polish/French) or Händel (German/English for the later works)” … True. But in musicbrainz, we are often faced with ambiguities like this. We will find a solution for those cases.

  • “Translating Mozart’s »Così fan tutte« into his native German »So machen es alle« doesn’t feel right to me.” … I completely agree, and that’s certainly not what I’m suggesting. If there is a clear artist intent behind the title, that one has highest priority, of course.

4 Likes

I think Disambiguation would be overused here, isn’t it original purpose just for Clarifications only ? For example 2 Artists with exactly same First and Last Name ?

Polish and Hungarian are Latin based, and being Polish, I don’t really see a purpose for Polish titles as main names on an international site. This is not very useful unless you are native speaker:

or this one:

It’s true that most of the Classical Western music composition names are either in German, French, Italian or English but that does not mean that other countries did not have composers. And Cyrillic Russian or Bulgarian or Greek is just a case in point.

I wish that the UI was multilingual, but it’s not, and as a lingua franca English is de facto it, like it or not.

@nadl40

Sorry, but my impression is that you don’t get at all what my point is.

Provided that the support in the UI is improved at some point, you could simply set it to “display the English alias for everything” and you would see everything in English, as you want.

But for people like me (and I’m not the only one) who prefer to get the titles as original as possible, this is not possible and it cannot be cured by UI updates. The reason is that the alias database does not contain the needed information. But the problem could easily be fixed by putting those titles directly to the title field.

I never suggested to use the disambiguation field for putting English or other language translations there. I wrote that it might make sense to create an UI option to display the alias in some language in disambiguation-style (i.e. in lighter color and parantheses next to the main title), for people who want that.

Sure, but what’s your point?

What I missed is that you suggest changes to the UI to make it multilingual, I thought the discussion is around a workaround with existing functionality.

I wish for a multilingual site as well, displaying UI and data elements in the browser preferred language. This is huge undertaking and I’m not optimistic it’s coming anytime soon.

As for the last paragraph, a common language, whatever it is, is a good compromise for ALL to understand work title, including the less popular locale.