I would consider act as a relationship-attribute because it’s a type of part (part of main work), not a type of work. I guess no one would search acts composed by Wagner. For me Collection is the only one that I might consider as a work type (which wouldn’t make it easier to define what a work type is in MB).
If I could select only one option I would create new relationship type. I would keep current “part of” for parts of main work and this new type could be used for linking so called main works to collections.
I’ve started to think that with collection it might also make sense to add work type for it. It’s usually the topmost type in the hierarchy and couldn’t have any other type. Sometimes collections were created by publishers but more often it is what artist intended. For example Beethoven’s sonata collections could be counted as “main works” which include “main works”. Would feel silly to leave this type of works without a type.
If people make searches based on a work type I could imagine them searching for collections. For example they might like to search for collections by Beethoven to find these sonata collections. Type could also be useful when filtering a list of works based on a type.
I hope I am not “talking past” people here. I genuinely do not have a specific implementation in mind - I just want us to make the best implementation. I am tring hard to understand other people’s alternative proposals and and weigh up their strengths and weaknesses, and if I am arguing against them I hope I am doing so on a logical basis.
Yes - sticking with Work Type not create somethng new just for the sake of it.
I don’t understand why you would want Act but not Movement or Scene.
There is a balance to be had between having a very uniform and simple approach which would need more mandatory data (which might at first sight be superfluous) but which makes machine understanding and applying algorithms easier, and a minimalist approach which keeps the additional data to a minimum but isn’t uniform and therefore is much more difficult for a machine algorithm to make sense of.
Making the Work Type field mandatory and giving the extra values needed to cover every eventuality and not doing anything new with work-work relationships would make machine understanding much easier than e.g. a mixed approach using work type and extra information in the relationships (whether a relationship attribute or a different type of work-work relationship) and where you have to infer that e.g. a sub-work of a collection is a main-work rather than be told explicitly it is a main-work.
This seems to me to prompt a question as to whether a work which is a collection should also be allowed to have a type i.e. a Collection of Sonatas, a Collection of Operas (e.g. Wagner’s Ring Cycle).
I agree that whatever we decide is most likely a compromise. Machine-readable data isn’t always that easily readable by humans, and vice versa. It’s important to remember that currently only humans are adding this data.
Work type is already hard to define in MusicBrainz. There’s types for poem and prose which aren’t directly related to music. There’s some musical forms. One special genre of opera. There’s soundtrack which is actually a type of recording. I could continue with this but you got the idea already. Now it’s proposed that we should make this field mandatory and add more options into this mess… Suddenly it wouldn’t be about work types anymore but we would also include type of (work) parts into same field.
I’m starting to repeat myself (and will stop after this) but there’s clearly 2 types of data: data related to (main) works and data related to parts. How is forcing 2 types of data into one field helping machine to understand it?
I don’t see this necessary. Human can (usually) instantly understand the content of the collection just by looking at the titles. Machine could easily check if all parts are by type [worktype] and then name the collection as “[worktype] Collection” if necessary. In some rare cases collections include multiple types.
It could be made mandatory for new works, and we could have a Bot which attempts to determine the correct type based on parsing the title and relationships and creates votable edits where it thinks it can set it correctly.
By this logic we should not have one type of work object but two. We would not IMO be forcing two types of data into one field - we would be using the field to hold whatever best describes the type of work.
Or we have Collection as a binary field separate from Type - but that would be equally awkward. I can probably live with this straightforward example of an algorithm (though more generally, laving algorithms to draw inferences is likely to result in e.g. different taggers implementing slightly (or even very) different algorithms and producing different results).
Is part of the issue here to do with what we actually mean by a “collection”? Examples:
Bach’s Well Tempered Clavier Books 1 and 2 are “works” in MB although some might argue that they are a collection - each prelude and fugue has a separate BWV no. The reason for calling them a work is that the collection was created as such by the composer.
Saint-Saens’s books of Bach Transcriptions are not recorded as works in MB so each transcription appears as an orphan - e.g. Work “Ouverture from Cantata, BWV 29” - MusicBrainz - although there is an arrangement relationship to the Bach work. However each of the two books of transcriptions were published during his lifetime with his active involvement (I believe). Maybe this is just an omission, but I would think that it is not that different from the first example.
On the other hand “Beethoven’s piano sonatas” is clearly just an arbitrary collection and not related to an original grouping either by the composer or publisher.
So what is “collection” intended to mean in this discussion?
The style guidelines say:
"Collections
Sometimes works are published in “collections”. This is common for songs and shorter instrumental pieces, but can also happen with larger works like piano sonatas. These works can be interesting to have as “containers”, but should not be treated as a main work with parts (for instance regarding Recording titles).
Note: In general you should only add a collection if the composer was involved. Do not enter things like “All piano sonatas by Beethoven” as works in MusicBrainz."
As a bit of a newbie, I still struggle to understand the intention of this (e.g my Bach and Saint-Saens example). Is the proposal that the new “collection” type (however implemented) would extend this meaning, or just implement it?
Extra values won’t help as long as only one value can be selected. And making fields mandatory decreases the chance of Works getting entered to begin with, or getting entered with wrong data instead of just missing data. Keep in mind that Works are not unique to classical music.
I’m not convinced that a new field (or re-purposing an existing one) is the answer to the question posed. Why not just list the top-level works for each composer and provide an “expand”/“expand all” type of functionality. A new field seems to raise more problems than it solves: IMHO any marginal benefit would be outweighed by the time required to maintain it - time that could be better spent increasing and improving the existing data.
In short:
Do we need more data? -Yes
Do we need better ways of viewing, searching and retrieving data - Yes
Do we need more data fields? - Not unless a strong case can be made
Do we need more mandatory fields? - Almost certainly not
I’d like to do exactly that, but without showing something like this work in that list, since it’s not a particularly relevant entry there, since it’s basically a few unrelated works grouped together for publication (as opposed to on a list of Handel’s opus numbers, where it’d be 100% relevant).
As a new contributor to this topic, I may well be misunderstanding some of the issues. However I have some comments on the structure of works and recordings.
Works:
Works in Musicbrainz terms are complex structures, and can already be structured in an hierarchical sense with the “Part of” relationship
To me it would be helpful if the top level represented the work as it is typically published/performed i.e “Piano sonata no. 2” rather than “Beethoven’s piano sonatas”. May be a “Series” should be used to show these higher level relations
Expand/contract functionality could help at all levels
If this is to work there need to be some guidelines, and management of them!
Recordings: I would find it very useful to be able to identify whether a release contains recordings of a whole work, or is a compilation. In a structural sense individual recordings can be both.
I have wondered whether it would be appropriate to use the “compile” relationship to create “Whole work recordings” - linked to “Whole work” works. This all seems a bit tedious however, but it is possible to envisage significant advantages when entering releases of whole works.
Another significant benefit would be that it would be possible to list whole work recordings, rather than the current situation, where they are hidden.
For this particular example, I would agree - Beethoven never wrote his Sonatas as a group, and a series might indeed be a better way to group them (if MBS allows you to use Series for works - I have only ever used them for Releases / Release Groups) . However as a counter example, Wagner did intend his Ring operas to be considered a collection.
Yes - I can see this. How about building a Work Type “guess” algorithm into the editor so that if they leave Work Type blank and the algorithm guesses from the format of the title and the relationships that it is e.g. a Sonata, then they are prompted with a “Are you sure you want to leave Work Type blank? This looks like a Sonata.”
I would like to see this implemented, whether it solves this topic’s problem or not. Either that or adding movement, act, scene, etc. to the list of work types, but I’m not sure it makes sense to say that a symphony movement is the same type of work as a sonata movement. Anyway, we should be able to store that information somewhere.
Typically, it does. The classicist 4-movement Symphony is a Sonata for orchestra, and with some predominating chamber constellations it is called – not titled, rather classified – as such (String Quartet). With instrumental solo to duet, the form Sonata is typically retained (Piano Sonata, Violin [and Piano] Sonata). I find it somewhat problematic having Work Types based on form and instrumentation both present and having to choose 1 if any.
There may well be a number of “works” like this where it might be considered preferable to pass over them in the hierarchy. However, they would seem to be the exception rather than the rule. Consequently, assuming some suitable way could be found to denote them, it would be entirely optional and would not create an additional effort for editors. Ideally the user could opt to include or “pass over” collections like this via a simple flag-setting. Whether it is worth the bother or not, I’m not sure. Perhaps if we have a “hierarchical” view implemented, it would be easier to decide the benefits of enhancements like this?
MB series work very well for collecting works - https://musicbrainz.org/series/1b6aec18-db22-4f91-98fb-2a5770183374 - an example where it is useful to collect works together, but are very unlikely to be performed as a whole. I agree that “The Ring Cycle” was conceived as a whole, and as a series of works (operas) rather than one opera.
I keep asking myself what are the user benefits of collecting works (movements) together to form whole works? I suspect that the aim of MB is not to provide a hierarchical work catalogue, but rather to collect them in a way which supports the release/recording metadata. e.g. when entering a release with a whole work, a sub screen could then be used to quickly match sub-works (movements) to tracks. Another benefit could be to enable reviewers to identify whole works versus movement compilations Once these objectives are clearer the mechanism to use is likely also to become clearer.
The universal lingua franca for music by providing a reliable and unambiguous form of music identification, enabling both people and machines to have meaningful conversations about music.
For this, it’s useful to have identifiers for both movements and parent works. It’s also useful to have catalogues of works, and all the info we can have about them. After all, if we only cared about works inasmuch as they are useful for releases, we wouldn’t care about storing information like score links, dedications, keys, etc
Sure, we want to let people quickly link the right works to their release of Beethoven’s Complete Piano Sonatas. We also want to be able to answer the questions “how many piano sonatas did Beethoven compose?”, “when did Beethoven compose his piano sonatas?”, “which is the most recorded Beethoven sonata?”, “what’s the average duration of each of Beethoven’s piano sonatas”, “who are the dedicatees of Beethoven’s piano sonatas”, etc. We’re not there yet, but those are all questions we should be able to answer eventually.
The universal lingua franca for music by providing a reliable and unambiguous form of music identification, enabling both people and machines to have meaningful conversations about music.
Thanks for putting me right on that - however it is very general, IMO objectives are more easily achieved if they are more specific (bearing in mind the overall mission).
Is there an overall diagram that models in an information sense the entities and relationships MB wants to support (not an entity relationship diagram used to implement databases) and their appropriate definitions. Such a diagram could form a very useful basis for these discussions Without the definitions the use of relations is potentially confusing e.g. “part of” and “series” appear to perform much the same information function
I agree that better documentation would be helpful, Often documentation falls behind functionality: I’m prepared to live with that in the MusicBrainz context, but it can be a bit frustrating for those of us not so much “in the know” as others. Regarding “part of” and “series”, I think it is fairly clear (to me unless someone tells me I’ve got it wrong ): a “part of” is part of a composed work, whereas a “series” is a (subsequently) compiled catalogue. That said, there seems still to be a bit of a grey area where a composer collaborated with a publisher in combining works to be released in a “book”. E.g. Saint-Saens’s 2 books of Bach piano transcriptions. My inclination is to call this “part of” but some consensus around these grey areas would be useful.
There may well be a number of “works” like this where it might be considered preferable to pass over them in the hierarchy. However, they would seem to be the exception rather than the rule. Consequently, assuming some suitable way could be found to denote them, it would be entirely optional and would not create an additional effort for editors. Ideally the user could opt to include or “pass over” collections like this via a simple flag-setting. Whether it is worth the bother or not, I’m not sure. Perhaps if we have a “hierarchical” view implemented, it would be easier to decide the benefits of enhancements like this?
): a “part of” is part of a composed work, whereas a “series” is a (subsequently) compiled catalogue. That said, there seems still to be a bit of a grey area where a composer collaborated with a publisher in combining works to be released in a “book”. E.g. Saint-Saens’s 2 books of Bach piano transcriptions. My inclination is to call this “part of” but some consensus around these grey areas would be useful.