Disambiguations on artists and labels when no similar artist/label exists in the database

MusicBrainz Style
, ,
1

A continued discussion from this edit:

TL;DR: Disambiguation comments are useful even when there are not 2 identically named entities due to UI short-comings. Current Style guidelines encourage removing disambiguation comments in these instances which is detrimental to clarity.

Current Style Guidelines

Disambiguation Comment - MusicBrainz notes that disambiguation comments are to be used to distinguish identically or similarly named artists, labels, and other entities. There is a whole section about when NOT to disambiguate that mostly relates to recordings, releases, release groups, and works but does explicitly state “Disambiguation comment fields should not be used to store general background information: that should go in the annotation.” and this is not specific to the previous listed entities but to all entities on MBz. This leaves a bit of a grey area for artists/labels that do not have identical/similarly named entities within MBz.

At least from my interpretation of this, it seems as a way to keep disambiguation comments shorter/absent and less intrusive in the UI for cleanliness (which I understand the reasoning for). What this does though, is suggests that if a disambiguation is not needed to tell two entities apart, it should be removed (or moved to annotation).

UI Issues

Currently, the UI on the site doesn’t do the best job of disambiguating artists and labels without said disambiguation comments on some pages. The search does a great job where the label search (which I think this is the first time I have ever searched for a label directly in the search bar) includes the Name, Type, Code, Area, Begin Date, and End Date and the artist search includes the Name, Sort name, Type, Gender, Area, Begin Date, Begin area, End Date, and End area. This leaves little question (assuming the data is present) as to what artist/label is which. Meanwhile those same searches from the dropdown menus in the ”Add release” page show nothing but the disambiguation comments for labels and the disambiguation comments, type, and start/end dates for artists. This leaves out geographic information and none of the site UI incorporates user tags.

Why This is a Problem

While disambiguation comments are required when entities have the same name, they’re not required for every entry. This means that if someone enters THISISTOTALLYABANDNAME and adds a few albums but no disambiguation comment (or adds one and it is removed since the information is already present in the area fields and tags), someone else across the world may want to add their local (but different) band called THISISTOTALLYABANDNAME’s albums and just selects the existing one assuming someone else already added it. Happens frequently when there isn’t much data in the artist profile. Happens a little less when area info is added as well as start/end dates but still happens. Even when all data is entered and awesome disambiguation comments exist, it still happens (looking at you Self-Released - MusicBrainz ) so it’s not foolproof but generally the more details present, the less the chance it happens. With the plethora of artists and labels out in the world, this is only getting worse as more and more names are used up and thus can only be reused by people unfamiliar with existing entities of that same name.

Modern Interactions with MusicBrainz Makes This Worse

Modern scripting tools like Harmony and the browser import scripts for other databases like Discogs, Bandcamp, Metal Archives, etc. are life savers for adding data but also create a new way users interact with the website. It is entirely possible to find an album scanned with MBz Picard didn’t return results so you go add the album from another source and never actually interact with the good UI on the search results page, you just se the “Add release” page. Not having a disambiguation for artists and labels means that users are more likely to select an entry that already exists rather than double checking if that entity is the correct entity or if a new one needs to be created.

Ideas for Solutions

Disambiguation Comments

The disambiguation comment field solves this issue 99% of the time (not reading is the remaining 1%, nothing will solve that)…

More Fields in UI on Dropdowns

…BUT if disambiguation comments are thought to be too cumbersome and intrusive, then the UI including more details in the dropdowns on the relationship search is another option.

  • Geographic fields

Geographic information would go a long way to helping disambiguate both artist and labels without needing a disambiguation comment and is my preferred choice for a field added. The Place dropdown when searching for Place relationships includes geographic information which is immensely useful (I guess it makes sense since Places are innately geographic).

  • User tags

If the concern then becomes whether to use Area vs Start/End areas for artists, then perhaps encouraging duplication of geographic data in disambiguation comment could help. Beyond geographic information, user added tags are also a useful way to disambiguate, especially genres. Having these appear as they can fit (but not increasing space) could be another solution. Maybe if there is no disambiguation present for an artist/label, the user tags are shown in the same spot for as many can fit.

