Sorry I don't understand what you're trying to change then.
The constraint on P1196 says that it should only be used as a main value. And the usage in a qualifier on https://www.wikidata.org/wiki/Q7951553 triggers a constraint violation as expected. Where is the issue I'm not seeing?

This is how P4224 is used. So we should not treat the qualifier as constraint violation.

Ahhhhhhhhhhhhhhhhhhhh now I think I get it. Pretty please be more descriptive in the requests. This one is really hard to understand.

So if I get it right "category contains" is a property that should always just accept any qualifiers even if the property used in the qualifier has a constraint saying the property should only be used in the main snak.

@Lucas_Werkmeister_WMDE: Is that what wgWBQualityConstraintsPropertiesWithViolatingQualifiers does?

That is what this config setting does, yes, though it was only intended for the “example” properties. Whether we want to extend it to “category contains” is a different question, and one I’d like to get some feedback from others on.

Ok thanks.
It seems ok to me to use it then. It seems to be in the same vain as the example property to me.

More specifically, that setting disables all constraint checks on qualifiers of statements for those properties – not just “property scope” (main/qualifier/reference), but also, for example, “type” aka “subject class”. I guess that’s what we want here as well.

Change 583407 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[operations/mediawiki-config@master] Don’t check constraints on “category contains” qualifiers

https://gerrit.wikimedia.org/r/583407

I'm afraid this will continue the path of overcomplicating property constraints with exception layers patching weak or ill-defined constraints. Do you think it would be okay to complete/relax the constraint by allowing P1196, and other properties, to be used as a qualifier, @Bugreporter?

(Sorry for commenting so late)

I don't think so, given how P4224 is used.

I think that other constraints still apply even if "manner of death" (P1196) is used as a qualifier for "category contains" (P4224). Also, "category contains" (P4224) will not be the only property with which "manner of death" (P1196) and other properties can be used as qualifiers.

The difference between

• properties that can be used with main values but not as qualifiers and
• properties that can be used in both ways

doesn't seem clear. Many properties (like "manner of death") that today are indicated to be limited to main values could be used at any time as qualifiers with a current or future property, or are even already violating the constraint, at least according to the flexible way qualifiers are used and understood right now.

There's already a general tendency to add false positives as exceptions to patch up poorly polished constraints, even a tendency (less usual but existing) to ignore violations, instead of rethinking and improving on previous work (data or constraints). This is causing the constraints to become increasingly complex and over-adjusted to specific data, and therefore less generalizable, understandable and useful. Spreading to darker layers of configuration/implementation the habit of adding exceptions to ignore the expected behavior of some constraints instead of rethinking them could make things worse.

Defining general constraints in a correct and justified way takes time and effort, but it's the only way to get useful constraints. At the moment I do not believe that new layers of complexity are necessary to satisfy certain use cases, but just the opposite, I believe that we should make the features and constraints simpler and more generalizable, or one day not even Lucas (Lucas! :O) will end up knowing how Property constraints work.

I think any discussion of the constraints of P1196 (manner of death) is a distraction here, to be honest. The thing about P4224 is that it can have almost any other property as qualifier, even properties that aren’t supposed to be used as qualifiers, because it’s really simulating main statements. This isn’t specific to P1196, but it is specific to P4224, as far as I know – only “category contains” and properties like “Wikidata property example” interpret qualifiers as main statements like that, as far as I’m aware. So I think it makes a lot of sense to treat them in the same way. (If you know other properties where the same thing happens, please let us know.)

When doing this, please add "is a list of" (P360) as well.

BTW, I noted it as an exception at Help:Property_constraints_portal/Property_Scope_Constraint. Obviously, it applies to other constraints too, but less importantly so.

I’ve documented it at the main constraints portal instead now.

Good. Just noticed that we discussed this 3 years ago .. on talk of that help page. Maybe flag it for follow-up in 2024 then ;)

Ready for code review imho.

Change 583407 merged by jenkins-bot:

[operations/mediawiki-config@master] Don\u2019t check constraints on two property qualifiers

https://gerrit.wikimedia.org/r/583407

The given example item stopped showing a constraint violation in the meantime, but I found another one (with this query).

Note that, even after this change is deployed, cached constraint check results with violations will remain valid (until they’re purged or the TTL expires).

Mentioned in SAL (#wikimedia-operations) [2021-09-15T11:10:36Z] <lucaswerkmeister-wmde@deploy1002> Synchronized wmf-config/InitialiseSettings.php: Config: [[gerrit:583407|Don’t check constraints on two property qualifiers (T235292)]] (duration: 01m 11s)