I just started to merge these two persons, but then I realiized that these two are connected to another ( ‘legal name’ and ‘also performs as’).
But when I search on the GEMA database for the writer of the song “Call of the Wild” from Powerwolf, then it reports Benjamin Buss as writer of this songs.
First Question: Should I merge those two persons?
Second Question: Should I use Benjamin Buss as writer or Matthew Greywolf (if they will not be merged)?
I would merge the legal name into the performance name and add the legal name as an alias. Then it also matters less who the writer credits go to. If you can find the releases the works appeared first on, you can check the liner notes to find out which artist credit to use. Databases like GEMA are mainly meant for legal purposes (that is, where to send money to), and I wouldn’t use them as reliable sources.
It is very common for a musician to credit the Work to their Real Name, but the performance to their Stage name. It is often spotted in the booklet as ( Stage name ) played guitar, but ( Real name ) wrote the work. MB would then want to see the two different names in use.
Thank you for the hint with Lemmy. His artist page runs under “Lemmy Kilmister” but the writing credits just overwritten (creditet as) with “Ian Fraser Kilmister”. I think that’s a good idea also for the guys of Powerwolf. The question now is should I merge the stage name into the real name or the other way round?
My opinion is to use the real name and put their stage in the disambiguation, because all of them have more than one stage name (different band, different stage name). And after the merge I would change the credits to the stage names like in Lemmy’s case.
I own the CD “Blessed & Possessed”, but in the booklet there are no credits. But Wikipedia has credits, but I don’t know the original source.
Artist (stage) name is the preferred page ‘title’.
There are some exceptions. In fact, there are some exceptions as to when to merge and when to link via the ‘performs as’. But, for the most part, Always merge into the Artist name.
*note: some people prefer to merge into the older profile, and then rename it as needed. But I think the problem with the edit history being lost has been fixed and therefore no longer requires us to merge into the older profile.
I’m not sure about any edit history issue but I think that we should make merges in the direction that requires the least amount of work after the merge.
This consideration must include the fact that merges often require updates to be done outside of MB because of changed MBIDs which are used in external applications. For example, it may become necessary to retag some files with Picard when an artist MBID changes as a result of a merge, in order to get the update saved in files. @jesus2099’s collection highlighter userscript is another example.
Usually this means we should merge to the oldest entry, because it’s been around the longest and probably has the most stuff associated with it for that reason alone. But it’s not always the case. For example, if a performance name has a bunch of releases and the legal name has only work relationships, then I would merge into the performance name that already has releases and recordings regardless of whether or not it is older.
That is what the guidelines say - merge to the better quality item. It is a myth that “oldest is preferred”, but as you say usually oldest is the better one.
If I am merging artists I take note of which one has the most Releases and Recordings associated to it and aim at that one. Aiming to minimise changes. But anyone with an old MBID in an external application will still be redirected to the new MBID.
If Benjamin Buss and Matthew Greywolf are merged both of his old MBIDs will find the merged entity. Remember to add the other name to the Alias.
One of the things to watch out for is that disambiguration text is not merged, so that needs manually transferring across.
Use the name most likely to be searched. Which is usually the stage name. Add all the other variations of names to the Alias for the search to find. And yeah, disambig can be handy for those trying to spot one name from another.
Lemmy is a good example again. Check out the Alias page and you see alternate names for him listed. Especially “Legal Name”. And on the bottom half of the page you see all those “credited as” ways he has been named in the database
Not really. The redirection only exists in the MB database and in practice only applies to MB web service calls. It is irrelevant to many real-world use cases of MBIDs, such as the aforementioned collection highlighter.
In the real world, MBIDs get recorded in non-MB databases and then used as identifiers without making web service calls. The collection highlighter records MBIDs associated with your collections and Picard saves MBIDs into files. A music player might e.g., use the saved identifiers to implement features like grouping files based on artist MBID. After a merge everyone with files affected by a changed MBID will have to re-run Picard to see the redirection applied to bring things back in sync. For the collection highlighter you have to reload your collection (which takes a long time) to get things properly highlighted.
Editor should take care of not creating duplicates.
When they notice their mistake, it’s better to merge the newly created bogus duplicates into the pre-existing entities.
And there are the externally stored MBID reasons cited above (collection highlighter, automatisms based on tags, including Flickr, but not only, where the MBS redirect cannot run).
Even if it’s not widespread, the preference to oldest MBID makes slightly more sense than the opposite.
I also use KODI so understand how MBIDs get used, but that cuts both ways. When an artist has been incorrectly split - it is split. That would also be mirrored in the App and the app will also want to see them remerged.
If an App has an older pre-merge MBID and only using it internally, then the App is not affected until they go and update with MB. In those cases it is then better to update the whole artist allowing the App to fully update a local database.
When that app does make a lookup into the MB database using the old or new MBID they will still get the data they expect about the original artist. (Unlike Discogs for example)
If collection highlighter or any other app is broken this should not stop us correcting errors in MusicBrainz data.
I am not talking about freshly added data. I am talking about two older entities that have been spotted in the database like the OP has picked out.
I don’t know why I am quoting the guidelines to AEs again . How to Merge Releases - MusicBrainz “you should choose the release with the most correct information. If there is no real difference, the usual choice is the older entry.”
When I say “myth” I mean a lot of people get confused and assume the rule is ALWAYS pick the oldest to merge to when the guideline clearly says to pick the better quality release.
I have often seen older entities that are incorrect, have typos, or just plain wrong which has caused people to therefore use a newer more correct entity. It is not always the newest data that is wrong.
A good example is when using Mass Merge Recordings as sometimes the oldest release is not the one with the most used Recordings. For example, maybe a vinyl that didn’t have times, so the CD edition has been the most common in use. Preserving those more commonly used MBIDs would be more helpful to those external apps.
This is very common with a VA collection where one or two Recordings may have a few hundred tracks already associated to it.
In the OPs original question the oldest is the preferred merge target as it fits the main rule of best quality target to be chosen. So Matthew would be merged into Benjamin. In the majority of cases the oldest is the target, but this should not be blindly assumed.
For the sake of those external users of MBIDs one needs to check which entities are more in use and use that as the target.
. 