User talk:So9q

Previous discussion was archived at User talk:So9q/Structured Discussions Archive 1 on 2024-12-02.

Welcome to Wikidata, So9q!

Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!

Need some help getting started? Here are some pages you can familiarize yourself with:

• Introduction – An introduction to the project.
• Wikidata tours – Interactive tutorials to show you how Wikidata works.
• Community portal – The portal for community members.
• User options – including the 'Babel' extension, to set your language preferences.
• Contents – The main help page for editing and using the site.
• Project chat – Discussions about the project.
• Tools – A collection of user-developed tools to allow for easier completion of some tasks.

Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.

If you have any questions, don't hesitate to ask on Project chat. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.

Best regards!

Welcome to Wikidata, So9q!

Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!

Need some help getting started? Here are some pages you can familiarize yourself with:

• Introduction – An introduction to the project.
• Wikidata tours – Interactive tutorials to show you how Wikidata works.
• Community portal – The portal for community members.
• User options – including the 'Babel' extension, to set your language preferences.
• Contents – The main help page for editing and using the site.
• Project chat – Discussions about the project.
• Tools – A collection of user-developed tools to allow for easier completion of some tasks.

Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.

If you have any questions, please ask me on [[User talk:|my talk page]]. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.

Best regards!

Nomen ad hoc (talk) 07:30, 13 November 2019 (UTC).

Thanks!--So9q (talk) 07:33, 13 November 2019 (UTC)

Isom*rism

Please note that you have been adding many incorrect isomerism links (spotted 1741986224, verified by 1741987405 in first one of many backlinks). —Mykhal (talk) 08:26, 21 June 2025 (UTC)

Unfortunately I don't know of a tool capable of undoing this batch because it had been archived. If you know of a way to programmatically undo them all please let me know. So9q (talk) 13:59, 6 July 2025 (UTC)

Wikidata:Property proposal/OpenStreetMap key

As you wrote User:So9q/Comparison between wikidatawiki and openstreetmap database, you might be interested in Wikidata:Property proposal/OpenStreetMap key, which proposes proper separation of "OSM key" and "OSM tag" into two properties allowing for the removal of the prefixes "Key:" and "Tag:" and thus better linking, reduction of the overall WD database size and easier mapping between WD and OSM. OSMan2025 (talk) 21:58, 10 September 2025 (UTC)

Wikidata Platform Newsletter - January 2026

Please forgive the double message, this has the link fixes

This is the second issue of our new monthly newsletter! The next issue will be published in February 2026.

• User agent header policy: On August 29, 2025, the Wikidata Query Service (WDQS) was granted an exception to the WMF policy requiring API requests to have a user-agent header. This exception will be removed on February 18, 2026. This policy primarily impacts federated queries. To avoid regressions on existing workstreams, we encourage WDQS users to explore the following mitigation strategies:
  1. Configure a UA header: After reviewing documentation for the most common RDF databases employed by Wikibase users, we believe most impacted queries can avoid regression simply by configuring a user-agent string that is compliant with the WMF user-agent header policy.
  2. Adjust the directionality of a federated query: Query federation is a bidirectional process, meaning queries can originate from either WDQS and federate out or a separate knowledge base and federate into WDQS. There are compliance requirements for both options. Queries that originate in a separate knowledge base and use WDQS for federation will be blocked if they do not set an acceptable user agent header. However, queries that originate from WDQS only require that the target endpoint for federation is on the WDQS Allowlist. If users are unable to set a user agent header because of software limitations, they can switch the direction of their request by going through the process to get an endpoint added to our allowlist.
  3. Support use cases through different access points: If users are unable to set a compliant UA header or change the direction of their federated query, we recommend accessing the required data through alternative methods. The Wikidata Query Service is one of many ways that users can access Wikidata. Alternatives like data dumps, QLever’s Wikidata endpoints, and eventstreams may be a more suitable long-term solution. Read more about data access methods.

  Please direct questions on this change to the Wikidata Platform team on Phabricator.

• Migration office hours starting in January: The Wikidata Platform (WDP) is launching a new office hours series. We will host a 60-minute office hours session starting January 27th, 2026 and continuing on the first Tuesday of each month. The scope of this series will be limited to Blazegraph migration support for the entirety of 2026. General inquiries, feature requests, and troubleshooting help will continue to be offered through team processes on Phabricator and talk pages. Participants are encouraged to register in advance for each session and may optionally add a brief description of their migration-related questions to the shared Etherpad to help guide preparation. See Blazegraph Migration office hour page for more details

• Legacy endpoint decommissioning: The legacy full graph endpoint (wdqs-legacy-full) will be decommissioned on January 20, 2026. This WDQS endpoint was created to prevent negative impact to users with scholarly use cases following the graph split in March 2025 and was originally scheduled to be turned off in December 2025. This work can be tracked on Phabricator (T411410).

