Upload a picture directly from list of nearby places needing photos

[misaochan]

Update: This is in the IEG renewal and work will begin on it shortly. I have edited the opening post to add the scope and use case. Also making a list of steps as this is a pretty long and involved task.

Use case:
The current process of contributing images for nearby places that need pictures is rather cumbersome. The user would have to go to the list or map of nearby places, and after finding a location that they want to photograph based on that, they would need to go back to the main screen of the app and submit their image via the standard upload process. None of the wealth of information available in the Wikidata item for that location is utilized in the upload process.

Scope:
We intend to implement direct uploads, where the process would be:

• When the user selects an item on the nearby list or map, there would be an option for them to upload a picture for that item. They can choose camera or gallery as usual.
• After a picture has been taken (camera) or selected (gallery), they would be taken to the title & description screen as usual. This screen would have an option for "use suggested title and description" which would fill in the fields with the title and description of the Wikidata item (the user will still be able to edit them).
• In the Categories screen, category suggestions would be offered based on the categories associated with the Wikidata item (in addition to other category suggestions).
• After a successfully uploaded picture, the app would add the image to the Wikidata item by editing the P18 property. This action will be logged for collecting metrics, as well as to confirm that we are doing it correctly.

Steps:

• Before starting, need to fix Nearby item descriptions not working in v2.5.0 (beta) #823 (If not already fixed)
• Overhaul the item view UI in Nearby map and list Develop new UI for Nearby item view pane, to include Upload option #922 . We need to think about where the "upload image for this item" button will be, and in the process figure out if the existing one needs to be overhauled.
• Implement upload button, making sure to check for necessary permissions and to allow the user to select Camera or Gallery
• Prefill image title in ShareActivity with the Wikidata item's title and desc
• Add category suggestions based on the categories associated with the Wikidata item
• Edit P18 property in Wikidata to add the uploaded image
• Log P18 edits Log P18 edits after direct Nearby uploads implemented #923 (need to talk about how and where to log)

[nicolas-raoul]

Great idea!
Sounds feasible I would say :-)

[nicolas-raoul]

For both list and map, ideally.

[misaochan]

Adding this to the renewal proposal:

• When user selects an item on the nearby list or map, there could be an option for them to upload a picture for that item. They can choose camera or gallery to take the picture.
• After a picture has been taken or selected, they could be taken to title/desc screen. Title/desc screen could have an option for "use suggested title and description" which would fill in the fields with the title and description of the Wikidata item
• Category suggestions could be offered based on the categories associated with the Wikidata item (in addition to other category suggestions)

A few questions

1. Would it be a good idea as well to include a link to editing the Wikipedia article after the user has uploaded a pic for an item (along with brief instructions for how to add the image to the article)? We could see if the Wikipedia app allows us to do that, or otherwise link to the web view. Not sure if this is a good idea though, if it leads to vandalism. :/

2. I don't think the results of the Nearby query will be updated immediately after the user has uploaded a pic (actually, when ARE they updated?). So users might feel like they "didn't make a difference", since they uploaded a pic already but the location is still showing up as "needing photos". How do we prevent that? Or is this not really a problem and I'm overthinking it? :)

[nicolas-raoul]

1: Great idea! I am sure that people who are actually at that place (GPS) have much lower chances of being vandals than people hiding somewhere on the Internet.
2. Wikidata is real-time, if you add a picture and run the query immediately after then the added picture will be taken into account.

[VojtechDostal]

1. It is a good idea.... but it has a lot of associated problems that we would need to solve. For example, which Wikipedia language version will you direct the user to? Will they be logged in to Wikipedia automatically? Quick difficult. Maybe easier to make the user (or the app itself) edit Wikidata which does not have language editions, see my answer at "2".

2. picture must be added to the corresponding Wikidata item via the P18 (image) property. So if you want the pins to disappear after the upload, you need to make sure the app edits the item and adds the name of the picture in it.

[nicolas-raoul]

@VojtechDostal
1: I personally don't see these as big problems. Get the Wikipedia page in the user's language, and don't show the link if no such article exists. Since their browser will open, they will not be logged in, they can log in or edit as IP, no trouble. Showing the Wikidata is another option, but less understandable for casual users.
2: Indeed, I take it as granted that the app should set P18. We can steal the code from https://tools.wmflabs.org/wikishootme

