Levels in the structure of works

MusicBrainz Classical
22

@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.

23

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.

24

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 :slight_smile:

1 Like
25

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
26

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.

27

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.

28

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
29

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.

30

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

31

Ah yes - it would do that which is useful for tagging, but does not really add much sematic information.

32

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
33

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
34

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
35

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.

36

There’s no need to reinvent the wheel. We already store data about work types (field “Type” when editing works). If people are interested to discuss about them I believe there’s some earlier topics on the forums.

3 Likes
37

Y[quote=“ListMyCDs.com, post:36, topic:293047”]
There’s no need to reinvent the wheel. We already store data about work types (field “Type” when editing works). If people are interested to discuss about them I believe there’s some earlier topics on the forums.
[/quote]

Yes - there is Work Type which can have the following values:

Song, Aria, Audio drama, Ballet, Beijing opera, Cantata, Concerto, Étude, Incidental music, Madrigal, Mass, Motet, Musical, Opera, Operetta, Oratorio, Overture, Partita, Play, Poem, Prose, Quartet, Sonata, Song-cycle, Soundtrack, Suite, Symphonic poem, Symphony, Zarzuela

The style guidelines say:

[quote]Work types should only be used on works that specifically match the chosen type (not every work needs to have a work type!).

  • Beethoven’s Sonata Pathétique is set to “Sonata”, but its first movement should not have a type, since it’s not itself a sonata (nor does it fit any other existing work type).
  • Schubert’s Winterreise is set to “Song-cycle”, while its first part, Gute Nacht is set to “Song”.
  • John Williams’ soundtrack for Star Wars, Episode V: The Empire Strikes Back is set to “Soundtrack”, but the Imperial March should not be.[/quote]

So, yes, this would seem to fit the bill EXCEPT that a main work does not have to have a type set, and so some main works (like e.g. Vivaldi, Les Quatre Saisons) cannot be identified as such from the Metadata. This is partly because the Type is optional (and without any prompt even if it has sub-works and no parent) and so is not entered in many cases, and partly because some Main Works don’t easily fit any of the types (like Vivaldi, Les Quatre Saisons).

So we will probably need to add to the list of values, and perhaps prompt for Type depending on the work-work relationships defined.

Ideally we might have an algorithmic bot create votable edits for works which appear to be main works and which do not have a type set and which we can determine the type from the existing title.

However, if we e.g. added Movement, Act, Scene, Piece, Main Work, Collection to the list of Work Types, I am then wondering why we would also need relationship-attributes?

38

If relationship with attribute tells that concertos are “part of collection” do you really need a work attribute for “collection”? Isn’t it already clear for everyone that it’s a collection?

If a work with no type set is having “movements” (relationships) isn’t it already clear that it’s a “main work”? All the necessary data could be found from relationship attributes.

3 Likes
39

I can’t find an example of a work which is part of two different works and whose type would be different in each context. Any examples I can think of tend to be be related as an arrangement (how would arrangements be treated in the proposed scheme?).
BTW a release I like to use as a good test - large and quite complex - is an oratorio, not an opera: https://musicbrainz.org/release/ec519fde-94ee-4812-9717-659d91be11d4

40

@ListMyCDs.com and @Sophist, I think you’re just talking past each other a bit. I assume when @Sophist mentioned types as work attributes he just meant keeping them as-is (for now at least), not moving them to be what we officially call work attributes :slight_smile:

Out of “Movement, Act, Scene, Piece, Main Work, Collection”, the only ones I could see belonging as a work type are Act and Collection. Everything else is too wide compared to the rest I’d say.

I’d expect the only difference we need to know between “piece” and “movement” is what their parent work is. So we could either add a Collection parent type, where every part of a Collection can be considered a separate piece (“main work”), or a relationship or relationship attribute to change “part of” to “collected in”.

41

So to deal with the specific problem of how to tell whether a top-level work is a “collection” or a “main work”; I think you’re proposing three options:

  1. Add a “Collection” work type and set “collection” works to this.
  2. Create an attribute that can be added to the “part of” relationship, I think it’s been suggested it be called “part of collection”.
  3. Create a new relationship, something like “collects/collected in”, and use this to link collections to main works, instead of what we do now: use the “part of” relationship.

I’d vote for 3, creating a new relationship. One reason: having a work type or attribute called “collection” or “part of collection” seems like very non-standard terminology to me, compared to more widely used terms like “symphony”, “act”, “sonata”, etc.
It is also for this reason that I think the new relationship should be called something more generic than “collects/collected in”, for example “includes/included in”.

Piano Sonatas, op. 2 includes Sonata for Piano no. 1
Sonata for Piano no. 1 is included in Piano Sonatas, op. 2

If we could first get consensus around a solution for this, we could then move on to @sophist’s more complicated proposal of adding semantic attributes such as “movement”, “act”, “scene”, etc.

2 Likes