• Journal file available for download: As part of our efforts to mitigate regressions caused by the decommissioning of the legacy full graph endpoint, we will make a Blazegraph journal file for the entire Wikidata dataset (both scholarly and main) available via HTTP download at https://dumps.wikimedia.org once the service is decommissioned. This static file can then be used to build self-hosted instances of Wikidata Query Service and will be available until March 2026.

Udehb-WMF (talk) 11:21, 12 January 2026 (UTC)

Wikidata Platform Newsletter - February 2026

This is the 3rd issue of our new monthly newsletter! The next issue will be published in March 2026.

• WDQS Triple Store Evaluation Benchmark Results Report: We’ve completed an initial evaluation of alternative triple store databases to explore potential replacements for Blazegraph in the Wikidata Query Service (WDQS). Our goal was to gain hands-on experience with open source systems and assess which meet the minimum criteria for performance, features, operations, and governance. Virtuoso and QLever meet our acceptance criteria and demonstrate superior performance compared to the current Blazegraph baseline. Either system represents a viable path forward for WDQS modernization. Read the full report
• User agent policy enforcement: As announced in the January edition of this newsletter series, the WDQS exception to the user agent header policy is being revoked on February 18th, 2026 (T402959). This policy primarily impacts federated queries. To avoid regressions on existing workstreams, we encourage WDQS users to explore the following mitigation strategies:
  1. Configure a UA header: After reviewing documentation for the most common RDF databases employed by Wikibase users, we believe most impacted queries can avoid regression simply by configuring a user-agent string that is compliant with the WMF user-agent header policy.
  2. Adjust the directionality of a federated query: Query federation is a bidirectional process, meaning queries can originate from either WDQS and federate out or a separate knowledge base and federate into WDQS. There are compliance requirements for both options. Queries that originate in a separate knowledge base and use WDQS for federation will be blocked if they do not set an acceptable user agent header. However, queries that originate from WDQS only require that the target endpoint for federation is on the WDQS Allowlist. If users are unable to set a user agent header because of software limitations, they can switch the direction of their request by going through the process to get an endpoint added to our allowlist.
  3. Support use cases through different access points: If users are unable to set a compliant UA header or change the direction of their federated query, we recommend accessing the required data through alternative methods. The Wikidata Query Service is one of many ways that users can access Wikidata. Alternatives like data dumps, QLever’s Wikidata endpoints, and eventstreams may be a more suitable long-term solution. Read more about data access methods.

Please direct questions on this change to the Wikidata Platform team on Phabricator.

• LDF Endpoint Decommissioning: The Wikidata Platform and Wikimedia Deutschland teams have decided to decommission the WDQS LDF endpoint on February 18th, 2026 (T415696). This endpoint serves very limited traffic, which the WMDE reuse team is in the process of migrating to other data access methods that can support existing use cases. The hardware used to support the LDF endpoint will be reallocated to support the ongoing backend migration efforts.
• Team Phabricator practices: The Wikidata Platform team has a new Phabricator board. This board will serve as the team's main board, and all the team's backlog will live there. The team has completed the first Sprint, and from now on, all sprints will be milestones on that Phabricator board.

As a result, the Wikidata-query-service Phabricator board is no longer the point of contact for the Wikidata Platform team.

• Migration office hours: The first Blazegraph Migration Office Hour took place in January last month; meeting notes are available on the Etherpad. The next session will be held on 3rd March 2026. Please register in advance via the event page if you plan to attend. You’re also invited to add questions or concerns beforehand on the office hour Etherpad to help us prepare and address them fully.
  

This series is strictly focused on the Blazegraph migration work.

Udehb-WMF (talk) 11:50, 12 February 2026 (UTC)

Wikidata Platform Newsletter - March 2026

This is the 4th issue of our monthly newsletter! The next issue will be published in April 2026.

• Team communication update: Since November, our small and newly formed team has been developing our approach to sharing our work with the community and incorporating feedback. Migrating Wikidata Query Service’s infrastructure is a large and complex undertaking that serves many different audiences. Our goal has been to find the right mix of channels, engagement levels, and response times that allows us to reach the broadest possible audience with the resources we have.

Now that we have more of this structure in place, we are sharing project updates through regular newsletters and publishing reports and learnings on-wiki, where discussion pages are open for questions and comments. Our Phabricator board is available for flagging bugs or engaging in ongoing tasks. We also host regular office hours as a shared space for community members to raise questions and topics that may be relevant to others as well (next is in April). Questions added to the Etherpad will be addressed during those sessions.

The team reviews feedback shared through these channels and incorporates it where it helps advance our migration goals. While we aim to respond to questions within about a week when possible, we may not be able to reply to every individual point.

