I just got French text on https://www.wikidata.org/wiki/Q1035 but a purge fixed it.

Thanks. This is a known issue (cf. https://github.com/fnielsen/scholia/issues/53 and https://github.com/fnielsen/scholia/issues/189 ) for which we have not found a good solution yet.

Thanks all!

The problem seems to affect graphs in general, not just the two types mentioned above. Other examples are the Co-author graph and Academic tree graphs in author profiles, e.g. https://tools.wmflabs.org/scholia/author/Q8219 .

@WMDE-leszek Can you provide some more details on why this is to be phased out?

Thanks for working on this, @Addshore . Looking forward to see this resolved - had to cancel a demo of it due to the spam interfering.

Still hundreds of spam pages at https://wikibase-registry.wmflabs.org/wiki/Special:AllPages , and I don't see how to get rid of them at scale.

So far, spam seems to go exclusively to the main namespace, so perhaps it's worth restricting edits there to autoconfirmed users.

@Addshore My example is from Commons (see main page), but in case we allow local uploads (not sure about that right now), it would certainly be nice to be able to display these properly as well.

This now exists at https://phabricator.wikimedia.org/project/view/3356/ .

Another aspect of this would be to consider ShEx for selecting the data to be migrated. More info via https://phabricator.wikimedia.org/T192884 .

This would include considerations about

This sounds like something for ShEx: https://www.wikidata.org/wiki/Wikidata:WikiProject_ShEx .

This could also include tokens or API keys or things like that for the associated MediaWiki APIs or the respective SPARQL endpoints

@Magnus seems to be working on this: https://twitter.com/MagnusManske/status/986260652237967360

e.g. how to change the logo, license or user rights in a new Wikibase/ WDQS installation.

Find all other (registered) Wikibase instances that have information for "exact match" to something specific.

A good candidate query for a fresh Wikibase instance could also be to query the Wikibase registry for other instances of Wikibase.

We might also want to consider using some existing graphical UI for the SPARQL endpoint. One popular example is Blockly, and here are two papers that report on doing it for SPARQL:

• http://www.infomus.org/Events/proceedings/CHItaly2015/CHItaly2015/p86-bottoni.pdf
• http://ceur-ws.org/Vol-1456/paper12.pdf

Example for a user-friendly SPARQL interface
http://sparql-playground.nextprot.org/

Accessibility has multiple dimensions.

I like the suggestion of adding a load-dependent server-side delay for API edits.

There has been some erratic behaviour of this feature for Wikidata as well lately, e.g.
https://www.wikidata.org/wiki/Special:Nearby#/page/Q16896007
sometimes goes to where it would be expected, and sometimes to where the user is.

In T104762#3806240, @Smalyshev wrote:

Tabular data on Commons should be a good place for it, not? Do we need yet another place/way to store tabular data?

That seems like a good option indeed. In that case, we'd need a way to pull the data back into the WDQS for visualization.

I would suggest to start the items without a "published in" statement, and to build a tool/ Wikidata game/ Mix'n match catalog for reconciling those mismatches.

Here's a suggestion in terms of mechanisms to avoid malicious re-runs. I'm not sure how practical it is, but perhaps it helps us move forward