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

Brian Schweitzer brian.brianschweitzer at gmail.com
Sun Mar 2 08:52:28 UTC 2008


Summary:
Proposal: Add pre-NGS works lists, change the intent of CSG, modify
the "version of " AR into an 'instance of' AR, and change the
suggested target point for the "cover of", "parody of", "version of",
and composition-related ARs.

Developer impact: According to Robert, minimal and pretty easy,
basically reuses code already written

Benefits: Both "sides" of CSG get what they want, and the database in
general gains the ability to begin this type of work long before it's
eventual "true" implementation under NGS.  It also solves some of the
AR issues we have generally, not just in classical, by providing a
true "generic instance".

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.

('work' here is used when 'movement' might be more correct, depending
on the particular work/movement being described within the list).

I further propose that CSG be then limited to those works lists, and
that classical releases now be listed using whatever is decided to be
the "on the liner" text.

I further propose that CSG then, in the rewrite, be aimed towards
comprehensiveness, not approachability, so as to allow for covering,
in as much depth as we think needed, any issues relating to
less-common or cat-corner issues.  As it will be solely then used by
editors working on classical works lists, it does not have a need then
to be a quick "how to title tracks" for classical, but it does then
have a strong need to be a guideline that even can cover cat-corners.

I further propose that a the "earliest version of" AR be changes to
"is an instance of", to allow tracks on releases to be linked to works
list entries, and that this AR include a numerical attribute - would
allowing 1 through 10 be sufficient? - to indicate the ordering of
instances, with a default value of 1.  Thus, in a particular
recording, Symphony No. 10: I. Allegro might have an attribute value
of 1, and Symphony No. 10: II. Andante might have an attribute value
of 2, indicating that, in that one track, both the Allegro work and
the Andante work are present, and that the Allegro work is first,
followed by the Andante work.  A new AR might be created, but as it
encompasses the entire point, plus some, of the "version of" AR, it's
perhaps better simply to rename and enhance the existing AR.

I further propose that work-based ARs be encouraged to be added to the
works list version, rather than the instance version, with the express
understanding that such ARs are *always* to be inheritable,
eliminating the "duplication of ARs" problem (at least for
non-specific performance ARs) that dmppanda pointed out several weeks
ago.

I further suggest that this then eliminates such issues as "no covers
for classical" by providing a true generic instance which can be used
as the target on the classical work's end of that AR, changes the
encouragement generally for the "parody of" and "cover of" ARs such
that those ARs then point to the works listing, and not any one track.

I further propose that such works listings ought to be strictly for a
single movement - no additional listings just for combo-tracks, as
they are handled by the instance of AR.

I further propose that such works listings should be the "complete"
form, such that any data relevant to required identifying a specific
version of a work, but not such data that would indicate a particular
recording of a work, be included.  So, "with clarinets" and "without
clarinets" would both be listed, as well, perhaps, as a generic form
(for when we don't know which specific version it is) not mentioning
clarinets, but such details as "(take 3)" would be left to releases,
and not tracks, as they indicate a particular recording, not a
particular work.

Brian



More information about the Musicbrainz-style mailing list