Page MenuHomePhabricator

Store accepted depict suggestions in the database
Closed, ResolvedPublicFeature

Description

Feature summary

We need to store suggestions that have been accepted by the user in the ISA database.
For this initial version of the feature, we only need to keep a record of Google Vision suggestions (already implemented) that have been "accepted". However, the next iteration of the feature will require us to also store:

  • Rejected suggestions
  • Metadata-to-Concept module suggestions

A suggestion is "accepted" when the user adds a depict statement with the same Wikidata Q number as one of the suggestions presented in the UI.

NOTE: A suggestion will be considered as accepted even if the user adds it manually. So they do not have to specifically click on suggestion tag.

Uses

The main uses of this feature will be:

  • Analysing the performance of the automated suggestions
  • Reporting back to the suggestion services which statements where accepted/rejected
  • Not displaying rejected statements (for this one we need to make sure the solution used allows us to quickly and cheaply query for "rejected statements for image X" as this will need to be completed when the user lands on an image)

Technical info

Database

It seems the best approach would be to create a new table for storing suggestions, e.g.

idcampaign_idfiledepict_itemstatus

Where:
campaign_id = campaign in which the suggestion was presented
file = filename of the image which the suggestion is for
depict_item = the Wikidata item of the suggestion depict value
status = "accepted" or "rejected" (or perhaps better to use integer codes instead? 0=rejected, 1=accepted)

NOTE: For performance it might be worth considering storing rejected/accepted statements in the Images table instead of making a new table, as this must be accessed anyway to load an image.

Front end

We need to add a key to the object used in the postContribution method.
For this iteration, we only need to add:
"googleVisionSuggestion": true/false
Where this is determined in the front end by comparing the depict values to the list of suggestions.

Later, we can add another service (e.g. conceptToImageSuggestion = true/false

Event Timeline

NavinoEvans updated the task description. (Show Details)

Is rejected the opposite to or lack of accepted? It sounds like there are only the two states which assumes that the user not doing anything would count as rejecting. There may be situations where they're unsure if a suggestion is correct and therefore don't accept.

No, the plan was to have a specific mechanism for rejecting a statement although there is nothing in the UI yet for the initial test version. It should be something like a 🚫 icon on the actual suggestion.

So if a user simply ignores a suggestion it remains visible to subsequent editors who land on the same image. But if they specifically reject it then it should be removed from future suggestions. This is the most crucial part of the feature for informing the architecture we choose, as we would need to query for rejections when landing on any image that has suggestions available.

perhaps better to use integer codes instead? 0=rejected, 1=accepted)

Or possibly a boolean option?

perhaps better to use integer codes instead? 0=rejected, 1=accepted)

Or possibly a boolean option?

We may end up with other statuses in future too, e.g. "ignored" so best to keep it more flexible for now I think.

I just realised I forgot something in the plan above. We also need to store which service the suggestion came from ("Google Vision" or "Metadata-to-Concept Module")

Do you think it's best to include each service as a separate Boolean column?

e.g.

....GoogleVisionMetadataToConcept

@NavinoEvans Does the above suggested procedure mean both can be stored in an example case?

NavinoEvans moved this task from Review to In progress on the ISA board.