Using series entity to store work related data

Tags: #<Tag:0x00007f0508b02048>


On Community Cleanup / Debussy topic some feedback was requested about . I’m starting another topic about this because in general this isn’t just about Debussy (and people not interested about the composer might skip the posts on that topic).

I believe MB series entity wasn’t really planned for this kind of usage. People subscribing artist aren’t able to see this type of edits because it’s not related to the artist. At the moment series entity doesn’t have similar relationship types as works so series can’t have a composer, arranger, lyricist or any necessary relationship types. Other websites and databases consider our work data being stored only on work entity.

I would discourage doing similar edits until there’s been more discussion about it. Even though we have something called “series” might not mean that it makes sense to store this type of data. Even UI doesn’t seem to be suitable for this task at the moment. I mean how many pages you need to scroll to see all the titles of the series if there’s tens of parts?

Community Cleanup #1: Debussy

Thanks for it.

As I wrote in my Edit, the alternative would have been be to create a (sub-)Work for each Livre (book). They could have been related to the main work and, possibly to the composer, to his two works catalogue, L. and CD, with the number “CD 143”, “CD 143-I”/“CD 143-II”, “CD 143 (L1)”/“CD 143 (L2)”, etc. for example (highly debatable proposals!).

Personally, I do not like such a multiplication of Works, when it is just a way to structure a rather complex Work made of several parts, sub-parts, etc., like an e.g. operas, set of songs, suites, etc. especially when there are different possible ways to consider this structure, i.e. different possible arrangement of sub-works.
In Debussy’s Études case, the Livre level could be considered as optional: some could consider that the work Douze Études is made up of 12 Études, column. Others may consider that the Douze Études are undoubtedly comprised of 2 Livres each one including 6 Études.
Should then the Études works be related to both upper-level Works: to the intermediate one Livre and to the top one Douze Études? Here we have only 3 levels in the tree structure, of which only one is optional; what about a more complex situation when there would be 5 levels, of which 2 or 3 are optional, and possibly interwoven…

For sure, the Series is not the perfect answer to my wish of avoiding Works. With a Series, there is no AR with a parent work, neither to the composer artist (or only as the Cataloguer, which is wrong)… Moreover, there is no Series type that corresponds to this purpose. I intently used the “Series of Works” rather the “A series of works which form a catalogue of classical compositions”.

But I thought it would a be an appropriate (maybe temporary) way to record the existence of this intermediate level Livres.

I would be happy if this discussion led to an improvement of the Schema, to better manage works structuring.


I fail to see benefits of storing this data on series entity. Now data about the work is split between 2 different entities. Currently it’s well hidden: full structure can’t be seen on (main) work page and it’s no way related to composer (there’s no relationship types for this).

I don’t understand how more complex tree structures should be divided between these entities. Instead of trying to fit this data into series (by adding new relationship types with some UI changes) we could improve the current work entity. For me it would make more sense to store all work related data with work entities without trying to store data which is only related to structure with another entity.

I believe there’s quite many of us who believe that work structures could be handled somehow differently. Pretty long discussion about it already started on another topic. Levels in the structure of works. Topic is pretty long but I recommend checking it if you haven’t already done so.

I see no reason to do that. I guess with this we just need to trust common sense. If opera has acts, parts of act are also part of opera. People should be able to understand this without linking all pieces with act and the main work. That’s how hierarchies in tree structures work.


The problem with the original example is, I think, that that there is more than one edition of the 2 Livres and they comprise different sets of works. Otherwise a multi-level structure of works would be fine. To have multiple possible intermediate subdivisons looks overly complex so maybe the best answer is just to have the top Douze then each work.
The reason there are multiple editions is because these were subsequently created by publishers, not the composer - so per the style guidelines, the Livres are not works.


Guidelines mention “Works should be entered into MusicBrainz using the boundaries decided by the composer, as printed in the score”. Seems that we don’t care about original manuscripts :innocent:

More seriously, we are still allowed to use some common sense. Most of the people haven’t even heard about the original order of études and printed scores typically include Livres. English Wikipedia didn’t even mention about the difference. Even Centre de Documentation Claude Debussy lists this with Livres and traditional order. I would consider mentioning about the difference only on annotation.

We still have an option to have 2 separate works for this if it’s felt to be necessary. Some titles aren’t the same but we still support aliases and disambiguations can also be used when necessary. We already have multiple sub-works which are part of different works. For example isn’t any sort of problem.


To me, this kind of looks like a book with tunes, akin to

Which I personally think are worthy of inclusion in MusicBrainz (or I wouldn’t have added the above two :slight_smile:). I may misunderstand what this is though, so feel free to disregard.