Skip to content

Musing on lists

As some of you may know, I write the occasional tool to help support Wikipedia, Wikidata, Commons, and other projects in the WikiVerse. Most of my tools work on the same basic principle: Get some data to start with, think about it, and present a result. The input data is often a list of pages (or Wikidata items, which is similar), defined by some sort of query.

Now, the number of potential sources for such lists have been multiplying over the years. Off the top of my head, I can think of:

  • Manual lists (paste in a box)
  • Lists on Wikis (numbered, unnumbered, with or without links, with comments, in tables etc.)
  • Category trees
  • Category tree intersections (e.g. QuickIntersection)
  • More complex intersections of category trees, templates, etc. (e.g. CatScan2)
  • Wikidata Queries
  • Complex intersections of categories, WDQ, lists etc. (e.g. AutoList)
  • SQL queries (e.g. Quarry)
  • SPARQL queries (e.g. WDQS)
  • All the tools that use any combination of the above, and generate page lists in return, could be sources again

The problem, however, is more complicated than this:

  • Most tools that process lists could potentially use most of the above sources, or combinations thereof, even if this is not apparent at first glance; a Wikidata tool can still use lists of French Wikipedia articles, as they can be “converted” into corresponding Wikidata items, and vice versa
  • Any of these sources can be combined in several ways; e.g. only pages that are in list A and (list B or list C)
  • These can be combined with non-list properties (last edited less than a month ago, excluding bots; created over 5 years ago; edited by one of these users; use the matching talk/content page; no redirects)
  • This can be done recursively; the same source “types” can be used several times, in a complex query

I have previously tried to allow users to construct a query pipeline, combining the outputs of different tools, and processing (e.g. filtering) them through more tools in new and interesting ways. However, that attempt was not taken up, neither by users nor tool developers.

I tried again to solve the issue, this time by putting the “pipeline” into JavaScript, running right in the users’ web browser. However, usage numbers (except for a single, quite active user) show that again, there was no uptake by users in general.

Maybe I am the only one in the WikiVerse thinking about this? Maybe my attempts are still too clunky for the average user? Maybe there is just no demand, and all the tools run perfectly fine as they are?

There seems to be some general interest in lists; my list generating bot appears to be reasonably popular with users on Wikipedia, albeit not in the article namespace. And an experimental, manual list-generating feature called Gather on mobile Wikipedia seems to be popular. Maybe I am just missing the “killer application” for lists, though the point is that all tools and applications could benefit from list management.

The Game of Source

Wikidata has beautiful mechanisms to associate individual claims with sources for that claim. However, finding and adding such sources is surprisingly complex, and, between multiple open tabs and the somewhat sluggish interface, can strain the patience of the most well-meaning editor.

I had previously attempted to simplify adding sources to Wikidata statements; and while I believe this interface to be much easier to use than Wikidata proper, it is still clunky, and has issues on mobile.

Screen Shot 2015-06-01 at 22.18.35So, I went ahead and reduced the issue to its most basic form: Does a short text snippet support a specific claim? To achieve such a simplified interface, the following must happen:

  • A Wikidata item is picked (by random)
  • The associated Wikipedia articles are investigated
  • The external links of these articles are merged
  • The HTML for these URLs is retrieved, and HTML tags are stripped, leaving only the plain text
  • Claims from the item are prepared. This includes getting the label of “item statements” (Pxx => Qyy), and formatting the dates of “time statements” in various ways (2015-06-01, “June 1, 2015”, etc.)
  • The claim values (labels and dates, for now) are searched for in the HTML of the external URLs above
  • The hits, including some flanking text, are stored in a database

This process is repeated over and again. Finally, an interface presents the hits for a specific claim to the user. A single click can now add that URL as a source to the claim on Wikidata (via WiDaR), together with the original retrieval date (example). The entire set can be marked as “Done” (as in, don’t show this again to anyone), or skipped (claim goes back into the “pool”).

It is early days for this interface now. No doubt, many improvements are possible, and even though claims are added to the database in the background, there are only ~1,000 claims in there at the time of writing this. Patience.

Überlistet

