We still need to tweak it a bit here and there, yeah. We're working on that right now. Also it will get smarter as more statements are added to items.

On Tue, Jul 1, 2014 at 9:52 PM, Derric Atzrott <datzrott(a)alizeepathology.com> wrote: \o/ We've just changed the threshold a bit so it should give less but more fitting suggestions. We'll play around with that setting a bit more over the next days to find the one that's right for us. It basically creates a table of correlations for properties over all items in Wikidata. So if say date of birth and place of birth are used together a lot they get a high correlation. When you then have an item with no place of birth but a date of birth it will suggest that because of the high correlation. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

On 01/07/14 22:00, Lydia Pintscher wrote: ... Oh! I have a suggestion to make ... Looking at properties that co-occur is good, but for P31 and P279, you must use the values instead (assuming that you can cope with the size: there are about 20k different values for these properties right now; seems doable). It does not tell you much if an item has "instance of" (P31), but it is very informative to know that you have "instance of: historic house museum". If you look at Q4810979, you can see that it really has no property that suggests that we are looking at an historic building: instance of, Commons category, coordinate location, country, Freebase identifier, image. Based on properties alone, this could really be anything, including a person. Note that even the new suggestions seem to miss most of the "typical" properties that I listed in my other email ("English Heritage list number" being the most obvious one for Q4810979). My algorithm uses values of P31 as its main information. Maybe this is why it performs better at first sight. Should be fixable with some feature engineering using the infrastructure you have now (where I trust that your recommender system backend has no problem with a slightly bigger number of features).

(2) "Grade I listed building" http://tools.wmflabs.org/wikidata-exports/miga/?classes#_cat=Classes/Id=Q15… Related properties: English Heritage list number, masts, Minor Planet Center observatory code, home port, coordinate location, OS grid reference, mother house, architect, manager/director, Emporis ID, MusicBrainz place ID, country, architectural style, visitors per year, Commons category, Structurae ID (structure), officially opened by, floors above ground, inspired by, religious order, number of platforms, street, owned by, diocese These are computed fully automatically from the data, with no manual filtering or user input. But don't get me wrong -- great work! Brilliant to have such a thing integrated into the UI. In any case, my algorithm for computing the related properties is certainly very different from theirs; I am sure it also has its glitches.

Markus, could your algorithm work together with human direction? Like, if we entered which properties are common for a class, and then a user creates an instance of that class, would the algorithm be able to sort those properties based on how often they appear on the database?

Thanks, Micru On Tue, Jul 1, 2014 at 10:23 PM, Markus Krötzsch &lt;markus(a)semantic-mediawiki.org <mailto:markus@semantic-mediawiki.org>> wrote: On 01/07/14 22:14, Markus Krötzsch wrote: ... (2) "Grade I listed building" http://tools.wmflabs.org/__wikidata-exports/miga/?__classes#_cat=Classes/Id… <http://tools.wmflabs.org/wikidata-exports/miga/?classes#_cat=Classes/Id=Q15700818> Related properties: English Heritage list number, masts, Minor Planet Center observatory code, home port, coordinate location, OS grid reference, mother house, architect, manager/director, Emporis ID, MusicBrainz place ID, country, architectural style, visitors per year, Commons category, Structurae ID (structure), officially opened by, floors above ground, inspired by, religious order, number of platforms, street, owned by, diocese These are computed fully automatically from the data, with no manual filtering or user input. But don't get me wrong -- great work! Brilliant to have such a thing integrated into the UI. In any case, my algorithm for computing the related properties is certainly very different from theirs; I am sure it also has its glitches. P.S. One weakness of my algorithm you can already see: it has troubles estimating the relevance of very rare properties, such as "Minor Planet Center observatory code" above. A single wrong annotation may then lead to wrong suggestions. Also, it seems from my list under (2) that some Grade I listed buildings are ships. This seems to be an error that is amplified by the fact that property "masts" is used only 11 times in the dataset I evaluated (last week's data). I guess the new property suggester rather errs on the other side, being tricked into suggesting very frequent properties even in places that don't need them. -- Markus _________________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> https://lists.wikimedia.org/__mailman/listinfo/wikidata-l <https://lists.wikimedia.org/mailman/listinfo/wikidata-l> -- Etiamsi omnes, ego non

P.S. One weakness of my algorithm you can already see: it has troubles estimating the relevance of very rare properties, such as "Minor Planet Center observatory code" above. A single wrong annotation may then lead to wrong suggestions. Also, it seems from my list under (2) that some Grade I listed buildings are ships. This seems to be an error that is amplified by the fact that property "masts" is used only 11 times in the dataset I evaluated (last week's data). I guess the new property suggester rather errs on the other side, being tricked into suggesting very frequent properties even in places that don't need them.

My hope is that with my other suggestion (using P31 values as features to correlate with), the property suggester will already be able to outperform my little toy algorithm anyway. One could also combine the two (my algorithm is really simple [1]), but maybe this is not needed.

I guess the new property suggester rather errs on the other side, being tricked into suggesting very frequent properties even in places that don't need them.

Hi Lydia, Two questions: * Is it possible to see if an added statement was suggested to the user?

* * Do you have some kind of versioning for the UI, to see if features you add have a positive effect on the way Wikidata is used?

I'm not familiar with the tag system, but it looks like it can be exploited to see where the users edit Wikidata. I can see edits made with the wikidata game or other tools from Magnus have a "Widar[1.3]" Tag, maybe this should be splitted into one tag for each application.

* Can you send a link to the thesis you mentioned?