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

[Brian Schweitzer]

On Sat, Mar 22, 2008 at 2:48 AM, David K. Gasaway <dave at gasaway.org> wrote:
> On 5 Mar 2008 at 20:41, David K. Gasaway wrote:
>
>  > On 5 Mar 2008 at 0:15, Aaron Cooper wrote:
>  >
>  > > I've loaded Beethoven's first 6 opuses at
>  > > http://test.musicbrainz.org/release/8ffd2068-a872-49b4-80f8-c4ce0a0f1b
>  > > 19 .html
>
> >
>  > Did you already create a wiki page as well?
>
>  ..... I'll take that as a "no". ;)  I didn't want to mess with the
>  current CSGS/Beethoven page, so I copied Op.1/1 to another page, did a
>  quickie German translation, linked to the NAT list, and created track-
>  to-NAT ARs for one release.  Does this agree with everyone's vision
>  thus far?
>
>  http://wiki.musicbrainz.org/dkg/BeethovenWorkListTest
>  http://test.musicbrainz.org/release/d9765cac-9a4c-4d92-af95-
>  f25d1e05c0f5.html

Just a few thoughts...

I started in this same direction with the Mozart list.  But there's a
few problems, I think.

Personally, I think CompositionDate ought to be left as an AR for the
work - much easier to then inherit it to the tracks.  Where it's a
vague date, we can then leave it for a work annotation.  ("Spring
1786", "late 1821", "either December 1789 or January 1790").

In terms of the concept itself, I think that too is problematic.  The
wiki server is already having enough stress that the FullSearch macro
is currently disabled.  The Mozart page is, if I recall correctly,
around 2 mb, once it is rendered.  The JS Bach page can be expected to
be similarly large, with others - Beethoven and Vivaldi come to mind -
perhaps almost as large.  We really need to get all these lists off
the wiki server.  If we have them in the wiki, and we write a script
to make setting these ARs easy - be it a server script, or a
GreaseMonkey/UserJS script - we'll be pulling these lists all the
time.  That would, plain and simple, kill the wiki server.  It's just
not intended to serve out pages that large that frequently.

But Ido agree that we need some way to link the parts of works
together.  Using what we currently have (or will, once work lists
actually exist), why not instead use tags?  I did something a little
like this to link the various NATs within They Might Be Giants, simply
to try and bring some order to that (huge) NAT list:
http://musicbrainz.org/show/release/?mbid=c1828671-05bc-4855-9b47-b6e288798877

We could have tags like:
work-beethoven-op 1 no 1 - piano trio no. 1
work-beethoven-op 1 no 1 - piano trio no. 2
work-beethoven-symphony 5
work-beethoven-symphony 9
work-mozart-requiem kv 626
etc.

(This of course assumes works will be able to be tagged.)

Since one track can have multiple tags, we could even then have people
set up different languages or catalogues:
work-beethoven-symphony 5
work-beethoven-symphonie 5
work-beethoven-symphonia 5
work-wamozart-concerto for violin no 97 kv 120
work-wamozart-concerto for violin no 97 k6 285j
etc.

...or whatever tag format we decide on.  If we did do them all in a
single standard format, then we also can use the current tag lookup to
easily create scripted drop-downs to select the exact work:
http://musicbrainz.org/show/tag/?tag=nat-tmbg-cover&show=track

Could easily be something like:
http://musicbrainz.org/show/tag/?tag=work-wamozart-kv%20626&show=work
to pull up a list of all works tagged "kv 626" under W.A. Mozart.
Even for a client-side script, it'd then be quite easy to parse the
results page and form a drop down - and the main MB server is *much*
better equipped to handle a single request for a small subset of data
like this, compared to the wiki server being asked to return the
entire works page for a given composer, over and over again.

Since realistically, at least for classical composers, the majority of
the work to add works to work lists will likely be done by the
classical editors, and not editors who happen to simply be adding a
little classical to the database, just like we've talked of expecting
the work lists to be done in full CSG form, it doesn't seem to far a
stretch to also ask those editors to tag the works to a standard
format, to allow worklist lookups without requiring the wiki-server to
do anything...

Brian