Advanced Relationship Type Proposal

From MusicBrainz Wiki
Revision as of 10:16, 4 June 2007 by Murdos (talk) (clean-up (Imported from MoinMoin))

Proposals of Additions or Changes to Advanced Relationship Types

Attention.png This page is superceded by ProposedAdvancedRelationshipType.

Initially this page was designed to collect all additions and changes that need to be done to the initial set of AdvancedRelationshipTypes. Unfortunately this page has become an unmaintainable TooLongList in which things get LostInLists. Additionally, the StyleCouncil really needs a tracker to be able to keep an overview of all OpenStyleIssues and assign them priorities. Lastly, this page has a BadWikiName. The correct one being ProposedAdvancedRelationshipType (to fit in with ProposedStyleGuideline).

Therefore this page is slowly going to die. The new page is ProposedAdvancedRelationshipType. Anyone who has submitted an issue here and is interested in it being implemented should create a (preferably well named) wiki page for this issue and give it the CategoryProposedAdvancedRelationshipType. --DonRedman

And here follows the TooLongList:

RelationshipEditors are able to change relationship types or add new ones. but for this to happen you will need consensus on first the UsersMailingList and then the StyleMailingList, and an AdvancedRelationshipType page that descripes the new relationship in all details.

Inconsistent Link directions

(by Dupuy) There's some general inconsistency in our link types about the directionality of 1-N relations:


  • 1-N X "is the legal name of" Y, Z, A, ...
  • 2-N X "is the parent of" Y, Z, A, ...


  • 1-N X "is the earliest release of" Y, Z, A, ...
  • but N-1 X (and Y?) "is a remaster of" A ("always point to earliest")


  • 1-N X "is the earliest release of" Y, Z, A, ...
  • 1-N X "is the earliest version of" Y, Z, A, ...
  • but N-1 X (and Y?) "is a remaster of" A ("always point to earliest")
  • N-1 X (and Y?) "is a cover of" A ("always point to earliest")

Whatever we decide to do with the is-person relationship, we need to make these consistent...

Allow Instrument Attribute for Members of a Band

Should MemberOfBandRelationshipType not have an instrument attribute? --DonRedman

This would introduce some additional complexity in interpreting artist roles: see ArtistRoleInheritance --MatthewExon

Another thought: the instrument attribute doesn't have "vocals", so this wouldn't work for recording singers. Maybe the InstrumentRelationshipAttribute hierarchy should include the VocalRelationshipAttribute hierarchy, and "Performed instrument on" be merged with "Performed vocal on"? There are other roles for members of a band as well: The Prodigy has two dancers as "official" members. IMO these could probably be adequately covered by "other" --MatthewExon

Also Known As

The current Alias property should be repurposed now that AR is ready. Artist who have recorded under multiple names should have a relationship instead. The existing Alias property would still be usefully for misspelled names but there are some artists like Aphex Twin and Wynonna Judd who have recorded under different names and the release should be reflected correctly for those artists. The current "is the legal name/is the performing name" is insufficient since in some cases an artist might perform under two names and neither is their legal name (i.e. Wynonna and Wynonna Judd) --WolfSong

Rename Legal Name to Birth Name

I propose renaming this simply because more often than not, finding someone's birth name is more plausible than their legal name since names can be changed and although in the US such information becomes public record, this may not be the case everywhere. This was actually changed from official name to legal name due to discussions over Wendy/Walter Carlos. In this scenario Wendy is probably the legal name and Walter is the birth name. Both names should be listed seperately since this person has released recordings under each name. --WolfSong