Page MenuHomePhabricator

Inform users about constraint violation
Open, Needs TriagePublic

Description

Background

Properties may have property constraints that are defined by the Wikidata community. Editors agree on how a property should be used and add these rules as constraints, or they identify common mistakes made by other editors that could be caught via a constraint. If a Wikidata user submits a value that violates a constraint, the value is saved, but the user is presented with a warning describing the constraint violation. Some constraint violations are included in the query service so users can create lists of problematic statements and fix them (vs. just stumbling upon them), but this work is incomplete.

There are 3 levels of constraints:

  1. Mandatory, e.g. "sexual orientation should always have a reference"
  2. Normal, e.g. "if person A is the sister of person B, then B should also be the sister of A"
  3. Suggestions, e.g. "if there is a date of birth then there should probably also be a place of birth"

Constraints are not enforced by the software; they are more or less strong hints to the editors. The editors might socially enforce certain constraints based on Wikidata policy (e.g. the sexual orientation example above).

(Thanks to Lydia Pintscher for providing this info!)

Constraints on Commons

Technical implementation

We would like to include constraint violation warnings in a similar way in the structured data UI on commons to facilitate the collection of accurate data. There has been some discussion on whether we should pull constraints from Wikidata via an API call or allow Commons editors to add their own constraints, but at least initially we will maintain parity with Wikidata. According to Lydia, it would possible for WMDE to add a parameter to constraint definitions to indicate that a constraint only applies to MediaInfo.

User interface

On the design side, we need to figure out how to best show the resulting message to the user at both the "item level" (rows below the input field in the statement panel) as well as at the qualifier level. We should follow the wikidata paradigm of displaying constraint violations as warnings and not errors, and we will allow the data to be saved regardless of constraint violations. Ideally, in the warning message, we would link to the constraints portion of the relevant wikidata item so the user can understand where the constraint is coming from.

We should support the display of constraint violation messages for any property that has constraints, regardless of data type.

Event Timeline

egardner created this task.Nov 25 2019, 8:27 PM
Restricted Application removed a project: Patch-For-Review. · View Herald TranscriptNov 25 2019, 8:27 PM

Where do you plan to store the constraints? Currently the constraints are on Wikidata on the properties.

Where do you plan to store the constraints? Currently the constraints are on Wikidata on the properties.

I assume we'd test for constraint violation when a new value for a given property is submitted by using the appropriate API action, and wouldn't keep track of the constraints ourselves. We'd just check against what was defined on Wikidata.

However, if a value is saved that violates a property's constraints, we probably want to ensure that other users can see the warning message in their appropriate language prior to editing (and possibly without any reliance on JS at all).

Where do you plan to store the constraints? Currently the constraints are on Wikidata on the properties.

I assume we'd test for constraint violation when a new value for a given property is submitted by using the appropriate API action, and wouldn't keep track of the constraints ourselves. We'd just check against what was defined on Wikidata.

Currently constraints are defined on properties on Wikidata, for example for creator at https://www.wikidata.org/wiki/Property:P170 .

However, if a value is saved that violates a property's constraints, we probably want to ensure that other users can see the warning message in their appropriate language prior to editing (and possibly without any reliance on JS at all).

This assumes that constraints for Wikidata are the same as constraints as for Commons. I don't think this assumption will hold. For example on Commons we currently don't add P31 (instance of) yet. So every item with a creator will get a constraint violation. See for example https://commons.wikimedia.org/w/index.php?title=File%3ATerWorm.jpg&type=revision&diff=374654987&oldid=365995523
Reminds me of something else, do we already have a task to add support for "somevalue" in the interface? We've been using it quite a bit already.

This assumes that constraints for Wikidata are the same as constraints as for Commons. I don't think this assumption will hold. For example on Commons we currently don't add P31 (instance of) yet. So every item with a creator will get a constraint violation. See for example https://commons.wikimedia.org/w/index.php?title=File%3ATerWorm.jpg&type=revision&diff=374654987&oldid=365995523

Good point, I'm not sure exactly how we should handle things if properties have a different set of constraints when used on Commons. We might need to answer that question before we can move forward with this task (though the design work can probably proceed regardless).

Also, I see that there is some discussion about constraints here: https://phabricator.wikimedia.org/T230314 – maybe this ticket should be rolled into that one.

Reminds me of something else, do we already have a task to add support for "somevalue" in the interface? We've been using it quite a bit already.

I didn't see an existing task here so I created one: https://phabricator.wikimedia.org/T239172

Not sure where it will fall in the team's current priorities but it's something we're aware of.

egardner removed egardner as the assignee of this task.Dec 3 2019, 5:30 PM
egardner moved this task from To Do to Blocked on the Structured-Data-Backlog (Current Work) board.

On the technical side, we need to make some kind of API call during the submission step that will test against a given property's constraints.

Note: currently, WikibaseQualityConstraints only supports checking constraints on saved statements, so you would make the API call after saving the new statement. (The task for checking constraints before saving statements is T168626.)

Jheald added a subscriber: Jheald.Dec 10 2019, 12:27 AM
AnneT updated the task description. (Show Details)Dec 12 2019, 6:19 PM
AnneT updated the task description. (Show Details)Dec 13 2019, 5:34 PM