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

[David K. Gasaway]

On 22 Mar 2008 at 18:12, Brian Schweitzer wrote:

> 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.  

They are multi-purpose but they are not all-purpose.  They are 
primarily used for social functions.  They are not designed to handle 
those problems best solved by a structured database.

> Please point me to the email which said all this.  

Let me be more be more clear: The links to the sample data I posted 
were a test for the ideas (suggested by Aaron) that the wiki pages 
could be used to address questions raised by me regarding translation, 
organization, and the like.  This was a test, nothing more.  I will 
note, however, that no one seemed to disagree at the time.

> 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.  

Adding a single link for each movement constitutes "a LOT of 
functionality"?  If the wiki server cannot handle the load (not that I 
see that there would be all that much), then the frequent editors can 
keep local copies.  I don't know a lot about MoinMoin or MB's 
particular implementation of it, but most wiki softwares have caching 
features to help reduce server load.  Or are you concerned about 
bandwidth?  Hopefully, this will not be required in the long term.

> * 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). 

This is all true.  But the wiki at least can have TOCs (in multiple 
orders), and cross references for the catalogs.  The work list, on the 
other hand, will seemingly be a flat, unindexed list with no well-
defined order (or, at least, an order that is not configurable).  I 
can't see how folksonomy tags could even solve this problem.  If you 
have ideas, I'd like to hear them.

> * 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? 

Possibly, but the idea was to take a CSGS page and translate it in 
whole to create another page complete with all the indexing features.

* 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.

If loading a CSGS page is really that burdonsome on the browser, we can 
divide it into multiple pages.  Will we have that option for the works 
list page?  How does executing tag searches on the server help vs. 
loading a work list or wiki page once?  However the idea behind 
"browseability" was to have the indexes available to navigate (great 
for more casual users) rather than resorting to searches.

> * 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.

I don't mean to suggest that the wiki is any better suited to this 
function.  However, if we do keep the wiki pages, they do seem to be a 
logical place to keep this information.

> Anyhow, even when making the first CSGS page, I recognized it was a
> problematic solution to use the wiki.  

I recognize that it is problematic, but I also recognize that this is 
only temporary until a better solution comes along.  For the quick 
test, I found the process bearable.  It may be too awkward to use to 
convert existing entries en-masse, this is true.  That goodess may have 
to wait?  Actually, I'm sure some enterprising folk (such as yourself) 
can find a way to make batch edits using a cached wiki page.

> 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.  

Somehow, I don't believe that the folksonomy tag solution as presented 
(which seems designed for elite classical editors) will magically cause 
most people to bother. ;)

> 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.  

I'm very sorry I missed it.  Was it brought up in the context of this 
RFC?

> 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.  

If you're talking strictly about custom client-side scripts, wouldn't 
it be reasonable to have the scripts operate on a local copy of the 
wiki pages?

-- 
-:-:- David K. Gasaway
-:-:- Email: dave at gasaway.org
-:-:- Web: dave.gasaway.org
-:-:- MusicBrainz: dkg