[VojtechDostal]

We should definitely monitor the Wikidata items where P18 was set. At least in the beginning, we want to ensure we are not creating chaos in Wikidata :)

[misaochan]

Awesome, thanks guys. Will add to proposal draft.

[misaochan]

I've been thinking about the P18 modification and have a couple of concerns:

1. Do we really want to modify P18 (which will take a location off the Nearby list if I understand correctly) when only 1 image has been submitted, and we don't know the actual relevance or quality of the image?
2. Will that lead to the number of Nearby places dropping off very quickly? I imagine that especially in densely populated cities, very soon people will find that there are no more nearby places that could do with pictures. Even though those places actually could still do with pictures, since they might only have 1 image or no good-quality images.

[nicolas-raoul]

1. As a long-time Wikidata user who spends a lot of time adding images, I can say that for P18, any image is better than nothing. If only a blurry picture of that building is available, then we will use that blurry picture. The uploader probably knows the relevance of the picture better than anyone who will stumble upon that item's Wikidata page in the next 5 years.
2. I would love that number to drop that quickly, but the sad reality is that it will probably takes years before the number of missing pictures is halved. For a few years I have used WikiShootMe! (and its predecessor before that) and add pictures every week, but still it seems like I will never manage to fill my neighbourhood, nevermind the whole city. That being said, we can start thinking about it Nearby items lacking a "good" picture #741

[VojtechDostal]

Great questions Josephine. I agree with Nicolas.

[misaochan]

Ah, good points, thanks. I wonder if we should add this as a measure of success, then - something like a 10% reduction in Wikidata places with p18 not set, maybe? Is there an easy way of measuring that, and would it be a reasonably reliable measure (for instance, if the number just fluctuates wildly every year, it wouldn't be a reliable measure)?

[VojtechDostal]

Achieving such decrease through our app would be huge but I don't think it's achievable in short-term. There are millions items in need of a picture (and hundreds of thousands are geocoordinated so that they appear in our app) so 10% would probably amount to hundreds/tens of thousands of uploaded pictures. I think even 1000-2000 Wikidata P18 edits would be a huge success in one year's time (that's about 3-6 P18 edits per day!), but even 500 would still be a success.

We should measure in absolute numbers as I suggest above. The current % number often goes up and down, especially when new geocoordinated items are added through mass data donations. It won't be difficult to get this metric in absolute numbers because we definitely need to track the edits somewhere - either by adding a qualifier to Wikidata (not sure if that would be by Wikidata's standards) or by logging it on an external page.

[misaochan]

Thanks @VojtechDostal . I agree, in that case using an absolute number would be best. The renewal can only be for 6 months though I think, so in that case we should probably aim for 500?

What do you guys think would be the best way to log the edits? @nicolas-raoul

[nicolas-raoul]

We have to ask (on project chat I guess) for a new tag: https://www.wikidata.org/wiki/Special:Tags
I guess it works just like the commons tag we already use.

[misaochan]

I've been writing the renewal proposal and thinking about one of the proposed improvements:

Would it be a good idea as well to include a link to editing the Wikipedia article after the user has uploaded a pic for an item (along with brief instructions for how to add the image to the article)? We could see if the Wikipedia app allows us to do that, or otherwise link to the web view. Not sure if this is a good idea though, if it leads to vandalism. :/

