Extension:WikiGrok

WikiGrok prompts a user to confirm metadata information that will be eventually stored in Wikidata. The extension depends on the MobileFrontend extension and the UI part of it depends on the CentralAuth extension too. It is currently used for four discrete functions:
 * Generating Wikidata claim suggestions for Wikipedia pages (WikiGrok campaigns)
 * Recording responses from the WikiGrok interface (via wikigrokrespose API module)
 * Providing an API for retrieving random Wikipedia pages that have claim suggestions (via wikigrokrandom query generator)
 * Presenting a WikiGrok dialog to the user

Prototype user testing results
See Design/Research/Guerilla testing Wikigrok.

WikiGrok version A
WikiGrok version A is a simplified interface that only asks a single binary question (randomly selected from all claim possibilities for that item), for example, "Was Anne Dallas Dudley an insurance broker?" It offers three possible answers: 'Yes', 'No', and 'Not sure'. After the user answers the question, they are thanked for participating and can then dismiss the interface. Note that this version will be removed soon. The default version will be the version B below.

WikiGrok version B
Version B is a more complicated tagging interface. In this version the user is presented a random set of several possible metadata tags. The user is asked to select the correct tags and then submit them. After the user submits the tags, they are thanked for participating and can then dismiss the interface. The tags only have two possible states: selected and not selected. 'Not selected' is an ambiguous state, i.e. it can either mean that the user rejected the tag or that the user isn't sure the tags is correct.

WikiGrok version C
This version is similar to WikiGrok version B, except the dialog is fixed at the bottom of the page. Also, the user is able to get to this version by opening the navigation menu and clicking on 'Contribute'.

Vocabulary
Wikidata:Glossary is required reading to understand the rest of this documentation. Especially the entries on item, property, claim, label, and values.

Claim recording
Right now (during prototype testing) claims are recorded via EventLogging (and are not yet being pushed to Wikidata). This is handled by the wikigrokresponse API module provided by the WikiGrok Extension. The client-side code that interacts with that API is in the WikiGrokResponseApi JS class. Once we have selected a UI model to productize (A or B), we will probably switch to using a dedicated database table.

Pushing responses to Wikidata
Before we start pushing response data to Wikidata, we will be analyzing the quality of the responses along different axes: logged-in vs. anon, high edit count vs. low edit count, version A interface vs. version B interface, etc. We will then use that data to figure out how to maximize the quality of the data we push to Wikidata via a scoring system. For example, we could implement an algorithm that selects responses to push to Wikidata as so:

Single response score = ( 1 + logged-in modifier (0 or 1) + edit count modifier ( 1 − 1 / ( 1 + edit count ) ) )

Composite response score = sum of single response scores that agree with claim / total sum of single response scores (both that agree and disagree)

If number of responses > 1, and composite response score > 65%, then push response to Wikidata.

This is just one possible example.

Claim suggestions
WikiGrok analyses existing Wikidata content related to a page to generate cached lists of claim suggestions for each page. For example, if a page's Wikidata item indicates that the item is 'instance of human' and 'occupation writer', but not 'occupation author', it will add 'occupation author' as a claim suggestion for that page. The different types of claims that are possible to generate are defined as 'campaigns'. The campaign definitions are defined in the $wgWikiGrokSlowCampaigns global variable.

Criteria for campaigns
See Extension:Wikigrok/Claim_suggestions.

Local testing
To get WikiGrok to load locally, you have to do four things:
 * 1) Install the MobileFrontend, CentralAuth, and WikiGrok extensions
 * 2) Set   and    and   and      (This last setting is only needed for testing the version C.)
 * 3) Assign suggestions to the page in the database
 * 4) Assign a Wikidata item ID to the page using the query string

Assign a Wikidata item ID to the page using the query string

Assign suggestions to a page
First get the article id of the current page (use ) and in your LocalSettings copy the following: To assign suggestions to a page on your local wiki, you'll need to insert records into the wikigrok_questions table in your local database. Here's an example:

Change in the code above to the page ID of the page you want to test on. That will add two claim suggestions to the page: 'instance of live album' and 'instance of studio album'.

Verify by checking  has a value.

Assign a Wikidata item ID
You can manually assign any page a Wikidata item ID via the query string. Just append 'wikidataid=Q123' to the query string of the URL. It doesn't really matter what ID you assign, as long as you assign one.

You can manually assign any page a Wikidata item ID via the query string. Just append 'wikidataid=Q123' to the query string of the URL. It doesn't really matter what ID you assign, as long as you assign one.

You can manually assign any page a Wikidata item ID via the query string. Just append 'wikidataid=Q123' to the query string of the URL. It doesn't really matter what ID you assign, as long as you assign one.

Forcing a particular WikiGrok interface
You can force WikiGrok to load version A or version B by appending  or   to the query string of the URL. You can load the version C by setting the location hash to

Testing WikiGrok Roulette
In addition to the steps above, set  and. You should now see the 'Contribute' item in the main menu.