Changing accessTokenURL will not work with Wikimedia wikis, for instance the default baseURL is https://meta.wikimedia.org/ so w/index.php must be appended. Changing userAuthorizationURL neither will work as mentioned at https://www.mediawiki.org/wiki/OAuth/For_Developers#cite_note-4 because of bug https://phabricator.wikimedia.org/T74186.

Just use the still existing repository location and do a new release at npm. I created a pull request at https://github.com/milimetric/passport-mediawiki-oauth/pull/3.

This has partly been implemented in wikidata-integrator but full support of DOIs requires this to be implemented.

Adding via DOI (probably from crossref data) is another ticket: https://phabricator.wikimedia.org/T172043

Seems to be a duplicate of https://phabricator.wikimedia.org/T107021

This is either not solved or not installed. The latest dcat-ap file from November 22th is broken: https://dumps.wikimedia.org/wikidatawiki/entities/dcatap.rdf (contains xmlns:rdf="")

Creating RDF/XML by hand is bad practice anyway, no matter in which programming language. The current script could be modified to use Purtle like other Wikimedia software, this would also solve the bug.

Yes, being able to query the information from dcatap would increase its usability a lot because WDQS is integrated in the Wikidata tool ecosystem. Having to download, parse, and evaluate the RDF file on your own requires RDF technology. There is no statement that WDQS content and described dumps are from the same date so I don't understand the problem. I think dcatap could be added and updated as named graph. Maybe this is related to Wikistats, I would also welcome a dedicated SPARQL endpoint with information about dumps and statistics - this endpoint could be included into WDQS via federated queries but I don't want to open a can of worms if there is a simple solution.

Seems to be fixed, at least in the current file.

The Chopin example could be written like this to become a simple example:

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.

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/

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?

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.

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.

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).

I found an example where even uselang and language does not help but part of the response is always English:

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.

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.

This is kind of a subtask of https://phabricator.wikimedia.org/T114741

The export should be available via request parameter format=csv or format=tsv.