Just want to point out that confusions could arise if Collection or Collected In is used.
There are many books of scores, tunes,songs etc which are titled along the lines of A Collection of English Ballads.
A sonata might be Collected In an Opus and in A Collection of Beethoven’s Piano Sonatas.
A new user of MB might have another hurdle to crash into.
We need to close this discussion off and make some kind of decision.
Can someone who understands the nuances please summarise the options and their pros and cons so we can have a poll about them?
So was I 
Give me a few more days and I’ll get something written - I’m starting uni this week again so it’s a bit hectic, but I’m trying to cut down on time spent editing so I have more time for actual style issues.
One thing I made sure with @yvanzo earlier is that adding attributes might break ordering as it is now, but that a normal code change (not a schema change) should be all that’s needed to avoid that breakage.
2 Likes
Another exception are Milhaud’s string quartets 14—5, ad lib performed simultaneously as octet; all 3 works sharing opus number 291.
So! What I’d propose as a first attempt at this (to be improved in the future if necessary):
No new work types as part of this change (more work types should be added in the future, but not for “what kind of part something is” - just for “what kind of thing this part is”).
A few new attributes should be added to the “part of” relationship:
-
Collection (Y part of collection: X, X collects: Y): wording could be changed but basically this would represent a case where the “parent work” is not necessarily meant to be performed as a set. For example, Brahms’ collection of 5 songs, op. 72, or Debussy’s second book of preludes, or Beethoven’s 3 piano sonatas, op. 10. Parts of a collection can still be ordered/numbered (and often are!) - it just doesn’t necessarily refer to the required performance order.
-
Movement (Y movement of: X, X has movement: Y): a case where the parent work consists of several parts, which are generally meant to be performed one after another in a particular order. For stuff like Stockhausen’s Tierkreis or other (mostly contemporary) works were all the parts (or a specific number of them) should be played in a different order each time, I’d suggest not using “movement”, but sticking to a more generic “part” relationship.
-
Act (Y act of: X, X has act: Y): for operas and similar works, in order to make it possible to know how many acts an opera has; this is often desirable information, but it’s hard for a machine to tell as it is since they’ll often also have other parts like overtures and entr’actes/intermezzos.
-
Number (Y number of: X, X has number: Y): for operas and similar works that are separated in numbers. It would allow us to store the information about the numbers defined by the composers, even if there are (for example) spoken segments in between (like in Mozart’s Singspiel “Die Entführung aus dem Serail”).
If we see this approach works well, we might want to add other attributes for other uses, but this seems to be a small but useful starting set.
5 Likes
These all look good to me. These attributes seem to cover majority of the potential usage cases.
I agree with this. Better to see how well it works and get some feedback if more types are necessary.
1 Like
@reosarevok: Thanks for summarising this - it looks good to me too. A couple of points:
a. Do we also need:
- Scene (Y scene of: X, X has scene: Y): for operas, musical theatre and similar works, in order to make it possible to know how many scenes an act in an opera has; this is often desirable information, but it’s hard for a machine to tell as it is since they’ll often also have other parts like overtures and entr’actes/intermezzos.
b. How will numbering of Movement, Act, Scene and Number relationships work, and will it be possible to sequence all relationships so we see e.g.
* Overture
1 Act I
2 Act 2
Ideally the web UI would show the hierarchy e.g.
* Overture
1 Act I
1.1 Act I Scene 1
1.1.1 Duet x
1.1.2 Aria y
1.2 Act I Scene 2
2 Act II
2.1 Act II Scene 1
2.2 Act II Scene 2
c. Do we have any idea how these changes will look in both the web pages for Works and Releases, and also in the works XML?
Thanks.
S
P.S. How easy is it to get the upwards works hierarchy into the XML so you Picard doesn’t need to make recursive calls to get the parents layer by layer?
From CSG / Works: "In opera, “scenes” are instructions about who appears on stage (e.g. “Don Giovanni. Zerlina”), and/or what should take place (e.g. “Kurwenal enters boisterously through the curtains”). A scene is not an independent work in an opera. Furthermore, scenes can change completely independent of the music, sometimes several times during a single number. In general you should not create “scene works” as a container for numbers. "
Our work guidelines specifically say not to use scenes as works for operas (it’s different for ballets though, and it might make sense to add that for ballets in the future).
We should be able to order all the relationships in the same way as now - might require a small code change but it shouldn’t be too hard.
Agreed, but that I can’t promise just yet 
I’d want them to look pretty much the same as now at first, with any changes we decide we want while testing the stuff coming after that. So attributes would be shown in the pages after or before each part (ideally in a way in which they won’t break the parts list display, which again might require some coding work) and they would be shown as part of the attribute list in the XML like for member-of here).
Honestly, you might have a better idea than I do at this point - I haven’t really tried to use works much in the WS.
1 Like
Is this also true of Musical Theatre?
Ok - so let’s include it for Ballets now then.
I like most of that, but do we need different attributes for movement/act/scene? Some way to differentiate them from collections as meant to be played together, definitely, but it seems to me like we can just say “Y is inherently part of: X” and let the work type specify which of the three it is. Or am I just resurrecting the earlier debate by saying that?
This. We need attributes to specify the type of part because it’s not clear based on the type of the work. For example without it you can’t tell if a part of opera is an act or an actual opera piece. Using relationship attributes is the most logical solution when we try to indicate the type of relationship between two works.
Could I just clarify re the XML. Does the
<relation ... type="parts">
remain, but with the addition of something like
<attribute-list>
<attribute>collection</attribute>
</attribute-list>
?
In other words any existing XML lookups using the parts type will still work?
Yup, that’s how this should work.
I don’t understand the definitions of Collection and Movement, especially Movement:
This would apply to just about every multi-part work, wouldn’t it?
Determining when to use (and not to use) Act and Number would be less trouble since these are usually already included in the work title.
Probably does apply to just about every one. At least symphonies, concertos, etc. I think “movement” will be by far the most common one.
@reosarevok BTW, in your list of options, which would use use for Wagner’s Ring? It’s odd to call the four operas “movements”, but that seems match the definition given. I suppose we can continue to use the generic part/part of for things that don’t fit?
I would expect to just use “part of” for everything which isn’t really anything of the others, yes (and I’d expect it to be used quite often). More options can always be added in the future if we see a need.