User_Magnus_Manske_listeria_test_-_Wikipedia,_the_free_encyclopedia_-_2015-05-06_13.20.14One of the early promises of Wikidata was the improvement of lists on Wikipedia. These would be automatically generated and displayed, solving a number of problems:

  • Solve inconsistent lists on the same topic across Wikipedias
  • Keep all lists up-to-date
  • Track all possible members of the list via items, instead of per-Wikipedia red links
  • A single edit on Wikidata would propagate to all Wikipedias

Like many other features of Wikidata, this one has been delayed for some time now. With WDQ, and the upcoming SPARQL services, there are now several unofficial query services for Wikidata. It’s time to introduce a service for auto-generating lists now.

Which brings me to the pun of the blog entry title: It’s the German word for “outwitted”, but it could also be read as “super-listed”. Sadly, umlauts can still cause problems with non-German speakers and keyboards, so I run this tool under a biology pun name: Listeria (actually, a genus of bacteria).

How does this work? On Wikipedia (currently, English and German are supported, but it would be easy to add more), one adds a pair of templates to a Wiki page. Once a day (or on manual request), a bot finds those pages, reads the template parameters, and generates a WDQ-based list of items. The list is implemented as a table, to allow for various properties, including images, to accompany the entry. Items are linked to the respective article on the wiki, or to the Wikidata item if no article exists. The list can be auto-sectioned on a Wikidata property (e.g. the administrative unit of an item). Once generated, the bot compares the list with the one already on the page (between the two templates); if different, the bot replaces the list on the page with the new, up-to-date list.

My example page lists Dutch lighthouses, auto-sectioned by administrative unit. I made an English and a German version, using the same template code. They will both be updated at least once a day by the bot; the top template also generates a link to manually trigger the update for a specific page. Starting a new automatic list is as easy as inserting and filling the two templates into a page. So, Wikidata-based lists have arrived, after a fashion.

What’s that, you say? Your manual list contains more entries? Well, go to Wikidata, and create or link up items correctly so they all show on the automated list as well! Oh, your manual table contains more details? Add them to Wikidata! That way, any language edition of Wikipedia can enjoy the list and the information it contains. Also, comparing your list to the automatic one can highlight discrepancies, which may point to faulty information somewhere.

Don’t like lighthouses? How about 15th century composers instead, sectioned by nationality? Or 1980s video games, sectioned by company, ordered by date? Your imagination is the limit!

Now, if we only had numbers with units on Wikidata, so we could store the height of those lighthouses…

The games must go on

When I first announced the Wikidata Game almost a year ago, it certainly profited from its novelty value. Since then, it has seen a few new sub-games, and quite a number of code patches from others (which doesn’t happen often for my other tools!). But how does the game fare medium-/long-term?

With >200K “actions” (distinct game decisions, some of which result in edits on Wikidata) in March 2015 alone (an average of >6.500 actions per day, or one action every 15 seconds), it has certainly dropped from its initial popularity (>30.000 actions/day over the first ten days), but is still going. Let’s look at the long-term number of actions per sub-game:

2015-03-game

Most games show the initial “popularity peak”, which does seem to cause the cheapo trend lines I added to point downwards. Some games have started later than others. Some games have ended, because the users have won the game (that is, few or no more candidates remained).

So action numbers are down but stable. But what about distinct user numbers? Let’s look at the “people without birth/death dates” game as an example:

users_people_no_dateAgain, we see the initial peak drop off quickly to ~1/4 of its initial value; however, the number of distinct players remains between 75 and 100 per month, over the last 7 months.

All in all, it appears that the Wikidata Game is still in use, and contributing to Wikidata proper, one statement at a time.

Wikidata by country

Since November 2014, I have been collecting statistics on Wikidata by country, initially for Australia, France, New Zealand, and the United Kingdom. The raw, live numbers have always been online here, but staring at raw data has been known to result in aggravated academics. Therefore, I generated a few plot from said data, and accumulated them in a PDF (218kb). Data collection was interrupted for all countries but UK for some time, but I like to think that even patchy data can make for some interesting read…

Sex and artists

Now that I got your attention … Prompted by a post from Jane Darnell, I thought to quickly run some gender-related stats on artists in Wikidata. Specifically, the number of articles on Wikipedias for artists with a specific property, by gender.

