History:Work/Relationship Inheritance in Works Trees Proposal: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
(→‎Other rules: New section. Put ARs at highest meanngful level. No cycles.)
(→‎Issues: +Fill in ARs on all parents and children for now? +Hunt and kill redundant ARs?)
Line 34: Line 34:
* 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. [[User:JimDeLaHunt|JimDeLaHunt]] 12:07, 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. [[User:JimDeLaHunt|JimDeLaHunt]] 12:07, 28 October 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. [[User:JimDeLaHunt|JimDeLaHunt]] 12:07, 28 October 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. [[User:JimDeLaHunt|JimDeLaHunt]] 12:07, 28 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, but I see the virtue in it. [[User:JimDeLaHunt|JimDeLaHunt]] 06:57, 29 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 relationsips well, so redundant Relationships on both a Parent and Child Work entity might work around the software's limitations for now. [[User:JimDeLaHunt|JimDeLaHunt]] 06:57, 29 October 2011 (UTC)


==Proposed text of Style/Work/Partial Works Relationship Inheritance==
==Proposed text of Style/Work/Partial Works Relationship Inheritance==

Revision as of 06:57, 29 October 2011


Status: This page describes an active style guideline proposal and is not official.



Proposal number: RFC-339
Champion: Jim DeLaHunt
Current status: RFC

RFC


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 Style/Work/Partial Works Relationship Inheritance, with the text below
  2. Adding a stub entry (below) to Style/Work (presently empty) to point to Style/Work/Partial Works Relationship Inheritance
  3. Adding text (below) to Parts Relationship Type, summarising and referring to Style/Work/Partial Works Relationship Inheritance

Motivation

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

Issues

  • 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)
  • 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)
  • 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)
  • 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)
  • 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, but I see the virtue in it. JimDeLaHunt 06:57, 29 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 relationsips 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)

Proposed text of Style/Work/Partial Works Relationship Inheritance

Create a new page at Style/Work/Partial Works Relationship with this text:

MusicBrainz can represent metadata about musical compositions, and parts of those compositions, by using multiple Work entities linked together with "Parts" relationships. For instance, there is one Work entity for Beethoven's Symphony No. 9 in D minor, Op. 125 "Choral", and four more for each of its movements (I., II., III., IV.).

The MusicBrainz database represents the fact that a composer composed a musical work by means of a Composer Relationship between the Artist entity for the composer and the Work entity for the composition. If this relationship is attached to the Work entity for part of the composition, that has a different meaning than attaching it to the Work entity for just one movement. The Parts Relationship Type sets up inheritance between the parent and child Work entities, so that a relationship attached to one of the Work entities has a meaning about the other entity.

Relationship Inheritance Rules

Given two Work entities, which we'll call Parent and Child, with a Parts Relationship Type saying "Child is a part of Parent", then the meaning of relationships to either Work entity (which are not Parts Relationship Type themselves) is as follows:

Indivisibility
Any relationship to Parent applies to the all of the composition to which Parent refers, and to any portion of it.
All of Child inherits from Parent
Any relationship to Parent, be it from an Artist, ReleaseGroup, Release, Label, URL, or Work (except for Work-Work Parts Relationship Type), means that the same relationship applies also to the entire portion of the musical composition to which Child refers, whether or not a corresponding relationship entry to Child is explicitly recorded.
Some of Parent inherits from Child
Any relationship to Child, be it from an Artist, ReleaseGroup, Release, Label, URL, or Work (except for Work-Work Parts Relationship Type), means that the same relationship applies to some non-zero portion, and maybe or maybe not all, of Parent, even if no corresponding relationship entry to Parent is explicitly recorded.
Siblings don't inherit
Given another Work entity, Child 2, which also has a Parts Relationship Type saying "Child 2 is a part of Parent", then any relationship to Child does not imply any meaning about that relationship and Child 2. Inheritance passes between parent and child, but not from one child to another of the same parent.
Inheritence is transitive
Given yet another Work entity, Grandchild, which has a Parts Relationship Type saying "Grandchild is a part of Child", then any relationship which Child inherits from Parent, Grandchild in turn inherits from Child (its parent). Any relationship which Child inherits from Grandchild (its own child), Parent in turn inherits from Child.

These rules cause inheritance for any between a Work and any other entity (Artist, ReleaseGroup, Release, Label, URL, or Work), except for the Parts Relationship Type (Work-Work). This relationship defines the parent-child structure, so it doesn't itself inherit.

Other rules

Relationships on works should be applied to the largest (highest) Work entity in Parts Relationship Type chain where it still applies. If there is a Relationship to a Work entity which has child entities, the identical Relationship should not be applied to any of the child works in the chain. Different but similar entities may be applied to child works, if the result is meaningful.

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.

Examples

Suppose there is one Work entity for Beethoven's Symphony No. 9 in D minor, Op. 125 "Choral". (Actually, there is, but we're adding a little bit to reality for this example.)

This structure conveys several meanings.

  • Each of the four movements has Composer relationship with Beethoven, even though they have no direct Composer relationship defined (All of Child inherits from Parent).
  • Beethoven is the Composer of every portion of every movement (All of Child inherits from Parent).
  • Schiller has the Librettist relationship with some portion, but maybe or maybe not all, of the overall Symphony No. 9 in D minor, Op. 125 "Choral" (Some of Parent inherits from Child)
  • Schiller does not have the Librettist relationship with movements I, II, and III (Siblings don't inherit)
  • Schiller has the Librettist relationship with the excerpt, 'Ode an die Freude' aus Sinfonie No. 9, Op. 125 (All of Child inherits from Parent).
  • If the Librettist relationship with Schiller were attached to the overall Symphony No. 9 in D minor, Op. 125 "Choral" instead of movement IV., then Schiller would have the Librettist relationship with movements I., II., and III. also (All of Child inherits from Parent). It turns out that these movements are entirely instrumental; they have no words. Whether it's meaningful for an instrumental movement to have a Librettist is a matter for Librettist Relationship Type, not here.
  • The excerpt 'Ode an die Freude' aus Sinfonie No. 9, Op. 125 has the Composer relationship with Beethoven (Inheritence is transitive).
  • If the Librettist relationship with Schiller were attached to the excerpt 'Ode an die Freude' aus Sinfonie No. 9, Op. 125, instead of to movement IV., then the Librettist relationship with the overall Symphony No. 9 in D minor, Op. 125 "Choral" would be unchanged: the Librettist relationship would be with some portion, but maybe or maybe not all, of the overall composition (Inheritence is transitive).

Without relationship inheritance, a search for Releases that had Recordings of performances of works by Beethoven wouldn't turn up many instances of the Symphony No. 9. Most Releases would put each movement of the symphony on a separate Track, and each Track would link to a corresponding Recording, and the Recording is most accurately linked to the child Work for the movement. But the Composer relationship for Beethoven is attached to the overall Symphony No. 9 work, not the child works for each movement. It is the relationship inheritance which connects the Release to the Composer.


Proposed stub for Style/Work

The page Style/Work is presently empty. There are people working on Work style issues, and I don't want this proposal to get trapped waiting for that effort to complete. But it also seems odd to have no reference to Style/Work/Partial Works Relationship Inheritance in the Style page tree. Thus I propose a simple stub, with this text:

Style guidelines for Works are not yet complete. See, however, "Partial Works Relationship Inheritance".


Proposed modification to Parts Relationship Type

The page Parts Relationship Type will have the following paragraph added at the end of the section, "Guidelines":

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.

Related reading