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

[Brian Schweitzer]

On Sun, Mar 30, 2008 at 10:50 PM, David K. Gasaway <dave at gasaway.org> wrote:
> On 30 Mar 2008 at 20:40, Brian Schweitzer wrote:
>
>  > * A single work title (with devolution of this for on-the-fly
>  > construction and translation, some time in the (far) future a
>  > possibility)
>
>  There was at one time an idea to use some defined character to separate
>  the work title from the movement title.  Is this idea still on the
>  table?

I'd suggested it when we were talking the NAT-type lists.  I wouldn't
take it off the table, but it does, then and now, sound like kind of a
hack.  Perhaps it would be possible to have 2 fields?  Nothing on the
level of complexity of a field for just about every possible type of
data, but just a "left side" "right side" type of field?  Most
non-classical might not use it, but I'm sure someone could think of an
example where it might be needed elsewhere.

>  > * At least one catalogue field, preferably able to be titled, but if
>  > field titling would cause works implementation to be delayed, that part
>  > can be skipped.
>
>  What will we do in those cases where no catalog is available?
>
>
>  > * In any listing of works, they ought to be sorted by the catalog
>  > field (if multiple fields are allowed, now or in the future, allow the
>  > user to select which one is used for sorting/grouping), then by the work
>  > title.
>
>  You've chosen the word "grouping" here, but I hope we all understand by
>  now that the problem is bigger than just how to make a single work or a
>  category of works group together.  For example, perhaps the catalog
>  field can be used to create a (or more than one) catalog index.  It
>  would be even more helpful if there could be an index by work type.
>  Then, if you have a CD of piano sonatas but only keys are listed, you
>  can jump to the piano sonata grouping with a click (like on the
>  CSGS/Mozart page).

Oh definitely, I would eventually want something like that - both from
the data use and the tagging points of view, it would be excellent to
have.  But I would think that the type of grouping starts to get too
far into the "a field for each part of the work", where sure it's
possible, but long term, not short term.  Would you agree?  Like I
said a long time back in the original RFP, I think works really is
something we need asap; if the levels of complexity that would be
required to do the type of breakdown you're describing mean it'll take
6 months of discussion to identify the fields, then maybe it gets
implemented a year from now, great, let's start that discussion - but
until then, we need at least some basic "work" functionality *now*.

>  > This would allow the cat # field(s) to be used for scripting.  Sorting
>  > by cat # first would also allow grouping right there.  (Perhaps we would
>  > also need some sort of group sequence field to sort on, instead of work
>  > title, for opera/etc).  This seems like it would solve both while also
>  > removing the need for any use of the wiki.
>
>  Do we need any special considerations to make the cat# field sortable
>  (like padding with zeros)?

I'd hope not, but I guess that would come down to whether python/perl
can sort properly without having them.

>  > What do you think?
>
>  Definitely an improvement. :)
>
>  I'm still very curious about the language question.  Are we choosing a
>  single language for each composer?  Or rather, a single list with only
>  one entry for each work (even if language changes from work to work)?

As we'd talked about originally, yes, I would think a single language,
but consistent within a listing.  We still don't have support for
multiple languages for track titles; this would seem at least on that
same level of complexity to implement - and regarding it being complex
to implement leading to it taking that much longer to implement, see
my comments above.  You said composer, but let me take it back to
"artist" - works is something that'll apply to any artist, not just
composer.  For non-classical, titles typically aren't translated
(except transliterations, etc), there I'd stick with the title in
whatever language it's in.  But within classical, yes, I would think
we would want consistency for the work listings within any given
composer; it's really not going to do those of us who want full
details much good if it also means I have one movement linked to a
work in French CSG, one linked to a work in English CSG, and one
linked to a movement in German CSG...

Brian