• Label and MWApi service migration : We’ve completed an analysis of the wikibase:label and wikibase:mwapi services. One or both of these services are used in more than half of the requests sent to the Wikidata main graph. Preserving the functionality of these features is a core requirement of our backend migration away from Blazegraph. Full results of this investigation can be found on Wikitech.
• Rate limits: Global rate limits for Wikimedia Foundation APIs were announced on March 2 and will be rolled out over the next month. These limits do not currently apply to WDQS, as we are still evaluating appropriate rate limits for our platform as part of our backend migration (ETA: July ‘26). In the interim, to protect against service interruptions like the ones observed during the week of February 23 following an increase in request volume and complexity, we have rate-limited a handful of identified users whose requests gridlocked our system. While details regarding specific actors have not been publicly disclosed (PII is involved) Wikimedia SRE deployed a workaround to a known Blazegraph bug that manifests under traffic spikes (T242453). While this does not solve the root cause of the problem, we expect it to increase WDQS reliability in the short term. We will continue to implement these spot fixes as needed until a more scalable solution is determined.
• Work in progress: traffic analytics and operations: In the February sprint, we dedicated time to improving analytics on traffic and query behavior, with a particular focus on query latency classes and volumes by user-agent. This work provides two main benefits: 1) it informs different access patterns and latency-bound quality-of-service considerations, and 2) it led to short-term improvements in the real-time metrics we use to operate WDQS. We introduced new panels in Grafana, as well as internal-facing analytics tools, to report error rates and latency buckets, as well as new alerts that trigger on trends indicating timeouts. This approach allows us, on one hand, to proactively react to traffic spikes before an outage impacts end users, and on the other hand, to define the observability requirements that our new target backend will need to meet.
• Work in progress: development and test infrastructure: In our previous newsletter, we published exploratory benchmarking that identified two candidate systems for Blazegraph replacement that met minimum requirements. The purpose was to gain experience with open source triple store implementations as we embark on the migration. Building on these learnings, one of our goals this quarter is to deploy test instances of Virtuoso and QLever on internal eqiad infrastructure, to gain experience operating both systems and supporting internal development efforts (T414443). We have now 4 hosts that serve main and scholarly data via QLever and Virtuoso (respectively). This work informed improvement ideas for our data infrastructure, and allowed us to refine our understanding of indexing times on graph splits. As part of this work, we modified the real-time index updater code base to remove hard dependencies on Blazegraph. While this is a work in progress, we can now update both QLever and Virtuoso indexes in real-time while reusing existing WDQS infrastructure (T414447). This allows us to experiment and load test traffic on infrastructure similar to Blazegraph-based WDQS, and is a milestone towards exposing a new backend to public traffic later this year. If you have experience operating Wikidata triple stores at scale, we would like to get in touch and exchange learnings.

Udehb-WMF (talk) 17:07, 12 March 2026 (UTC)

Wikidata Platform Newsletter - April 2026

This is the 5th issue of our monthly newsletter! The next issue will be published in May 2026.

