[mb-style] RFC-339: Partial Works Relationship Inheritance
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
Re: [mb-style] RFC-338: Clarification of gender=other
jw wrote: The proposal is to add this paragraph to the Gender chapter in Style/Artist [1]: The 'other' gender option is meant to represent a gender that is neither male nor female, and is not intended for use with entities for which the concept of gender is illogical, such as companies. +1. The values male and female do not describe the gender of every human being. Having an other option is worthwhile. Being clear that it does not mean n/a is worthwhile. I also say +1 for introducing the n/a gender option, and documenting it. But that would be a separate proposal. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-338-Clarification-of-gender-other-tp6930788p6939680.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
Re: [mb-style] RFC-339: Partial Works Relationship Inheritance
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
Re: [mb-style] RFC-339: Partial Works Relationship Inheritance
While the idea of work inheriting seems pretty reasonable, I wonder how it would work for stuff like song-cycles, where each song is actually a piece in its own right. Or to things like 2 piano sonatas, Op. whatever. Would we store the information at the group level, or at each work? Does this only count for movements? Also, in general, this shouldn't be made a guideline until a proper way of handling works is developed. Although I understand the interest on removing what is seen as data duplication, right now the machine has no clear way of knowing it *is* data duplication and won't be able to inherit the info for things like composer tags (or for display in the page for that matter). On Fri, Oct 28, 2011 at 3:30 PM, Rupert Swarbrick rswarbr...@gmail.com wrote: Jim DeLaHunt from.nab...@jdlh.com writes: 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 This is a great idea! Indeed, it would be even better if the MB software had some support for showing this eg. a slightly differently formatted copy of the inherited AR or something. About your question of whether all artist-work relationships should be inherited: I think so, given the current list, and I can't think of any plausible new artist-work relationships that would break this... Definitely a +1 from me. Rupert ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-339: Partial Works Relationship Inheritance
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
Re: [mb-style] RFC-339: Partial Works Relationship Inheritance
On Fri, 2011-10-28 at 13:30 +0100, Rupert Swarbrick wrote: Jim DeLaHunt from.nab...@jdlh.com writes: 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 is a great idea! Indeed, it would be even better if the MB software had some support for showing this eg. a slightly differently formatted copy of the inherited AR or something. About your question of whether all artist-work relationships should be inherited: I think so, given the current list, and I can't think of any plausible new artist-work relationships that would break this... Speaking as a person who is currently attempting to write a music player that uses Musicbrainz metadata... Inheritence of ARs makes a lot of things in the database model a /lot/ harder to deal with, particularly when doing things like searching for all works composed by a particular artist. I would need to maintain a list of which ARs cause data inheritence and which don't - which is liable to get out of date - and then, in the data model, I would actually store duplicate ARs at all relevant levels in order to be able to directly map searches. Speaking as an editor, I actually don't really mind doing adding these duplicated ARs manually. Although I admit that I don't do much with opera or musicals, etc. :) It would be /really/ helpful to have some sort of support for this by the musicbrainz server and webservice; preferably /before/ the guideline starts to be applied to data on the site. None of the existing portions of the website (e.g. the recording page) or tools (e.g. bitmap's release releations script) support going multiple levels deep to pull out a composer AR; so in these cases you simply wouldn't see one even if it's there. Other users of the webservice would have similar issues. -- kepstin Calvin Walton calvin.wal...@kepstin.ca ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-339: Partial Works Relationship Inheritance
On Fri, Oct 28, 2011 at 12:17:21PM -0400, Calvin Walton wrote: How would you handle, for example, the case where the entire work is known to be composed by two composers, A B - but it is known that, for example, only A composed the prelude and only B the overture, which are parts of that entire work? You wouldn't want to inherit both of the composers from the top level work in that case. Exactly, I wanted to give a similar example with composition date. I've seen a lot of examples where the movements have exact composition dates (e.g. 1874-1876 and 1877-1878) and the entire work has 1874-1878. So here the entire work kind of inherits the composition dates from the contained sub-works. So I don't really see the benefit of just blindly copying ARs... Johannes ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-339: Partial Works Relationship Inheritance
In my opinion, if the sub-work contains an AR that is also stored in the supra-work but with a different value then the sub-work AR should always take precedence and only it should be shown. That said, it might be useful to have an attribute at the AR level where one could over-ride this and allow both to be shown and extracted (can't think of examples at this moment though...) Sebastien. On Fri, Oct 28, 2011 at 1:11 PM, Johannes Weißl jar...@molb.org wrote: On Fri, Oct 28, 2011 at 12:17:21PM -0400, Calvin Walton wrote: How would you handle, for example, the case where the entire work is known to be composed by two composers, A B - but it is known that, for example, only A composed the prelude and only B the overture, which are parts of that entire work? You wouldn't want to inherit both of the composers from the top level work in that case. Exactly, I wanted to give a similar example with composition date. I've seen a lot of examples where the movements have exact composition dates (e.g. 1874-1876 and 1877-1878) and the entire work has 1874-1878. So here the entire work kind of inherits the composition dates from the contained sub-works. So I don't really see the benefit of just blindly copying ARs... Johannes ___ 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
Re: [mb-style] RFC-339: Partial Works Relationship Inheritance
I don't think your proposed Style/Work/Partial Works Relationship Inheritance page belongs under Style as it's currently written. The Style pages are intended to simply be guidelines saying how editors should enter data and nothing more. From what I understood of the proposal, that could written as one sentence along the lines of When a work has parts, any relationships that apply to all sub-works should only be added to the parent work. I also agree with Calvin and think we need server support before inheriting relationships before adding a guideline like this. Instead of attempting to get the server, the search server and anything else using MusicBrainz data to implement the same version of inheritance, perhaps what we really need is a better way of adding/editing relationships. Would this still be a problem if we improved relationship editing so that, for example, we were able to add/edit relationships for a work and all its sub-works at the same time? Regarding your Artist Role Inheritance question on the wiki page, I wasn't the one who deleted it, but it was marked as a failed proposal and we already have http://wiki.musicbrainz.org/Style/Relationships#Crediting_an_artist.27s_role_at_the_track_vs._the_release_level as part of the official guidelines. By the way, please make actual pages for the pages you're proposing rather than embedding the changes you want to make within a single page. Nikki Jim DeLaHunt 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
Re: [mb-style] RFC: Remove Merchandising Provider Relationship Type
Well, since nobody else seems to care either way, I'll give this a +1 :P Nikki Nicolás Tamargo de Eguren wrote: The sheer uselessness of this relationship amazes me (and surely also the people -who only used it 55 times- AND even its proposer, seeing that The purpose of this Relationship Type is unknown.) I'd gladly see it removed. Alternatively, if someone feels this should be kept, please counter-proposal this with an update with description, purpose and examples :) http://wiki.musicbrainz.org/Merchandising_Provider_Relationship_Type ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Reduce the requisites for Live Performance Relationship Type
jacobbrett wrote: * Radio, TV, and internet-streamed performances are considered to be 'live'. * This relationship type should not be used to link from compilations of live performances, nor should it be linked to box sets. * The song order of the live release does not have to match the song order of the studio release. * At least 80% of the tracks from the studio release must be present on the live release. * At least 80% of tracks on the live release must be present on the studio release. * For either of the above two guidelines, the 80% requirement may be lowered if sufficient reason exists, subject to agreement by voters. I think it may be worth keeping the above guidelines, though the 80% rules are a bit superflous. What about something like The original and live releases should contain mostly the same songs? (instead of the last three bullet points) Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
