Properties may have [[https://www.wikidata.org/wiki/Help:Property_constraints_portal|property constraints]] that are defined by the community. If a user submits a value that violates a constraint, we should still save it, but we need to inform users that the value may break the rules.## Background
On the technical sideProperties may have [[https://www.wikidata.org/wiki/Help:Property_constraints_portal|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), we need to make some kind of API call during the submission step that will test against a given property's constraintsbut 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 likely 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.