| Lucas_Werkmeister_WMDE renamed this task from "“GND ID” constraint violation on every statement" to "Broken constraint parameters on Wikidata". Lucas_Werkmeister_WMDE updated the task description. (Show Details) |
CHANGES TO TASK DESCRIPTION
This line in the constraints CSV is faulty:
```
32755add-0b0a-494b-9f8c-3a0eb6bda115,227,Qualifiers,"{""property"": ""P1810,P1932,P742,P101,P106,P580,P582,P131P136,P1476,P571,P1269,P518,P1552""}"
```
Note the missing comma between two of the qualifier properties: `P131P136`. This comes from the following constraint templateere are a couple of broken constraint parameters in the `constraints.csv` file for Wikidata:
```- P227’s Qualifiers constraint has `P131P136` with no comma in between.
{{Constraint:Qualifiers|list= <!--
person: --> {{P|1810}}, {{P|1932}}, {{P|742}}, {{P|101}}, {{P|106}}, <!--
organization: --> {{P|580}}, {{P|582}}, {{P|131}} <!--
work: --> {{P|136}}- P227’s Unique value, {{P|1476}}P276’s Value type, {{P|571}}P373’s Unique value, {{P|1269}}P685’s Item, <!--
P704’s Item, generel: --> {{P|518}}P901’s Item, {{P|1552}} }}and P3430’s Type constraint have Q-IDs with no comma in between (matches for `[0-9]Q`).
```
The comma is also missing there, but apparently the constraint report bot can deal with that – we can’t.
Previously, the Qualifiers checker used to do a simple string comparison between the qualifier property ID serializations on the statement and the comma-separated properties in the parameters, so (I believe) the only effect was that P131 and P136 qualifiers would erroneously be reported as not permitted. But with the migration to constraint statements, we now do more validation on the constraint parameters even when they’re sourced from statements- P276’s Value type, so this is now reported as a violation on every P227 statement:
> The value for the parameter "property" must be a propertyP279’s Conflicts with, not "P131P136"and P901’s Item constraint have Q-IDs with double Qs (“QQ13406463”).
What do we want to do about this?Previously, the checkers mostly did simple string comparisons on the parameters, but with the migration to constraint statements, we now do more validation on the constraint parameters even when they’re sourced from templates, We have a couple of options:so most of these errors are now reported as violations on all statements for the affected property.
1. Teach `ConstraintParameterParser` about this one, particular exception, and backport that fix. (As far as I can’t tell, there aren’t any more non-comma-separated properties in the file (no more matches for `[0-9]P`).)
2. Edit the `constraints.csv` file to fix the parameters and rerun the import script.
3. Fix the constraint on Wikidata and reimport constraints from templates.
4. Don’t do anythingWe should ask the community to fix these where they haven’t been fixed already (or fix them ourselves?), since we’ll usand then do one more constraint statements exclusively soon enoughtemplate import.
```
32755add-0b0a-494b-9f8c-3a0eb6bda115,227,Qualifiers,"{""property"": ""P1810,P1932,P742,P101,P106,P580,P582,P131P136,P1476,P571,P1269,P518,P1552""}"
```
Note the missing comma between two of the qualifier properties: `P131P136`. This comes from the following constraint templateere are a couple of broken constraint parameters in the `constraints.csv` file for Wikidata:
```- P227’s Qualifiers constraint has `P131P136` with no comma in between.
{{Constraint:Qualifiers|list= <!--
person: --> {{P|1810}}, {{P|1932}}, {{P|742}}, {{P|101}}, {{P|106}}, <!--
organization: --> {{P|580}}, {{P|582}}, {{P|131}} <!--
work: --> {{P|136}}- P227’s Unique value, {{P|1476}}P276’s Value type, {{P|571}}P373’s Unique value, {{P|1269}}P685’s Item, <!--
P704’s Item, generel: --> {{P|518}}P901’s Item, {{P|1552}} }}and P3430’s Type constraint have Q-IDs with no comma in between (matches for `[0-9]Q`).
```
The comma is also missing there, but apparently the constraint report bot can deal with that – we can’t.
Previously, the Qualifiers checker used to do a simple string comparison between the qualifier property ID serializations on the statement and the comma-separated properties in the parameters, so (I believe) the only effect was that P131 and P136 qualifiers would erroneously be reported as not permitted. But with the migration to constraint statements, we now do more validation on the constraint parameters even when they’re sourced from statements- P276’s Value type, so this is now reported as a violation on every P227 statement:
> The value for the parameter "property" must be a propertyP279’s Conflicts with, not "P131P136"and P901’s Item constraint have Q-IDs with double Qs (“QQ13406463”).
What do we want to do about this?Previously, the checkers mostly did simple string comparisons on the parameters, but with the migration to constraint statements, we now do more validation on the constraint parameters even when they’re sourced from templates, We have a couple of options:so most of these errors are now reported as violations on all statements for the affected property.
1. Teach `ConstraintParameterParser` about this one, particular exception, and backport that fix. (As far as I can’t tell, there aren’t any more non-comma-separated properties in the file (no more matches for `[0-9]P`).)
2. Edit the `constraints.csv` file to fix the parameters and rerun the import script.
3. Fix the constraint on Wikidata and reimport constraints from templates.
4. Don’t do anythingWe should ask the community to fix these where they haven’t been fixed already (or fix them ourselves?), since we’ll usand then do one more constraint statements exclusively soon enoughtemplate import.
TASK DETAIL
EMAIL PREFERENCES
To: Lucas_Werkmeister_WMDE
Cc: Jonas, Lucas_Werkmeister_WMDE, Aklapper, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331
Cc: Jonas, Lucas_Werkmeister_WMDE, Aklapper, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
