Good point, updated. I'd appreciate any other language comments. Thanks, Jeroen
On Sun, Nov 21, 2010 at 7:17 PM, Frederic Da Vitoria <davito...@gmail.com>wrote: > Your new version does not remove my previous concerns, because I didn't > have any more :-) But I suggest replacing "The following relationship types > are considered 'generic types':" with something "Here is a list of "generic > types" and examples of preferred specific types:", else someone will have to > update this Guide each time we create an new specific type AR. > > 2010/11/20 Jeroen Latour <f.j.lat...@gmail.com> > > Hi everyone, >> >> What I'm hearing is: >> * Chris wants to tell editors that "writers" and its kin are a sub-optimal >> credit. >> * Frederic and Brian want to prevent editors from guessing credits and >> entering wrong data that cannot easily be discovered later >> * Brian feels the current text pressures editors too much in doing extra >> research. >> >> I've updated the proposal to remove the sentence requiring editors to do >> extra research. >> * It still says that "writers" and the other generic types should be >> replaced with specific credits, if possible. >> * It still does not suggest that editors guess credits, saying that when >> in doubt you should stick with the less specific types. >> * It no longer pressures editors to do extra research, asking them only to >> look at the information that is available and to think. >> >> Brian, you also made some remarks suggesting that it's wrong to ask >> editors to deduce. I feel that if it's really obvious which of the subtypes >> apply, we should encourage editors to use those instead as it enriches the >> data. Note that the proposal says 'easily deduce'. >> Chris, I've also made no distinction between ARs for Works and ARs for >> Recordings. Like Frederic, I don't yet see the reason for doing so. >> >> Brian, I've mentioned the RFC in the list of specific types as you >> suggested. >> http://wiki.musicbrainz.org/Proposal:Prefer_Specific_Relationship_Types >> >> Does this take away some of the concerns? >> >> Regards, >> Jeroen >> >> On Fri, Nov 19, 2010 at 10:24 PM, Brian Schweitzer < >> brian.brianschweit...@gmail.com> wrote: >> >>> >>> >>> 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. >>> >> > -- > Frederic Da Vitoria > (davitof) > > Membre de l'April - « promouvoir et défendre le logiciel libre » - > http://www.april.org > > > _______________________________________________ > MusicBrainz-style mailing list > MusicBrainz-style@lists.musicbrainz.org > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style >
_______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
