Property talk:P4680
Documentation
defines the scope where a constraint is checked – can specify the usage scope (main value of a statement, on qualifiers, or on references) and the datatype (Wikibase item, property, lexeme, etc.)
| Represents | Wikidata constraint scope (Q54718960) | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Data type | Item | |||||||||
| Domain | According to this template:
Wikidata property (Q18616576)
According to statements in the property:
When possible, data should only be stored as statementsWikidata property (Q18616576) | |||||||||
| Allowed values | constraint checked on main value (Q46466787), constraint checked on qualifiers (Q46466783), constraint checked on references (Q46466805), Wikibase item (Q29934200), Wikibase property (Q29934218), Wikibase lexeme (Q51885771), Wikibase form (Q54285143), Wikibase sense (Q54285715) or Wikibase MediaInfo (Q59712033) | |||||||||
| Example | start time (P580) → constraint checked on qualifiers (Q46466783) reference URL (P854) → constraint checked on main value (Q46466787) | |||||||||
| Robot and gadget jobs | KrBot could ignore constraints without “main value” scope | |||||||||
| See also | property constraint (P2302), property scope (P5314) | |||||||||
| Lists | ||||||||||
| Proposal discussion | Proposal discussion | |||||||||
| Current uses |
| |||||||||
| Search for values |
List of violations of this constraint: Database reports/Constraint violations/P4680#Scope, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P4680#Entity types
List of violations of this constraint: Database reports/Constraint violations/P4680#Type Q18616576, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P4680#Item P2302, search, SPARQL
values[edit]
Notified participants of WikiProject property constraints
I’ve created three new items for the values of this property, since that seemed to be the consensus on the proposal discussion: constraint checked on main value, constraint checked on qualifiers, and constraint checked on references. I’ve opted on the side of caution here, with long, unambiguous names – if you think they should be shorter (e. g. just “main value”, “qualifiers”, “references”), feel free to change them :) --Lucas Werkmeister (WMDE) (talk) 10:58, 22 December 2017 (UTC)
- I like the descriptive labels. —MisterSynergy (talk) 11:07, 22 December 2017 (UTC)
- I also prefer long less-unambiguous names over shorter names. --Jarekt (talk) 13:01, 22 December 2017 (UTC)
- Longer labels, please. - PKM (talk) 19:52, 22 December 2017 (UTC)
not yet supported by WikibaseQualityConstraints[edit]
Just for the record – the WikibaseQualityConstraints extension (and therefore the checkConstraints gadget) don’t yet support this parameter. I’ll add a comment here as soon as it does. --Lucas Werkmeister (WMDE) (talk) 11:11, 22 December 2017 (UTC)
Done Sorry, I forgot to update this… but it’s definitely supported now, and has been for a few weeks :) --Lucas Werkmeister (WMDE) (talk) 16:49, 9 February 2018 (UTC)
default scope[edit]
Notified participants of WikiProject property constraints
I kinda glossed over this question in the proposal (sorry) – what should the default scope of a constraint be? Currently, WikibaseQualityConstraints hard-codes that some constraint types are also checked on qualifiers and references, and some aren’t. Should I keep it this way, with hopefully reasonable defaults, and the option to override them with constraint scope (P4680) – or would you prefer to check all constraints only on the main value by default, and always explicitly specify constraint scope (P4680) when a constraint should also be checked elsewhere?
For the record, the current status is:
- checked everywhere: distinct-values constraint (Q21502410), value-type constraint (Q21510865), value-requires-statement constraint (Q21510864), one-of constraint (Q21510859), range constraint (Q21510860), Commons link constraint (Q21510852), format constraint (Q21502404)
- checked everywhere except on references: subject type constraint (Q21503250)
- checked on the main value: conflicts-with constraint (Q21502838), difference-within-range constraint (Q21510854), inverse constraint (Q21510855), item-requires-statement constraint (Q21503247), required qualifier constraint (Q21510856), multi-value constraint (Q21510857), allowed qualifiers constraint (Q21510851), single-value constraint (Q19474404), symmetric constraint (Q21510862)
- special cases: used as qualifier constraint (Q21510863), used as reference constraint (Q21528959), used for values only constraint (Q21528958)
Of course, that’s not necessarily the final list of defaults even if we decide to keep the defaults – for example, we could check constraint types that are purely about the value (like one-of constraint (Q21510859) or format constraint (Q21502404)) everywhere, but be more cautious about more ambiguous constraints like subject type constraint (Q21503250) (i. e., by default only check them on the main value). --Lucas Werkmeister (WMDE) (talk) 11:33, 22 December 2017 (UTC)
- Checking type constraint on qualifiers often doesn't make sense. When the subject doesn't match the type but the object does currently a constraint violation is thrown. This happens for example with all property examples. As long as it behaves that way I think the default should be main value/subject only. ChristianKl ❪✉❫ 11:39, 22 December 2017 (UTC)
- There are many situations where it does make sense, though (some examples are in phabricator:T177388) – I’ve gone back and forth on this a few times, it’s not trivial :) and property examples are a completely different topic (phabricator:T183267), but in general, if the object should match the type and not the subject, then the constraint type should be value-type constraint (Q21510865)! --Lucas Werkmeister (WMDE) (talk) 15:27, 22 December 2017 (UTC)
This property now supports restricting by entity type as well[edit]
I've added entity types in Special:Diff/1502064197 because phab:T269724 has added support for this property to restrict constraints to specific entity types as well as to specific locations. For example, we can now say that a constraint only applies on items. - Nikki (talk) 09:20, 23 September 2021 (UTC)