On Fri, Nov 19, 2010 at 4:30 AM, Frederic Da Vitoria <davito...@gmail.com>wrote:
> 2010/11/19 SwissChris <swissch...@gmail.com> > >> >> On Thu, Nov 18, 2010 at 7:27 AM, Brian Schweitzer < >> brian.brianschweit...@gmail.com> wrote: >> >>> On Wed, Nov 17, 2010 at 1:14 PM, Jeroen Latour <f.j.lat...@gmail.com>wrote: >>> >> Not telling the editors clearly that "wrote" is a sub-optimal credit, >> which we (if possible) should try to replace by "composed" or "wrote >> lyrics/libretto" is damageable to the MB data quality and is going to be a >> lot of unnecessary work to correct. >> > > I disagree: what would be really damageable would be to input bad data with > no way to know where the bad data is. Writer instead of Composer and/or > Lyricist is incomplete, but > 1 - it is not wrong (only incomplete) > 2 - it is easily locatable. > > I agree the second, more precise, solution should be preferred, but only if > the editor is quite confident which more specific AR(s) should be used. > Yes, thank you Frederic, this is exactly it. As I cited earlier, the language that is there currently seems too strong. "You can easily" seems somewhat mocking of the editor who doesn't do it, "You should" is not the same as "You can, if you feel comfortable doing it", etc. Let's say liners say "wrote" but the editor knows from another source that > the artist composed the music (but nothing about the lyrics); if we push too > much in your direction, the editor would be tempted to enter a Composer and > a Lyricist AR, which could be completely wrong. In this case IMO he should > enter a Writer AR and a Composer AR. > On a side note @ Brian: I don't really understand your arguments: In the >> discussions about re-adding [traditional] you were the one fighting against >> fuzziness, telling editors to *not* simply take the liner using “trad." for >> granted, asking for precise guidelines. Why is it now wrong to tell the >> editors that "written by" on covers/sleeves/liners does not (should not!) >> automatically translate into *our* "written by". After all these are >> guidelines, not strong rules, still leaving the final decisions to the >> discretion of the editors (and the voters). We're just telling them to have >> a closer look before making a decision. >> > > You are taking quite a shortcut here: "does not" is completely different > from "should not". I agree with "does not", I don't with "should not". And I > fail to see how editors could not understand "You should make an effort to > make the relationship type as specific as possible. This means that you > should avoid any of the generic types(...)" to mean what you are asking for. > Again, I agree. Chris, you're trying to compare this with [trad]. Yes, I asked for more precise guidelines there. 'Precise' in terms of when [trad] would be correct, however. I was/am perfectly fine with an editor using [unknown] if s/he's unsure if unknown, anon, or trad would be best. That's not the same as saying that an editor *should* try to decompose a fuzzy AR. On the contrary, I think the my positions on the two things are entirely complimentary. Re: [trad] I wanted a clear definition for when it would correctly be used, and when it should not, *if* it is used, and re: this proposal, I think the option to do it should be left to the editor - is the editor comfortable? is the editor sure? - if not, then don't decompose it. This proposal, on the other hand, seems to say the opposite - it requires the editor to do things, unless they can prove the reason *not* to do it. That seems backwards to me. > > Last, under "Generic Types", I think there should also be identification >>> of the ARs which are the "less fuzzy" version for each of those generic >>> types. Ie, "Arranger" -> "Instrumentator", "Orchestrator", and so on. >>> >> >> While writing I start to doubt whether it is a good idea really to have >> all these generic types put together in one guideline. >> "Writer/Composer/Lyricist" (and maybe at least some types of "Arranger") are >> fundamental information for "Works" while the others are >> "Recording"-related. I can easily accept fuzziness for the latter, but I >> think "Work"-related types need more emphasis on precise information. >> > > Probably not: I don't see why one would be less picky about data quality > for Recordings than for Works. Especially since recordings all are from the > modern era while a lot of works were composed at a period when exactitude > was not a preoccupation :-) > > Yes, Frederic, I agree - I don't see the reason why we'd be more accepting of "guessed" ARs over "fuzzy" ARs based on the liner, simply because one AR is about the work but the other about a performance. But I don't read Chris as saying that. Chris, what you're saying in that last sentence I can accept, though it comes down to 'known facts' vs 'fuzziness'. I think both recordings and works (and all other entities, for that matter) should only have such ARs as we can either directly prove from documentation, or clearly interpret from other information. I'm fine, then, with the AR results being however fuzzy they end up being - after all, it's the best we can do without more info, *without* guessing (and perhaps guessing wrong). The last is my problem with this proposal's current text. I don't disagree with the proposal, and I think you comments about my 'unwillingness', etc. are a bit unfair. Indeed, I was the one who suggested this proposal, rather than have this as a part of the writer AR. I think this proposal is right, but also think that the current language pushes too far in the direction of required guessing, rather than *allowing* reasoned guesses, but only if we're comfortable and pretty much sure that they're the only possible interpretation. Otherwise, as Frederic says, we might benefit by guessing right in some places - but any benefit there is far outweighed by the incorrect guesses which create indistinguishable wrong ARs. Brian
_______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
