[Wikidata-bugs] [Maniphest] T261451: Add Wikidata support to jawikivoyage
Yurik added a comment. Just caught this while comparing sitematrix output <https://meta.wikimedia.org/w/api.php?action=sitematrix> against the list of allowed sites values <https://www.wikidata.org/w/api.php?action=help=wbsetsitelink>. Is there a reason why these are not coming from the same source? Is there a way to get the list that wikibase is using via api? TASK DETAIL https://phabricator.wikimedia.org/T261451 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Yurik, MF-Warburg, Aklapper, LILOBJTOFU123, Tmv, Atmark-chan, Ladsgroup, jhsoby, Meno25, Dzahn, Urbanecm, Nintendofan885, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T181319: Support external tabular datasets in WDQS
Yurik added a comment. @NavinoEvans I agree - feel free to take my implementation (which was already working for any CSV-style inputs), and extend/adapt it. Ideally, it should be merged upstream to the Blazegraph, so it should support any kind of CSVs. It may make sense to have either some sort of a wrapper for the tabular datasets as an extension to Blazegraph, or alternatively to extend the jsonconfig's API to be able to get CSV directly (which might be a better solution, as it would allow other, non-blazegraph usages) TASK DETAIL https://phabricator.wikimedia.org/T181319 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Librarian_lena, Jinoytommanjaly, Mrjohncummings, mxn, Base, Ferdinand0101, Mahir256, Bugreporter, Daniel_Mietchen, NavinoEvans, Pasleim, Lucas_Werkmeister_WMDE, Smalyshev, Aklapper, Yurik, Kroger4, CBogen, Demian, darthmon_wmde, ET4Eva, Dinadineke, DannyS712, Nandana, tabish.shaikh91, Lahi, Gq86, Darkminds3113, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, EBjune, merbst, LawExplorer, Avner, StuartPrior, Silverfish, debt, Reasno, Gehel, _jensen, rosalieper, Scott_WUaS, Jonas, FloNight, Xmlizer, Volker_E, SBisson, mys_721tx, Jane023, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Xelgen, Manybubbles, jayvdb, zhuyifei1999, TheDJ, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T174981: Add pageviews total counts to WDQS
Yurik added a comment. @Gehel lets define `this amount of data`, just for clarity. My back-of-the-envelope calculations: - each pageview statistics statement is a counter (8 bytes), a reference to the name of the article (8 bytes), and property (8 bytes). In reality it might be a bit less (blazegraph uses 7-bit packing), but we can ignore that for the sake of simplicity. - I do not count page name as part of the statement because the page page name is already stored for other statements - so no additional space is needed for it. - Blazegraph needs to store the same statement in 3 indexes. - Total - about `24*3*1M ~= 68MB` per one million of pages. And again, I suspect this number is about 4 times higher than the actual need because of the bitpacking. Thus, if we just include the articles (rather than all redirects and talk pages), and assume there are about 25 million articles, we are looking at less than 2GB of disk space at most. How significant is 2GB increase of blazegraph index? TASK DETAIL https://phabricator.wikimedia.org/T174981 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Gehel, Zache, Nuria, Tagishsimon, Elya, christophbraun, Bovlb, thalhamm, EBernhardson, Esc3300, Lydia_Pintscher, Yair_rand, Smalyshev, Aklapper, Yurik, 4748kitoko, darthmon_wmde, ET4Eva, Nandana, Akovalyov, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, _jensen, rosalieper, Scott_WUaS, Jonas, FloNight, Xmlizer, JAllemandou, terrrydactyl, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331, jeremyb ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T212843: [EPIC] Access to Wikidata's lexicographical data from Wiktionaries and other WMF sites
Yurik added a subscriber: Lucas_Werkmeister_WMDE. Yurik added a comment. @Lucas_Werkmeister_WMDE thank you for all the hard work on this task! Do you have any approximate timeline of the `getEntity()` returning all lexeme forms, or is that already implemented? How significant of a challenge is it? I have been spending considerable time updating Lexicator bot <https://github.com/nyurik/lexicator> to parse multiple Wiktionary languages, and handle multiple linguistic types, but all that work is mostly pointless until Wiktionaries can access that data. Thanks! TASK DETAIL https://phabricator.wikimedia.org/T212843 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Lucas_Werkmeister_WMDE, mxn, Marsupium, So9q, reosarevok, TomT0m, Yurik, Vesihiisi, ArthurPSmith, Iniquity, Tobias1984, Theklan, Fnielsen, RexxS, Pamputt, Mike_Peel, MarcoSwart, Geertivp, Liuxinyu970226, Addshore, Jdforrester-WMF, deryckchan, Lydia_Pintscher, Lea_Lacroix_WMDE, darthmon_wmde, Nandana, Mringgaard, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, jberkel, Psychoslave, Wikidata-bugs, aude, GPHemsley, Shizhao, Nemo_bis, Darkdadaah, Mbch331, Ltrlg, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T174981: Add pageviews total counts to WDQS
Yurik added a comment. I would guess this is mostly a devops task - orchestrate execution of an updating script. Here's the working implementation - https://github.com/Sophox/sophox/blob/master/osm2rdf/updatePageViewStats.py Simply run it locally near the Blazegraph server. TASK DETAIL https://phabricator.wikimedia.org/T174981 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Tagishsimon, Elya, christophbraun, Bovlb, thalhamm, EBernhardson, Esc3300, Lydia_Pintscher, Yair_rand, Smalyshev, Aklapper, Yurik, 4748kitoko, darthmon_wmde, ET4Eva, Nandana, Akovalyov, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Gehel, _jensen, rosalieper, Scott_WUaS, Jonas, FloNight, Xmlizer, JAllemandou, terrrydactyl, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331, jeremyb ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T174981: Add pageviews total counts to WDQS
Yurik added a comment. @Tagishsimon this proposal would not edit wikidata. Instead, as part of the WDQS import process, it would upload pageviews in bulk from the pageview dump files directly into the Blazegraph index. It could do it every hour, and computation-wise it will be relatively inexpensive (i ran it as part of Sophox a few times). TASK DETAIL https://phabricator.wikimedia.org/T174981 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Tagishsimon, Elya, christophbraun, Bovlb, thalhamm, EBernhardson, Esc3300, Lydia_Pintscher, Yair_rand, Smalyshev, Aklapper, Yurik, 4748kitoko, darthmon_wmde, ET4Eva, Nandana, Akovalyov, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Gehel, _jensen, rosalieper, Scott_WUaS, Jonas, FloNight, Xmlizer, JAllemandou, terrrydactyl, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331, jeremyb ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T224312: Improve LinguaLibreBot on Wikidata Lexeme
Yurik updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T224312 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Esc3300, real68er, Pamputt, darthmon_wmde, DannyS712, Nandana, Mringgaard, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, Base, aude, Darkdadaah, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T224312: Improve LinguaLibreBot on Wikidata Lexeme
Yurik updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T224312 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Esc3300, real68er, Pamputt, darthmon_wmde, DannyS712, Nandana, Mringgaard, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, Base, aude, Darkdadaah, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T212843: [EPIC] Access to Wikidata's lexicographical data from Wiktionaries and other WMF sites
Yurik added a comment. @Fnielsen i am not sure I understand what that query does, could you elaborate? Especially I am confused why you look at the forms -- from the perspective of Wiktionary, you request a single Lexeme, not individual forms. (btw, the query times out for me). Also, I just realized that I shouldn't have grouped by the language, because in Wiktionary each page is per Lemma, regardless of which language contains it. So if Wiktionary wants to show data about all lexemes spelled a certain way, the query becomes https://w.wiki/8yY (the results are nearly identical -- words are still by far unique, at least with what we currently have in WD): | lexemes_per_word | words | | 1| 173657 | | 2| 4670 | | 3| 351| | 4| 66 | | 5| 15 | | 6| 8 | | 7| 3 | | 8| 1 | TASK DETAIL https://phabricator.wikimedia.org/T212843 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: TomT0m, Yurik, Vesihiisi, ArthurPSmith, Iniquity, Tobias1984, Theklan, Fnielsen, RexxS, Pamputt, Mike_Peel, MarcoSwart, Geertivp, Liuxinyu970226, Addshore, Jdforrester-WMF, deryckchan, Lydia_Pintscher, Lea_Lacroix_WMDE, darthmon_wmde, DannyS712, Nandana, Mringgaard, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, jberkel, Psychoslave, Wikidata-bugs, aude, GPHemsley, Shizhao, Nemo_bis, Darkdadaah, Mbch331, Ltrlg, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T212843: [EPIC] Access to Wikidata's lexicographical data from Wiktionaries and other WMF sites
Yurik added a comment.
P.S. @Fnielsen does bring a valid point about various linked lexemes , and
that might be useful -- for example if lexeme lists another lexeme as being a
synonym, it would be good to show it as a word rather than an L-number.
That said, I do not believe we need it just yet -- it will take a while for
the synonyms to be populated to the level of wiktionary, so for now lexemes
will be needed just for the "infoboxes" -- e.g. list all forms and basic info,
not the advanced features.
At this point, I can easily replace the `{{noun ru|...}}` template (generates
morphology summary and a forms table), but I won't be able to easily replace
the synonyms section with the auto-generated content, and thus, linked lexemes
are somewhat useless until they have much better coverage.
TASK DETAIL
https://phabricator.wikimedia.org/T212843
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Yurik
Cc: TomT0m, Yurik, Vesihiisi, ArthurPSmith, Iniquity, Tobias1984, Theklan,
Fnielsen, RexxS, Pamputt, Mike_Peel, MarcoSwart, Geertivp, Liuxinyu970226,
Addshore, Jdforrester-WMF, deryckchan, Lydia_Pintscher, Lea_Lacroix_WMDE,
darthmon_wmde, DannyS712, Nandana, Mringgaard, Lahi, Gq86, Cinemantique,
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, jberkel,
Psychoslave, Wikidata-bugs, aude, GPHemsley, Shizhao, Nemo_bis, Darkdadaah,
Mbch331, Ltrlg, Krenair
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T212843: [EPIC] Access to Wikidata's lexicographical data from Wiktionaries and other WMF sites
Yurik added a comment. @Lydia_Pintscher most of the Wiktionary pages have just one corresponding lexeme - and that's all I would expect to load. Some statistics: https://w.wiki/8xw (note that this is per language, not just when lemmas match) | lexemes_per_word | words | | 1| 173680 | | 2| 4659 | | 3| 351| | 4| 65 | | 5| 15 | | 6| 8 | | 7| 3 | | 8| 1 | | The tricky bit comes when a page has multiple associated lexemes -- yes, in theory there could be up to 8 (per query result), but I think this is a mistake to store so many lexemes per word -- most of them have identical forms, pronunciation, and top-level claims. They only differ in their meaning - and as such, we should put that meaning inside the senses. TASK DETAIL https://phabricator.wikimedia.org/T212843 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: TomT0m, Yurik, Vesihiisi, ArthurPSmith, Iniquity, Tobias1984, Theklan, Fnielsen, RexxS, Pamputt, Mike_Peel, MarcoSwart, Geertivp, Liuxinyu970226, Addshore, Jdforrester-WMF, deryckchan, Lydia_Pintscher, Lea_Lacroix_WMDE, darthmon_wmde, DannyS712, Nandana, Mringgaard, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, jberkel, Psychoslave, Wikidata-bugs, aude, GPHemsley, Shizhao, Nemo_bis, Darkdadaah, Mbch331, Ltrlg, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T212843: [EPIC] Access to Wikidata's lexicographical data from Wiktionaries and other WMF sites
Yurik added a comment. @RexxS you do bring up a valid point about watchlist. The minor difference here is that lexeme is tied to a specific language, so it is less likely to have content not relevant to that one language / wiktionary. The only exception might be the description of sensese in other languages. TBH, I am not sure that adding sense description in a non-native language is a scalable solution -- we are repeating the issue of sitelinks, where every wiki page referenced all other wiki pages on the same subject. But this is a separate discussion, unrelated to this ticket. Performance-wise, there is not much difference -- lexemes are not attached (yet) to wiktionary pages, the way wikidata item are attached with their sitelinks, so every lexeme retrieval will be "expensive". On the other hand, getting just a handful (at most) lexemes per wiktionary page should not affect performance in a significant way. And since most of the content will be relevant to the page generation, having multiple calls might actually be slower than rendering a large chunk of page in a single template with a module, where that module would get the whole lexeme content. Lastly, we could always optimize the process, but remember that having a simple interface to get the entire lexeme is far quicker to implement than to have a very complex system - so at the end it might be better, but in the mean time you won't have it for several years (?), and you may need to allocate resources to this project at an expense of another project. TASK DETAIL https://phabricator.wikimedia.org/T212843 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: TomT0m, Yurik, Vesihiisi, ArthurPSmith, Iniquity, Tobias1984, Theklan, Fnielsen, RexxS, Pamputt, Mike_Peel, MarcoSwart, Geertivp, Liuxinyu970226, Addshore, Jdforrester-WMF, deryckchan, Lydia_Pintscher, Lea_Lacroix_WMDE, darthmon_wmde, DannyS712, Nandana, Mringgaard, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, jberkel, Psychoslave, Wikidata-bugs, aude, GPHemsley, Shizhao, Nemo_bis, Darkdadaah, Mbch331, Ltrlg, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T232930: Unable to create lexeme talk pages (permission error)
Yurik updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T232930 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Yurik, darthmon_wmde, DannyS712, Nandana, Mringgaard, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Darkdadaah, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T232930: Unable to create lexeme talk pages (permission error)
Yurik created this task. Yurik added a project: Lexicographical data. Restricted Application added a project: Wikidata. TASK DESCRIPTION Navigate to Lexeme:L10 <https://www.wikidata.org/wiki/Lexeme:L10>, click "discussion" tab, and try to create the page. I get `Permission error` (both as a logged in user and as anonymous) F30344043: image.png <https://phabricator.wikimedia.org/F30344043> counterexample Permission error Jump to navigationJump to search You do not have permission to create this discussion page, for the following reason: You are trying to create a talk page which cannot be associated with a lexeme. Therefore saving this edit was blocked. You should check whether the title of the talk page is typed correctly. If you think you are correct, please contact an administrator. Navigation menu TASK DETAIL https://phabricator.wikimedia.org/T232930 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Yurik, darthmon_wmde, DannyS712, Nandana, Mringgaard, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Darkdadaah, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T212843: [EPIC] Access to Wikidata's lexicographical data from Wiktionaries and other WMF sites
Yurik added a comment.
P.S. to sum up -- Wiktionary just needs just a single Lua function for the
minimum viable product: `getEntity('L10')` that simply returns the whole
Lexeme JSON. Everything else is optional.
TASK DETAIL
https://phabricator.wikimedia.org/T212843
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Yurik
Cc: Yurik, Vesihiisi, ArthurPSmith, Iniquity, Tobias1984, Theklan, Fnielsen,
RexxS, Pamputt, Mike_Peel, MarcoSwart, Geertivp, Liuxinyu970226, Addshore,
Jdforrester-WMF, deryckchan, Lydia_Pintscher, Lea_Lacroix_WMDE, darthmon_wmde,
DannyS712, Nandana, Mringgaard, Lahi, Gq86, Cinemantique, GoranSMilovanovic,
QZanden, LawExplorer, _jensen, rosalieper, jberkel, Psychoslave, Wikidata-bugs,
aude, GPHemsley, Shizhao, Nemo_bis, Darkdadaah, Mbch331, Ltrlg, Krenair
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T212843: [EPIC] Access to Wikidata's lexicographical data from Wiktionaries and other WMF sites
Yurik added a comment. I have imported some Russian nouns (~20,000 so far, but will be more soon), plus added a link from Wiktionary to the corresponding Lexeme. I think the simplest use case for Lexemes would be to allow Wiktionary Lua script to be able to load Lexeme by its ID. This will instantly make Lexemes useful to Wiktionary because the Lua script will be able to: - generate table of the word forms - generate etymology and pronunciation sections - do the above for every lexeme if more than one is used on the page. Note that the last point makes it substantially different from the regular Wikipedia usage because it is likely that more than one Lexeme corresponds to a single Wiktionary page. Also, while nice to have, it is not really required for Wiktionary to be able to read Wikidata Q items because those could be hardcoded in Lua (the list of used Q-IDs is not too big - under a thousand) TASK DETAIL https://phabricator.wikimedia.org/T212843 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Yurik, Vesihiisi, ArthurPSmith, Iniquity, Tobias1984, Theklan, Fnielsen, RexxS, Pamputt, Mike_Peel, MarcoSwart, Geertivp, Liuxinyu970226, Addshore, Jdforrester-WMF, deryckchan, Lydia_Pintscher, Lea_Lacroix_WMDE, darthmon_wmde, DannyS712, Nandana, Mringgaard, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, jberkel, Psychoslave, Wikidata-bugs, aude, GPHemsley, Shizhao, Nemo_bis, Darkdadaah, Mbch331, Ltrlg, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T232557: Lexeme's Grammatical features are created in random order
Yurik created this task. Yurik added a project: Lexicographical data. Restricted Application added a project: Wikidata. TASK DESCRIPTION When a new lexeme is created, gramatical features show up in a random order. This makes it somewhat confusing especially when they are generated by a bot. Any attempt at ordering is ignored. Example: https://www.wikidata.org/wiki/Lexeme:L82714 The order of "singular" and "case" is arbitrary for each grammatical feature. TASK DETAIL https://phabricator.wikimedia.org/T232557 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Yurik, darthmon_wmde, DannyS712, Nandana, Mringgaard, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, B20180, _jensen, rosalieper, Wikidata-bugs, aude, Darkdadaah, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T230051: wikidata.org handles GET MWAPI requests, but silently fails on POST
Yurik updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T230051 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Aklapper, Anomie, Yurik, darthmon_wmde, WDoranWMF, holger.knust, EvanProdromou, Legado_Shulgin, DannyS712, Nandana, thifranc, AndyTan, Davinaclare77, Qtn1293, Techguru.pc, Lahi, Gq86, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, LawExplorer, Sethakill, Zppix, dg711, _jensen, rosalieper, Agabi10, Pchelolo, Jonas, Wong128hk, Wikidata-bugs, aude, jayvdb, Lydia_Pintscher, faidon, Mbch331, Jay8g, fgiunchedi, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T230051: wikidata.org handles GET MWAPI requests, but silently fails on POST
Yurik added a project: Operations. TASK DETAIL https://phabricator.wikimedia.org/T230051 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Aklapper, Anomie, Yurik, darthmon_wmde, WDoranWMF, holger.knust, EvanProdromou, Legado_Shulgin, DannyS712, Nandana, thifranc, AndyTan, Davinaclare77, Qtn1293, Techguru.pc, Lahi, Gq86, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, LawExplorer, Sethakill, Zppix, dg711, _jensen, rosalieper, Agabi10, Pchelolo, Jonas, Wong128hk, Wikidata-bugs, aude, jayvdb, Lydia_Pintscher, faidon, Mbch331, Jay8g, fgiunchedi, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T230051: wikidata.org handles GET MWAPI requests, but silently fails on POST
Yurik renamed this task from "wikidata.org handles GET MWAPI requests, but silently redirects on POST" to "wikidata.org handles GET MWAPI requests, but silently fails on POST". TASK DETAIL https://phabricator.wikimedia.org/T230051 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Aklapper, Anomie, Yurik, darthmon_wmde, WDoranWMF, holger.knust, EvanProdromou, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Sethakill, dg711, _jensen, rosalieper, Agabi10, Pchelolo, Jonas, Wikidata-bugs, aude, jayvdb, Lydia_Pintscher, Mbch331, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T230051: wikidata.org handles GET MWAPI requests, but silently redirects on POST
Yurik renamed this task from "Wikidata breaks MW-API response format on (some?) errors" to "wikidata.org handles GET MWAPI requests, but silently redirects on POST". Yurik updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T230051 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Aklapper, Anomie, Yurik, darthmon_wmde, WDoranWMF, holger.knust, EvanProdromou, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Sethakill, dg711, _jensen, rosalieper, Agabi10, Pchelolo, Jonas, Wikidata-bugs, aude, jayvdb, Lydia_Pintscher, Mbch331, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T230051: Wikidata breaks MW-API response format on (some?) errors
Yurik updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T230051 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Aklapper, Anomie, Yurik, darthmon_wmde, WDoranWMF, holger.knust, EvanProdromou, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Sethakill, dg711, _jensen, rosalieper, Agabi10, Pchelolo, Jonas, Wikidata-bugs, aude, jayvdb, Lydia_Pintscher, Mbch331, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T230051: Wikidata breaks MW-API response format on (some?) errors
Yurik created this task.
Yurik added projects: MediaWiki-API, Wikidata.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Core Platform Team.
TASK DESCRIPTION
A POST API call with this data works ok on sites like ru.wiktionary.org, but
returns an HTML API help page when used on wikidata.org. This breaks the
fundamental API contract that the response (including errors) should be in the
requested format.
data = {
lgname: 'YurikBot',
lgpassword: 'mycode@some-hex-password',
action: 'login',
format: 'json',
}
TASK DETAIL
https://phabricator.wikimedia.org/T230051
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Yurik
Cc: Aklapper, Anomie, Yurik, darthmon_wmde, WDoranWMF, holger.knust,
EvanProdromou, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden,
LawExplorer, Sethakill, dg711, _jensen, rosalieper, Agabi10, Pchelolo,
Wikidata-bugs, aude, jayvdb, Mbch331, Legoktm
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T222506: wikidata conflict error message has missing param
Yurik created this task. Yurik added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION Reproduce: set multiple sitelinks on the same wikidata item in rapid succession has produced this error on several of the ~10 wikis i modified at nearly the same time (multiple tabs). The $1 clearly needs a param. (the error itself is fine - clicking "confirm" again fixed it) F28924844: image.png <https://phabricator.wikimedia.org/F28924844> TASK DETAIL https://phabricator.wikimedia.org/T222506 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Aklapper, Yurik, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T218749: Allow own Wikidata ID to be used inside the Formatter URL
Yurik created this task. Yurik added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION The formatter URL <https://www.wikidata.org/wiki/Property:P1630> supports a single `$1` parameter - the value of the property. Please add `$2` to be the ID of the Wikidata entity itself. This way some Wikidata-aware systems will be able to offer much more accurate representation of the value. TASK DETAIL https://phabricator.wikimedia.org/T218749 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Aklapper, Yurik, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T47224: [Story] Custom edit summaries
Yurik added a comment.
Here's a working implementation using the browser's prompt text box, based on
the original idea by @Ricordisamoa. Copy it into your
`https://wiki.openstreetmap.org/wiki/User:___username___/common.js` page. Note
that the save will happen even if the user clicks `Cancel` because there is no
good way to abort saving without crashing. This code can be directly used as a
gadget.
/*
* EditWikidataSummary.js
* @author [[User:Yurik]] based on code by [[User:Ricordisamoa]]
*/
( function( $, mw, window ) {
$( function () {
if( !mw.config.exists( 'wbEntityId' ) ) {
return;
}
mw.hook('wikibase.entityPage.entityView.rendered').add(function () {
oldPost = wb.api.RepoApi.prototype._post;
wb.api.RepoApi.prototype._post = function ( params ) {
if ( params.summary === undefined ) {
var summary = window.prompt('Enter edit summary (optional):', '');
if ( summary ) {
params.summary = summary;
}
}
return oldPost.call( this, params );
};
} );
} );
} )( jQuery, mediaWiki, window );
TASK DETAIL
https://phabricator.wikimedia.org/T47224
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Yurik
Cc: mxn, Yurik, Darwinius, CatCat, ElanHR, Salgo60, reosarevok,
Lucas_Werkmeister_WMDE, Zppix, YFdyh000, Nikki, Daniel_Mietchen,
Lydia_Pintscher, Bene, jayvdb, Aklapper, Candalua, MGChecker, Liuxinyu970226,
Wikidata-bugs, Abraham, jeblad, Addshore, aude, matej_suchanek, Ricordisamoa,
Beta16, Allen4names, Danmichaelo, alaa_wmde, Dinadineke, Nandana,
tabish.shaikh91, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345,
JakeTheDeveloper, QZanden, dachary, merbst, LawExplorer, Puik, _jensen,
rosalieper, D3r1ck01, Envlh, Tobias1984, Sjoerddebruin, TheDJ, Mbch331, Jay8g
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T47224: [Story] Custom edit summaries
Yurik added a comment. This feature has been requested several times when adding Wikibase to OpenStreetMap wiki. I think the very first step we can already do is to make it possible for gadgets to add edit summary string during the "save" command. This way we can experiment with the UI implementation. What is the recommended way for gadgets to dynamically modify POST parameters? TASK DETAIL https://phabricator.wikimedia.org/T47224 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Yurik, Darwinius, CatCat, ElanHR, Salgo60, reosarevok, Lucas_Werkmeister_WMDE, Zppix, YFdyh000, Nikki, Daniel_Mietchen, Lydia_Pintscher, Bene, jayvdb, Aklapper, Candalua, MGChecker, Liuxinyu970226, Wikidata-bugs, Abraham, jeblad, Addshore, aude, matej_suchanek, Ricordisamoa, Beta16, Allen4names, Danmichaelo, alaa_wmde, Dinadineke, Nandana, tabish.shaikh91, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, dachary, merbst, LawExplorer, Puik, _jensen, rosalieper, D3r1ck01, Envlh, Tobias1984, Sjoerddebruin, TheDJ, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T217873: Allow custom user summaries to be added to Wikibase edits
Yurik updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T217873 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Aklapper, Yurik, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T217873: Allow custom user summaries to be added to Wikibase edits
Yurik updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T217873 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Aklapper, Yurik, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T217873: Allow custom user summaries to be added to Wikibase edits
Yurik created this task. Yurik added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION Per user request, it is often important for the editors to be able to add custom edit summary message in addition to the automatically generated one. Yet there doesn't seem to be any way for the wikidata users to add that right before hitting `save`. The Wikibase API already supports it (e.g. I was able to add an extra `summary` parameter right before the `setClaim` call, producing this summary text <https://wiki.openstreetmap.org/w/index.php?title=Item%3AQ2761=revision=1818989=1818988>), so this change would only be needed in javascript, possibly as a gadget (at first). Proposed implementation: On `save` link mouse-over, show a drop down, and do not hide it unless user clicks outside of the box. Any entered text should be preserved even if the dropbox is closed. Other `save` links on the same page would not be affected. For mobile, we may have to have a separate edit box. F28344839: image.png <https://phabricator.wikimedia.org/F28344839> The first step should make it easy to implement via Gadgets (e.g. by providing some sort of a pre-save hook) so that a Gadget would 1) handle the mouseovers on save to show the popup, and 2) handle pre-save hook to add an extra summary parameter to the post (and be able to examine parameters are being sent. TASK DETAIL https://phabricator.wikimedia.org/T217873 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yurik Cc: Aklapper, Yurik, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T173052: Show OpenStreetMap features associated with Wikidata items
Yurik added a comment. Note that this is also possible with Sophox -- e.g. a SPARQL query can use Wikidata via federation together with all of OSM data itself (tags), plus attach the OSM geometry shapes to each wikidata ID it sees in the query result. Click "run query" under the example.TASK DETAILhttps://phabricator.wikimedia.org/T173052EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: mxn, YurikCc: Yurik, Salgo60, Jc86035, debt, TheDJ, Planemad, Pigsonthewing, Aklapper, mxn, PokestarFan, Nandana, MSantos, Lahi, Gq86, Looniverse, GoranSMilovanovic, QZanden, Orienteerix, LawExplorer, Ddproxy, _jensen, JGirault, phabyogi, GAllegre, Susannaanas, ferdbold, lxbarth, Wikidata-bugs, aude, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T215073: OSM map layers other than the default should be displayable in the Wikidata Query Service
Yurik added a subscriber: Pnorman.Yurik added a comment. In T215073#4921970, @Jim_Carter wrote: It is very irresponsible if the reliability of the map is questioned, yet it is been implicatied that "we will use the map because its free". In fact, the map that has been provided (OSM) is very different https://openstreetmap.in/#4/25.32/77.17 and accurate than the one rendered by Wikimedia, it is an act of intentional vandalism, then. If Wikimedia use what OSM provide then please restore it to that version instead of creating a new coined version. Jim, the main OpenStreetMap map - https://www.openstreetmap.org/#map=4/25.24/77.17 shows a different border than the one you linked to. I understand it is a touchy subject (similar to Crimea and several other disputed territories). Unfortunately WMF is not currently investing into maps in any significant fashion, and moreover, a developer (@Pnorman) was hired to work on better display of the disputed territories, and after over a year of work, after it essentially being 90% complete, WMF decided to stop the project without any explanation to the community.TASK DETAILhttps://phabricator.wikimedia.org/T215073EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Pnorman, Yurik, Smalyshev, Lydia_Pintscher, TerraCodes, Mholloway, Liuxinyu970226, Jim_Carter, KCVelaga, Aklapper, Titodutta, Mahir256, Nandana, MSantos, Lahi, Gq86, Looniverse, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, Orienteerix, merbst, LawExplorer, Salgo60, Ddproxy, _jensen, JGirault, Jonas, phabyogi, Xmlizer, GAllegre, Susannaanas, ferdbold, lxbarth, jkroll, Planemad, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T215073: OSM map layers other than the default should be displayable in the Wikidata Query Service
Yurik added a comment. FYI, there has been a number of discussions at OSM on how to document disputed territories. See the latest proposal.TASK DETAILhttps://phabricator.wikimedia.org/T215073EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Yurik, Smalyshev, Lydia_Pintscher, TerraCodes, Mholloway, Liuxinyu970226, Jim_Carter, KCVelaga, Aklapper, Titodutta, Mahir256, Nandana, MSantos, Lahi, Gq86, Looniverse, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, Orienteerix, merbst, LawExplorer, Salgo60, Ddproxy, _jensen, JGirault, Jonas, phabyogi, Xmlizer, GAllegre, Susannaanas, ferdbold, lxbarth, jkroll, Planemad, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T90492: [Task] Make Wikibase Repo work with a custom File collection, not only Wikimedia Commons
Yurik added a comment. Are there any updates/progress on this issue? The OpenStreetMap Wikibase has both the local images and it supports Commons, which means every Wikibase "image" property is actually two properties - one of "image" type, and another being a manually copy/pasted string of the local (OSM) wiki file - in case the file is not on Commons. It would greatly simplify things for OSM community if an image property would be a single "media", regardless of where it is actually stored. What could be done to solve this?TASK DETAILhttps://phabricator.wikimedia.org/T90492EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despens, YurikCc: Yurik, Addshore, Abit, ToBeFree, Jakob_WMDE, Tarrow, LJ, Daniel_Mietchen, despens, Loz.ross, RazShuty, PokestarFan, Lokal_Profil, Reedy, Steinsplitter, Snaterlicious, adrianheine, Ricordisamoa, gerritbot, daniel, Aklapper, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, D3r1ck01, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T212069: API action=wbgetentities does not handle formatversion=2
Yurik updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...* `https://www.wikidata.org/w/api.php?action="" style="padding: 0 2px; color: #33; background: rgba(251, 175, 175, .7);">` * `https://www.wikidata.org/w/api.php?action="" style="padding: 0 2px; color: #33; background: rgba(251, 175, 175, .7);">` ```lang=json...TASK DETAILhttps://phabricator.wikimedia.org/T212069EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Anomie, Aklapper, Yurik, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Sethakill, dg711, _jensen, D3r1ck01, Wikidata-bugs, aude, jayvdb, Mbch331, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T212069: API action=wbgetentities does not handle formatversion=2
Yurik created this task.Yurik added projects: MediaWiki-API, Wikidata.Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTIONBoth of this requests return identical result, ignoring JSON v2:
https://www.wikidata.org/w/api.php?action="">
https://www.wikidata.org/w/api.php?action="">
{
"entities": {
"-1": {
"site": "enwiki",
"title": "Bug12345",
"missing": ""
}
},
"success": 1
}
expected for v2:
{
"entities": [
{
"site": "enwiki",
"title": "Bug12345",
"missing": true
}
],
"success": true
}TASK DETAILhttps://phabricator.wikimedia.org/T212069EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Anomie, Aklapper, Yurik, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Sethakill, dg711, _jensen, D3r1ck01, Wikidata-bugs, aude, jayvdb, Mbch331, Legoktm___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T184933: Display map for geocoordinate statements
Yurik added a comment. In T184933#4813382, @hoo wrote: In T184933#4812900, @TheDJ wrote: Fancy... Just a followup/enhancement idea: since we have precision.. wouldn't this be a good place to draw a precision circle ? This is a very good point: Basically we can alter the generated mapframes like in any article… in fact we generate them from wikitext (see CachingKartographerEmbeddingHandler::getWikiText). I created a new task (T211676) for this… suggestions on how exactly to implement this are very welcome there :) Awesome idea! The only problem is that GeoJSON does not support circles :( I guess it will be a choppy circle, e.g. with 16 sides :)TASK DETAILhttps://phabricator.wikimedia.org/T184933EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, YurikCc: Yurik, TheDJ, Mholloway, Mvolz, Lea_Lacroix_WMDE, JeroenDeDauw, Stashbot, Lydia_Pintscher, Lucas_Werkmeister_WMDE, Ainali, MSantos, WMDE-leszek, Tpt, Jonas, gerritbot, hoo, Ayack, Sjoerddebruin, Aklapper, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, Looniverse, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Orienteerix, dachary, LawExplorer, Lewizho99, Maathavan, _jensen, JGirault, D3r1ck01, phabyogi, Susannaanas, lxbarth, Planemad, Wikidata-bugs, aude, Ricordisamoa, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T210692: WDQS should not add (...) to VALUES
Yurik updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...I think the extra parentesis produce more harm than good. Most of the time, VALUES is a relatively short single-value list, not a list of lists, so making it one item per line creates unnecessary hindrance to understanding and maintaining the query code. Thanks! Upstream issue: [[ https://github.com/RubenVerborgh/SPARQL.js/issues/68 | #68 ]]TASK DETAILhttps://phabricator.wikimedia.org/T210692EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Lucas_Werkmeister_WMDE, Aklapper, Yurik, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Salgo60, _jensen, D3r1ck01, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T210692: WDQS should not add (...) to VALUES
Yurik added a comment. [[ Upstream issue | Upstream issue ]]TASK DETAILhttps://phabricator.wikimedia.org/T210692EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Lucas_Werkmeister_WMDE, Aklapper, Yurik, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Salgo60, _jensen, D3r1ck01, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T210692: WDQS should not add (...) to VALUES
Yurik added a comment.
@Lucas_Werkmeister_WMDE I think both should be fixed - it should never use unneeded parenthesis for single values, and when the VALUES list is short enough, it should be shown singleline. For a very long list, it should be shown like this:
SELECT * WHERE {
VALUES ?a {
wd:Q1 wd:Q2 wd:Q1 wd:Q2 wd:Q1 wd:Q2 wd:Q1 wd:Q2 wd:Q1 wd:Q2 wd:Q1 wd:Q2
wd:Q1 wd:Q2 wd:Q1 wd:Q2 wd:Q1 wd:Q2 wd:Q1 wd:Q2 wd:Q1 wd:Q2 wd:Q1 wd:Q2
}
}
I guess this is really an upstream request, but we could track it here as well to either encourage upstream to see it, or for someone in WDQS community to tackle it.TASK DETAILhttps://phabricator.wikimedia.org/T210692EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Lucas_Werkmeister_WMDE, Aklapper, Yurik, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Salgo60, _jensen, D3r1ck01, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T210692: WDQS should not add (...) to VALUES
Yurik created this task.Yurik added a project: Wikidata-Query-Service.Restricted Application added a subscriber: Aklapper.Restricted Application added a project: Wikidata.
TASK DESCRIPTIONIn WDQS, pressing the diamond autoformats this:
SELECT * WHERE {
VALUES ?a { wd:Q1 wd:Q2 }
}
into this:
SELECT * WHERE {
VALUES (?a) {
(wd:Q1)
(wd:Q2)
}
}
I think the extra parentesis produce more harm than good. Most of the time, VALUES is a relatively short single-value list, not a list of lists, so making it one item per line creates unnecessary hindrance to understanding and maintaining the query code. Thanks!TASK DETAILhttps://phabricator.wikimedia.org/T210692EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Aklapper, Yurik, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, D3r1ck01, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T209807: osmUpdate throws exceptions importing OSM Wikibase
Yurik closed this task as "Resolved".Yurik claimed this task.Yurik added a comment. Turns out the --conceptUri http://wiki.openstreetmap.org should have been http instead of https. Thanks @Smalyshev for your help!TASK DETAILhttps://phabricator.wikimedia.org/T209807EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Aklapper, Smalyshev, Yurik, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, D3r1ck01, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T209807: osmUpdate throws exceptions importing OSM Wikibase
Yurik created this task.Yurik added a project: Wikidata-Query-Service.Restricted Application added a subscriber: Aklapper.Restricted Application added a project: Wikidata. TASK DESCRIPTIONRunning runUpdate with an empty Blazegraph causes exceptions (of several types) when processing OSM wikibase data, e.g. Item:Q6. I also get similar errors when running without the -s flag. Quiet possibly this is a configuration problem of sorts, but not sure where to even begin looking. Thanks! runUpdate.sh \ -h http://blazegraph: -s -- \ --wikibaseUrl https://wiki.openstreetmap.org --conceptUri https://wiki.openstreetmap.org --entityNamespaces 120,122 04:49:24.613 [update 4] INFO o.wikidata.query.rdf.tool.rdf.Munger - Unrecognized subjects: [http://wiki.openstreetmap.org/entity/statement/Q6-1a82f62d-442d-ab74-2558-7a443ac85074, http://wiki.openstreetmap.org/entity/Q6] while processing https://wiki.openstreetmap.org/entity/Q6. Expected only sitelinks and subjects starting with https://wiki.openstreetmap.org/wiki/Special:EntityData/ and https://wiki.openstreetmap.org/entity/ 04:49:24.827 [update 6] INFO o.wikidata.query.rdf.tool.rdf.Munger - Unrecognized subjects: [http://wiki.openstreetmap.org/entity/statement/Q6634-39B6AE97-4C15-4F5B-85C8-B6402C822C66, http://wiki.openstreetmap.org/entity/statement/Q6634-36307B0D-54B9-4F4F-844B-A667D13750D4, http://wiki.openstreetmap.org/entity/statement/Q6634-7B0757EC-DC43-4B2A-8181-0F57F3FF302B, http://wiki.openstreetmap.org/entity/Q6634, http://wiki.openstreetmap.org/entity/statement/Q6634-D75BE75A-75B4-4438-8CB4-5D75B6E2A16D, http://wiki.openstreetmap.org/entity/statement/Q6634-510F87B0-36B8-4C9A-BADB-6B75BC710E03, http://wiki.openstreetmap.org/entity/statement/Q6634-D62ACE81-72AD-4FD7-AD63-AB69A616DC48, http://wiki.openstreetmap.org/entity/statement/Q6634-F3FACF0A-89EB-49CF-ADC8-EB5A79F6673E, http://wiki.openstreetmap.org/entity/statement/Q6634-209245C4-D566-40C5-BCD1-BED1AD280331, http://wiki.openstreetmap.org/entity/statement/Q6634-81B27F8E-80EF-473C-87C7-4095611126F1] while processing https://wiki.openstreetmap.org/entity/Q6634. Expected only sitelinks and subjects starting with https://wiki.openstreetmap.org/wiki/Special:EntityData/ and https://wiki.openstreetmap.org/entity/ 04:49:24.844 [update 1] INFO o.wikidata.query.rdf.tool.rdf.Munger - Unrecognized subjects: [http://wiki.openstreetmap.org/entity/P10, http://wiki.openstreetmap.org/prop/reference/value/P10, http://wiki.openstreetmap.org/prop/qualifier/P10, http://wiki.openstreetmap.org/prop/statement/value/P10, http://wiki.openstreetmap.org/prop/direct/P10, http://wiki.openstreetmap.org/prop/reference/P10, http://wiki.openstreetmap.org/prop/novalue/P10, http://wiki.openstreetmap.org/prop/qualifier/value/P10, http://wiki.openstreetmap.org/prop/statement/P10, http://wiki.openstreetmap.org/prop/P10] while processing https://wiki.openstreetmap.org/entity/P10. Expected only sitelinks and subjects starting with https://wiki.openstreetmap.org/wiki/Special:EntityData/ and https://wiki.openstreetmap.org/entity/ 04:49:24.867 [update 4] INFO o.wikidata.query.rdf.tool.rdf.Munger - Unrecognized subjects: [http://wiki.openstreetmap.org/prop/statement/value/P24, http://wiki.openstreetmap.org/prop/qualifier/value/P24, http://wiki.openstreetmap.org/entity/P24, http://wiki.openstreetmap.org/prop/qualifier/P24, http://wiki.openstreetmap.org/prop/direct/P24, http://wiki.openstreetmap.org/prop/statement/P24, http://wiki.openstreetmap.org/entity/statement/P24-113273b1-414e-8b65-3559-ffa3451f3006, http://wiki.openstreetmap.org/prop/P24, http://wiki.openstreetmap.org/prop/reference/P24, http://wiki.openstreetmap.org/prop/novalue/P24, http://wiki.openstreetmap.org/prop/reference/value/P24] while processing https://wiki.openstreetmap.org/entity/P24. Expected only sitelinks and subjects starting with https://wiki.openstreetmap.org/wiki/Special:EntityData/ and https://wiki.openstreetmap.org/entity/ 04:49:24.872 [update 7] INFO o.wikidata.query.rdf.tool.rdf.Munger - Unrecognized subjects: [http://wiki.openstreetmap.org/prop/statement/value/P25, http://wiki.openstreetmap.org/entity/P25, http://wiki.openstreetmap.org/prop/qualifier/value/P25, http://wiki.openstreetmap.org/prop/statement/P25, http://wiki.openstreetmap.org/prop/qualifier/P25, http://wiki.openstreetmap.org/prop/direct/P25, http://wiki.openstreetmap.org/prop/reference/P25, http://wiki.openstreetmap.org/prop/P25, http://wiki.openstreetmap.org/prop/reference/value/P25, http://wiki.openstreetmap.org/prop/novalue/P25] while processing https://wiki.openstreetmap.org/entity/P25. Expected only sitelinks and subjects starting with https://wiki.openstreetmap.org/wiki/Special:EntityData/ and https://wiki.openstreetmap.org/entity/ 04:49:24.878 [update 9] INFO o.wikidata.query.rdf.tool.rdf.Munger - Unrecognized subjects: [http://wiki.openstreetmap.org/prop/novalue/P16, http://wiki.openstreetmap.org/prop/qualifier/value/P16, http://wiki.openstreetmap.org/entity/P16
[Wikidata-bugs] [Maniphest] [Created] T206426: Storing multiple sitelinks to a multilingual wiki
Yurik created this task.Yurik added a project: Wikidata.Restricted Application added a subscriber: Aklapper. TASK DESCRIPTIONIn the case of multilingual wiki (Wikidata, Commons, OSM wiki), there could exist pages in multiple languages all representing the same topic. Currently, it is only possible to store only one sitelink per wiki. One hacky workaround could be to store data as monolingual strings. What would be the best way to change Wikibase to support multilingual wikis via sitelinks? Current sitelink system relies on wiki ID, not on language ID.TASK DETAILhttps://phabricator.wikimedia.org/T206426EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Aklapper, Yurik, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86517: [Story] Add a new datatype for multilingual text
Yurik added a comment. Another possible use case: multiple sitelinks to the same site. For example, Wikidata may have a project page for postal codes in English, and someone wants a similar page in German. But the community does not want direct translation, because English page may want to cover the whole world, while the corresponding German page may only want to concentrate on the aspects specific to Germany. In short, we end up with multiple pages about the same subject, just like Wikipedia, that should have "sitelinks", but all pages live on the same wiki, and all would like to share the same wikibase item. P.S. (tangent) TBH, I am not a big fan of the language-based content division because languages do not map well to territories, but this may be the reality of that community, e.g. if postal codes are similar in Austria / Swiz / ...TASK DETAILhttps://phabricator.wikimedia.org/T86517EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Yurik, Wostr, Lucas_Werkmeister_WMDE, Stryn, Marsupium, Bugreporter, Esc3300, Susannaanas, Laddo, Agabi10, Thibaut120094, MGChecker, Sannita, Snipre, Candalua, Ricordisamoa, Rits, Liuxinyu970226, Aklapper, Lydia_Pintscher, daniel, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T189490: Solve search inconsistencies. Suggestion: Replace item selector search box with normal search box
Yurik updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION **User Story:**: As a user, I want to have consistent search behavior across wikis and at UIs that look the same **Context of use**: :** * For Wikidata: I assume the user would search mainly for items on Wikidata, but (with some search syntax) also for e.g. help or discussions**Current Problems:** Currently, we patch an item selector on top of the normal search box. This leads to inconsistencies e.g. as described in T63948 **Possible Solution**::** One way to improve the situation for the user to use the "normal" search input box. TASK DETAILhttps://phabricator.wikimedia.org/T189490EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Yurik, Aklapper, Nemo_bis, Wikidata-bugs, Smalyshev, PokestarFan, Liuxinyu970226, Jan_Dittrich, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T205560: Add option to disable Wikibase’ custom search box
Yurik added a comment. @Smalyshev correct. Ideally we should have T190454, but unless we want to stop using wikibase until it is ready, this is a good interim solution.TASK DETAILhttps://phabricator.wikimedia.org/T205560EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Smalyshev, Aklapper, Lucas_Werkmeister_WMDE, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T205560: Add option to disable Wikibase’ custom search box
Yurik added a comment. See also community discussion threadTASK DETAILhttps://phabricator.wikimedia.org/T205560EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Aklapper, Lucas_Werkmeister_WMDE, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T189490: Solve search inconsistencies. Suggestion: Replace item selector search box with normal search box
Yurik added a comment. @Jan_Dittrich I think context of use is correct for Wikidata, but not for some other Wikibase installations. Wikibase may not be the centerpiece of the wiki installation. For example, OpenStreetMap wiki has recently installed Wikibase extension. This caused some community members to complain that the searchbox suggester became useless - instead of showing useful information from the regular OSM wiki, it now shows just the wikibase items.TASK DETAILhttps://phabricator.wikimedia.org/T189490EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Yurik, Aklapper, Nemo_bis, Wikidata-bugs, Smalyshev, PokestarFan, Liuxinyu970226, Jan_Dittrich, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T190454: Display entity & article namespace completion search together
Yurik added a comment. This issue has raised a lot of concerns at the OpenStreetMap wiki after wikibase installation. Is it possible to disable wikibase search suggestions until this ticket is implemented? Thx!TASK DETAILhttps://phabricator.wikimedia.org/T190454EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Yurik, Lea_WMDE, Stryn, jeremyb, Ricordisamoa, matej_suchanek, He7d3r, Legoktm, MGChecker, Mbch331, thiemowmde, Beta16, XXN, JEumerus, PokestarFan, Ladsgroup, Nirmos, Txantimedia, Bene, EBjune, Yair_rand, EBernhardson, RazShuty, daniel, Lydia_Pintscher, Aklapper, Smalyshev, Lahi, Gq86, Darkminds3113, GoranSMilovanovic, QZanden, LawExplorer, Avner, Gehel, FloNight, Wikidata-bugs, aude, jayvdb___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T202676: Support non-Q items in custom Wikibase installations
Yurik renamed this task from "Support non-Q and non-P items in custom Wikibase installations" to "Support non-Q items in custom Wikibase installations".Yurik added a project: Federated-Wikibase-Workshops@NewYork-2018. TASK DETAILhttps://phabricator.wikimedia.org/T202676EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Nikki, ImreSamu, Aleksey_WMDE, WMDE-leszek, Lydia_Pintscher, thiemowmde, Bugreporter, gerritbot, daniel, Aklapper, Yurik, Gaboe420, LJ, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, SandraF_WMF, Bsandipan, Lordiis, Andrawaag, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, YULdigitalpreservation, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Daniel_Mietchen, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T204788: Self-hosted Wikibase has no API to search sitelinks
Yurik closed this task as "Invalid". TASK DETAILhttps://phabricator.wikimedia.org/T204788EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Addshore, Aklapper, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T204788: Self-hosted Wikibase has no API to search sitelinks
Yurik added a comment. @Addshore thanks! It does work indeed! I saw that many query modules were marked with Caveat: On a repo wiki, this module only works directly on entity pages, not on pages connected to an entity via a sitelink. This may change in the future., and I couldn't find any way around it. Thanks for the quick help! https://wiki.openstreetmap.org/w/api.php?action="">TASK DETAILhttps://phabricator.wikimedia.org/T204788EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Addshore, Aklapper, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T204788: Self-hosted Wikibase has no API to search sitelinks
Yurik updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...* Use internal scribunto API module: `{action: 'scribunto-console', format: 'json', title: 'Module:Sandbox', question: "=mw.wikibase.getEntityIdForTitle( 'Key:bridge:movable' )"}` - [[ https://wiki.openstreetmap.org/w/api.php?action="" | try it ]]. This is bad because it is not cachable, and because being internal, it could change at any moment.
* Create a dedicated protected Lua module, and use action="" to call itTASK DETAILhttps://phabricator.wikimedia.org/T204788EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Aklapper, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T204788: Self-hosted Wikibase has no API to search sitelinks
Yurik created this task.Yurik added a project: Wikidata.Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTIONInstalling Wikibase as both a repo and a client on the same wiki, and using local sitelinks makes it impossible to get Wikibase item by using the sitelink string via MW API.
For example, in OSM wiki, which is both a client and a wikibase repo, each item has a sitelink:
Q104 -> Key:bridge:movable. Note that the sitelink is shown at the top right corner using a CSS hack. The site name is wiki.
A very common operation is to get the item by knowing the Key:bridge:movable string. A user can navigate to it with the Special:ItemByTitle/wiki/Key:highway. Lua code can get it with mw.wikibase.getEntityIdForTitle( 'Key:bridge:movable' ). But there seems to be no clean way to do that via MW API, which seems like a big omission.
Some (bad) workarounds:
Use internal scribunto API module: {action: 'scribunto-console', format: 'json', title: 'Module:Sandbox', question: "=mw.wikibase.getEntityIdForTitle( 'Key:bridge:movable' )"} - try it
Create a dedicated protected Lua module, and use action="" to call it
TASK DETAILhttps://phabricator.wikimedia.org/T204788EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Aklapper, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T202676: Support non-Q and non-P items in custom Wikibase installations
Yurik added a comment. @thiemowmde @daniel my last patch only refactors Wikibase extension a bit, without touching the data model. It fixes the last few places I found that used direct Item ID parsing/composition, instead using the same common interface used by other code. Are there any concerns with that? For example, Lua function getSiteLink() used TermIdconstructor, whereas all other code in that same file used EntityParser instance. Merging this code should be a noop for Wikidata, and it may even simplify T114904 -- all related code may be in one place. Or it certainly shouldn't get in the way of the db migration. So if this patch has no impact on Wikidata, but helps us, could you merge it to help us? I do understand your point about the UI, but sadly that's the problem -- it is not just UI issue in OSM. The OSM ecosystem is much less centralized than Wikidata. There is no single editor to make it consistent. There is no common validation system. There is really only one "convention" that all tools understand -- that OSM data is stored as a simple key-value string table. Tools do not assume anything else about the data, e.g. semantic meaning of the keys, etc. So it is almost always up to the users to type in or copy/paste all values. One of the conventions is how Wikidata Q items are entered - e.g. wikidata = Q42. Any user in any tool can instantly tell that Q42 is a Wikidata item, and some tools even make it into a link using heuristics, e.g. if the key contains the word wikidata, and the value matches Qnnn regex, it shows as a link, but other tools simply show it as text. Most OSM users by now are fairly well versed in this. If we introduce OSM Wikibase, it will be stored in the same way - a text string, with some key. For example, if community decides to introduce a few items in OSM Wikibase, e.g. "type of OSM feature", and possibly one more "something else", the feature key-value table would look like this: keyvalue feature_typeQ123 wikidataQ456 something_elseQ789 As you can see, this is very confusing. We cannot suddenly change how we store Wikidata items - that will break all of the existing tools and data consumers. Requiring an`osm:Q123` style for osm-stored items would also lead to problems - many users will simply forget to type it in, and multiple OSM editing tools make it impossible to effectively enforce it. Having no way to visually distinguish the source of item will potentially create a chaos. I have already extensively tested my patch, and it seems that it solves what we need - effective way to store "osm items" as having different prefix. I'm sure I can work with other tools to adapt them to this need as well.TASK DETAILhttps://phabricator.wikimedia.org/T202676EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: WMDE-leszek, Lydia_Pintscher, thiemowmde, Bugreporter, gerritbot, daniel, Aklapper, Yurik, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T202676: Support non-Q and non-P items in custom Wikibase installations
Yurik added a comment. I think I figured out most of the code needed for item ID parsing/creation without calling new ItemID() directly. Submitted as a new patch ^, let me know if this approachTASK DETAILhttps://phabricator.wikimedia.org/T202676EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: thiemowmde, Bugreporter, gerritbot, daniel, Aklapper, Yurik, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T202676: Support non-Q and non-P items in custom Wikibase installations
Yurik added a comment. Spoke too soon: overriding entityTypeDefinitionsArray in a hook works well for creating/editing Wikibase items, but it does not work in some cases like sitelink lookups (used by wiki pages to find corresponding wikibase items). I think to make custom prefixes possible, all direct usages of the ItemId::* methods should only be made via the entity types table (overridable in a hook). For example, ItemId::newFromNumber() in SiteLinkUsageLookup.php usage. How can entityTypeDefinitionsArray be made available to that code?TASK DETAILhttps://phabricator.wikimedia.org/T202676EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: thiemowmde, Bugreporter, gerritbot, daniel, Aklapper, Yurik, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T202676: Support non-Q and non-P items in custom Wikibase installations
Yurik added a comment.
Update: I have implemented a custom extension that overrides default item https://github.com/nyurik/OsmWikibase :
public static function onWikibaseRepoEntityTypes( &$entityTypeDefinitionsArray ) {
$entityTypeDefinitionsArray['item']['entity-id-pattern'] = OsmItemId::PATTERN;
$entityTypeDefinitionsArray['item']['entity-id-builder'] = function ( $serialization ) {
return new OsmItemId( $serialization );
};
$entityTypeDefinitionsArray['item']['entity-id-composer-callback'] = function ( $repositoryName, $uniquePart ) {
return OsmItemId::newFromRepositoryAndNumber( $repositoryName, $uniquePart );
};
return true;
}
The OsmItemId extends ItemId class, overriding the 'Q' to 'Y'.
There are a few other places with 'Q' as part of the Wikibase extension, not in the model. I'm still trying to determine what they affect.TASK DETAILhttps://phabricator.wikimedia.org/T202676EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: thiemowmde, Bugreporter, gerritbot, daniel, Aklapper, Yurik, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193645: [Epic] querying for lexicographical data
Yurik added a comment. I think lex data dumps should be available independently of the other Wikidata data. For example, https://sklonenie-slov.ru/ shows all Russian noun declensions (30,000+), and I think such sites can greatly benefit from the community work. P.S. I have began a discussion with the site authors, trying to get them to donate their database to Wikidata.TASK DETAILhttps://phabricator.wikimedia.org/T193645EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Yurik, Lea_Lacroix_WMDE, Smalyshev, Aklapper, Lucas_Werkmeister_WMDE, Lydia_Pintscher, Mringgaard, Lahi, Gq86, Darkminds3113, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Darkdadaah, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T202676: Support non-Q and non-P items in custom Wikibase installations
Yurik added a comment.
@Bugreporter and @thiemowmde , thank your for the thorough responses!
Thiemo, just as Bugreporter mentioned, changing Q to [anything] is a big usability request. Here is an OpenStreetMap entry for Salzburg part of UI:
F25305354: image.png
A link to Wikidata is shown as a Q number, and the tag name ("wikidata") indicates the context. There are many other Wikidata tags like brand:wikidata and subject:wikidata. By now, most OSM users are very familiar with the Q numbers, so whenever someone is looking at the data, or talks on the forums, Q123 instantly gives everyone the context of what is being discussed without any additional information. Note that this is not a programming concept as one would do in the WDQS federated query, or a prefixed wd:Q123 value. Q123 is enough as it is.
The goal of our new project is to add a structured Wikibase store to the OSM wiki itself. This will allow OSM community to organize the keys (left side of the above table). For example, take a look at Key:place -- it's a big wiki page describing the place key, and a summary "info card" on the right side -- very similar to how Wikipedia organizes a lot of data. That info card should be stored in a Wikibase-backed store, e.g. OSM wiki's Item:Q123 to allow external tools usage. But introducing another set of Q-numbers will create confusion in discussions especially for the novice users. Seeing Q123 in a forum thread would no longer be unambiguous.
If, instead, we can set up OSM wiki to use another prefix, e.g. Y123, there would not be any ambiguity. It is OK for other sites to also use the same prefix -- it is highly unlikely that OSM will decide to use another site as a massive external reference site to cause significant confusion. Wikidata is uniquely positioned to be the central hub of the reference data, so we really only have two types -- the "local" and the "wikidata". Of course for the WDQS services, the OSM items will clearly have to be uniquely-prefixed.
I agree that the Q prefix should only be appended during the item creation, and only use an opaque string identifier everywhere else. What steps can we do to achieve that?TASK DETAILhttps://phabricator.wikimedia.org/T202676EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: thiemowmde, Bugreporter, gerritbot, daniel, Aklapper, Yurik, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T202676: Support non-Q and non-P items in custom Wikibase installations
Yurik updated the task description. (Show Details) CHANGES TO TASK DESCRIPTIONFor non-Wikidata installations, it would be beneficial to use letters other than Q for the Wikibase items. Custom installations still tend to rely on Wikidata as an external reference source, so having two types of Q numbers - those in Wikidata, and those in the custom Wikibase - tend to be highly confusing, especially for a large community-driven project like OpenStreetMapTASK DETAILhttps://phabricator.wikimedia.org/T202676EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: daniel, Aklapper, Yurik, stebsco, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T202676: Support non-Q and non-P items in custom Wikibase installations
Yurik created this task.Yurik added a project: Wikibase-DataModel.Restricted Application added a subscriber: Aklapper.Restricted Application added a project: Wikidata. TASK DESCRIPTIONFor non-Wikidata installations, it would be beneficial to use letters other than Q for items. Custom installations still tend to rely on Wikidata as an external reference source, so having two types of Q numbers - those in Wikidata, and those in the custom Wikibase - tend to be highly confusing, especially for a large community-driven project like OpenStreetMap. For example, if we have OSM-specific items, they should be easily distinguishable from Wikidata items - e.g. Y123 vs Q123. I have looked in depth at the code, and it seems Q has been hardcoded in a large number of places. Some of these places, like WikibaseDataModel do not appear to have a "settings" context, yet they have ItemId::newFromNumber() methods that use hardcoded Q. I will try to work on introducing this, but I may need some guidance on how best to do it. Thanks!TASK DETAILhttps://phabricator.wikimedia.org/T202676EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: daniel, Aklapper, Yurik, stebsco, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T196191: Support SPARQL returning WKT data as GeoJSON for Kartographer
Yurik renamed this task from "Support SPARQL POLYGON in Kartographer" to "Support SPARQL returning WKT data as GeoJSON for Kartographer". TASK DETAILhttps://phabricator.wikimedia.org/T196191EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Aklapper, Multichill, Lahi, Gq86, Looniverse, GoranSMilovanovic, QZanden, Orienteerix, LawExplorer, Ddproxy, JGirault, phabyogi, GAllegre, Susannaanas, ferdbold, lxbarth, Zache, Planemad, Wikidata-bugs, aude, Yurik, MaxSem, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T196164: Broken encoding in Lexeme's Language & Category entries
Yurik created this task.Yurik added projects: Wikidata, Lexicographical data. TASK DESCRIPTIONSwitching interface language to Russian breaks encoding of the lexeme's language and category entries. F18651356: image.pngTASK DETAILhttps://phabricator.wikimedia.org/T196164EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T192249: Support for non-integer Wikidata IDs (or alternative)
Yurik added a comment. @daniel sorry, let me clarify. The goal is to use Wikbase as a secondary documentation (metadata) for the tags, not as a tag storage replacement. We need to describe each tag, describe how they relate to each other, provide localized documentation, etc. OSM has multiple key-value tags (strings) for each object. The string keys could be represented by Wikibase entities (with some hacking to use string instead of integers to ID, per above). Some of these tags use "free form" values - like address - there is no need to store/document these in Wikibase, but we may store some validation information in the tags itself (e.g. store some regex in the "zip code" tag) Some other tags like religion imply a predefined list of values (enum). As you can see, there is currently a big list on that page, and that list could be stored in Wikibase. So the question is - should that list of values be stored as statements on the "religion" tag, or use a more flexible approach to store each as a separate entity, possibly in a separate namespace. Storing them as statements may make that entry too big (hundreds), and not offer enough flexibility. For example, for religion=pagan -- pagan should link to Wikidata's entry, and also may link to some other key to specify that it should/shouldn't be used with that, or it may point to another value as a redirect. So if values are stored in a separate namespace, what would be the good way to identify them? One way could be "religion=pagan" form -- include both the tag key and value. But this is bad because renaming is hard... so unsure of the best approach...TASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Pigsonthewing, Lydia_Pintscher, Micru, Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T192249: Support for non-integer Wikidata IDs (or alternative)
Yurik added a comment. @daniel this is awesome, thanks! The sitelink hack would probably be the best approach for the tag keys (e.g. name, address etc.) I am not yet sure of the best approach for the "enum-like" values -- some tags, e.g. religion tend to have a well-known list of values. It would be good to have a separate namespace for all the possible values for them. Enforcing uniqueness for them does not make sense -- same value could be used for more than one tag, and could have very different meaning. One option to store tag value would be to allow duplicates (use a regular string property to store the actual value), to reference all tag entities, and to use a bot to ensure that tags are referenced only ones per each unique value. Or it could be some on-db-update check...TASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Pigsonthewing, Lydia_Pintscher, Micru, Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T192249: Support for non-integer Wikidata IDs (or alternative)
Yurik added a comment. thx, clearly this wouldn't be used for wikidata. @daniel could you point me to the relevant code plz, or perhaps something similar, or maybe sketch the implementation approach? I was thinking that this would be the only real path to solve this, possibly with a custom database table to prevent accidental duplicates.TASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Lydia_Pintscher, Micru, Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T192249: Support for non-integer Wikidata IDs (or alternative)
Yurik updated the task description. (Show Details) CHANGES TO TASK DESCRIPTIONWikibase could be highly useful for other projects, such as organizing OpenStreetMap tags. ([[ https://wiki.openstreetmap.org/wiki/Talk:Wiki#Wikibase | see discussion ]]) The main difference with Wikidata usecase is that OSM has community-set string IDs, not integers. Storing string IDs as regular properties would cause a number of problems: they are not unique, they are mutable, they can be easily deleted, and there could be more than one defined per entryTASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T192249: Support for non-integer Wikidata IDs (or alternative)
Yurik created this task.Yurik added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONWikibase could be highly useful for other projects, such as organizing OpenStreetMap tags. The main difference with Wikidata usecase is that OSM has community-set string IDs, not integers. Storing string IDs as regular properties would cause a number of problems: they are not unique, they are mutable, they can be easily deleted, and there could be more than one defined per entry. Would it be possible to either have a user-provided entry key, or a special immutable single string value property? It might be even OK to allow such entry creation via API only, and not to have a UI.TASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T164773: Error replicating wikidata blazegraph setup
Yurik closed this task as "Invalid".Yurik added a comment. Seem like lowering the upload batch size fixed most of the memory issues. The system still crashes on occasion, but works okayish otherwise. Thx!TASK DETAILhttps://phabricator.wikimedia.org/T164773EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, YurikCc: Hjfocs, Gehel, Smalyshev, Aklapper, Yurik, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T181319: Support external tabular datasets in WDQS
Yurik added a comment. @Smalyshev the reason I made type as a string is to allow additional parsing parameters, e.g. ?start tabular:startDate 'date:-mm-dd' MultiSearchIterator and binding params Correct, most usages would be static, but in theory it might be possible to supply URL or other parsing params depending on some dynamic calculation and other data, right? Its not a must have requirement, but if there are no performance or other major disadvantages, I think it's better to support both? I am not sure what would be the best way to split WDQS and OSM code, yet package it together. Any suggestions? whitelist - agree, if whitelist exists, i think it should be used. TASK DETAILhttps://phabricator.wikimedia.org/T181319EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: NavinoEvans, Pasleim, Lucas_Werkmeister_WMDE, Smalyshev, Aklapper, Yurik, Lahi, Gq86, Darkminds3113, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T181319: Support external tabular datasets in WDQS
Yurik added a comment. The first version of this feature has been implemented in Sophox -- see docs. At this point, it supports any GET request that returns CSV-style data (parsable by Java's CSVParser, with many parameters). If @Smalyshev has any spare time to review the code at https://github.com/nyurik/wikidata-query-rdf/tree/tabular , I will try to port it to support .tab pages as well, with a slightly different set of input parameters.TASK DETAILhttps://phabricator.wikimedia.org/T181319EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: NavinoEvans, Pasleim, Lucas_Werkmeister_WMDE, Smalyshev, Aklapper, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T181319: Support external tabular datasets in WDQS
Yurik added a comment. @Lucas_Werkmeister_WMDE I agree - I am planning to implement this feature for both WDQS and Sophox QS. For WDQS, it should only support tabular datasets, or possibly other respected sources.TASK DETAILhttps://phabricator.wikimedia.org/T181319EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Lucas_Werkmeister_WMDE, Smalyshev, Aklapper, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T181319: Support external tabular datasets in WDQS
Yurik updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION... SERVICE wikibase:tabular {
# Data location
bd:serviceParam wikibase:url {.
# CSVFormat constant, e.g. EXCEL, MYSQL, RFC4180, TDF. Default = 'DEFAULT'
bd:serviceParam wikibase:csvFormat 'DEFAULT' .
# If true, treat the first row as header. Default - depends on csvFormat
bd:serviceParam wikibase:firstRowIsHeader true .
# Some way of column parsing is TBD.# If true, use tabular:, Here we extract two otherwise use tabular:<columnsn_number> (1-based)
# The prefix for the first column could be something else# By default, this value is the same as firstRowIsHeader
bd:serviceParam wikibase:csvColumnByName true .
bd:Date bd:serviceParam ?date . # output to ?date# Parse columns into variables by their name
bd:D?date bd:serviceParamType tabular:Date 'date:-mm-dd' . # date parsing# parse as date
bd?dateStr tabular:Close bd:serviceParam ?close .'string' . # unparsed date value
bd?close tabular:Close bd:serviceParamType ''double' . # parse as double' .
}...| ?date | ?dateStr | ?close |
| 2017-11-24 | 2017-11-24 | 315.55 |TASK DETAILhttps://phabricator.wikimedia.org/T181319EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Smalyshev, Aklapper, Yurik, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T181319: Support external tabular datasets in WDQS
Yurik updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...# Some way of column parsing is TBD. Here we extract two columns, and we filter by date # The prefix for the first column could be something else...# Extract a single date/close value FILTER ( ?date = "2017-11-24T00:00:00Z"^^xsd:dateTime )...TASK DETAILhttps://phabricator.wikimedia.org/T181319EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Smalyshev, Aklapper, Yurik, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T181319: Support external tabular datasets in WDQS
Yurik updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...'Date' bd:serviceParam ?date . # output to ?date# The prefix for the first column could be something else 'bd:Date' bd:serviceParamType ' ?date:-mm-dd' . # date parsing# output to ?date 'Close'bd:Date bd:serviceParam ?close .amType 'date:-mm-dd' . # date parsing 'bd:Close' bd:serviceParamType 'double' . ?close . # Extract a single date/close valuebd:Close bd:serviceParamType 'double' . } FILTER ( ?date = "2017-11-24T00:00:00Z"^^xsd:dateTime )# Extract a single date/close value } FILTER ( ?date = "2017-11-24T00:00:00Z"^^xsd:dateTime ) }...TASK DETAILhttps://phabricator.wikimedia.org/T181319EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Smalyshev, Aklapper, Yurik, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T181319: Support external tabular datasets in WDQS
Yurik updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...FILTER ( ?date = "2017-11-204T00:00:00Z"^^xsd:dateTime )...``` Expected result: | ?date | ?close | | 2017-11-24 | 315.55 |TASK DETAILhttps://phabricator.wikimedia.org/T181319EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Smalyshev, Aklapper, Yurik, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T181319: Support external tabular datasets in WDQS
Yurik updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION... SERVICE <https://www.quandl.com/api/v3/datasets/WIKI/TSLA.csv> {...TASK DETAILhttps://phabricator.wikimedia.org/T181319EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Smalyshev, Aklapper, Yurik, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T181319: Support external tabular datasets in WDQS
Yurik created this task.Yurik added projects: Wikidata-Query-Service, Commons-Datasets.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONWhat would be the best way to integrate WDQS with the tabular data, as well as other CSV sources? For example, if a large dataset provider publishes CSV or TSV files, and WDQS wants to federate with it, we could do something like this (this example should be modified as we flash out the exact interface)
SELECT * WHERE {
# This is a well known public data source for stock quotes - Tesla daily, first lines:
# Date Open High Low Close Volume Ex-Dividend Split Ratio Adj. Open Adj. High Adj. Low Adj. Close Adj. Volume
# 2017-11-24 313.79 316.41 311 315.55 3242220 0 1 313.79 316.41 311 315.55 3242220
SERVICE https://www.quandl.com/api/v3/datasets/WIKI/TSLA.csv {
# Some way of column parsing is TBD. Here we extract two columns, and we filter by date
'Date' bd:serviceParam ?date . # output to ?date
'Date' bd:serviceParamType 'date:-mm-dd' . # date parsing
'Close' bd:serviceParam ?close .
'Close' bd:serviceParamType 'double' .
# Extract a single date/close value
FILTER ( ?date = "2017-11-20T00:00:00Z"^^xsd:dateTime )
}
}TASK DETAILhttps://phabricator.wikimedia.org/T181319EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Smalyshev, Aklapper, Yurik, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T179991: Add a geo lookup service to WDQS based on the .map pages on Commons
Yurik added a comment. In T179991#375, @Base wrote: Label service is also very slow, like 2 times slower than to just query labels a normal way, considering that map data processing is probably more complex than just fetching a label I am afraid that it won't work for any real queries with current timeout… Label service is a disk IO operation. For every object, it must load some/all available labels, and pick the best. This service is fully in-memory and CPU bound -- you load the map once, cache it, and afterwards each point lookup is just an rtree search in a memory data structure.TASK DETAILhttps://phabricator.wikimedia.org/T179991EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Base, Lucas_Werkmeister_WMDE, daniel, Smalyshev, Aklapper, Yurik, Lahi, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T180314: WDQS geof:distance() throws an error on some P625 value
Yurik added a subscriber: Pnorman.Yurik added a comment. In T180314#3754292, @Lucas_Werkmeister_WMDE wrote: Duplicate of T175578? Might be related, but the issue is not that its a different planet, the issue is that geof:distance does not normalize its values before calculation. So if the longitude is +239.91, which I think is Ok (cc @Pnorman), in theory geof:distance should first normalize it to -180..+180 range, and perform calculations afterwards. Of course this can also be solved with the import sanitizer, but TBH I think geof:distance should be more versatile and handle every value. BTW, I tried to figure out if Mars was using the same -180..180 convention, but there doesn't seem to be much info on that in the wiki. Bummer :(TASK DETAILhttps://phabricator.wikimedia.org/T180314EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Pnorman, Lucas_Werkmeister_WMDE, Smalyshev, Aklapper, Yurik, Lahi, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T179991: Add a geo lookup service to WDQS based on the .map pages on Commons
Yurik updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...SERVICE wikibase:geolookup {
#--- INPUT ---
bd:serviceParam wikibase:data 'World Countries Outline.map' . # this is the .map page on Commons in the data namespace
bd:serviceParam wikibase:globe wd:Q2 . # The globe which is being searched. Optional, default it's Earth (wd:Q2)data 'World Countries Outline.map' .
bd:serviceParam wikibase:location ?location . # INPUT: ?location specifies the point to lookup# The globe which is being searched. Optional, default it's Earth (wd:Q2)
?countryWd wikibase:property 'bd:serviceParam wikidataId' .# Assigns geojson's wikidataId property to ?countryWdbase:globe wd:Q2 .
?countryIso wikibase:property 'isoCode' . # more than one property can be extracted from the same geojson feature# ?location specifies the point to lookup
} }
```
=== Usage as a lookup bd:serviceParam wikibase:location ?location .
# --- OUTPUT ---
**NOTE**: @smalyshev does not recommend this approach, as functions are not well suited for external data initialization, like services. # Assigns geojson's wikidataId property to ?countryWd
```lang=sparql ?countryWd wikibase:property 'wikidataId' .
?wd wdt:P625 ?location .# more than one property can be extracted from the same geojson feature
BIND(geof:lookup('World Countries Outline.map', ?location,countryIso wikibase:property 'iso') as ?iso)Code' .
} }
```
=== Algorithm...TASK DETAILhttps://phabricator.wikimedia.org/T179991EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: daniel, Smalyshev, Aklapper, Yurik, Lahi, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T179991: Add a geo lookup service to WDQS based on the .map pages on Commons
Yurik updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...=== Usage as a lookupservice
```lang=sparql
SERVICE wikibase:geolookup {
?wd wdt:P625 ?location .bd:serviceParam wikibase:data 'World Countries Outline.map' . # this is the .map page on Commons in the data namespace
BIND(geof:lookup('World Countries Outline.map', ?locabd:serviceParam wikibase:globe wd:Q2 . # The globe which is being searched. Optional, 'iso') as ?isodefault it's Earth (wd:Q2)
```
=== Usage as a service ?place wdt:P625 ?location . # ?location specifies the point to lookup
```lang=sparql
SERVICE wikibase:geolookup { ?wd wikibase:property 'wikidataId' .# assuming geojson contains wikidata IDs in properties, extract it (as a string) into ?wd
bd:serviceParam?iso wikibase:data 'World Countries Outline.map' . # this is the .map page on Commons inproperty 'isoCode' . # more than one property can be extracted from the data namespacesame geojson feature
bd:serviceParam wikibase:globe wd:Q2 . # The globe which is being searched. Optional, default it's Earth (wd:Q2)}
```
?place wdt:P625 ?location . # ?location specifies the point to=== Usage as a lookup
?wd wikibase:property 'wikidataId' .# assuming geojson contains wikidata IDs in properties, extract it (as a string) into ?wd**NOTE**: @smalyshev does not recommend this approach, as functions are not well suited for external data initialization, like services.
```lang=sparql
?iso wikibase:property 'isoCode' . # more than one property can be extracted from the same geojson featurewd wdt:P625 ?location .
} BIND(geof:lookup('World Countries Outline.map', ?location, 'iso') as ?iso)
```...TASK DETAILhttps://phabricator.wikimedia.org/T179991EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: daniel, Smalyshev, Aklapper, Yurik, Lahi, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T180314: WDQS geof:distance() throws an error on some P625 value
Yurik updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...Also, this seems to indicate that some other validation is failing, and an invalid P625`P 625` makes it into the WDQSTASK DETAILhttps://phabricator.wikimedia.org/T180314EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Smalyshev, Aklapper, Yurik, Lahi, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T179991: Add a geo lookup service to WDQS based on the .map pages on Commons
Yurik updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...=== Usage as a lookup ```lang=sparql...``` === Usage as a service ```lang=sparql...TASK DETAILhttps://phabricator.wikimedia.org/T179991EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: daniel, Smalyshev, Aklapper, Yurik, Lahi, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T179991: Add a geo lookup service to WDQS based on the .map pages on Commons
Yurik updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...```lang=sparql
?wd wdt:P625 ?location .
BIND(geof:lookup('World Countries Outline.map', ?location, 'iso') as ?iso)
```
```lang=sparql
SERVICE wikibase:geolookup {...TASK DETAILhttps://phabricator.wikimedia.org/T179991EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: daniel, Smalyshev, Aklapper, Yurik, Lahi, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T180314: WDQS geof:distance() throws an error on some P625 value
Yurik created this task.Yurik added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONSELECT
?wd ?loc
WHERE {
?wd wdt:P625 ?loc .
BIND(geof:distance("Point(0 0)"^^geo:wktLiteral, ?loc) as ?dist)
FILTER(?dist < 0.01)
}
I would think that geof:distance should not throw an error on invalid value, but instead either return unbound, or a NaN, but instead the whole query crashes.
Also, this seems to indicate that some other validation is failing, and an invalid P625 makes it into the WDQS.
Unknown error: EastWest: -290.38000
java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException: org.openrdf.query.QueryEvaluationException: java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.Exception: task=ChunkTask{query=9c55ede5-1891-4fae-a40e-a992b04277f6,bopId=3,partitionId=-1,sinkId=6,altSinkId=null}, cause=java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: EastWest: -290.38000
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:206)
at com.bigdata.rdf.sail.webapp.BigdataServlet.submitApiTask(BigdataServlet.java:293)
at com.bigdata.rdf.sail.webapp.QueryServlet.doSparqlQuery(QueryServlet.java:654)
at com.bigdata.rdf.sail.webapp.QueryServlet.doGet(QueryServlet.java:288)
at com.bigdata.rdf.sail.webapp.RESTServlet.doGet(RESTServlet.java:240)
at com.bigdata.rdf.sail.webapp.MultiTenancyServlet.doGet(MultiTenancyServlet.java:271)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:769)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1667)
at org.wikidata.query.rdf.blazegraph.throttling.ThrottlingFilter.doFilter(ThrottlingFilter.java:288)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)
at ch.qos.logback.classic.helpers.MDCInsertingServletFilter.doFilter(MDCInsertingServletFilter.java:49)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)
at org.wikidata.query.rdf.blazegraph.filters.ClientIPFilter.doFilter(ClientIPFilter.java:43)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1125)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1059)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:497)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:248)
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:610)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:539)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.util.concurrent.ExecutionException: org.openrdf.query.QueryEvaluationException: java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.Exception: task=ChunkTask{query=9c55ede5-1891-4fae-a40e-a992b04277f6,bopId=3,partitionId=-1,sinkId=6,altSinkId=null}, cause=java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: EastWest: -290.38000
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at com.bigdata.rdf.sail.webapp.QueryServlet$SparqlQueryTask.call(QueryServlet.java:865)
at com.bigdata.rdf.sail.webapp.QueryServlet$SparqlQueryTask.call(QueryServlet.java:671)
at com.bigdata.rdf.task.ApiTaskForIndexManager.call(ApiTaskForIndexManager.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624
[Wikidata-bugs] [Maniphest] [Created] T179991: Add a geo lookup service to WDQS based on the .map pages on Commons
Yurik created this task.Yurik added projects: Wikidata-Query-Service, Commons-Datasets.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONI think it would be a very valuable addition to have a generic polygon lookup function for the WDQS.
Use cases
Given a geo point, tell me which country/region/zip code/tectonic plate/voting district it belongs to
Historic geo lookups - use older map data
Non-earth lookups - regions of the moon/mars/...
Usage
SERVICE wikibase:geolookup {
bd:serviceParam wikibase:data 'World Countries Outline.map' . # this is the .map page on Commons in the data namespace
bd:serviceParam wikibase:globe wd:Q2 . # The globe which is being searched. Optional, default it's Earth (wd:Q2)
?place wdt:P625 ?location . # ?location specifies the point to lookup
?wd wikibase:property 'wikidataId' .# assuming geojson contains wikidata IDs in properties, extract it (as a string) into ?wd
?iso wikibase:property 'isoCode' . # more than one property can be extracted from the same geojson feature
}
Algorithm
Download commons:data:World Countries Outline.map page
Create (and cache) an RTree from all closed polygons. Should also handle multipolygons with holes.
For all ?location points, find the first polygon that contains it.
extract all requested properties from the found polygon
TASK DETAILhttps://phabricator.wikimedia.org/T179991EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: daniel, Smalyshev, Aklapper, Yurik, Lahi, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Reasno, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Base, aude, Tobias1984, Manybubbles, jayvdb, zhuyifei1999, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T174298: Figure out a way for WDQS example parsing not rely on parsoid
Yurik added a comment. @Smalyshev I suspect it will be relatively easy to do with the standard API - and if so, why not reuse the existing functionality? POST is a very small price to pay for this (think how often this feature is used - not worth creating a special parser just to avoid a few CPU cycles)TASK DETAILhttps://phabricator.wikimedia.org/T174298EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Smalyshev, Anomie, gerritbot, Lucas_Werkmeister_WMDE, Addshore, Wikidata-Query-Service, Aklapper, Yurik, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, merbst, Avner, Lewizho99, Maathavan, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T174298: Figure out a way for WDQS example parsing not rely on parsoid
Yurik added a subscriber: Anomie.Yurik added a comment. @Lucas_Werkmeister_WMDE manually doing regex-style parsing of Wiki markup in _javascript_ is a guaranteed path to hell. Trust me on this one :) CCing @Anomie - is there an easy api way to get resolved template parameters on a wiki page via a GET request.TASK DETAILhttps://phabricator.wikimedia.org/T174298EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Anomie, gerritbot, Lucas_Werkmeister_WMDE, Addshore, Wikidata-Query-Service, Aklapper, Yurik, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, merbst, Avner, Lewizho99, Maathavan, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T174298: Figure out a way for WDQS example parsing not rely on parsoid
Yurik added a comment. @Lucas_Werkmeister_WMDE I don't think it needs parsoid - OSM wiki doesn't have it as far as I can see, and this approach works there. @Addshore correct, this approach does require visual editor extension. I wonder if it would be possible to use action=""> instead.TASK DETAILhttps://phabricator.wikimedia.org/T174298EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Lucas_Werkmeister_WMDE, Addshore, Wikidata-Query-Service, Aklapper, Yurik, Lahi, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T174298: Figure out a way for WDQS example parsing not rely on parsoid
Yurik added a comment. I have already implemented this as part of my own override: https://github.com/nyurik/wikidata-query-gui/blob/master/wikibase/queryService/api/QuerySamples.js#L171TASK DETAILhttps://phabricator.wikimedia.org/T174298EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Addshore, Wikidata-Query-Service, Aklapper, Yurik, Lahi, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T176927: WDQS updater crashed
Yurik added a comment. I also disagree :) The real monitoring should not look at the process running at all. It should only look at the last timestamp - see how far behind WDQS is. If it gets behind further than X, send the alert - and that would be a very stable indicator that something is wrong - no matter if its the process that hung, or crashed, or simply cannot cope with the amount of data. On the other hand, the updater service itself should be resiliant to any kinds of problems - if there is an intermittent problem like a temporary DNS is down (like I had), the service will continue trying, and will self-recover the moment network is back up. This is the same logic as in any router or replication service - they always keeps trying until succeeding.TASK DETAILhttps://phabricator.wikimedia.org/T176927EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Smalyshev, Aklapper, Yurik, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T176927: WDQS updater crashed
Yurik added a comment. @Smalyshev I don't think updater should ever crash - regardless of the error. Even if the network goes down, it should go into a retry mode.TASK DETAILhttps://phabricator.wikimedia.org/T176927EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Smalyshev, Aklapper, Yurik, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T178786: Empty map results give an error
Yurik created this task.Yurik added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONBoth of these queries show unhelpful errors instead of a helpful warning message like "no data was found". Also, looking at the code, there seems to be no way for the visualizer to show a custom error message in the error band above visualizer.
Returns a single empty object
#defaultView:Map
SELECT ?place ?placeLabel ?location
WHERE {}
{
"head" : {"vars" : [ "place", "placeLabel", "location" ] },
"results" : {"bindings" : [ { } ] }
}
Returns empty response
#defaultView:Map
SELECT ?place ?placeLabel ?location
WHERE { wd:Q0 wdt:P0 ?location . }
{
"head" : {"vars" : [ "place", "placeLabel", "location" ] },
"results" : {"bindings" : [ ] }
}TASK DETAILhttps://phabricator.wikimedia.org/T178786EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Aklapper, Yurik, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T178222: WDQS UP arrow is broken (upper right corner)
Yurik created this task.Yurik added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery. TASK DESCRIPTIONThe "UP" button in the upper right corner does nothing. Try it at http://tinyurl.com/y95oylnsTASK DETAILhttps://phabricator.wikimedia.org/T178222EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Aklapper, Yurik, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T177734: License mismatch in wikidata-query-gui
Yurik added a comment. Well, according to Apache's own site we can - because anything submitted under Apache license is usable under GPL. Its like if someone submitted a patch under MIT, and I build a GPL software, i can simply copy paste MIT code without asking for permission. But legal may know better about this topic. BTW, I suspect this file was added when adding Vega Graphs capability about a year ago.TASK DETAILhttps://phabricator.wikimedia.org/T177734EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Lucas_Werkmeister_WMDE, Aklapper, Yurik, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T177734: License mismatch in wikidata-query-gui
Yurik created this task.Yurik added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery. TASK DESCRIPTIONSeveral pieces of code, as well as package.json specify GPL 2.0 as the license, whereas https://github.com/wikimedia/wikidata-query-gui/blob/master/LICENSE is for Apache. According to Apache site, any code under Apache license can be used with GPL software, so that should be no issue. The license file should say GPL 2.0 or laterTASK DETAILhttps://phabricator.wikimedia.org/T177734EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Aklapper, Yurik, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T176192: WDQS clone keeps freezing up on GC
Yurik added a comment. I saw the issue again, and filed a bug with the stacktraces - https://jira.blazegraph.com/browse/BLZG-9058 Seems like there is a lock contention of sorts.TASK DETAILhttps://phabricator.wikimedia.org/T176192EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Yurik, Smalyshev, Gehel, Aklapper, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
