History:Featuring Artist Style: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
(Huston, we have a problem (Imported from MoinMoin))
(No difference)

Revision as of 22:33, 17 November 2005

Style for Featuring Artists

Alert.png W A R N I N G ! Alert.png

This is complete chaos at the moment.

What the Hell Is Going On?

The old FeaturingArtistStyle is very disputed. There were numerous attempts of GettingRidOfFeaturingArtistStyle. Several lengthy and heated discussions happened on the StyleMailingList (and only there. A huge section of the users never knew what happened). Finally a new guideline was proposed (see below).

During these discussions we found out that the StyleCouncil lacked procedures for deciding upon issues. The majority of the members of the StyleCouncil supported the new guideline in an apache-like vote launced by RodBegbie. This vote however has no legitimity.

Finally the new guideline was made quasi official by Zout on 15-11-2005 by changing this wiki page. He did so because it was supported by a majority of those people that took part in the discussion.

Now that is is being applied other poeple are raising strong objections to the new guideline, mainly because it forces editors to change albums into VariousArtist albums.

Therefore neither guideline can really be considered official at the moment. We really have a problem.

Both the old and the new guideline are listed here for your information:

Old Guideline

When two artists collaborate on a track or release, file the track/release under the primary artist, and then append the name of the secondary artist to the name of the track/release as follows:

  • "Put Your Lights On (feat. Everlast)"

If neither artist can be considered secondary, choose either artist.

New Guideline

If two or more artists collaborate on a track or release, with one artist being the primary artist,

  • "Put Your Lights On (feat. Everlast)"

If no artist can be considered secondary,

  • "Artist 1 & Artist 2"

and file the track/release under that artist, and

Example

darely needed

History of the Guideline

There was a lot of discussion going on on the MailingList regarding this guideline (10/2004). General consensus seems to be that we want to scrap this guideline, however there is no "good" way to to do this with the present system and so work on this will be postponed until AdvancedRelationships comes in. In this process the VersusStyle will probably be changed as well.

See the discussion thread for more details.

Now that AdvancedRelationships is available, the removal of this guideline has been brought up again. The newest discussion on the mb-users list can be found here.

Nothing has really changed since then and in 10/2005 RodBegbie has raised this issue again in this email thread. This OpenStyleIssue is on the agenda for the MusicBrainzSummit7 and is discussed in GettingRidOfFeaturingArtistStyle.

As of 15/11/2005 this guideline has been changed. A majority of users and members of the StyleCouncil have agreed upon the new guideline as written above, although the decision process was quite messy, to say the least.

Attempted summary of that discussion

By MatthewExon. (this does not yet reflect the discussion of 10/2005)

There was some kind of consensus that the very best way to handle many of these collaborations would be to attach more than one primary artist to a song or an album, similar to how discogs does it. There was an objection that many applications expect a single primary artist, but this could be solved by just concatenating artists together with "&" for those applications. There was also (somewhere, can't find it now) an objection that this would be inefficient for the back end. The major problem with this, however, is that it's a pretty big upheaval of the database, requiring a huge amount of website code to change, and so this isn't going to happen any time soon.

In the meantime, the guidelines are there to try and strike a compromise between readability and usefulness now, and the ease of conversion to the above system whenever it becomes available.

The current, pre-AdvancedRelationships FeaturingArtistStyle does this by arbitrarily choosing one artist to be primary, and putting the others in brackets with "feat.". This guideline is widely reviled because it's counter-intuitive and impedes searching for works by an artist. A script to convert to a full multi-artist system would have to parse out all the "feat." bits and figure out which artists were meant, intelligently bypassing commas and ampersands only where appropriate.

The alternative proposal is to add new artists representing the collaboration, called "X and Y" or something, and link both artists to the collaboration using "collaborated on" relationships (see MusicalAssociationRelationshipClass).

Problems with this:

  • Will add thousands of pseudo-artists to the database, which strikes lots of people as counter-intuitive.
  • Makes it harder to navigate from an artist to all of the works they actually performed on.
  • Much slower to add these collaborations using the website, since you have to go through the palaver of adding new artists and setting up a bunch of relationships.
  • Results in a mess like what's happened to Tom Morello (see here and here).

Advantages:

  • Probably a cleaner way of setting ourselves up for the "nice" system above
  • Means recording collaborations with actual artist IDs rather than merely putting their names in a freetext field
  • Helps when trying to identify which tracks on different albums are actually just the same track
  • Probably going to be more straightforward for a script to convert to the ideal situation above.

There's still lots of disagreement over which style is the best. In the database right now, we have a mixture of styles, depending largely on what made sense to the editor at the time. In the absence of a real consensus this seems likely to continue. Each style is particularly appropriate or inappropriate in certain situations, so even if we came up with an "official ruling", it'd probably be ignored by those users who don't read the mailing list ('desire lines', like David Scotson says).


CategoryHustonWeHaveAProblem