• Q3 Wrap-up: We closed out the month of March by completing all of our team goals for the quarter. This work included setting up test environments for production-replay traffic testing using on-premises hardware, the next step from last quarter’s benchmarking analyses, defining data access guidelines for our platform, and solidifying details of our migration plan such as release schedule and target use cases. The results of our Q3 efforts are currently being reviewed with internal stakeholders and will be shared with the community soon as part of our broader communication on the upcoming Blazegraph migration.
• Q4 Plans: In Q4, the Wikidata Platform team is shifting from planning to execution readiness. We are focused on finalizing our migration plan, building out automated query validation to ensure correctness of the new service, developing a communications plan to smooth the transition, and beginning the technical build of our new architecture. In parallel, we are continuing work on platform access and Quality of Service (QoS) guidelines, including rate limiting and user authentication policies aimed at reducing system abuse, improving telemetry, and aligning with broader WMF standards. We will share more details and updates throughout the quarter.
• Upcoming Feedback Cycles: Within this month of April, we will share artifacts outlining our recommendation for a Blazegraph replacement and our proposed technical architecture for the Wikidata platform. We welcome community feedback on our plans-your input will help us smooth the transition and develop mitigations for impacted use cases. We will share more details about the upcoming migration once we’ve collected and incorporated community feedback, including a timeline of changes, query rewriting best practices, and migration support documentation for the soon-to-be launched endpoints.
• Team is Growing: Our team is growing! At the beginning of March, we welcomed Andrea Westerinen to the team as a contractor. In the coming months, Andrea will assist with the upcoming Blazegraph migration by creating technical documentation, providing query rewrite support, and advising on SPARQL requirements.
• Rate Limiting Updates: As announced in last month’s update, we are working closely with site reliability engineers (SREs) to protect against WDQS service interruptions caused by increased request volume and complexity. While we work towards migrating to a more scalable backend that’s more resilient than Blazegraph, we are selectively rate-limiting users when we observe a correlation between their activity and performance incidents. Additionally, we have deployed and fine-tuned auto-remediation measures to restart servers that have been gridlocked. The intention of these changes is to stabilize the WDQS experience for the community, which we have observed to be effective. If you believe you’ve been negatively impacted by these changes, please let us know.
• Runbooks for Common WDQS Issues:
  • Data reconciliation: Some WDQS users reported an issue where items deleted from Wikidata were still queryable (T407702). Here’s some background to explain the issue: WDQS is continually synced against Wikidata via a streaming-update data flow with automatic retrying in case of failure, but it can happen that an update is missed and never gets picked up by the streaming updater. This can cause Blazegraph’s state to drift from Wikidata’s. In this case, we determined that the Wikidata deletion events were indeed missed by the streaming updater, and we resolved the issue by manually running a tool that rereads the source of truth for a specific entity (or list of entities) and updates Blazegraph accordingly. We also added a Wikitech runbook to document this fix. After the migration we will have more options available for keeping WDQS’s data up to date, including regular bulk data syncing and reindexing pipelines.
  • High Lag troubleshooting: Over the last two quarters the Wikidata Platform team has been working with SRE teams to troubleshoot and proactively address queries and actors that are putting a strain on WDQS infrastructure. We reviewed existing metrics, alerts and Grafana panels, and tuned our instrumentation to emerging traffic patterns. We authored and shared a new runbook that guides Wikidata Platform engineers in troubleshooting and escalation, during periods of elevated WDQS load and user-facing query failures. This work is part of a broader operational excellence effort in which we are partnering with SRE and other teams at the Foundation to streamline cross-team collaboration and protect our infrastructure.
• Wikidata through Wikimedia Enterprise: On March 31st, Wikimedia Enterprise announced the launch of Wikidata APIs as part of the suite of Enterprise offerings. These endpoints are built to support high-volume access needs by commercial reusers. This new resource will provide right-sized solutions for some of the largest consumers of Wikidata and users of our platform, supporting our vision for stable and sustainable access to Wikidata for everyone. More details can be found in WME’s full announcement.

Udehb-WMF (talk) 17:20, 13 April 2026 (UTC)

Wikidata Platform Newsletter - May 2026

This is the 6th issue of our monthly newsletter! The next issue will be published in May 2026.

• Backend replacement and architectural design proposals: For the past few months, we've shared learnings from our investigations into backend replacement, and today we are sharing our recommendations for a new RDF database to replace and accompanying technical architecture for the migration away from Blazegraph as the backend of the Wikidata Query Service (WDQS). These documents outline the selected direction and how the new architecture is designed to improve scalability while making future backend changes easier.

We are inviting feedback from the Wikidata community and other WDQS users until 25th May 2026, particularly on:

1. Any important considerations we may have missed
2. How your WDQS use cases, tools, or workflows may be affected

We encourage you to share feedback on the migration discussion page. You can also join our upcoming office hour (Next tomorrow, May 12th) to ask questions and discuss your use cases.

To help identify higher-risk areas, we have created a page to track high-impact use cases and tools. This page is not intended to catalogue all WDQS usage, but to highlight complex or critical cases that may require additional attention.

• Blazegraph Migration Office Hour (May session): Our next Blazegraph Migration Office Hour will take place on Tuesday, 12 May 2026 (Tomorrow) at 16:00 UTC. This session is focused on supporting the migration away from Blazegraph as the backend of WDQS. Whether you have questions, need clarification, or want to discuss how your use case may be affected. You can register for the session via the event page.

In preparation, we encourage you to add questions, feedback, or migration-related support needs to this etherpad. This helps us shape the agenda and focus on the most relevant topics during the session.

Udehb-WMF (talk) 14:34, 11 May 2026 (UTC)

Wikidata Platform Newsletter - June 2026

This is the 7th issue of our monthly newsletter! The next issue will be published in July 2026.

• QLever as the New Backend System for WDQS: After reviewing feedback from the community on our architectural proposals shared last month (see Backend Replacement and WDQS Architecture Re-Design), we have decided to migrate to QLever as the new backend for the Wikidata Query Service. This decision has been aligned upon across partners in WMF, WMDE, and the QLever team. We are very excited about the improvements to performance and sustainability that this choice unlocks for WDQS users. We will continue to share details on the user-facing impacts of this decision, in future newsletters and on our migration project page, as the work progresses.

We encourage all members of the community to continue helping us identify higher-risk areas by reporting use cases on our high-impact use cases and tools page. This page is not intended to catalogue all WDQS usage, but to highlight complex or critical cases that may require additional attention.

