History:Linking Different Artist Names Proposal
Proposal for Legal / Performance Name handling
This is set of ProposedAdvancedRelationshipType
s for dealing with ArtistName
s using AdvancedRelationships. It comes from the LinkingDifferentArtistNamesDiscussion that originated on MusicalAssociationRelationshipClass.
Current Relationship Types
Problems with the current Relationship Types
It's not possible to represent multiple legal names in the system (for example maiden names, Walter/Wendy Carlos), except by the rather inaccurate method of calling later legal names "performance names" of the birth name.
You also can't easily find out what is the legal name of, say, Madonna, at the time of release of a particular album.
To answer the question "who is person X, really?", we will concentrate on the LegalName. A "legal name" is the name that the artist uses in official documents such as passports. An artist can change their legal name, but we'll assume that they only ever have one at a time (note: this might not be true for, for example, ex-pat Chinese artists).
In line with the DontMakeRelationshipClusters policy, each legal name will be related to the very first legal name, using a new "Is the birth name of" relationship.
Another option would be to use a "changed their name to" relationship instead of "is the birth name of". This might seem more natural. The disadvantage is that it's more complicated and time-consuming to accumulate a list of all the legal names (you can't do a simple SQL join).
It would be possible to add more specific relationship types, such as "Is the maiden name of". However, that would confuse the issue. For example, say a person is born "Susan Dingbat". During her twenties, Susan changes her name to "Susan Smith". Then she marries Carl Jones to become "Susan Jones". In that case, "Susan Smith" is the maiden name of "Susan Jones". In order to find out the birth name of "Susan Jones", you have to find all the birth names of all the maiden names of "Susan Jones"; two levels of indirection. To simplify this, if "is the maiden name of" ever gets added, I think this should be in addition to the "is the birth name of": that is, both relationships should be recorded for "Susan Smith".
Performance names would then represent a whole different sequence running in parallel to the legal name sequence. Each performance name would link, via a "is a performance name of" relationship, to the corresponding legal name.
We would not link performance names to the birth names, but to the legal name in force at the time. The reason for this is that the sentence "Susie Smith is a performance name of Susan Dingbat" is simply wrong, if her name at the time was actually "Susan Smith". It would still be possible to display the correct sentence, by retrieving the list of all legal names from the birth name, and then finding the legal name that corresponds to the time period of the performance name. But this is clearly a complicated and bug-prone procedure, and unlikely to ever be implemented. Linking performance names to legal names is much cleaner.
The big problem with this is what happens when a performance name overlaps with several legal names. There are two options here: either allow more than one "is a performance name of" relationship; or create multiple performance name artists, one for each period. Both of these are shown in the diagrams below, assuming that Susan Smith releases material under the stage names "Susie Smith" and later just "Susie":
Where to place albums
With the above system in place, you would be free to record albums under whichever artist the album gives credit to. So Susan Smith might release albums under all four of the names given above: "Susan Dingbat", "Susan Smith", "Susie Smith" and "Susie". That is, albums can be associated to both legal names and performance names. In the simplest case, where an artist releases albums under their legal name, then there is no need to much around with any of this stuff.
In the above example, "Susie Smith" is given as an alias for "Susan Smith". "Susie" is a pretty common nickname for "Susan", so there's really no need to get picky about things. The legal names could just as easily all use "Susie" instead of "Susan", and this should be the recommended way of entering artist names. Only where the legal name is completely different from the performance name (such as Elton John or Bono) should there be separate entries.
Splitting the artist names would also be justified where the artist releases material under both names. For example, Björk usually releases material just as "Björk" (in accordance with usual practice for Icelandic names), so in this case it would be usual to use that as her legal name. However, she has released at least one album where she's credited as "Björk Guðmundsdóttir". In this case then, her legal name should be set as "Björk Guðmundsdóttir" and "Björk" be given as a performance name.
Wow, first, thank you for this proposal. It looks to me like a good description of the problem, the discussion around it and one possible solution.
The relationships you propose are relatively intuitive. Names are either legal or performance. However, it seems to me that this is one more case in which AdvancedRelationships turn MusicBrainz from a searchable database into a klick-through set of webpages. The proposal is good but in your scenario one might have to follow quite a few AR links until one finds a certain album. IMO MusicBrainz should work like Google: Enter a name and here are the results, and not like a wiki: Klick yourself through seven links before you find what you were looking for.
What about this (Just an idea): Could perhaps a wise use of ArtistAlias
es remedy this problem? What about adding the origninal birth name as an alias to all artists. One could even add all other names as aliases to all artists. That way when searching for any name Susan Dingbat ever had or used would list all names she ever had or used. Does this make sense? --DonRedman
- The discussion arround removing Björk's birth date because it is redundant being also stored in the entity "Björk Guðmundsdóttir" brought up some thoughts on how to manage that. The idea basically was: use one artist as the main entity (birth name in this case) and store all the data (albums, URL-ARs, birth dates aso.) in it. Then have other entities representing variants (other legal names, performance names) which are linked to the main entity. Now when someone tries to access the artist page for Susie Smith, data is loaded from the entity Susan Dingbat and represented as if it was stored under Susie Smith. And if someone tries to add data to Susie Smith he is automatically redirected to Susan Dingbat. The problem is: how do you say which data is important for which entity? Not all albums were released under the name Susie Smith. Is AR capable of doing links such that albums can be visible only to certain entities? So here we have problems. The idea can be relativated by saying: store the albums under the names that they were released under (just as we are doing it now). But still show info from the main entity as if it was stored under this entity. Why is this necessary? One example are the birth dates. You don't want to have them stored under multiple entities because they are redundant then and this can lead to inconsistency. But the birth date is import for every linked entity. So store it in the main entity and when building the artist page of a linked entity, load it from there. Another example are Wikipedia pages. Mostly you have those named under the most known LegalName of an artist. So you would add it to this entity. But the contents of the page are also important for the PerformanceName
s. Then you have cases where the PerformanceName is so popular that the Wikipedia page is named after it. If no additional page for the legal name is present (most cases) then link it to the main entity I'd say. Otherwise link it to the said PerformanceName as it might not be important for other PerformanceName
s. This gets clearer when looking at Discogs entries. They have pages for every PerformanceName so we should link them to the appropriate PerformanceName
s as they are not important for other name entities. Conclusion: if you view a PerformanceName page you only see the data important for this entity (part of it accessed through inheritance from the main entity). And one final remark: we have a nearly complete identical situation for bands thus no ARs are discussed yet for them. :) Bands can change their name (band name changes should only be considered as those if the lineup stays mostly the same and/or the label contract stays intact - otherwise we have a new band which is linked to the older through the participating members; example: the Global Playboys had to change their name to Global Deejays for legal reasons) and they can perform under aliases (and I mean not just variants of the name but really different names; example: Die Tosen Hosen released some records under the name Die Roten Rosen). --Shepard Btw: wrote this down in DisplayInheritance. --Shepard