Page MenuHomePhabricator

Add P4224 and P360 to wgWBQualityConstraintsPropertiesWithViolatingQualifiers
Closed, ResolvedPublic


Main components:

  • Constraint System

User story:
As a Wikidata editor, I do not want to get false-positive constraint violations for items that use P4224 (“category contains”) or P360 ("is a list of").

P4224 ("category contains") and P360 ("is a list of") are properties that should always just accept any qualifiers. This remains true even if the property used in the qualifier has a constraint saying the property should only be used in the main snak. Currently, these properties correctly often lead to false-positive constraint violations.


Include P4224 and P360 in wgWBQualityConstraintsPropertiesWithViolatingQualifiers. 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”.

Acceptance criteria:

  • P4224 and P360 are included in wgWBQualityConstraintsPropertiesWithViolatingQualifiers.

Event Timeline

Lydia_Pintscher claimed this task.
Lydia_Pintscher added a subscriber: Lydia_Pintscher.

That's defined in the constraint itself and can be changed on-wiki: (last statement says it should be used only in the main snak)

No: P1196 usually should be only used as main value. This usage is not normal.

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 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

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.)

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 ;)

Manuel renamed this task from Add P4224 to wgWBQualityConstraintsPropertiesWithViolatingQualifiers to Add P4224 and P360 to wgWBQualityConstraintsPropertiesWithViolatingQualifiers.Aug 31 2021, 7:37 AM
Manuel updated the task description. (Show Details)

Change 583407 merged by jenkins-bot:

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

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)

Addshore claimed this task.