[mb-style] CSG compromise?

[Brian Schweitzer]

On Sat, Mar 1, 2008 at 6:13 PM, Aaron Cooper <cooperaa at gmail.com> wrote:
>
> On 1-Mar-08, at 5:56 PM, Mike Morrison wrote:
>
>  >
>  > On Sat, 1 Mar 2008, Brian Schweitzer wrote:
>  > <snip>
>  >> 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
>  >
>  > I like this!
>
>  I don't think it's a bad idea either, but I'm generally not a fan of
>  NATs.  Just throwing the idea out there... what about creating an
>  album for each work?  Example:
>
>  Release Title: Trio for Piano, Violin, and Cello No. 1 in E-flat
>  major, Op. 1 No. 1
>  #1 Track Title: I. Allegro
>  #2 Track Title: II. Adagio cantabile
>  #3 Track Title: III. Scherzo
>  #4 Track Title: IV. Finale. Presto
>
>  If we wanted ordered lists based on catalog number we could enter the
>  release title as something like "Op. 1 No. 1: Trio for Piano, Violin,
>  and Cello No. 1 in E-flat major".
>
>  Thoughts?

I think the dangers of creating a separate album listing for each work would be:

* People actually tagging to those "releases" / submitting TRMs/PUIDs for them
* Massive swelling of the apparent discography listings for the composers
* You then have to actually load that entire composer's discography to
find the ones you want (already 1500+ listings for JS Bach and WA
Mozart), rather than just the NAT listing for the artist (which, iirc,
is already linked from within the artist title bar on each release)
* lots of single-track "releases" for one-movement works

Perhaps such subdivision might be best left to the real NGS, rather
than further trying to stretch it to fit a non-NGS situation?

There's one other problem, and I'm not sure either suggestion really
solves it - what to do then when you have two or more works on the
same track?  You could link them each as instances, but how does
something trying to interpret that - the datafeed user or the tagger -
make sense of it?  Not insurmountable, but definitely a question that
would have to be addressed.

Brian