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

[David K. Gasaway]

On 24 Mar 2008 at 22:08, Brian Schweitzer wrote:

> Asking any editor, average or not, to install an apache server simply to
> make a script work seems frankly crazy to me, when there's a much much
> simpler way that would allow for such a script to work and at the same
> time take a lot of load off the wiki server.

If we're talking about GreaseMonkey scripts, then the editor might just 
have to install Firefox, GreaseMonkey, and the scripts.  At that point, 
we're in unsanctioned power-user territory and nothing is too crazy.  
Officially, MB would have nothing to do with any of this, ever.  Point 
is, the wiki isn't the absolute crutch you make it out to be.  Ideal?  
Probably not, but it doesn't require any changes to MB.

> How is it polluting the UI to use tags for such a purpose?

Wrong.  I said I didn't want to pollute to the UI with *any* specific 
implementations related to the work list hack.

> Why is it not needed to have some functional way to make linking
> tracks to works actually something the normal editor might do?

What wouldn't a normal editor do?  Oh, that's right .. a normal editor 
wouldn't enter any ARs at all. :)

> Yup - yours is instead to have each editor install and maintain an
> apache server and local save copies of wikipages.  :D

Wrong.  I suggested it only for those editors that do a lot of edits 
that would benefit from it.

> You did?  Unless you're referencing the "polluting of the MB UI" - ie,
> that you simply don't like the idea, so you've insulted it rather than
> explain why you wouldn't like such functionality - then I clearly missed
> it.

I said that taking a kludge (which I think we've all admitted that this 
RFC is -- a temporary patch but a very good and very useful one) and 
extending it to more parts of the system than necessary is a bad thing. 
 That's an insult?  It wasn't about your implementation in particular.

> What are these additional benefits?  Looking at the wiki example you put
> up, I see notes (work annotations are better anyhow), composition dates
> (we already had talked about this and other similar info being in work
> ARs), and links to the works (which I'm suggesting would be better
> handled in a different way).  What are the additional benefits you see
> to wiki-tizing the listings, benefits which aren't already handled by
> existing mechanisms in a better manner?

I might suggest you look back in the thread history, as I've mentioned 
them numerous times already:  Having a list of works that is ordered, 
grouped, indexed, browsable, translated, and so on.  There had been 
some other passing attempts at addressing perhaps one of these without 
the wiki, but no detail.

> But why do you seem determined to make doing such linking as hard as
> absolutely possible?  Let's see:

Wrong.  As I said, the wiki stuff had *nothing to do* with UI scripts.  
In fact, the initial assumption coming into this RFC discussion was 
that there would be no special UI magic for the ARs, because there was 
nothing in the RFC about any of this.  Frederic suggested an idea that 
could exist and work independent of the RFC to help, and I have tested 
this idea at the links I posted.  I have no desire to make things 
difficult for anyone.

> your solution: 

Wrong.  Again, you're painting "my solution" as a solution to providing 
some extra UI sugar.  A) It's a solution to entirely different 
problems.  B) It's not even my solution.

> Ever noticed how few track-track ARs end up getting set?  Ever tried to
> link a remaster, track by track, with an earlier release?  It takes
> forever, for very little apparent benefit.

As I said, time might be better spent finding a proper solution that 
works for ARs in general, and not a hack that works for one specific 
AR.  If you want to expand this tag idea beyond the work list AR, 
another RFC is probably in order.

> If you think we need a way to group works, and I agree that would be a
> good thing, I'm not tied to the tags solution - but a wiki-based
> solution, with all the convolutions you've already had to cover just to
> make it even work in theory...  that solution is broken from the outset.

Wrong.  Anything I suggested about the possibility of using the wiki 
pages to build custom, unsanctioned scripts for frequent users has 
nothing to do with "convolutions [...] to make it work in theory".  It 
works in practice (as tested) without any convolutions.

> Sure - but let's say we make it simply work by pulling all works
> tagged to some catalogue number.  What are the chances someone is
> really going to take the time to pollute the works tables for some
> artist with "BWV 467" over and over again?

Does it matter what the likelyhood is?  The problem is using it for 
something it was not designed to do.  If the powers that be want to 
accept it for this purpose, then so be it, but I won't support it.

> Well, considering I wrote the first such page (ok, the second,
> counting panda's Sartre project :D), and helped design how the next few
> ought to be designed, and we always discussed specifically that the
> pages should be set up to support some form of scriptable structure, to
> make auto-accessing the lists possible (this was before we realized it
> would be a bad idea to actually implement that, from a server pov), then
> quite frankly, you have no idea what you're talking about.  If you're
> taking the existing pages and tweaking them, then you also inherit the
> design choices made for the existing pages - and right from the start,
> access to them via script was planned and very much part of the layout
> concept.

Obviously I can't speak to the purpose behind the original design of 
the pages (and don't presume to - I never mentioned the original intent 
of the CSGS pages).  Rather, I'm saying that the wiki pages were 
suggested as a solution to certain *new* problems inherent in the work 
list and RFC.  If you have ideas how to better solve those new 
problems, let's hear them.

> Problem 1) The pages are huge, and hard on the server.
> Problem 5) The pages are huge and hard to edit.

The size of the pages can be reduced.

> Problem 2) The pages are not at all obvious to the user.

Obviously.  But that can be improved by linking from the CSG pages, 
linking from the work list, artist annotations, etc.

> Problem 3) There's no way to link from a track to a particular entry in
> the wikilist. 
> Problem 4) There's no way to automatically update each and
> every instance of a work when that work is changed in the wikilist.

I don't know where you're going with these.  Problem (3) doesn't really 
seem to be a problem.  For (4), an update to the wiki wouldn't 
necessarily require an update the work list by design.  And tags don't 
seem to solve (4) any better (updating a work list item does not 
automatically update the tags or VV).

> Work lists then have 2 problems:
> Problem 1) Catalogue sorting is lost
> Problem 2) Work grouping is lost
> 
> So your solution is to take the lists back into the wiki.  Why?

Wrong.  Not my solution, but the best one I've heard so far.

> Why not, indeed,
> tag all movements in BWV 467 with "BWV 467"?  Quite simple, then, to
> access "all tags for JS Bach and for works and with a tag name of BWV
> 467".  Want a sorted list?  No problem - pull all tags for "JS Bach and
> work tags" - the list is already sorted, all BWV #'s will be sorted
> right there.  Want K1, K2, K3, K3a, and K6 catalogue numbers?  No
> problem, works can be tagged to each, and the "WA Mozart and work tags"
> list will have each set sorted.

I appreciate that you're finally at least trying to address these 
issues, which I brought up weeks ago in response to your original RFC.  
That said, some elaboration is needed.  Tell me how a user is going to 
perform these queries you suggest, how the user will know how to 
form/perform these queries, how these queries will have sorted results, 
how these these can be browsed and used without resorting to queries.  
At first blush, folksonomy tags all seems relatively weak in these 
areas compared to the wiki.

Keep in mind, as well, that in the end, one simple struture of any sort 
may not feasibly solve all problems in one fell swoop.  Thus, when all 
is said and done, I think we'll still be anxiously awaiting NGS.

> If it's indexing that you care about, you're still going to have
> the current problem in the wiki, unless you make a separate list for
> each index (WAMozart = 5 different indexes, Chopin = 4 different
> indexes, etc).

I didn't suggest a separate list for each index (though, obviously, you 
could provide multiple indexes of the same list).  Rather, I just said 
they would provide a cross reference.

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