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

This page is for discussions related to the Community Wishlist/Wishes/Wikidata: Enable the "class" and "relation" parameters on more constraint types page.   Please remember to: Sign posts using the four tildes (~~~~) Remain civil and polite during discussions. Place new text under old text (start a new post).

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 and nonsensical subclass chains. 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. Here are a couple other valuable constraints we could make, from a long list I've been keeping (there aren't many current violations of these, since I've cleaned them up recently):

• The value of instance of (P31) should not be a religion or worldview such as Q22679 (Baháʼí Faith): If the item is a person, their views should be expressed with P140 (religion or worldview), or if the item is a version of another religion or worldview, that should be expressed with P279 (subclass of). This would be a none-of constraint on P31, with class=Q71966963 (religion or worldview), relation=instance of, and replacement property=P140 or P279.

• Subclasses of education (the activity) should not generally have instances: Types of education should be subclasses (rather than instances) of education or its subclasses, and educational institutions should be instances of educational institution, not instances of education or its subclasses. This would be a none-of constraint on P31, with class=Q8434 (education), relation=subclass of, and replacement property=P279 or replacement value=Q2385804.

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)