It is the latter. As you may note from the URLs to the three different relationships, they each have a unique UUID. One UUID = one relationship type. One “relationship” I’d define as the actual relationship between two entities. E.g., Recording “World Bboy Classic 2016” by DJ Nobunaga & DJ Uragun - MusicBrainz has 3 Relationships.
The help text should maybe read
The Mastering relationship between recordings and artists is deprecated.
so that it’s clearer that other relationships (with the same name, no less) are not.
“This relationship type is deprecated and should not be used” is the hardcoded error message for all deprecated relationship types, and I can’t change it specifically for this one 
The description for the relationship type is more clear, but of course it depends on the user actually opening the help:
This relationship type is deprecated! Please add mastering engineers at the release level.
1 Like
This particular case (mastering) is a bad fit to begin with - I agree it’s not ideal to have them on recordings, but we’d need track-artist/place (plus possibly medium-artist/place) relationships.
I’ve come across several releases where not all mediums have the same mastering credit (most typically bonus discs), and I’ve come across a couple with specific mastering credits for different tracks on one medium. Yes, I can (and do) use annotations for those cases, but those are not really machine-readable via the web service, for example.
1 Like
For this bonus track section vs main album section, having tracksets would be helpful (sorry if you already know about it as I link to it quite abusively often). 
1 Like
Sure, they’d be nice for a lot of reasons (and I voted for the ticket), but in some cases it’s not bonus releases, just that a release was made up of tracks that were mastered (possibly in groups, but not necessarily clustered together on the final release) at separate times, without a final medium-wide mastering pass.
So it would still need track relationships too.
1 Like
The hardcoded message could be changed to read
"This relationship type is deprecated here and should not be used. See the help text for details."
2 Likes
I don’t agree with the “here” (because a relationship type is either always deprecated or never deprecated, and the “here” just helps ingrain the confusion that different relationship types are actually one and the same). But having something like “see the documentation for details” would be useful, since it should be safe to assume that the docs will always say something about why the reltype is deprecated and what to do instead.
3 Likes
Well, the source of the confusion seems to be that we’re using a technical definition of the noun relationship that clashes with what the rest of the world uses. Editors, coming largely from the “rest of the world” set of people, are bound to be confused.
…
After mulling it over for a while, I think the “type” is the main stumbling block.
If Fernando and Paul come to a catholic priest to get married, would the priest say:
(a) “This relationship type is inappropriate.” or
(b) “This relationship is inappropriate.”
In my opinion, (b) is clearer. Of course “This relationship type is inappropriate between [male] and [male]” would be most specific, but (back in MB) we would have to massage the code for that.
1 Like
I agree here…
I’ve been adding data for a lot of albums in my collection recently, and on numerous ocassions have come across individual tracks with differing Mastering Credits.
It should really be posible to add this credit to each track, and not just a release as a whole.
2 Likes
I think a lot of people agree with this. The problem is that currently we can’t add relationships to tracks at all - only to releases or to recordings (shared by many releases sometimes). So between those two, we opted for release because keeping different mastering together makes life much better for almost everything else than this relationship 
If we become able of having track relationships, I’d expect mastering to move there.
4 Likes
