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

From MusicBrainz Wiki
Jump to navigationJump to search
(→‎Issues: Revise issues based on mb-style discussion.)
m (CallerNo6 moved page Proposal:Work/Relationship Inheritance in Works Trees to History:Work/Relationship Inheritance in Works Trees Proposal: https://chatlogs.metabrainz.org/brainzbot/metabrainz/msg/3675767/)
 
(18 intermediate revisions by 3 users not shown)
Line 4: Line 4:
|status=RFC
|status=RFC
|discussion=
|discussion=
|rfc=http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-October/013880.html
|rfc=http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-November/013978.html
|rfv=
|rfv=
|style=1
|style=1
Line 10: Line 10:
|jira=
|jira=
}}
}}
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 [[:Category:Relationship Family|Relationship Family]] has its meaning inherited (except [[Parts Relationship Type]], that would be too recursive).


MusicBrainz can represent metadata about musical compositions, and portions of those compositions, by using multiple [[Work]] entities linked together with [[rt:ca8d3642-ce5f-49f8-91f2-125d72524e6a|"Parts" relationships]]. For instance, there is one Work entity for [[artist:1f9df192-a621-4f54-8850-2c5373b7eac9|Beethoven]]'s ''[[work:c35b4956-d4f8-321a-865b-5b13d9ed192b|Symphony No. 9 in D minor, Op. 125 "Choral"]]'', and one more for each of its movements ([[work:3308d248-b287-38e9-9718-0119d7a3bf9d|I.]], [[work:87f3a5a6-fb92-381b-892b-5fc50ed0f2c1|II]]., [[work:4ebf3fc1-4dd4-361b-a441-bf1dc9421e34|III.]], [[work:3761b925-82b2-3a61-9581-57751dee2e9e|IV.]]). A "Parts" relationship indicates that each movement's Work ''is a part of'' the Symphony's Work.
This proposal is implemented by three changes:
# Adding a new page [[Style/Work/Partial Works Relationship Inheritance]], with the text below
# Adding a stub entry (below) to [[Style/Work]] (presently empty) to point to [[Style/Work/Partial Works Relationship Inheritance]]
# Adding text (below) to [[Parts Relationship Type]], summarising and referring to [[Style/Work/Partial Works Relationship Inheritance]]


This structure of linked Work entities is referred to as a '''Work Tree'''. Any Work entity which has a Relationship, "is part of" another Work entity, is a '''child''' Work. The linked Work, containing the Child, is a '''parent''' Work. Any Work which is not a Child is called the '''root''' of a Work Tree. The '''ancestors''' of a Work are the Work's Parent, and the Parent's Ancestors. Similarly, the '''descendants''' of a Work are the Work's Children, and each Child's Descendants.
==Motivation==


Any Work which has no [[rt:ca8d3642-ce5f-49f8-91f2-125d72524e6a|"Parts" relationships]] is a '''stand-alone''' Work entity, a very simple Work Tree with a Root and no Children. These inheritance rules may be applied to a Stand-Alone Work. They turn out to have no effect.
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.
The MusicBrainz database represents the fact that a composer composed a musical work, by means of a [[Composer Relationship Type|Composer Relationship]] between the Artist entity for the composer and the Work entity for the composition. If this relationship is attached to the Work for a part of the composition, that has a different meaning than attaching it to the root Work. The [[rt:ca8d3642-ce5f-49f8-91f2-125d72524e6a|Parts Relationship Type]] sets up '''inheritance''' between the parent and child Works, so that a Relationship attached to one of the Works conveys a meaning about the other. The same inheritance applies for almost all Relationships on Work entities, not just the Composer Relationship.


==Relationship Inheritance Rules==
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.


