History talk:Featuring Artist Style

From MusicBrainz Wiki
(Redirected from Talk:Featuring Artist Style)

Comment: Remove "(feat. ...)" from the title of songs:

  1. It conflicts with artists ("Little Feat").
  2. It conflicts with titles ("No Mean Feat" by External Menace).
  3. Is implemented inconsistently amongst song databases.
  4. Is not the song's title (from the original sheet music, or what Joe Average calls it).
  5. Makes searching for songs by title inaccurate (e.g., "exact matches").
  6. Is difficult to parse.
  7. Featured artists are extended attributes of a song.
  8. Makes accurate searching for specific featured artists difficult.
  9. Naming conflicts can be resolved using track numbers (if the same song appears twice on an album), or other uniquely identifying traits (such as extended attributes).
  10. It runs counter to an object-oriented way of thinking (one field, one responsibility).
  11. Hinders the normalisation of data (3rd or 4th normal form).

-- Thangalin 2008-10-06

Comment: You've dropped out the second part of the current FeaturingArtistStyle, "If no artist can be considered secondary...", which describes what to do in the event of an equal collaboration. I think it's needed here, because I don't see it described elsewhere. Maybe in ReleaseArtist? If so put a reference to that. CollaborationRelationshipType doesn't tell the story about creating a CollaborationArtist, that's for sure. —JimDeLaHunt 2008-02-06

  • IMO the previous guidelines was incorrect and shouldn't have been here in the first place. I would be happy to create a CollaborationArtistStyle but it would be little more than "If two or more artists are credited equally as primary artist on a release, without using a new group name, represent them as a new artist "Artist X & Artist Y" (or, for multiple artists: "Artist X, Artist, ... & Artist Z")". We need to move away from trying to work out who contributed what to a release, and instead look at how they're credited. —Gecks 2008-02-07
    • Indeed, that part of the guideline dates from before collaboration artists (with AR's) were possible. There is no reason in the world to keep it here. -- KrazyKiwi 2008-02-07
      • So what do we have now (written text) about duets TrackArtist ? Don't you think removing guidelines ("Artist A & Artist B" TrackArtist + two CollaborationRelationshipType) on this is too much ? -- jesus2099 08:04, 12 June 2008 (UTC)
        • What's to say about it, though? If it's credited as a collaboration ("Artist A & Artist B") and there's no guideline for what to do with it, then users will add it in as is, which is exactly what any guideline would say anyway :) In any case it would require a new page as it's nothing to do with Featuring artists. -- Gecks
          • Yes, it makes sense. Thank you murdos for the discussion page. -- jesus2099 16:03, 12 June 2008 (UTC)

Comment: I'd like to see some text at the beginning saying that this does not apply when ClassicalStyleGuide is in use. Note that CSG and ClassicalReleaseArtistStyle already takes a different position from ReleaseArtist and FeaturingArtistStyle on how to handle ReleaseArtist for collaborations. ClassicalReleaseTitleStyle is about to discourage FeaturingArtistStyle altogether, I expect. How about this text, after second paragraph of "Official Guideline". —JimDeLaHunt 2008-02-06

  • This guideline applies to most MusicalGenres, but it does not apply to entries covered by the ClassicalStyleGuide. Collaboration takes a different form in ClassicalMusic. See the ClassicalStyleGuide, and especially ClassicalReleaseArtistStyle and ClassicalReleaseTitleStyle, for guidance.
    • Well, I would disagree with dropping FeaturingArtistStyle from the CSG. I think it still has a place there, but I've said my piece on the list. —Gecks 2008-02-07
      • Do we really need to say "Except for CSG" here? It'll apply to every style guideline. It'd be more succinct to put on the CSG "...and ignore every other guideline MB has".-- KrazyKiwi 2008-02-07
        • I agree, but more because using (feat.) is already not part of the current (unofficial) CSG - the only place within CSG it does occur is the messy release title exception in CSG - and that too is just waiting on a database / interface change to go away. I'd think it'd be rather easiest to leave CSG out here, and just add in to the title section of newCSG "until the db can do better, this guideline overrides FeaturingArtistStyleAmendment" or some such. It's cleaner, and makes it so when such a db interface does happen, we only have one guideline, not two, in need of updating. -- BrianSchweitzer 17:50, 07 February 2008 (UTC)
        Yes, I think we really need to say "Except for CSG" here. One of the problems MB poses for contributors is that the style guidelines are often inconsistent and ambiguous. Without an "Except for CSG" disclaimer, then a contributor reading this guideline but not the CSG may not know the rules are different there. A contributor who reads both may not be sure which takes precedence. If both refer to the other and both say that CSG (actually, ClassicalReleaseTitleStyle) takes precedence where CSG applies, then MB is more consistent and less ambiguous. — JimDeLaHunt 2008-05-14
        • If such a note is considered to be needed, perhaps, rather than making it confusing by having editors read through (and possibly miss it) to find it in the text on each page, perhaps it would be better done as a what-cha-ma-call-it icon thingie "Does not apply to classical", or something like that, on each such page, so any guideline that we do think needs such a classical exemption can be easily identified before anyone (who already is likely confused trying to follow the rules of CSG) gets even more confused trying to integrate yet another guideline (and then de-integrate it when they do find that "except for CSG" buried in the text)? Would also help make the guidelines themselves less wordy, as they wouldn't have to work that wording into the page text... -- BrianSchweitzer 05:37, 09 October 2008 (UTC)

Comment: This text doesn't define the term "name-check". It would be helpful if it did. — JimDeLaHunt 2008-05-14