You added a conflicts statement between MusicBrainz work ID (P435) and MusicBrainz release group ID (P436) in https://www.wikidata.org/w/index.php?title=Property:P435&diff=772715575&oldid=755172086&diffmode=source. Was that intentional? According to https://www.wikidata.org/w/index.php?title=Property_talk:P435&diff=215225728&oldid=212698347&diffmode=source, both of those properties were not meant to conflict.
Topic on User talk:Jc86035
My decision was intentional, yes. The 2015 omission was also a presumably unilateral decision, by Nikki, and this was several years before Moebeus (and I) began separating singles into items which would be one-to-one matches with MusicBrainz entities. All Wikidata users, including unregistered users, can add or remove property constraints.
While Wikidata may not in practice distinguish songs from singles (except when noting covers of a song), it is probably beneficial nevertheless to have different Wikidata items for the distinct entities. (See also the deletion discussion for B-side (DEPRECATED) (P1432).) Unfortunately, the data is terribly inconsistent at the moment, because there are more than 80,000 items for singles, and so far all of the several hundred separations have been done manually. In the meantime, data reusers will have to deal with it or use other databases.
@Mineo There is another issue with your bot: It updates WD not only based on WD links on MusicBrainz, but also based on wikipedia-links. This breaks a lot of stuff, and I think your updates should be limited to WD-item<>MB item. The reason for this is that Wikipedia articles will often cover several subjects (song, cover versions, releases) and MusicBrainz editors will link wikipedia articles to display relevant text on their items, which is fine. The problem comes when these links are imported back into Wikidata, like what happened here: Q7428899 - in this example two versions of the same song are correctly tagged with WD items, but the wikipedia article (which covers both versions) causes problems. Could you have a look at your script?
This is a known issue. I believe the answer is that because Wikidata has functional constraints and querying infrastructure and MusicBrainz does not, the error-fixing should occur on our end and the same fixes should then occur on MusicBrainz.
Just to clarify this for me: is MusicBrainz work ID (P435) on items with instance of (P31) single (Q134556) now officially wrong? Since it seems the constraint process doesn't require any approvals or reviews, I'm not sure how to interpret the current situation. If that's the case, I'll just prevent the bot from adding any MusicBrainz work ID (P435) statements in the future.
Would it be possible to check if an MB Release/MB Release group ID is already present on the item before adding a MB Work ID? Personally I think the biggest problem is items with more than one/conflicting MB IDs, but that's just my opinion.
If you go to a random category like w:en:Category:1988 singles and check the Wikidata items, you'll find that basically all the data was imported from the English Wikipedia infoboxes in 2012 and 2013. I don't think a lot of those are linked to MusicBrainz at all.
I think adding them will still be beneficial, since (depending on your point of view) the item represents the recording and composition as well as the single, since all of the English Wikipedia articles are supposed to have the song as the primary topic unless the single has more than one track (I think?). (The data is already polluted, in any case, so MineoBot won't be breaking anything that wasn't already broken.) I don't think there's anything official, and there are few active contributors in this area, but for now I think adding it should be okay until someone comes around to clean up all of the items.
According to https://www.wikidata.org/wiki/Property_talk:P435, the domain of MusicBrainz work ID (P435) are indeed single (Q134556)s. It would be super awesome if you could create a consistent view for this property, @Jc86035, because at the moment, the property page and its documentation are clearly in conflict.
The template parameter was added by Laddo in 2014, which was shortly after the Dexbot import in 2013. At the time this would have been accurate, and at the time property documentation was always stored in the template on the property talk pages instead of being indicated in the Property namespace. I didn't even notice that text until you mentioned it.
I've removed the template parameters on the talk page, since they are redundant to and/or contradict the information stated in the property entity itself. Everything here was done unilaterally (I think), and a revert and a discussion should be enough to establish consensus.
And the example for MusicBrainz work ID (P435) is Bohemian Rhapsody (Q187745). There's really more cleanup needed here.
As always. I think Wikidata right now is a bit like an emptier 2006 Wikipedia (no references, everything is a bit messy). I wasn't there in 2006, but Wikidata's about the same age as Wikipedia was in 2006.
I think this comment I made yesterday might be relevant. Essentially, there are 80,000 to 500,000 items to fix (across music and books), and I don't really know how that would be done because I haven't learned how to run a Wikidata bot and don't know if it would be possible for me to do it.