• Migration Timeline: Following the decision to use QLever, we would like to share some key milestones for our migration. More details will be shared as we approach full implementation. Please note that all dates are targets and may change in the event of unforeseen challenges. Refer to the migration project page for up to date information.
  1. Exploration: (COMPLETED) From September through March, the team conducted traffic and benchmarking analyses to understand the needs of WDQS users and alternatives to our current system. This culminated in our final recommendations for a new backend and platform architecture, which have been reviewed and aligned upon across stakeholders.
  2. Installation: (IN-PROGRESS) In April, the team began building. The development of new QLever endpoints (ie. WDQS v2) is underway, as is the refactoring of our platform architecture. This includes work on indexing, update pipelines, and rewriting observed production traffic into the SPARQL 1.1 standard. We are on track to complete our build of the new endpoints by July 1st and transition into initial implementation. The query service will continue to be available in its current state through implementation phases.
  3. Initial Implementation: (NOT STARTED) WDQS v2, a new endpoint built on QLever, will be first available to a small number of pilot users. The team will work closely with this group to learn where improvements are needed and how we can best support users in independently migrating their use cases. A self-service hub will be published by October 1st. This will include learnings from our pilot group, guidance on how all users of WDQS can migrate their work flows, and documentation on best practices for adapting all Blazegraph dependencies to our new system or alternative endpoints where needed.
  4. Full Implementation: (NOT STARTED) The new endpoints will be scaled to meet the needs of the broader community and will be generally accessible to all. The original Blazegraph endpoints will still be available, but may experience service degradation beginning in February, 2027 as we reallocate resources to the new infrastructure and begin slowly winding down the legacy service. We aim to have all WDQS traffic migrated by June 30, 2027, at which time the Blazegraph endpoint will be decommissioned.
• Query Categorization and Testing: We have begun evaluating WDQS queries to identify Blazegraph-specific features and functionality. All bespoke query aspects need to be rewritten into the SPARQL 1.1 standard in order to work with the new QLever backend. We have documented our process for this work in two Wikitech publications on SPARQL Query Characterization and Test Architecture for QLever. These documents provide more detail on methodology and testing used to validate the correctness and performance across the new and old backends. They are intended as supporting technical references for contributors interested in the migration validation and benchmarking approach.
• 2026-05-08 incident report: On May 7, 2026, aggressive web scrapers began overwhelming the Wikidata Query Service (WDQS), triggering a multi-day service degradation that impacted both availability and lag SLOs. The excessive load caused Blazegraph to timeout for over half of users at peak, while also throttling the streaming updater, which blocked index updates and cascaded into edit throttling on wikidata.org itself. Initial mitigation on May 7-8 included depooling the eqiad datacenter WDQS deployment and applying rate limits based on sampled request data, but the outage persisted through the weekend. Full resolution came on Monday, May 11, when deeper analysis of WDQS logs revealed a scraper that had evaded sampled webrequest data used for initial rate limiting. Once a targeted rate limiting rule was applied to the scraper's signatures, timeout rates returned to normal. See the full incident report
• Blazegraph Migration Office Hour (June session): Our next Blazegraph Migration Office Hour will take place on Tuesday, 9 June 2026 (Tomorrow) at 16:00 UTC. This session is focused on supporting the migration away from Blazegraph as the backend of WDQS. Whether you have questions, need clarification, or want to discuss how your use case may be affected. You can register for the session via the event page.

In preparation, we encourage you to add questions, feedback, or migration-related support needs to this etherpad. This helps us shape the agenda and focus on the most relevant topics during the session.

Udehb-WMF (talk) 11:10, 8 June 2026 (UTC)

Wikidata Platform Newsletter - July 2026

This is the 8th issue of our monthly newsletter! The next issue will be published in August 2026.

• Documentation on Query Rewrites: As WDQS continues its migration off Blazegraph, queries that rely on Blazegraph-specific extensions will need to be updated to comply with the SPARQL 1.1 and GeoSPARQL standards. To support this, we are publishing documentation to help you identify affected queries and rewrite them, so your queries keep working through the migration and beyond.

This transition to standard SPARQL reduces vendor lock-in, improves interoperability with other triplestores, and ensures our codebase remains robust. Importantly, the specifics of these rewrites are doing more than just guiding manual code updates. The details define the processing logic for an upcoming tool designed to automatically convert Blazegraph queries into standard SPARQL for the QLever engine.

The query rewrite details are focused on four key areas:

1. Graph Analytic Services (GAS): See Blazegraph_Migration:_Rewrite_of_GAS
2. MediaWiki API (MWAPI) Service: See Blazegraph_Migration:_Rewrite_of_MWAPI
3. Label and Utility Services: See Blazegraph_Migration:_Rewrite_of_Label_and_Utility_Services_and_Functions
4. Geospatial Functions: See Blazegraph_Migration:_Rewrite_of_Geospatial_Services_and_Functions

