Skip to content

Guiding questions — Data exchange#

Fork notice. The questions below are reproduced from the iSHARE Data Space Template page Data exchange → 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 exchange.

Building block T2 · owner(s) iLabs (input: FHC Corp, HyEnSys) · 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. Protocol Selection#

Purpose: Identify core transmission protocols and sector-specific APIs that enable seamless data exchange.

  • Which generic transmission protocols (e.g., REST/HTTP, NGSI-LD, LDES, MQTT) should be adopted?
  • Which domain-specific APIs are required for sectoral use cases?
  • Should a “preferred protocol set” be provided for faster onboarding?
  • Are Event Streaming (HTTPS or MQTT), IDSCP, or Protocol Buffers used for transmission?

LDT answer DRAFTED · owner: iLabs (input: FHC Corp, HyEnSys) · due 26 Sep 2026

Decided The adopted set, fixed by the Grant Agreement and the block page:

  • Eclipse Dataspace Components (EDC) with the iSHARE extension — the control plane for trust-framework-aware exchange: catalogue, contract negotiation, transfer process.
  • iSHARE-compliant APIs (openapi.ishare.eu) for authorisation flows.
  • NGSI-LD over REST/HTTP for city data, MIM2-compliant.
  • OGC services for geospatial layers — with non-ESRI interoperability explicitly required (funder recommendation, Annex 9), which in this scheme is a portability rule rather than a preference.

Proposed The preferred protocol set the template asks about is exactly the list above, and the scheme should say so explicitly: a participant that adopts EDC + iSHARE extension + NGSI-LD/REST can onboard without a protocol negotiation. Anything else is possible but costs a conversation and an ITB-S profile.

Proposed On the specific options: MQTT is justified where a site has genuine high-frequency telemetry — Aadorp's meter and generation telemetry is the candidate — but should not be adopted scheme-wide on the assumption that it will be needed. LDES is worth considering for the city twins' time-series, and nobody has evaluated it. IDSCP and Protocol Buffers are not adopted; the LDT has no requirement they answer.

Needs owner iLabs, with FHC and HyEnSys — the open 🧩. Domain-specific APIs per use case remain unnamed, and the data-source inventories they depend on are still _TODO_ on every site profile.

2. Modes of Exchange#

Purpose: Define when data should be exchanged via push, pull, streaming, or batch transfers to meet diverse use cases.

  • Will data be exchanged as push (provider sends) or pull (consumer requests), or both?
  • Which scenarios require continuous streaming versus finite batch transfers?
  • How will real-time updates and triggered exchanges be handled?

LDT answer DRAFTED · owner: iLabs (input: FHC Corp, HyEnSys) · due 26 Sep 2026

Proposed Both push and pull, selected by data characteristics rather than by preference:

Pattern Where Why
Pull (request/response) the default — indicators, datasets, scenario outputs, catalogue queries works with the EDC contract-negotiation flow and leaves the provider in control
Subscription / push NGSI-LD context-broker subscriptions for dynamic city data consumers that need change notification should not poll
Streaming high-frequency site telemetry (PED meters, airport operational feeds) only where latency genuinely matters
Batch historical series, model outputs, periodic emission computations the bulk of cross-site benchmarking traffic

Proposed The governance point that matters more than the protocol choice: a policy decision must precede every mode. Streaming and subscription make this harder than request/response, because the policy is checked once at subscription and the data keeps flowing afterwards. The scheme's rule should be that a subscription is re-evaluated on credential or policy change and terminated on revocation — otherwise revocation does not actually stop anything.

Needs owner iLabs: confirm the EDC + iSHARE extension enforces that on long-lived transfers. The requirement is stated here; the capability is assumed. Second question on the same component, raised by PD4 v1.0 §3: the pinned pilot profile names protocols, credential formats, status lists and policy enforcement at the gateway, but no connector. Confirm that the EDC + iSHARE extension path satisfies that profile unchanged, or state which part it implements differently — PD4 Table 2 describes the Cartagena ingestion as MQTT/JSON/UL connectors into the data-space layer, with no EDC mentioned, and the two descriptions should not be left to be reconciled by the reader.

