Difference between revisions of "History:Getting Rid Of Featuring Artist Style"

From MusicBrainz Wiki
(additional 'pro' for sg5 (Imported from MoinMoin))
((Imported from MoinMoin))
Line 17: Line 17:
 
** The "feat" artist is providing guest instrumentation on a track.  (TODO:  Find example)  
 
** The "feat" artist is providing guest instrumentation on a track.  (TODO:  Find example)  
 
** The "feat" artist is a primary collaborator on a track. (eg. [http://musicbrainz.org/track/ff0df0ce-d49d-491d-9247-1aa2fa0c6df1.html http://musicbrainz.org/track/ff0df0ce-d49d-491d-9247-1aa2fa0c6df1.html])  
 
** The "feat" artist is a primary collaborator on a track. (eg. [http://musicbrainz.org/track/ff0df0ce-d49d-491d-9247-1aa2fa0c6df1.html http://musicbrainz.org/track/ff0df0ce-d49d-491d-9247-1aa2fa0c6df1.html])  
 +
** The "feat" artist is a composer of a track. (eg. [http://musicbrainz.org/track/9bbe8738-32bd-41e9-acec-bfac9ae62947.html http://musicbrainz.org/track/9bbe8738-32bd-41e9-acec-bfac9ae62947.html])
 +
** The "feat" artist is a co-producer of a track. (eg. [http://musicbrainz.org/track/6db39d74-12c5-4eb7-b4f8-e73d7a97c5d0.html http://musicbrainz.org/track/6db39d74-12c5-4eb7-b4f8-e73d7a97c5d0.html])
  
 
* Unless the featured artist is added as an AR *in addition* to the text in the title field, there is no way to track at a database level guest performances, collaborations, etc.  
 
* Unless the featured artist is added as an AR *in addition* to the text in the title field, there is no way to track at a database level guest performances, collaborations, etc.  

Revision as of 17:29, 20 October 2005

Getting Rid of Featuring Artist Style

This page tries to sum all problems of and possible solutions to the FeaturingArtistStyle.

The idea to create this page comes from a post from DonRedman on mb-users (start of discussion here).

Problems with the current Guideline

The current FeaturingArtistStyle has a couple of severe issues. This section should identify them:

  • Storing artist information as a section of the Title field is incorrect.
    • The Title field should contain a track's title.
    • The Artist field should contain a track's primary artist. The primary artist can be a Person, a Group or a Collaboration.
    • Any other contributors should be stored as Relationships to the track.
  • Unless the featured artist is added as an AR *in addition* to the text in the title field, there is no way to track at a database level guest performances, collaborations, etc.
  • A search for A & B doesn't list artists that have tracks Track Name (feat. B).

On the other hand the current Guideline is not completely void of sense. the pro's for it are:

  • The hierarchy between the CoreEntities Artist-Album-Track is kept (well, at the expense of one artist being completely dropped out of this hierarchy). Most media players categorize tracks this way.
  • This presentation of the 'featuring' artists is often done in this exact format on the real world tracklisting.
  • ...

Proposed Solutions

This section should help to get a clearer picture of the proposed solutions and their pros/cons.

  • Change the style guide. Strawman: When two or more artists collaborate on a track or release, file the track/release under the primary artist, and then add Performance relationships to the secondary artists. If no artist can be considered secondary, create a new artist in the form 'Person A & Person B' and add the artists as collaborators.
    • Pros: Removes cruft from Title fields. Stores richer information (what did the secondary artist perform?) Creates a more relational and future-proof database. Requires no coding changes.
    • Cons: Secondary artist information will not be added to ID3 tags. Current website design doesn't give visibility into relationships attached to Tracks. Current website design to add members to a Group is clunky.
  • Continue without changing the style guide until Picard can deal with giving users options on how they want AR data applied to tags.
    • Pros: Requires no changes to anything now.
    • Cons: Will compound the current problem. Will make it harder to switch to a "correct" approach in the future.

Now we would need to describe these proposals in detail and then sum up all arguments for and against them.


Authors: RodBegbie