Ignore deprecated constraints in constraint tool
Closed, ResolvedPublic

Description

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).

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 18 2017, 1:07 PM

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?

I think it should just support the ranks, that's what people expect how it should work.

Change 403641 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Ignore deprecated constraints

https://gerrit.wikimedia.org/r/403641

thiemowmde triaged this task as Normal priority.Jan 11 2018, 3:28 PM

@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.

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.

thiemowmde closed this task as Resolved.Jan 12 2018, 9:34 AM
thiemowmde moved this task from Review to Done on the Wikidata-Sprint-2018-01-03 board.
thiemowmde assigned this task to Lucas_Werkmeister_WMDE.

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.

thiemowmde moved this task from incoming to in progress on the Wikidata board.Jan 12 2018, 9:34 AM

Change 403641 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Ignore deprecated constraints

https://gerrit.wikimedia.org/r/403641

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).