This is one issue that already came up on the first review of classical issues in 2014, and was brought up again by @Sophist recently. Currently, works are a flat list, and displayed as such. They aren’t exactly flat, in that works can be listed as part of other works, but right now that isn’t used for organisation at all.
Displaying works better based on that is something that was requested many years ago, and we should be able to improve that relatively soon. But without an extra level of detail that we currently miss, we wouldn’t know what to show in a work list, other than “the top level of the work relationships”.
This is not ideal, since it’d mean showing “Piano Sonatas, op. 2” on Beethoven’s work list instead of each sonata, which is what a user would expect, or showing “6 Gesänge, op. 34” on Mendelssohn’s list instead of the songs.
A suggestion that we’ve had is to have a field for the work “level” - something like “collection”/“main work”/“part”. Is this something that people thing would work? I’m sure there are plenty of edge cases waiting. I’ll offer the first: The overture for Mendelssohn’s Ein Sommernachtstraum, op. 61 was composed separately as its own work many years before it was included as the overture for the later work.
This is a complicated issue, and one I have given quite some thought to.
My first suggestion is that we define some attributes for MB Works to indicate whether they represent a (commonly used) main work (i.e. each Sonata), an overarching work (LvB Piano Sonatas, op. 2), a movement (of e.g. a symphony) an act/scene (of e.g. an opera), a piece (e.g. an aria in an operatic scene) etc.
At the moment MB works are at best hierarchical, but you cannot tell by looking at the hierarchy whether the work refers to an overarching work, a main work, a movement/act/scene or a piece. IMO, the hierarchy plus the above semantic attributes would give a full picture of the work and its parts.
The second question would be how to represent this in music media file tags - but a discussion on this is even more complicated and is perhaps best left until the first question has been discussed and consensus reached/
That could be the best option. Another option I’ve been considering is adding attributes (movement, part of collection, etc.) for current part-of-relationship. With these attributes relationship could easily describe what kind of part it is.
This sounds like an option, but it just sounds like it might be annoying to set all the attributes. But of course I assume there would be a @loujin script two days after this was added…
If we edit a symphony having 4 movements, it would be only 4 edits to get it fixed with relationship attributes. With work attributes it would be one edit more when we would need to set main work and then all the movements.
I would’ve thought that adding a boolean “is a collective work” attribute would be sufficient to achieve what you’re aiming for. Why would it be necessary to specify, using attributes, each work’s position in the hierarchy? Isn’t it just the top level that needs the extra detail?
Keeping the release and release-group model, works could be grouped somehow (as in the same opus, or the same work if we consider operas).
A work-group could even contain other work-groups (an opus of 3 sonatas, where each of them have 4 movements). The reason why the work is in a work-group could be defined by attributes (mouvement, number, … with an order maybe).
A recording (a track) could be linked to a work-group or a group.
I’m a bit concerned that we may be fixing the wrong thing here. MusicBrainz is well structured, but using that (e.g. in Picard) is harder. To get the work structure out, multiple XML lookups are needed. I have written a (draft) plugin to do this and will shortly be updating this to provide greater robustness and flexibility. To my mind, the first priority is to make use of the rich data already in MB rather than add to it with (possibly erroneous and certainly incomplete) semantic attributes. I would also far rather we found ways to get more complete data on releases, recordings and works than create additional input fields for editors to complete.
Naturally we all have different priorities but the issue we are talking about here is good way to start because it’s also quite easy to fix. It also improves the web service lookups when we could finally respond to simple questions like “how many acts does this opera have?” or “Is this a one movement symphony?”. I believe there’s multiple ways to improve the current web service to handle classical data but that’s another topic.
Adding new relationship types and attributes is kind of trivial thing to do and shouldn’t be compared to more complex changes to UI or web service. MB is more than a release catalog and not just a service to support file tagging. We should be able to store any kind of valuable and interesting music data. There’s quite little harm done with some new input fields when usually none of these are required to be filled or selected.
I agree, and the great thing about defining on the relationship rather than the work itself it is solves the problem of how to handle when a work is part of multiple works (the 4 season problems). When you have two levels of works they usually can be considered to map to the work/movement, the difficulty is when there are additional levels such as Operas it can be difficult to work out what each part actually is so it would be very useful if the type can be defined on the part of relationship.
I do find it a bit confusing that everything is considered a work in MusicBrainz, whether it is a single work linked to a song, a movement within a work, or the work that the movement is part of. Buts that okay I have got used to it.
Adding a “is a collective work” attribute doesn’t really help, that can be worked out by seeing if there is a ‘part of’ relationship but it doesnt describe the part of the work,
My concern was driven by the implication that (rightly or wrongly) I had read into Sophist’s paper - Picard Multi-level Work Tags - Discussion document v0.1 - Google Docs - that the additional attributes would be necessary for extraction by Picard of multi-level tags. If that is not what is intended then I have no problem with optional attributes, particularly enhancing the “part-of” relationship, and especially if it [quote=“ijabz, post:14, topic:293047”]
solves the problem of how to handle when a work is part of multiple works (the 4 season problems)
[/quote]
An example of a “collective” work is Beethoven’s Piano Sonatas, op. 2. This is a collection of three sonatas, the individual sonatas would be thought of as the “main” works, and what we would want to display on Beethoven’s Works page. The question is what is the best way to flag the over-arching/collective work so it can be treated separately to the “main” work/s. @reosarevok Perhaps just a new work type Collection or Set?
An option would be to have a different relationship than “part of”, “collected in” or something like that. A work type could also work, but it might be less obvious?
@reosarevok I am unclear whether you are suggesting it is implemented as a work attribute or a work-work relationship attribute.
My own vote would be that it is a work attribute, because being an overall work (opus) or a commonly known work or a movement relates to the MB work and not its relationship with other MB works.
I am also unclear exactly what attribute options would be made available. We should discuss and agree a list here before implementation.
Also, whilst it might be easy to implement these attributes for manual edits, there are a couple of other aspects which might take more time:
a. Ensuring that the attributes appear in the WS output (not only in /ws/2/work but also in other responses when works are included) so that Picard can make use of them. (This may already be automatic - apologies for my lack of knowledge of MBS internals.)
b. (More contentiously) a batch script which would try to initially populate the new attributes through parsing of work relationships and their work titles - automatically creating edits which would be subject to voting. Again, IMO it would be sensible to discuss the algorithm to be used here.
The point of my suggestion is that we can not only tell if it is a collective work, but also whether it is a formal movement or (for operas) an act or scene, or if it is a smaller part (a piece? a song?) like an aria which might form part of an operatic scene.
Having this information would not only round out the information about the work, but would enable statistical analysis across the classical genre, from the metadata and more informed and appropriate tagging of music files (so e.g a user could choose to tag a particular track not only with the piece name(s) but also choose whether to use the collective work or the commonly known main work as some sort of group tag).
@MetaTunes This is part of the confusion- whilst this discussion originated from a tagging perspective, the issue is really more about adding semantic information to MBS so that we are told what type of work it is and don’t have to guess from the title style.
Once you have this knowledge embedded in MBS, then you can decide what algorithm to use to tag files in e.g. Picard.
@ijabz Could you perhaps use the 4 seasons example and give us examples of how this would work on both the work-attributes and relationship-attributes options?
We could give it a go, I’ll look into implementing this in a few days to try it unless someone has some good reasons not to do it this way