[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Page MenuHomePhabricator

Inform users about constraint violation
Closed, ResolvedPublic

Description

Background

Properties may have 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), but 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. Note that because properties reside on wikidata their constraints are defined on wikidata.

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

How to test locally

  • make sure you have federation set up locally
  • install WikibaseQualityConstraints
  • run maintenance/ImportConstraintEntities.php --wiki wikidatawiki and copy and paste the output into LocalSettings.php (assuming that your local wikidata's database is called wikidatawiki) ... note that the output you paste into LocalSettings needs to be accessible to all wikis and not just wikidatawiki
  • add constraints to a property on your local wikidata - have a look at https://www.wikidata.org/wiki/Property:P21 for an example
  • run maintenance/ImportConstraintStatements.php --wiki wikidatawiki to import the constraints you've just added into the db
  • go to a File page on local commons, and add some values that violate your constraint (top-level and qualifier) - you should see messaging to let you know about the violations
  • note that constraint checks are run if and only if you are logged in (same as on wikidata)

COVID-19 Deployment Criteria

  • Can you roll back this change without lasting impact?
    1. A recovery plan is required as this will help identify our capacity for recovering from the failure
    2. THIS IS A KEY QUESTION, if you can’t answer it, you shouldn’t deploy
  • Is specialized knowledge required to support this change in production? If so, are there multiple people with this knowledge?
  • Is there a way to increase confidence about the correctness of this change?
    1. Reviews (Design, Code, etc)
    2. Testing coverage (unit tests, integration tests)
    3. Manual testing (e.g. Beta, vagrant, docker)

Event Timeline

Where do you plan to store the constraints? Currently the constraints are on Wikidata on the properties.

Where do you plan to store the constraints? Currently the constraints are on Wikidata on the properties.

I assume we'd test for constraint violation when a new value for a given property is submitted by using the appropriate API action, and wouldn't keep track of the constraints ourselves. We'd just check against what was defined on Wikidata.

However, if a value is saved that violates a property's constraints, we probably want to ensure that other users can see the warning message in their appropriate language prior to editing (and possibly without any reliance on JS at all).

Where do you plan to store the constraints? Currently the constraints are on Wikidata on the properties.

I assume we'd test for constraint violation when a new value for a given property is submitted by using the appropriate API action, and wouldn't keep track of the constraints ourselves. We'd just check against what was defined on Wikidata.

Currently constraints are defined on properties on Wikidata, for example for creator at https://www.wikidata.org/wiki/Property:P170 .

However, if a value is saved that violates a property's constraints, we probably want to ensure that other users can see the warning message in their appropriate language prior to editing (and possibly without any reliance on JS at all).

This assumes that constraints for Wikidata are the same as constraints as for Commons. I don't think this assumption will hold. For example on Commons we currently don't add P31 (instance of) yet. So every item with a creator will get a constraint violation. See for example https://commons.wikimedia.org/w/index.php?title=File%3ATerWorm.jpg&type=revision&diff=374654987&oldid=365995523
Reminds me of something else, do we already have a task to add support for "somevalue" in the interface? We've been using it quite a bit already.

This assumes that constraints for Wikidata are the same as constraints as for Commons. I don't think this assumption will hold. For example on Commons we currently don't add P31 (instance of) yet. So every item with a creator will get a constraint violation. See for example https://commons.wikimedia.org/w/index.php?title=File%3ATerWorm.jpg&type=revision&diff=374654987&oldid=365995523

Good point, I'm not sure exactly how we should handle things if properties have a different set of constraints when used on Commons. We might need to answer that question before we can move forward with this task (though the design work can probably proceed regardless).

Also, I see that there is some discussion about constraints here: https://phabricator.wikimedia.org/T230314 – maybe this ticket should be rolled into that one.

Reminds me of something else, do we already have a task to add support for "somevalue" in the interface? We've been using it quite a bit already.

I didn't see an existing task here so I created one: https://phabricator.wikimedia.org/T239172

Not sure where it will fall in the team's current priorities but it's something we're aware of.

On the technical side, we need to make some kind of API call during the submission step that will test against a given property's constraints.

Note: currently, WikibaseQualityConstraints only supports checking constraints on saved statements, so you would make the API call after saving the new statement. (The task for checking constraints before saving statements is T168626.)

Change 574005 had a related patch set uploaded (by Cparle; owner: Cparle):
[mediawiki/extensions/WikibaseMediaInfo@master] Work in progress

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

Change 574005 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Display constraint violations on File page

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

Ramsey-WMF added subscribers: Cparle, Ramsey-WMF.

This should be testable on Beta Commons

Cparle added a subscriber: Etonkovidova.

Not working on beta because of an issue with interwiki lookups

Change 583080 had a related patch set uploaded (by Cparle; owner: Cparle):
[mediawiki/extensions/WikibaseQualityConstraints@master] ATM the only way to get a link to a federated property is via 'Special:EntityPage'. Because this is a special page it has namespace == -1, and therefore there is no way to determine its Talk page. Work around this by using the federated Property page for the "discuss" link instead

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

Change 583080 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Handle linking to federated props in constraint violation

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

Change 583918 had a related patch set uploaded (by Cparle; owner: Cparle):
[mediawiki/extensions/WikibaseQualityConstraints@master] Temporary debugging patch

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

Change 583918 abandoned by Cparle:
Temporary debugging patch

Reason:
Figured it out, I think

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

Change 583932 had a related patch set uploaded (by Cparle; owner: Cparle):
[mediawiki/extensions/WikibaseQualityConstraints@master] Allow load of constraints js on File pages with MediaInfo installed

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

Change 583932 abandoned by Cparle:
Allow load of constraints js on File pages with MediaInfo installed

Reason:
Thought of a better way to do this

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

Change 583959 had a related patch set uploaded (by Cparle; owner: Cparle):
[mediawiki/extensions/WikibaseMediaInfo@master] Load constraints js here rather than in constraints extension

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

One issue I noticed with the current implementation: almost the whole content of the constraints widget is bold, because the whole thing is a descendant of an <h4> element (the label of the value).

Screenshot_2020-03-27 File Thonk png - wiki1.png (541×437 px, 38 KB)

I think one solution would be to use OOUI’s overlay mechanism to move the popup somewhere else in the DOM, where it won’t inherit the h4 styles. This seems to do the trick:

diff --git a/resources/statements/ConstraintsReportHandlerElement.js b/resources/statements/ConstraintsReportHandlerElement.js
index 9cc2851..e9d10a5 100644
--- a/resources/statements/ConstraintsReportHandlerElement.js
+++ b/resources/statements/ConstraintsReportHandlerElement.js
@@ -131,7 +131,8 @@ ConstraintsReportHandlerElement.prototype.createPopupWidget = function ( $conten
 			padded: true,
 			head: true,
 			label: $content.find( '.wbqc-reports:first-child > .oo-ui-labelElement-label *' ).detach()
-		}
+		},
+		$overlay: true
 	} );
 	widget.popup.$element.css( 'z-index', 2 );

This also allows the popup to break out of the surrounding “structured data” panel (you’ll notice it wasn’t centered on the button before).

Screenshot from 2020-03-27 16-49-03.png (739×530 px, 71 KB)

Change 583959 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Load constraints js here rather than in constraints extension

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

Change 584565 had a related patch set uploaded (by Cparle; owner: Cparle):
[mediawiki/extensions/WikibaseMediaInfo@master] Styling fixes for constraints

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

Change 583992 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseMediaInfo@master] Move constraints popup to OOUI overlay

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

Sorry, looks like I’d forgotten to add a Bug: line to that ^ change.

Change 583992 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Move constraints popup to OOUI overlay

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

Change 584565 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Styling fixes for constraints

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

Closing this one but T251178 still needs to be addressed (thankfully, it's fairly minor)