Federated Objects - User contributions [en]

Item:Q5

2026-07-14T13:57:34Z

Fthierygeo: /* wbsetclaim-update:2||1 */ Property:P38: Item:Q10

Item:Q10

2026-07-14T13:57:25Z

Fthierygeo: /* wbsetclaim-create:2||1 */ Property:P1: Item:Q9

Item:Q10

2026-07-14T13:57:15Z

Fthierygeo: /* wbeditentity-create:2|en */ E22 Human-Made Object

Item:Q5

2026-07-14T13:56:48Z

Fthierygeo: /* wbsetclaim-create:2||1 */ Property:P38: Item:Q9

Item:Q9

2026-07-14T13:56:27Z

Fthierygeo: /* wbeditentity-create:2|en */ CIDOC CRM class

Property:P38

2026-07-14T13:56:13Z

Fthierygeo: /* wbeditentity-create:2|en */ CIDOC CRM class

Item:Q5

2026-07-14T13:55:36Z

Fthierygeo: /* wbsetclaim-create:2||1 */ Property:http://www.wikidata.org/entity/P31: Item:Q8

Item:Q8

2026-07-14T13:55:27Z

Fthierygeo: /* wbeditentity-create:2|en */ Archaelogical Artifact

Main Page

2026-07-14T13:41:28Z

Fthierygeo:

= NFDI4Objects using Federated Items from Wikidata =

Create new item: '''[[Special:NewItem|Item]]'''

Create new property: '''[[Special:NewProperty|Property]]'''

Query Service: '''[https://query.federated-objects.de query.federated-objects.de]'''

= Use Cases =

[[UseCases]]

[[UseCases/Ogham]]

[[UseCases/Software]]

GitHub-Repository: https://github.com/n4o-rse/wikibase-federation

UseCases

2026-07-14T13:40:15Z

Fthierygeo: Created page with "= 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..."

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

Main Page

2026-07-14T13:24:02Z

Fthierygeo:

= NFDI4Objects using Federated Items from Wikidata =

Create new item: '''[[Special:NewItem|Item]]'''

Create new property: '''[[Special:NewProperty|Property]]'''

Query Service: '''[https://query.federated-objects.de query.federated-objects.de]'''

= Use Cases =

[[UseCases/Ogham]]

[[UseCases/Software]]

GitHub-Repository: https://github.com/n4o-rse/wikibase-federation

Main Page

2026-07-14T13:20:32Z

Fthierygeo: /* Use Cases */

'''NFDI4Objects using Federated Items from Wikidata'''

Create new item: '''[[Special:NewItem|Item]]'''

Create new property: '''[[Special:NewProperty|Property]]'''

Query Service: '''[https://query.federated-objects.de query.federated-objects.de]'''

= Use Cases =

[[UseCases/Ogham]]

[[UseCases/Software]]

GitHub-Repository: https://github.com/n4o-rse/wikibase-federation

Main Page

2026-07-14T13:19:21Z

Fthierygeo:

UseCases/Ogham

2026-07-14T13:17:36Z

Fthierygeo: /* Use Case: 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 ([[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.''

UseCases/Software

2026-07-14T13:17:02Z

Fthierygeo: /* Use Case: Software */

= Use Case: Software (CodeMeta) =

Two research-software items — '''SPARQLing Unicorn QGIS Plugin''' ([[Item:Q6|Q6]]) and '''Academic Meta Tool''' ([[Item:Q7|Q7]]) — modelled with a '''CodeMeta ↔ Wikidata crosswalk'''.

== What we mean by federation here ==