First, RKDartists (at the moment of writing, 21,859 male and 2,801 female artists on Wikidata):

Number of articles on male (x axis) and female (y axis) artists with the RKDartists property. The line indicates the gender-unbiased coverage.

Number of articles on male (x axis) and female (y axis) artists with the RKDartists property.
The line indicates the gender-unbiased coverage. Only Wikipedias with >= RKDartist articles were used.

As we can see, not a single Wikipedia reaches the unbiased line; all Wikipedia are biased towards male biographies. English, German, Dutch, and French Wikipedia come closest, however, that may be due to reaching saturation (as in, almost complete coverage of all RKDartists) rather than intrinsically unbiased views. Otherwise, Finnish Wikipedia seems to be closest to unbiased amongst the “mid-range” Wikipedias.

Doing the same for ULAN (33,057 men, 3,100 women) looks a little better:

mf_ulan

Here, English Wikipedia has actually a tiny bias towards women. Breton and Maltese appear as “less biased outliers”.

I have uploaded both data sets here.

UPDATE: ODNB

mf_odnb

Pictures, reloaded

About four month ago, I blogged about Wikipedia pages vs. Wikidata items using images. In that post, I predicted that Wikidata would pass German Wikipedia in about four months’ time, so about the end of this month. Using the same metrics, it turns out that it’s a close run:

Site 2014-11 2015-03 Difference Per day
enwiki 1,726,772
enwiki (Commons only) 1,257,691
dewiki 709,736 729,577 19,841 182
wikidata 604,925 720,360 115,435 1,059
frwiki 602,664 623,400 20,736 190
ruwiki 491,916 509,436 17,520 161
itwiki 451,499 462,879 11,380 104
eswiki 414,308 425,399 11,091 102
jawiki 278,359 284,607 6,248 57

So, images in Wikidata items “grow” at about 1,000 per day, or ~900 faster than German Wikipedia. The difference has shrunk to ~9,000 pages/items. As there are 10 days to go for my prediction, it looks like I’m spot on…

Now, assuming a similar rate for enwiki, Wikidata should pass the Commons usage on en.wp in about two years.

Linkin mash

So I recently blogged about automatic descriptions based on Wikidata. And as nice as these APIs are, what could they be used for? You got it – demo time!

Linkin Park band member Dave Farrell has no article on English Wikipedia (only a redirect to Linkin Park, which is unhelpful). He does, however, have a Wikidata item with articles in 35 other languages. This is, essentially, the situation you get on smaller Wikipedias – lots of articles in other languages, just not in yours. There is information about the subject, but unless you can read any of those other languages, it’s closed to you.

On English Wikipedia, I created a template for this situation a while ago. Instead of a redlink, you specify the target and the Wikidata item, and you get the “normal” redlink, as well as links to Wikidata and Reasonator. An improvement, undoubtedly, but still rather clunky.

Thus, I resorted to something from the 90’s – a “mash-up” of multiple existing parts. A little bit of Wikipedia mobile view, my automatic description API, the Wikipedia API to render Wikitext as HTML, season with some JavaScript, and boom! we have a Wikipedia clone – with a twist. By default, this mash-up will happily display the Linkin Park article; however, under the “Band members” section (about the middle of the page), Dave Farrell now has just another, normal link:

Band section on Wikipedia

Band section on Wikipedia

Band section in the mash-up

Band section in the mash-up

The mash-up code recognized the code generated by the template on Wikipedia, and replaced it with a normal-looking, special link. Clicking on that “Dave Farrell” will lead to a live-generated page. It uses the automatic description API to get Wikitext plus infobox, then uses the Wikipedia API to render that as (mobile) HTML. And while the text is a little bit dull, it looks just like another Wikipedia page rendered through the mash-up, image and all.

I am well aware of the current limitations of this approach, including the potential deterrent to creating “proper” articles. However, with the much-hyped next billion internet users, many of them limited to the smaller Wikipedias, banging on our virtual door, such a mechanism could be a stop-gap measure to provide at least basic information in smaller languages, in a user-friendly way. Details of text generation for those languages, infoboxes, integration into Wikipedia proper, redlink markup, etc. would have to be worked out for this to happen.

Dave Farrell

Dave Farrell, as rendered by the mash-up


