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.