Editing UseCases/Ogham (section)

= 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 ([[Item:Q5|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 <code>https://database.factgrid.de/entity/$1</code>). 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 <code>formatterUrlProperty</code>; 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.''