[mb-style] RFC-327: Featured Artists

[Andii Hughes]

On 12 July 2011 17:25, Aurélien Mino <a.mino at free.fr> wrote:
> On 07/12/2011 04:45 PM, Andii Hughes wrote:
>> I've written a proposal for handling featured artists post-NGS:
>>
>> http://wiki.musicbrainz.org/Proposal:Featured_Artists
>>
>> This deals with the legacy data issue (ws/1 still provides data in
>> pre-NGS format) by retaining the existing guideline for track
>> listings, while making use of artist credits at recording level.  When
>> ws/1 is finally removed, we can allow track listings to be entered as
>> on the release, as some have suggested.
>>
>> RFC Expiry Date: 19th of July, 2011 (in 7 days)
>
> I disagree and would veto this proposal.
>
> I don't see a good reason enough to wait for formating data in a better way.
>

As Nicolás already pointed out, vetoing the proposal would keep the
existing use of feat. in the track title for everything, which
contradicts your second point.

I think the proposal is an acceptable compromise while we're still in
the early days of NGS.  It provides access to a better way of
representing these tracks at recording level, while retaining the
status quo at other levels   I neglected to include releases and
release groups in the initial version of the proposal, but these are
now listed along with track listings.

> 1. Legacy ws/1 can stay for a long time. If data consumers want better
> data, they should just migrate to ws/2.
> ws/1 is here for compatibility, but should not restrict us in how we
> format data.

Migrating to ws/2 is not something you 'just' do.  It's an extensive
change which has been years in the making, and requires significant
redesign work to adapt to it on the part of web service consumers.
Even projects closely related to and developed by MusicBrainz
developers (Picard and the C/C++ bindings) only have beta versions
available with initial support for NGS.

I could understand your point if ws/2 had been available for a long
time but it's less than two months since NGS was launched.  My point
with supporting ws/1 was that I assumed some termination date had
already been decided for this service, but I can't find any reference
to one.  Would it be more acceptable if we said that this happened on
the 18th of May, 2012 (a year after the release of NGS) rather than
some arbitrary time?

A professional project provides gradual removal of established
features and behaviour, rather than abruptly changing things
overnight.  I believe MusicBrainz to be a professional project and
that's why it's used and sponsored by companies like the BBC and
Google, and why ws/1 is still available at all.  Handling transitions
like this well allow more people and companies to rely on MusicBrainz
and, in turn, provide funding which results in a better MusicBrainz
for us all.  Treating users with disdain does not help, and if it's a
choice between forcing to rush into ws/2 or dump MB altogether, some
may have to take the latter route.

The ws/1 service is here for compatibility, but that becomes
compatibility in name only if the actual data becomes useless due to
changes been made which we know to be harmful to this compatibility
service.

>
> 2. Having a different rule and practice for recording and tracks is
> confusing.
>

That already applies generally.  My understanding is that one of the
reasons for separating them was to allow different rules to apply at
track and recording level, with the track level retaining a more
accurate representation of the original data from the cover or
whatever of the release and the recordings being normalised.  Thus,
any rule for track listings would be different anyway, presumably
going something like 'represent it as on the release but use artist
credits', whereas the rule for recordings given here specifies
specific join separators for standardisation.

What I foresee this guideline allowing is for the mass of recordings
containing 'feat. X' in the title to be changed to give proper
attribution to artist entities.  I don't see it making a huge
difference to the entering of new releases as these will need to use
the old guideline and then have any new recordings altered later.  The
number of existing recordings should easily outnumber the recordings
created in the space of the next year.

> 3. Changing data is a long process. E.g. we still have releases missing
> proper catno, label, format information whereas this info is in the
> release annotation.
> So phasing data changes is a wrong method, and will just lead to data in
> an inconsistent state.

Well, first of all, the major difference from the examples you list is
that these require research (preferably the actual release) whereas
moving feat. is a mechanical operation.  I believe you could pretty
easily write a bot to do the majority of them, parsing '(feat. X)' and
moving it to the artist credit if a single 100% match is found for X.

More generally, this is always going to be the case with such a huge
database and generally you will find data on releases which active
users care about is of high quality and regularly updated, and other
releases are in a much worse state.  During my editing of MB over the
past four to five years, I've certainly noticed this.  For example,
there's a lot of excellent work on some high profile rock groups, but
some of the pop and electronica artists are a complete mess :-).
There's also a clear preference in autoeditor nominations to reward
people who work in particular niche areas which are otherwise
untouched.

Also, having worked on trying to convert some of the collaboration
artists that weren't automated (e.g. 'X vs. Y'), the process of
changing track entries and changing recording entries is pretty
separate.  It's possible to clear one and leave the other completely
intact.  So I don't see too much problem with only allowing one change
on feat. artists for now.  As you say, it's not like there's not
plenty of other cleanup work to do!

>
> - Aurélien
>
> _______________________________________________
> MusicBrainz-style mailing list
> MusicBrainz-style at lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>



-- 
Andii :-)