Page MenuHomePhabricator

[Story] Integrate violations into Wikidata UI
Closed, ResolvedPublic

Assigned To
Authored By
Tamslo
Apr 23 2015, 11:46 AM
Referenced Files
F7792956: Birthdate constraint.JPG
Apr 27 2017, 2:14 PM
F7750910: image.png
Apr 25 2017, 9:18 AM
F7076727: image.png
Mar 29 2017, 8:43 AM
F1492568: screenshot_item.jpg
Aug 14 2015, 8:56 AM
Tokens
"Like" token, awarded by waldyrious."Love" token, awarded by matej_suchanek."Like" token, awarded by Pintoch.

Description

We want to keep the data quality high and expose more people (readers!) to issues so they can help fix them. In order to do that we need to expose the constraints violations and mismatches with 3rd party databases right next to the statement that is problematic.

In a first version we will do on-demand checking only. For this we need:

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Tamslo raised the priority of this task from to Needs Triage.Apr 23 2015, 11:46 AM
Tamslo added a project: Wikibase-Quality.
Tamslo moved this task to Backlog on the Wikibase-Quality board.
Tamslo added a subscriber: Tamslo.
Tamslo renamed this task from Integrate into Wikidata UI to Integrate violations into Wikidata UI.Apr 23 2015, 11:46 AM
Tamslo set Security to None.
soeren.oldag reassigned this task from soeren.oldag to dominic.sauer.
soeren.oldag moved this task from TODO to DOING on the Wikibase-Quality board.
Jonas renamed this task from Integrate violations into Wikidata UI to [Story] Integrate violations into Wikidata UI.Aug 13 2015, 4:39 PM
Jonas updated the task description. (Show Details)
Jonas added a subscriber: Jonas.

Can you please insert existing mock-ups to the description?

Some remarks from a usability perspective:

  • We have few space (Which makes icons attractive)
  • …but no one understands Icons we think up ourselves
  • …in particular, simple traffic-light metaphors are to be avoided, since in their full-traffic-light they use up much space and in the just-colored-light they are not accessible to the colorblind population

One solution would be:

  • What is shown
    • There is one standardized set for icons, e.g. a warning sign (violation) and a stop sign (severe violation).
    • When there is no violation, nothing is shown, if there is one violation it’s grade of severity is shown in the icon
    • if there are multiple violations, the icon for the most severe is shown
    • We can show a number behind the icon indicating the number of violations
  • upon click on the icon, we show a list of violations (as the click on the mediawikis up-right area message tray shows a list of mentions)

Mock: 1) small version of indicator 2) larger version of indicator 3) expanded infos

image.png (693×642 px, 72 KB)

We could offer an API for that, so that you can hook in your checks as well as your UI for them. The latter could be done declaratively (similar like declaring a UI in Jamovi, but it could be even much simpler)

Change 348080 had a related patch set uploaded (by Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Add user script to include reports on item pages

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

Change 348080 adds a user script that shows a violation indicator, similar to Jan’s mockup. Here’s what it looks like:

image.png (502×532 px, 29 KB)

(The particular constraints here are not very meaningful, just added for testing. Also, the extension currently doesn’t have different severities of violations, so there are no different icons we could show.)

Change 348080 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Add user script to include reports on item pages

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

Birthdate constraint.JPG (417×596 px, 37 KB)

I have added the js in my commons.js and started doing some tests. This happened to me: p569 (date of birth) and p570 (date of death) are perfectly ok, but for some reason the script notices me a violation (well, *two* in the case of p569). I've got also some malfunction with p27 (country of citizenship), if p569 and/or p570 are not there.

@Sannita: Thanks for your feedback!

The violation in P​569 is because of this constraint on P​569’s talk page:

Difference with “date of birth (P​569)” within range [30, 150]: the difference with property “date of birth (P​569)” should be in the range from “30” to “150”.

Read: a date of birth should be at least 30 years away from itself. In my opinion, that makes no sense, and I don’t know who added it… but the constraint is there, we imported it, and now the API reports violations for it on practically every human with a date of birth :/

However, the constraint on P​570 is more sensible (within 0-150 years of date of birth), so I don’t know why that would report a violation. Did you get violations for P​570 as well, or only for P​569?

And can you please elaborate on the malfunction with P​27?

@Sannita: Thanks for your feedback!

The violation in P​569 is because of this constraint on P​569’s talk page:

Difference with “date of birth (P​569)” within range [30, 150]: the difference with property “date of birth (P​569)” should be in the range from “30” to “150”.

Read: a date of birth should be at least 30 years away from itself. In my opinion, that makes no sense, and I don’t know who added it… but the constraint is there, we imported it, and now the API reports violations for it on practically every human with a date of birth :/

Got it. I already saw somebody contacted the user who added that restriction. The *very* strange thing is that I get the same violation twice - it's still the very same of the image I posted before.

However, the constraint on P​570 is more sensible (within 0-150 years of date of birth), so I don’t know why that would report a violation. Did you get violations for P​570 as well, or only for P​569?

I have a "Range ⧼wbqc-violation-message-range-parameters-needed⧽" violation on p570, but only once. It seems to be either a malfunction or we didn't still described that violation.

And can you please elaborate on the malfunction with P​27?

It disappeared since my last comment, so we can ignore it, I think.

Read: a date of birth should be at least 30 years away from itself.

Actually, I think I misunderstood this constraint – there’s another parameter to the template that isn’t shown in the rendered constraint, but apparently the intended meaning is/was to constrain the age difference between doctoral student and doctoral advisor. But anyways, Ivan removed this constraint, so it should be gone on the next reload.

The *very* strange thing is that I get the same violation twice

The template was present twice (with different properties in the extra parameter), so we had the same constraint twice.

"Range ⧼wbqc-violation-message-range-parameters-needed⧽"

Okay, that’s two other problems (one that causes the violation to appear in the first place, and another that causes the untranslated message), but both are already known and should be fixed soon. Thanks.