Page MenuHomePhabricator

Type constraints still report false violations
Closed, ResolvedPublic

Description

The “type” and “value type” constraints should no longer have any false violations, now that they fall back to SPARQL, but for some reason, books are still not recognized as subclasses of works, so you get constraint violations on “author” (P​50) or “notable work” (P​800) statements.


Another sample in T171933 (closed as duplicate)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 30 2017, 12:15 PM

This issue is currently waiting on two changes:

If that doesn’t help, I’ll have to look into other ways to investigate this.

Seems to work a lot better now – at least, books are now properly recognized as works. (Note that Douglas Adams and some other items currently don’t work at all due to T171295: Fatal error: Argument 4 passed to WikibaseQuality\ConstraintReport\Constraint::__construct() must be array, but that’s unrelated.)

Thanks for merging this with T171933.

I think it would be better if the timeout would be displayed as such, not as a constraint violation.

Esc3300 updated the task description. (Show Details)Jul 28 2017, 8:28 AM

Ooooooh. I think I finally realized what’s happening. Let’s take The Private Life of Genghis Khan, a short story that gets constraint violations because it’s supposedly not a book.

  • The TypeCheckerHelper takes The Private Life of Genghis Khan’s P​31 statement – short story – and checks if it is a subclass of work.
  • Since the limit for type checks in PHP has not yet been reached, TypeCheckerHelper takes the first P​279 statement – prose – and checks if that is a subclass of work.
  • TypeCheckerHelper descends into prose’s type hierarchy. Eventually, at some unknown superclass (say, literary genre), it reaches the limit for type checks.
  • Since the limit has been reached and a SparqlHelper is configured, TypeCheckerHelper falls back to SPARQL. It asks if literary genre is a subclass of work.
  • SPARQL tells us (correctly) that literary genre isn’t a subclass of work.
  • TypeCheckerHelper walks back the stack of subclass checks, returning false on each level. At no level is the SparqlHelper consulted again, because we don’t want to spam WDQS.
  • Eventually, TypeCheckerHelper has fallen back to short story. It checks the next P​279 statement: literary work.
  • Since the limit for type checks has already been exceeded, the check returns false immediately (and since the limit was already exceeded earlier, not in this call, the SPARQL fallback doesn’t happen either).
  • In the end, TypeCheckerHelper returns false for the overall check.

The SPARQL fallback needs to happen at the outermost level, not at the first subtype check that exceeds the limit.

So one could try "fix" it by re-ordering the P 279 statements. ;)

Ideally, most values used for P 31 would have several P 279 statements.

Change 368664 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Fix type checking SPARQL fallback

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

Change 368664 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Fix type checking SPARQL fallback

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

Change 369429 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikidata@wmf/1.30.0-wmf.12] Update Wikidata - fix constraint type checks

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

Change 369555 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikidata@master] Update Wikidata - fix constraint type checks

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

Change 369555 abandoned by Lucas Werkmeister (WMDE):
Update Wikidata - fix constraint type checks

Reason:
Sorry, pushed to wrong refs/for/ path – this belongs on wmf/1.30.0-wmf.12.

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

Change 369429 merged by jenkins-bot:
[mediawiki/extensions/Wikidata@wmf/1.30.0-wmf.12] Update Wikidata - fix constraint type checks

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

Mentioned in SAL (#wikimedia-operations) [2017-08-02T13:07:18Z] <hashar@tin> Synchronized php-1.30.0-wmf.12/extensions/Wikidata: fix constraint type checks - T169326 (duration: 02m 13s)

waldyrious added a subscriber: waldyrious.
Lucas_Werkmeister_WMDE closed this task as Resolved.Aug 3 2017, 7:30 PM
Lucas_Werkmeister_WMDE claimed this task.

Okay, the change was finally deployed (it was delayed for a while, not sure why), and it seems to work – no more violations on The Private Life of Genghis Khan and on the Hestskjær Lighthouse.

Unfortunately, the Wikidata deployment was rolled back due to unrelated problems in Wikibase itself, so the false violations are back for the time being. If the build problem persists, I might try to get the fix backported, otherwise we’ll just have to wait it out – sorry.

Jarekt added a subscriber: Jarekt.Oct 12 2017, 12:23 PM

I am confused about this issue is it fixed or is it still a problem? Is the task is "resolved" but the fix is not deployed yet?

I came to phabricator to report an issue I noticed today with "type constraint " d:Wikidata:Database reports/Constraint violations/P1472 reports a constraint violation based on an item that is an instance of "newspaper", which is a subclass of "media company", which is a subclass of "organization", which is on a list of approved types for the constraint. Is this a new issue for which I should create a new ticket, or is this issue still unresolved?

The fix was deployed a long time ago, this bug is resolved. But regardless of that, whatever you’re seeing on d:Wikidata:Database reports/Constraint violations is KrBot’s business – the WikibaseQualityConstraints extension (which this bug is about) has nothing to do with that. Do you also see the constraint violation on d:Special:ConstraintReport or when looking at the item with the checkConstraints gadget enabled?

Do you also see the constraint violation on d:Special:ConstraintReport or when looking at the item with the checkConstraints gadget enabled?

No I do not. I will check with KrBot.