We Want Your Feedback!

As we map out these transition rules and develop the automated QLever conversion program, your input is critical. Please review the Wikitech pages linked above and let us know whether:

• The rewrite rules cover your use cases
• There are edge cases or specific Blazegraph quirks that are not accounted for

Please share your thoughts, concerns, or examples of queries on the related Discussion pages of the links above, so we can ensure the automated converter works seamlessly for everyone.

• Technical Build Complete: We are preparing to onboard the pilot migration cohort at https://query-next.wikidata.org (and https://query-scholarly-next.wikidata.org).

The system architecture from the WDQS v2 design doc has been implemented and deployed on Kubernetes. We ran a successful end-to end-test and validated that the QLever deployment can pick up a newly built index, start to backfill it with real-time events, and once ready the database can be queried. The service returns valid results, metrics are properly reported and available in Grafana, and logs are shipped to Wikimedia’s Observability Platform. Upcoming work will be focused on performance optimization and improvements to the indexing and real-time update pipelines supporting the service.

• Timeline Update: As mentioned in our June newsletter, we are kicking off the Initial Implementation phase of the Blazegraph migration in July. After a few short weeks of final testing and iteration on the new endpoints, the first round of WDQS v2 users will be given access to the new endpoints so they can begin their migration. The QLever endpoints will become accessible to the broader community by October 1st, when we kick off Full Implementation, along with documentation on query rewriting.
• Reminder to Report Use Cases: We encourage all members of the community to continue helping us identify higher-risk areas, namely SPARQL queries that are highly complex, by reporting use cases on our high-impact use cases and tools page. As a reminder, any use case can be reported through this mechanism. The purpose of this page is to give the WDP team visibility into user-level migration needs.
• Blazegraph Migration Office Hour (July session): Our next Blazegraph Migration Office Hour will take place, Tuesday, 7 July 2026. This session is focused on supporting the migration away from Blazegraph as the backend of WDQS. Whether you have questions, need clarification, or want to discuss how your use case may be affected. You can register for the session via the event page.

In preparation, we encourage you to add questions, feedback, or migration-related support needs to this etherpad. This helps us shape the agenda and focus on the most relevant topics during the session.

Udehb-WMF (talk) 10:54, 3 July 2026 (UTC)

Wikidata Platform Newsletter - August 2026

This is the 9th issue of our monthly newsletter! The next issue will be published in September 2026. This is the 9th issue of our monthly newsletter! The next issue will be published in September 2026.

• WDQSv2 Scaling: Work in Progress: The new QLever public endpoints are serving live traffic and are generally available to pilot cohort clients for testing. Our partner team at WMDE started porting the Query UI to https://query-next.wikidata.org and https://query-scholarly-next.wikidata.org. We have also rolled out a number of improvements to support federation and increase availability of the service. We have stood up a new staging environment on Kubernetes. Lastly, we are experimenting with a bleeding edge version of QLever that significantly improves memory footprint and update performance, and supports index rebuilds without needing service restarts.

• SPARQL Query Re-Writing Tool: We have begun work on a tool that will rewrite Blazegraph-specific SPARQL queries into a format that is compatible with our new QLever implementation. This tool will apply the rewrite guidance we have published on WikiTech, offering an easier path for users to migrate to WDQS v2. The purpose of this tool is not to fully adapt all queries to the new endpoint, but to support users through their migration efforts. Development on the test infrastructure is underway and expected to be complete by August 14th. An evaluation of rewrite performance will be complete by September 4th, when we will share our results. We will iterate throughout the month of September and provide access to the tool by the first week of October.

• Reminder to Report Use Cases: We encourage all members of the community to continue helping us identify higher-risk areas, namely SPARQL queries that are highly complex, by reporting use cases on our high-impact use cases and tools page. As a reminder, any use case can be reported through this mechanism. The purpose of this page is to give the WDP team visibility into user-level migration needs.

• Blazegraph Migration Office Hour (August session): Our next Blazegraph Migration Office Hour will take place tomorrow, Tuesday, 4th August 2026. This session is focused on supporting the migration away from Blazegraph as the backend of WDQS. Whether you have questions, need clarification, or want to discuss how your use case may be affected. You can register for the session via the event page.

In preparation, we encourage you to add questions, feedback, or migration-related support needs to this etherpad. This helps us shape the agenda and focus on the most relevant topics during the session.

Udehb-WMF (talk) 17:10, 3 August 2026 (UTC)

Wikidata Platform Newsletter - September 2026

This is the 10th issue of our monthly newsletter! The next issue will be published in October 2026.