Concluding Thoughts

While this isn’t some world ending problem as each mistake is easily fixed, it is a time saver. Having this information faster rather than selecting an existing entity with no disambiguation and then clicking the hyperlink that pops up to visit the entity’s page to verify or relying on a search from another browser tab/window. I currently try to add disambiguation comments to every artist/label I add for this very reason and it can be frustrating seeing them removed and then having to double check again in the future if this is indeed the right artist/label or do I need to add a new one.

7 Likes
2

Personally, I believe this is the best route we could take, bar none.

We should be leveraging the information already available to us, not doubling down by entering that same information twice in two different places.

4 Likes
3

This has already been discussed a bunch and my opinion hasn’t changed for a while:

Something like this would be a big improvement:

But until that day I think we should allow disambiguations on artists with unique names. If the guidelines need to be updated to reflect that, then let’s do it.

9 Likes
4

The auto-disambiguation is more or less what the UI is trying to do with the info provided in search windows, maybe if no disambiguation field is present, it automatically shows more info like the fields suggested in my solutions post or the feature aerozol linked to. And agreed that this is preferable over disambiguation comments but I recognize development isn’t instant and takes effort so until that point, more disambiguations for everyone!

1 Like
5

I think while we wait for development to implement a smoother disambiguation process, cleaning up the section of the Style guideline I highlight above would go a long way to providing clarity on how to treat disambiguations. I am afraid I am not much help when it comes to wording as I tend to be overly verbose and not the best at creating succinct clarity.

2 Likes
6

I agree that the “general background information” bit can confuse people by being under “When not to disambiguate” - it’s mostly meant as “How not to disambiguate”, and I think it’s best to move it to the top section. I would suggest some changes and additions to that section (in cursive below, improvements welcome):

Disambiguation comments are used to distinguish identically or similarly named artists, labels and other entities. They are visible on entity pages, as well as in search results.

They should be in English and kept short. A few words are usually enough to disambiguate the entity. Follow the same capitalization guidelines as for extra title information, as these comments are not part of the name. Disambiguation comment fields should not be used to store general background information: that should go in the annotation.

You will be prompted to enter a disambiguation comment when you create an artist, label or place that shares its name with an existing one. You will not be forced to enter disambiguation comments for the existing entities, but it is best to add them as well, or there may still be confusion for other editors.

For artists and labels specifically, it can often be useful to add disambiguation comments on creation even if no other entry with the same name exists yet. This helps avoid them being wrongly selected in the future by editors that do not know they should be creating a new entity instead.

10 Likes
7

Agree with @aerozol that adding disambig for obscure little bands is really useful. Some automatic script showing tags would not be enough. A human can better create a couple of words to let you know what you are dealing with.

Editing a heap of old obscure UK punk at the weekend I was tripping over this exact issue. Life was made so much easier when I looked at a list of dozens of bands of the same name and could see (UK punk) or (Danish boy band) or (US rock). It is simple, neat and easy.

A few times I hit the example of an artist with no disambig and when looking closer it was three combined unrelated artists that needed splitting. This is a good example of where adding a new artist with even something simple like (UK punk) helps reduce errors.

7 Likes
8

Having the comment is a real time saver. In my opinion, it should be always added to any artist and label.

The disambiguation comment is the only thing you can see when creating the relationships in the editor. If there is none, you need to select it and go to the entity to figure out if it is the one you want.

For example, adding the Weedian series or other various artists compilations that feature lots of smaller bands, you’ll spend an hour or more adding those, checking if the (badly) commented entities are the correct ones for this release…

I usually add the country, type and genre in the comment. Years or era if defunct, possibly area if it is otherwise too similar with another entity.

This makes it quite easy to distinguish when choosing, e.g:

  • Finnish black metal band
  • Italian cassette label, 90’s
8 Likes
9

I really like that addition, it conveys exactly the point I was trying to make. It also reads well to me, but as I said, I’m no expert in being concise.

1 Like
10

