# Levels in the structure of works

**URL:** https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047
**Category:** Classical
**Tags:** works
**Created:** [June 26, 2017, 7:13pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047 "2017-06-26T19:13:07Z")
**Posts on this page:** 20
**Page:** 2

<div class="post-metadata">

### Author: ![Sophist](https://community.metabrainz.org/user_avatar/community.metabrainz.org/sophist/32/70055_2.png) [@Sophist](https://community.metabrainz.org/u/Sophist)
#### Post date: [June 29, 2017, 12:48pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/22 "2017-06-29T12:48:26Z")

</div>

> [@MetaTunes](#):
>
> 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](https://docs.google.com/document/d/1egx67PQ34aWvcKFmcYZtPQJlwEdmzuEmuxxFhtHaLyM/edit) - 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

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

---

<div class="post-metadata">

### Author: ![ijabz](https://community.metabrainz.org/user_avatar/community.metabrainz.org/ijabz/32/7784_2.png) [@ijabz](https://community.metabrainz.org/u/ijabz)
#### Post date: [June 29, 2017, 1:02pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/23 "2017-06-29T13:02:33Z")

</div>

> [@Sophist](#):
>
> @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?

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

---

<div class="post-metadata">

### Author: ![Kid\_Devine](https://community.metabrainz.org/user_avatar/community.metabrainz.org/kid_devine/32/17561_2.png) [@Kid\_Devine](https://community.metabrainz.org/u/Kid_Devine)
#### Post date: [June 29, 2017, 1:45pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/24 "2017-06-29T13:45:22Z")

</div>

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](https://musicbrainz.org/relationship/589447ea-be2c-46cc-b9e9-469e1d06e18a) of that name 🙂

---

<div class="post-metadata">

### Author: ![Sophist](https://community.metabrainz.org/user_avatar/community.metabrainz.org/sophist/32/70055_2.png) [@Sophist](https://community.metabrainz.org/u/Sophist)
#### Post date: [June 29, 2017, 1:47pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/25 "2017-06-29T13:47:13Z")

</div>

> [@ijabz](#):
>
> 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.

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.

---

<div class="post-metadata">

### Author: ![ijabz](https://community.metabrainz.org/user_avatar/community.metabrainz.org/ijabz/32/7784_2.png) [@ijabz](https://community.metabrainz.org/u/ijabz)
#### Post date: [June 29, 2017, 7:13pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/26 "2017-06-29T19:13:52Z")

</div>

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 [Work “Concerto in E major, op. 8 no. 1, RV 269 “La primavera”: I. Allegro” - MusicBrainz](https://musicbrainz.org/work/3f62d0d8-8ccd-31ab-bfca-768a1ae5708d) is one of three parts of “la Primvera” and has default type Work

[Concerto “Concerto in E major, op. 8 no. 1, RV 269 “La primavera”” - MusicBrainz](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 - [Work “Le quattro stagioni” - MusicBrainz](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 [Work “Il cimento dell’armonia e dell’inventione, op. 8” - MusicBrainz](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.

---

<div class="post-metadata">

### Author: ![Sophist](https://community.metabrainz.org/user_avatar/community.metabrainz.org/sophist/32/70055_2.png) [@Sophist](https://community.metabrainz.org/u/Sophist)
#### Post date: [June 29, 2017, 9:35pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/27 "2017-06-29T21:35:15Z")

</div>

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  
[https://musicbrainz.org/work/3f62d0d8-8ccd-31ab-bfca-768a1ae5708d](https://musicbrainz.org/work/3f62d0d8-8ccd-31ab-bfca-768a1ae5708d)  
TYPE: Movement

is part of:

Concerto in E major, op. 8 no. 1, RV 269 “La primavera”  
[https://musicbrainz.org/work/0d2a5e67-8efc-3233-9ac9-f4be8644be14](https://musicbrainz.org/work/0d2a5e67-8efc-3233-9ac9-f4be8644be14)  
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”)  
[https://musicbrainz.org/work/87886dcf-9776-49cb-b6f5-10104da6e42c](https://musicbrainz.org/work/87886dcf-9776-49cb-b6f5-10104da6e42c)  
Type: Main Work

and:

Il cimento dell’armonia e dell’inventione, op. 8  
[https://musicbrainz.org/work/7044d543-9f9d-4598-8ee7-0f9945d28595](https://musicbrainz.org/work/7044d543-9f9d-4598-8ee7-0f9945d28595)  
Type: Main Work

Perhaps Wagner Ring Cycle would be another useful example, in part because of the number of levels of work it has.

---

<div class="post-metadata">

### Author: ![reosarevok](https://community.metabrainz.org/user_avatar/community.metabrainz.org/reosarevok/32/69228_2.png) [@reosarevok](https://community.metabrainz.org/u/reosarevok)
#### Post date: [June 30, 2017, 12:22pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/28 "2017-06-30T12:22:07Z")

</div>

> [@Sophist](#):
>
> 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

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”)

---

<div class="post-metadata">

### Author: ![Sophist](https://community.metabrainz.org/user_avatar/community.metabrainz.org/sophist/32/70055_2.png) [@Sophist](https://community.metabrainz.org/u/Sophist)
#### Post date: [June 30, 2017, 1:22pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/29 "2017-06-30T13:22:18Z")

</div>

> [@reosarevok](#):
>
> 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”)

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.

---

<div class="post-metadata">

### Author: ![reosarevok](https://community.metabrainz.org/user_avatar/community.metabrainz.org/reosarevok/32/69228_2.png) [@reosarevok](https://community.metabrainz.org/u/reosarevok)
#### Post date: [June 30, 2017, 1:47pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/30 "2017-06-30T13:47:29Z")

</div>

> [@Sophist](#):
>
> 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

---

<div class="post-metadata">

### Author: ![Sophist](https://community.metabrainz.org/user_avatar/community.metabrainz.org/sophist/32/70055_2.png) [@Sophist](https://community.metabrainz.org/u/Sophist)
#### Post date: [June 30, 2017, 2:49pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/31 "2017-06-30T14:49:11Z")

</div>

> [@reosarevok](#):
>
> 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.

---

<div class="post-metadata">

### Author: ![ListMyCDs.com](https://community.metabrainz.org/user_avatar/community.metabrainz.org/listmycds.com/32/62_2.png) [@ListMyCDs.com](https://community.metabrainz.org/u/ListMyCDs.com)
#### Post date: [July 1, 2017, 12:10am UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/32 "2017-07-01T00:10:08Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![Kid\_Devine](https://community.metabrainz.org/user_avatar/community.metabrainz.org/kid_devine/32/17561_2.png) [@Kid\_Devine](https://community.metabrainz.org/u/Kid_Devine)
#### Post date: [July 1, 2017, 12:25am UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/33 "2017-07-01T00:25:16Z")

</div>

> [@ListMyCDs.com](#):
>
> 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.

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.

---

<div class="post-metadata">

### Author: ![Sophist](https://community.metabrainz.org/user_avatar/community.metabrainz.org/sophist/32/70055_2.png) [@Sophist](https://community.metabrainz.org/u/Sophist)
#### Post date: [July 1, 2017, 10:20am UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/34 "2017-07-01T10:20:03Z")

</div>

> [@Kid\_Devine](#):
>
> 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.

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.

---

<div class="post-metadata">

### Author: ![MetaTunes](https://community.metabrainz.org/letter_avatar_proxy/v4/letter/m/ea5d25/32.png) [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [July 1, 2017, 2:58pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/35 "2017-07-01T14:58:54Z")

</div>

> [@Sophist](#):
>
> 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.

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.

---

<div class="post-metadata">

### Author: ![ListMyCDs.com](https://community.metabrainz.org/user_avatar/community.metabrainz.org/listmycds.com/32/62_2.png) [@ListMyCDs.com](https://community.metabrainz.org/u/ListMyCDs.com)
#### Post date: [July 1, 2017, 3:22pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/36 "2017-07-01T15:22:12Z")

</div>

> [@Sophist](#):
>
> A work attribute to hold Symphony, Concerto,Opera, Aria etc.)

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.

---

<div class="post-metadata">

### Author: ![Sophist](https://community.metabrainz.org/user_avatar/community.metabrainz.org/sophist/32/70055_2.png) [@Sophist](https://community.metabrainz.org/u/Sophist)
#### Post date: [July 1, 2017, 4:06pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/37 "2017-07-01T16:06:24Z")

</div>

Y[quote=“[ListMyCDs.com](http://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?

---

<div class="post-metadata">

### Author: ![ListMyCDs.com](https://community.metabrainz.org/user_avatar/community.metabrainz.org/listmycds.com/32/62_2.png) [@ListMyCDs.com](https://community.metabrainz.org/u/ListMyCDs.com)
#### Post date: [July 1, 2017, 4:31pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/38 "2017-07-01T16:31:57Z")

</div>

> [@Sophist](#):
>
> so some main works (like e.g. Vivaldi, Les Quatre Saisons) cannot be identified as such from the Metadata

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.

---

<div class="post-metadata">

### Author: ![MetaTunes](https://community.metabrainz.org/letter_avatar_proxy/v4/letter/m/ea5d25/32.png) [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [July 2, 2017, 9:45am UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/39 "2017-07-02T09:45:00Z")

</div>

> [@MetaTunes](#):
>
> I think a few more complex examples would be a good idea to check it out - I’ll have a hunt around.

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](https://musicbrainz.org/release/ec519fde-94ee-4812-9717-659d91be11d4)

---

<div class="post-metadata">

### Author: ![reosarevok](https://community.metabrainz.org/user_avatar/community.metabrainz.org/reosarevok/32/69228_2.png) [@reosarevok](https://community.metabrainz.org/u/reosarevok)
#### Post date: [July 2, 2017, 11:49am UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/40 "2017-07-02T11:49:11Z")

</div>

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

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

---

<div class="post-metadata">

### Author: ![Kid\_Devine](https://community.metabrainz.org/user_avatar/community.metabrainz.org/kid_devine/32/17561_2.png) [@Kid\_Devine](https://community.metabrainz.org/u/Kid_Devine)
#### Post date: [July 2, 2017, 1:34pm UTC](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047/41 "2017-07-02T13:34:53Z")

</div>

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.

[Previous page](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047.md?page=1)

[Next page](https://community.metabrainz.org/t/levels-in-the-structure-of-works/293047.md?page=3)
