Wikidata deletion request trends (RFDs)

Wikidata is a free and open knowledge base that anyone can edit. It is a sister project of Wikipedia and serves as a central repository for structured data, so rather than paving pages with text, it stores data in a structured format that can be queried and reused across different platforms.

One of the key features of Wikidata is its ability to handle deletion requests, which are known as RFDs (Requests for Deletion), a similar process happens on Wikipedia. These requests allow users to propose the removal of items from the database that are deemed unnecessary, incorrect, or otherwise unsuitable for inclusion.

I was recently asked if there was currently any “tracking of the amount of deletion requests on WD over time”, with a specific focus on promotional editing, number of requests, and administrator burden. I was not aware of any such tracking, so I decided to investigate the data and see what insights could be gleaned from it, and possibly help out with whatever then end up happening as part of T429036 [Analytics] [Request] Baseline data for Item deletions which looks like it will happen soon.

Approach

All of the requests for deletion go via the RFD page on Wikidata. This page is treated as a talk page, with each section being a request for deletion. Each section has a title, which is the item, or items being requested for deletion, and a body, which contains the reason and any discussion around the request. The page is often maintained by bots in terms of marking when deletions occur, and when requests are closed, so the page is a good source of data for analysis. And like many other talk pages, it is also archived, with older requests being moved to archive pages. The main RFD page has been around for a while, and the archive pages go back to 2012.

Data Gathering

I’m trying out marimo for my data gathering things time, when I would normally use a standard IPython notebook. It’s self described as “a next generation Python notebook”.

Read more

Editing wikibase.world (a MediaWiki site), with Jules (an AI agent)

I recently decided to run an experiment on wikibase.world: what happens when you give an AI agent the keys to a live MediaWiki instance and ask it to do some targetting gardening, including edits to Wikibase?

Meet the Jules free tier, though i’m sure you could use any agent. Over the course of a few hours, I tasked Jules with editing wikibase.world, moving from simple API edits, querying SPARQL, browsing external websites, and even learning how to properly participate in MediaWiki talk pages, requesting for me to edit its knowledge / prompt on a protected wiki page.

Onboarding and Basic API Usage

Before Jules could do anything, it needed an account. I asked it to register itself as “Addagent” using the MediaWiki API and handle the CAPTCHA and token requirements.

The prompt was:

Can you register me an account on https://wikibase.world/ I guess via https://wikibase.world/w/index.php?title=Special:CreateAccount&returnto=Project%3AHome or the API And then tell me the password The username should be “Addagent”

It went ahead and did this first time, and now https://wikibase.world/wiki/User:Addagent exists. To create the account it seemingly used https://www.guerrillamail.com/ which I have since changed to an actual email address I control incase I need to reset the account password (which I also noted down).

One thing of note while using Jules, is that it really is optimized for coding, and it continually reports that it is “Running code review…” between steps, even though there is no code repo and nowhere to commit code to and no real code in this project either, and it continually referred to “pre-submit steps” even though there is not going to be any code submission.

It looks like Python was used by the agent to perform the account creation, and that script included completing whatever CPATCHA it was served as part of the wikibase.cloud hosting.

The screenshot to the right shows the various steps completed by the agent, as it broke down the task to be completed.

A first edit, adding a description

Read more

Wikidata Map in 2025

This entry is part 17 of 17 in the series Wikidata Map

Another year, another map, and another Birthday for Wikidata. Last generated in 2024 by @tarrow and @outdooracorn, this year I have put the work in just ahead of the 13th Wikidata birthday to have a look at what’s changed in terms of items with coordinates this past year on Wikidata.

And here it is!

But really you need to look at the diff between previous years to see what has changed!

Read more

Wikidata, instance of and subclass of through time (P31 & P279)

Last month I looked at all Wikimedia Commons revisions and managed to generate some data and graphs for the usage of depicts statements since they were introduced on the project.

This month, I have applied the same analysis on Wikidata but looking at instance of and subclasses of items. A slightly bigger data set, however essentially the same process.

This will enable easy updating, of various pie charts that have been published over the years, such as

In future, this could be easily adapted to show per Wikipedia project graphs, such as those that are currently at Wikidata:Statistics/Wikipedia

Method

The details of the method can be seen in code in my previous post about depicts statements, and this mostly stays the same.

In words:

  • Look at every revision of Wikidata ever
  • Parse the JSON to determine what values there are for P31 and P279 for each revision
  • Find the latest revision of each item in each given month, and thus find the state of all items in that month
  • Plot the data by number of items that are P31 or P279 of each value item

There are some minor defects to this logic currently that could be cleaned up with future iterations:

  • Deleted items will continue being counted, as I don’t consider the point items are deleted
  • Things will be double counted in this data, as 1 item may have multiple P31 and P279 values, and I don’t try to join these into higher level concept at all

We make an OTHER and UNALLOCATED count as part of the final data summarization. OTHER accounts for things that have not made it into the top 20 items by count, and UNALLOCATED means that we didn’t have a P31 or P279 value in the latest revision.

2025

For August 2025 (or at least part way through it), this is the current state of Wikidata per the above method.

You can now find a PNG of this pie chart on Wikimedia Commons https://commons.wikimedia.org/wiki/File:Wikidata_P31_%26_P279_analysis_August_2025.png

Read more

What is Wikibase “Federated Properties” in 2025