3. Integration with Semantics & Discovery#

Purpose: Ensure protocols are aligned with semantic models and discoverable through catalogs.

  • How will protocols link to the agreed semantic data models?
  • How will API specifications and protocol details be published for discoverability?

LDT answer DRAFTED · owner: iLabs (input: FHC Corp, HyEnSys) · due 26 Sep 2026

Decided Protocols link to the semantic models through the offering description: every DCAT-AP record names the data model used, the distribution's format and access URL, and embeds its ODRL policy and licence reference. A consumer therefore resolves meaning and permission from the same record it uses to find the endpoint — see Descriptions.

Decided API specifications are published for discoverability through the catalogue of the Marketplace of the EU LDT Toolbox, with iSHARE's own authorisation APIs documented at openapi.ishare.eu.

Proposed The rule to state in PD4, because it is the one that makes automated consumption possible at all: a distribution whose description does not name a model and a policy is not listable. SHACL validation enforces it mechanically rather than by review. This is the same "policy-complete description" condition the marketplace already applies for listing, extended to semantics.

Needs owner iLabs + Nunsys: whether OpenAPI documents for site-specific APIs are published in the catalogue alongside the dataset descriptions, or only linked. It affects whether a consumer can generate a client automatically.

4. Quality & Reliability#

Purpose: Implement mechanisms for ensuring accuracy, resilience, and compatibility in data transfers.

  • How will completeness and accuracy of data transfers be ensured?
  • What mechanisms for error handling, reconnection, and version compatibility will be in place?

LDT answer DRAFTED · owner: iLabs (input: FHC Corp, HyEnSys) · due 26 Sep 2026

Proposed Completeness and accuracy of transfers are a transport concern and should not be confused with data quality, which is declared per offering (Data space offerings section 4). At transport level: integrity protection on the channel, transfer-process state tracked by the EDC control plane, and a control-plane audit entry per transfer so an incomplete transfer is visible rather than silent.

Proposed Error handling and reconnection: idempotent retrieval wherever the data model allows it, bounded retry with backoff, and — the part that usually gets forgotten — a defined behaviour when a policy check fails mid-transfer. The scheme's position should be fail closed: a transfer whose authorisation lapses stops, and the failure is logged as a policy event rather than a transport error, because the two have different consequences.

Decided Version compatibility: each block names the normative version of the standards it adopts; version changes enter through the change procedure.

Decided Every exchange path is validated in the ITB-S before production use, and PD2 interoperability scores depend on it.

Needs owner iLabs — the 🧩 asks for the error-handling and reconnection policy and the ITB-S conformance procedure that gates production onboarding. Neither is written.

5. Federation Readiness#

Purpose: Guarantee interoperability with other EU data spaces through shared protocols and a common inventory.

  • How will interoperability with other EU data spaces’ protocols be ensured?
  • Will a shared “protocol inventory” be maintained for federated connections?

LDT answer DRAFTED · owner: iLabs (input: FHC Corp, HyEnSys) · due 26 Sep 2026

Proposed Interoperability with other EU data spaces rests on the LDT having adopted the common layer rather than a LDT-specific one: EDC as the connector, the iSHARE Trust Framework for identity and policy, DCAT-AP for descriptions, ODRL for policies. A data space using the same stack can interconnect without protocol translation; one using a different trust framework needs a recognition arrangement, which is a governance question for TIPS and iSHARE Foundation, not a technical one.

Proposed A protocol inventory should be maintained, and the LDT has the beginnings of one scattered across block pages rather than collected. The useful form is a single table — per exchange path: protocol, version, semantic model, policy enforcement point, ITB-S profile, and status. That table is also exactly what PD2 needs for interoperability scoring and what a prospective participant needs in order to estimate integration effort.

Proposed It should live in this block and be generated from the ITB-S profiles rather than maintained by hand, so it cannot drift from what is actually tested.

Needs owner iLabs: whether ITB-S can emit that inventory. If it can, the scheme gets federation readiness as a by-product of conformance testing instead of as a documentation exercise.