Given two Work entities, which we'll call '''Parent''' and '''Child''', with a [[rt:ca8d3642-ce5f-49f8-91f2-125d72524e6a|Parts Relationship Type]] saying "'''Child''' ''is a part of'' '''Parent'''", then the meaning of relationships to either Work entity (which are not [[rt:ca8d3642-ce5f-49f8-91f2-125d72524e6a|Parts Relationship Type]] themselves) is as follows:
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.
;Indivisibility: Any relationship to a Work entity applies to the all of the composition (or part of a composition) to which the Work refers, and to any portion of it. This applicability is called '''full coverage'''.
;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 [[rt:ca8d3642-ce5f-49f8-91f2-125d72524e6a|Parts Relationship Type]]), means that the same relationship applies also to the entire portion of the musical composition to which '''Child''' refers (''i.e.'', with '''full coverage''').
;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 [[rt:ca8d3642-ce5f-49f8-91f2-125d72524e6a|Parts Relationship Type]]), means that the same relationship applies to some non-zero portion, and maybe or maybe not all, of '''Parent'''. This applicability is called '''partial coverage'''.
;Siblings don't inherit: Given another Work entity, '''Child 2''', which also has a [[rt:ca8d3642-ce5f-49f8-91f2-125d72524e6a|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.
;Inheritance is transitive: Given yet another Work entity, '''Grandchild''', which has a [[rt:ca8d3642-ce5f-49f8-91f2-125d72524e6a|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'''.
;Inheritance status matters: Anything which displays or interprets Relationships should present the distinction between inherited and direct Relationships, between inheritance from distant and immediately-linked relatives, and between full and partial coverage, in a way that's appropriate.


