Re: [mb-style] RFC: Percussion and string instruments
Simon Reinhardt wrote In the instrument tree I would like some of the generic terms changed to the way they are mostly credited on releases: - percussion instruments - percussion - string instruments - strings Those generic terms have two interpretations: as the label for a category of more detailed instrument names, and as a non-specific term to use in performance Relationships. Should these terms be used in performance Relationships at all, or should they only be labels for a category? And in fact, how often are they used in performance Relationships? The present wording sounds fine to me if they are labels for a category. The proposed wording sounds like an improvement only for using them in performance Relationships. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-Percussion-and-string-instruments-tp7095474p7096408.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-345: Extend License Relationship to recordings
Aurélien Mino wrote On Wed, Dec 14, 2011 at 10:36 PM, Johannes Weißl lt;jargon@gt; wrote: However, release level links should always be preferred if possible. For the record, this goes against the Prefer Specific Relationship Types principle [1]. Which means some inconstancies in guidelines if we go that way. - Aurélien [1] http://wiki.musicbrainz.org/Advanced_Relationship_Style#Prefer_Specific_Relationship_Types Actually, this is not how I interpret the Prefer Specific Relationship Types principle [1]. I think the principle guides the choice between Relationship Types, e.g. between Arranger [2] (more general) and Orchestrator [3] (more specific). See the examples in the principle explanation. Johannes is proposing guidance a choice between targets of the License Relationship Type specifically, not between two different Relationship Types. [2] http://wiki.musicbrainz.org/Arranger_Relationship_Type [3] http://wiki.musicbrainz.org/Orchestrator_Relationship_Type -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-345-Extend-License-Relationship-to-recordings-tp7095229p7096421.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] Genre support
Lukáš Lalinský wrote ...We already do have tags, the majority (but not all) of which are genres. What I proposed here was a layer above the tagging system, which just helps people to give some meaning to the tags that we already have What I want is to define what kind of genres are there, how are they related and what tags people usually use to represent them. With this information you can say that the tags hip hop, hiphop, rap, usa are in fact mentioning only one genre - Hip-Hop. You can also say from tags psytrance and psy-trance that both represent a genre called Psychadelic Trance, which has its origins in Trance, which is a style of Electronic music. It would help me if MusicBrainz had some basic genre tags, because my music players have a genre field, and I'd like to have this populated by something which divided my music files into broad groups. There's a difference between an opera aria and a spoken book chapter, and it would help me if the music files had a genre field to say which is which. Lukáš, I understand that you want entities that correspond to genre and which can have multiple tags giving multiple names for the genre. But I think some of the problems with genre grow out of more multiples in connection with genres: There are multiple definitions for what the boundaries are for a genre. You and I might draw the boundaries between Psychedelic Trance and Goa Trance slightly differently. One's view of where the boundaries are might depend on how expert one is about the genre. Any given work could be associated with multiple different genres, partly because different people define the genre boundaries differently, partly because some boundaries are judgement calls, partly because some works are hybrids of multiple genres. Any given artist could be associated with multiple different genres, partly because different people label the genre of a given recording by that artist differently, partly because artists do different music from time to time. One thing I like about MusicBrainz is that it wades into complicated, subjective areas of music metadata, and comes up with Style guidelines which are surprisingly objective and useful. The challenge for genres in MusicBrainz is coming up with ways to deal with all these subjective and multiple aspects. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/Genre-support-tp7086589p7092728.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-345: Extend License Relationship to recordings
jw wrote This is a really small RFC to extend the newly introduced License Relationship Type [1] to recordings. This is necessary to specify the license for standalone recordings or for mixed-license releases [1] http://musicbrainz.org/doc/License_Relationship_Type Wiki page: http://wiki.musicbrainz.org/Proposal:Extend_License_Relationship_To_Recordings Expiration date: Wed, 21 Dec 2011 22:00:00 UTC Ah, but small changes can have large consequences. Issue 1. The Description field should explain more clearly when to apply the License relationship to a Release and when to a Recording. Does a License Relationship applied to a Release apply to every Track and Recording on that Release? What if there is a License Relationship at both the Release level and the Recording level, which takes precedence? I could make a try at writing a draft Description if you'd like. Issue 2. Should Licensing really be attached to a Recording? It seems like a Track would be a better target. The license is a matter of the business arrangements when a recording gets fixed onto a specific medium and released. The recording itself has no business arrangements. Issue 3. What if Release Rel1 and Release Rel2 both include Recording R, and each Release has a mix of different licensing arrangements for its tracks, and each specifies a different license for Recording R? -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-345-Extend-License-Relationship-to-recordings-tp7095229p7095336.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-319: Add warning about conductors/choir masters to Member of Band
+1 Nicolás Tamargo de Eguren wrote Hi! I am resurrecting an old RFC, because it seems to me that it makes sense. It adds the following paragraph to Member of Band RT: The conductor or chorus master of a group is almost never also a member of that same group. The Member of Band relationship should only ever be used to link a conductor or chorus master to the conducted group if that person is credited as a member of the group; it should never be assumed without such evidence. ... http://wiki.musicbrainz.org/Proposal:Member_Of_Band_Relationship_Type_modification This should go to RFV on Tue, Dec 20. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-319-Add-warning-about-conductors-choir-masters-to-Member-of-Band-tp7089487p7092631.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-341 CSG Recording parts Relations (+1)
I think JW has identified the crucial difference between the pop music idea of compilation and Sebastian's idea of Recording parts relations, namely the difference between: a. One long recording presenting multiple short complete Works b. Multiple short recordings presenting pieces of one long Work jw wrote This is a very interesting problem indeed, because technically both ARs describe the same thing (multiple recordings appear one after another in another recording, completely unaltered = no crossover mix), while semantically they are different. To summarize: 1. In pop music, works (= songs) are usually short, and we often have multiple works in one recording 2. In classical music and for audiobooks/audioplays works are usually much longer than CD tracks, so works are split into multiple tracks The compilation AR would be technically correct, but not semantically, since a newly created standalone recording would not be the compilation of multiple distinct works. I'm not satisfied that this discussion has worked out the relationship between the ideas of recordings, works, and compilations yet. I'm also not satisfied that the value of this change to MusicBrainz contributors and users is clear enough. Nor is the list of changes which would be required in MusicBrainz software in order to deliver this value. I am in favour of continuing to think this proposal through, and explaining it better in the proposal text, before we let it out of RFC status. That's why I'm not giving a +1 yet. I realise that my own RFC-339 proposal is encountering similar difficulty. I sympathise. But not all proposals are simple or easy. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-341-CSG-Recording-parts-Relations-tp7006175p7092685.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] RFV-343: Add 歌詞タイム to Lyrics Whitelist
+1 What the heck, just to be clear. Calvin Walton-2 wrote This is the RFV continuation of my RFC published at http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-November/014122.html I have now upgraded it properly to full proposal status - there is an RFC number and a proposal page and everything! Check it out at: http://wiki.musicbrainz.org/User:Kepstin/Proposal:Add_%E6%AD%8C%E8%A9%9E%E3%82%BF%E3%82%A4%E3%83%A0_to_Lyrics_Whitelist -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFV-343-Add-to-Lyrics-Whitelist-tp7056193p7062657.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] RFV-337: Add 'solo' performer relationship attribute
Alex Mauer wrote This is RFV-337[1]. It will expire on 2011-12-02. This proposal adds a 'solo' attribute to the performer relationship type In response to comments on the RFC, I have changed the description to only apply this attribute in cases where there is an actual credit listing a solo performance, rather than leaving it up to editor judgement etc. 1. http://wiki.musicbrainz.org/User:Hawke/Proposal/Performer_solo +1. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFV-337-Add-solo-performer-relationship-attribute-tp7047649p7052111.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: Add 歌詞タイム (kasi-time.com) to the Lyrics whitelist
Jim DeLaHunt wrote I'll have a go at sending this email. I'm not a native speaker, but I can probably put together a comprehensible request for permission. Permission email received. Noted at http://wiki.musicbrainz.org/Talk:Style/Relationships/URLs/Lyrics_whitelist#Kasi-time.com_permission . -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-Add-kasi-time-com-to-the-Lyrics-whitelist-tp7023016p7052117.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: Add 歌詞タイム (kasi-time.com) to the Lyrics whitelist
Jim DeLaHunt wrote Calvin Walton-2 wrote ... Our proposal procedure requires that we obtain written/email permission to link to the page. I am not confident enough in my knowledge of Japanese to be able to write such an email, and I'm not sure what the best way going forwards with this would be. Does anyone know someone fluent in Japanese who could help? The contact address is listed on their help page at http://www.kasi-time.com/info/index.php I'll have a go at sending this email. I'm not a native speaker, but I can probably put together a comprehensible request for permission. I sent an email to the site's contact address just now. I made a note of the contact at http://wiki.musicbrainz.org/Style/Relationships/URLs/Lyrics_whitelist#Sites_Which_Have_Been_Contacted . By the way, I think the process is that you should create a proposal page with an RFC number for adding this site to the whitelist, following the instructions at http://wiki.musicbrainz.org/Proposals#Special_Procedures . I didn't see an RFC number in this thread. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-Add-kasi-time-com-to-the-Lyrics-whitelist-tp7023016p7042057.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
[mb-style] Skipping RFC numbers for proposals [was: Re: RFC: Add 歌詞タイム (kasi-time.com) to the Lyrics whitelist]
Nicolás Tamargo de Eguren wrote On Tue, Nov 29, 2011 at 10:32 AM, Jim DeLaHunt lt;from.nabble@gt; wrote: ... By the way, I think the process is that you should create a proposal page with an RFC number for adding this site to the whitelist, following the instructions at http://wiki.musicbrainz.org/Proposals#Special_Procedures . I didn't see an RFC number in this thread. :) RFC numbers are not really used too often because they're seen as kind of a PITA, especially for small things like this - I mean, does it make sense to make people actually add a wiki page and all for such a small thing? It can all be added to the whitelist when/if it passes, which sounds like the only wiki page important enough to change... I love the idea of making a simpler, lightweight process for simple changes. Unfortunately, neither the rules for the regular process http://wiki.musicbrainz.org/Proposals#Process_for_Idea_Champions , nor the special procedures for Has Lyrics At http://wiki.musicbrainz.org/Proposals#Special_Procedures offers that possibility. Interestingly, the regular process does not call for assigning numbers to RFCs either. It should; I think numbers are a good way to track and refer to RFCs. We do our editors a disservice when we change the process without changing the written description of the process. We end up with a system that you can only participate in if you live on mb-style. And I know of many good editors who would rather not live on mb-style. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-Add-kasi-time-com-to-the-Lyrics-whitelist-tp7023016p7044811.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: Add Multiple Scripts support to Style/Release
Nicolás Tamargo de Eguren wrote Nikki proposed changing If several scripts are used on a release, choose the most common script (there is no 'Multiple Scripts' choice) to If several scripts are used in the titles, choose the most common script. For releases where there's an equal mix of two or more scripts and hence no obvious answer, 'Multiple Scripts' may be the best choice. That leaves the rest of the paragraph unchanged... +1 Nicolás Tamargo de Eguren wrote Now that the adding of Multiple Scripts has passed, we need to modify http://wiki.musicbrainz.org/Style/Release#Language_and_script (yeah,I should have noticed before and sent these two together :/ ) Actually, as I read http://wiki.musicbrainz.org/Proposals#Process_for_Idea_Champions , there doesn't seem to be a good way to propose changing multiple pages at once. So what you did here -- change the policy first, and then change the documentation to suit -- seems the best that the Proposal process allows. And, there's a lot to be said for proceeding step by step, making small changes. Complex, multi-part changes have more pieces to get stuck in discussions or vetoes. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-Add-Multiple-Scripts-support-to-Style-Release-tp7037774p7041422.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] Are string quartets chamber orchestras?
Rupert Swarbrick wrote I hope this is the right forum for this question... It is! Welcome, and thank you for contributing to MusicBrainz. Rupert Swarbrick wrote If you have a look at the relationships page for your favourite string quartet (eg [1]) you'll see various types of relationships. First, there's instrument, which presumably means someone incorrectly used the performed instrument relationship and didn't get work out how to put the magic vln/vln/vla/cello into the box... Secondly, you see performer, which is bland, but definitely correct (if not as precise as one might like) Thirdly, you see performing orchestra. It seems that many people are entering relationships with string quartets as orchestra performed (and usually ticking the chamber box). This seems utterly bizarre to me, but I thought I should ask whether anyone knows a good reason to do it. [1] http://musicbrainz.org/artist/598063d1-1fc6-496a-8e91-2c21c38d8c92/relationships For me, the important distinction is: An Artist of type Person plays an individual musical instrument: violin, drum, etc. An Artist of type Group plays as a musical ensemble: orchestra, choir, etc. Performer types of Performer and Instrument are headings, and I think should not often (if ever) be allowed in Relationships. But our current code permits them in, so editors use them. A string quartet is of type Group, so it should be listed as playing as an ensemble. Of the options we have today, Orchestra, chamber is the best approximation. But I think you are pointing out that it might be good to add other options, similar to Orchestra, for small ensembles. We could make them attributes of Orchestra, like chamber is. Or we could add an entry for small ensemble or quartet. Thank you for pointing that out. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/Are-string-quartets-chamber-orchestras-tp7037362p7041455.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] RFC2-340: Improve CC-license links
jw wrote I accept, although it is really not important at all (it is just used in the documentation). How about: This links a release to a license under which it is available. Reasons: ... * I left out URL, because almost all summaries from this class [1] don't have it. It is clear from the type of the entities involved. * I started with This links also because this is the wording for most relationships in [1]. [1] http://musicbrainz.org/doc/Category:External_Information_Relationship_Class Oh, I get it. You are proposing text to be added to http://wiki.musicbrainz.org/Category:External_Information_Relationship_Class to describe the new License Relationship. I think the change to Category:External_Information_Relationship_Class should be another bullet point in the list at http://wiki.musicbrainz.org/Proposal:Improve_CC-license_links#Proposal . We're now up to 4 parts to the proposal. I agree this wording is fine for Category:External_Information_Relationship_Class . It's not complete, though. You also need to have some examples of the Relationship text, e.g. Release is licensed under URL . And it was this relationship text which I thought the previous discussion was about! In other words, the relationship text at http://wiki.musicbrainz.org/User:hrglgrmpf/License_Relationship_Type . You presently have: Release is licensed under URL URL is a license for Release How about: Release is licensed under terms given at URL URL gives license terms for Release Maybe the previous discussion was the text under description heading in the the new License_Relationship_Type page. The last suggestion I saw was to have the Description text be something like, This relationship states that a copyright licence applies to the release. It links to a URL where the text of this licence can be found. I think that's a good level of detail for the relationship Description. Also, you have an attribute description for License_Relationship_Type, and say it should be empty. I see that other Relationships in the External_Information_Relationship_Class also have an attribute description but say it should be empty. Does anybody know why we can't simply hide this attribute instead? -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFV-340-Improve-CC-license-links-tp7024689p7041515.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: Add 歌詞タイム (kasi-time.com) to the Lyrics whitelist
Calvin Walton-2 wrote ... I would like to propose adding http://www.kasi-time.com/ to the whitelist for permitted lyrics sites. They specialize in J-POP and music from Japanese Anime and games. ...They are licensed by JASRAC in Japan to host the lyrics, and list their JASRAC member code at the bottom right of their home page. +1 Calvin Walton-2 wrote ... Our proposal procedure requires that we obtain written/email permission to link to the page. I am not confident enough in my knowledge of Japanese to be able to write such an email, and I'm not sure what the best way going forwards with this would be. Does anyone know someone fluent in Japanese who could help? The contact address is listed on their help page at http://www.kasi-time.com/info/index.php I'll have a go at sending this email. I'm not a native speaker, but I can probably put together a comprehensible request for permission. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-Add-kasi-time-com-to-the-Lyrics-whitelist-tp7023016p7032264.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] RFV-340: Improve CC-license links
I support the intent of this prospal. However, does the fact that we are discussing the wording for the License Relationship Type part of the proposal indicate that it's a bit early for RFV? Instead, should we move back to RFC until the wording is clarified, and then try for RFV? Rupert Swarbrick wrote This links a release to a URL containing the text of a copyright license which applies to it. Any comments from (other) native speakers? I have no problem changing the text. Maybe: This relationship states that a copyright licence applies to the release. It links to a URL where the text of this licence can be found. ... -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFV-340-Improve-CC-license-links-tp7024689p7032290.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: Add Multiple Scripts to the script list
Nikki-3 wrote: Jim DeLaHunt wrote: But we don't really appear to have a style guideline for the Release Language and Release Script fields... Style guidelines are either under Style/ or on relationship type pages: http://wiki.musicbrainz.org/Style/Release#Language_and_script Right you are, Nikki. We do have a Style guideline for Release Language and Release Script, and it answers my concerns about not using Multiple Script for ordinary Japanese. I didn't find that text because I searched for Release Script, which doesn't appear there. I'm happy. Obviously if we adopt a Multiple Scripts option for the script list, then someone needs to make a proposal to reword that paragraph. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-Add-Multiple-Scripts-to-the-script-list-tp6993791p7011826.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: Add Multiple Scripts to the script list
Nicolás Tamargo de Eguren wrote: We already have a Multiple Languages option, but we lack Multiple Scripts, which applies to several of the same places where we use multiple languages (it's not too strange to have Japanese scripts, Cyrillic or Arabic in the same release as Latin). So this is just asking for us to add that to the script list. For an example of a clear Multiple Scripts release, see http://musicbrainz.org/release/575f1987-e61c-49cb-8c95-92b6b42b6700 +1 I wish we had a style guideline for how to fill out the Release Language and Release Script fields, because I would like to see a caution added there about Multiple Scripts: If a Release has titles in a language which features multiple scripts, then use that language's script instead of Multiple Scripts. This matters particularly for Japanese, where the four scripts Han ideographs, hiragana, katakana, and Latin letters are routinely used together. But we don't really appear to have a style guideline for the Release Language and Release Script fields. http://wiki.musicbrainz.org/How_to_Use_the_Release_Editor mentions the fields in passing. There is a red link to a non-existant page http://wiki.musicbrainz.org/?title=How_To_Add_Script_And_Language . But no real good place to write this down, at the moment. So I'll make a note here, and hope it doesn't get completely lost. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-Add-Multiple-Scripts-to-the-script-list-tp6993791p7010566.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-340: Improve CC-license links
jw wrote: Hello, this is a proposal to improve the situation for releases that are available under a Creative Commons (CC) or other free license. 1. Introduce a new License Relationship Type, which links a release to an official URL of the license (e.g. http://creativecommons.org/licenses/by-sa/1.0/). This has the benefit that exact versions of the license can be specified. 2. Obsolete the Creative Commons Licensed Download [1]. This can be done by either placing a note obsolete, do not use anymore, or by disabling new additions of this AR. Existing relationships should be converted by hand, or by a bot if possible (nikki wrote a script). 3. A drop-down list of some often used licenses (= license URLs) should be added to the Free Download [3] and Paid Download [4] Relationship Type. If a license is selected there, this results in two separate edits: - one for the pure download URL - one for the license URL This was suggested to make the process not more difficult as it was before. +1 -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-340-Improve-CC-license-links-tp6998925p7010571.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-337: Add 'solo' performer relationship attribute
Alex Mauer wrote: On 11/12/2011 03:44 AM, Jim DeLaHunt wrote: What is the definition of a solo? How can determine (without looking at credits) whether a performance counts as a solo or not? ... I'm not ready to +1 your proposal until it's clear enough for editors to agree whether a performance counts as a solo, in the case where there is no solo credit. I’m inclined to leave this undefined, i.e. up to the judgement of the editors/voters interested in the recordings in question, to determine ...whether the solo attribute works for that genre, and whether that particular instance qualifies as a solo itself. If there are disagreements, they could certainly brought to the list once we have a better idea how people tend to use this attribute. What do you think of that idea? I'm sorry, but I think it would be a mistake to a make a proposal that adds an attribute but fails to define how editors should use that attribute. (To be specific: saying the solo attribute applies if there is a solo citation is clear enough, but saying that the attribute applies if an artist performed a solo part, without definition, is not acceptable.) I agree it's hard to write such a definition. If you, the proposer, finds solo hard to define, then it will be much worse for everyone else using the database. What is the chance that two editors will agree on whether a specific performance counts as a solo? What is the chance that a database user tomorrow will understand what a contributor today means by solo? If a definition is hard, improve the proposal or withdraw it. Don't throw the problem into the laps of future editors. That, at least, is my opinion. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-337-Add-solo-performer-relationship-attribute-tp6905622p7010587.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: Remove Travel Agent Relationship Type
Nicolás Tamargo de Eguren wrote: Another not-truly-musical, pretty random relationship. Used a grand total of SIX times. I think it's pretty safe to merge this one into miscellaneous roles (and maybe extend that one to artist-RG, as it's not available at that level now) or just remove it completely. http://wiki.musicbrainz.org/Travel_Agent_Relationship_Type +1 -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-Remove-Travel-Agent-Relationship-Type-tp6987088p6987688.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: Work/Relationship Inheritance in Works Trees
Frederic: Thanks for your comments and questions. I'll try to answer them one by one. At 4:20 AM -0800 11/11/11, Frederic Da Vitoria [via MusicBrainz mailing lists] wrote: 2011/11/9 Jim DeLaHunt /user/SendEmail.jtp?type=nodenode=6985185i=0[hidden email] (...) Sorry for answering so late. I think I understand what you are trying to achieve and I agree it has to be done. Here are my comments. Indivisibility: what about the famous Mozart Requiem? Does this mean that nobody composed it since nobody composed all of it? Well, don't confuse claims about music with the rules for interpreting MusicBrainz structures. Let's consider claims about music. What answer should MusicBrainz give to the question, Who composed the famous Mozart Requiem? a) Nobody composed the Requiem. b) Mozart composed parts of the Requiem, but did not compose the rest. c) Mozart composed the Requiem, and we refuse to comment about whether he composed all of it or just part of it. d) Mozart composed all of the Requiem, and we refuse to comment about some confusing second composer. e) we give Mozart a Composer credit for all of the Requiem, and we give another person Additional Composer credit for part of the Requiem f) we give Mozart a Composer credit for all of the Requiem, and we also give another person Additional Composer credit for all of the Requiem RFC-339 is about how to interpret Relationships and Work entities. Right now, MusicBrainz can only give the answers a) or c). RFC-339 clarifies the rules for interpreting MusicBrainz structures, so that MusicBrainz editors can choose between answers a), b), d), e), or f). All of Child inherits(...): why do you exclude exceptions ? If developers can implement it, it would probably be nice. At least, we should try to think how it should work and if we manage to do it, let the developers decide if it could be achieved at a reasonable cost. I exclude exceptions because I'm trying to make RFC-339 the smallest step I can. Yes, Relationship exceptions would be nice to have in MusicBrainz. Let's do that as a later step. - if the child relation applies to all of Parent, then wouldn't the AR better be set to the Parent, thus avoiding multiple ARs to the children?... Maybe so. But changing the location of an AR is an editing action. RFC-339 is rules for interpreting the AR+Works structure as it exists. It lets editors agree what it means to have an AR attached to a child, and what it means to have the AR attached to the parent. ... In other words, can anybody imagine a situation where a Child AR would apply to all the Parent but not to the siblings? If I am right, I guess the and maybe or maybe not all would better be removed The reason for the wording, maybe or maybe not all, comes from a limitation of Works Trees made with the Parts Relationship Type. A parent Work has a set of child Works, but there's no way to tell if this set represents *all* of the parent. Imagine a parent Work for an opera, and 3 child Works for Acts I, II, and III. MusicBrainz has no way to indicate that there are only 3 acts, that there is no Act IV in the opera which is missing from MusicBrainz. If all existing child Works have the same AR applied, maybe that AR applies to all of the parent Work. Or maybe there's a child Work missing from MusicBrainz, and the AR does not apply to the missing child Work, and thus it applies to only part of the parent Work. Discussion: Software which reads(...) I disagree here. I believe only the server should know and apply the inheritance mechanisms, and he should send data to the client applications as if the inherited ARs physically existed. Requiring client applications to implement inheritance themselves would mean increasing the difficulty of using correctly MB data. So I fear that developers would avoid implementing inheritance. Furthermore, implementing on the client's side would require some processing power. If some day some developer creates a MB-aware music player for smartphones, I am not sure the hardware will be up to this. I understand your point. I agree, it would be good if the server could apply the inheritance mechanisms, and give client software lists of relationships with all inheritance. I have a plan to propose exactly this extension to the MusicBrainz web services API, partly to prove that inheritance is practical and partly to save the work for clients. But some software doesn't use the server software, it reads the database directly. The rules should say what such software is supposed to do. Whether the software does the work or not is a decision for that product's developers. Thus, I think RFC-339 should say that these rules apply to all software. Let's hope that most software can take advantage of an implementation in the MusicBrainz server, so it's easy for them to comply. Thank you for your various suggestions on improving the wording. I have a rewording under way, and I'll see
Re: [mb-style] Making edit note for Add release mandatory
jw wrote: Hello! I know that it is not directly a style issue, but anyway: What do you think of making an edit note mandatory for Add release edits? It is always annoying for me to vote on such edits. A simple CD in hand or an URL is certainly not too much asked. I agree that you've identified a problem. I don't think you've found a very effective solution. If the software refuses to accept a blank edit note, then it won't take the lazy editor long to discover that typing x or . in the edit note space gets accepted. If you want the software to insist on a real edit note, it gets hard to specify what the software should check for. Some alternative solutions to the problem: 1. when you review the edit, either Abstain or vote No, and post a comment that you are declining to vote Yes because there is no edit note. The editor who cares will read the voting comments, and learn the lesson that edit notes matter. 2. change the editing software to make it easier to add stock comments like I have this Release in my hand or Evidence at URL [fill in the blank]. 3. change the voting software to make it easier to add in repetitive comments like those suggested in #1. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/Making-edit-note-for-Add-release-mandatory-tp6981599p6987704.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-337: Add 'solo' performer relationship attribute
Alex Mauer wrote: On 11/02/2011 10:48 AM, Frederic Da Vitoria wrote: ... Not excluding this would allow users to enter the wrong solos which symphonick showed, wouldn't it? Nothing prevents people from entering wrong credits, except the voters. They will have to do their jobs, as they do for every other edit made. It's not just the voters that prevent people from entering wrong credits. Well-written Style guidelines probably have an even bigger influence than votes, because they improve the edits which get made but never get auto-accepted after no-one gets to them in the voting queue. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-337-Add-solo-performer-relationship-attribute-tp6905622p6987710.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-337: Add 'solo' performer relationship attribute
Alex Mauer wrote: On 11/02/2011 12:38 PM, Jim DeLaHunt wrote: ... If no Release ever give a performance a solo credit, then how can you be sure that the solo attribute is Artist Intent and not editor trying to rewrite history? ...It’s not a question of artist intent, but one of fact. If someone performed a guitar solo in a musical piece, they did, period. ... What is the definition of a solo? How can determine (without looking at credits) whether a performance counts as a solo or not? On this question, your proposal says only, an artist performed a solo part, and doesn't define what solo means. I thought you were moving to a definition of an artists performed a solo part if there was a moment in the recording when they were the only one making a sound, but from later posts I'm thinking you are closer to Frederic Da Vitoria's definition, solo means prominent. I'm not ready to +1 your proposal until it's clear enough for editors to agree whether a performance counts as a solo, in the case where there is no solo credit. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-337-Add-solo-performer-relationship-attribute-tp6905622p6987732.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: Work/Relationship Inheritance in Works Trees
Parent and Child Works. A Medley relationship gets inherited between Parent and Child Works. But an is Part of relationship does not get inherited between Parent and Child Works. Example of Composer relationship getting inherited: 1. Beethoven composed the Symphony. Therefore, Beethoven composed the first movement. Example of Parts relationship making no sense to inherit: 2. Movement is part of Symphony. Therefore, Movement is part of Movement. That said, I'm 100% in favor of the concept as I understood it (and still do globally, I think) that we should have inheritance rules between entities (in this case work-work) so that can minimize data entry, reduce useless duplicate ARs (thus reducing errors), etc... ... Excellent. Let's agree on RFC-339, then use it as a foundation for the many improvements we need. Sebastien On Mon, Nov 7, 2011 at 7:48 PM, Jim DeLaHunt /user/SendEmail.jtp?type=nodenode=6976897i=0[hidden email] wrote: At 1:04 AM -0800 11/7/11, symphonick [via MusicBrainz mailing lists] wrote: IMHO it would be better if the page began with your proposal examples, and you could get into details further down. Judging from your responses to my other mail, I obviously don't understand exactly what you're suggesting here. Symphonick and swisschris: Thank you for your feedback. I'm getting the impression that the way I wrote the proposal text isn't communicating clearly. It's hard for me to improve this, because the text is clear to *me*. But I'll try. If the page begins like this, is it a big improvement? = Work/Relationship Inheritance in Works Trees When one Work entity (Parent) is linked to another Work (Child) with the Parts Relationship Type (Child is part of Parent), then each Work entity inherits the Relationships on the other Work entity. The inheritance rules are: 1. *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. 2. *All of Child inherits from Parent*. Any relationship to the Parent Work means that the same relationship applies also to the entire portion of the musical composition to which the Child Work refers (i.e., with full coverage). 3. *Some of Parent inherits from Child*. Any relationship to the Child 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. 4. *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. 5. *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. 6. *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. = Examples ...[more text goes here]... = Definitions ...[more text goes here]... = Discussion ...[more text goes here]... -- --Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant 157-2906 West Broadway, Vancouver BC V6K 2G8, Canada Canada mobile +1-604-376-8953 -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Work-Relationship-Inheritance-in-Works-Trees-tp6952822p6977309.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: Work/Relationship Inheritance in Works Trees
At 1:04 AM -0800 11/7/11, symphonick [via MusicBrainz mailing lists] wrote: IMHO it would be better if the page began with your proposal examples, and you could get into details further down. Judging from your responses to my other mail, I obviously don't understand exactly what you're suggesting here. Symphonick and swisschris: Thank you for your feedback. I'm getting the impression that the way I wrote the proposal text isn't communicating clearly. It's hard for me to improve this, because the text is clear to *me*. But I'll try. If the page begins like this, is it a big improvement? = Work/Relationship Inheritance in Works Trees When one Work entity (Parent) is linked to another Work (Child) with the Parts Relationship Type (Child is part of Parent), then each Work entity inherits the Relationships on the other Work entity. The inheritance rules are: 1. *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. 2. *All of Child inherits from Parent*. Any relationship to the Parent Work means that the same relationship applies also to the entire portion of the musical composition to which the Child Work refers (i.e., with full coverage). 3. *Some of Parent inherits from Child*. Any relationship to the Child 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. 4. *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. 5. *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. 6. *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. = Examples ...[more text goes here]... = Definitions ...[more text goes here]... = Discussion ...[more text goes here]... -- --Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant 157-2906 West Broadway, Vancouver BC V6K 2G8, Canada Canada mobile +1-604-376-8953 -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Work-Relationship-Inheritance-in-Works-Trees-tp6952822p6972719.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: recordings: remove remaster from the 'should not be merged' list
lorenz pressler wrote: http://musicbrainz.org/doc/Style/Recording ... # add: 3.2 remasters most remaster jobs just consist of some minor adjustment in volume and cutting silence. In these cases merging is valid and remastering credit should be added to the release only (not the recordings itself). If there is a real difference they should not be merged and it is mandatory to add a short disamiguation comment to the remastered recordings, detailed info can be added to the annotations. I don't have strong feelings on remastering Recording style myself. But I am recently getting strong feelings about helping other people get their RFC's into good shape, then approving them. What I take from the rest of this thread is that there are several cases where it's bad to merge remasters into the same Recording, and there are some cases where it's good. Your proposal says, most remaster jobs just consist of... , which appears to put the case where merging is good at the centre. Perhaps it would work better if it was more balanced between the cases. Maybe have a list of cases where merging is bad (different ISRCs, remastering to make a louder recording with less dynamic range for a loudness war, etc.) and where merging is good (minor adjustment in volume not for a loudness war, cutting silence). Also, the proper RFC should have a page with the new text of Style/Recording, so we can see it in context. If you could come up with something like that, I'd +1 it. Thanks for your contribution to MusicBrainz! -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-recordings-remove-remaster-from-the-should-not-be-merged-list-tp6963253p6973421.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: Work/Relationship Inheritance in Works Trees
At 6:18 AM -0800 11/6/11, jacobbrett [via MusicBrainz mailing lists] wrote: My first reaction to viewing the proposal page was to not bother reading through it, because it appears so wordy. If the text may not be condensed, could you add a simplified summary (bullet points?) of the proposal's main rules? Have a look at the section Relationship Inheritance Rules. Does that work as a simplified summary? It gives six precise rules, each 2-3 lines long. -- --Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant 157-2906 West Broadway, Vancouver BC V6K 2G8, Canada Canada mobile +1-604-376-8953 -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Work-Relationship-Inheritance-in-Works-Trees-tp6952822p6969193.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: Work/Relationship Inheritance in Works Trees (v.3)
symphonick wrote: It looks like you're suggesting that Mozart should be added as orchestrator? Maybe it should be stated that it's implied in composing. RFC-339 doesn't suggest that Mozart should be added as an orchestrator. You might be referring to one of RFC-339's examples, the Mozart Requiem. That is http://musicbrainz.org/work/e27bda6e-531e-36d3-9cd7-b8ebc18e8c53 . That's an example taken from real MB data. Some editor(s) put in both Composer and Orchestrator from that Work to Mozart. RFC-339 doesn't claim this is correct, just that it's an example of multiple Relationships to the same Work entity. The point RFC-339 is that multiple Relationships from the same Artist to the same Work is permitted by the MusicBrainz system. If those Relationships don't fit that Work, then someone should edit those Relationships. If the Composer relationship should imply Orchestrator, that should be explained at the Composer Relationship Type and Orchestrator Relationship Type . That's not what RFC-339 is trying to do. symphonick wrote: We need a way to remove an inherited AR for works like Pluto (not Holst). That might be very useful, but it's not the topic of RFC-339. RFC-339 is just trying to make the meaning clearer, for the Relationships and the Work Trees we already have. symphonick wrote: Actually, I'd like the UI to display some (optional) inherited-from-parts ARs on the root page, like librettists, even if they don't apply to all parts (instrumentals in operas similar). I'd like that too. But that's a feature request, not the subject of RFC-339. Let's pass RFC-339, and then let's work on the feature questions that follow from it. symphonick wrote: How will this page affect works outside of western classical? RFC-339 applies to all kinds of Work entities in MusicBrainz, classical and non-classical. However, it has no effect for Stand-Alone Works. I'll bet that most of the Work Trees are for classical music, opera, sound tracks, and a few concept rock albums. Outside of that, I'd guess most Works are stand-alone. symphonick wrote: This page doesn't seem to deal with when when not to create a new work. IMO we should define that first before getting into inheritance of ARs. When and when not to create a new work should be covered by the Work/Style guideline. This, sadly, doesn't exist yet. It would be good if we did have some good guidelines there. But we don't. What we do have, as of a few days ago, are 4440 Parts Relationships. Over 97% of the Work entities attached to these Parts Relations have other Relationships, like Composer. (Thanks, Nikki, for these statistics.) It would be a step forward for MusicBrainz if we had a clear rule for what those existing structures mean. If MusicBrainz never took steps forward in one place because we also needed to take steps forward in another place, we'd never take any steps at all. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Work-Relationship-Inheritance-in-Works-Trees-v-3-tp6966776p6969261.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
[mb-style] RFC-339: Work/Relationship Inheritance in Works Trees (v.3)
This is an updated RFC for RFC-339, Work/Relationship Inheritance in Works Trees. Expiration date for the RFC: November 12, 2011 (UTC) Summary: Define rules for how to read Relationships applied to Work Trees (multiple linked Work entities describing a single musical composition). Is neutral about where in a Works Tree editors should apply Relationships, since there are pros and cons to all suggested approaches. Will be a subpage of Work, not of Style/Work. The only changes in this revision are wording, not substance. Based on comments from the last RFC I went through the whole thing, trying to make the text clearer, and patching holes in logic. Proposal: http://wiki.musicbrainz.org/Proposal:Work/Relationship_Inheritance_in_Works_Trees Previous discussion: * [mb-style] RFC-339: Partial Works Relationship Inheritance and replies, started Fri Oct 28 10:57:43 UTC 2011, http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-October/013880.html * http://wiki.musicbrainz.org/Proposal_talk:Work/Relationship_Inheritance_in_Works_Trees has Motivation, Issues (including my comments on issues raised in mb-style discussion), Notes for follow-on RFCs from this one, and Further Reading. * [mb-style] MB does inheritance, just not on Parts Relationship Type, Jim DeLaHunt, Sun Oct 30 06:44:20 UTC 2011, http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-October/013911.html * [mb-style] RFC-339: Work/Relationship Inheritance in Works Trees, Jim DeLaHunt, Tue Nov 1 18:45:36 UTC 2011, http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-November/013940.html Thanks everyone for the good discussion. I think this proposal is much better for it. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Work-Relationship-Inheritance-in-Works-Trees-v-3-tp6966776p6966776.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
[mb-style] Practical Observations on Opera Tracks and Work entities
= Practical Observations on Opera Tracks and Work entities [This text, with hyperlinks and better formatting, is also at http://wiki.musicbrainz.org/User:JimDeLaHunt/Practical_Opera_Tracks]. The Work entity in MusicBrainz now exists. But we are told it's not yet fully formed, and we certainly don't yet know quite how to use it. A particular issue is how to use the Work entity to describe operas. Many of the issues also apply to other classical music compositions. To help the discussion along, here are some practical observations: real operas, with the track divisions from actual Releases of those operas. Just to be clear, my strong goal is to make it easier for editors to contribute data to MusicBrainz. Others may want to build an encyclopedia of music; I'm a data entry and music tagging person. A big obstacle is the complexity of the cultural tradition of classical music, which manifests itself in complicated metadata and a tangled, bewildering Classical Style Guide. I want to use the Work entity of MusicBrainz to make data entry easier. Others have different agendas. The Work entity might also turn out to be useful to scholars and musicologists making an encyclopedia of classical musical works. That's fine by me, but it's not my objective. = Case study: I Capuleti opera As a practical case study, I built a Works Tree for the opera I Capuleti e i Montecchi, by Vincenzo Bellini (http://musicbrainz.org/work/0a0bc66a-800b-465f-b112-e239f5bd3e17). There are at least four Releases of this opera in MusicBrainz at the moment, and I based my case study on the two Releases I recently added. This tree has a Work entity for the overall opera, and a work entity for each track start position I found in my Releases. Some of those Work entities correspond to composer-defined scene and aria divisions. But others are based on where Release producers chose to put track divisions. (I realise that I'm breaking the rules of the Parts Relationship Type with these, but it's what we'd need for simplifying data entry.) I linked my two Releases of I Capuleti e i Montecchi: I Capuleti e i Montecchi (Orchestra of the Royal Opera House feat conductor Riccardo Muti) (1984-04), and I Capuleti e i Montecchi (Wiener Symphoniker feat. conductor Fabio Luisi) (2008-04). This required going through each Recording of each Release, and creating a Performance relationship from Recording to child Entity. See an example child Work entity, I Capuleti e i Montecchi: Atto I. Sinfonia, with two Performance relationships. There turned out to be 46 child Work entities in the Work Tree. The Releases to which I linked had 36 and 41 tracks respectively, but some of the track divisions were different. Most of the Work entities applied to Recordings of both Releases, but some Work entities ended up specific to one Release or the other. Constructing the Works tree was tedious. To create a single child Work entity and link it to the root Work, I counted 16-17 user interface actions—clicks, menu selections, radio button choices. It took me several hours to complete the work. Think about it: a few seconds per UI action, times 16 actions; a half-minute or so per page submit, all times 46 child Works, adds up to a long time. I benefited from clever use of multiple browser tabs. A novice editor using the MusicBrainz interface in a straightforward manner would take several times as long. Knitting the Work Tree to the Recording Tree was quite tedious, for basically the same reasons. I gave up partway through the second Release. I did not add any Work entities corresponding to Acts or Scenes shown in the opera's score. I don't think that kind of structure helps with data entry (though I can appreciate it helps someone creating an encyclopedia of music). All my child Work entities are attached directly to the root, not to Work entities for each act. = Lessons learned *Setting Work entity titles to strings according to the Classical Style Guide and Opera Track Style Style works pretty well. *It seems opera Releases all make slightly different choices about where to put track divisions. We should expect each recording to have a few track divisions that differ from other recordings, and many that are pretty similar. *Even so, there is a lot of commonality. We can save editors a lot of effort by letting them re-use Work titles as Track titles. *Operas Releases have a lot of tracks, and so opera Works Trees will have a lot of child Work entities. Expect 30-50 children per opera. *We need some way of imposing a sequence on the Work parts of an opera. Alphabetic ordering by Work title gives wrong answers, e.g. Atto I. Sinfonia (the overture) sorts after Atto I, Scena I., but should come before; Scene IX sorts before Scene V. A sequence numbering across all the child Work entities in a tree would be sufficient. *Opera composers and score publishers use Act divisions pretty clearly and consistently. However, Releases do not
Re: [mb-style] RFC-339: Work/Relationship Inheritance in Works Trees
Hi, symphonick: symphonick wrote: Do you mean that Mozart can't be the composer for the parent work Requiem because it would mean that AR would end up on childs that M. didn't compose? It depends what meaning you want to convey. If what you want to say is, there is a musical composition Requiem, and nobody gets credit for being composer of the whole thing, but Mozart gets credit as composer of some parts and somebody else gets credit as composer of the other parts Then yes, Mozart can't be composer of the parent Work entity. However, take a look at the work entity 'Requiem in D minor, K. 626 (Süßmayr completion): I. Introitus: Requiem aeternam' (http://musicbrainz.org/work/e27bda6e-531e-36d3-9cd7-b8ebc18e8c53). It lists Mozart as Composer, and Süßmayr as Additional Composer. If you want to say that Mozart is the Composer of the composition overall, and Süßmayr is the Additional Composer of some movements... Then link Mozart as Composer to the parent Work entity, and link Süßmayr to child Work entities as Additional Composer. This may be one case where we have a conflict between a simpler popular understanding (Mozart wrote the Mozart Requiem) and a more historically accurate understanding (Mozart wrote most of some movements, only bits of others, and never finished it). symphonick wrote: The same thing for Holst Planets, added Pluto version? Again, what really matters is what meaning the editor wants to convey. RFC-339 doesn't try to extend the expressive power of MusicBrainz ARs, or to find a way to express complicated realities in simple terms. It just tries to make clearer what ARs in Work Trees actually mean. By the way, the ARs on the Süßmayr completion of Mozart's Requiem are a bit messy. See all the redundancy, and the different combinations of writers in the various Work entities: http://musicbrainz.org/search?query=Requiem+in+D+minor%2C+K.+626+%28S%C3%BC%C3%9Fmayr+completion%29type=worklimit=100 Thanks to your nudging, I've added another rule to RFC-339 (Inheritance status matters) and another Discussion point. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Work-Relationship-Inheritance-in-Works-Trees-tp6952822p6956147.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] Recording-level orchestration/instrumentation
Nicolás Tamargo de Eguren wrote: On Wed, Nov 2, 2011 at 2:29 PM, Nikki lt;aeizyx@gt; wrote: Hello Right now we have arranger on both works and recordings, but the sub-types for orchestration and instrumentation only exist on works. Should those relationships be added to recordings too? I would say yes. If in the future the decision is taken of allowing them only at work level, they could be easily migrated by work-splitting. +1 -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/Recording-level-orchestration-instrumentation-tp6955025p6956161.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-337: Add 'solo' performer relationship attribute
Hawke: Alex Mauer wrote: ... I’d rather not exclude the situation where the credits themselves don’t specify but other research does determine the correct artist who performed a solo. When and how would you expect this sort of situation to come up? One scenario I can imagine is: a 1950 LP release of a smokin' hot 1949 Duke Ellington Live concert. Exquisitely edited, detailed cover notes say Saxophone - Jim DeLaHunt (solo). Fast forward to 2011: budget label issues a digital remaster of this LP, but with cheap and shabby CD label that just says, Saxophone - DeLaHunt. In that case, someone who entered a Relationship based on the cheap and shabby CD label wouldn't include solo, but someone who later found the 1950 LP release would have grounds to add the attribute solo. I think this is a great opportunity for the editor to appeal to the Style Principles (http://wiki.musicbrainz.org/Style/Principle). Artist Intent and Most Common Version override Style Guidelines. If no Release ever give a performance a solo credit, then how can you be sure that the solo attribute is Artist Intent and not editor trying to rewrite history? -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-337-Add-solo-performer-relationship-attribute-tp6905622p6956207.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] Type of a Work? Re: RFC-339: Partial Works Relationship Inheritance
symphonick wrote: 2011/11/1 Jim DeLaHunt lt;from.nabble@gt; But I believe that MusicBrainz editors face a huge problem in contributing data on classical and opera music: the MusicBrainz structure doesn't do enough of the work of representing the complexity of naming classical and operatic music. I want the Works table to be part of the solution (NGS 'Works' should help cut CSG Gordian Knot, http://lists.musicbrainz.org/pipermail/musicbrainz-style/2010-December/010713.html ). When the rest of the system is ready enough, I will be proposing either a change to this rule for Parts Relationship Type ... But I don't really understand (maybe I missed something in the big thread): it's easier (and also more work) to always create a 1:1 recording - work, but what would you want this for? How do you want to display these works in the UI? By this I take it you mean: what would I want the Works table to do as part of cutting the CSG Gordian Knot? I would like to see expert CSG editors build up finely-crafted Work Trees for classical and opera works, with the Work titles that can be re-used as Recording or Track titles. Of course, the Work entities would have to correspond to track boundaries which recordings usually use. Then I'd like a Works-first Add Release wizard. This would let an editor, even one who doesn't know the CSG well, find the Work Tree that their Release presents, and move Work Titles into Recording Titles. From there, the titles become Track Titles. What would the UI be? A great question. We need to design it. Getting good Classical support for novice editors is a long road, we won't get there in one step. symphonick wrote: ...I'd also like us to try and finish a basic CSG works guideline first Agreed. When the rest of the system is ready enough. Including the relevant Style guidelines. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6956257.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
[mb-style] Override the same ARs? Difficult
Hi, folks: One comment that's appeared repeatedly in the discussion of Relationship Inheritance is that whether a directly attached Relationship could override the same Relationship inherited from elsewhere. I have a problem defining the terms override and same in the context of Relationships. MusicBrainz allows an editor to attach a second Relationship to an entity as long as it differs in some detail from the first. There can be two Composer Relationships from two Artists to the same Work entity. If both relationships are Composer Relationships, are they the same? Should one override the other? The basic relationships editor doesn't seem to think so. There can can be two Composer Relationships from the same artist to same Work entity, if one has a date and the other doesn't. Are these Relationships the same? Should one override the other? The basic relationships editor doesn't seem to think so. Maybe an example will help. This is a single Work entity, so there is no issue of inheritance. Requiem in D minor, K. 626 (Süßmayr completion): I. Introitus: Requiem aeternam http://musicbrainz.org/work/e27bda6e-531e-36d3-9cd7-b8ebc18e8c53 This Work has a Composer Relationship to Mozart, and a Additional Composer Relationship to Süßmayr. Are those the same? Should one have overridden the other? I think not. There are actually two Composer Relationships to Mozart. One has no dates, one has a date of 1791. Are those the same? Should one have overridden the other? In this case, I think yes. When the editor came to enter the second relationship, the software should have guided them to modify the first relationship instead. But suppose you want to express the meaning, Artist Composed this Work from 1788-1789, and also for a period in 1791? Should there be two Composer Relationships to the same Work entity, differing only in dates? The current Advanced Relationship scheme in MusicBrainz has limitations. There are things it would be nice to express that it can't right now. It might be nice to add a way to override an inherited copy of the same Relationship. I think it's possible to invent improvements to the current system. But it won't be easy to define the improvement, and say precisely what the details should be. No Reply Necessary (NRN), I just want to put that thought into our consciousness. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/Override-the-same-ARs-Difficult-tp6956331p6956331.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
Nikki-3 wrote: Jim DeLaHunt wrote: Is there a way to measure how good the data is?... There are, as I write this, 4440 parts relationships. If my queries were correct, there are: 4028 cases where both the parent and the child have a composer relationship. 202 cases where the parent does but the child doesn't. 100 cases where the parent doesn't but the child does. 110 cases where neither the parent nor the child have a composer relationship. Excellent! Thank you for these statistics. (I will sooner or later need to install my own copy of the database, I think.) -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6952380.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] Type of a Work? Re: RFC-339: Partial Works Relationship Inheritance
Nicolás Tamargo de Eguren wrote: I suspect a lot of people aren't going to agree with Performer division being a work. See http://musicbrainz.org/doc/Parts_Relationship_Type This relationship should only be used for works where the composer split a work into multiple parts... I understand. The current rules in the Parts Relationship Type make sense in terms of using the Works table for music scholarship. But I believe that MusicBrainz editors face a huge problem in contributing data on classical and opera music: the MusicBrainz structure doesn't do enough of the work of representing the complexity of naming classical and operatic music. I want the Works table to be part of the solution (NGS 'Works' should help cut CSG Gordian Knot, http://lists.musicbrainz.org/pipermail/musicbrainz-style/2010-December/010713.html). When the rest of the system is ready enough, I will be proposing either a change to this rule for Parts Relationship Type. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6952523.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] Merging the theatre relationships?
Nicolás Tamargo de Eguren wrote: Hi! An user has added this to the wiki: http://wiki.musicbrainz.org/Talk:Proposals#Theatricalia I was wondering if this was a good time to merge the two (pretty unused) IBDB and IoBDB relationships into one with a more neutral name, which would also allow adding links to this Theatricalia site or other theatre databases. We could still make them appear as IBDB or IoBDB or Theatricalia or whatever on the sidebar, the same way we do with Facebook (we don't have a specific Facebook relationship). IBDB (Broadway database) and IoBDB (Off-Broadway database) are two members of the External Website Relationship Class (http://wiki.musicbrainz.org/Category:External_Website_Relationship_Class). Every relationship in this class is to URLs at a specific named website. There is also the External Information Relationship Class (http://wiki.musicbrainz.org/Category:External_Information_Relationship_Class), which is relationships to URLs containing certain kinds of information (biography, discography, fanpage) at any web site. Finally, the all-purpose escape valve for recording URLs about an entity is the Annotation; editors can put anything there. So, I think the easy question for me is whether we should merge the IBDB and IoBDB relationships? I'd say No. Relationship Types of the External Website Relationship Class refer to specific sites. The next question for me is whether to add Relationship in the External Website Relationship Class for Theatricalia. What would be the benefit? We could conclusively link Artist records in Musicbrainz with the corresponding artist record in Theatricalia. We might be able to link soundtrack Releases with the theatre production which created the soundtrack. But is Theatricalia extensive enough, and likely to persist long enough, to make it worthwhile to create connections? There might be value in creating a Has Entry in Other Database Relationship in the External Information Relationship Class. This would let editors make connections between MusicBrainz entities and the corresponding entities on other databases, without having to create a Relationship Type for each new database. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/Merging-the-theatre-relationships-tp6946577p6947231.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: declaring neutrality on where in Parts tree to attach Relationships
jw wrote: What exactly will be changed by RFC-339 now, or is it put on ice for now? What is still changed by RFC-339 now is interpretation: we will have a written MusicBrainz rule about what Relationships inherit to one Work entity when it is attached by a Parts Relationship Type to another Work entity. The humans of MusicBrainz can begin to interpret using this rule immediately, even if the software takes a while to adopt it. This will be helpful to all of us in cases where editor chose to put Relationships on the leaf partial Works, but skipped the root Work; or if the editor put the Relationship only on the root and skipped the leaves. RFC-339 is most definitely not put on ice. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-declaring-neutrality-on-where-in-Parts-tree-to-attach-Relationships-tp6946544p6948827.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
[mb-style] LMFAO reltype census [was: Re: RFC-339: Partial Works Relationship Inheritance]
Nicolás Tamargo de Eguren wrote: There are at the moment 4352 part of relationships, according to http://mb.lmfao.org.uk/reltype (the number can be a bit old as I don't know how often this is updated). Wow, this is a useful page! I had done a similar census a long time ago, as a static report (http://wiki.musicbrainz.org/User:JimDeLaHunt/AdvancedRelationshipsCensus). It's great to see that someone did it as a live report. Right now, I think 12 hours after your email, the page reports 4386 part of relationships. So the page appears to be updating. Thank you for sharing this link! -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6946304.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
[mb-style] RFC-339: declaring neutrality on where in Parts tree to attach Relationships
Hi, everyone. Thanks for the great discussion about where best to attach Relationships in a tree of Work entities with Parts relationships. Formalising inheritance rules brings the issue into focus, and I think that's good. After some thought, I've concluded that it's unnecessary for RFC-339 to take a stand on this issue. We should instead leave the choice of where to attach Relationships to the good judgement of editors. Editors who have a usage pattern where Relationships on the leaf matter will attach to the leaf. Editors who want to make one entry and have it apply to the whole tree will apply to the root. These choices will change as MusicBrainz software starts to support inheritance. Eventually the time will be right for a Style guideline to prefer Relationships low or high or all over a Work tree. At that time, we will probably be able to write some kind of bot which will take existing Relationships, use the inheritance rules of RFC-339 to assign meaning to them, and and make whatever corrections to the Relationships are necessary in a particular Work tree. Between now and that future time, various editors will want to record facts in our database about relationships between Works and Artists, URLs, etc. I want to keep welcoming those efforts. Even if the Relationship ends up attached to what we later decide is the wrong place, it will be much easier to adjust a Relationship that's there than a Relationship that is missing because the editor couldn't figure out the right place for it. I believe the inheritance rules of RFC-339 will make that adjustment easier. So, I've added this text in the Considerations section (http://wiki.musicbrainz.org/Proposal:Partial_Works_Relationship_Inheritance#Considerations): 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. In the issues section, I've made a comment that RFC-339 does not imply a campaign to move existing Relationships to the top of Works trees. That would wait until better MusicBrainz software support arrives, and there's a consensus about what style is appropriate. Is this acceptable for those who are concerned about preserving Relationship visibility at leaf nodes of Parts trees? -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-declaring-neutrality-on-where-in-Parts-tree-to-attach-Relationships-tp6946544p6946544.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
Lemire, Sebastien-2 wrote: 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. +1 for me Thank you for your support! Lemire, Sebastien-2 wrote: 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 [parent]-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. That's a very good point. I will add a mention of that to my Partial Works Relationship Inheritance page. I actually think that a note about this this should also get added to the description page for each Relationship Type involving works. I'd expect an editor to read those pages rather than Partial Works Relationship Inheritance. However, I'm going to leave that proposal to a separate RFC. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6942649.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
Rupert Swarbrick wrote: 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. Thank you for your support! I agree it would be even better to for the MB software to support this inheritance. I see that as a later step. First step, define the data model we want in our database. Second step, change how we add new data to fit our new data model. Third step, extend our software to support that data model. Fourth step, remove any old data which is redundant under the new data model. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6942656.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
Nicolás Tamargo de Eguren wrote: 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? Well, the Parts Relationship Type already exists, and I'm not proposing to change its definition. Consider some song cycle. Should each song have the Parts Relationship Type is part of the song cycle today? If they aren't connected by Parts Relationship Type, then the Relationship Inheritance proposal doesn't apply to them. If they are connected, the Relationship Inheritance proposal helps an editor figure out whether a relationship could be applied to the song or the song cycle. I'd argue that right now, it's not clear to editors whether Relationships should be made at the group level or with each composition. Different editors are probably doing inconsistent things. I think defining the inheritance rules would create more consistency. Nicolás Tamargo de Eguren wrote: 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). Interesting. Let me extend that thought a bit. 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? My answer would be No. That approach wasn't my intention. I primarily want to be able new data correctly, and to give clear instructions to the MusicBrainz software developers about how to improve Partial Works Relationship Inheritance by the Web Server and Picard and the libraries etc. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6942682.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
Frederic Da Vitoria wrote: 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? RFC-339 would not make cadenza handling better or worse. The MusicBrainz data model has fairly limited abilities to convey facts about cadenzas and several other areas. I don't propose to make the data model more able to describe, just to be clearer about how to use the descriptive power it already has. Frederic Da Vitoria wrote: You don't seem to suggest physically storing this information in each movement... Correct, I suggest storing this information in parent Works, higher in the tree, and stating clearly that inheritance gives a clear meaning for how that information applies to child Works. Frederic Da Vitoria wrote: ... 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 agree these are challenges. But I think they are challenges inherent in the body of recorded music we are trying to describe. There are many, many, recordings of Bach compositions. If we do a search through an accurate database of metadata about recordings, we will get many results. Richard Wagner really did compose musical works with deep structure. Frederic Da Vitoria wrote: 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 don't know. I hope that some of the MB developers and administrators could give us guidance. My guess is that this will be a reasonable task for MB's servers. I've written code to do a search through hierarchies before, and it ran fine on ordinary web server machines. Frederic Da Vitoria wrote: I agree that such a system would make input both intuitive and user-friendly, though. Thank you for the encouragement. I will say, I don't intend Works Relationship Inheritance primarily to make data input easier. I want to make the data model clearer and better specified. I think the most powerful way to make input more intuitive and user-friendly is to improve the web server software for data input. I have several ideas for that, but they will wait for later proposals. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6942698.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
Calvin Walton-2 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. I don't think RFC-339 increases the expressive power of the MusicBrainz data model, it just makes it clearer how to interpret different uses of Relationships for Parts Relationships between Work entities. In your example, the correct way to express these relationships is to push the Composer ARs to the child Work entities, and have no Composer ARs on the parent Work entity. So: have a Work entity for the Prelude, with an AR of A as Composer to it; have a Work entity for the Overture, with an AR of B as Composer to it; have Work entities for any other parts of the composition, with Composer ARs to those entities as appropriate; and no Composer AR on the Work entity for the whole composition. There would be no inheritance from the whole composition to the parts of the composition. There would be inheritance from the parts to the whole: the structure would mean, some non-zero portion, and maybe or maybe not all, of the whole composition was composed by A; and also some non-zero portion, and maybe or maybe not all, of the whole composition was composed by B. I think that's actually a pretty accurate statement, though not all that precise. Note that the MusicBrainz data model has no way of saying that a particular set of Work entities linked by Parts Relationships to a parent Work entity is complete. We could have fifty Work entities for Prelude, Overture, and all the scenes from Acts I, II, and III; but the MB data model has no way of saying this is everything, there is no Act IV which we haven't gotten around to entering yet. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6942752.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, Johannes: Thanks for this example. jw 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. The answer is the same as for Calvin's example. RFC-339 doesn't change the expressive power of the MusicBrainz data model, it just makes it clear what certain Relationships attached to certain Work entities means. Since in your examples the composition dates differ from movement to movement, then the editor should attach Composer ARs to each movement, with the appropriate dates. There should be no Composer AR attached to the Work entity for the overall composition. RFC-339 talks about parent Works inheriting the relationships attached to their children. The meaning for the parent Work entity would be: some non-zero portion, and maybe or maybe not all, of the parent work was composed from 1874-1876; some non-zero portion, and maybe or maybe not all, of the parent work was composed from 1877-1878. It will be up to the software interpreting this meaning whether it makes sense to condense that down to parent work composed 1874-1878. It might instead present it as parent work composed 1874-1876, 1877-1878. Or it might follow the Parts relationships down and say movement I. composed 1874-1876, movement II. composed 1877-1878. RFC-339 doesn't tell the software which option to choose. jw wrote: So I don't really see the benefit of just blindly copying ARs... I don't think RFC-339 advocates just blindly copying ARs. Thank you for your comments! -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6942760.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, Alex / Caller #6: caller#6 wrote: The Work Group thread [1] talked about a mechanism for over-riding global parent ARs with local child ARs.[2] [1] http://musicbrainz.1054305.n4.nabble.com/RFC-Concept-of-works-group-tp3535348p3535348.html [2] would that mean we'd need a null value available to over-ride an AR that doesn't apply to a child? Thank you for the reference to this earlier discussion! I'll add it to my Background section. Reading the thread now, it seems to reinforce for me the value of RFC-339, to be clear about Partial Works Relationship Inheritance. caller#6 wrote: Jim, would your proposal work the same way? Or would you simply not set a parent ARs unless it is true for all children? RFC-339 doesn't propose to increase the expressive power of the MusicBrainz data model, it just clarifies what applying certain Relationships to certain Work entities means. It does not propose a null value to override a parent AR. In the MusicBrainz data model today, and after RFC-339, you would (as you say), simply not set a parent ARs unless it is true for all children. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6942781.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, Nikki. Thanks for taking a look at this RFC. Nikki-3 wrote: 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. Fair enough. So where do you think the proposed Partial Works Relationship Inheritance page should reside? And what pages should like to it? Nikki-3 wrote: 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 propose adding text like this to Parts Relationship Type as part of RFC-339. Another comment in this thread suggests adding it to the description of every Relationship Type involving Work entities. I think that's a good idea, but I'll leave it out of RFC-339. It can be a followup proposal. Nikki-3 wrote: I also agree with Calvin and think we need server support before inheriting relationships before adding a guideline like this. Tell me more. (repeating my reply to Calvin:) I had intended this proposal to guide addition of new data into MusicBrainz, not to initiate a campaign to get rid of ARs on partial Work entities which inheritance renders redundant. But I get the impression that you and others are concerned about delaying the purge on such ARs until the software is up to snuff. i'm OK with that. I'm even OK with an interim policy which says, put ARs everywhere for now, while we get the software able to handle inheritance, and then do a much bigger purge of redundant ARs. Would that answer your objection? Nikki-3 wrote: 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? I think that, regardless of RFC-339, relationship editing for works is hugely inadequate for handling works and subworks for opera compositions, and to a lesser extent for Classical. With 30-50 subworks for an opera, and 16 UI actions (clicks, buttons, text fields) per sub-work relationship, entering subworks for a single opera takes hours and is very tedious. I have a number of ideas for improving this, but they are beyond the scope of RFC-339. (repeating my reply to Calvin) I'm hearing a couple of people in this thread allude to a preference for having Relationships describing compositions be applied to every parent and child Work entity in the Parts Relationship tree of Work entities. This is a legitimate choice for the data model. It makes application development easier, at the cost of making data entry harder, accidental inconsistency of data more likely, etc. But we could decide we prefer that trade-off. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6942817.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
[mb-style] Proposal formatting, for multi-part proposals [was: Re: RFC-339: Partial Works Relationship Inheritance]
Nikki-3 wrote: 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. Fair enough. RFC-339 proposes to make coordinated changes to three different Style or Documentation pages. If the Proposal: page should be the actual text for the proposed new page, then should I present this proposal as three separate RFC's, each with its own number? I added Rationale and Related reading sections to my proposal. I think those are useful to write down somewhere. Especially Rationale; there's too much at MB which says do it this way, with no hint as to why. If that doesn't belong in the Proposal: page, then where does it belong? -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6942833.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
Nicolás: Nicolás Tamargo de Eguren wrote: On Sat, Oct 29, 2011 at 11:29 AM, Jim DeLaHunt lt;from.nabble@gt; wrote: ... I'm hearing a couple of people in this thread allude to a preference for having Relationships describing compositions be applied to every parent and child Work entity in the Parts Relationship tree of Work entities. This is a legitimate choice for the data model. It makes application development easier, at the cost of making data entry harder, accidental inconsistency of data more likely, etc. But we could decide we prefer that trade-off. (meh, I kinda wrote a long mail...) It doesn't have to make data entry harder (or just marginally) if a good way of batch adding relationships is developed. At some point you said you didn't know if people were adding relationships for subparts: I certainly am, and I would be more worried about whether other people do add parent works at all, as it's not straightforward and obvious with the current structure ...[snip]... So, are you in favour of rejecting the Inheritance idea of RFC-339, and instead approving a guideline that asks editors to put ARs on every child Work entity relating to partial compositions, as well as on every Parent entity? I generally agree with your other comments: improvements to MB's handling of Classical are badly needed, and are on the way. However, my experience with Classical music in MB is that we tend to try to fix too many things at once, and nothing gets changed at all. With RFC-339 I'm trying to make a small change to the mechanism we already have, and solve one small problem at a time. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6942933.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
Frederic: Thank you for your ideas about this issue. It's valuable to hear a lot of different perspectives about how MusicBrainz should deal with works. I think you and I agree about many things. However, I have a slight disagreement with you about two points: Frederic Da Vitoria wrote: I believe that as Calvin pointed out, simply applying this idea to the data would make the data partially unusable. OTOH, very few users would be willing to enter the level of data duplication which would be needed, so that the data quality in classical music would become very poor because too many useful AR duplications would not be entered. Let me highlight the words would become very poor. That seems to imply that the data quality -- of Works entities with Parts relationships, and Relationships on those entities, that's the topic here -- is good now. I believe that the number of Works entities with both sub-parts and Relationships is quite small. This is because the editing tools for multi-part Works and Relationships are very poor. I entered just the child Works for one opera, and it was a very long and tedious process. Is there a way to measure how good the data is? For instance, do we have a count of how many Works have both multiple levels using the Parts Relationship, and have Relationships for things like composer? I looked for a way to test this using MB Search, and http://musicbrainz.org/doc/Text_Search_Syntax, but I couldn't find a way to looks for Relationships. I argue that the data quality, i.e. the number and importance of Relationships on Works entities which also have Parts Relationships, is poor in the MusicBrainz database right now. I base this on perceptions, not facts. Can anyone cite facts, search results, etc., to prove otherwise? If we have no proof that the data quality is currently good, then RFC-339 will either have no effect, or will make bad data bad in a different way. I believe the data quality here will remain poor until we have better editing tools, and we have to make design choices like RFC-339 before the editing tools can improve. RFC-339 won't improve the data greatly. It will just be a brick in the bridge leading to better data. We need many other bricks also. Frederic Da Vitoria wrote: There is a discrepancy between making input user-friendly and keeping the data retrieval efficient... I agree. A distinction might be an even better word than discrepancy, but I understand your meaning. Frederic Da Vitoria wrote: I believe that since data retrieval is after all the justification of data entry, then the database should physically make retrieval as efficient as possible, which means that ARs should be duplicated. As a software engineer, I do not completely agree with this statement. The database should physically make retrieval efficient /enough/ to accomplish its purpose. But design is about tradeoffs, and efficiency is not the only factor we are trying to balance. Once the retrieval is efficient enough, then other factors -- like data consistency and clarity of meaning -- should get greater weight. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6944751.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
[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: Add Do not infer attributes to the Master, Mix and Recording engineer pages
Nicolás Tamargo de Eguren wrote: Do not infer attributes This text is present at the Engineer relationship guidelines... I would like to add it to those three pages: http://wiki.musicbrainz.org/Recording_Engineer_Relationship_Type http://wiki.musicbrainz.org/Mix_Engineer_Relationship_Type http://wiki.musicbrainz.org/Mastering_Engineer_Relationship_Type +1. I don't know very much about recording engineers, but I do like to see more precision in the instructions we give editors for how to apply ARs. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-Add-Do-not-infer-attributes-to-the-Master-Mix-and-Recording-engineer-pages-tp6928178p6930685.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] CSG - Track recording standardization, linking recordings, removing duplicate works ARs
Sebastien: You have some great ideas here. I've been thinking about a lot of the same things. And I think many of these points are actually very long-standing topics for debate, or in some cases a new light from NGS on an old style guideline. Lemire, Sebastien-2 wrote: *Normalized recording title based on normalized work title:* - First, with popular recordings there was an RFC to standardize the tracklists with the recordings. I believe that we should do something quite different with classical recordings. I think that we should actually standardize the recordings in accordance with the standardized work title rather than the track list. The essential policy of the Classical Style Guide, from before the Next Generation Schema (NGS), is that we would rather impose standard track titles (based on an elaborately specified form of composition titles used in the classical music tradition) than accept whatever track titles the CD publishers put on their covers. NGS gives us a work structure (call them MBWorks). This is an obvious place to put the standard composition titles specified by the Classical Style Guide. I strongly believe we should use MBWorks in whatever way makes entering good classical track titles easy. But these claims aren't yet consensus, and aren't reflected in style guidelines for MBWorks yet. I think the discussion about keeping Recording titles the same as Track titles still applies. But combine it with the CSG principle that standardised composition titles overrule CD publishers, and with putting standardised composition titles in MBWorks, and you get exactly your proposal: Standardised composition titles - MBworks titles - Tecording titles - Track titles. Lemire, Sebastien-2 wrote: - To keep a certain link with the original album I don't think we should normalize track lists but the recordings themselves can appear on various releases (where each release can have different naming conventions and language) I think you are seeking to re-argue RFC-333, Unify track/recording guidelines. See mb-style thread at http://thread.gmane.org/gmane.comp.audio.musicbrainz.style/11724 and http://thread.gmane.org/gmane.comp.audio.musicbrainz.style/11943 . I support RFC-333, so I think classical album track titles should still follow recording titles, which follow standard titles stored in MBWorks. Lemire, Sebastien-2 wrote: - Special tempo information or movement information that differs from our works standard should be kept in the recording title (they should technically remain the same across releases). That said, I wouldn't be opposed to this being standardized based on the works as well since it is already specified in the track titles. I don't know of cases where a recording should have non-standard tempo information in a Recording title. The standard tempo information in a Recording title should be based on the composer's score, right? The performers may ignore that tempo, but that doesn't change the standard title. By Special movement information, do you mean cases where different recordings slice a long performance into tracks at different places? This frequently happens with opera recordings; e.g. one recording starts track 3 at measure 40 of Act I Scene II, but another recording has measure 40 landing partway through track 5. I think we ought to have lots of MBWorks, all with an AR pointing to the MBWork for the complete composition, and each child MBWork has the title specified by the CSG. It will be a lot of entries, but I think with a sequence field and some better data entry wizards on the server, it will be manageable. I should write a separate post about that. Lemire, Sebastien-2 wrote: *Grouping Classical recordings like we do currently for works:. * - At the moment, I think most will agree, linking performance credits to recordings is a major pain and extremely time consuming. (not just for classical). - Every recording needs it's own performance ARs and, especially in classical, often repeated over several recordings resulting in the addition of extra ARs. I absolutely agree, linking Artist performances to Recording entries is a major pain. Lemire, Sebastien-2 wrote: - Therefore, what if we created the same system as for the works where we could link (say the 4 movements of a same performance of a symphony) to a supra-recording? To this supra-recording we could give all the proper performance ARs with proper dates. I do not think this is the best way to solve the problem. Instead, let's improve the editing tools on the MB server to make it easy to add performance credits of many Artists to many Recordings at once. The NGS server has a way of Relating to... Recordings from a Release page, and this lets you add one Artist performance relationship to every Recording in one edit action. Or, you can select check boxes for only
Re: [mb-style] RFV-228: Style/Language/Japanese
Calvin: Thanks for putting this proposal forward. Just to be clear, the number of this RFC/RFV is 288, right? (Subject: line says RFV-228 instead.) And just to be clear, what do you want the URL of this page to be? A new page, http://wiki.musicbrainz.org/Capitalization Standard Japanese ? Where will the page be linked to from? From http://wiki.musicbrainz.org/Style/Language/Transliterations perhaps, as Chinese, Hebrew, and Yiddish are? (Those pages are at URLs like http://wiki.musicbrainz.org/Capitalization Standard Chinese etc.) -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-228-Style-Language-Japanese-tp6917929p6921437.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] Work Style Guideline: List of Issues
Apologies for coming into this old thread. I'm coming back to MB-Style for the first time post NGS, and trying to understand how the big Classical and Opera Style issues I care about are changed by the new schema. I've added two items to the work issues list http://wiki.musicbrainz.org/User:PBryan/Work_Issues: WI-14 What is purpose of Works entity? WI-15 Should Works entity make Classical Style Guide compliance much easier? I'll start mb-style threads on each topic. Thanks, Paul, for setting up that list and inviting contributions. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/Work-Style-Guideline-List-of-Issues-tp6716300p6856988.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
[mb-style] Works issue WI-14 What is purpose of Works entity?
Hi, folks: I have a lot of experience with MB and the Classical Style Guide from the pre-NGS days. I'm coming back to MB after a bit of an absence, and trying to figure out how the Next Generation Schema actually turned out and what effect it has on the classical and opera recordings I'm cataloguing. I think the Works entity of NGS has the potential to dramatically simplify a MB contributor's task of complying with the CSG. Whether it accomplishes that or not depends greatly on how we define the Works entity and the Works Style guide. There's a lot of good discussion on this topic, and many people have devoted a lot of effort to it. I'm trying to catch up with their work. I have a fundamental question: What is purpose of the Works entity in MusicBrainz? Why is it worth a MusicBrainz contributor's time to register Works data? What value will it add to MusicBrainz and to the world? Why is that time better spent than, say, adding Performer ARs? My opinion is that there are two overriding purposes for the Works entity in MusicBrainz: 1. To better describe what various music recordings in the MusicBrainz catalogue have in common thanks to shared musical compositions which were performed and recorded. 2. To dramatically simplify the task for a MB contributor's task of complying with the Classical Style Guide. Another opinion is that the Works entities in MB NGS are a way to describe musical compostions for their own sake. I saw this opinion in my reading last night, on either mb-style or in tickets.musicbrainz.org. Something like: there is no good catalogue for music compositions, and MB has the potential to become that catalogue. (Unfortunately I can't find the quote now.) What brings this up is the tenor of discussion about Works style as applied to Opera and Classical music. I find it tends to spin off in to the fine abstractions of whether an Act of an opera can be broken down into scenes or arias or some such sub-division, and how much arranging it takes to qualify a bit of music as a different Work. There tends not to be a grounding in what value the Works entity intends to add. I think that stating clearly what the purpose of the Works entity in MusicBrainz is, and how we expect it to add value, will make it easier to make good choices in Works Style and Works-related features. Apologies if it's already stated clearly somewhere; I haven't found it. Where I'd expect to see it is in http://wiki.musicbrainz.org/Work . I've registered this issue as WI-14 in http://wiki.musicbrainz.org/User:PBryan/Work_Issues . WI-14: Agree on and write down the purpose for having Works entities in MusicBrainz, and why contributors should want to spend the effort to enter such data. In particular: are we cataloguing music compositions for their own sake, or as a means to better describe the contents of music recordings? Comments? -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/Works-issue-WI-14-What-is-purpose-of-Works-entity-tp6857077p6857077.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
[mb-style] Works issue WI-15 Should Works entity make Classical Style Guide compliance much easier?
Hi, folks: I have a lot of experience with MB and the Classical Style Guide from the pre-NGS days. I'm coming back to MB after a bit of an absence, and trying to figure out how the Next Generation Schema actually turned out and what effect it has on the classical and opera recordings I'm cataloguing. I think the Works entity of NGS has the potential to dramatically simplify a MB contributor's task of complying with the CSG. But I don't see the current discussion around Work Style and Work-related feature enhancements pointing in that direction. So I want to ask the question whether everyone else accepts this as a goal. Classical Style Guide compliance is hard. I believe this is inherent: any Classical Style Guide telling how to write a text string describing a track's worth of recorded classical music, will be complicated and hard to learn. Sure, our pre-NGS CSG is a messed-up tangle, but even if it were well-written and officially endorsed, it would still be difficult and require both months of study, and familiarity with the classical and opera music culture, to use it well. This is a huge barrier to MusicBrainz contributers with classical and opera releases. Since almost all my MB work is in these genres, I care about this problem a lot. And even though I have spent months studying the CSG and years in the classical and opera culture, it's really hard even for me. The only hope MB contributors have that their task of submitting good classical music Recording or Track titles will become much easier, if they don't want to become CSG experts, is to let them select from a list of well-formed name strings which CSG experts have prepared and reviewed beforehand. See http://wiki.musicbrainz.org/CSG_Standard/Mozart#OperaEtc10 for an example of a list of well-formed work names. This reference saved me /hours/ in the last few days entering http://musicbrainz.org/release/24320d30-8603-402a-a937-a2469e9c4b00 . And I know the CSG wel! I think that the Works entity in the Next Generation Schema is our best near-term hope of making CSG compliance dramatically easier. It involves using the Work Names to store the list of well-formed name strings. Experts would go over Work names of classical works until they conformed to the CSG. The release entry and editing tools would add a way to present a list of these Work names that might apply to a Release, and let the contributor choose the most appropriate ones as the starting point for their Recording or Track titles. I go so far as to say that if our Works style must make this possible, and if the Work style doesn't, we shouldn't adopt it. See me rant to this effect: NGS 'Works' should help cut CSG Gordian Knot, Dec 18 2010, http://musicbrainz-mailing-lists.2986109.n2.nabble.com/NGS-Works-should-help-cut-CSG-Gordian-Knot-td5847956.html . So that's my opinion. But I don't see that understanding suffusing the discussion of Works style. In fact, I see hardly any mention of how Works Style relates to solving the problems of CSG. I don't see the definition of partial Opera works being motivated by making it easier to enter opera releases into MB. I see some proposals that there should be some other mechanism, e.g. an attribute attached to a Works record, which provides the well-formed CSG compliant string which editors will use. So, Will the Works entities and ARs in MusicBrainz have a primary goal of helping make CSG compliance much easier? If so, how? If not, what other MB structure will do this job? I've registered this issue as WI-15 in http://wiki.musicbrainz.org/User:PBryan/Work_Issues . WI-15: Should Works entity make Classical Style Guide compliance much easier? Comments? -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/Works-issue-WI-15-Should-Works-entity-make-Classical-Style-Guide-compliance-much-easier-tp6857138p6857138.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
[mb-style] CSG Standard/Verdi, pls review
Hello, all:
I've now created a CSG Standard page for Guiseppe Verdi. I've filled in the
section on his opera Rigoletto in detail, and roughly sketched the other
operas. I haven't started on the non-operatic Verdi works yet.
See http://wiki.musicbrainz.org/CSG_Standard/Verdi%2C_Giuseppe#Rigoletto
Contributions to the wiki page, and discussion in its Talk page or direct to
me, are welcomed.
Looking at the size of the Rigoletto track titles list, and how many operas
Verdi wrote, I'm thinking that each opera might be best off in its own page.
Hence it might become:
http://wiki.musicbrainz.org/CSG_Standard/Verdi%2C_Giuseppe/Rigoletto
('/' not '#')
I'm also gathering interesting data on track boundaries in operatic
recordings, and what that says about defining NGS Works Style for opera
recordings. But that's a topic for a different message.
--
View this message in context:
http://musicbrainz-mailing-lists.2986109.n2.nabble.com/CSG-Standard-Verdi-pls-review-tp6079326p6079326.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] CSG Standard/Verdi, pls review
Let me repeat the URLs in my message. Nabble's web UI doesn't display them.
CSG Standard page for Verdi and Rigoletto:
http://wiki.musicbrainz.org/CSG_Standard/Verdi%2C_Giuseppe#Rigoletto
Possible URL if we move each opera to its own CSG Standard sub-page:
http://wiki.musicbrainz.org/CSG_Standard/Verdi%2C_Giuseppe/Rigoletto
Jim DeLaHunt wrote:
Hello, all:
I've now created a CSG Standard page for Guiseppe Verdi. I've filled in
the section on his opera Rigoletto in detail, and roughly sketched the
other operas. I haven't started on the non-operatic Verdi works yet.
See http://wiki.musicbrainz.org/CSG_Standard/Verdi%2C_Giuseppe#Rigoletto
http://wiki.musicbrainz.org/CSG_Standard/Verdi%2C_Giuseppe#Rigoletto
Contributions to the wiki page, and discussion in its Talk page or direct
to me, are welcomed.
Looking at the size of the Rigoletto track titles list, and how many
operas Verdi wrote, I'm thinking that each opera might be best off in its
own page. Hence it might become:
http://wiki.musicbrainz.org/CSG_Standard/Verdi%2C_Giuseppe/Rigoletto
('/' not '#')
I'm also gathering interesting data on track boundaries in operatic
recordings, and what that says about defining NGS Works Style for opera
recordings. But that's a topic for a different message.
--
View this message in context:
http://musicbrainz-mailing-lists.2986109.n2.nabble.com/CSG-Standard-Verdi-pls-review-tp6079326p6079944.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
[mb-style] CSG Standard/Bellini, pls review
Hi, folks: As preparation for adding two Releases of Bellini's opera Norma to MB, I decided to make a CSG Standard page for that work, so I'd only have to figure out the Opera Track Style once. As a side effect of that, I created a CSG Standard page for Bellini. I also came up with a format for opera track listings, which helps a contributor submit not just TrackTitles but also per-track singer ARs. I'd welcome your review. If you are interested, please review: * http://wiki.musicbrainz.org/CSG_Standard/Bellini%2C_Vincenzo#Norma , with an eye to any mistakes I made in style compliance for the opera Norma. * The Bellini page as a whole, and how the CSG Standard page links to its children. * The per-track singer notations, to see if it might be improved, and might be useful elsewhere If you want to make fixes right on the page, please go ahead. For comments, or meta-discussion, let's head to the Talk page of CSG Standard/Bellini..., or in this mb-style thread. I'm off now to listen to Casta Diva. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/CSG-Standard-Bellini-pls-review-tp6039174p6039174.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
[mb-style] NGS 'Works' should help cut CSG Gordian Knot
) for a hint of what's possible. Novice editors need only enter simple Release and Track entries for a new Release; they or a more experienced editor makes the connection from Release and Track to Work (via whatever intermediate structure NGS provides); and voilà! the Release and Track entries benefit from the care put into the Works. Also, I think some of the arcana of the CSG will wither away. Instead of having to write detailed rules for how to name a track containing movements of symphonies in general, the editors improving on Works metadata can agree on specific adaptations of high-level CSG principles for the Work in question. And if a better adaptation emerges, one edit to the right Work entry will benefit all Tracks recording of that work. Instead of having to write detailed rules for which performers to mention in a feat. parenthetical, editors can simply add ARs to Tracks and Releases, and let the tagger generate the feat. parenthetical if desired. In the legend of the Gordian Knot, Alexander unties it by slicing it asunder with his sword. In the same way, I hope that the Works notion of NGS will slice the CSG asunder. I hope it will free most novice editors, and many expert classical music editors, from the CSG's burden. I submit that we should make this a goal of the Works style guidelines. If the style guidelines for Works don't lead us to this world, then we should reject those guidelines and keep working to improve them. There are many voices in MB, and on mb-style. The above is merely my view. I look forward to hearing yours. --Jim DeLaHunt, Vancouver, Canada -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/NGS-Works-should-help-cut-CSG-Gordian-Knot-tp5847956p5847956.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
[mb-style] Style leader returns after an absence
Hi, folks, Some of you may recall that I was appointed a Style Leader last year. The purpose of this role is to help the style process move more smoothly. Late last year, I got distracted by The Rest Of Life and fell behind on reading mb-style. Well, it's a new year, and I'm back on the list, and catching up on old messages. It's great to see renewed interest in cleaning up the ClassicalStyleGuide! I'm glad to help shepherd that. One other project to dust off is a review of the Style change process, which Robert Kaye and I announced last August. See http://wiki.musicbrainz.org/StyleCouncil/August2008ProcessReview . He and I both set off to find participants for this review, and didn't find the right people immediately, and the project stopped. I'll be restarting it. Would you like to participate in this process review? If so, read the page, and either contact me or add your name to the page. Thanks! - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Style-leader-returns-after-an-absence-tp21430288s2885p21430288.html Sent from the Musicbrainz - Style 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] German Opera Track Style: I. Akt, III. Szene or Akt I, Szene I?
Frederic Da Vitoria wrote: On Tue, Oct 21, 2008 at 7:23 AM, Jim DeLaHunt [EMAIL PROTECTED] wrote: We don't even have official agreement for how Act I, Scene I should be written in the English language. See http://wiki.musicbrainz.org/OperaTrackStyle OperaTrackStyle and http://wiki.musicbrainz.org/ClassicalTrackTitleStyle ClassicalTrackTitleStyle for some of the discussion about the English language case. I don't catch your meaning: do you mean these pages are not official yet or that these pages disagree? I'm sorry I wasn't clear. I meant to say that a) the pages are not official yet, and b) they aren't clear about how Act I, Scene I should be represented, and c) that's for English, which is usually in MB the language with the clearest guidelines. Frederic Da Vitoria wrote: So my advice is to come up with a convention which you think you and others can apply consistently for German-language track titles, and then propose that convention once we've agreed on the English-language styles. I don't see why English should come first. If German-speaking users can reach a consensus before the others, perfect (I don't speak German, but being French, I know that we will be the last to reach a consensus - no, I meant: that we will never reach a consensus :-D ) Good point. I retract my Anglophone chauvinism. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/German-Opera-Track-Style%3A-%22I.-Akt%2C-III.-Szene%22-or-%22Akt-I%2C-Szene-I%22--tp20048484s2885p20105359.html Sent from the Musicbrainz - Style 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] RFV: Part of series relationship
Hi, folks. I put on my Style Leader role, and asked Johannes to work with a small group off-line to improve this proposal in answer to this recent discussion. Chad agreed to be part of that small group. Does anyone else want to join them? Let me know by email to style at musicbrainz.org, and I'll add you to the discussion. I consider the present proposal back to the RFC stage. I take the discussion as a veto of the proposal as it was worded. But progress continues. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/RFV%3A-Part-of-series-relationship-tp19918956s2885p20083564.html Sent from the Musicbrainz - Style 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] German Opera Track Style: I. Akt, III. Szene or Akt I, Szene I?
Willensmacht wrote: I've looked through the Classical StyleGuide as well as the Opera Track StyleGuide and haven't seen anything talking about how to format the act and scene in a German-language release you can also find instances where the formatting is I. Akt, I. Szene, for example. Has a standard been decided already? Not as far as I know. We don't even have official agreement for how Act I, Scene I should be written in the English language. See http://wiki.musicbrainz.org/OperaTrackStyle OperaTrackStyle and http://wiki.musicbrainz.org/ClassicalTrackTitleStyle ClassicalTrackTitleStyle for some of the discussion about the English language case. See http://wiki.musicbrainz.org/ClassicalReleaseLanguage ClassicalReleaseLanguage/href to see how tangled the discussion on language can get. So my advice is to come up with a convention which you think you and others can apply consistently for German-language track titles, and then propose that convention once we've agreed on the English-language styles. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/German-Opera-Track-Style%3A-%22I.-Akt%2C-III.-Szene%22-or-%22Akt-I%2C-Szene-I%22--tp20048484s2885p20083634.html Sent from the Musicbrainz - Style 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] RFV: Part of series relationship
Johannes: Thank you for making this proposal. My impression is that no strong objections emerged in the RFC discussion. So it's good to proceed to RFV. However, I'm a bit concerned that you are not completely clear about what specifically you are proposing. You are saying we could use the exact same AR for a set and a series, but I think you are proposing that we not do this, and use a different AR. You say It would also be possible to have a checkbox..., but again I think you are not proposing this. What should we do about gaps? Could you rewrite that paragraph with a statement of what people should do? Imagine you are writing the wiki page that explains this AR, and tells ordinary contributors how to use it. I have Complete works of Bach, Volume 15, Complete works of Bach, Volume 16, and Complete Works of Bach, Volume 28, but no others. Should i use this AR? What do I do about the missing Volumes 1-14 and 17-27? Could I ask you to rewrite this message, saying exactly what you propose, and leaving out mention of what you do not propose? Think of a developer reading this message and trying to implement the proposal. Will it be clear what to do? I'm also interested in technical feasibility. Could someone who is able to implement the AR take a look at this and tell us if this looks well-specified and feasible? Johannes Dewender wrote: Hello, Similary to the set AR I would like to see a series AR. Series have quite similar properties. The last comment on the corresponding RFC is more than two weeks old, so I start a RFV for the series AR. The text ist mostly the same as for the RFC, but I fixed the wording to be more series-like. RFC: http://lists.musicbrainz.org/pipermail/musicbrainz-style/2008-September/007113.html A series: The Return of the Rock The Return of the Rock, Volume 2 http://musicbrainz.org/release/5d0df9bf-b51c-4644-8655-35c1c04362b5.html http://musicbrainz.org/release/c08df278-87e2-4cce-a93d-fa6e8d66e23d.html A bigger series: http://wiki.musicbrainz.org/Series/CafeDelMar (note: only the 14 official volumes would use this AR) Technically, we could use the exact same AR for a set and a series. However, the wording for the set AR does not permit such a usage and it would help the semantics later when there is an extra AR for series. It would also be possible to have a checkbox for series or a radiobox for set and series. If we want to print a name of a set or series, this would be the name of the first release, stripping disc and volume information. The first release is automatically the one without a predecessor. (see problems with gaps below) Differences: Obviously, the word set should get changed to series then. The optional/bonus option doesn't make sense for a series. Sets consists of usually 2 or maybe 3 discs, series can consist of a lot more. This might make a difference, when we want to list all of them fast, see problems. Wording: [A] is part of a series, the next release in the series is [B] [B] is part of a series, the previous release in the series is [A] Additional rules: In cases of multi-disc releases that are part of the series: Only the first disc in a set should get linked to the first disc of the next release in the series. If there are multiple versions of a release, only the first/original/main releases get linked and the other releases attached with other ARs. Problems: One might be interested to list all the items of a set and likewise all the releases in a series. It might not be cheap to list all 20 releases, because we need 20 queries, unless I am missing a feature that can do this as fast as selecting all rows with a certain property. The same is true for a 50 disc classic box set, though. It might not be uncommon, that we will have gaps in the data, meaning we have a bunch of releases in order and then there is this one release that is not in the DB, so we can't link it to the next bunch, creating two different series in terms of our logic. We should annotate this, providing a link to the next bunch. It might also be wise to try and find enough information to add the missing releases. Implementation: I can do the wiki stuff, when it is clear that such a thing is implemented, but I can't create the AR myself, so some help from a dev would be needed. I can also do the wiki rightaway if this helps. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/RFV%3A-Part-of-series-relationship-tp19918956s2885p19938913.html Sent from the Musicbrainz - Style 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] artist A presents artist B
On Thu, 18 Sep 2008, Toni Panadès wrote: LSS it's a group where the main artist is Dennis White (AKA Static Revenger), and in some places (and on the cover of the album) appears as Static Revenger presents Love Song Surprise What you think? I need to put an alias for this artist, or I need to change the name of the artist? Steve Wyles wrote: I'm certain this has been covered in previous discussions, either on the mailing list or the IRC channel. My understanding is: The current artist Love Song Surprise should stay exactly as named. It is probably worth adding Static Revenger presents Love Song Surprise as an alias under Love Song Surprise So, would any of you like to point to which style guideline ought to contain this guidance, and how the guidance ought to be worded? Please make a proposal. Then we can clarify the style guidelines to make this clear for the next contributor. Thank you all for your work on Love Song Surprise (and all the other artists you work on)! - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/artist-A-presents-artist-B-tp19554569s2885p19874233.html Sent from the Musicbrainz - Style 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] Non-ascii in Japanese artist sort names?
Philip Jägenstedt-3 wrote: The sort name of 岩代太郎[1] is currently Iwashiro, Tarō, which is something I've never seen before. I realize that Tarō and Taro may not sound the same, but is it customary to include this in the sort name?... Tarō is a customary latin-script transliteration of the Japanese name. Taro is also customary, and Taroh and Tarou are also sometimes seen. The macron over the o conveys the same thing that the oh and ou convey, which is a long vowel. http://wiki.musicbrainz.org/SortNameStyle SortNameStyle does not say anything about macrons in latinised Japanese words specifically. It does say specifically that accents on latin script letters should be retained. Thus I think the contributor who gave us a sort name of Iwashiro, Tarō is absolutely correct. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Non-ascii-in-Japanese-artist-sort-names--tp19237665s2885p19239784.html Sent from the Musicbrainz - Style 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] album version, original mix, etc.
Jan van Thiel wrote: 2008/8/18 Tim [EMAIL PROTECTED]: I believe that unique tracks should have unique track names across all releases. This seems to be essential for distinguishability of tracks by their track names... Each name has one sound and each sound has one name. [...] MusicBrainz is a discography site with all info on music and some on artists... This info can be used for tagging. Picard has the powerful TaggerScript which lets you format any tag basically the way you want. There's no need to change almost all track titles to accommodate your tagging needs. +1. Tim: what problem are you trying to solve? That your digital music player only offers an Artist and a Title field, and your collection has some entries which are indistinguishable using just these two fields? Then there are a number of ways you can address that problem. In addition to what Jan said, you could perhaps switch to a different music player, which can take advantage of more metadata tags and display more fields. Music metadata is complex and varied. It won't fit in simple-minded Artist and Title text strings in any satisfactory way. I think it's MusicBrainz's job to store the real information in all it's detail and complexity. It's the job of the taggers and other exporters to flatten this information to fit the constraints of music players, other databases, and so on. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/album-version%2C-original-mix%2C-etc.-tp19025740s2885p19138669.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Call for volunteers and thoughts on style process
Hi, folks! I'm glad to take on the role of style leader, and I hope it will serve to get the style process moving in a good way, and cut down the tangle of unresolved issues in the ClassicalStyleGuide. If you want to contact me in my role as Style Leader, you can reach me via the http://musicbrainz.org/show/user/?userid=363367 contact link on my MB user page . I agreed with RobertKaye that the first order of business is to take a look at our present style process. We want to see what works and should be kept, and what needs changing. The process by which we'll do this review isn't defined yet, except that it will start with a small group working on it (per http://lists.musicbrainz.org/pipermail/musicbrainz-style/2008-July/007011.html RobertKaye's mb-style message of Jul 11 ), and will involve a community review via the mb-style list. So don't worry about something vile being snuck in. The timing I'm aiming for is that this take weeks not months. I've started a page to organise this project, and communicate to you about it, at http://wiki.musicbrainz.org/StyleCouncil/August2008ProcessReview . Check it out. Robert and I are actively recruiting a few MB participants to work on this review. If you'd like to volunteer, please add your name and MB user name on that wiki page. Jim will let you know if you are accepted. We have to keep the group small to make it manageable. Don't worry, there will be a chance for everyone on mb-style to take a look at what we come up with before it's carved in (stone? vinyl? polycarbonate?). If you have thoughts about the current process which you want to toss in the hopper, I'd like to hear them. Send me a private message, or post them to the appropriate section of the wiki page above. I'd encourage you not to reply to the mb-style list unless you think it's of general interest. Thanks, everyone. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Call-for-volunteers-and-thoughts-on-style-process-tp18866437s2885p18866437.html Sent from the Musicbrainz - Style 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] MediaWiki (was: Looking for a new [Documentation|Style] leader)
Philip Jägenstedt-3 wrote: Ah, MediaWiki is quite refreshing, I like it Hear, hear! +1! I like what I see at the prototype pages. We should make a place to list issues with the migration (he said, presuming that it will in fact go ahead). For instance, I'd like to see all of the edit history migrate forward, instead of just the most recent edit. Also, the page http://wiki.musicbrainz.org/StyleCouncil has some markup that leaves spare dl, dt, and dd tags in the MediaWiki page text at http://mediawiki.musicbrainz.org/Style_Council . I think it's the MoinMoin :: markup that triggers the problem. Salivating for a MusicBrainz wiki hosted on MediaWiki, and for a robust migration, - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/MediaWiki-%28was%3A-Looking-for-a-new--Documentation%7CStyle--leader%29-tp18829838s2885p18866546.html Sent from the Musicbrainz - Style 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] Looking for a new [Documentation|Style] leader
Aurélien Mino wrote: BTW, I figured nearly one year ago that we should migrate to MediaWiki, because it may better fits our needs (true categories support, advanced templates (Moin cards are limited), native discussion page for each article, namespaces). However I feel discouraged by the needed work, and stopped my investigaton. +1 I don't know about transclusion. However, for all the other areas of Wiki-fu that I've encountered at MusicBrainz, I would be much happier to have MediaWiki than Moin wiki. Editing power, better structure for discussion, better support for watchlists, better tracking of links, full-text search that might be turned on, better category function, better template function, perhaps more contributers who know the syntax, perhaps more developer power behind the software: MediaWiki looks better to me on all these counts. What would be really great is to figure out how to port across the edit histories with the page content. Then we could still look up how things came to be. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Looking-for-a-new-style-leader-tp18205649s2885p18748012.html Sent from the Musicbrainz - Style 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] Looking for a new style leader
current. 8. It would be good to have more data from the database to guide decisions about Style choices. Examples of data: for an AR which can relate to Tracks or Releases, what proportion of its use is with Tracks and what proportion with Releases? Which Composers have the most Tracks, and what works do they contain (pointing to priorities for the CSGStandard pages)? How many times is a particular instrument used in ARs? I'd love to see a small pool of people with the tools and query skills to be able to chime in with such answers. 9. For the ClassicalStyleGuide and its offshoots, there's a ton of work to do, and the major overhaul seems to have gotten stuck. Therefore I like the idea of breaking it into pieces. I think the Style Czar should be assertive in cutting off bite-sized pieces and assembling a crew of participants to come up with a proposed improvement. It's OK that the Style Czar not be part of that crew. 10. We should keep in mind the need to welcome and groom new contributors. The more of them we welcome, the more hands we have to make light our work. MB is an intimidating place, with its complicated rules and inaccurate documentation and immediate judgment on a newbie's first contributions. I think many of us could stand to be more welcoming in our interaction with newbies — make a point of saying Hi, thank you for contributing before saying but your TrackTitle is all wrong. We should have some canned Welcome texts. And most of all, we should get our docs to the point where someone following the docs is doing the right thing, instead of some wrong or obsolete thing. Interestingly, one thing which I think the Style Czar not need do much of, is make style policy decisions. Because, I think, we've got fine people with fine ideas, we already have the wisdom to get those decisions right. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Looking-for-a-new-style-leader-tp18205649s2885p18646284.html Sent from the Musicbrainz - Style 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] Looking for a new style leader
Robert Kaye wrote: ... FYI: http://blog.musicbrainz.org/?p=332 If you have any thoughts on Jim being the style leader, please drop me a *private* email. Of course it's obvious to anyone who sees how he dresses that Jim is hopelessly unqualified to be a style leader. I mean really, a fleece jacket in July. He must live in Canada or something. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Looking-for-a-new-style-leader-tp18205649s2885p18397085.html Sent from the Musicbrainz - Style 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: FeaturingArtistStyle amendment
Gecks: Gecks wrote: One I would like to repeat: I'd like to see some text at the beginning saying that this does not apply when ClassicalStyleGuide is in use. well, i've reinstated* the previous details and discussion section on my amendment, which mention the CSG. i'm not interested in elaborating on how the CSG uses featuring artists here - if someone wants to amend that at a later date they can do this :) I agree that this article shouldn't say *how* the CSG uses featuring artists, just where to go to find out about featuring artists in classical. I like your reinstated section. I don't think the mention of CSG in the second bullet point there accomplishes that cross-reference; it is about additional contributors who didn't perform on the track I suggest adding a bullet point in the details and discussion section: * This guideline applies to most MusicalGenres, but it does not apply to entries covered by the ClassicalStyleGuide. Collaboration takes a different form in ClassicalMusic. See the ClassicalStyleGuide, and especially ClassicalReleaseArtistStyle and ClassicalReleaseTitleStyle, for guidance. This is a clearer cross-reference, but doesn't attempt to get into the how CSG uses featuring artists. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/RFC%3A-FeaturingArtistStyle-amendment-tp17239632s2885p17241671.html Sent from the Musicbrainz - Style 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] How long is an RFV supposed to stay open?
Mike: Mike Morrison-2 wrote: How long is an RFV supposed to stay open? I thought it was 48 hours per http://musicbrainz.org/doc/StyleCouncil but then I came across http://musicbrainz.org/doc/RelationshipEditor which says two weeks. ...Does the length of time depend on the magnitude of the proposed changes? My experience is that a lot of the documentation at MusicBrainz is incomplete or not fully polished. This includes the documentation of the process for writing documentation. In practice, both StyleCouncil and RelationshipEditor urge achieving consensus. So if you have a consensus, then your action is fine. If there isn't consensus on the proposal, then you experience the difficulty that there's not a strong consensus on what process to follow next. In particular, I think you did a fine job of getting consensus with your 4-25 proposal, and you did the right thing by declaring the proposal accepted. It's up to you to make sure that the change gets implemented, though. Keep your eyes out for the AR change, and raise a flag if no RelationshipEditor makes the change you proposed. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/How-long-is-an-RFV-supposed-to-stay-open--tp17059838s2885p17071483.html Sent from the Musicbrainz - Style 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] CSG: Box set compilations / disc names / title length
knakker: knakker wrote: ...It's more of a standards question that came up seeing the current lack of disc titles for many (classical) releases: are all disc texts other than just disc x considered a disc title and should therefor be added, or is a title something more specific?... The standard for how to fill in the ReleaseTitle field in classical releases is at http://wiki.musicbrainz.org/ClassicalReleaseTitleStyle . Could you perhaps rephrase your question in terms of that guideline? Or in other words, given that guideline, what decisions are still unclear? What parts of the guideline are insufficient? - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/CSG%3A-Box-set-compilations---disc-names---title-length-tp16956192s2885p16967785.html Sent from the Musicbrainz - Style 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] RFV: renaming JapaneseArtistsException to JapaneseArtistsClarification (was: JapaneseArtistsException)
Kuno: A nicely-written page! I'm not entirely clear what you mean by Japanese release, though. Do you mean Japanese-language release, where ReleaseTitle and TrackTitles have some English language text mixed in with Japanese language text, or releases intended primarily for the Japan market, which have ReleaseTitle and TrackTitle in English? I figure this clarification has to apply to ReleaseTitle and TrackTitles which are partly in English, because if they were entirely in the Japanese language then the question of CapitalizationStandardEnglish wouldn't arise. In general I find the English language demands that writers be careful if they want to distinguish between a language, a geography, and a nationality of person; all are reasonable interpretations of a phrase like Japanese release. Kuno Woudt-2 wrote: On Tue, Feb 19, 2008 at 09:25:03AM +0100, Kuno Woudt wrote: JapaneseReleasesClarification perhaps? Yes, please :) If no-one objects, I'll change it in a few days and remove my comments from the page. I'll stick an RFV in the subject here just in case. I'm really not convinced that it's actually a guideline of it's own. Or that it needs an RFV as one. It maybe does need some indication of 'official' concensus I suppose. I don't think it needs to be made anymore official than it is right now. I've made the changes to this page, so for those interested, please have a look and let me know if I made a mistake :). http://wiki.musicbrainz.org/CapitalizationStandard/JapaneseReleasesClarification -- kuno / warp. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Open-call-for-people-who-can-speak-Yiddish%2C-Hebrew%2C-Spanish%2C-Swedish%2C-Turkish%2C-etc-tp15516754s2885p15675893.html Sent from the Musicbrainz - Style 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] Wiki and documentation experts: CategoryTerminology?
Olivier: Olivier-10 wrote: Any WikiGod around with some answers? :-] What to do with CategoryTerminology? It has grown up to the point it's pretty unmanageable. Even as a WikiJanitor :-) , I can see that it's hard to look at the list of pages in this category right now. The page http://wiki.musicbrainz.org/CategoryTerminology would be a really good place to look to get ideas, but the search function which makes this page useful is disabled at the moment. http://blog.musicbrainz.org/archives/2008/02/performance_pro.html - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Wiki-and-documentation-experts%3A-CategoryTerminology--tp15698215s2885p15707107.html Sent from the Musicbrainz - Style 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: What defines a unique release, attempted clarification
Olivier: Great job! Support. And, I was bold and fixed a spelling error in one of your headings. The change log will tell you where. Olivier-10 wrote: + alternative titles for tracks http://wiki.musicbrainz.org/dmppanda/wdaurdraft?action=diffrev2=9rev1=8 Sorry for the spam :] I should be done with completing the draft now. Waiting for possibly more comments before moving this to its place and stuff. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/RFC%3A-What-defines-a-unique-release%2C-attempted-clarification-tp15673758s2885p15706964.html Sent from the Musicbrainz - Style 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: Splitting up ConsistentOriginalData
Kuno Woudt-2 wrote: So, I propose to split [ConsistentOriginalData] into two new pages, and throw away the current name to avoid any further confusion. Support. Kuno Woudt-2 wrote: The two new pages would be: ConsistentOfficialData If, something is consistently labelled in a different style on official sources, then this classifies as ConsistentOfficialData and overrules the StyleGuidelines. Note that you need to provide some evidence for ConsistentOriginalData (ideally in the EditNote), or your edits will most likely be voted down. As Lauri pointed out, you use Original one time in this paragraph, where you should use Official. I also like the Gecks suggestion in http://wiki.musicbrainz.org/ConsistentOriginalData . I made a couple of minor suggestions there. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/RFC%3A-Splitting-up-ConsistentOriginalData-tp15677693s2885p15706827.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: Re: [mb-style] Musicbrainz-style Digest, Vol 34, Issue 86
leivhe wrote: Brian Schweitzer wrote: ... If I gave you just one, you'd assume I cherry picked it. Here's a dozen or so, just pulling from the first 30 on my messy releases list. http://musicbrainz.org/show/release/?releaseid=57554 http://www.amazon.com/Mozart-Relaxation-Richard-Stoltzman/dp/B0I9M0 etc. Leivhe, a virtuoso bit of research! But I think it misses the larger point. The point really ought to be, are the track titles Brian points out really the quality level we want to settle for in MB? I think they aren't good enough for my satisfaction, and I imagine even many tagging consumers would be dissatisfied. The purpose of the CSG is to tell contributors what quality level and style to aim for. Andante isn't good enough. Andante K. 315, as Amazon seems to indicate is on the Release package, is much better, because of the catalog number. The CSG gives a contributor encouragement to add in that K. 315. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Re%3A-Musicbrainz-style-Digest%2C-Vol-34%2C-Issue-86-tp15696280s2885p15707227.html Sent from the Musicbrainz - Style 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] Don't read the C*S*G, smoke it!
Olivier: Olivier-10 wrote: ... [kilometers-long introduction omitted] ... Now, I'm concerned about the following points, which I would really like that you, fine Classical Editors, sort out: 1. Your documentation *sucks* big time. Not because you haven't thought (or discussed) enough about things, but because you're not actually turning these into reality (eg: documentation) Agreed. Olivier-10 wrote: 2. The attitude consisting in telling people in edit notes that the doc ought not to be followed but rather some unwritten knowledge hold by a pair of senior editors is extremely bad - the least reason for that being that whenever these seniors will take vacation, the knowledge will vanish Agreed. In fact I stopped entering my CD's into MusicBrainz in December so that I could whip the docs into shape. i want to enter my CD's according to a written CSG, not the unwritten knowledge. Olivier-10 wrote: 3. All these discussions are for a good part disconnected from reality. Reality being: the classical releases in the db are in bad shape (IMHO, largely worth than what we have in other sections of the database), and we have a somewhat limited system right now that doesn't allow (yet!) for all the fancy super things you have in mind - learn to live with it! Disagree. Many of the kilometres of traffic have in fact been about what goes into classical ReleaseTitles and TrackTitles in today's MB. For instance: how much detail to put in before the : to identify a work. Whether to take the ReleaseTitle from the physical release, a change from what the present ClassicalReleaseTitleStyle says. Whether the composer or performer should be ReleaseArtist. Whether to limit our entries by what's easy for taggers or easy to type. Sure, many more kilometres have been about trivia, or about the future. I think some kilometers were caused by the working culture of this group. It could be more helpful than it is. I think we could be more direct about reaching for compromise, instead of holding to extreme positions. I think we could do better at empowering contributors to be bold about making incremental improvements (you are actually one of the best in this respect). I think we could do better at understanding what each other's messages actually say. I think we could be better at summarising areas of agreement. I think we could be better at thanking and celebrating each other. I found the working culture of Wikipedia and Wikitravel more welcoming than mb-style, frankly. Olivier-10 wrote: ... maybe **WE** could move onto the first step to sanity: Turn http://wiki.musicbrainz.org/ClassicalTrackTitleStyle into a *concise*, *helpful*, *up-to-date*, **adequate**, *manageable*, and not too controversial page. Good idea. Olivier-10 wrote: Good style decisions are not the one that satisfy the über-puristic views of a handful of persons dealing with *a couple of releases*, but these which actually help the majority of people enhance the overall quality of the database. Agreed. Thank you for helping us focus on the big picture. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Don%27t-read-the-C*S*G%2C-smoke-it%21-tp15702869s2885p15707750.html Sent from the Musicbrainz - Style 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] RFV: SameArtistWithDifferentNames
Olivier-10 wrote: Given the RFC just triggered one (positive) answer in a week, I guess we can move on... Just catching up with this thread now. Support. And I updated http://bugs.musicbrainz.org/ticket/3585, which tracks the proposal. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/RFV%3A-SameArtistWithDifferentNames-tp15658899s2885p15672362.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] colossal waste of time (was: Re: Is ConsistentOrginalData really the basis for CSG?)
Lauri Watts wrote: Personally, I think most of the last month's mail flood has been a colossal waste of time, at least as far as an actual CSG and editing with the DB as it is now. I imagine that *some* of last month's mail flood may have been a waste of time. Maybe some of the time spent debating the CSGS lists would have been better spent fleshing them out instead. But contributors still need *somewhere* to discuss the list improvements, right? And, I think a lot of the flood has been useful. Bear in mind, the CSG we have now doesn't reflect current practice, and a lot of CSG traffic has been working over the discrepancies. There is a large backlog of issues in CSGDiscussion and elsewhere. The results haven't shown up in actually CSG pages yet, but that will come. And there's been a side-current of non-CSG issues that are getting approved and closed. I can think of more efficient ways to get the same work done. But while the flood is colossal, I don't think it's a waste of time overall. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Is-ConsistentOrginalData-really-the-basis-for-CSG--tp15596346s2885p15673016.html Sent from the Musicbrainz - Style 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] Is ConsistentOrginalData really the basis for CSG?
leivhe wrote: That's a question I don't really want to pose, but brianfreud claimed so recently in an edit note [1]. To me this was a bit surprising, as I thought people just had agreed (at the very least) that COD was very vague. ... Consistency is often a boon, and I guess that more often than not, people prefer to be consistent in some way or another, but what does the COD has to do with the CSG? Jim's short answer: Yes. Jim's longer answer: It sure would be nice if the text at http://wiki.musicbrainz.org/ConsistentOriginalData were clearer, and if the text in StylePrinciple were consistent with it. It would be nice if the term Original were applied to ClassicalMusic. Sadly, we don't have that. But the key concepts for me are ambiguous and consistent. The consistent data that the CSG draws on is the general musicological convention of identifying works by musical type (e.g. symphony), keys, instruments, opus numbers, etc. The CSG serves to pull contributions closer to that consistent convention, overcoming inconsistencies among the contributor's own habits, and between the wacky variations in tracktitles which publishers put on CD covers and booklets. There is little ArtistIntent, in the sense that the artist in question is a composer who is usually long-dead. What intent we know of is usually encoded in that musicological convention on which CSG draws. There's a practical rationale for having consistency in track titles as the CSG directs. It means one contributor's entries are something that another user can likely accept as adequate. It means that if two contributors each enter one disc of a multi-disc release, there's a fighting chance they will have consistent results. It gives us consistent data, especially in TrackTitles, which gives hope that moving to the Musical Work entities of NextGenerationSchema can be somewhat automated. So, in my mind ConsistentOriginalData is meaningful for ClassicalMusic as a term for that convention that gives us consistent data. I'm in favour of adding text to the ConsistentOriginalData article to have it be explicit about that. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Is-ConsistentOrginalData-really-the-basis-for-CSG--tp15596346s2885p15673195.html Sent from the Musicbrainz - Style 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: Clarify CoverRelationshipType not for Classical, takes 1st release
Olivier-10 wrote: Mechanic in place for documentation right now is: There is no mechanic coz there is no active doc editors So, here is the (not formal) mechanic: ...[snip]... The whole point being: touching the wiki doesn't have to go through the whole hassle of style processing. Just do it :-) Resolving open (controversial) questions on the other hand, does. What a nice process! Since this proposal was purely for wording of the docs, not for open controversial questions, I think I've just been given a blessing to complete the revision quietly with input from a few senior contributers. Thus I'll take it off the StyleCouncil RFC/RFV track. I'm in favour of adding Olivier's process for editing documentation to StyleCouncil, as a way of saying Don't bug the mb-style list for purely editorial changes. And I think it's OK to follow Olivier's process to do that. :-) Jim DeLaHunt wrote: I'll make another draft of my proposal which is all written out, instead of making reference to the existing page And for whoever else is interested, http://wiki.musicbrainz.org/CoverRelationshipType now has revised contents. Comments welcome. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/RFC%3A-Clarify-CoverRelationshipType-not-for-Classical%2C-takes-1st-release-tp15328891s2885p15674409.html Sent from the Musicbrainz - Style 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] RFV: StylePrinciple
Brian: I don't think I mentioned: I created BugTracker http://bugs.musicbrainz.org/ticket/3579 to track this. I think it's more accurate to describe this proposal, especially the revised wording, as RFC rather than RFV. The proposal just got changed, the discussion is unfolding. Once that discussion dies down or becomes unproductive, then I think it will be ready for RFV. Changing to phase_RFC in the ticket. And, I support this modified proposal in the same (sort of guarded) way I supported the previous wording. Brian Schweitzer wrote: Hence why I say, it's an order of precedence and principles we all take for granted anyhow I agree, the wording is badly chosen, both in the original note, and in my referring to it as a guideline So, if I may, let me amend the wording of the RFV, then, to: ...[snip]... - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/RFV%3A-StylePrinciple-tp15501843s2885p15536333.html Sent from the Musicbrainz - Style 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] [Clean up CSG] Correct punctuation (was: Typography)
Brian, David, and all: Brian Schweitzer wrote: Ok, on typography, I'm willing to drop the idea, for the moment. I would much rather focus on getting CSG finished and passed, even if it has to pass with 'plain' typography still required Actually, I'm not quite willing to drop the idea yet. We've had a very good discussion. As I read it, almost everyone who's participating is comfortable with the two-track approach to correct punctuation. Some people, including David, aren't in favour of that. Does the clear majority rule in this case? I intend to send an RFC laying out the two-track approach to punctuation, so that we have a clear proposal to decide on, and can decide in isolation from the other CSG issues. I'm willing to put it to RFV and see if there are vetoes, and if so take the veto to the Elder. This is not to force something bad on everyone, it's an attempt to let our StyleCouncil process unfold the way it says it's supposed to. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/-Clean-up-CSG--Correct-punctuation-%28was%3A-Typography%29-tp15324431s2885p15537118.html Sent from the Musicbrainz - Style 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] JapaneseArtistsException [was: Open call for people who can speak Yiddish, Hebrew, Spanish, Swedish, Turkish, etc]
Lauri: Lauri Watts wrote: (and while we're at it, JapaneseArtistsException is still an open proposal too...) That one was not so much a proposal for a new style guideline, as documenting existing practise. It's really just a reiteration of Consistent Original Data and Artist Intent anyway, in fact, it's as good a brief explanation of both of those (or at least how we apply them) that we have anywhere. I can RFV that one, I think it was mine in the first place. Do you mean the thread [mb-style] Japanese capitalisation fun by Lauri Watts on Thu May 3 07:15:33 UTC 2007 (http://lists.musicbrainz.org/pipermail/musicbrainz-style/2007-May/004744.html) and the comments at http://wiki.musicbrainz.org/CapitalizationStandard/JapaneseArtistsException ? The latter page looks like notes on an issue, but isn't quite clear about which pages to change and how. Could I ask that it get reintroduce as an RFC instead of an RFV, to bring us all up to speed on what the proposed change is? I can create a BugTracker ticket on it if you like. (The above URLs are part of the homework for the ticket, actually.) Should I make you the owner? And BTW I support the exception in principle. I think it's very apt to describe such text as language: Japanese, script: Latin. Modern Japanese culture uses lots of latin-script loanwords and text, and it frequently departs delightfully from standard English (or French or whatever) practice. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/Open-call-for-people-who-can-speak-Yiddish%2C-Hebrew%2C-Spanish%2C-Swedish%2C-Turkish%2C-etc-tp15516754s2885p15537121.html Sent from the Musicbrainz - Style 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: StylePrinciple Reasoning
Lauri Watts wrote: On Feb 17, 2008 1:22 AM, Jim DeLaHunt [EMAIL PROTECTED] wrote: Consider adding a phrase to give a rationale and point the reader to a larger principle, such as: It is more important for MusicBrainz to accurately describe what the artists put into the recording than what the publisher put on the cover. I think anything even near that wording would only further muddy already very murky waters. OK, drop my suggestion. It's not a big deal for proposal at hand. Just to make sure we're on the same page: Lauri Watts wrote: Moving the text is almost a no brainer, and at this point seems unopposed. Modifying it would definitely bear discussion. It may seem trivial, but it's opening a great big wriggly can of worms. [emphasis added by Jim] Actually, I think Philip's proposal is indeed to modify a paragraph, not to move it. See below. Philip Jägenstedt-3 wrote: Having read http://wiki.musicbrainz.org/StylePrinciple I thought the Reasoning section was pretty poorly phrased. Current: There are enough cases of record companies mucking up track listings or even artist names (see some of the Front Line Assembly releases sometime), or creating new imaginary words for stylistic purposes that it makes much more sense to fix these things. I think that we generally value spelling and punctuation correctness over cover accuracy. Suggestion: There are many cases of record companies making errors with track titles or even artist names (e.g. some of the Front Line Assembly releases), or creating new imaginary words for stylistic purposes. In such cases it often makes sense to fix the errors, valuing spelling and punctuation correctness over cover accuracy. Comments? Philip (foolip) - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/RFC%3A-StylePrinciple-Reasoning-tp15500258s2885p15537608.html Sent from the Musicbrainz - Style 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] RFV: StylePrinciple
Brian Schweitzer wrote: Just cleaning out an RFC that never actually became an OfficialGuideline, we all follow StylePrinciple ( http://wiki.musicbrainz.org/StylePrinciple ), and indeed, pretty much the entire which guideline applies structure depends on the steps it describes, but it never actually became a formal guideline. Any objections to this guideline / principle being formalized? In the interests of cleaning up the half-finished business on MB's style pages, I'm not going to veto this RFV. However, I do find that ArtistIntent, StrongGuidelines, ConsistentOriginalData, and StyleGuidelines are not as complete, clearly-written, and consistent with the actual MB practice as I think they should be. That makes the StylePrinciple not much help either. Vetoing this RFV won't fix those problems, of course. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/RFV%3A-StylePrinciple-tp15499310s2885p15518802.html Sent from the Musicbrainz - Style 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: StylePrinciple Reasoning
Philip: Support. Consider adding a phrase to give a rationale and point the reader to a larger principle, such as: It is more important for MusicBrainz to accurately describe what the artists put into the recording than what the publisher put on the cover. I've opened BugTracker http://bugs.musicbrainz.org/ticket/3580 to track this proposal. Philip Jägenstedt-3 wrote: Having read http://wiki.musicbrainz.org/StylePrinciple I thought the Reasoning section was pretty poorly phrased. Current: There are enough cases of record companies mucking up track listings or even artist names (see some of the Front Line Assembly releases sometime), or creating new imaginary words for stylistic purposes that it makes much more sense to fix these things. I think that we generally value spelling and punctuation correctness over cover accuracy. Suggestion: There are many cases of record companies making errors with track titles or even artist names (e.g. some of the Front Line Assembly releases), or creating new imaginary words for stylistic purposes. In such cases it often makes sense to fix the errors, valuing spelling and punctuation correctness over cover accuracy. Comments? Philip (foolip) - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/RFC%3A-StylePrinciple-Reasoning-tp15500258s2885p15518913.html Sent from the Musicbrainz - Style 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] [Clean up CSG] Documentation
Brian: Brian Schweitzer wrote: So I can start getting the new CSG documentation in order, so as to prepare for the eventual RFP, would everyone please take a look at the rewritten CSG I mentioned earlier, http://wiki.musicbrainz.org/BrianFreud/sandbox , *ignoring* content for the moment, only paying attention to the structure and style of the document? ... Wow, this is a monumental bit of writing! I think there is good material there, but I think it is too much to deliver it in one article. My target audience for the CSG is a contributor who has a CD in one hand and a MB web page in the other, who wants to get the music on the CD registered in the database quickly and then move on to something else. They don't want to absorb the full richness of the CSG for it's own sake. Thus we need to give the information in a form and sequence that lets them complete the data entry task quickly but correctly. I believe there is one CSG for all languages. Rules like whether CSG applies, and that Track Artist is set to composer not performer, and that the Track Title identifies the work instead of the title printed on the Release packaging, apply across languages. The human language used only affects some details of how the ReleaseTitle and TrackTitle are worded and punctuated, it does not become a completely different CSG. Thus I support e.g. pages on FrenchTrackTitleIssues and EnglishTrackTitleIssues within one CSG, not a FrenchCSG and an EnglishCSG. I believe that the basic structure of documents should be: 1. ClassicalStyleGuide: entry point. Aimed at a contributor who wants to complete a data entry task. Tells the 20% of the rules which apply to 80% of the cases. Rarely explains why, instead it refers to subarticles that explain rationale, history, and details. Tells how to decide if CSG applies. Summarises but delegates on to subarticles: * ClassicalReleaseArtistStyle: how to set ReleaseArtist field correctly * ClassicalReleaseTitleStyle: how to set ReleaseTitle field correctly * ClassicalTrackTitleStyle: how to set TrackTitle field correctly * ClassicalARStyle: how to set AdvancedRelationships correctly 2. ClassicalReleaseArtistStyle: Aimed at a contributor who wants to fill in a ReleaseArtist field, and needs to decide between composer, Various Artists, performing artist, or collaboration artist of performers. If this gets lengthy, it supplies 20% of the information which covers 80% of the cases and refers off to reference articles for the rest. Rationales, history are removed to reference articles. 3. ClassicalReleaseTitleStyle: Aimed at a contributor who wants to fill in a ReleaseTitle field, and didn't get enough guidance from the brief summary in CSG article. If this gets lengthy, it supplies 20% of the information which covers 80% of the cases and refers off to reference articles for the rest. Rationales, history are removed to reference articles. 4. ClassicalTrackTitleStyle: Aimed at a contributor who wants to fill in a ReleaseTitle field correctly. Contributor should be able to read this article, and perhaps one referenced article for details of a less common structure, and complete the task. This will be the most complex article. It supplies 20% of the information which covers 80% of the cases, and/or gives a decision tree and refers to reference articles for less-common but complex cases. This is the article which links off to the works catalogues for composers. 5. ClassicalARStyle: Aimed at a contributor who wants to complete a data entry task, and motivates them to add a few AdvancedRelationships which do the most to improve the database. Tells which ARs are the must haves, which are nice to have (rest are by implication not important). If this gets lengthy, it supplies 20% of the information which covers 80% of the cases and refers off to reference articles for the rest. Rationales, history are removed to reference articles. 6. Reference articles: aimed at an advanced MB contributor or CSG maven who wants to know the details, the whys, the rationale. Can be long and complete. Articles 1-5 link to these articles as necessary. I think the draft you have in Sandbox tries to be all of #1-6, which is why it is too long. A key filter for #1-5 is: does a particular bit of content help an impatient editor get the data entry task done? If not, then consider moving it off to a reference article (#6). Would it help if I made my own sandbox to demonstrate what I mean by this structure? I don't think I'll be able to do it by this weekend. Thus I think this weekend is too soon for a whole new CSG to go out for RFC. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/-Clean-up-CSG--Documentation-tp15450322s2885p15488246.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ Musicbrainz
Re: [mb-style] [Clean up CSG] Box sets, aka, what defines a unique release?
Brian: Brian Schweitzer wrote: I'm not disagreeing with you - if it's released separately, add just the standalone release. If it's added in a box, add the box. The problem I'm describing is the cases like the Brilliant Classics Master Composers series, or the Philips and Brilliant Classics Complete Edition box sets ...[snip]... I'm suggesting that, in these cases, all the standalones list as one listing, and for the boxes, so long as it still is the same label, all combine into the largest set - so in this case, the 45, the 17, and the half-the-series would all be listed once, as part of the complete series box. If another label - Brilliant Classics, for example - then licenses that CD for a different BC box, that too gets a separate listing, within the same largest BC box concept. ... I'm not following the explanation above, frankly. Even reading the example I snipped out, I'm not following the explanation. What really want to understand, and don't, is what steps a contributor should take, who has a box set in their hand, and no clue about other releases or box sets. How will they know what existing MB entries to look for? What should they do with them if they find them? How will they know which of the CDs in the box have been released in the past? How will they know how to group the CDs? What text on the box or in the insert do they look for? - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/-Clean-up-CSG--Box-sets%2C-aka%2C-what-defines-a-unique-release--tp15446985s2885p15488668.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
