[mb-style] CSG compromise?

[Brian Schweitzer]

On Sat, Mar 1, 2008 at 5:10 PM, Mike Morrison <mikemorr at umich.edu> wrote:
>
>  On Sat, 1 Mar 2008, Brian Schweitzer wrote:
>  > the question is, what are we going to do until then?
>
>  For now, I think each track essentially needs two title fields: one for
>  the TrackCoverText, and one for the CSG title. So I'm basically splitting
>  the userbase into two groups and proposing a way to let each group use the
>  title it prefers, until NGS allows for more personalized customization. If
>  we can't agree on two titles, we could go for three (a liner title, a CSGS
>  title, and a middle-ground title), but I'm hoping it won't come to that.
>
>  Here's why I think each track needs two titles for now: If anyone is going
>  to want to use the TrackCoverText in the future, I think we have to
>  preserve it somewhere now. Same thing with CSG titles as work identifiers:
>  if anyone is going to want to link a track to a WorksDatabase entry in the
>  future, I think we should leave something attached to the track now to
>  facilitate that.
>
>  If we decide to give each track two titles, I see two options: we could
>  change the database structure to allow tracks to have two TrackTitle
>  fields, or we could use our existing database structure.
>
>  Here's one way I can think of to use the existing structure temporarily
>  until we have NGS. It's not ideal, because it misuses one of our existing
>  fields, but here goes. Please, anyone, suggest better ways of implementing
>  double track titles if you can think of them:
>
>  Very few of the releases I've come across make any use of the
>  TrackAnnotation field. Would it be feasible to appropriate this field for
>  the "second title field" and write a tagger plugin to use TrackAnnotations
>  as track titles? Then if someone wants to add a real track annotation,
>  they could use ReleaseAnnotations for now, with a note saying which track
>  they apply to.
>
>  Alternatively, we could put all of the secondary titles in the
>  ReleaseAnnotation field, and put in some standardized formatting
>  characters to allow a tagger to parse them into track titles.
>
>
>  > If we're aiming for "as on the liner", which liner, which translation,
>  > and what still gets fixed - caps, typos, mislisted works, etc?
>
>  These are not necessarily easy questions. I think they should be decided
>  by the folks who want their track titles "as on the liner". I think
>  whatever they come up with should go in one of the two title fields for
>  now, and eventually in the TrackCoverText field.
>
>
>  > If we're aiming for CSG, how complete, which languages
>
>  Again, not necessarily easy questions, but I hope the folks who do prefer
>  standardization can reach some agreement. Otherwise we will need three
>  titles instead of two! The standardized work title would go in one of the
>  two title fields for now, and eventually in the WorksDatabase.
>
>
>  > and are we essentially admitting that classical track titles per liners
>  > are descriptions and not "titles" per say?
>
>  To me, yes.
>  For the TrackCoverText, no.
>  For the interim CSG titles, yes, I think.
>  For the eventual WorksDatabase, yes.
>
>
>  > Where can we all compromise such that the (I think majority) who wants
>  > at least some structure in the titles isn't left waiting 1-2 years for
>  > NGS to replace CSG, plus all the quite likely years of editing work to
>  > actually implement it across our classical listings?
>
>  My hope is that a choice of two titles for each track will be enough to
>  satisfy everyone in the interim.

While I agree that it does seem two track titles are needed, I think
annotations are perhaps not the best way to go.  I've worked on a few
releases where I was leaving annotation notes in each track, and to be
quite honest, if we decided to put CSG-style track titles in
annotations, I can't see even myself bothering to normally do it, let
alone your average editor who happens to be adding a classical release
every so often.  It's also, as you note and as I mentioned in IRC,
essentially blocking one or the other annotation fields from being
used for the purpose those fields really are intended for.

But another possibility occurs to me, an option that actually would be
closer to NGS, would avoid the need for mega-lists in the wiki, and
would allow for annotations to not only not be blocked on the
releases/tracks, but actually, would allow for notes on a work-level,
like some of the notes I've attached around listings in the Mozart
list, to help ID exactly which one is desired.  It would also map
quite well, I think, to an eventual NGS implementation.

While there's perhaps some few 20th century classical composers
someone might be able to point to, one thing classical composer
generally have in common is that they didn't actually release LPs or
CDs - or NATs.  Perhaps it'd be simple to create a NAT-type of list
for use for works lists, I don't really know.  That would seem most
optimal.  But lacking that, could we not just use the NAT entry for
each classical composer to hold the works lists?  Create a new AR,
something like "is an instance of" to link release tracks to the NAT
tracks, store the CSG-style names in NATs and whatever the
liner-liking people like in the releases?  I'd think it'd be pretty
easy then to add an option to Picard/datafeed users/etc to allow them
to travel up to that NAT to get the CSG title.  Then we also can more
easily use the normal editing system, as well, to vet
corrections/changes within the NAT-work lists, with the goal of those
work lists being to make them the "complete" tiles.  When NGS comes
around, all the links and such already will be in place, we just
migrate them from the NAT listed track to a NGS entry for that work,
and (perhaps in some automated fashion which says "this NGS entry is
specifically the NAT entry we had over here") migrate those
work-instance links over to NGS?

It would allow the dual track titles, it would satisfy both types of
data users, it would allow us now to start really working on
correcting noted typos and errors in work lists, and it would allow
us, likely 1-2 years ahead of time, to already start working on
linking instances back to work-masters.

Brian