Wikidata is an amazing site, holding probably the largest collection of general-knowledge structured data ever created, with over 1 billion statements; and serving as the backbone of the so-called Linked Open Data web. It is powered by Wikibase, the collective term for a set of MediaWiki extensions that allow a wiki to hold statements (or facts) that are multilingual, referenced, and queryable.
Perhaps it is no surprise that Wikibase has taken on a life of its own, with various organizations creating their own installations to hold their data, in the hopes of recreating some of the Wikidata magic. But they soon discover that Wikibase, in addition to its difficulty of installation, is also difficult to use: editing pages is difficult because there is only minimal indication of which properties are meant to go with which page types; and there are various complicating elements like references that, for the most part, are not needed in local Wikibase installations. Querying Wikibase's data is even more difficult, because it requires knowledge of the language SPARQL, a syntax-heavy query language that only a small number of people will ever master. And there is no native way to create even the simplest inline data display, like "list of all people".
In truth, there are better tools that exist for data storage in MediaWiki: the extensions Cargo, Semantic MediaWiki and Page Forms. These extensions are used by hundreds, or possibly even thousands, of wikis to provide a seamless interface for editing and displaying structured data. Unless your data set is heavily multilingual, there is no need to use the more awkward Wikibase software. (Semantic MediaWiki can even store its data in an RDF triplestore, enabling the same kind of SPARQL querying that is a central feature of Wikibase.)
Nevertheless, the use, or at least attempted use, of Wikibase outside of Wikidata seems to be continuing. Given that, we at WikiWorks offer a suggested suite of tools that make the use of Wikibase easier for installations of any size, from the smallest data sets to Wikidata itself; and we call this suite Enhanced Wikibase. It consists of existing tools (mostly written by us) that are entirely open source – and one proposed tool that would be released as open source as well. You can use all of these for free; with that said, we at WikiWorks would be happy to assist anyone who has a Wikibase setup and wants to make use of these tools.
Those looking at Wikidata for the first time may be surprised to see that there is no "aggregation" anywhere: no big list of all countries, or all cars, or all poems, etc.; let alone something more sophisticated like tables, maps and timelines. Wikibase somehow lacks the ability to query its own data. We don't mean to single out any Wikibase installation, but you can see one (painful) example of this on the Rhizome ArtBase wiki's artworks from 2007 page; if you look at the source for the page, you can see that this long list of artworks is simply coded by hand. Wikibase provides an enormously powerful storage system, and ironically no way to show any of its data.
Fortunately, there already is a way to query Wikibase data and display the results within the same wiki, using the MediaWiki extension External Data and, to a lesser extent, Cargo. External Data is a multi-purpose extension that lets you retrieve and display data from a large variety of sources: databases, files, APIs, etc. In this case, External Data can be used to retrieve the data from a SPARQL query and then display it in a variety of ways, from basic lists to more complex formatting. For the more complex formatting, Cargo is also used – not for data storage, but for the display formats it defines, including maps, calendars and timelines.
See this page for some examples of querying Wikidata's data from within a wiki. In this case, it is one wiki querying another's data; but this functionality could of course be used to have a wiki query its own data.
Another useful element in data-driven sites is a "drill-down" interface for browsing the data. This sort of interface lets users select values of different filters in order to find specific items, and to get a general sense of the layout of the data. It is often seen on e-commerce sites, but it exists in many other sites as well.
Anvesha helps users interact with the data in a variety of ways:
- Showing the high-level set of page types
- Showing, for each page type, what its stored fields are
- Letting users click through, to get a sense of the data
- Letting users find specific pages
- Serving as a SPARQL query building tool - note that among the links at the bottom of each page of results is the link "View SPARQL query" - which lets users see, and copy, the query used to create that specific set of results.
The use of Anvesha would probably be best done outside of the wiki, on a separate site, but it could certainly be linked to from the wiki, such as from the sidebar.
Wikibase does supply a rather powerful editing interface, but what it provides in terms of flexibility and internationalization, it sorely lacks in ease-of-use. There is no easy way to know what properties go with which page types - or which qualifiers go with which of those properties. And unfortunately, unlike for the other features, there is no existing tool that can be used to simplify Wikidata's editing process. That is why we propose to create a new MediaWiki tool that provides an additional editing tab that presents a more structured, and simplified, interface for editing data.
The basic approach of this editing tool would be to provide a new editing tab for each class/type that a page belongs to, based on its "instance of" properties. This tab, or tabs, would not replace the main editing, which happens directly in the main tab for any item; rather, it would serve as a helpful additional form, which displayed the standard set of expected fields for that class/type.
This figure shows what such a tab could look like for an item of type "room", i.e. one which has an "instance of" value set to "room". Let us say that, for the "room" class, the "properties for this type" property has the following values:
- has use
...and that, for the "image" property, the "qualifier for this property" property has the following values:
- point in time
This additional helper form simply uses what is defined for each class: the expected properties, their types (item, string, date, etc.) and their qualifiers, to display a simple form that makes it easier for users to enter the relevant data, without fear that they are doing something incorrect.
Where you see a downward-pointing triangle, that is meant to be an indication that this is input is a "combobox", which autocompletes on the current items stored in the wiki, in the manner of the main editor tab's inputs. Properties of type "item" would get this combobox, while properties of type "date" would get a date input, etc.
Please contact us if you want to discuss funding the creation of such a tool - or, for that matter, if you want to help in developing it.