FactGrid

FactGrid is a Wikibase for historical data – we opted for the software with an eye toward the MediaWiki which we had been operating, which needed the support of a database. This decision had tremendous consequences, as it turned us immediately into a platform of international data-sharing within our field. Unlike Wikidata, we are an open identity platform: Our users get real-name accounts, and they must state their research interests. In return they can operate without notability criteria in an environment that explicitly encourages original research.

We started with a spreadsheet of some 7000 Illuminati documents and labeled our properties’ column by column without looking at Wikidata, a trivial process that created properties like “number of pages”, “archival holding”, “shelf-mark”, “author”, etc. The research-driven approach was attractive. Our observers realized that we could run practically any data model on our Wikibase. Today we try to learn from and synchronize with Wikidata, but we remain very independent and research-driven. A research project in need of a new property gets that property very fast.

I was a Wikipedia admin from 2006 to 2016. Thanks to our clear name policy,the FactGrid community is extremely friendly and supportive. Our first users were Wikiverse inhabitants. Soon, however, we were traveling in the currents of the ongoing software evaluations that involved examining Wikibase. In 2020, we were contacted by the emerging NFDI4Memory consortium with the news that we were among the avant-garde of databases in the field. Projects contacted us wanting to test the software; they stayed, since it was far easier to work within the community than to start a solo site somewhere else.

Wikibase is extremely bright software – it did far more than we wanted to do. The graph database modeling is uniquely open and flexible; the platform itself is as transparent as any MediaWiki.

The big challenges are the core assets of Wikibase themselves:

• the SPARQL search engine – how can anyone use it without knowing the database in the first place?
• the input interface – it is cool to create database objects without tedious input forms, but a massive task to establish data models in such an open environment.
• the data visualizations – this is where Nodegoat scores with better design and a clearer understanding of the visualiations projects are looking for.

How do we address these challenges? By investing in a Wikibase viewer, which, we hope, will gain more traction over the next years. The software itself is so incredibly cool that we can ignore all the present problems.