• Blazegraph Service Support in v2: In the last quarter, the Wikidata Platform team has investigated Blazegraph-specific features that are not one-to-one compatible with the SPARQL 1.1 standard and our chosen backend for the v2 system, QLever. Working with a contracted SPARQL expert, we’ve drawn the following conclusions on what will be supported and available in v2, what won’t, and how WDQS users can continue to support their use cases. Below is a summary of the impacted features.

Category	Feature	Status
Services	wikibase:mwapi	Evaluation pending
	wikibase:decodeURI	not supported in v2
	GAS	Supported in v2
	wikibase:box	Supported in v2
	bd-sample	Supported in v2
	bd-slice	Supported in v2
	wikibase:around	Supported in v2
	wikibase:label	Supported in v2
Functions	geof-globe	Supported in v2
	geof-latitude	Supported in v2
	geof-longitude	Supported in v2
	geof-distance	Supported in v2
	is-some-value	Supported in v2
Syntax	named-subquery	Supported in v2
	query-hint	Supported in v2

Queries that either do not use Blazegraph-specific features or use the features that can successfully be rewritten account for ~86.5% of WDQS v1 query volume. The only feature that cannot be supported, decodeURI, is largely a tool used to improve readability and only accounts for ~.4% of traffic volume. The MediaWiki API (mwapi) service, which accounts for ~13% of query volume on v1, cannot be supported by WDQS v2 with exact parity. Wikimedia Deutschland’s Reuse team is currently evaluating a path to support for mwapi service that leverages the other data access methods maintained by their team.

The underlying rewrite logic for these features can be found on Wikitech, where you can leave feedback directly on the discussion page. As mentioned in previous newsletters, a tool that will rewrite Blazegraph-specific SPARQL queries into a format that is compatible with our new QLever implementation is currently under development and will be released and demo’d for the community at the Query Service Days event during October.

• Query Service Days event: We are excited to announce the upcoming Wikidata Query Service Days (October 17-23, 2026), an online event focused on the migration of the Wikidata Query Service from Blazegraph to QLever. The event is organized by Wikimedia Deutschland in collaboration with the Wikimedia Foundation's Wikidata Platform team. It will be a space for the community to come together around this major transition.

This event is designed to:

• Update the community on the current state of the migration
• Help people get familiar with the new system and try it out
• Explain what is changing and what you need to adapt to
• Provide hands-on support for rewriting queries
• Give the development teams deeper insight into community use cases and concerns

The event will be fully online, with live sessions spread over one week (October 17-23). Sessions will be recorded and made available afterwards. We will try to cover different time zones by repeating key sessions at multiple times. Register here to get the access link to the event: Event:Query Service Days 2026.

• Rate Limiting update: Work on rate limiting is under progress for WDQS v2. Many targeted fixes have been deployed for WDQS v1 to protect against harmful use. In the new service, we will aim to implement cost-based rate limiting. This implementation is still being evaluated and will be experimented with over the coming months. Our end goal is to provide a stable service with equitable access to all users.

• Reminder to Report Use Cases: We encourage all members of the community to continue helping us identify higher-risk areas, namely SPARQL queries that are highly complex, by reporting use cases on our high-impact use cases and tools page. As a reminder, any use case can be reported through this mechanism. The purpose of this page is to give the WDP team visibility into user-level migration needs.

• Blazegraph Migration Office Hour (September session): Our next Blazegraph Migration Office Hour will take place Tuesday, 8th September 2026 at 16:00 UTC. This session is focused on supporting the migration away from Blazegraph as the backend of WDQS. Whether you have questions, need clarification, or want to discuss how your use case may be affected. You can register for the session via the event page.

In preparation, we encourage you to add questions, feedback, or migration-related support needs to this etherpad. This helps us shape the agenda and focus on the most relevant topics during the session.

--User:Sannita (WMF) (talk) 09:33, 2 September 2026 (UTC)

Wikidata:Property proposal/European Legislation Identifier

