[mb-style] Agree, and more detailed proposal [was: Re: Composition/Performer/Production ARs at Release or Track level? - PROPOSAL]

[Bram van Dijk]

Well, I admit that I didn't pay a lot of attention to all  the NGS stuff 
(not enough champagne to kill me, but still more than enough). I was 
mainly trying to say that the stuff in there which affects how we edit 
(and vote on edits) now. (Which basically comes down to: apply AR's to 
the lowest level possible.)

Still, it seems that in the proposal the introduction of track masters 
(the technical solution) solves your original problem about AR 
propagation, just as I stated in the original thread.

So I don't feel like I changed my mind, at least, if I understood 
everything correctly. Sorry to have confused you ;-) .



On another note, I think that the "quarrel" here is also a bit about 
what musicbrainz is. Either a database for tagging mp3 files, or an 
encyclopedia of music.

If it is just a means of tagging MP3 files, there is no need for 
release-level AR's, unless they propagate to tracks. And if they 
propagate to tracks, an AR should only be added at the release level if 
it should propagate to each track. (view 1)

While those who think of musicbrainz as an encyclopedia think that a 
release-level credit should be documented, even if it does not propagate 
to each track. (view 2)

Bram

Olivier schreef:
> 2008/1/3, Jim DeLaHunt <from.nabble at jdlh.com>:
>   
>> J-1: A Release is an entity that exists separately from the Tracks it
>> contains. An AR can describe a Release without describing the Tracks of the
>> Release. The "provided photography on" AR is an example.
>>
>> J-2: Brief Definition: a Track is one rendition of a Track Master. Each
>> Track has exactly one Track Master, but each Track Master can be rendered by
>> multiple Tracks.
>>     
>
> I don't think so. It's fairly common to see a master being splitted
> into multiple tracks, or several masters being spliced into one track.
> I guess that depends on what you call a track master - the use of
> "rendition" here doesn't make it really clear.
> Is a "Track Master" for you what is (actually) linked through an
> "earliest version" or an "earliest release" link? Or something else?
>
> I will assume you're speaking about Track Master as in "earliest
> release", and that we are speaking of tracks re-issues, not
> "rendition" - hence my reserve above, as IMO track masters should take
> into account the cases I mentioned (maybe through relations between
> track masters? Hence inheritance will not be as straight-forward as
> you suggest it).
>
>   
>> A Track Master contains performances of one or more Musical
>> Compositions. A Musical Composition is an entity that exists separately from
>> any performances of it.
>>
>> J-3: An AR describes at most one of a Track or a Track Master or a Release
>> or a Musical Composition. (Some ARs describe none of these, e.g.
>> Artist-Artist or Artist-URL ARs. They don't apply in this discussion.) As
>> part of this proposal, we need to go through each AR and be specific about
>> which entity it describes. Some ARs may need to be split if they say
>> different things about Tracks vs Releases.
>>     
>
> Well... I don't agree here... Some AR (the earlier mentioned "wrote
> liner notes") are perfectly valid either on the track or release
> level, with the exact meaning that they just apply to the given level.
> 1. Artist A wrote liner notes for Release B
> 2. Artist C wrote liner notes for Track C (on release B)
> Same AdvancedRelationship (and I really don't see a need to split it
> up), and #1 sure *doesn't* mean that A wrote liner notes for each
> track, or that it's fuzzy.
>
> The same goes for the "producer" AR, as mentioned several times in
> this thread...
>
>
> Sure thing, documentation may be clarified and enhanced in several
> places. Not really the problem though. What this proposal is trying to
> pass from the beginning is the assumption that a given AR can only
> "really" apply at one given level, and that having it applied at
> another level means either some kind of fuzzyness, or complete implied
> inheritance, which is just plain wrong IMHO - really, we were proposed
> with two "viewpoints", and both where entirely similar from that point
> of vue, which, again, seems to me entirely erroneous and uninformed.
>
>   
>> J-4: An AR that describes a Track *should* be attached to each individual
>> Track record that it applies to, if there is solid evidence that ties the AR
>> to that Track. If it means an AR is attached to every Track in a Release,
>> that's fine. Similarly, an AR that describes a Track Master should be
>> applied to each individual Track Master entity, and an AR that describes a
>> Musical Composition should be applied to each individual Musical Composition
>> entity; if there is solid evidence.
>>     
>
> And we are back at the "fuzzy" part.
> What do you call a solid evidence"?
> This is one of the critiqued point from the start of this thread: some
> people (me for example) think that you just shouldn't add data without
> solid evidence. If you have reasons to doubt the given credits, just
> don't add the link!
> Cases:
>  * If it's on a sleeve and you don't know better, how would you be
> able to judge if it's even "fuzzy" or not?
>  * If you know better than sleeves, use that "better" knowledge, and
> if still in doubt, please use annotations, not links
>  * If you're just sourcing from your local tags/random info, just don't do that
>  * If you're sourcing from Amazon/OtherDB without cross-checking, just
> don't do that...
>
>   
>> J-5: An AR that describes a Track or Track Master or Musical Composition
>> *may* be applied to a Release. This formally means that this AR applies to
>> some, at least one and perhaps all, Tracks of the Release.
>>     
>
> Or either (given we don't really have track masters but pretend we do)
> that applying at release level just made more sense rather than at
> track level (a release consisting of one master that was splitted into
> several different tracks).
>
>   
>> Applying a such
>> an AR to a Release is appropriate if there is solid evidence which ties the
>> AR to the Release, but which does not specify to which Tracks (or Track
>> Masters or Musical Compositions) the AR applies.
>>     
>
> Same objections, see above.
> Here, again "solid evidence/fuzyness/etc" just don't (yet) make sense.
> Keeping the "fuzzy" definition "fuzzy" will encourage both sloppy
> editing and undesirable defiance toward sleeves.
>
>   
>> J-6: If you find a Track or Track Master or Musical Composition AR applied
>> to a Release, then you must not conclude that the AR *certainly* applies to
>> each Track (or Track Master or Musical Composition) of the Release. You must
>> conclude that it *might* apply to any or all of them, and use that
>> conclusion appropriately for your task. For example, if you are a tagger,
>> you might put the AR information into an MP3 tag, but marked with a "?".
>>     
>
> Same problem as above (assuming that the same AR can't apply at
> different levels without being either strictly equivalent to being
> applied to the level under it (so called viewpoint 1), or that it's
> fuzzy (so called viewpoint 2))...
> At least, current Picard behavior perfectly makes sense in that there
> are no physical "releases" container when it comes to tagging, and
> that the only place to store release level AR is in track tags, hence
> systematic propagation.
>
>   
>> J-7: If you are summarising information about a Release, if it is
>> appropriate for your task, it is correct to include AR information from the
>> Tracks, Track Masters, and Musical Compositions of that Release in the
>> summary. For instance, if you are generating a report about the Performers
>> on a Release, it is correct to list all Artists mentioned in Performer ARs
>> for all Track Masters and Tracks.  If you find that in all the Musical
>> Compositions of a Release there is only one Composer mentioned, it is
>> correct to report that as the "Composer of the Release".
>>
>> J-8: An AR that describes a Track Master may be attached to a Track. (Right
>> now it *always* will, by necessity, since there are no Track Master entities
>> in the MB structure.)  This means that the AR applies to the Track Master
>> associated with the Track. If there is no explicit Track Master entity, then
>> the Track Master is implicit, and the Track is its placeholder. Where a
>> Track Master or Musical Composition record for the track exists, it is
>> always correct to remove relevant ARs from the Track and apply them to the
>> Track Master or Musical Composition entity.
>>     
>
> Apparently, I raised quite a fiery opposition about that (the "remove"
> part) earlier (with some reasons), though I tend to agree with that
> point.
> Check the "propagate AR or not along earliest lines" thread a couple
> of weeks ago.
>
> Interestingly, Bram van Dijk stated in that thread that:
> "[...] require lots of editing effort, and since there will (some
> day) be a technical solution to these issues, the concensus seems to be
> that this effort can be used in more productive ways."
>
> And now Bram seems to no longer have any objection about it :-)
>
> Too much champaign? Or do people who were thinking that a (very
> localized) question from a couple of weeks ago had to wait for a
> proper technical solution, *now* think that (the whole shebang
> problem) can't wait no longer?
> Mmmm, go figure :]
> </teasing>
>
>   
>> J-9: An AR that describes a Musical Composition may be attached to a Track
>> or Track Master. (Right now it *always* will, by necessity, since there are
>> no Track Master or Musical Composition entities in the MB structure.)  This
>> means that the AR applies to some, at least one and perhaps all, of the
>> Musical Composition(s) associated with that Track Master. If there are no
>> explicit Musical Composition entities, they they are implicit, and the Track
>> Master (or Track) are the placeholder for them. Where a single Musical
>> Composition entity for the Track Master exists, it is always correct to
>> remove relevant ARs from the Track and apply them to the Musical Composition
>> entity. Where multiple Musical Composition entities for the Track Master
>> exist, then it requires editor judgment to move the AR from Track or Track
>> Master to Musical Composition.
>>
>>     
>
>   
>> J-10: Transition task: Review all Track and Release ARs and assign them to
>> exactly one of a Track or a Track Master or a Release or a Musical
>> Composition. Revise the AR description to be precise about what it is
>> describing. If needed, split ARs which presently mean one thing for Track
>> and another thing for Release.
>>     
>
> Clean-up and enhance the doc, sure.
>
> As for the rest, there exists ARs that can legitimately apply to
> different levels, with exactly the same "meaning" (but the entity to
> which they apply), and not being equivalent to being set for all
> entities on the below level, neither have a "fuzzy" meaning.
>
>   
>> J-11: Transition task: Review all Track or Track Master or Composition ARs
>> that are attached to Release entities, and make a judgement about whether
>> they should be migrated to Tracks.  It would be helpful to have reports and
>> tools to make this easier. It would be nice to let editors who added ARs get
>> first crack at judging them.
>>     
>
> Please, yes. No bot, and no mass-uninformed editing :-)
>
>   
>>  It will be important to have a convention for
>> recording judgements that an AR belongs at the Release level.
>>     
>
> Not sure what you are referring to, here?
>
>   
>> J-12: When Track Master entities join the MB structure, it should be a
>> fairly mechanical operation to migrate Track Master and Musical Composition
>> ARs from Track to Track Master entities.
>> It's mechanical because each Track
>> has exactly one Track Master.
>>     
>
> As stated, I don't think it will be that trivial (assuming I
> understood you definition of Track Masters) - again, I have no idea
> how Track Masters will get implemented, and how we will be able to
> relate Track Masters together.
>
>   
>> Track Master and Musical Composition ARs which
>> are attached to Release entities at this stage can stay there, if an editor
>> has judged that they belong at the Release level.
>>
>> J-13: When Musical Composition entities join the MB structure, most Track
>> Masters will have exactly one Musical Composition. For these, it should be a
>> fairly mechanical operation to migrate Musical Composition ARs from Track
>> Master to Musical Composition entities.  However, there will be a transition
>> task to determine whether a Track Master contains one or multiple Musical
>> Composition entities. If multiple, there is a judgement task to decide to
>> which Musical Composition each such AR belongs.  There will probably be some
>> judgement tasks to resolve conflicting ARs migrated to one Musical
>> Composition from multiple Track Masters.  Again, Musical Composition ARs
>> which are attached to Release entities at this stage can stay there, if an
>> editor has judged that they belong at the Release level.
>>
>>
>> Whew.
>>
>> Comments?
>>     
>
>
> Well, beside rephrasing here the objections raised earlier in the thread:
>  * enhancing the documentation, am all for it
>  * I disagree with the assumptions made by the thread about how ARs
> relate to entities, especially the two restrictive (and similar to
> some extent) viewpoints presented as the only alternatives. They are
> just black-and-white ideas that lacks background
>  * if something is going to be master-minded about how the AR question
> is going to mix with NGS evolutions, I think it still need more
> thinking rather that a somewhat simplistic view of it (your concept of
> Track Master, especially, probably can use some refining <- again I
> don't know if/how that will get done)
>
> So I'm all for clarifying the documentation*s* for each individual AR,
> and such an effort is definitely welcome and this sure can be
> discussed on a case by case AR basis. Now, I just can't agree with
> some sort of (supposedly) work-for-all ill-formed conception about
> "everything" (even if everything is just perf/prod/comp ARs, which is
> already quite a lot).
>
> All in all, what problem does this thread try to solve?
>  a * if it's the global question of NGS and AR, I think this
> discussion here is not appropriate, that it's too early (without even
> knowing what exactly we will have from NGS and in what timeline, and
> exactly how things will get implemented)
>  b * if it's some local question about a specific AR
> (implied/fuzzy/whatever) inheritance, yes, let's think about it, AR by
> AR, by small chunks on which we can agree rather than as a big blurb
> blanket statement about the inheritance problem as a whole ;)
>  c * if it's to help newbies and have a more uniform way of voting, I
> think the solution will come from (b)
>
>
>
> I'm very glad you're (apparently) willing to tackle some doc
> enhancement, and that this thread orients towards something
> productive.
> If you need to edit the wiki but still want the official doc to stay
> still meanwhile, please just ping me or editor "murdos" so we put the
> needed pages into transcluded state meanwhile.
>
>
> Best regards,
>
> - Olivier
>
> _______________________________________________
> Musicbrainz-style mailing list
> Musicbrainz-style at lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
>
>