UPDATE: Aaaand… my template introduction has been reverted, effectively breaking the demo. I’m not going to start an edit war over this, you still have the screenshots.

Thy data, writ large

Ever since Rambot effectively doubled the size of English Wikipedia in a matter of days, automatic text generation from a dataset has been met with suspicion in the Wikiverse. Some text is better than none, for most readers, say some; but number-heavy, boring bot text is not really an encyclopaedia entry, and it could also take away some of the joy of writing, say others. To this day, it is an issue that can split Wikipedians into fierce combatant groups like little else.

Change of scenery. Wikidata is a young but vibrant Wikimedia project, and in many aspects still finding its shape. Each item on Wikidata can have a brief, textual description. This is helpful, for example in the current Wikipedia mobile app, where these descriptions are superimposed on a header image, say some; it is a waste of volunteer’s time to write a text that just reiterates the item statements, say others. Some (including myself) say that manual descriptions make sense for a few items, but the vast majority of items do not require a human to describe the item.

The solution for both above issues is, of course, bot-generated text on-the-fly; text that is written by software based on a data source, but that is not permanently stored. That way, essential information can be given to the reader, without discouraging writers, and without the need to maintain and update the bot-generated text, as it is never stored in the first place, but updated from the current dataset on demand.

I have previously written some code that does aspects of this; Wikidata search results are displayed on some Wikipedias (e.g. Italian) underneath the standard ones; they contain a brief, automatically generated description of each Wikidata item. And some people have seen my Reasonator tool, where (for some item types, and some languages) rather long descriptions can be generated.

But these examples are “trapped” in their respective tool or environment; other tools, websites, or third-party users have no way to get automated descriptions for Wikidata items easily. That is, until now. AutoDesc is a web API that can generate automated descriptions of almost any Wikidata item; the quality of the description improves with the quality of the statements in the item, of course.

And thanks to node.js, which is now available as a server on Wikimedia Labs (thanks to YuviPanda!), little rewriting of code was necessary; the “long description” generator is, in fact, the exact same source code used in Reasonator at this moment. This means that previous development by myself and other volunteers is not lost, but has paid off; and future improvement to either version of the text generator can simply be copied to the other.

The API can take an item number, a language code, and some other options, and generate a description of that item. It can return the description wrapped in JSON(P), or as an HTML page. It can generate plain text, wiki markup, or HTML with Wikipedia/Wikidata/Reasonator links. If you request the long description, it will automatically fall back to the short one if the item type or language for a long description are not supported (yet!).

Now, a word of caution: As I cobbled the text generation together from previously existing code, and code that was intended for use in a browser at that, things may not run as smoothly as one would expect. There is, in fact, little caching, and the cache that exists is not invalidated until the next server restart; an event that will be necessary to put new code live, and that will mean several seconds (the horror!) downtime for the API. If you base anything important on the API at this moment in time, homework will be eaten, data will be lost, and the write-everything-by-hand-fanatics will win. Be warned!

That said, I will try to improve the code over the coming weeks; if you want to help out, you can find the code here.

Red vs. blue

Recently, @notconfusing has been living up to his name by presenting us with preliminary results from the Wikipedia Gender Inequality Index. For me, that report is also an annoyance, because I was not aware this was going on, and had started to prepare my own research, with intend to publish, about the same topic. Fact is, I’ve been “scooped”, though not intentionally of course. Ah well, bygones. So that my (quite early) work was not entirely in vain, I’ll show some titbits of it here; interested parties, feel free to me for access to the the data and the full Google doc (which is not exactly in a polished state). All data presented here was collected in November 2014-January 2015, using either WDQ or Labs databases. As far as I can tell, my findings correlate well with @notconfusings, which is always nice.

Methods

WDQ was used to retrieve item counts for items marked as human (P31:Q5) on Wikidata, grouped by birth dates (P569) in the ranges of 0-1800, 1800-1900, 1900-1950, 1950-1980, and 1980-today. Item counts were further grouped by gender (P21), using male (Q6581097) and female (Q6581072) only (ignoring intersex, transgender, and genderqueer). Further subgrouping was done for items with identifiers from external catalogs (e.g. ODNB, VIAF), and for nationality (P27).