Hi @So9q, after adding some information about the European Legislation Identifier, I've found your withdrawn proposal regarding the ELI on Wikidata. In my opinion, such a property would be very useful, even if there's no single URI scheme for every ELI implementation. Personally, I would prefer a single ELI property over database-specific properties, since the ELI URI is an identifier in the first case, a locator only in second. Furthermore, every assigned ELI refers to a single European standard; additionally, countries are free to define multiple URI schemes for their ELIs (see, for example, Denmark's ELI schemes). So – what do you think about reactivating the proposal? I can do this myself, but I didn't want to proceed without your consent. Maybe, adding some national legislation ELIs as examples would be useful. Additionally, I would negate the "single-value constraint", since one legal source may have multiple ELIs assigned (see, for example, https://www.legifrance.gouv.fr/eli/loi/2004/7/9/ECOX0300083L/jo/texte and its alias https://www.legifrance.gouv.fr/eli/loi/2004/7/9/2004-669/jo/texte). I would be glad to hear your opinion about this. Fl.schmitt (talk) 05:53, 8 September 2026 (UTC)

Go ahead, I suggest you adopt it as yours 😀 So9q (talk) 06:37, 8 September 2026 (UTC)

Wikidata Platform Newsletter - October 2026

This is the 11th issue of our monthly newsletter! The next issue will be published in November 2026.

• Query Service Days event: We are excited to announce that the program of the upcoming Wikidata Query Service Days (October 17-23, 2026), an online event focused on the migration of the Wikidata Query Service from Blazegraph to QLever, is now online. You can check the program on the event page.

The event is organized by Wikimedia Deutschland in collaboration with the Wikimedia Foundation's Wikidata Platform team. It will be a space for the community to come together around this major transition. The program includes sessions on:

• • The migration to QLever, explaining what will happen and the timeline.
  • What is changing and how to adapt your queries.
  • Adapting queries together in workshop-style settings.

Live sessions are scheduled at different times over the course of the week to cover multiple time zones, and recordings will be available afterwards.

The event will be fully online. Register here to get the access link to the event: Event:Query Service Days 2026.

• Updating the Current Documentation for WDQS: As part of our work on moving away from Blazegraph and adopting QLever, we are reviewing the existing documentation about the Wikidata Query Service, consolidating what has accrued during the years and deprecating what will become obsolete once the migration is complete.

As of the end of September, published a revised and expanded Migration Guide with useful information about what is changing, the current timeline of events, how you can start to migrate your queries to QLever, and how to get more involved.

In addition to that, introductory content from the WDQS User Manual on mediawiki.org was removed when it was already covered in other places, and/or integrated into more appropriate pages, such as Wikidata:SPARQL tutorial. The remaining sections of the User Manual all relate to technical details of the current Blazegraph-based implementation. Some of these sections will become obsolete when Blazegraph will be fully deprecated, while some others will be replaced with v2 documentation, when ready.

• Clarity on service support in WDQS v2: In last month’s newsletter, a table featuring all known Blazegraph features and services was included that marked each as “supported in v2” or “not supported in v2.” Based on community feedback, we understand that this may have caused confusion about how each service will be supported.

To clarify: "supported" means that the functionality will be achievable through SPARQL 1.1 or QLever capabilities. Queries that use these features will still need to be rewritten. Guidance on the required rewrites is available in the WDQS Backend Migration Guide.

• Request Early Access to WDQS v2: As we continue to get our new service fully ready for production, we are happy to welcome users to test and begin migrating their use cases. The new endpoint is still under development and subsequently does not have any committed SLOs (yet). In addition to providing test traffic for your work flows, we welcome feedback on the experience and performance of the service.

Information for signing up and participating as an early adopter of WDQS v2 is available here.

• Outage Report - 21/09/2026: WDQS (query.wikidata.org) suffered sustained high replication lag (ElevatedMaxLagWDQS, >10min) across most of the eqiad/codfw fleet for roughly 48+ hours starting on September 21st. High lag also triggered Wikibase's edit-throttling protection mechanism, which began rate-limiting legitimate Wikidata bot writes as a side effect. Requests with low share of total request count but high share of total elapsed time and very few successful responses (e.g. few but extremely expensive queries) were found to be the main culprit of the incident. The queries were complex multi-join SPARQL (e.g., "monuments from the 20th century depicting a person with exactly two spouses and no children"), computationally expensive for Blazegraph well beyond their small LIMIT. We were able to resolve the issue with targeted blocks of the requestors sending the expensive queries and stabilize the system within 2 days of first alert. This event underscores the importance of our ongoing efforts to implement global rate limiting of WDQS (ETA: January, 2027).

• Reminder to Report Use Cases: We encourage all members of the community to continue helping us identify higher-risk areas, namely SPARQL queries that are highly complex, by reporting use cases on our high-impact use cases and tools page. As a reminder, any use case can be reported through this mechanism. The purpose of this page is to give the WDP team visibility into user-level migration needs.

• Blazegraph Migration Office Hour (October session): Our next Blazegraph Migration Office Hour will take place on Tuesday, 6th October 2026, at 16:00 UTC. This session is focused on supporting the migration away from Blazegraph as the backend of WDQS. Whether you have questions, need clarification, or want to discuss how your use case may be affected. You can register for the session via the event page.

In preparation, we encourage you to add questions, feedback, or migration-related support needs to this etherpad. This helps us shape the agenda and focus on the most relevant topics during the session.

-- User:Sannita (WMF) (talk) 10:26, 2 October 2026 (UTC)