UseCases
Use Cases: Federation in the Wikibase Ecosystem
[edit | edit source]This wiki demonstrates, on a small live Wikibase (federated-objects.de), what "federation" actually means in practice — with two worked, end-to-end use cases:
- UseCases/Ogham — one object described across several Wikibases (statements on entities that live elsewhere).
- UseCases/Software — research software modelled by reusing Wikidata and extending it with a CodeMeta vocabulary.
Federation is not one thing. In these use cases we mean and need three distinct capabilities:
a) Wikidata federation — reuse Wikidata entities and properties
[edit | edit source]Use Wikidata as the reference source and reference ontology (Task Force terms): everything generic comes from Wikidata, so instances don't reinvent it and don't drift apart. Two mechanisms:
- Federated values — a statement's value is a Wikidata item (e.g. programmed in → wd:Q28865 Python).
- Federated properties — the predicate itself is a Wikidata property (e.g. wd:P31 instance of).
We exercise both, and can switch per statement between local, federated, or both side by side (see PROPERTY_MODE in each use case) — making the "with vs. without federation" difference visible on the same item.
b) Own properties and entities — where Wikidata has no fit
[edit | edit source]A domain always needs something Wikidata does not have a property (or item) for. The Task Force names this as a key driver for graph "splits": extra data on an item where no relevant property is in Wikidata. Our answer is not a silent fork:
- create local properties/items for the domain-specific part (CodeMeta fields; per-source identifiers; epigraphic detail), and
- record their Wikidata equivalent (a string equivalent Wikidata property) so the local vocabulary stays aligned and query-bridgeable.
This keeps domain autonomy without losing interoperability.
c) Wikibase-to-Wikibase federation — reuse entities and IDs across the ecosystem
[edit | edit source]The center is not only Wikidata. The same real object is often curated in several specialist Wikibases (FactGrid, Fuzzy-SL, Semantic Kompakkt, SquirrelBase, LinkedOgham…). We need to point at those entities and reuse their IDs so the ecosystem forms one coherent, queryable graph:
- per-source external-id + formatter URL → a resolvable IRI back to the source (the Task Force's "external ID back to Wikidata/source" pattern), enabling federated SPARQL across endpoints;
- strict identifier discipline — full entity URIs, never bare Q-numbers, because Q-numbers collide across instances (FactGrid Q1000294 ≠ ours).
This is the Task Force's hardest stated need — "statements in one Wikibase on an entity from another Wikibase" — approached with today's tools while native support matures.
The two use cases, mapped
[edit | edit source]| Capability | Ogham | Software |
|---|---|---|
| a) Wikidata entities + properties | ✔ generic layer (type, script, place, collection) | ✔ software ontology (developer, language, licence, …) |
| b) Own properties / entities | ✔ per-source IDs, CIIC/CISP, epigraphy | ✔ CodeMeta fields (dev status, CI, README, …) |
| c) Wikibase-to-Wikibase reuse | ✔✔ the core — 5 linked Wikibases | – (Wikidata reuse only) |
Together they cover the spectrum: Ogham stresses cross-Wikibase reuse (c), Software stresses Wikidata reuse plus a domain extension (a + b).
What we need from federation
[edit | edit source]- Combined querying — treat several inter-related Wikibases as one dataset (federated SPARQL across endpoints on an allowlist).
- Statements on foreign entities — natively, not only via external-id bridges.
- No identifier collisions — each Wikibase keeps its own Q/P space; references use full URIs.
- Prevent drift — reuse Wikidata (short lag, completion) and map local ↔ Wikidata equivalents explicitly.
What to watch out for (things we hit on this instance)
[edit | edit source]- url datatype is blocked → url fields are bridged as external-id + formatter (Ogham) or stored as string (Software).
- Federated Wikidata items render as "(Deleted Item)" via the API until registered once via the UI (alpha gap).
- formatterUrlProperty must be set server-side for external-ids to resolve to IRIs and be clickable.
- Label conflicts — a local instance of collides with the built-in P1; reuse the existing property instead of duplicating.
- Transient server errors (internal_api_error) on rapid writes — mitigated by retry + throttle.
Status
[edit | edit source]Both use cases are live and reproducible from a frozen model (one command each). What works today: Wikidata value + property federation, local properties with equivalence mappings, and cross-Wikibase links via resolvable IRIs. What still needs the software/instance: native Wikibase-to-Wikibase values, url datatype, formatterUrlProperty, and API-side resolution of federated entities.
Details and crosswalks: UseCases/Ogham · UseCases/Software.