I’m inclined to agree. This seems the simplest answer. The “work class” is a bit of a red herring because it is implied by the part-of attribute - but some discussion is required as to what values that might take (e.g. “movement of”, “Act of”, “part of collection”?). Work types should not include things like “Act” as proposed in
In fact, I think the discussion as to what goes in Work Type could be a separate matter.
I refer back to this previous comment which I agreed with at the time:
The work attribute already exists - Work Type.
Can we reset the discussion to this point and focus on the relationship attribute?
Yes - good idea - but only if there is consensus that relationship attributes are the way to go.
I can see that using relationship attributes are easier because you can change them in a single edit from either end of the relationship. My concern is that (in database design theory) you only want to hold common details about something once in order to avoid the possibility of two items which should have the same information actually holding different information.
What I am not yet clear about is whether an MB work could be e.g. a Movement of a one main work, and an Act of another - in which case relationship attributes are definitely the way to go. Or is a Movement always a Movement, in which case we need to decide whether we are happy to accept the possibility that in MB it is shown as a Movement in one relationship and an Act in another?
(MB is NOT a transactional business database - so perhaps these sorts of inconsistencies are acceptable as they can always be ironed out by another edit later.)
Another point in favour of Relationship attributes is that I think that they might be more obvious than a work attribute and so more likely to be populated. (Work Type is left blank fairly often.)
OTOH…
When you create a the fact that it is a Movement is intrinsic to the work, and so selecting that as part of the work creation should not be a major issue. After all, we currently put it in the work title through a structured style definition, an you cannot change that when editing a parent or child work.
I have no axe to grind here - I genuinely want the best overall solution for MB.
I am not sure whether there are grey areas about whether something goes in a Relationship attribute or the Work Type. As an example, the Overture of an Opera is not an Act or Scene, so do you have a Relationship attribute “is Overture of”/"has an Overture) or do you put Overture in the Work Type field and ise “is part of”/“has a part”?
So - to try to move things forward…
Is there consensus that Relationship attributes are the way to go?
What is the definitive list of relationship attributes we now need?
Should these be sub-attributes of “is a part of” or separate sibling attributes?
Do we need to consider Work Type in concert, or can we leave it until we have defined the Relationship Attributes we need?
This has 5 sub-parts, a Prelude and 4 Acts. If we use different work-work relationship attributes for the Prelude and the 4 Acts, then we still need to be able to sequence them as a group of 5. This may restrict the possible solutions using relationship attributes or even scotch it altogether if it would require significant code development (rather than being a STYLE change).
Perhaps someone knowledgeable could comment on this and confirm what constraints there might be.
That’s a good point. This is just an educated guess but most likely database schema isn’t limiting factor but only the current UI. It should be quite trivial to support ordering of the same relationship type (as a group) without caring about different attributes. No idea if this would need some changes to web service API.
The vast majority of the time, a movement/act/etc. is only associated with one main work; the graph formed by all the related works is a tree.
Exceptions that come to mind:
Symphony exists in multiple revisions, but the composer only revised the 1st and 4th movements. The 2nd and 3rd are shared between both revisions. In this case, the type (“movement”) is the same.
Composer takes parts of a ballet or opera and makes a concert/symphonic version of them. Sometimes those are different works (arrangements), but can probably be the exact same thing. Then the type would be different (“scene” or “overture” vs. “movement”). I can’t think of an example at the moment, though—all the ones I can think of are arrangements. Hard to believe it doesn’t exist, though.
It’d be interesting to look for works that are part-of more than one work… but I don’t have a MB database loaded into Postgres anywhere to try and run that query.
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.
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.
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.
@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?
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.
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.