Apps-android-commons: 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:

• [x] Before starting, need to fix #823 (If not already fixed)
• [x] Overhaul the item view UI in Nearby map and list #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.
• [x] Implement upload button, making sure to check for necessary permissions and to allow the user to select Camera or Gallery
• [x] Prefill image title in ShareActivity with the Wikidata item's title and desc
• [x] Add category suggestions based on the categories associated with the Wikidata item
• [x] Edit P18 property in Wikidata to add the uploaded image
• [x] Log P18 edits #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.

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

[VojtechDostal]

I'm no expert in anything like this but what about just inserting a simple template like this:

{{description from wikidata|Q42}}

We can then tweak the description template any way we like and the whole thing will be much more flexible. As content in Wikidata grows, the content generated from the template will get better and better. @tobias47n9e ?

[psh]

Given that people might skip tapping the "use suggested title and description" button, how would you feel if the app simply pulled that data automatically and then allowed the user to change it if they wanted to? (Similarly, with the categories) I'd hate for good data to go to waste because of a forgotten button click.

[misaochan]

Given that people might skip tapping the "use suggested title and description" button, how would you feel if the app simply pulled that data automatically and then allowed the user to change it if they wanted to? (Similarly, with the categories) I'd hate for good data to go to waste because of a forgotten button click.

Great idea IMO! Pre-filling the title and desc fields would also save the user an extra tap. It does make things a bit more difficult for anyone who would have preferred to enter their own (as they would need to delete the pre-filled ones), but if they were submitting the image via Nearby, I think it's unlikely they would want to change the title and desc significantly anyway.

I would like to switch to this and drop the "use suggested title and description" button if others agree.

[nicolas-raoul]

I totally agree with pre-filling.
People who want to prepend their own before the generated part of the string.
Anyway, if the generated "Castle in Malta, built in 1541 by Gianno Frangipani" is not a good description for the item, then it is a sign that the picture is not a good P18 image for that item.

Allowing friendly multilingual is a great idea, but I suggest leaving that for a subsequent phase because:

• Creating a multilingual UI would take more time. Alternatively, putting template code in the text field is not user-friendly and people who are not used to wikicode (think of people who use the VisualEditor when editing Wikipedia, or do not edit Wikipedia at all) have high chances of breaking the template.
• What would you think if some description in a language you don't understand is submitted in your name, as if it were you that had written it? While you can check a description written in your default language, you will not be able to detect mistakes (or even vandalism) in many other languages, thus propagating false information. This would need some more thinking, so better not delay phase 1 with that.

For reasons a bit similar to what I said in the second bullet, I am not sure about the {{description from wikidata|Q42}} idea either: What if in the future the description changes in a way that makes it not describe the picture correctly anymore? A lot of Wikidata items have differently-focused articles in each Wikipedia, for instance many "Embassy of X in Y" items are linked to a "list of embassadors of X in Y" items in other languages because it is the closest thing available and most people thing a wikilink is desirable, even though it is not an exact concept match. Embedding the template means that your picture of an embassy might become labeled "List of embassadors" in the future when the item gets split or when someone tries to harmonize descriptions.

[VojtechDostal]

Good point @nicolas-raoul

[misaochan]

Been thinking about how to implement and test the p18 edits. There are bound to be some problems when testing at the start, and it surely wouldn't endear us to the community if we vandalized some of the Wikidata listings during development... is there a "Wikidata beta" server that we can use as a sandbox for development, much like our current Commons beta server uploads? @nicolas-raoul @whym @VojtechDostal any ideas?

[nicolas-raoul]

This sandbox item is yours: https://www.wikidata.org/wiki/Q13406268
Feel free to set its coordinates to it as you see fit. I just deleted its P18.
This one exists too: https://www.wikidata.org/wiki/Q4115189

[misaochan]

Thanks @nicolas-raoul ! It'll be a while before we get there, but good to know we have those ready for testing. :)

[whym]

There is also test.wikidata.org. The "image" property is P185 there, so a little modification will be necessary, though. (And since there is not may items on test.wikidata.org, you'll probably need to add a lot of items to get a meaningful list of places.)

[misaochan]

@nicolas-raoul @whym @tobias47n9e I'm currently trying to query for the Commons categories associated with the Wikidata item (to display category suggestions). I am rather inexperienced with SPARQL/Wikidata, so my attempt ends up with Unknown error: com.bigdata.rwstore.sector.MemoryManagerOutOfMemory when I run it on the Wikidata query service.

This is my current query. It's basically the query from nearby_query.rq in the app, with the location and language hardcoded, and the addition of OPTIONAL { ?sitelink wdt:P373 ?Commons_category. } (which is what I thought I should do to get the categories).

Any idea why I'm getting this error, or what the appropriate query should be?

[nicolas-raoul]

This query seems to work better.
I removed the Commons article but feel free to reintroduce it if it is actually used.

[misaochan]

Thanks so much @nicolas-raoul ! :)

[misaochan]

A general question: Does anyone know of a geolocated Wikidata item that has more than 1 Commons category associated with it? I have not been able to find one - even searching in an extremely popular location (e.g. heart of Sydney) does not turn up any. Are items just restricted to 1 category each, or is it possible but extremely rare to have more than 1?

I have the rudimentary code set up for retrieving the category now, but can't generalize it to work with more than 1 category without an example to test on.

[nicolas-raoul]

This query will give you some for your tests:
https://query.wikidata.org/#SELECT%20%3Fitem%20%3Fc1%20%3Fc2%20WHERE%20%7B%0A%20%20%3Fitem%20wdt%3AP373%20%3Fc1.%0A%20%20%3Fitem%20wdt%3AP373%20%3Fc2.%0A%20%20FILTER%28%3Fc1%20%21%3D%20%3Fc2%29.%20%0A%7D%0ALIMIT%2010

[nicolas-raoul]

I just found out that a Wikidata item should not contain more than one category:
For more info, see the "single value constraint" constraint at https://www.wikidata.org/wiki/Property:P373

This constraint is not being enforced in the UI, which means that newcomers keep adding categories and janitors keep removing them.

So, if you have not implemented it already, feel free to not handle the case where more than one category is available, or use only the first one. Well, using them all would be fine too, I guess.

[misaochan]

Oh, good to know! No, it hasn't been implemented yet. :)

[VojtechDostal]

In fact it would be cool if we could read Commons categories from sitelinks too, right?

Sometimes these are not linked via p373...
http://tinyurl.com/ya9f2z4t

[misaochan]

@VojtechDostal Interesting, I wonder why not? Is this a frequent occurrence, or is it rare?

[VojtechDostal]

Actually there are only 3043 geocoordinated items like that, so I'm withdrawing that idea :-)

http://tinyurl.com/y7gpj5hu

[misaochan]

Added some steps to the checklist based on where we currently are. I think we should probably try to release this feature once we complete the steps listed in the first checklist. Then users can use the feature and report bugs while we work on the P18 edits and logging.

[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: https://github.com/Wikidata/Wikidata-Toolkit/issues/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.