Hi Jim, This proposal is exactly what I've beens suggesting on MB this style list. It is imperative that we allow child(sub-works) to be able to inherit data from the parent(supra-work) in order to simplify and accelerate the works-based data.
I would recommend as I did in my other thread to be explicitly clear that a child-item *should not* have any AR that is duplicated in the partent-work. This would mean that as soon as this proposal passes RFV, we can proceed to start removing redundant composer ARs from child-works if they are already present in the parent-work. Thanks for this! PS: I still think that it would be great if we had a similar hierarchy and inheritance based guideline in our recording entities. :) +1 for me Sebastien On Fri, Oct 28, 2011 at 6:57 AM, Jim DeLaHunt <from.nab...@jdlh.com> wrote: > Hi, everyone: > > I would appreciate review and comments on RFC-339: Partial Works > Relationship Inheritance. The full proposal is at > http://wiki.musicbrainz.org/Proposal:Partial_Works_Relationship_Inheritance > http://wiki.musicbrainz.org/Proposal:Partial_Works_Relationship_Inheritance > . Comments welcome at that Wiki page, or on its Talk page, or here in this > thread. > > This RFC is open at least 7 days, until November 5 GMT or later. I > consider > what I have there a first draft, and I'll want to polish the text at least > before it becomes a solid RFC. > > Summary: > > 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 in any of the > Work-relatedRelationship 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. > > > Comments welcome! > —Jim DeLaHunt http://wiki.musicbrainz.org/User:JimDeLaHunt > > -- > View this message in context: > http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6939661.html > Sent from the Style discussions mailing list archive at Nabble.com. > > _______________________________________________ > MusicBrainz-style mailing list > MusicBrainz-style@lists.musicbrainz.org > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
_______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
