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

[Olivier]

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