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

From MusicBrainz Wiki
(My two cents, in full. (Imported from MoinMoin))
(additional 'pro' for sg5 (Imported from MoinMoin))
Line 23: Line 23:
 
On the other hand the current Guideline is not completely void of sense. the pro's for it are:  
 
On the other hand the current Guideline is not completely void of sense. the pro's for it are:  
 
* The hierarchy between the [[Core Entities|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.  
 
* The hierarchy between the [[Core Entities|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.
 
* ...  
 
* ...  
  

Revision as of 17:02, 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