I actually think it might be a good idea to keep this for the 2018 proposal with WMCZ. What do you think guys? For the 2017 renewal it might be best to focus on the Wikidata edits first, and after we have successfully tracked those and concluded that it works well, then Wikipedia edits can be considered for 2018? (I'm also finding the time budget for the 2017 renewal a bit tough so am having to take 1 or 2 planned items out, haha)

[misaochan]

Updated opening post to add use case, scope, and steps. Feedback welcome!

Questions: Do we want to use Wikidata's description to allow the user to autofill the "Description" field with it? From what I've seen, Wikidata's descriptions are not very, uh, descriptive.

[nicolas-raoul]

As a pre-filled Commons description I would be in favour of:

• Using a description if there is one, even if very short
• Add automatically generated description from the item's statements, for instance "Castle in Malta, built in 1541 by Gianno Frangipani". I have seen such auto-generated descriptions in several places, I hope there is some code somewhere for us to steal. At least "instance of" is easy to use.

[VojtechDostal]

That would be really cool. As for descriptions, we can even do multilanguage descriptions eg. {{en|castle in Czechia}}{{cs|hrad v Česku}} - Wikimedia Commons supports that.

[misaochan]

@nicolas-raoul and @VojtechDostal sounds great! Do you guys know which other open-source programs do that? Would be good if we could "reuse" some parts of their code, haha.

[misaochan]

@nicolas-raoul @VojtechDostal I've been thinking about how to do the P18 edits - I think the API we are using currently is solely for querying (query.wikidata.org/sparql) and cannot be used for editing Wikidata, right?

What about a tool like AutoList that was described here: http://magnusmanske.de/wordpress/?p=128 ? It seems that with the AutoList tool, we can "claim" a property-value set to modify. However, I haven't found an API yet to replace the web interface.

Or is there a much more obvious solution that I'm missing?

[VojtechDostal]

IMO the Wikibase API is just for that. https://www.mediawiki.org/wiki/Wikibase/API

[misaochan]

Thanks @VojtechDostal !

[nicolas-raoul]

At that page "Add a claim with a string data value" sounds like the most appropriate method :-)

[maskaravivek]

The Wikibase API at first look is very intimidating. From what I could gather from the above discussions and as @nicolas-raoul points out, we need to "Add a claim with a string data value".

This means editing the P18 property for it and setting the uploaded image link as the value.

@nicolas-raoul @VojtechDostal please correct me if my understanding is wrong. :)

[nicolas-raoul]

Not sure that helps, but Wikishootme adds an image to an item like this in PHP:

function addImageToItem ( $q , $image ) {
        global $out ;
        $image = ucfirst ( trim ( str_replace ( '_' , ' ' , $image ) ) ) ;
        $oa = new MW_OAuth ( 'wikishootme' , 'wikidata' , 'wikidata' ) ;
        $claim = array (
                "prop" => "P18" ,
                "text" => $image ,
                "q" => $q ,
                "type" => "string"
        ) ;
        $out['claim'] = $claim ;
        if ( $oa->setClaim ( $claim ) ) {
        } else {
                $out['error'] = $oa->error ;
        }
        $out['res'] = $oa->last_res ;
}

I wonder whether a similar Java non-OAuth library exists. Probably not, actually.

[nicolas-raoul]

I have found https://www.mediawiki.org/wiki/Wikidata_Toolkit , a Wikidata/Wikibase Java library for bots and other non-user actors (ie not OAuth).
While it might sound overkill for just one operation, I would say we should use it because:

• Commons is migrating to Wikibase, so in the future we will have to migrate most of our API calls to Wikibase.
• This library is developed by WMF, it is an official project, so it is less likely to get abandoned (people who know the our app's history might laugh at me here ^^)

Adding statements to an entity:
https://github.com/Wikidata/Wikidata-Toolkit-Examples/blob/master/src/examples/EditOnlineDataExample.java#L141

[psh]

Have you tried using the toolkit on Android? I have some concerns that there are libraries that might not be compatible - valid choices for desktop / server use but not conducive to mobile usage. Also noticed (in the "release notes" for WDTK)

Compatibility with JDK 9

Android hasn't made it to version 9 yet.

[nicolas-raoul]

@psh I haven't seen anything saying that it is usable on Android, indeed.
I just asked: Wikidata-Toolkit/Wikidata-Toolkit#356

[misaochan]

@maskaravivek I've been looking through the API and that looks right to me, too. My guess is that we would do something like this:

	'action' => 'wbcreateclaim',
	'entity' => '[our entity]',
	'property' => 'P18',
	'snaktype' => 'value',
	'value' => '"[Filename]"'

Also, for Filename I think you will likely need to check for the actual filename, not the title the user inputs. As currently we increment filenames if we find a duplicate, so title alone is not enough.

However, I am new to this API too. @tobias47n9e and @whym , any chance you guys can help us? :)

[maskaravivek]

Guys am stuck at making the wiki data edit from the app. Am able to make the edit using the API sandbox:
https://www.wikidata.org/wiki/Special:ApiSandbox#action=wbcreateclaim&format=json&entity=Q13406268&snaktype=value&property=P18&value=%22Ada%20lovelace.jpg%22&token=%2B%5C

