Page MenuHomePhabricator

Don’t check constraints on deprecated statements
Closed, ResolvedPublic

Description

The following constraint types should all not be checked on deprecated statements: conflicts with, difference within range, inverse, item requires claim, mandatory qualifier, multi value, one of, allowed qualifiers, range, single value, symmetric, value requires claim, type, unique value, value type.

Rationale: all of these constraint types are “logical” or “semantical” constraints, not “technical” ones, and the deprecated rank already marks the statement as logically / semantically incorrect.

Does anyone disagree?

Event Timeline

Lucas_Werkmeister_WMDE moved this task from incoming to in progress on the Wikidata board.

Hm, which constraint status should be reported for skipped checks? “compliance”? “exception”? or a new one (e. g. “skipped”)?

Edit: If it’s a new status, probably not “skipped”, because “exception” is already a kind of “skipped”. “deprecated” would be alright, I guess.

What about the format constraint? Is that a semantical constraint or a technical one? I’m leaning towards the latter, i. e. still check it on deprecated statements.

Change 364731 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Don’t check constraints on deprecated statements

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

What about the format constraint? Is that a semantical constraint or a technical one? I’m leaning towards the latter, i. e. still check it on deprecated statements.

Yes let's check it for now.

Hm, which constraint status should be reported for skipped checks? “compliance”? “exception”? or a new one (e. g. “skipped”)?

Edit: If it’s a new status, probably not “skipped”, because “exception” is already a kind of “skipped”. “deprecated” would be alright, I guess.

I think it should have a new status to be able to distinguish it easily from the others. "deprecated" isn't really nice but the best I can think of so let's use it for now.

I honestly thin we don't need this. This is introducing quite a bit of complexity to solve a potential problem before it arises. I'd much rather see a better system for handling exceptions. That could easily be used to manually mark the handful of deprecated statements that are also constraint violations.

Compare T111313: [Story] Marking external mismatches as exceptions. Not sure why we only discussed this for mismatches with external data. Should be the same for constraint violations.

Change 364731 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Don’t check constraints on deprecated statements

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

Personally, I'd exclude all deprecated statements from constraint checks.

Change 366581 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Finish constraint status for deprecated statements

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

Change 366581 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Finish constraint status for deprecated statements

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