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?
1 Like
@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?
@MetaTunes When it comes to tagging, there are two types of tagging you can do:
a. Level-tagging - where you simply add tags for every level upwards in the work hierarchy; (your plugin already does this - the only enhancement that would be useful would be for MB to give all the ancestors in the work WS response and avoid the need for additional, multiple, ws calls to get it)
and
b. Semantic-tagging - where you have e.g. a tag for the track work and a tag for the overall work - without semantic knowledge in the MB database, you cannot achieve this except by guesswork from the relationships and their titles - and guesses are often wrong.
Ill do this when I can
What do you mean by work-attributes, work type ?
My point was that isnt wasn’t possible with just work type, you needed part of type.
I like the idea of using a different relationship. With two different relationship types, it may be easier to accommodate tricky cases like Mendelssohn’s opus 21 & 61, as opposed to using a work type. Another option for the name could be “included in”, I like the symmetry with the RG-RG relationship of that name 
1 Like
We do, of course, need to be specific and precise about what we want before we start implementation, and I am not clear about either of these? Hence my request for an example.
Don’t worry if you don’t know what the names and values should be - feel free to make them up as a straw-man as this will move the discussion forward.
1 Like
Maybe this was not the best example since in both cases we have concertos that are part of a group of concertos, but anyway
Currently have:
Concerto in E major, op. 8 no. 1, RV 269 “La primavera”: I. Allegro https://musicbrainz.org/work/3f62d0d8-8ccd-31ab-bfca-768a1ae5708d is one of three parts of “la Primvera” and has default type Work
https://musicbrainz.org/work/0d2a5e67-8efc-3233-9ac9-f4be8644be14 Concerto in E major, op. 8 no. 1, RV 269 “La primavera” has work Type Concerto
and is part of The Four Seasons - https://musicbrainz.org/work/87886dcf-9776-49cb-b6f5-10104da6e42c and just has default work type of Work
It is also part of Il cimento dell’armonia e dell’inventione https://musicbrainz.org/work/7044d543-9f9d-4598-8ee7-0f9945d28595 which also has default work type Work
Proposed
Where we have to set Work type to just Work it implies we are usually missing something, I would think
The Four Seasons & Il cimento dell’armonia e dell’inventione should both have Work Type of “Group” unless there is special word for "Group of Concertos"
Part Type for “La Primevera” to “Il cimento dell’armonia e dell’inventione” would be "Part of Group"
Part Type for “La Primevera” to “The Four Seasons” would be “Part of Group”
and maybe an additional flag to say ‘primary’ if one relationship could be considerd the primary one.
For Concerto in E major, op. 8 no. 1, RV 269 “La primavera”: I. Allegro we could say Work Type is Movement, but if there are cases where a piece of music could be standalone or a movement in a work then would be better for Part Type to be Movement
I havent got an example, but maybe you have a piece of music that is both part of an Opera, and part of something else and known differently depending on what they are part of.
This seems to be a work-attribute example. However…
The missing example at the end has helped me see why a relationship-based model might possibly be better - because it would allow a work to have several different types, though I am unclear whether there are actually such examples, and if there are whether it would make more sense to think of them as separate arrangements of the same work.
However, I think that relationship-attributes have a fundamental flaw.They would either need to have attributes for both ends of the relationship, in which case you can easily get conflicts between relationships saying different things about the same work - OR they would only describe e.g. the lower end of the relationship in which case you will have one less attribute than the number of works. Based on this, I think we should stop considering relationship attributes as a solution and focus on work attributes.
Taking this example as a basis, my proposal would be as follows:
Concerto in E major, op. 8 no. 1, RV 269 “La primavera”: I. Allegro
TYPE: Movement
is part of:
Concerto in E major, op. 8 no. 1, RV 269 “La primavera”
TYPE: Not sure - it is not really a complete work (as commonly understood) itself, because it is really part of “4 Seasons”. I guess this demonstrates the difficulties of getting this right. Perhaps the suggestion of Concerto is a good idea, but then what do you call the parent(s), and how many alternatives do you need (Symphony, Opera are obvious other values, but I suspect you will still need a catch-all for music which doesn’t fit.)
is part of TWO higher level works:
Le quattro stagioni (“The Four Seasons”)
Type: Main Work
and:
Il cimento dell’armonia e dell’inventione, op. 8
Type: Main Work
Perhaps Wagner Ring Cycle would be another useful example, in part because of the number of levels of work it has.
Why is that? What it’s describing is the relationship between the two works: “this is collected in this work” or “this is a movement of this work” (which is bidirectional, since that automatically means “this work is a collection including this one” and “this work has this movement”)
2 Likes
My belief is that the point of semantic attributes is to classify the type of work - is it a piece/movement/scene/act/main work (which could be sub-classified into Opera, Symphony, Concerto, Musical Theatre, etc.)/Collection. If this is the objective, I still don’t see how relationship attributes will work.
But if the point is only to say whether it is a collection or not, then I do not see how saying a higher level work (which has several child works) is a “collection” actually adds anything to the hierarchical work-work relationships we already have.
It allows the end user to know whether they should skip it if they’re only interested in the “main” work, rather than any higher “collection” levels
Ah yes - it would do that which is useful for tagging, but does not really add much sematic information.
Work attributes wouldn’t work that well with the current UI. For example on MB website you could see concerto with 3 parts but to know what kind of parts you would need to open pages for them and look at the right top corner to see attributes. With relationship attributes this data would be available like other relationships on the same page. Similar situation with webservice, you either make one query (relationships) or 4 queries (work attributes) to get exactly same information.
Similar situation with editing. To edit all necessary types for 3 movement concerto you would need to open 4 separate pages and edit all these works/attributes separately. You could edit all the relationship attributes from the same page.
In MB relationship defines that there’s some sort of relationship between two entities. Relationship attributes define what kind of relationship is. There’s a “part of” relationship already available but we are still discussing if something which is clearly an attribute of it should be stored to some other place. Part, act or movement are always somehow related to another entity/work. There isn’t just “part of something” without that “something”. When we store data about relationships between entities we should use… relationships.
2 Likes
I agree with this, relationship attributes are the way to go.
The way I see it is:
A work type = concerto, sonata, aria, etc.
A part type = movement, act, number, etc.
A work type provides information about a work. It’s stored on the entity level.
A part type provides information about a work’s relation to another work. It’s relational information, it makes sense to store it as part of a relationship.
8 Likes
So actually we are saying we need both Work and Relationship attributes. A work attribute to hold Symphony, Concerto,Opera, Aria etc.) and a relationship attribute e…g. “has a movement”/“is a movement of”, “has an act”/“is an act of”, “has a piece”/“is a piece of”, “has a collection part”/“is a part of collection” etc.
Do people agree with this? If so, we should perhaps move onto creating a definitive list of work and relationship attributes.
1 Like
I think this is the right answer.
I think a few more complex examples would be a good idea to check it out - I’ll have a hunt around.