Work on the long awaited query functionality for the Wikidata project has already happened during a period of several months. Since queries are a completely disjoint feature set from the existing functionality, we decided to put it into a new component part of the Wikibase software. This component is called Wikibase Query. WB Query is a MediaWiki extension that depends on the WB Repo extension. It’s responsible for providing query functionality bindings in the MediaWiki UI and web API.
The actual execution of queries is done via a component WB Query depends on: Wikibase QueryEngine. WB QueryEngine does not depend on MediaWiki and simply defines a high level interface to storing and querying Entity data. Entities are stored using ->insertEntity(Entity $entity) and queries are run with ->getMatchingEntities(a query object). The queries are defined using the Ask language, which I blogged about before.
The git repo that contains WB QueryEngine also comes with our first, and currently only, implementation of the WB QueryEngine interfaces. This implementation is called SQLStore, and as it’s name suggests is an implementation that works with relational databases. If you are familiar with Semantic MediaWiki, especially it’s internals, this should sound very familiar. The SQLStore is meant to allow us bootstrapping the functionality relatively quickly, and defer the decision of what other storage and query technologies we want to switch to a point where we will be better informed. If we create such an alternate implementation, the SQLStore will remain as a more simple to setup basic implementation, useful to developers and wikis that are not Wikidata.org scale.
The SQLStore uses a database abstraction layer to not bind itself to a particular relational database. We’ve just made big changes to the database abstraction layer used, which is the topic of my next blog post: Wikibase and Doctrine DBAL.
2 thoughts on “The Wikidata phase3 software components”