wmde / wikidata-wikibase-architecture

Wikidata and Wikibase architecture documentation

Architecture Overview

Welcome to the Wikidata & Wikibase architecture documentation. The canonical place to read these docs is on Github Pages.

Here you will find a high level overview of Wikibase, its surrounding systems, and some details relating to specific cases and deployments such as Wikidata.

Systems are documented using arc42 structured templates. You can read more about this method at docs.arc42.org.

Wikibase Systems

Wikibase has expanded far beyond the initial MediaWiki extension that was created called Wikibase.

Multiple other MediaWiki extensions, and other surrounding systems now make up part of the Wikibase system landscape.

To simplify things the whole system is represented as Repository, Query Service and Client.

Other components

You may be familiar with other components, and should be able to easily navigate to their location using the table below.

Component	Parent System
Termbox & Termbox SSR	Repository
EntitySchema	Repository
Property Suggester	Repository
QualityConstraints	Repository
WikibaseLexeme	Repository
WikibaseMediaInfo	Repository
DataBridge	Client
Article Placeholder	Client
Query UI	Query Service
Query Builder	Query Service
Quickstatements	External tools

Contributing

If you would like to contribute to these docs then please read the dedicated contributing guide.

wikidata-wikibase-architecture's Issues

Write about the high level entity type dispatching pattern

Wikibase makes use of a generic service pattern, focused around entity ids, "dispatching" to specific implementations per entity type based on entity type definitions.
We should write about this as a high level concept that is reused around the place

Write about the high level concept of secondary data lookups

These secondary data lookups, primarily mysql tables, are added by Wikibase to allow more efficient lookup of data that would otherwise need to be requested from entities themselves.
(essentially specific indexes on parts of entities)

Lots of this would be covered in https://doc.wikimedia.org/Wikibase/master/php/md_docs_topics_storage.html

Write about current maxlag integration etc

Editor representation, automated vs non

While working on some docs today I found the desire to get rid of the right hand side of this diagram for simplicity.

I think a different framing, that may then also make sense for the stakeholder definitions further up would make sense.
This would divide Editors into Editors that want to use the API and editors that want to use the UI.
Of course, an individual can be both of these, however they have different expectations of the system, and also different interaction patterns with the system.

Perhaps API User / Editor and UI User / Editor are over simplifications?

Thoughts?

Represent how a property type such as datetime integrates with everything

Hopefully then we would have something to point to when we get questions like this

making it so that one can enter more specific time values (https://phabricator.wikimedia.org/T57755). extension? core code?

Document secondary term storage access and uses

Would be useful in the discussions ongoing on the [Wikibase] Experiences/doubts regarding bulk imports into Wikibase mailing list thread

Define "constraint definition" in glossary

While talking about https://phabricator.wikimedia.org/T269724 we had the question around what a "constraint definition" actually was.

E.g.

Try to represent Special:Import usage for importing entities

As it recently came up in https://phabricator.wikimedia.org/T289332

Add "Parser Function" to the glossary

This came up in a discussion around federation v2 and I realized there was nothing to easily link to in our arch docs.

Add high level quality constraints -> shellbox interaction to our architecture docs

I noticed that this ticket references diagrams https://phabricator.wikimedia.org/T285104

We should try to add the quality -> shellbox interaction to our architecture docs