This is the Task Force's '''"reference source / reference ontology"''' case: reuse Wikidata's ontology for everything generic, and keep your own vocabulary only where the domain needs it.

* '''Reuse Wikidata''' (8 fields): instance of, developer, programmed in, license, version, DOI, source repository, website — mapped to wd:P31 / P178 / P277 / P275 / P348 / P356 / P1324 / P856.
* '''Own properties''' (5 fields with '''no Wikidata equivalent'''): development status, continuous integration, README, build instructions, code sample type — taken from '''CodeMeta'''.

== Why a Wikibase ecosystem, not Wikidata alone ==

* CodeMeta captures software metadata that '''Wikidata has no property for'''. In the Task Force's own words this is a "driver for a split": ''extra data on an item where no relevant property is in Wikidata.''
* Instead of forking silently, we create local properties '''and record their Wikidata equivalent''' (<code>equivalent Wikidata property = P178</code>). The local vocabulary stays '''aligned''' with Wikidata and does not drift.
* Result: Wikidata's shared ontology '''plus''' your domain extension, in one queryable graph.

== How it works technically ==

* Predicates are '''local properties''' → the model works on any Wikibase, even '''without''' the Federated Properties feature.
* A switch (<code>PROPERTY_MODE</code>) writes each mapped fact '''local''', '''federated''' (wd:P…), or '''both side by side''' — the direct "with vs. without federation" comparison, on the same item.
* Item values reference Wikidata concepts (value federation): ''developer'' → wd:Q…, ''programmed in'' → wd:Q28865 (Python).

== What to watch out for ==

* '''Prevent drift / splits.''' Always map a local property to its Wikidata equivalent (we use a string property "equivalent Wikidata property"). This is the Task Force's anti-drift point made concrete.
* '''Label conflicts.''' A local ''instance of'' collides with the built-in P1 → reuse the existing property, do not create a duplicate.
* '''url datatype is blocked''' → repository / website are stored as string (not clickable until url is unblocked).
* '''Identifier discipline.''' Full URIs for Wikidata values; local Q/P numbers stay local (no collision with Wikidata).

== TODOs ==

* '''[Flo]''' Replace illustrative CodeMeta values (development status, README, CI) with real ones.
* '''[Flo/devs]''' Unblock url so repository / website / CI become proper links and IRIs.
* '''[Flo]''' Decide the policy per instance: local-only vs. local+federated.
* '''[Flo]''' Extend the crosswalk to more CodeMeta fields as needed.

== What would matter most for federation ==

* An '''official local↔Wikidata mapping property''' (equivalent property) that the software honours in queries and RDF would make this pattern first-class.
* Reuse of the Wikidata ontology with '''short lag''' and completion, to keep instances aligned and prevent drift.

''See also: [[UseCases/Ogham]] — the "statements on entities from another Wikibase" case.''

Item:Q5

2026-07-14T13:09:06Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P37: C[A]SSITT[A]S MAQI MUCOI CALLITI

Item:Q5

2026-07-14T13:09:01Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P36: 51°53'37.172"N, 8°29'32.795"W

Item:Q5

2026-07-14T13:07:03Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P35: Item:http://www.wikidata.org/entity/Q1574185

Item:Q5

2026-07-14T13:06:54Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P34: Item:http://www.wikidata.org/entity/Q69379477

Item:Q5

2026-07-14T13:06:49Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P33: Item:http://www.wikidata.org/entity/Q104295278

Item:Q5

2026-07-14T13:06:43Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P33: Item:http://www.wikidata.org/entity/Q69385525

Item:Q5

2026-07-14T13:06:37Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P32: Item:http://www.wikidata.org/entity/Q184661

Item:Q5

2026-07-14T13:06:31Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P1: Item:http://www.wikidata.org/entity/Q2016147

Property:P37

2026-07-14T13:06:26Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P15: P1684

Property:P36

2026-07-14T13:06:25Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P15: P625

Property:P35

2026-07-14T13:06:25Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P15: P195

Property:P34

2026-07-14T13:06:25Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P15: P276

Property:P33

2026-07-14T13:06:25Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P15: P189

Property:P32

2026-07-14T13:06:24Z

Fthierygeo: /* wbcreateclaim-create:1| */ Property:P15: P282

Property:P37

2026-07-14T13:06:24Z