Fthierygeo: /* Use Case: Software */

2026-07-14T13:17:02Z

Use Case: Software

← Older revision		Revision as of 13:17, 14 July 2026
Line 1:		Line 1:
	= 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.''

Fthierygeo: Created page with "= Use Case: Software ="

2026-07-14T13:01:17Z

Created page with "= Use Case: Software ="

New page

= Use Case: Software =

UseCases/Software - Revision history

Fthierygeo: /* Use Case: Software */

Fthierygeo: Created page with "= Use Case: Software ="