I recently wrote a post looking at the history of the Wikibase “Federated Properties” feature. While at Wikimania 2025 the topic of federation came up a few times, particularly given the current discussions ongoing on the Wikidata project chat page including discussions about wikicite, and the recent Wikidata graph split.

All the code for the “Federated Properties” feature still exists in Wikibase code, despite a ticket being open on phabricator to potentially delete it. And it turns out that the configuration for it still exists on wikibase.cloud too, where the feature was initially presented to the communities to try out.

So with a little bit of sneaky “hacking”, I can try to summarize the current / final state of the “Federated Properties” feature, after development during the MVP stopped some years ago.

This also means you can still try out the feature on your own wiki using the setting.

$wgWBRepoSettings['federatedPropertiesEnabled'] = true;

Creating a local property

Firstly, we need a property, and the creation workflow is exactly the same as on a normal Wikibase.

Read more

What was Wikibase “Federated Properties”

The “Federated Properties” feature allows / allowed a local Wikibase instance to access and utilise properties directly from a remote Wikibase, primarily Wikidata. Its primary purpose is to enable partial federation between a local Wikibase and Wikidata, broadening the base of available data without needing to create a property set from scratch.

I’m split between using the present and past tense here, as all of this code still exists within the Wikibase extension, however no one has used it since 2022, and it certainly doesn’t seem to be on the short or medium term (or maybe even long term) roadmaps.

This overview comes from the Wikibase – Federated Properties Phabricator project, which I’ll quote the whole of here for prosperity.

Federated Properties v2 (2021)
An initiative to give users the ability to access remote properties from their local Wikibase and use them in combination with custom local properties. The primary use case is enabling partial federation between a Wikibase and Wikidata. This version of the feature will allow you to:

  • Opt-in to use Wikidata’s properties in addition to your own custom local properties
  • Create and view statements about local entities that contain both local and federated properties
  • Query your Wikibase using both local and federated properties

Federated Properties v1 (2020-2021)
An initiative to give users the ability to access remote properties from their local Wikibase (no local properties were possible in this MVP). This version was launched in the Wikibase Spring Release in May 2021.

As far as I remember, the project died with v2, and I don’t even recall if v2 really saw the light of day outside WMDE internal testing and or hidden testing on wikibase.cloud.

Read more

Wikimedia Commons Depicts statements over time

Wikimedia Commons now uses Structured Data on Commons (SDC) to make media information multilingual and machine-readable. A core part of SDC is the ‘depicts’ statement (P180), which identifies items clearly visible in a file. Depicts statements are crucial for MediaSearch, enabling it to find relevant results in any language by using Wikidata labels, as well as having pre precise definition and structure than the existing category structures.

SDC functionalities began to roll out in 2019. Multilingual file captions were introduced early that year, enabling broader accessibility, followed by the ability to add depicts statements directly on file pages and through the UploadWizard.

Although there are numbers floating around showing a general increase in usage of structured data on Commons, there didn’t seem to be any concrete numbers around the growth in use of depicts statements.

I was particularly interested in this, as must tool WikiCrowd is steadily becoming a more and more efficient way of adding these statements en masse. So I decided to see what data I could come up with.

Read more

WikiCrowd for 2025

I wrote the first version of WikiCrowd back in 2022 and haven’t really iterated on it much since, beyond adding the odd new set of image categories, and removing features that I decided were not optimum.

At the 2025 Wikimedia Hackathon however, WikiCrowd came up as both an entertaining little game to show people during beers, and also a project similar (ish) to something Daanvr was working on (I think it was Suggestion-Engine-Commons-prototype ?)

Upgrades

During the hackathon, and in the weeks following, WikiCrowd went through quite a number of changes

  • The YAML config files for the pre-calculated depicts statements are now on Commons for all to edit
  • Generation of the questions has been spruced up to stop it breaking as it gets deeper into category trees
  • Generation can now be triggered in the UI, as can deleting pending questions
  • The old one by one image mode was removed, and instead replaced by a grid mode
  • More categories and depict options were added
  • A custom grid view was added, allowing users to specify their own category and or Wikidata item
  • Ability to zoom in on an image being displayed
  • Addition of “levels” of questions
  • Display of Wikidata labels and descriptions in the UI (Making use of the new REST API)

Read more

Wikidata Map in 2024

This entry is part 16 of 17 in the series Wikidata Map

Another year on from the last generation of the Wikidata map, @tarrow and @outdooracorn spent some time in preparation for the Wikidata birthday to prepare a new map (see git commits).

The latest images have already been uploaded to Wikimedia Commons, and appear in the Wikidata map commons gallery.

In this post, I’ll have a look at what has changed in the past year that is visible from the map!

Read more

Visualizing Wikibase connections, using wikibase.world queries

This entry is part 1 of 3 in the series Wikibase ecosystem

Over the past week I have spent some time writing some code to start running a little bot on the wikibase.world project, aimed at expanding the number of Wikibases that are collected there, and automating collection of some of the data that can easily be automated.

Over the past week, the bot has imported 650 Wikibase installs that increases the total to 784, and active to 755.

I mainly wanted to do this to try and visualize “federation” or rather, links between Wikibases that are currently occurring, hence creating P55 (links to Wikibase) and P56 (linked from Wikibase).

251 Wikibases seem to link to each other, and Wikidata is very clearly at the centre of that web.

Read more