These rules cause inheritance for any [[:Category:Relationship Family|Relationship Family]] between a Work and any other entity (Artist, ReleaseGroup, Release, Label, URL, or Work), '''except''' for the [[rt:ca8d3642-ce5f-49f8-91f2-125d72524e6a|Parts Relationship Type]] (Work-Work). The Parts Relationship Type defines the parent-child structure, so it doesn't itself inherit.
==Issues==
* 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. [[User:JimDeLaHunt|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. [[User:JimDeLaHunt|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, but I see the virtue in it. But I think this is a sseparate Style issue to this proposal. [[User:JimDeLaHunt|JimDeLaHunt]] 06:57, 29 October 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 ''[http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-October/013911.html (mb-style) MB does inheritance, just not on Parts Relationship Type]'', Jim DeLaHunt, Sun Oct 30 06:44:20 UTC 2011.
* 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. [[User:JimDeLaHunt|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. [[User:JimDeLaHunt|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. [[User:JimDeLaHunt|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]]. [[User:JimDeLaHunt|JimDeLaHunt]] 10:49, 28 October 2011 (UTC) A: The page [[Style/Relationships#Crediting an artist's role at the track vs. the release level]] addresses what [[Artist Role Inheritance]] used to. Per Nikki [http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6941285.html Oct 28, 2011; 11:31am].
* 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)


==Discussion==
==Proposed text of Style/Work/Partial Works Relationship Inheritance==
Create a new page at [[Style/Work/Partial Works Relationship]] with this text:


Software which reads the MusicBrainz database is what implements Relationship inheritance for a Work in a Work Tree. This software traverses the Parts Relationship Type links, and reports which Relationships affect the starting Work. Some Relationships will be attached directly to the Work, some will be inherited from ancestors, some will be inherited from descendants. Some Relationships will apply to the whole Work, some will apply to just some portion (and maybe or maybe not all) of it. As of October 2011, MusicBrainz software does not implement these inheritance rules. (However, it performs similar link traversals in other contexts, ''e.g.'' to get the Recording artists for a Work.)
MusicBrainz can represent metadata about musical compositions, and parts of those compositions, by using multiple [[Work]] entities linked together with [[Parts Relationship Type|"Parts" relationships]]. For instance, there is one Work entity for [http://musicbrainz.org/artist/1f9df192-a621-4f54-8850-2c5373b7eac9 Beethoven]'s ''[http://musicbrainz.org/work/c35b4956-d4f8-321a-865b-5b13d9ed192b Symphony No. 9 in D minor, Op. 125 "Choral"]'', and four more for each of its movements ([http://musicbrainz.org/work/3308d248-b287-38e9-9718-0119d7a3bf9d I.], [http://musicbrainz.org/work/87f3a5a6-fb92-381b-892b-5fc50ed0f2c1 II]., [http://musicbrainz.org/work/4ebf3fc1-4dd4-361b-a441-bf1dc9421e34 III.], [http://musicbrainz.org/work/3761b925-82b2-3a61-9581-57751dee2e9e IV.]).


The inheritance rules do not themselves dictate a [[Style]] guideline on where to apply Relationships to Works in a Work Tree. Until MusicBrainz software implements inheritance rules, a style of applying Relationships to the lowest Work in the tree has the advantage that current software is most likely to detect them. However, it requires multiple Relationships to be applied to multiple child Works in the tree, with a chance that they will accidentally be different, or that some Works will be missed. A style of applying Relationships to the highest Work in a tree, where they are still correct, has the advantage that relationships inherited to the lowest Works in the tree will be consistent and have complete coverage. It also has the advantage of lower data entry effort and lower storage requirements, though these are less important factors. However, until MusicBrainz software implements inheritance, the Relationships may be largely invisible.
The MusicBrainz database represents the fact that a composer composed a musical work by means of a [[Composer Relationship Type|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.


It's completely valid to attach more than one [[Advanced Relationship]] of the same type to the same Work entity. For instance, the composition popularly known as the "[[work:e27bda6e-531e-36d3-9cd7-b8ebc18e8c53|Mozart ''Requiem'']]" has Relationships to one [[Composer Relationship Type|composer]] ([[artist:b972f589-fb0e-474e-b64a-803b0364fa75|Mozart]]), one "additional" composer ([[artist:d3602c4f-bd37-49cd-b16d-a295e2a6659f|Süßmayr]]), and three [[Orchestrator Relationship Type|orchestrators]] ([[artist:b972f589-fb0e-474e-b64a-803b0364fa75|Mozart]], [[artist:d3602c4f-bd37-49cd-b16d-a295e2a6659f|Süßmayr]], and [[artist:9140f046-d57e-4643-9d08-ba094988f9e9|Freystädtler]]). Also, MusicBrainz has no way to cancel or override Relationships. Thus, all the Relationships a Work inherits, or has directly attached, are valid. If there's a Work Tree where some Children need one Relationship "A", and other Children need a different relationship "B", then apply these Relationships to the Children. Do not apply either Relatioship, "A" or "B", to the Parent.
===Relationship Inheritance Rules===


Why does inheritance status matter? For a Work entity, a directly attached Relationship has slightly different significance than the same exact Relationship inherited from an Ancestor. The meaning of the Relationship itself is the same: both have "full coverage", and link to the same other entity. But it's possible for editors to apply Relationships without realising how other Works in the Tree will inherit the Relationship. Also, Relationships inherited from Descendants have only partial coverage, while directly attached Relationships have full coverage. Because these differences are likely significant to users of MusicBrainz, they should be display in some appropriate way.
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'''.


The definitions for '''ancestors''' and '''descendants''' above are ''recursive''. This kind of definition works well for some people, and for mathematicians and computer scientists. It can be brain-twisting for many people. Here's another way to express those definitions. The Ancestors of a Work in a Work Tree are: that Work's Parent, the Parent's Parent, and so on back to the Root entity of the work tree. The Root Work itself has zero Ancestors. The Descendants of a Work in a Work Tree are: all of that Work's Children, and all of Children of the first Child, and all of Children of the second Child, and so on through all of the Work's Children, and all the Children's Children's Children, stopping at those final Works which themselves have no Children. Some Works in any Work Tree will have zero Children, and so zero Descendants.
These rules cause inheritance for any [[Category:Relationship Family]] 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.


==Examples==
===Considerations===
Suppose there is one Work entity for [[artist:1f9df192-a621-4f54-8850-2c5373b7eac9|Beethoven]]'s ''[[work:c35b4956-d4f8-321a-865b-5b13d9ed192b|Symphony No. 9 in D minor, Op. 125 "Choral"]]''. (We're basing this example on actual MusicBrainz entries, with some embellishment.) There is one more Work entities for each of its movements ([[work:3308d248-b287-38e9-9718-0119d7a3bf9d|I...]], [[work:87f3a5a6-fb92-381b-892b-5fc50ed0f2c1|II...]], [[work:4ebf3fc1-4dd4-361b-a441-bf1dc9421e34|III...]], and ''[[work:3761b925-82b2-3a61-9581-57751dee2e9e|IV. Finale. Presto - Allegro assai]]''). Each movement's Work is linked to the root Work for the Symphony by a Parts Relationship Type.


There is another Work entity ''[[work:288e78c4-20f6-3524-b599-1afaa0f1e4be|'Ode an die Freude' aus Sinfonie No. 9, Op. 125]]'', and let's say it refers only to the part with the singing. It is linked to the IV. movement with a Relationship, ... "is a part of" ''[[work:3761b925-82b2-3a61-9581-57751dee2e9e|IV. Finale. Presto - Allegro assai]]''.
The inheritance rules do not themselves dictate where to apply Relationships to Work entities in a [[Parts Relationship Type]] tree. As of October 2011, MusicBrainz software does not implement these inheritance rules. So, applying Relationships to the lowest Work entity in the tree has the advantage that current software is most likely to detect them. However, this means multiple Relationships need to be applied to multiple partial-work entities in the tree, with a chance that they will accidentally be different, or that some entities will be missed. Applying Relationships to the highest Work entity in a tree, where it still applies, has the advantage that relationships inherited to the lowest Works in the tree will be consistent and have complete coverage. It also has the advantage of lower data entry effort and lower storage requirements, though these are less important factors.


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'''.
This structure is a '''work tree'''. It consists of six linked Work entities. They Symphony's entity is the '''root'''. The entities for Movements I-IV are '''children''' of the root. The entity for ''Ode an die Freude'' is a '''child''' of the entity for Movement IV.


Let's say there is a [[Composer Relationship Type|Composer relationship]] of [[artist:1f9df192-a621-4f54-8850-2c5373b7eac9|Ludwig van Beethoven]] to attached to the Root entity, ''[[work:c35b4956-d4f8-321a-865b-5b13d9ed192b|Symphony No. 9 in D minor, Op. 125 "Choral"]]''. There is a [[Librettist Relationship Type|Librettist relationship]] of [[artist:6eea5386-1d69-424c-851c-1236a72db3c2|Friedrich Schiller]] attached to ''[[work:3761b925-82b2-3a61-9581-57751dee2e9e|IV. Finale. Presto - Allegro assai]]''.
===Examples===
Suppose there is one Work entity for [http://musicbrainz.org/artist/1f9df192-a621-4f54-8850-2c5373b7eac9 Beethoven]'s ''[http://musicbrainz.org/work/c35b4956-d4f8-321a-865b-5b13d9ed192b Symphony No. 9 in D minor, Op. 125 "Choral"]''. (Actually, there is, but we're adding a little bit to reality for this example.)
* There are four more Work entities for each of its movements ([http://musicbrainz.org/work/3308d248-b287-38e9-9718-0119d7a3bf9d I...], [http://musicbrainz.org/work/87f3a5a6-fb92-381b-892b-5fc50ed0f2c1 II...], [http://musicbrainz.org/work/4ebf3fc1-4dd4-361b-a441-bf1dc9421e34 III...], and ''[http://musicbrainz.org/work/3761b925-82b2-3a61-9581-57751dee2e9e IV. Finale. Presto - Allegro assai]''). Each movement is linked to the parent Work entity for the Symphony by a Parts Relationship Type.
** There is a [[Librettist Relationship Type|Librettist relationship]] of [http://musicbrainz.org/artist/6eea5386-1d69-424c-851c-1236a72db3c2 Friedrich Schiller] to ''[http://musicbrainz.org/work/3761b925-82b2-3a61-9581-57751dee2e9e IV. Finale. Presto - Allegro assai]''.
** There is another Work entity ''[http://musicbrainz.org/work/288e78c4-20f6-3524-b599-1afaa0f1e4be 'Ode an die Freude' aus Sinfonie No. 9, Op. 125]'', and let's say it refers only to the part with the singing. It is linked to the IV. movement with a relationship, ... ''is a part of'' ''[http://musicbrainz.org/work/3761b925-82b2-3a61-9581-57751dee2e9e IV. Finale. Presto - Allegro assai]''.
* There is a [[Composer Relationship Type|Composer relationship]] of [http://musicbrainz.org/artist/1f9df192-a621-4f54-8850-2c5373b7eac9 Ludwig van Beethoven] to the top-level Work entity, ''[http://musicbrainz.org/work/c35b4956-d4f8-321a-865b-5b13d9ed192b Symphony No. 9 in D minor, Op. 125 "Choral"]''.


This structure conveys several meanings.
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).
* Each of the four movements has a 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).
* 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 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 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).
* 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.
* 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]] definition, not the inheritance rules.)
* The excerpt '' 'Ode an die Freude' aus Sinfonie No. 9, Op. 125'' has the Composer relationship with Beethoven (Inheritence is transitive).
* The excerpt '' 'Ode an die Freude' aus Sinfonie No. 9, Op. 125'' has the Composer relationship with Beethoven (Inheritance 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).
* 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 [[Release]]s that had [[Recording]]s 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.
Without relationship inheritance, a search for [[Release]]s that had [[Recording]]s of performances of works composed 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, in this example.


===Proposed stub for Style/Work===
The page [[Style/Work]] is presently empty. There are [[User:PBryan/Work Issues|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 [[Work]]s are not yet complete. See, however, "[[Style/Work/Partial Works Relationship Inheritance|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 [[Style/Work/Partial Works Relationship Inheritance|Partial Works Relationship Inheritance]].

==Related reading==
* [[Parts Relationship Type]]
* [[:Category:Relationship Family]], to look at all the relationships involving [[Work]].
** Few of the relationship families involving works are filled in: [[:Category:Artist-Work Relationship Family|Artist—Work]], [[:Category:ReleaseGroup-Work Relationship Family|ReleaseGroup—Work]] (none defined), [[:Category:Release-Work Relationship Family|Release—Work]] (none defined), [[:Category:Label-Work Relationship Family|Label—Work]], [[:Category:Recording-Work Relationship Family|Recording—Work]], [[:Category:Work-Work Relationship Family|Work—Work]], [[:Category:Work-URL Relationship Family|Work—URL]]
** See also the definition trees on the [[MusicBrainz]] server: [http://ngs.musicbrainz.org/admin/linktype/artist-work Artist—Work], [http://ngs.musicbrainz.org/admin/linktype/release_group-work ReleaseGroup—Work], [http://ngs.musicbrainz.org/admin/linktype/release-work Release—Work], [http://ngs.musicbrainz.org/admin/linktype/label-work Label—Work], [http://ngs.musicbrainz.org/admin/linktype/recording-work Work—Recording], [http://ngs.musicbrainz.org/admin/linktype/work-work Work—Work], [http://ngs.musicbrainz.org/admin/linktype/url-work Work—URL]
* [http://musicbrainz.1054305.n4.nabble.com/RFC-Concept-of-works-group-tp3535348p3535348.html The Work Group thread] talked about a mechanism for over-riding global "parent" ARs with local "child" ARs. (May 2011) (Thanks to Alex / caller #6 for the link.)
* [[:Talk:Artist Role Inheritance]] is the tip of the iceberg for a past debate (2007-2008) about when Release-Artist relationship types should be used, when Track-Artist, for roles like Performer and Producer. The philosophical issues are similar.
* [[Proposal:Display Inheritance]], talking about a similar issue of inheriting meaning in a tree structure. This RFC was declared offically abandoned on March 24, 2010.
* [http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-August/000319.html (mb-style) Advanced Relationship Inheritance (Was: Advanced Relationship Attribute "additional")], a long thread starting in August 2005.
* [[User:PBryan/Work Issues]], lots of work to be done regarding MB Work entities!

Latest revision as of 22:27, 28 August 2016


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



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

RFC


MusicBrainz can represent metadata about musical compositions, and portions 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 one more for each of its movements (I., II., III., IV.). A "Parts" relationship indicates that each movement's Work is a part of the Symphony's Work.

This structure of linked Work entities is referred to as a Work Tree. Any Work entity which has a Relationship, "is part of" another Work entity, is a child Work. The linked Work, containing the Child, is a parent Work. Any Work which is not a Child is called the root of a Work Tree. The ancestors of a Work are the Work's Parent, and the Parent's Ancestors. Similarly, the descendants of a Work are the Work's Children, and each Child's Descendants.

Any Work which has no "Parts" relationships is a stand-alone Work entity, a very simple Work Tree with a Root and no Children. These inheritance rules may be applied to a Stand-Alone Work. They turn out to have no effect.

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 for a part of the composition, that has a different meaning than attaching it to the root Work. The Parts Relationship Type sets up inheritance between the parent and child Works, so that a Relationship attached to one of the Works conveys a meaning about the other. The same inheritance applies for almost all Relationships on Work entities, not just the Composer Relationship.

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 a Work entity applies to the all of the composition (or part of a composition) to which the Work refers, and to any portion of it. This applicability is called full coverage.
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 (i.e., with full coverage).
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. This applicability is called partial coverage.
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.
Inheritance 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.
Inheritance status matters
Anything which displays or interprets Relationships should present the distinction between inherited and direct Relationships, between inheritance from distant and immediately-linked relatives, and between full and partial coverage, in a way that's appropriate.

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

Discussion

Software which reads the MusicBrainz database is what implements Relationship inheritance for a Work in a Work Tree. This software traverses the Parts Relationship Type links, and reports which Relationships affect the starting Work. Some Relationships will be attached directly to the Work, some will be inherited from ancestors, some will be inherited from descendants. Some Relationships will apply to the whole Work, some will apply to just some portion (and maybe or maybe not all) of it. As of October 2011, MusicBrainz software does not implement these inheritance rules. (However, it performs similar link traversals in other contexts, e.g. to get the Recording artists for a Work.)

The inheritance rules do not themselves dictate a Style guideline on where to apply Relationships to Works in a Work Tree. Until MusicBrainz software implements inheritance rules, a style of applying Relationships to the lowest Work in the tree has the advantage that current software is most likely to detect them. However, it requires multiple Relationships to be applied to multiple child Works in the tree, with a chance that they will accidentally be different, or that some Works will be missed. A style of applying Relationships to the highest Work in a tree, where they are still correct, has the advantage that relationships inherited to the lowest Works in the tree will be consistent and have complete coverage. It also has the advantage of lower data entry effort and lower storage requirements, though these are less important factors. However, until MusicBrainz software implements inheritance, the Relationships may be largely invisible.

It's completely valid to attach more than one Advanced Relationship of the same type to the same Work entity. For instance, the composition popularly known as the "Mozart Requiem" has Relationships to one composer (Mozart), one "additional" composer (Süßmayr), and three orchestrators (Mozart, Süßmayr, and Freystädtler). Also, MusicBrainz has no way to cancel or override Relationships. Thus, all the Relationships a Work inherits, or has directly attached, are valid. If there's a Work Tree where some Children need one Relationship "A", and other Children need a different relationship "B", then apply these Relationships to the Children. Do not apply either Relatioship, "A" or "B", to the Parent.

Why does inheritance status matter? For a Work entity, a directly attached Relationship has slightly different significance than the same exact Relationship inherited from an Ancestor. The meaning of the Relationship itself is the same: both have "full coverage", and link to the same other entity. But it's possible for editors to apply Relationships without realising how other Works in the Tree will inherit the Relationship. Also, Relationships inherited from Descendants have only partial coverage, while directly attached Relationships have full coverage. Because these differences are likely significant to users of MusicBrainz, they should be display in some appropriate way.

The definitions for ancestors and descendants above are recursive. This kind of definition works well for some people, and for mathematicians and computer scientists. It can be brain-twisting for many people. Here's another way to express those definitions. The Ancestors of a Work in a Work Tree are: that Work's Parent, the Parent's Parent, and so on back to the Root entity of the work tree. The Root Work itself has zero Ancestors. The Descendants of a Work in a Work Tree are: all of that Work's Children, and all of Children of the first Child, and all of Children of the second Child, and so on through all of the Work's Children, and all the Children's Children's Children, stopping at those final Works which themselves have no Children. Some Works in any Work Tree will have zero Children, and so zero Descendants.

Examples

Suppose there is one Work entity for Beethoven's Symphony No. 9 in D minor, Op. 125 "Choral". (We're basing this example on actual MusicBrainz entries, with some embellishment.) There is one more Work entities for each of its movements (I..., II..., III..., and IV. Finale. Presto - Allegro assai). Each movement's Work is linked to the root Work for the Symphony by a Parts Relationship Type.

There is another Work entity 'Ode an die Freude' aus Sinfonie No. 9, Op. 125, and let's say it refers only to the part with the singing. It is linked to the IV. movement with a Relationship, ... "is a part of" IV. Finale. Presto - Allegro assai.

This structure is a work tree. It consists of six linked Work entities. They Symphony's entity is the root. The entities for Movements I-IV are children of the root. The entity for Ode an die Freude is a child of the entity for Movement IV.

Let's say there is a Composer relationship of Ludwig van Beethoven to attached to the Root entity, Symphony No. 9 in D minor, Op. 125 "Choral". There is a Librettist relationship of Friedrich Schiller attached to IV. Finale. Presto - Allegro assai.

This structure conveys several meanings.

  • Each of the four movements has a 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 definition, not the inheritance rules.)
  • The excerpt 'Ode an die Freude' aus Sinfonie No. 9, Op. 125 has the Composer relationship with Beethoven (Inheritance 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 composed 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, in this example.