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

From MusicBrainz Wiki
(corrected typo (Imported from MoinMoin))
(My two cents, in full. (Imported from MoinMoin))
Line 8: Line 8:
  
 
The current [[Featuring Artist Style|FeaturingArtistStyle]] has a couple of severe issues. This section should identify them:  
 
The current [[Featuring Artist Style|FeaturingArtistStyle]] has a couple of severe issues. This section should identify them:  
* Applying [[Featuring Artist Style|FeaturingArtistStyle]] makes information disappear. Converting '''A & B - Track Name''' to '''A - Track Name (feat. B)''' doesn't necessarily mean artist A is the primary artist and B is a sort of guest artist.  
+
* 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.
 +
 
 +
* Currently "(feat. xxx)" can mean one of several things:
 +
** The "feat" artist is providing guest vocals on a track.  (eg. [http://musicbrainz.org/track/c1b2cea4-b493-4768-acf5-6948a4fe522b.html http://musicbrainz.org/track/c1b2cea4-b493-4768-acf5-6948a4fe522b.html])
 +
** 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])
 +
 
 +
* 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)'''.  
 
* 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:  
 
On the other hand the current Guideline is not completely void of sense. the pro's for it are:  
Line 18: Line 27:
 
==Proposed Solutions==
 
==Proposed Solutions==
  
This section should help to get a cleareer picture of the proposed solutions and their inconvenients. IIRC there are two possible 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.
 +
 
 
* Store ''all'' performance roles with [[Advanced Relationships|AdvancedRelationships]] of the [[Performance Relationship Class|PerformanceRelationshipClass]].  
 
* Store ''all'' performance roles with [[Advanced Relationships|AdvancedRelationships]] of the [[Performance Relationship Class|PerformanceRelationshipClass]].  
* Create [[Artist Cooperation|ArtistCooperation]]<code><nowiki></nowiki></code>s for "A feat. B" and relate tracks to this artist by means of the [[Core Relationship|CoreRelationship]] (that is store it as the [[Primary Artist|PrimaryArtist]]).
+
** Pros:  This is a more "correct" approach.  
* ...(are there more proposals?)
+
** Cons:  This requires a massive change to the database schema, the server and APIs in currently-shipping tools.  
  
 
Now we would need to describe these proposals in detail and then sum up all arguments for and against them.  
 
Now we would need to describe these proposals in detail and then sum up all arguments for and against them.  
  
----Authors: Everybody :-)
+
----Authors: [[User:RodBegbie|RodBegbie]]
  
 
[[Category:To Be Reviewed]] [[Category:Discussion]]
 
[[Category:To Be Reviewed]] [[Category:Discussion]]

Revision as of 16:59, 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.
  • ...

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