[mb-style] [Clean up CSG] Capitalization (and placement)

[Brian Schweitzer]

> > I think, perhaps, you have a misunderstanding of what catalogue
> > numbers mean.
>
> I think I understand well enough.  For you, the term "work" has a very
> precise meaning that isn't necessarily universally shared.  Yes, there
> may be different works (using your definition) cataloged under a single
> Koechel number.  I know and accept this.  But I'm inclined to let
> authoritative scholars define what is or what is not considered an
> object fit to be labelled as a fully identifiable and distinct unit (by
> catalog number).  It's not the most precise system, but it draws a very
> clear and unambiguous line what to include in a track title.
> Otherwise, arguments such as this may continue ad infinitum.

This still has that same flaw in the theory though.  While a single
catalogue number does identify a fully identifiable work, it does not
identify a distinct unit.  It never was intended to identify one and
only one distinct work.  It identifies  a collection of works which
are all fully identifiable as variations upon the same work.

> > My point is that we quite ought to identify which of those things it
> > actually is, if we're really concerned about identifying the work, and
> > not just the general group the work belongs to.  As for me, I'd be quite
> > interested to know which recordings are of the version without clarinets
> > vs the version with the clarinets.
>
> Have I mentioned that _I want to identify the work_?  Yes, I think I
> have.  You still seem to misunderstand what I mean by this.  For
> example, I am interested to know whether a specific performance of K.
> 550 includes clarinets.  I would record this information in my
> FLAC/Vorbis tags.  I would like to record this information in
> MusicBrainz.  However, in my opinion, the track title is not the best
> place to do it.

Ok, but as we don't yet have the generic works system that would
support notations such as this which could be passed along to a tagger
or pulled out by someone using the datafeed, as it was put long ago in
the very beginnings of CSG:

"I'm personally of the opinion that for now, it really doesn't matter how
clunky the album/track titles become when dealing with these sorts of
releases if it can make later conversion easier."
http://lists.musicbrainz.org/pipermail/musicbrainz-users/2004-January/004381.html

So sure, you could tuck this into annotations.  But while annotations
are good and useful for things like where a track was recorded or
whether the sun was out or it was raining at the time, this isn't
that.  This is basic work identification.  Seriously, while I can
understand, if not agree, with the argument that a single Kochel
identification is enough, this is basic work identification.  It's as
simple as that.

You may not agree that classical is comparable to anything else, but
we have this issue everywhere in the database.  Pop Song (radio edit),
Jazz Song (take 4), etc - they're all the same principle.
Identification of the *actual work* being represented by the track
title, not just a vague "it's one of the versions of that work".

> As eager as I am to end this marathon debate, please permit me to take
> one final stab at it.  If we choose to record details such as "with
> clarinets" in the track title, these are the possible outcomes as I see
> it (assuming that the user has an intent to use the masterlists):
>
> 1) The editor knows exactly which version of the work was used for the
> performance, and selects the appropriate entry in the masterlist.
> 2) The editor does not know which version was used, abandons the
> masterlist, and builds the track title by hand.
> 3) The editor does not know which version was used, and randomly
> selects an entry in the masterlist.
> 4) The editor does not know which version was used, and abandons the
> edit altogether.
>
> The negative outcomes trouble me.  In (2) through (4), we end up
> animosity both towards MB and towards the masterlists, which were
> conceived to ease frustration, not cause it.  Outcome (2) results in
> track titles that are not consistent with the masterlist.  Outcome (3)
> results in a factually incorrect entry and invalidates the whole point
> of adding this extra information to the title.  In fact, it is very
> difficult to differentiate this negative outcome (3) from the positive
> outcome (1).  The downsides to (4) are obvious.

I think you're oversimplifying it.  Consider the current situation: we
ask editors to understand a very complex titling system and expect
them to enter titles correctly using that system - and of course,
noone does it right the first few tries.

Now consider, we're asking something entirely different: "We're gonna
give you the track title to use, we just want to know - in the liner,
does it say anything about this being the earlier version, or the
version without clarinets?"

It's gone from a very complex process to a yes/no.  If further
guidance is needed, it's the work of a single line of moin to add a
note "If your liner mentions..., it's this version, otherwise it's
quite likely the other version".  How is this so difficult?  It's
nowhere near as difficult as creating the CSG titles now, nor as
difficult as many other things we ask of people - identifying the
correct label, identifying the correct artist for jazz, etc.  If it
needs more documentation to make it an easy yes/no, that's doable -
but not an excuse for why we ought to just ignore the question and
pretend it's all just the same work.

> Imagine instead a system where this information is excluded from the
> track title.  The masterlist page would include documentation on the
> different versions of the work and ask the user, if able, to identify
> the precise work in the release annotation.  It could even provide the
> exact text to copy-paste into the release annotation.  Here are the
> possible outcomes from this proposal:
>
> 1) The editor knows exactly which version of the work was used for the
> performance, selects the appropriate entry in the masterlist, and
> follows the annotation guidance.
> 2) The editor does not know which version was used, selects the
> appropriate entry in the masterlist, and ignores the annotation.

Or, we give a single line of guidance such that the user knows what to
look for (variant versions essentially never are on budget releases,
and on the decent releases, are invariably noted as "~something
special here!~" in the liner), and either by its presence or its
absence know quite which listing to use.  Thus, situations 2, 3, and 4
all are negated by a single line of documentation.

If, on the other hand, we provide three options, as you seem to
suggest - adding one line that doesn't distinguish - realistically,
most people will just take the easy way and use that, rather than take
30 seconds to open the liner and check what it actually says.  Call me
a pessimist, but if we give that option, or if we only give that
listing and trust people to annotate the version, it just ain't gonna
happen.

Brian