Skip to content

Guiding questions — Data models#

Fork notice. The questions below are reproduced from the iSHARE Data Space Template page Data models → Guiding questions — © iSHARE Foundation, used under the EUTwinLink Consortium Agreement (see Legal notices). The template's question text is carried over unchanged so this fork stays comparable to its upstream.

Everything between the LDT answer markers is the EUTwinLink instantiation — that is what partners fill in. Decisions already taken live on the block page: Data models.

Building block T1 · owner(s) iLabs + LogiNex + cities (iSHARE vocabulary) · due 26 Sep 2026 · block status DRAFTED · see the Building-block register.

Answer provenance. Every answer below is tagged with where it comes from, because a governance scheme that cannot be traced is not a governance scheme:

  • Decided — already fixed by the Grant Agreement, the Consortium Agreement or a recorded decision elsewhere in this scheme. Change it only through the change procedure.
  • Proposed — a defensible default, derived from the iSHARE Trust Framework, the DSSC Blueprint and the decisions this scheme has already taken. Drafted for the owner to confirm, correct or reject at TIPS. It is not an agreed position until TIPS approves it.
  • Needs owner — cannot be answered without the named owner: a fact about their systems, their legal position or their commercial intent. The text states what is needed and why.

Open points across the whole scheme are collected in Open questions for partners.

1. Understanding Scope & Semantics#

Purpose: Define the key concepts and relationships that must be standardised to ensure semantic alignment across use cases.

  • Which data products require semantic expression through a shared data model?
  • Which concepts, entities, and relationships must be standardised for your use case?

LDT answer DRAFTED · owner: iLabs + LogiNex + cities (iSHARE vocabulary) · due 26 Sep 2026

Decided Not everything needs a shared model, and the scheme's scope rule is deliberate: semantics are standardised at the boundary between twins, not inside them. Four twins were built independently on different stacks and will not be re-modelled; what crosses between them must be comparable.

Proposed Data products that therefore require shared semantic expression:

  • Indicators — emissions (gCO₂e per vehicle-km, kgCO₂e per building/scenario), air quality, energy balance, renewable share. These carry the cross-site benchmarking the whole LDT is for.
  • Offering descriptions — DCAT-AP, because discovery fails without them.
  • Scheme concepts — participant, role, credential, policy, licence. Fixed by iSHARE.
  • Shared dimensions — location, time, administrative area, measurement method.

What does not need standardising: each twin's internal entity model, its simulation structures, and site-specific operational detail that never crosses a boundary.

Needs owner iLabs + both cities + LogiNex: the concrete entity and relationship list per domain. The scope rule above is the scheme's position; the actual concepts are the 🧩 contribution and do not exist yet.

2. Selecting or Creating Models#

Purpose: Decide whether to reuse, extend, or develop new data models based on adoption, compatibility, and domain standards.

  • Can existing data models be reused directly? If not, can they be extended rather than replaced?
  • Which standards organisations or communities maintain the most relevant models for your domain?
  • What factors (adoption level, integration compatibility, constraints) influence model selection?

LDT answer DRAFTED · owner: iLabs + LogiNex + cities (iSHARE vocabulary) · due 26 Sep 2026

Decided Reuse before extension, extension before creation — the scheme's ground rule, applied here literally. schemas.ishare.eu/vocab# is the canonical iSHARE namespace and is extended, never forked; LDT-specific terms get their own namespace, coordinated with iSHARE Foundation.

Decided Models and communities already named per domain: DCAT-AP (SEMIC / EU) for descriptions; NGSI-LD with OASC MIM2 (ETSI ISG CIM / Open & Agile Smart Cities) for city data; ESSIM/DEMkit semantics for PED energy; LCMM / ISO 23795-1 for emission computation; mobility and LEZ models on ERTICO's advice; port logistics event models for Hamburg.

Proposed Selection factors, in the order the LDT should weigh them: (1) already in use at one of the sites — an adopted model beats a better one; (2) EU-level adoption, since replication is the LDT's stated ambition; (3) compatibility with JSON-LD and the NGSI-LD/DCAT-AP stack; (4) whether the maintainer is a live community, because an orphaned model becomes the LDT's maintenance burden.

Needs owner iLabs + cities + LogiNex: per domain, the model reused, its version, the extension needed, and the maintainer. ERTICO owes the mobility recommendation.

3. Expressing the Models#