To compare biographical article sizes in Wikipedias, the replica database for Wikidata in conjunction with the respective language Wikipedia replica database were used. Items that link to either male (Q6581097) or female (Q6581072) items were retrieved. For these items, corresponding Wikipedia articles in a language were interrogated for their size, measured in bytes of Wikitext markup.

Results

Datasets

Wikidata had, at the time of writing, 2,634,209 items tagged as human, of which 2,363,146 (~90%) have a gender (P21) assigned. A total of 1,575,028 items that are human and have a birth date were found on Wikidata, of which 909,075 (~58%) have a nationality assigned.

Total change over time, by country

Starting with the basics, this shows the percentage of male biographical items in the individual time ranges. While there are less male (and, thus, more female) biographies in recent times, the spread (variance by country) increases as well. Notably, there are always “low male” outliers; this seems to be mostly Sweden, for some reason.

 

Change over time by region

These two figures show the male percentage faceted by region and time range. The figure on the right also shows it by country; darker blue means less %men=more %women.

Date ranges, faceted by region Faceted by region, raster by country

Biographical items gender by country

This figure shows the percentage of male biographical items by country, for countries with >= 30 items; blue=more male, red=more female. At a glance, one can see the male-dominated countries in Africa and South America, as well as the South-East Asian countries (which @notconfusing mostly calls “Confucian”, which I find confusing) with a high female percentage. “The West” appears to be stuck somewhere in the middle.

 map

 Number of articles per gender

This table shows the number of sitelinks (that is, Wikipedia articles, mostly) by gender. Interestingly, there are slightly more articles about women than men, though women have more items without sitelinks, and less images. This might be due to historical factors; there would be less images (remember, paintings cost serious money!) of women than men from before, say, 1900. Also, items about women are often created for “structural need”; the father and the husband both have an article, but to connect them, a new item about the daughter/wife is created, without sitelinks.

Male Female
Total items with sitelinks 1,973,773 367,194
Single sitelink (~63.1%) 1,245,727 (~62.3%) 228,619
Mean sitelinks per item 2.48 2.55
Items without sitelinks (~1.2%) 23,600 (~1.5%) 5,454
Items with images (~9%) 177,993 (~10.7%) 39,287

Size of biographical articles by language

For each wiki with at least 100 biographical articles, this figure shows the size (in bytes) of the article. A few “high-size” wikis were removed from this figure; they appear to make heavy use of unicode, thus increasing the byte size massively, though they roughly adhere to the same “shape”. Each dot represents a wiki; the dot size increases with the number of biographical items on the wiki. The X axis shows the mean bytes per male, the Y axis the mean bytes per female article. Wikis above the line have more bytes per women! The linear fit is surprisingly good (Pearson 0.9955423). According to the distance to the line, Mirandese Wikipedia is the most sexist one biased towards men, whereas Tamil Wikipedia is the most sexist one biased towards women 🙂

Comparison to other biographical sources

A quick comparison between biographical items that have both a birth date and an ODNB or VIAF identifier. It seems ODNB (>85% of ODNB entries have a Wikidata item!) is more sexist than VIAF, which is more sexist than the Wikidata per-country mean!

External catalog Wikidata items Overall male %
ODNB 29,017 89.6%
VIAF 447,758 85.3%

And as a plot, by time range:

Total gender ratio, ODNB, VIAFSummary

This would be “Discussion&Conclusion” in a proper publication, but as this is just a blog post…

Strong gender bias towards men exists in the number of biographical items on Wikipedia and Wikidata, however, this bias appears to be to a large degree due to historical and/or cultural bias, rather than generated by Wikimedians. Since our projects are not primary sources, we are restricted to material gathered by others, and so reflect their consistent bias. All the above data points to less bias towards men over time, and in Asian and (to a degree) Western cultures, a trend which is mirrored in other sources. It also shows that we have comparable numbers of articles about men and women, and comparable article sizes on Wikipedia, though the latter depends on the language to some degree; all Wikipedias with over 100.000 biographical items are on the “female side” of the article size distribution (data not shown, though it can be glimpsed in the article size plot), which would indicate to me that, given enough eyeballs, gender bias becomes less of an issue on Wikipedia and Wikidata.