Handling entries with conflicting information

Is there a commonly accepted approach to handling entries which mix conflicting information from different releases of an album? Like an album initially had a link pointing to one release and then catalog number from another release was added. Obviously, the inconsistency can be resolved by removing either newly added information or the original link.

I find removing original information destructive as this effectively changes the identity of a release. The entry is identified by GUID and once it is published you have no control over it. Any third party can use it and rely on it. I can’t think of a decent information system that silently switches identity of the entries it manages.

1 Like

The better is to move the newly inconsistent information to its own release (check the edit history).
I call it a hijacked release, restore its state as it was before being hijacked.
Hijacking a release, is most of the time, unintentional. But still must be fixed. :slight_smile:

3 Likes

No question this is a better option. However, I wanted to know the community stance on changing identities (or hijacking if this is more descriptive name). Is it considered unacceptable?

Hijacking is a pity so it has to be fixed.
Unacceotable is a strong term but yes this shouldn’t be done and it requires fixing.

When you restore original identity, it is no longer hijacking, it is required, it is fixing.

3 Likes

Why? MB is a public information system. Substituting one identity with another creates mess and destroys the purpose of permanent identifiers. Not from a purist view, there are obvoius negative consequences in practice.

Absolutely, I think that too. But here is why I said unacceptable is a strong term:

Unacceptable, if it’s purposely done, yes it is.
But we don’t need to make a judgement, it is unwanted and against the purpose of MB.

3 Likes

I fully agree with @jesus2099 on everything he’s said here, and in particular this. Several points of both the MetaBrainz‐wide Code of Conduct and the MusicBrainz specific Code of Conduct touch on this; e.g.,

  1. Remember that everyone was new at some point and a polite nudge in the right direction is sometimes all that it takes to set them on the right path.
  1. Share knowledge freely. New members should not be embarrassed for ignorance.

Not everyone will know/understand enough about MusicBrainz to check edit notes, cross‐reference sources, etc. to figure out the original intent of a given entity. When you come across a hijacked entity, please do fix it! But don’t pass judgement or be rude towards the editor that did the hijacking. In far most cases, they just didn’t know better at the time!

Also, for ancient (ie., pre‐dating NGS) releases, a Release was the same as a track list, so you might have several editions clustered together in a single Release, and if there weren’t enough information in the Release when NGS rolled out, they won’t have been split out automatically then. In those cases, it’s a remnant of our old system, and not the fault of any editor at all!

4 Likes

Well, I used unacceptable in relation to the informational component, i.e. what perfectly intelligent information system will not accept as input. Until we have such a system, the part of this function is on the editors, to accept or not. I didn’t mean socially unacceptable and the like. Let alone as a way to blame anyone. Sorry if I made such an impression. I am well aware that vast majority of invalid edits are not made deliberately.

2 Likes

My question originates from https://musicbrainz.org/edit/60416229, where my attempt for such a fix was blocked. Based on invalid argumenation AFAIKT.

1 Like

3 posts were split to a new topic: Determining release packaging based on Amazon cover art