2011/10/28, Jim DeLaHunt <from.nab...@jdlh.com>: > 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!
What about cadenzas? How would we handle them. Note that AFAIK we don't handle them very well currently :-) But would your suggestion make things worse or better? You don't seem to suggest physically storing this information in each movement, which means that if I search for all tracks composed by Bach, the database would have actually to search all Tracks related to Works (through recordings) composed by Bach or to Works being a subwork of a Work by Bach. And the inheritance would be at least 4 levels deep (Wagner's cycle containing operas containing acts containing scenes). I don't know if the MB database would be able to implement this level of search in a reasonable time. Even if it did, adding this complexity would be a burden for the server. Would this burden be low enough to be acceptable? I agree that such a system would make input both intuitive and user-friendly, though. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org _______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style