How can this be escalated?

OK, there is a newer newsletter. But that's not a newer version of the information in the November newsletter, as far as I can tell. The wording in the inactive banner contains: "Either the page is no longer relevant or consensus on its purpose has become unclear." I don't think that either of these are the case and those who see the wording are likely to be misled.

This project is being revived for the 2026 GSoC.

https://www.wikidata.org/wiki/Wikidata:Wikidata_Platform_team/Newsletter_November_2025 is marked as inactive, with rather strong warnings about not being relevant. It this really the case?

https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update mentions this task so maybe posting this request here will be effective.

From https://www.wikidata.org/wiki/Wikidata:Database_download

Having a non-split query service available to interested users is going to be useful during the period from the end of the legacy service to the time that the new WDQS is available. This alternative service probably doesn't need the same uptime characteristics as even the WDQS.

It's well past 11/21. Has there been any progress?

In T405395#11238657, @gmodena wrote:

We are looking into AWS as a possible way to bootstrap experiments while we wait for on prem hardware. Given that we are memory bound, we are considering these two high-memory instances as a baseline:

• r8i.4xlarge: 16vcpus, 128 GiB ram.
• r8i.12xlarge: 48cpus, 384 GiB ram.

The evaluation of QLever on doubled Wikidata has some decent data to report on a preliminary basis. See https://www.wikidata.org/wiki/Wikidata:Scaling_Wikidata/Benchmarking/Phase_2_Preliminary_Report for the report.

My benchmarking used a machine with 16 cores (Ryzen 9950X) and 192GB of main memory, but I only ran one query at a time. Having lots of main memory is useful for measuring throughput with multiple queries running in parallel.

If you want to play around with loading Wikidata into QLever a 16-core machine is very useful as it can considerably cut down loading time.

In T405395#11222574, @BTullis wrote:

The main constraint is that qlever is designed for Ubuntu, not Debian, which presents some challenges.

I think that this is probably not as much of a barrier as you might think.

It's true that the Dockerfiles that are distributed with qlever are built using Ubuntu, but I'm fairly confident that we could make our own qlever image fairly easily, based on Debian.

We could set up a blubber/kokkuri pipeline that replicates the actions of the Dockerfiles, but with a Debian base image.

In T406140#11233770, @Lucas_Werkmeister_WMDE wrote:

FWIW, in T384344: Wikibase/Wikidata and WDQS disagree about statement, reference and value namespace prefixes we held that changing the prefixes in the TTL dump files (without changing the resulting URIs) was a significant change, not a breaking change.

I'm looking at the dumps from 20241028 and thereabouts (because those are the ones that I have benchmark data about and I'm doing some more benchmarking). Maybe some of the prefixes have changed since then and only data: is problematic.

I added links to the Phabricator pages of the mentors.
I added pointers to several Phabricator tasks related to the Distributed Game. These links can be used to find games implemented in the Distributed Game and other information that would be useful in the microtasks and throughout the project.

@Hanna_Bast Thanks for the detailed comments. I have updated the benchmarking code, which does output TSV files that are later analyzed to produce statistics. Many of the benchmarks are run in three variants - as-is, with only counts returned, and with DISTINCT added. The benchmarking code also records a bit of information about the output - counts for multiple results and a single value for single results. The latter provided the first indication that different engines produce different results for numeric and GeoSPARQL values.

Is there an easy way to get the resultant query sets as plain files?

More and more I run into incorrect information in Wikidata that I think would happen less if there was a good way of presenting usage instructions to users. The most recent example was for music (Q638), where Dmitry had to go in and clean out multiple incorrect subclasses. There is already Wikidata usage instructions (P2559) that can be used to hold these instructions so the only missing part is showing usage instructions more prominently. Couldn't it just be possible to put this property at the top of the displayed list of properties? That's not a great solution but it would be a good start. Even better would be to display more information when the item is used as a value, but that's a more complicated change to the Wikidata user interface.

I don't think that this is a duplicate of https://phabricator.wikimedia.org/T148154

How can I contribute to turning this vision into reality?

Based on a quick look at various Phabricator tickets and other information it appears to me that the only connection between the WDQS and Wikidata edit throttling is that a slowness parameter for the WDQS is used to modify a Wikidata parameter that is supposed to be checked by bots before they make edits. Further, it appears that the only reason for this connection is to slow down Wikidata edits so that the WDQS can keep up - the WDQS does not feed back into Wikidata edits, even edits by bots. So this connection could be severed by a trivial change to Wikidata and the only effect would be that the WDQS KB might lag behind Wikidata, either temporarily or permanently, and queries to the WDQS might become slow or even impossible without improvements to the WDQS infrastructure. I thus view it misleading to state in this Phabricator ticket that "performance issues [of the WDQS] cause edits on wikidata to be throttled", which gives the impression that the WDQS forms a part of the Wikidata editing process or some other essential part of Wikidata itself.

I was completely unaware that WDQS is so integrated into the inner workings of Wikidata. Where is this described? Was this mentioned in the announcement of the proposed change?

If 'unskolemizing' is a trivial step then that should be implemented by WDQS, instead of pushing it to every consumer (including indirect consumers) of Wikidata information, if this change is simply a change to make WDQS work faster.

In T244341#6113236, @Lucas_Werkmeister_WMDE wrote:

The difference is not with other SPARQL queries in the WDQS but against SPARQL queries in general (including SPARQL queries that use Wikidata URLs).

Is anyone proposing a change to Wikibase (or Wikidata)?

If divergence between Wikidata and WDQS is bad, then this proposed change has another bad feature as it turns the some value snaks into something that is less like an existential. And this proposed change is for both the RDF dump and the WDQS.
And then there is the problem of the proposed change requiring changes to SPARQL queries - not just a change, but a change from how SPARQL queries are writtern in just about any other context.

My view is that fewer breaking changes are to be preferred, and breaking changes in fewer "products" is to be even more preferred. So, again, I wonder why there is a breaking change proposed for the RDF dump instead of no breaking changes or limiting breaking changes to the WDQS only.

I don't understand why it was considered necessary to make a breaking change the RDF dump to improve WDQS performance when there is a solution that does not make a breaking change to the dump.

I added some technical content on this issue to https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Query_Service_and_search#Blank_node_deprecation_in_WDQS_&_Wikibase_RDF_model

What's happening to finish this task? P2559 has about 1790 uses, which is not an insignificant number, but P2559 is insignificant because it isn't prominently shown.

Of course it would by a breaking change. There is no formal spec of the JSON dump beyond the spec for the individual entities, but we have always said that the dump is a set (an array) of entities. Putting something in there that is not an entity will break consumers.

Right now, the JSON dump format is a sequence of JSON objects. Each of these JSON objects is a Wikidata entity. There is nothing preventing the dump format from having the first JSON object be information about the dump, including version of the dump format, version of wikidata format, time of dump, etc.