Constraint report tool should ignore any constraints set to deprecated like for example https://www.wikidata.org/w/index.php?title=Property:P2014&diff=prev&oldid=595537993 . This makes it easier for users to (temporary) remove constraints without having to remove everything. Would be nice to have the template on the talk page still show the constraint, but with a different color and explanation it's disabled and only a SPARQL link (constraint report link wouldn't point anywhere).
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Ignore deprecated constraints | mediawiki/extensions/WikibaseQualityConstraints | master | +64 -1 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Lucas_Werkmeister_WMDE | T173695 Enable constraint checks by default for users | |||
| Resolved | Lucas_Werkmeister_WMDE | T180874 Ignore deprecated constraints in constraint tool | |||
| Resolved | Ladsgroup | T184720 Re-import constraints from statements |
Event Timeline
Comment Actions
Hm, I just noticed – once we have the constraint scope parameter, a constraint scope of no value could perhaps also be used to disable a constraint. Not sure which is better. Any thoughts?
Comment Actions
I think it should just support the ranks, that's what people expect how it should work.
Comment Actions
Change 403641 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Ignore deprecated constraints
Comment Actions
@Sjoerddebruin, can you please be a little more specific about that?
I'm afraid what this ticket proposes (ignore deprecated statements) is not exactly what I would expect. I mean, it's a good first step no matter what. But ranks are meant to have an other step: if there is any preferred statement, the normal ones get also ignored. This concept is called "best statements". I think it should also apply here, for consistency.
Comment Actions
I don’t think the “best statement” interpretation makes sense for property constraints. Constraint statements don’t hold a list of values of the same kind, of which one is (in whatever way) determined to be the best; they define special characteristics of a property, which are mainly identified by the constraint type, and the fact that they’re all statements of a single “property constraint” property is mainly a technical detail of the encoding IMHO. I don’t see why it would make sense not to check a “single value” constraint just because there is a “format” constraint with preferred rank. And if you take constraint scope into account as well, I think this interpretation gets even stranger.
Comment Actions
I missed the fact that all constraints share the same property, but are mostly unrelated to each other. I think you are right: why should a preferred constraint disable all normal ones, when the preferred one is not a replacement for the others?
Let's go with the current solution and think about the (currently unspecified) meaning of preferred constraint statements later.
Comment Actions
Change 403641 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Ignore deprecated constraints
Comment Actions
Thanks for implementing this. What's left is updating https://www.wikidata.org/wiki/Module:Property_documentation to make use of the deprecated rank. Left a message about that on https://www.wikidata.org/wiki/Template_talk:Property_documentation#Handle_property_constraint_with_rank_deprecated
Comment Actions
We also need to update Help:Property constraints portal. But I would’ve waited with that until the code to ignore deprecated constraints is actually deployed (hopefully next Wednesday).