[mb-style] CSG compromise?

Brian Schweitzer brian.brianschweitzer at gmail.com
Sat Mar 1 23:58:36 UTC 2008


On Sat, Mar 1, 2008 at 6:50 PM, Mike Morrison <mikemorr at umich.edu> wrote:
>
>  On Sat, 1 Mar 2008, Brian Schweitzer wrote:
>
> > There's one other problem, and I'm not sure either suggestion really
>  > solves it - what to do then when you have two or more works on the
>  > same track?  You could link them each as instances, but how does
>  > something trying to interpret that - the datafeed user or the tagger -
>  > make sense of it?  Not insurmountable, but definitely a question that
>  > would have to be addressed.
>  >
>  > Brian
>
>  I don't know about the datafeed, but it seems like the tagger could just
>  concatenate the two work titles and put a slash between them, and perhaps
>  eliminate any information which is doubled. So (perhaps not the most
>  likely example) if the first two movements of K. 37 were on the same
>  track, we would have
>
>  Concerto for Piano No. 1 in F major, K. 37: I. Allegro /
>  Concerto for Piano No. 1 in F major, K. 37: II. Andante
>
>  which would be shortened to:
>
>  Concerto for Piano No. 1 in F major, K. 37: I. Allegro / II. Andante

I was thinking something similar.  Though perhaps we'd want to "help"
the interpretation a bit, using something specific to identify that
"split point", as well as adding an attribute to the AR to indicate
which position the works ought to be ordered in?

Something like
Concerto for Piano No. 1 in F major, K. 37|| I. Allegro
Concerto for Piano No. 1 in F major, K. 37|| II. Andante

Then the interpreter needs only to know to replace the first || with a
comma, and on the second+ instances, if everything on the left of the
| matches in both/each, leave it out and split with the slash?
(Thinking here of the fact that we do have "super-works" and
"container sections (masses)" which also use the colon as the
container separator.

And using a positional attribute then allows the tagger to make sense
of which work is in which position - they're not always from the same
overall work, nor always in chronological order...

Brian



More information about the Musicbrainz-style mailing list