UseCases/Ogham

Use Case: Ogham (CIIC 81)

A single object — the Ogham stone CIIC 81 / UCC Stone Corridor IV — is described across five Wikibases plus Wikidata. We tie them together in one hub item (Q5) on this instance.

What we mean by federation here

This is the hardest need the Task Force names: "the ability to have statements in one Wikibase on an entity from another Wikibase." The stone's facts do not live in one place:

• Wikidata — the generic layer: object type (Ogham stone), script (Ogham), find place, current location, collection.
• FactGrid (Q1000294) — the inscription reading and related persons.
• Fuzzy-SL (Q74) — the (fuzzy) coordinates.
• Semantic Kompakkt (Q1247) — the 3D model.
• SquirrelBase (Q48) — the FAIR Digital Object + Zenodo DOI.
• LinkedOgham (Y50000081) — the LOD record.

The hub reuses Wikidata for the shared layer and links to each specialist record for the domain detail — without copying it.

Why a Wikibase ecosystem, not Wikidata alone

• The domain detail (inscription epigraphy, fuzzy spatial models, 3D scans, FDOs) is too specialised / not notable enough for Wikidata. Each community curates its own Wikibase.
• Federation ties these into one queryable graph without duplication or drift — the Task Force's "combined querying" and "prevent splits" goals.
• Concrete example: the inscription C[A]SSITT[A]S MAQI MUCOI CALLITI stays authoritative in FactGrid. The hub carries only a reference to it, and a one-hop federated SPARQL query pulls it live at query time.

How it works technically

• Generic values: native Wikidata value federation (e.g. instance of → wd:Q2016147).
• Cross-Wikibase links: external-id + formatter URL per source (e.g. FactGrid ID = Q1000294, formatter https://database.factgrid.de/entity/$1). This yields a resolvable IRI in the RDF → traversable by federated SPARQL. This is exactly the Task Force's "external ID back to the source" pattern.
• Provenance: materialised values (coordinate, inscription) carry a reference to the source Wikibase.

What to watch out for (things we actually hit)

• Identifier collisions. Q-numbers repeat across instances (FactGrid Q1000294 ≠ our Q1000294). Always normalise to full entity URIs, never bare Q-numbers — this is the Task Force's identifier-reuse warning in practice.
• url datatype is blocked on this instance → we bridge with external-id + formatter (string), which also gives the resolvable IRI.
• Federated Wikidata items render as "(Deleted Item)" via the API until registered once via the UI (alpha API gap).
• formatterUrlProperty must be set server-side, or external-ids do not resolve to IRIs and are not clickable.
• Cross-Wikibase SPARQL federation requires the target endpoint on the query-service allowlist.

TODOs

• [Flo] Register the referenced Wikidata items once via the UI so they resolve.
• [Flo/devs] Set formatterUrlProperty; unblock the url datatype.
• [Flo/devs] Add FactGrid / Fuzzy-SL / Semantic Kompakkt / SquirrelBase endpoints to the query-service allowlist.
• [Flo] Curate remaining values; publish the crosswalk.

What would matter most for federation

• Native Wikibase-to-Wikibase values (not just Wikidata) would replace the external-id bridge — the single most valuable extension for this use case.
• Stable, collision-free identifiers across the ecosystem.
• Query-service federation across the linked instances.

See also: UseCases/Software — the "reuse Wikidata, extend with your own vocabulary" case.