Editing UseCases

= Use Cases: Federation in the Wikibase Ecosystem =

This wiki demonstrates, on a small live Wikibase ([https://federated-objects.de 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 ==

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 ==

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 ==

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 ==

{| class="wikitable"
! Capability !! [[UseCases/Ogham|Ogham]] !! [[UseCases/Software|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 ==

* '''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) ==

* '''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 ==

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]].''