Talk:Community Wishlist/Wishes/Wikidata: Enable the "class" and "relation" parameters on more constraint types

Thank you!

Hey @Swpb - thanks so much for submitting and then editing your wish!

It sounds like you'd like to expand the usage of constraints, which might solve for an anti-pattern workaround. If this wish were solved as you've proposed, what sort of impact do you think it'd have on the quality or breadth of Wikidata? JWheeler-WMF (talk) 19:46, 15 July 2024 (UTC)

The impact on quality would be enormous. A lot of work on Wikidata goes into deciding the correct way to model things, but without proper constraints, editors who add statements that violate these modeling decisions don't even know that they've done so. And cleaning up erroneous modeling can't generally be automated, because there is often ambiguity about the intended meaning of erroneous statements that has to be evaluated on the basis of other statements or Wikipedia article text in a way that doesn't scale.

To generalize part of what Peter mentioned below, one major area where this expansion will help is with errors in basic membership statements, which, because of the transitivity of subclass of (P279), lead to false inferences, nonsensical subclass chains, and overlaps in classes that are supposed to be disjoint. You can see that instance of (P31) has about 75 "none-of" constraints, most of which exist to head off these errors, but which are generally incomplete with respect to the values they disallow. One editor has been diligently collecting cases of nonsensical inferences for cleanup, and there is no shortage: I just finished cleaning up statements that led to about 40,000 works of art being misidentified as instances of artistic practices/activities. You can see how that happens when you consider words like "painting" and "pottery" that can describe both a practice and an output. With the enhanced constraint types, these errors can be flagged much more effectively: instead of just constraining the value of P31 to be not pottery, we can constrain it to not be any of the (currently 75) subclasses of pottery, and tell editors to use genre (P136) instead. Swpb (talk) 14:52, 16 July 2024 (UTC)

endorsement

I wholeheartedly support this wish. If these kinds of constraints were added they would make it much easier to specify and keep up-to-date constraints that would guard against errors like creating instances of classes that are occupations, such as plumber (Q252924), keeping the human (Q5) part of Wikidata more consistent with the community norms in that area. These kinds of constraints would also be useful in the ship (Q11446) domain. Peter F. Patel-Schneider (talk) 21:29, 15 July 2024 (UTC)