Talk:Q27949697

This item is a scourge

I have brought this up a few times are project chat and in a deletion request, but nobody else ever seems to understand the modelling problems this item is creating (perhaps because they are too long distance to see).

Real world entities/concepts are constantly being made subclasses of this item. It makes no sense and is equivalent to conflating concepts because this item is a Wikimedia internal entity.

For example, account suspension (Q87406427) is an item I created as part of a clean up for how we model suspended Twitter accounts. Multiple times it is set as a subclass of this item, which means while correctly being a punishment (Q186361) it is also (by transitivity, at time of writing):

• Wikimedia page (Q58494026)
• HTML document (Q60461402)
• intellectual work (Q15621286)

A very similar item to this ("Wikimedia reason for end cause") was previously deleted under the logic that it was creating confusion of this exact nature. I don't see how this item isn't the exact same. --SilentSpike (talk) 12:55, 12 April 2022 (UTC)

It might help to come up with a name which is easier to translate. Currently the Italian translation makes it sound like a property, and I'm not quite sure what the English label is supposed to mean. Nemo 00:05, 15 November 2022 (UTC)

Any item label including "Wiki" something with an uppercase "W" (especially when it's the first word of the label) stands out to me as being "special", something that should not be mixed with regular world items. If "motivo della deprecazione su Wikidata" sounds like a property, why would this lead to people attaching random items as instances (or subclasses) of that "property"? --SM5POR (talk) 06:08, 3 December 2022 (UTC)

@SilentSpike: I agree on conflation being a significant problem, myself wondering what the COVID-19 pandemic (Q81068910) is doing in this context, but the class is needed to enumerate clearly defined reasons for deprecation, which help explain why a particular statement is in error and should therefore not be reinstated (simply deleting the bad statement just asks for the same mistake to be repeated indefinitely). I don't know what "Wikimedia reason for end cause" was used for, but if you don't know why people keep making a particular mistake, deleting the possibly innocent target of that mistake won't necessarily reduce the number of mistakes: they will just move to a different target next time.

Maybe some conflicts-with constraint or similar could be added to instance of (P31) and subclass of (P279) in order to discourage mistakes that are due to a poor understanding of what this item is meant for? --SM5POR (talk) 06:50, 3 December 2022 (UTC)

Looking into the current class tree, I find that Wikibase reason for deprecated rank (Q27949697) has only three sub-classes; suggestion constraint (Q62026391), misinformation (Q13579947) and disfavored (Q112943271). Of these, only the latter two can be regarded as true (even if broad) reasons for deprecation, and they shouldn't be listed as sub-classes but rather instances of Wikibase reason for deprecated rank (Q27949697) (which they actually are, meaning that their subclass of (P279) statements are mistaken and should be removed, or perhaps "deprecated" for illustration).

The first class, suggestion constraint (Q62026391), isn't actually a reason why the deprecated statement should be considered wrong, but rather an excuse for adding the statement in a deprecated state from the beginning. Rather than creating an intermediary class "Wikibase reason a deprecated statement is considered wrong" for all the other reasons however, I'll accept lumping them all together in the same class, as direct or indirect instances ("reason" itself isn't a reason, it's just the class of all reasons)

That should simplify part of the constraint definition; simply make Wikibase reason for deprecated rank (Q27949697) a "none of" value item for subclass of (P279) (and should we ever need a sub-class at some time in the future, make sure to label it "Wikibase" something and make it an explicit exception to the constraint).

What remains after that is to prevent random items from being declared instance of (P31) Wikibase reason... SM5POR (talk) 11:15, 3 December 2022 (UTC)

I was mistaken about suggestion constraint (Q62026391) and confused it with constraint provides suggestions for manual input (Q99460987); it's actually an indicator of the severity of a constraint violation and thus has nothing to do with the reasons for deprecation. It should be moved elsewhere. --SM5POR (talk) 12:48, 3 December 2022 (UTC)

End causes are something that exists in the real world outside of Wikidata. Reasons for deprecating something inside of Wikidata on the other hand is something Wikidata internal. That's what makes it have a different nature. Deprecation is a Wikidata internal act. End causes of relationships outside of Wikidata are not Wikidata internal. ChristianKl ❪✉❫ 12:14, 3 December 2022 (UTC)

Exactly. Should I bring this up elsewhere for discussion, or can I go straight ahead and make the changes I'm proposing above? Since reason for deprecated rank (P2241) and subclass of (P279) are used all over Wikidata, I understand this may be a slightly sensitive operation, and it should not be done in a hurry but rather very carefully prepared before and verified afterwards. --SM5POR (talk) 13:00, 3 December 2022 (UTC)