[mb-style] RFC: Works lists (and other related changes then implied)

[Brian Schweitzer]

On Mon, Mar 3, 2008 at 4:03 AM, Lukáš Lalinský <lalinsky at gmail.com> wrote:
> On Ne, 2008-03-02 at 03:52 -0500, Brian Schweitzer wrote:
>  > Details:
>  > I propose that we add a NAT-like listing to the database for each
>  > artist (not just in classical), as was discussed yesterday,
>  > essentially using the exact same code that allows for NAT listings, to
>  > allow for works lists, until such time as NGS develops to a point
>  > where it obviates the need, when we can migrate those works lists to
>  > NGS work listings.
>
>  Frankly, I'd much rather spend a week or two on adding "something else
>  than tracks" (basically NGS works without attributes) to the database
>  and AR support for them, than abusing tracks for this. Having a special
>  release for non-album tracks is a hack, but having a special release for
>  hundreds of compositions would be, IMO, much uglier and unmanageable
>  hack.

I'd b open to any alternate suggestion for how you can see it
implemented, but I'm not sure I can yet see what you're describing.
Depending upon the artist, a list of all distinct works might be short
or large, but it's quite manageable, I think.  Subscribers see the
add-track edits to add a work to the list, and it'd be a pretty easy
script hack to add a lookup into the current artist's works listing,
to easily link tracks to works without lots of effort.  As I see NGS
eventually doing it, I imagine something similar, though with real
"work entities", not "tracks as works".  Either one, though, provides
a target point for the ARs, and allows the dual-naming structure,
allowing for both "liner titles" and "perfect guidelines" titles - the
track equivalent, now that I think of it, of ANV.

The only reason to even suggest it, though, is because it's easy,
reusing code already written to add at least  something functional,
even if it is a hack and there's little attention paid to making it
look pretty as implemented.  I'd much rather see even that week or two
that could be spent writing entirely new code and structure used to
pull off the real NGS.  But either way, I think we really have reached
a point where it's not that something like this would be nice, it's
really something the database needs, no matter how ugly and hackish
the initial implementation is, and not at whatever point that NGS is
accomplished, but something the database really does need asap.  It
solves a lot of the CSG issues, but outside of CSG, if you look at the
other guidelines about ARs, etc, there too it provides some real
solutions, where currently things can be kind of sticky.

Brian