[mb-style] RFV: SupportingMusicianRelationshipType OK for Groups

Mike Morrison mikemorr at umich.edu
Mon May 5 12:17:20 UTC 2008


It's been over a week with no replies to this RFV (though I am now 
uncertain as to the correct amount of time to leave an RFV open; see 
http://lists.musicbrainz.org/pipermail/musicbrainz-style/2008-May/006843.html
) so I went ahead and made the changes to the wiki pages for points 2 and 
3:

http://wiki.musicbrainz.org/MusicalAssociationRelationshipClass?action=diff&rev2=14&rev1=13

http://wiki.musicbrainz.org/SupportingMusicianRelationshipType?action=diff&rev2=23&rev1=22

I was going to ask a TransclusionEditor to let those revisions into the 
doc pages but I see now that those pages are not among the pages on the 
Transclusion Table 
http://musicbrainz.org/edit/wikitransclusion/transclusion.html
, that is to say, they are not "wikidocselt", and the changes are now live 
on the doc pages. So now all that remains to be done is for a 
RelationshipEditor to implement point 1.

Thanks!

Mike

On Fri, 25 Apr 2008, Mike Morrison wrote:
>
> It having been one week with no additional comments on this Request For
> Comment, I am submitting it as a Request For Veto.
>
> My initial post on this topic:
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2008-April/006776.html
>
> My initial RFC on this topic:
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2008-April/006783.html
>
> Amendments to the initial RFC:
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2008-April/006785.html
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2008-April/006786.html
>
> The intent of this RFV is to say that all four of the following are
> theoretically acceptable uses of the SupportingMusicianRelationshipType,
> although the distinctions between membership, collaboration, and support
> might need to be decided on a case-by-case basis:
>
> Person supported Person
> Person supported Group
> Group supported Person
> Group supported Group
>
> To that end, this RFV proposes to do the following three things:
>
> 1. In the link phrases for the SupportingMusicianRelationshipType, when
> there is no instrumental or vocal attribute,
>
> change:
> "is/was a supporting musician" and "has/had supporting musician(s)"
>
> to:
> "is/was a supporting artist" and "has/had supporting artist(s)"
>
> (because "musician" seems to exclude groups)
>
> 2. On http://musicbrainz.org/doc/MusicalAssociationRelationshipClass
>
> remove the sentence:
> "Both should be persons, the latter mostly a well known solo artist."
>
> 3. On http://musicbrainz.org/doc/SupportingMusicianRelationshipType
>
> change:
> "This AdvancedRelationshipType is for linking Solo artists to the
> SupportingMusicians which have played on their albums, and in their live
> bands. This will effectively replace band membership data for solo
> musicians, because as illustrated by the below examples, band members are
> listed for several solo artists, and really a 'person' can have no
> members."
>
> to:
>
> "This AdvancedRelationshipType is for linking artists to the supporting
> artists which have played on their albums and/or in their live bands. This
> effectively replaces band membership data for solo musicians, because
> really a 'person' cannot have any members."
>
> (Changed "SupportingMusicians" to "supporting artists" because "musician"
> seems to exclude groups)
>
> (Changed "will effectively replace" to "effectively replaces", to make it
> seem less like this AR type is a thing of the future)
>
> (Removed the part about "the below examples" because the example artists
> seem to have been updated to change the "members" to supporting musicians)
>
> (Changed "can have no members" to "cannot have any members" to reduce
> potential for (admittedly unlikely) misreading)




More information about the Musicbrainz-style mailing list