History:Getting Rid Of Featuring Artist Style: Difference between revisions
From MusicBrainz Wiki
Jump to navigationJump to search
(added a little bit more structure (Imported from MoinMoin)) |
(additional 'pro' for sg5 (Imported from MoinMoin)) |
||
(2 intermediate revisions by the same user not shown) | |||
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: |
||
* Storing artist information as a section of the Title field is incorrect. |
|||
* 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. |
|||
** 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: |
||
* The |
* 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. |
|||
* ... |
* ... |
||
==Proposed Solutions== |
==Proposed Solutions== |
||
This section should help to get a |
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]]. |
||
** Pros: This is a more "correct" approach. |
|||
* 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]]). |
|||
** Cons: This requires a massive change to the database schema, the server and APIs in currently-shipping tools. |
|||
* ...(are there more proposals?) |
|||
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: |
----Authors: [[User:RodBegbie|RodBegbie]] |
||
[[Category:To Be Reviewed]] [[Category:Discussion]] |
[[Category:To Be Reviewed]] [[Category:Discussion]] |
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.
- 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)
- 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)
- 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.
- Store all performance roles with AdvancedRelationships of the PerformanceRelationshipClass.
- Pros: This is a more "correct" approach.
- 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.
Authors: RodBegbie