Maybe it’s because I’m coming into MB with a Wikipedia mindset, where they know what the word ‘disambiguate’ means, but reading some redundant clutter when there’s no other entity with an identical or similar enough name doesn’t provide me any clarity and it doesn’t save me any clicks when there’s literally no other option to click on. It just makes me roll my eyes and think “No shit, Sherlock”.

The shortcomings of MB’s (or, worse, a third party’s) UI are not a good reason to add disambiguation comments. There’s parts of the website where the only info shown about a recording is the title and artist. That’s not a good reason to put the length, ISRC and release titles in the recording disambiguation comment. There’s parts of the website where the only info shown about a release is the title and artist. That’s not a good reason to put the format, label and catalogue number in the release disambiguation comment. There’s parts of the website where the only info shown about a work is the title, authors, publishers and variant works. That’s not a good reason to put the type, language, original performer and those various organisation IDs in the disambiguation comment. There’s probably more examples with other entities, but these are the obvious ones off the top of my head.

“[artist A] and [artist B who doesn’t exist in MB yet]” assumes that 1) artist B actually exists or will exist, rather than being speculated to exist and 2) the disambiguation comment doesn’t equally apply to this hypothetical artist. This reasoning can just as easily be applied to other entities. An artist might re-record a song, so all their recordings should have a disambiguation comment. An artist might release multiple self-titled, untitled or greatest hits albums, so all their release groups should have a disambiguation comment. An artist might record 2 different songs with the same title, so all their works should have a disambiguation comment. It’s “disambiguating” against a hypothetical something whose only confirmed existence is in a given editor’s head.

1 Like
11

So when you add a compilation with 50 unique-name-in-MB artists you blindly select the match?

Because for anyone doing due diligence that situation means 50x opening artists in new tabs to check that the genre and country etc matches, in case we have to make a new artist.

9 Likes
12

I’m guessing it’s not worth changing the terminology at this point, but I do think something closer to Wikidata’s description field would be nice. E.g., Nightingale - Wikidata has an English description of “Swedish progressive metal band” which is the kind of thing that’s useful in an MBz disambiguation given the other bands named Nightingale.

1 Like
13

I think showing more details would be a good end solution, but even with that, I see no issue having disambiguations on unique entities either. it might be belt and suspenders, but when editing, it’s good to have, I think

edit: I don’t think I have an issue with renaming the field to something like “Description” or “Short description”, following Wikidata’s example…

3 Likes
14

It seems to me the “disambiguation” field does what it needs to. It helps you tell two artists apart by focusing on a difference. It should not be a “description”, but something short to let us tell it apart from something else.

I was updating a release at the weekend which had two bands with the same name on the same release. No auto script would have let me tell them apart as they were both Devon punk bands. Seeing (UK punk band from Torquay) and (UK punk band from Okehampton) made it much easier to pick them out when setting the artists on the release.

I was entering a number of releases from the same label. For me it was really handy to have the disambigs. Especially because I could see traces of a previous editor who also had been working on the same obscure punk bands as they had added (UK punk) disambigs to so many of the same artists saving me a huge amount of time in making the initial selections.

I followed many of the same releases over to Discogs and found a tangled mess on some where US bands were being selected in mistake. I click and cross check and cross link as much as I can with that other place to aid identification. It is one of the fun parts of adding to the database as you end up doing a lot of research and find new things.

4 Likes
15

No, I click the link so I can check the artist’s page for any releases or recordings they were involved with, even if there’s a disambiguation like “US rapper” or “German jazz singer”. If that’s not helpful enough, I’ll do a quick check of Wikipedia and/or Discogs. If I’m still unsure if it’s the right artist by that point, I’ll tentatively create a new one and leave it to someone more knowledgeable than me to merge them if they’re actually the same. Because if I’m adding a compilation of 50 different artists, chances are the only thing I know about them is “performed track X on the release I’m adding”. In that case, disambiguation helps me cut down the list when there’s multiple candidates (I can safely ignore artists with “mastering engineer” or “photographer” after their name). But it doesn’t give me enough info that I wouldn’t need to check an artist I’m not familiar with.