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

[Brian Schweitzer]

On Sat, Mar 22, 2008 at 2:47 PM, David K. Gasaway <dave at gasaway.org> wrote:
> On 22 Mar 2008 at 3:58, Brian Schweitzer wrote:
>
>  > 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.
>
>  This is the first I've heard of trying to script a search of the wiki
>  page.  I wouldn't support such a thing.  But then again, I don't
>  understand why it would be necessary.  In the discussion leading to
>  this test, it was proposed that the wiki pages would remain available
>  to organize the work lists (for browsability and lookup), provide
>  translations for the non-English users, provide multi-catalog
>  references, and store miscellaneous notes about the works.  You would
>  like to roll all of these functions into the folksonomy tags?
>
>
>  > Using what we currently have (or will, once work lists
>  > actually exist), why not instead use tags?
>
>  Sorry, I can't support using the *folksonomy* tags for anything other
>  than *folksonomy*.
>
>  I feel we should simply accept the ugly wrinkles of this hack (such as
>  manual lookup in the CSGS page or work list) and not expend any effort
>  polluting the UI with additional ugly hacks to make our lives a little
>  easier.  These features will have to wait until NGS.

Considering that folksonomy tags have no single purpose, and are
intended to be a multi-use field, I don't know what you're objecting
to here.  Tags aren't just for genres; Double check even just some of
the suggested uses in http://wiki.musicbrainz.org/FolksonomyTagging ,
plus the uses being put to it for series.  Or we could check
Wikipedia, http://en.wikipedia.org/wiki/Folksonomy , which has
"Folksonomy (also known as collaborative tagging, social
classification, social indexing, and social tagging) is the practice
and method of collaboratively creating and managing tags to annotate
and categorize content."  Isn't that pretty much *exactly* what we're
talking about here?  Categorizing work movements into works?

To bring this part in out of order now:

>  understand why it would be necessary.  In the discussion leading to
>  this test, it was proposed that the wiki pages would remain available
>  to organize the work lists (for browsability and lookup), provide
>  translations for the non-English users, provide multi-catalog
>  references, and store miscellaneous notes about the works.  You would

Please point me to the email which said all this.  Yes, it was
mentioned that annotations and such should be available for work
lists.  Yes Aaron said something about using the wiki.  But you're
adding in a LOT of functionality to the wiki, and ignoring the point
that the wiki server can not handle these pages, long term.  Just to
address them point by point:
* organization: the wiki format limits this to strictly a single
organization order; all other possible methods then still miss out
(sorting by different catalogs, etc).
* translations: Again, simply too much data to be well organized in a
basic table, or to be useable.  Could you not also store these in work
annotations?
* browseability: Loading a 2 meg (or 3 or 4, potentially, if you're
also doing translations) page that consists almost entirely of HTML
tables, vs loading a works list and navigating either by movements or
work tags?  Neither is perfect, but the former is simply too much, for
either the server or the browser - some browsers already find the
Mozart page too large to load, and it can take my own machine 30
seconds to even render.
* store miscellaneous notes: Sounds perfect for a work annotation,
much less so (I know from experience trying to cleanly integrate them
on the Mozart page) mixed into a table format in the wiki.

Anyhow, even when making the first CSGS page, I recognized it was a
problematic solution to use the wiki.  We now will have tracks and
works.  But if we use tags, we can create scripts to link them rather
easily, ala luks' much-improved AR script now.  And we will want a
script to do so, whoever ends up writing it; doing track-track ARs is
otherwise so very very slow that most people won't ever bother to link
to works.  You may never have heard of anyone wanting to write such a
script, for wiki or otherwise, but it was discussed on the page notes
for the Bach page way back when that page was first started and it was
discussed in at least one of the CSG threads here.  At least once a
week someone sends me an email asking for me to write a script to pull
CSGS/M track titles from the wiki to make adding Mozart releases
faster.  I'm not willing - it would cripple the wiki server.  But we
do want to do this in a way that allows for easy work-linking, without
the crippling of the wiki server.

Brian