The above works perfectly and I am able to see the P18 property added to the entity as expected.
https://www.wikidata.org/wiki/Q13406268

Am stuck at doing the same thing from the app. Our App doesn't use any of the wikidata APIs as of now. To make the edit I need the edittoken. The edittoken for wikidata and mediawiki would be different. How can I obtain the edit token for wikidata?

• Should I be logging in the user to wikidata as well?
  -Are anonymous edits allowed in wikidata?

[VojtechDostal]

Anonymous edits are allowed. Would you like me to ask the Wikidata team at Wikimedia Deutschland to maybe help you? They offered us their help when I talked to some of them during Wikimedia Conference.

[misaochan]

@VojtechDostal That would be wonderful if possible, thanks! :)

[maskaravivek]

Any help on making wikidata edits work would be great @VojtechDostal.

@nicolas-raoul Do you have any idea if the central auth token is currently supported by our app or will we have to do some changes to make it work?

[psh]

I am making good progress in a rewrite of the API layer - building JsonMediaWikiApi - and been considering pushing it to a feature branch in our main repo so the rest of the team can get your hands on things.

There are still things to do to finish it, but I think the new code would very easily support coding queries to the WikiData API. Also, there's a method to get an edit token from the JSON wikimedia API :)

With a little effort it would be possible to split the underlying fluent API and data model out and build our own WikiData toolkit.

How do you feel about the feature branch approach?

[misaochan]

@psh Having the code in a feature branch sounds like a good idea to me. :)

[misaochan]

@nicolas-raoul @VojtechDostal I am trying to test #1495 , but first I need to remove the P18 claims on https://www.wikidata.org/wiki/Q13406268 , in order to start from scratch like a real user would. Trying to remove Example.png gives me the error:

Could not remove due to an error.
The save has failed.
Warning: The action you are about to take will remove a statement from this entity. In most cases, outdated statements should not be removed but a new statement should be added holding the current information. The old statement can be marked as deprecated instead.

Is there a better way to go about this?

[misaochan]

Weird, I just tried again and was able to remove it. :/ Sorry about that.

[maskaravivek]

@misaochan, In fact, every time I try to remove the image, it fails for the first time and works the second time. :D

[VojtechDostal]

Response I got from WMDE:

It would be great if Vivek could come to the Technical Advice IRC meeting - https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting - a weekly technical support office hour with our developers. I just talked to the Wikidata team: someone who could help him with that is going to host the meeting on Wed May 16, 5 pm our time zone :-) In general, Wikidata experts are hosting this meeting quite frequently (but not the one on Wed May 9).

Alternatively: If he or one of the people working on this is coming to the Hackathon, real life support would definitely be possible there!

If it can't wait until May 16, it might be worth posting on https://lists.wikimedia.org/pipermail/wikidata-tech/.

Does that sound reasonable? Hope it helps a bit.

[nicolas-raoul]

@maskaravivek Sorry I don't know anything about Wikidata authentication :-/ I would advise against anonymous edition because it would leak the user's IP address.

[maskaravivek]

@VojtechDostal Thanks a lot for reaching out to WMDE for help. I was able to figure out the authentication bit after @psh's comment. The PR is already up for review. #1495.

I have attached a video to show how the flow would look.

@nicolas-raoul Yes, I didn't do an anonymous edit. I was able to figure out the authentication. :)

[misaochan]

Thanks for the tip, @VojtechDostal ! Good to know about the wikidata-tech mailing list, we will post there if we have further questions. :)

[maskaravivek]

I was wrong in assuming that the edits are happening from the user account. Right now they are happening anonymously and as @nicolas-raoul pointed out, it would be leaking user's IP address.

I will try to attend this week's WMDE IRC meeting and ask them about the authentication. In the worst case will getting user consent before making wikidata edits be a good alternative? The consent would be one time and based on user's preference the edits can be made or else skipped.

[misaochan]

Thanks so much everyone! It seems our minimum viable product for P18 edits and logging is complete. :) Shall we merge the wikidataEdits branch into master now? After we have completed the other requirements at #1478 , we can push a beta release.