Purpose: Choose meta-standards and reference vocabularies to ensure consistent, machine-readable representation of data models.

  • Which meta-standards will be used to represent data models? (e.g., RDF/OWL, SKOS, JSON Schema, XML Schema, CSVW)?
  • What reference datasets or controlled vocabularies (e.g., EU vocabularies, ISO codes) will be linked?
  • Does your dataspace use W3C as a recognized standards for Identity Management?
  • Does Dataspace use JSON-LD type as a recognized standard of Identity & Access Management?
  • Are vocabularies in RDF (Resource Description Framework OWL complaint?

LDT answer DRAFTED · owner: iLabs + LogiNex + cities (iSHARE vocabulary) · due 26 Sep 2026

Decided Meta-standards: JSON-LD as the serialisation throughout; RDF/OWL for vocabulary expression where a model is published as a vocabulary; SHACL for validation of descriptions and payloads; JSON Schema where an API contract rather than a vocabulary is being expressed. Both are used, for different purposes — SHACL validates graph shape, JSON Schema validates an API body, and conflating them produces validation that passes while the data is wrong.

Proposed Controlled vocabularies to link: EU Vocabularies (data themes, languages, corporate bodies) via DCAT-AP, NUTS and LAU for administrative areas, ISO 3166 for countries, ISO 8601 for time, ISO 4217 where monetary values appear, and the unit vocabulary used by the chosen emission method.

Decided On the template's two identity questions, which belong to Identity & attestation but are answered here for completeness: yes — the LDT uses W3C standards for identity (Verifiable Credentials, DIDs where wallet flows require them) and yes, JSON-LD is the credential data model, consistent with the serialisation choice above.

Proposed Are the vocabularies RDF/OWL-compliant? The iSHARE vocabulary and DCAT-AP are. LDT extensions must be, as a condition of publication — otherwise the scheme's own discovery and validation tooling cannot consume them.

4. Governance and Maintenance#

Purpose: Establish processes for managing ownership, versioning, and stakeholder engagement around data models.

  • Who will act as the data model provider for each model (e.g., Standards Development Organisation, The governance team, sectoral community)?
  • How will versioning, change approval, and stakeholder engagement be managed?
  • What processes will be in place for resolving conflicts or inconsistencies between models?

LDT answer DRAFTED · owner: iLabs + LogiNex + cities (iSHARE vocabulary) · due 26 Sep 2026

Decided Model provider per model, which is also where change authority sits:

Model Provider
iSHARE vocabulary, credential schemas iSHARE Foundation — not the LDT's to change
DCAT-AP, NGSI-LD, MIM2, ISO methods external SDOs and communities — the LDT consumes versions
LDT extensions and profiles the LDT, in its own namespace, maintained by the owning block

Proposed Versioning: each block names the normative version of every standard it adopts, so "we follow DCAT-AP" is never ambiguous in an audit. LDT extensions use semantic versioning; a breaking change requires a new major version and a migration note, never a silent redefinition of an existing term.

Change approval follows the scheme's change procedure — proposed as a merge request, impact-assessed across blocks, approved at TIPS. Upstream version changes enter the same way, as a proposal rather than automatically, because adopting a new DCAT-AP version has consequences for every existing description.

Proposed Conflict resolution between models: where two domain models disagree about a shared concept, the boundary model wins and each twin maps to it locally. The alternative — reconciling the twins' internal models — is the re-modelling exercise the scheme has explicitly declined.

Needs owner iLabs: who maintains each LDT extension in practice.

5. Tooling and Accessibility#

Purpose: Provide accessible platforms and services to host, discover, and link data models with exchange schemas and APIs.

  • Which Vocabulary Service platform will host the data models?
  • How will models be made discoverable across other EU data spaces?
  • How will models be linked to actual data exchange schemas and APIs?
  • Does your dataspace have a browser-based UI & API?
  • Does your dataspace provide a vocabulary service?

LDT answer DRAFTED · owner: iLabs + LogiNex + cities (iSHARE vocabulary) · due 26 Sep 2026

Needs owner The LDT has no vocabulary service, and this is a genuine gap rather than a detail. The scheme states that schemas.ishare.eu/vocab# is canonical and that LDT terms get their own namespace — but no hosting, resolution or browsing for that namespace has been decided or assigned. A namespace that does not resolve is not a namespace.

Proposed Options, for iLabs and iSHARE to choose between: host LDT extensions under an iSHARE-operated vocabulary service (keeps one source of truth, requires iSHARE Foundation's agreement); publish them from this repository with content negotiation via GitLab Pages (cheap, works, looks provisional); or adopt an external vocabulary service.

Proposed Discoverability across EU data spaces runs through DCAT-AP rather than through the vocabulary service: offerings are harvestable by national and EU portals, and a harvested description carries its model references. That is the realistic route, and it only works if the references resolve.

Decided Models link to exchange schemas and APIs through the descriptions: every offering's DCAT-AP record embeds its ODRL policy and licence reference, and names the models it uses. API specifications are published per Data exchange.

Proposed Browser-based UI and API: the Marketplace of the EU LDT Toolbox provides both for offerings; neither exists for vocabularies, per the gap above.