The Work entity includes a text string “name”. But neither Style/Work nor Style/Classical/Works mention the Work name, let alone give guidance for how to write it.
Is it settled consensus that:
For classical Works, the Work name should follow the guidelines of Style/Classical/Track/Title, but applied to what name is in the music score instead of on a Release liner?
Similarly, for Works outside of classical, we follow the guidelines of Style/Titles, but applied to the work name printed on the song score or sheet music?
For either kind of Work entity, since frequently the Work is added to MB based on a Recording Title, which is based on a Track Title, which is based on a name printed on a Release liner — with no music score in sight — that it’s acceptable to use the track title on the Release liner as an approximation of the Work name, until something better comes along?
Is this settled enough, that it would be an editorial task rather than a Style policy decision to write something like this in Style/Work? I suppose @reosarevok could make that ruling.
If this isn’t settled consensus, then I suggest it would be helpful to achieve a consensus. I’m happy to write a proposal. I’d have to learn how the Style process works these days.
(By the way, I’ll observe that Style/Titles doesn’t actually say clearly that titles should be based on what’s printed on a Release. Funny how sometimes we overlook what seems obvious.)
Background: Name field discussed in thread What language to use for classical work names . Supports the consensus as stated above, but no conclusion that Style Guidelines should be improved.
While I have those wiki pages open, I’d like to add a “see also” link from “Style/Work” to “Style/Classical/Works”. Otherwise it’s hard to discover that Style/Classical/Works exists. Also, I’d like to add the big Style link box to the bottom of “Style/Classical/Works”.
Why do I think this matters? I just added some classical-music Works to MusicBrainz. I consulted Style/Work for guidance, didn’t see from that that Style/Classical/Work existed, and overlooked the consensus that Works which are movements of a parent Work should have the name of the Parent work as a prefix to the name of the movement. That’s in Style/Classical/Track/Title, but not in the Style/Work guide.
There was a discussion about (classical) work titles ages ago, and we never reached any consensus, so nothing got implemented. The proposal from back then was User:Symphonick/CSG Work Titles - MusicBrainz Wiki - there are quite a few things I disagree with in there, mind.
So for now all the work titling has mostly been “make sure the name is easy to recognise for other editors and hopefully all parts are consistent with each other and the parent” but doesn’t particularly mandate a specific title, because that was one of the big arguments back then: should we use the score name? (they’re often unwieldy and weird, especially for older stuff). Should we use the ur-text name? Should we use English, or the original title in the composer’s language, or the original name of the first publication, even if isn’t English nor the composer’s language? It’s all kinda tricky.
(Emphasis added.) I think a big problem is the word “a”, as if only one name is sufficient for a Work. Many things in our world have different names for different situations and different contexts.
The names “Mr DeLaHunt”, “Jim”, and “honey” all apply to me, in different contexts. Likewise, the names “Passio Domini Nostri J.C. Secundum Evangelistam Matthaeum”, “St. Matthew Passion”, and “Matthäus-Passion” all apply to work/45afb3b2. It’s not just “kinda tricky”, it’s impossible.
And yet. We have one Name field in a Work entity. Editors all over MusicBrainz find things to type in that field. And somehow the project advances. There is a wise statement in Symphonick’s draft: “just use the best source you can find. Titles can be corrected later.”
How about if Style/Work and Style/Classical/Work say that there is not agreement about exactly what to type in to the Name field, and here are a few of the “kinda tricky” issues, but “just use the best source you can find; titles can be corrected later”? Can we at least agree that guidelines like capitalisation, Style/Language, and putting the parent Work name as a prefix to a movement Work name are consensus?
Well, “use whatever you feel is right and it can be improved” is the standard in lack of a titles guideline, which is why I didn’t really add a guideline just for that
The caps/language bit is (but the language guidelines are already for all titles, nowhere does it specify it’s only for tracks or releases - if some place does, let me know because it should probably be changed!). The parent work thing is not a consensus as an end goal, as seen by the proposal I linked earlier - that wanted the work for a movement to have only the name of the movement and the parent work name to be inherited from the part-of relationship. I think everyone mostly agrees that with the current system the parent name should be kept, but some people (used to?) think that we should move towards a system where that wasn’t the case.
That said, I do agree a short work title guideline can be useful, so I might look into it once I have a bit of time (I’m traveling at the moment but I’ll be bored visiting family for a couple weeks soon!)
OK, I understand that. I suggest it’s better to say explicitly in the Style/Language that it applies to work names as well. The Work entity doesn’t have a “title”, it has a “name”, so it’s easy to miss that a guideline that applies to all “titles” applies to “names” as well. Better to be explicit, and provide an easy-to-follow cross-reference.
Count me among the people that would like something better as an end goal, but wants something pragmatic as the current guideline. MusicBrainz goals are so far beyond what the current system can accomplish, we will keep having to find a way to encourage pragmatic current practice while still leaving a path open to making the system better.
Excellent! If I can help, e.g. by contributing a first draft, I’m happy to do that. Let me know.
