Old hand at Wiki[pm]edia . Information scientists. Working at German library network GBV.
Jun 13 2017
The Chopin example could be written like this to become a simple example:
May 29 2017
May 21 2017
The target page should be https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service - if this is no good starting point, the page must be improved instead of using another subpage.
Have a look at https://www.npmjs.com/package/wikidata-taxonomy for some previous work about creation of hierarchies from Wikidata. The tool includes some additional information such as number of instances and number of sitelinks and additional parents. A tree visualization could also show arbitrary additional information so it would be like the table visualization but with a special first row with the hierarchy. One must also make sure to handle multihierarchies.
May 20 2017
I wrote a short blog post about what I learned about Phabricator yesterday: http://jakoblog.de/2017/05/20/introduction-to-phabricator-at-wikimedia-hackathon/
May 19 2017
May 18 2017
Some of the pages could also be merged. For instance I regularly struggle to find anything on https://www.wikidata.org/wiki/Help:Properties or https://www.wikidata.org/wiki/Wikidata:Properties. It's confusing to have both Help:TOPIC and Wikidata:TOPIC anyway.
When and where are blog articles expected to be published? Sure I can post to my private blog (http://jakoblog.de) but I am also happy to focus on writing for another blog.
For shared writing of blog posts I recommed http://hackmd.io/ - it's similar to etherpad but Markdown syntax. You should be able to copy the resulting HTML into your blogging software and it can be converted to MediaWiki syntax with pandoc. Anyway collaborative real-time writing is helpful, I'm also fine with Google Docs or Etherpad. We could share links to the editable documents here, can't we?
Apr 5 2017
Apr 4 2017
Apr 3 2017
Mar 20 2017
Jan 2 2017
Dec 29 2016
Thanks, I ended up using 2.0rc5 and adding SPARQL capabilities to my own code. For my use case this issue can be closed but a new release of pywikibot is required anyway.
Dec 21 2016
Dec 11 2016
Sure the sources work but I want to release a tool based on pywikibot. My current requirements.txt contains pywikibot but the latest version is 2.0rc5 without SPARQL features. I don't mind which version number but new features must be releases to be usable. Having unreleased features in a developer branch makes sense but these features are deployed at PAWS and documented (?). Without releases it is hard to tell whether and how some feature are available or not.
Sep 29 2016
Jun 2 2016
May 27 2016
Oct 26 2015
At least the documentation lacks a clear description of this complex language negotiation mechanism (uselang is not mentioned. Meaning of 'strictlanguage' unclear, examples only refer to English).
Oct 24 2015
I found an example where even uselang and language does not help but part of the response is always English:
Oct 22 2015
I also stumbled upon this weird behaviour. The Accept-language HTTP header is also ignored but response language for some fields comes from a cookie (?!). Luckily parameter uselang can be used to control the response language but this should definitely be included in API documentation.
Oct 12 2015
This does not block me from using the service, as my client can produce valid SPARQL TSV output from SPARQL JSON output. It's a nasty violation of of SPARQL specification.
Oct 8 2015
This is kind of a subtask of https://phabricator.wikimedia.org/T114741
Oct 7 2015
The export should be available via request parameter format=csv or format=tsv.