On 19/10/2018 07:09, Pine W wrote: You are right, and thankfully this is not what is proposed. The proposal was to offer people who search for Commons media the (maybe optional) possibility to find more results by letting the search engine traverse the "more-general-than" links stored in Wikidata. People have discovered cases where some of these links are not correct (surprise! it's a wiki ;-), and the suggestion was that such glitches would be fixed with higher priority if there would be an application relying on it. But even with some wrong links, the results a searcher would get would still include mostly useful hits. Also, at least half of the currently observed problems with this approach would lead to fewer results (e.g., dogs would be hard to include automatically to a search for all mammals), but in such cases the proposed extension would simply do what the baseline approach (ignoring the links) would do anyway, so service would not get any worse. Also, the manual workarounds suggested by some (adding "mammal" to all pictures of some "dog") would be compatible with this, so one could do both to improve search experience on both ends. Best regards, Markus

Hi Stas, Thanks for elaborating. I think we could always start with traversing only "subclass of". In spite of its limits, it does work in many areas (e.g. buildings, astronomical objects, vehicles, organisations, etc.), even if by far not in all. Where it doesn't work, one would simply not get enough results, but the alternative (do not even use "subclass of") will just make this problem worse. Any approach of fixing the latter will also help the former. Now regarding issues such as dog, woman, and many other things, it seems clear that what one would need are inference rules. It should be possible to say somewhere that a "if a human is female, then it is also woman" without having to add the unwanted statement "instance of woman" everywhere. Or "if someone has profession 'programmer' then he/she/they is/are a programmer" -- at least for the purpose of media search. The case of dogs would be complicated (referring to quantifiers) but still doable. Obvious questions arise: * Would we prefer to maintain such rules somewhere rather than adding the relations they might infer manually? (Probably yes, since one would need much fewer rules than manual statements, which would always add redundancy and cause conflicts -- cf. taxonomy modelling discussion -- that are not necessary when applications can select which inference rules to use without touching the underlying data.) * How would the rules look to human editors? (We have made some first proposals for this; see the rules supported by SQID [1]; but one can come up with other options) * Where would such rules be managed? (Preferably on Wikidata, but the encoding in statements would be a challenge; another challenge is how to associate rules with entities -- usually they make connections between several entities) * How would the rules be applied on the live data, especially if there are many updates? (Doable using known algorithms and based on existing tools, but still needs some implementation work; I think for a start one could just reduce the update speed on these "inferred tags" and still get a big improvement over the case where nothing of this type is done at all). So would this be a mid-term goal to overcome this issue? I would think so, also because there are enough degrees of freedom here to gradually grow this from simple (only allow rules that effectively add some more traversal hints) to powerful (have rules that can use qualifiers, as needed to get from dog to mammal). The main challenge is to find a good approach for community-editing this part without restricting upfront to a few special cases (as for the case of the constraints). Inference rules come up as potential solutions in many similar tasks where you want users to access/query the data. Imagine someone would look for the brothers of a person (let's assume we'd built an intelligent search for such things) -- again, Wikidata has no concept of "brother" and we would not have any idea how to answer this, unless somewhere we'd have a rule that defines how you can find brother-relationships from the data that we actually have. This happens a lot when you want users who are not familiar with how we organise data find things, but the solution cannot be to add every possible view/inferred statement to Wikidata explicitly. Obviously, the rule approach is not something we could deploy anytime soon, but it could be something to work towards ... Cheers, Markus [1] Example rule with explanation of how it was applied to find a grandfather of Ada Lovelace: https://tinyurl.com/y7rgmk7o The qualifier sets (X, Y, Z) are unused here and could be hidden entirely, but this is just a prototype. On 20/10/2018 00:28, Stas Malyshev wrote:

Hi! While I can not pretend to have expert knowledge and do not purport to interpret what Daniel meant, I think here we must remember that Wikipedia, while being of course of huge importance, is not the only Wikimedia project, so "start using it on Wikimedia projects" does not necessarily mean "start using it on Wikipedia", yet less "start adding bad information to Wikipedia" (there are other ways to use the data, including imperfect ontologies - e.g. for search, for bot guidance, for quality assurance and editor support, and many other ways) I am not prescribing a specific scenario here, just reminding that "using the ontology on wikimedia projects" can mean a wide variety of things. I am sure that would be a bad thing. But I don't think anything we are discussing here would lead to that happening. -- Stas Malyshev smalyshev(a)wikimedia.org

There is already stuffs to handle this kind of « mutex » on Wikidata : "disjoint union of", see for example in usage on htps:// www.wikidata.org/wiki/Q180323 . The statements are used on the talk page by templates that uses them to generate queries to find instances that violate the mutex : https://www.wikidata.org/wiki/Talk:Q180323 (for example This query <https://query.wikidata.org/#select%20%3Fitem%20where%20%7B%0A%09%3Fitem%20wdt%3AP31%2Fwdt%3AP279%2A%20wd%3AQ180323%20%20minus%20%7B%0A%09%09%7B%0A%09%09%09%3Fitem%20wdt%3AP31%2Fwdt%3AP279%2A%20wd%3AQ900457%20%0A%09%09%7D%20union%20%7B%0A%09%09%09%3Fitem%20wdt%3AP31%2Fwdt%3AP279%2A%20wd%3AQ578786%20%0A%09%09%7D%20union%20%7B%0A%09%09%09%3Fitem%20wdt%3AP31%2Fwdt%3AP279%2A%20wd%3AQ405478%20%0A%09%09%7D%20union%20%7B%0A%09%09%09%3Fitem%20wdt%3AP31%2Fwdt%3AP279%2A%20wd%3AQ46993066%20%0A%09%09%7D%20union%20%7B%0A%09%09%09%3Fitem%20wdt%3AP31%2Fwdt%3AP279%2A%20wd%3AQ2253183%20%0A%09%09%7D%0A%09%7D%0A%7D> , that does not find anything unsurprisingly because I don’t expect to find a lot of vertebra instances on Wikidata :) ) Le sam. 20 oct. 2018 à 12:09, Thad Guidry &lt;thadguidry(a)gmail.com&gt; a écrit :

Hi Pine, sorry for the misleading wording. Let me clarify below. Am 19.10.18 um 9:51 nachm. schrieb Pine W: What I meant in concrete terms was: let's start using wikidata items for tagging on commons, even though search results based on such tags will currently not yield very good results, due to the messy state of the ontology, and hope people fix the ontology to get better search results. If people use "poodle" to tag an image and it's not found when searching for "dog", this may lead to people investigating why that is, and coming up with ontology improvements to fix it. What I DON'T mean is "let's automatically generate navigation boxes for wikipedia articles based on an imperfect ontology, and push them on everyone". I mean, using the ontology to generate navigation boxes for some kinds of articles may be a nice idea, and could indeed have the same effect - that people notice problems in the ontology, and fix them. But that would be something the local wiki communities decide to do, not something that comes from Wikidata or the Structured Data project. The point I was trying to make is: the Wiki communities are rather good in creating structures that serve their purpose, but they do so pragmatically, along the behavior of the existing tools. So, rather than trying to work around the quirks of the ontology in software, the software should use very simply rules (such as following the subclass relation), and let people adopt the data to this behavior, if and when they find it useful to do so. This approach, over time, provides better results in my opinion. Also, keep in mind that I was referring to an imperfect *improvement* of search. the alternative being to only return things tagged with "dog" when searching for "dog". I was not suggesting to degrade user experience in order to incentivize editors. I'm rather suggesting the opposite: let's NOT give people a reason tag images that show poodles with "poodle" and "dog" and "mammal" and "animal" and "pet" and... -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation

Dear Wikibase Enthusiasts, if you happen to speak German and if you feel intrigued about the Illuminati, this might be of interest to you: https://blog.factgrid.de/archives/1151 We will use our upcoming Illuminati-Workshop on Nov. 16/17 to discuss how we can make better use of our Wikibase installation here at Gotha. https://database.factgrid.de/wiki/Main_Page The database is filled with metadata of Illuminati documents and (selected) membership information and is supposed to help us with complexities of our Illuminati wiki (https://projekte.uni-erfurt.de/illuminaten/Main_Page), but we do not yet have the clearest idea of what we have produced here or possibly can. If you feel intrigued - we pay travel expenses and accommodation - contact me before Nov. 5, 2018. Looking forward to an illuminating workshop, Olaf