History talk:Work/Relationship Inheritance in Works Trees Proposal

From MusicBrainz Wiki
Jump to navigationJump to search

I propose defining an inheritance of relationships between any two Works joined by a Parts Relationship Type. This makes explicit the logical consequence of the Parts Relationship Type's meaning: that one Work entity is a part of another Work entity. Any Relationship which is in any of the Work-related Relationship Family has its meaning inherited (except Parts Relationship Type, that would be too recursive).

This proposal is implemented by three changes:

  1. Adding a new page Work/Relationship Inheritance in Works Trees, with the text on the main page
  2. Adding text (below) to Parts Relationship Type, summarising and referring to Work/Relationship Inheritance in Works Trees. This will be a follow-on RFC.
  3. Adding text to Work, linking to Work/Relationship Inheritance in Work Trees


The composer, and sometimes librettist and arranger, are hugely important pieces of metadata for classical, opera, and musical theatre music. It's why we refer to Beethoven's 9th Symphony, or Gilbert and Sullivan operettas. These compositions are frequently recorded many times by many different performers, so more than other genres of music it will be common to have many Recordings point to a single Musicbrainz Work entity. And these compositions are large and long enough that a) the the composer breaks them into smaller pieces (movements, acts, scenes, arias, numbers), and b) Releases frequently break the recorded performance into multiple Tracks of a Release. Hence, there's great value for MusicBrainz in having a way to store metadata about musical compositions in a tree structure, with a single Work entity to represent the entire composition, and child Work entities to represent the composer or the Release publishers divisions of that composition.

The Parts Relationship Type provides a way to represent a musical composition in MusicBrainz as a tree structure. Right now it is the only relationship between a whole composition and a partial composition. In the future, other relationship types may be added, but for now, it's the only one. The Parts Relationship Type description is silent about what meaning a relationship with the Work at one end of the Parts relationship has for the Work at the other end.

At the same time, it's important to be clear to which Work entities Advanced Relationships like Composer and Librettist should be attached. In the past, there has been similar confusion about when Release-Artist relationship types should be used, when Track-Artist, for roles like Performer and Producer. This led to an extensive debate in 2007-2008; the tip of this iceberg can be seen at Talk:Artist Role Inheritance. Work entities are something of a blank slate. We should state principles now, before there are too many confounding entires in the database.

