On Wednesday, 7 October 2026, I received an email invitation to attend an online interview about Wikidata.
In preparation for the interview, I decided to explore Wikidata and get a better grasp of its current state, both in terms of the system itself and the data it contains. Lately, I have been experimenting with building my own Wikibase clone, so I rarely interact with Wikidata.org anymore.
First, I visited the homepage.
I noticed a nice new addition: the “Related to current events” section. I love it.
One small suggestion: perhaps each item could include a short excerpt explaining why it is related to current events. I saw several items here, but for most of them, I had no idea why they were relevant to current events.
Well, except Soai and Kagan. A few days ago, I wrote a long article elsewhere about the recently announced recipients of the 2026 Nobel Prize in Chemistry, so I was already familiar with both of them.
I am also curious about how this section works. Are the items added manually? Is there a committee that decides which items are notable enough to be featured? Can anyone suggest an item for inclusion? I would love to know more.
Anyway, I decided to use this section as a starting point for my exploration. I clicked on Q24284511, Kenso Soai.
Whenever I randomly visit a Wikidata item, I usually look for an interesting property that I have never encountered before, something that I might find useful in the future.
One of the biggest hurdles I faced when trying to contribute more to Wikidata was the lack of properties available to properly model the knowledge I wanted to represent. Although proposing new properties is possible, the process can sometimes be intimidating for newcomers.
I have read several archived property proposals from the past, and some of the discussions were genuinely intimidating. At times, they felt almost as brutal as an average PhD defence. You have to ensure that a proposed property is consistent with Wikidata’s existing, consensus-approved ontology, which is enormous and involves many interconnected properties.
Back then, I tried to study Wikidata’s properties one by one. Despite all that effort, I still felt discouraged from proposing a new property myself.
Well, I did try a little. Some property definitions could arguably be expanded to cover certain edge cases. However, those discussions suddenly devolved into petty edit wars and personal disputes, so I simply gave up.
Anyway, let’s get back to the main topic: properties.
The most interesting property I found on Q24284511 was P101, field of work.
The item lists two fields of work: asymmetric catalyst (a type of catalyst that preferentially accelerates a reaction pathway leading to one enantiomer over the other; usually, the catalyst itself is also chiral), and reactive organic chemistry.
I made a small correction here. Originally, the labels were written as “Asymetric catalyst” and “Reactive organic chemistry”. As far as I remember, Wikidata item labels should generally be lowercase, except for proper nouns. So I changed them to lowercase.
However, the changes did not immediately appear on Q24284511’s page. I refreshed it repeatedly, but the labels remained unchanged. I wonder how Wikibase handles this internally. I guess, as long as the statement is not updated, they wont ever bother to update it?
Now, I had a small question : how could I query every field of work in Wikidata? I was simply curious and wanted to see what was out there.
I wrote a query and ran it on the Wikidata Query Service. Errors everywhere. HTTP 502 Bad Gateway, query timeout limits exceeded, and so on.
Eventually, I added a limit of 1,000 results, and finally, I could see something.
But then I encountered another oddity. A bug, perhaps? Or a feature? At this point, I am not sure.
I was using English (en) as the default label language, but some labels appeared to be missing. When I checked the corresponding Wikidata pages, I discovered that some users had removed the English labels, moved the English labels to the “default for all languages” field, and then semi-protected the item pages.
Huh. I wonder whether this is becoming the new norm. Interesting, I suppose, but it could break a lot of existing systems.
All right, let’s assume this is the new convention. I just need to modify my query a little, right?
Instead of requesting English labels alone, I added mul to the language preferences. However, plenty of items still have an empty “default for all languages” field, so I could not simply use mul and drop en altogether. I needed both, with mul taking priority and en serving as a fallback.
I crafted the new query and ran it.
Error.
Somehow, adding mul completely destroyed the query’s performance. Previously, retrieving 1,000 results had been manageable. Now, I was getting “query timeout limit exceeded” all over again. I reduced the limit to 500, but the query still timed out.
All right, I gave up.
I stopped using the Wikidata Query Service and switched to QLever instead.
I had to modify the query quite substantially, but that was fine. I had heard that QLever was faster.
And that was it. Done. Fast.
I retrieved all 50,974 items in my first attempt. I did not even need to impose a result limit.
Satisfied.
With those 50,974 items in hand, I started thinking about what else I could do with them.
I built a small web app to browse all those field-of-work items.
It loads 50 randomly selected items initially, then reveals another batch of 50 whenever I click “Load more”. The order is randomised each time I open the app.
I hope this little exercise in computer-generated serendipity will lead to some amazing discoveries. Perhaps I will stumble upon an obscure, fascinating field of work buried deep inside Wikidata’s database, or discover people who specialise in fields I have never even heard of.
After all, there are 50,974 possibilities to explore. Let’s see what I find.
See also : P136 - Genre