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:
- Mandatory, e.g. "sexual orientation should always have a reference"
- Normal, e.g. "if person A is the sister of person B, then B should also be the sister of A"
- 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. Note that because properties reside on wikidata their constraints are defined on wikidata.
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.
How to test locally
- make sure you have federation set up locally
- install WikibaseQualityConstraints
- run maintenance/ImportConstraintEntities.php --wiki wikidatawiki and copy and paste the output into LocalSettings.php (assuming that your local wikidata's database is called wikidatawiki) ... note that the output you paste into LocalSettings needs to be accessible to all wikis and not just wikidatawiki
- add constraints to a property on your local wikidata - have a look at https://www.wikidata.org/wiki/Property:P21 for an example
- run maintenance/ImportConstraintStatements.php --wiki wikidatawiki to import the constraints you've just added into the db
- go to a File page on local commons, and add some values that violate your constraint (top-level and qualifier) - you should see messaging to let you know about the violations
- note that constraint checks are run if and only if you are logged in (same as on wikidata)
COVID-19 Deployment Criteria
- Can you roll back this change without lasting impact?
- A recovery plan is required as this will help identify our capacity for recovering from the failure
- THIS IS A KEY QUESTION, if you can’t answer it, you shouldn’t deploy
- Is specialized knowledge required to support this change in production? If so, are there multiple people with this knowledge?
- Is there a way to increase confidence about the correctness of this change?
- Reviews (Design, Code, etc)
- Testing coverage (unit tests, integration tests)
- Manual testing (e.g. Beta, vagrant, docker)