Behind these reasons lurks a larger one. MusicBrainz's ability to handle metadata for classical and opera works is hindered by the complexity of the cultural traditions for naming these compositions, and naming the Tracks and Releases of them. This is what has driven the Classical Style Guide to become such a snarl. I believe that the Works entity will likely be a part of the solution to this problem. While we don't know what form that solution will take, it's pretty clear to me that having tree-structured Works entities, and knowing who the Composer is, will be an important part. This proposal is hopefully a brick which will become a small part of the bridge to a better classical music and opera experience in MusicBrainz.


  • Does this proposal amount to a Works Style guideline that Relationships should now be attached as high in a Parts Relationship Type tree as they apply? No. The Style Council discussion was concerned about the MusicBrainz software not supporting inheritance right now, so that only Relationships attached to leaf Work entities would have a chance to be detected by current software. My conclusion is that it's premature to issue a Style guideline on this matter. We should leave it to editor discretion where best to attach Relationships in a Parts Relationship Type tree. The inheritance rules just make it clear how to read the Relationships on the tree, given the editor's choice of location. JimDeLaHunt 22:32, 30 October 2011 (UTC)
  • Does this proposal mean that, as soon as it's approved, editors should search for Work entity Relationships which are redundant given inheritance, and remove them? My thought is No. My primary motive is to make it clear what the right way is to enter new data, and give clear instructions to the MB software developers for how to improve the software. I understand that current software doesn't handle Works relationships well, so redundant Relationships on both a Parent and Child Work entity might work around the software's limitations for now. JimDeLaHunt 06:57, 29 October 2011 (UTC)
  • Would it be better to decide that, for now, Relationships to a Work with a Parts Relationship Type relationship should be applied to all Works in that tree, i.e. to the parents, all children, and all children of all the parents? This lets our existing software work see the Relationships for now. Then we improve the server software to handle inheritance. Finally we go back and delete all the redundant ARs? That wasn't my intention. I do see the virtue in it, but I also see drawbacks. I think this is a separate Style issue from this proposal, and someone else should champion it. JimDeLaHunt 07:09, 1 November 2011 (UTC)
  • Would it strain the computation and database capacity of MusicBrainz to implement the Relationship Inheritance proposed here? No. A code review seems to show that inheritance of relationships is alive and well on the MusicBrainz server! It's just inheritance along Recording-Work relationship types, not along Parts relationship types. See (mb-style) MB does inheritance, just not on Parts Relationship Type, Jim DeLaHunt, Sun Oct 30 06:44:20 UTC 2011. — JimDeLaHunt 18:22, 1 November 2011 (UTC)
  • If this proposal is approved, there are a number of obvious enhancements to request for the web server's search function, for Picard, etc. to build in this relationship inheritance. My next step would be to propose these enhancements, as RFC and or tickets. JimDeLaHunt 10:49, 28 October 2011 (UTC)
  • The word "Work" has a technical MusicBrainz meaning, and a cultural meaning of "composition". Should this style guideline use the term "Work", or "Composition" (i.e. "Partial Compositions Relationship Inheritance")? But "Composition" has a meaning in mathematics which might also be distracting in this context. JimDeLaHunt 10:49, 28 October 2011 (UTC)
  • I'm terrified to mention Style/Work for fear of getting blocked until that style guideline is completed. But I think this proposal is separable from that one. Still, if I add a stub text in Style/Work, should I also add a link to Style/Work from the Entities line in Template:StyleBox? I don't feel strongly either way. JimDeLaHunt 10:49, 28 October 2011 (UTC)
    • I'm less terrified, now that the target for this proposal is to fit under Work/ and not Style/Work/. JimDeLaHunt 18:22, 1 November 2011 (UTC)
  • I wonder why Artist Role Inheritance is a blank page. There used to be a style guideline under this title. Note: this proposal is not connected to Artist Role Inheritance. JimDeLaHunt 10:49, 28 October 2011 (UTC)
  • Can we really make a blanket statement that all Work-X relationships (except for Parts Relationship Type) get inherited? I think yes. Look though the list of existing relationship types. They all make sense inheriting from parent composition to child composition and vice versa. JimDeLaHunt 12:07, 28 October 2011 (UTC)
    • No objections raised in the RFC discussion. Nor have I found any myself with a few days of thought. JimDeLaHunt 18:22, 1 November 2011 (UTC)
  • Is Parts Relationship Type the only Work-Work relationship that triggers inheritance? Yes, it's the only one expressing a structural relationship between a composition and a fragment of that same composition. I can imagine creating another such relationship, to represent fragments of a composition which the composer didn't define. If we add other structural relationship types, then we should put them into their own relationship class, and modify Partial Works Relationship Inheritance to treat that class specially, instead of treating just Parts Relationship Type specially. JimDeLaHunt 12:07, 28 October 2011 (UTC)
  • Any need to add text to Style/Work, presently empty? I think No. With this proposal being moved out of Style/, it can be linked to from Work/. JimDeLaHunt 07:09, 1 November 2011 (UTC)

Proposed text of Work/Relationship Inheritance in Works Trees

See main page for this proposal: Proposal:Partial Works Relationship Inheritance.

Proposed stub for Work

TBD. Some simple reference to Work/Relationship Inheritance for Work Trees. This will be a follow-on RFC.

Proposed modification to Parts Relationship Type

The page Parts Relationship Type will have the following paragraphs added at the end of the section, "Guidelines". This will be a follow-on RFC.

Connecting two Work entities with this relationship type means that each Work inherits the meaning of relationships applied to the other Work. For instance, a Composer relationship applied to the main work is inherited by the work part. Applying a relationship to the overall Work has a different meaning than applying the same relationship to the work part. The details of this inheritance are spelled out in Partial Works Relationship Inheritance.

It is an error to connect Works in a cycle with Parts Relationship Type. In other words, if Work entity Child has the Relationship is part of a Work entity Parent, then it is an error for Parent to have the Relationship is part of the Work entity Child.

Proposal: It is an error for a Work entity to have more than one Parent.

Related reading