User talk:Kind data

Welcome to Wikidata, Kind data!

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! --Epìdosis 17:00, 5 February 2021 (UTC)

Invitation to participate in research exploring Wikidata editors' experience of content gaps

Dear Kind_data,

I hope this message finds you well!

We are researchers at King's College London investigating how content gaps arise and can be measured in Wikidata. Currently we have explored existing research papers to identify several categories of gaps. However, we have noted a lack of consideration of editors’ experiences in this existing research and are keen to hear about editors’ views on and methods for identifying and addressing content gaps. While this topic has seen a lot of attention in Wikipedia, we believe Wikidata presents unique challenges and content which warrant further investigation.

We are reaching out as we understand you have previously taken part in a research study with our colleague Kholoud and thought as an active and experienced editor, you may be able to share your experiences with us. We would therefore like to invite you to participate in an interactive online workshop to explore this topic further.

This will consist of a 90 minute online call consisting of a group discussion and collaborative editing of a document (in Miro). We will ask you to rank gaps according to your familiarity and your opinion of their importance, give feedback on which types of metric might be most valuable to you as an editor and give some initial thoughts and potentially even sketches of how a content gap monitoring tool might look for Wikidata.

The main goal of the workshop is to understand your perspectives on how to measure and monitor content gaps as well as potentially identify further metrics or even to propose new methods to identify and quantify gaps in Wikidata. Participation is completely voluntary. All personal data will be kept confidential in compliance with GDPR. If you are interest in taking part, you can find out more about the workshop from our participant information sheet. You can also read more about the research at our meta page.

You can sign-up to take part from our registration form.

The workshop will take place online using Microsoft Teams. We are hoping to host the workshop in the coming weeks, but if you would like to take part and are unavailable during the proposed times, we may be able to find an alternative time.

If you have any questions or concerns, please do not hesitate to contact us at anelia.kurteva@kcl.ac.uk and neal.t.reeves@kcl.ac.uk

Thank you for considering taking part in this workshop and supporting our research.

With kind regards, Celestialtoast (talk) 20:27, 28 September 2024 (UTC)

Ontology course project

Hi @Kind data, I still don't have a project in the Ontology course and would like to join your book project, can I join it? If yes, what can currently be done to improve or act upon the project? Best regards, Arcstur (talk) 17:48, 11 June 2025 (UTC)

Hi! Yes, I'd love to have you join us. Please add your name as a participant on the project page: Wikidata:WikiProject_Ontology/Ontology_Course/Books#Participants. We're meeting on 7/18 at 8:30am PST (time zone converter). Can you join us? Thanks so much! Kind data (talk) 17:11, 12 June 2025 (UTC)

Certificate for the Wikidata Ontology Course

	Certificate of Completion
	This certifies that Kind data has successfully completed the Wikidata Ontology Course. Date: 2025-07-03    Issued by: Peter F. Patel-Schneider and Ege Atacan Doğan Thank you for your dedication to improving Wikidata’s ontology!

Egezort (talk) 16:18, 3 July 2025 (UTC)

Thank you for a wonderful course, @Egezortand @Peter_F._Patel-Schneider! Kind data (talk) 16:25, 3 July 2025 (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)

Notability

Thank you for contributing to Wikidata. I see that you recently created an item that does not clearly indicate its notability. The Wikidata project only accepts items that meet its notability criteria, and your item is therefore likely to be deleted soon. In brief, items must have an associated Wikipedia article, must be needed for statements on another notable item, or must have both identifiers and serious sources. For the last case, a good indication of notability would be multiple articles about the subject in independent publications like newspapers or magazines. You can add such sources as references to specific claims using reference URL (P854), or as top-level claims using described at URL (P973).

Also, this may not apply in this specific case, but you should know that we discourage editors from self-promotion, contributing on topics with which they have a strong personal connection, as this may present a conflict of interest. If you are being paid to edit here, then you are obliged to disclose this. For a longer version, you might find it useful to read the essay "How to create an item on Wikidata so that it won't get deleted".  Bovlb (talk) 07:05, 28 June 2026 (UTC)

I'm still working on the latest items and haven't finished them yet. Thank you for the reminder about the new notability policy. I am deeply concerned that this will eliminate items for records from marginal groups, or areas of study, as this set of book entities does. I have been editing Wikidata for six years and am disappointed by this turn in policy.

Many of these items are related to research and archival collections at Stanford University and Teachers College, Columbia University. For example, Jessie Dodd is a pianist associated with the piano roll archive at Stanford. There is not much known about this pianist but they are notable in that their work is held in university archives. It is possible that this item was not finished during an edit-a-thon. Some of them are lesser known authors and writers, many of them women, which is why I was adding them to Wikidata in the first place. I am deeply disappointed by the policy and its new consequences.

In the meantime, I will add more references to these items. How much time do I have before they are needlessly deleted? Kind data (talk) 17:23, 28 June 2026 (UTC)

Thanks for working to improve these items. I encourage you to add any identifiers and sources you have available.

Just to pick up on one point: I'm not sure why you refer to a new notability policy. The notability policy has not changed significantly for many years. There is an effort currently underway to improve it. Bovlb (talk) 17:52, 28 June 2026 (UTC)

It's my understanding that this message is part of the effort to enforce? recent improvements. I have not been notified in this manner in the past, and the community has always been understanding that items are not ever completely finished on the day it is created. Thanks! Kind data (talk) 18:09, 28 June 2026 (UTC)

Thank you for explaining your concerns.

I understand why suddenly receiving this message might give the impression that the policy has changed. The notability policy itself has not changed significantly for many years. What has changed is the development of better tools to identify items that appear vulnerable under the existing policy, allowing me to contact editors while there is still an opportunity to improve them.

Some of these items were created quite a long time ago, so I can only apologize that they were not brought to your attention earlier. Faster and more consistent notification are among the motivations for developing these tools.

My goal here is to help you improve these items and avoid their deletion. Thank you for working to improve these items. Adding identifiers and reliable sources is exactly the kind of improvement that helps.

I also appreciate your broader concern about documenting underrepresented people and subjects. I'm not trying to discourage that work, but to help it be more successful. We need to ensure that items contain enough information for other editors to maintain them in the future. Bovlb (talk) 18:44, 28 June 2026 (UTC)

I understand. Thank you! I look forward to cleaning these up and staying more on top of improving items I've created moving forward. What happens when an item gets deleted? Is the Q number deprecated? Is there any kind of list of deleted items? Thanks, again. Kind data (talk) 03:07, 29 June 2026 (UTC)

Thanks.

We're not rushing to delete these if you're able to fix them, but to answer your questions: The Q number will disappear and become just a log entry. Administrations can always find and undelete items later. Regarding finding deleted items, there's a little information at Wikidata:Guide_to_requests_for_undeletion#Why_was_it_deleted?. Bovlb (talk) 03:36, 29 June 2026 (UTC)

Nancy Green Saraisky (Q113411776), The Global Politics of Educational Borrowing and Lending (Q113443955), KARMA (Q114727383), Gabi Abrão (Q133272741), The Speak Angel Series (Q134533921), Descent of Alette (Q134538726), BIBFRAME 3.0 (Q137791591), Irene Di Giovanni (Q138296550), Jessie Dodd (Q138296555), Edna Hart (Q138296563), Collapsed mythologies : a geofinancial atlas (Q140371362), Eline Benjaminsen (Q140371366), Dayna Casey (Q140371375), Collapsed mythologies : a geofinancial atlas (Q140371384), Collapsed mythologies : a geofinancial atlas (Q140371394) Bovlb (talk) 07:05, 28 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 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)