Skip to content

Guiding questions — Data space offerings#

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

Building block B3 · owner(s) Nunsys + LogiNex + cities · 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.

Purpose of this Building Block Component: The offering comprises data assets and associated services that enable use cases. This includes: data products and services.

It is essential to bundle offerings in a way that reflects user needs (e.g. emissions dashboard for real estate owners; API-based footprint verification for consultants). This should also account for: * Licensing models * Terms of use * User support services * Interoperability with EU data infrastructure (e.g. Data4Sustainability, EUDR registries) A well-structured offering enhances usability, legal certainty, and trust, increasing uptake and long-term engagement.

Data products: structured environmental, spatial, emissions, material flow, or asset-level data

Services: access control, consent management, data quality assurance, enrichment tools, compliance reporting modules

1. Data Products#

Purpose: Clearly structured environmental, spatial, emissions, material flow, and asset-level data.

  • What key data assets will be initially offered?
  • How will data assets be standardised and validated?
  • How frequently will data be updated and shared?
  • How can data products be designed to be modular and reusable across multiple use cases?
  • How can data assets be standardized and validated efficiently?
  • How can offerings remain aligned with participant needs over time?

LDT answer DRAFTED · owner: Nunsys + LogiNex + cities · due 26 Sep 2026

Decided Candidate initial data products, per the block page: LEZ mobility and air-quality feeds (Cartagena); PED energy balances and flexibility, including ESSIM/DEMkit outputs (Almelo/Aadorp); airport operational flows (Aruba); port logistics events (Hamburg); CO₂ and emission datasets with derived indicators (LogiNex).

Decided Standardisation and validation: DCAT-AP (v3) descriptions, JSON-LD serialisation, SHACL validation of every description, NGSI-LD/MIM2 for city data, and an ODRL policy plus a Licence Catalog reference embedded in each description. A description that fails SHACL is not a listing.

Proposed Modularity and reuse across use cases is achieved by publishing indicators separately from raw data. Cross-site benchmarking needs comparable indicators, not comparable raw feeds, and indicators can carry an open or restricted licence where the underlying data cannot. This is the same mechanism the profiles call "derived-indicator publication rights", and it is what makes a product reusable across use cases with different sensitivity.

Alignment with participant needs over time is maintained through the use-case profiles' section 6 and through unmatched searches on the Marketplace of the EU LDT Toolbox.

Needs owner Nunsys + LogiNex + both cities — the open 🧩. Per product: source, update frequency, quality level, licence tier and Green-Deal descriptors. Update frequency is not stated for a single product today, and it determines protocol choice in Data exchange.

2. Functional Questions:#

  • What data model will be used?

LDT answer DRAFTED · owner: Nunsys + LogiNex + cities · due 26 Sep 2026

Decided The data model stack, fixed by the Grant Agreement and recorded in Data models:

  • DCAT-AP (v3) for dataset and offering descriptions, combined with iSHARE/Gaia-X self-descriptions;
  • NGSI-LD with OASC MIM2 compliance for city data;
  • JSON-LD as serialisation, SHACL for validation;
  • schemas.ishare.eu/vocab# as the canonical namespace — extended, never forked; LDT-specific terms get their own namespace, coordinated with iSHARE Foundation.

Domain models are selected per domain rather than invented: mobility and LEZ (ERTICO advice), energy and PED (ESSIM/DEMkit semantics), airport operations, port logistics events, and CO₂ indicators carrying their method reference (LCMM / ISO 23795-1).

Decided The mapping per city twin is no longer unconfirmed — the signed application states it. Cartagena harmonises into FIWARE data models compliant with OASC MIM2, behind an NGSI-LD context broker, on the Libelium Iris360 stack with the EU LDT Toolbox. Almelo/Aadorp authors in ESDL with the open-source ESDL MapEditor and executes in ESSIM/DEMkit. (Source: EUTwinLink LDT4SSC WS1 Application Form, Annex 4 to the Pilot Grant Agreement.)

Needs owner iLabs + both cities + LogiNex: the versions of those models and who maintains each LDT extension. The application names the families, not the releases, and names no maintainer for anything the scheme adds on top.

3. Functional/Technical Questions:#

  • How can offerings remain aligned with participant needs over time?
  • What is the source of the data?

LDT answer DRAFTED · owner: Nunsys + LogiNex + cities · due 26 Sep 2026

Proposed Keeping offerings aligned with needs over time: the three signals the scheme actually has are unmatched marketplace searches, the "sharing rules needed" sections of the use-case profiles, and policy-check failures in the audit trail — a repeatedly denied request usually means the licence tier is wrong rather than that the requester is. All three are reviewed at TIPS; none is automated today.

Decided Sources of data, per product: municipal sensing and enforcement systems (Cartagena), household meters and generation/storage telemetry plus model outputs (Aadorp, via Almelo Energie), airport operational systems (FHC), port systems (Hamburg), and computed outputs from LogiNex's emission methodology. Each offering's description must name its source, because provenance is what makes a derived indicator auditable — see Provenance, traceability & observability.

Needs owner The per-source inventories are _TODO_ on every site profile and are the precondition for this block's 🧩.

5. Licensing and Terms of Use#

Purpose: * Data access control & consent management * Data quality assurance & validation * Data enrichment tools (e.g., analytics, visualisation) * Compliance reporting modules (aligned with CSRD, etc)

LDT answer DRAFTED · owner: Nunsys + LogiNex + cities · due 26 Sep 2026

(The template lists this heading without questions; the licensing questions appear under section 4.)

Decided Every offering carries usage terms from the iSHARE Licence Catalog (licenses.ishare.eu) plus an ODRL policy that makes those terms machine-enforceable. The Licence Catalog is the binding artefact and may not be paraphrased or translated without iSHARE Foundation's prior written consent — see Legal notices. The scheme therefore references licences; it never restates them.

Decided Three access tiers: open (public dashboards, city transparency), restricted (consortium or use-case participants), commercial (marketplace).

Proposed The rule that keeps tiers meaningful: a tier is a statement about who may access, while the ODRL policy is a statement about what they may do. Both are required — an open tier without a policy still needs to prohibit re-identification attempts, and a restricted tier without a policy does not bound purpose. Describing an offering by tier alone is incomplete, which is why policy metadata is mandatory in the LDT rather than optional.

4. Associated Services#

  • Which services are critical to the initial use cases?
  • How will compliance and consent management be technically enforced?
  • What are the minimum standards for data quality assurance?
  • Which services add the most value to participants while remaining interoperable?
  • How should services be prioritized based on current and future use cases?

Purpose: Licensing models clearly aligned with open data standards or commercial/regulated usage. Define clear terms of use, including IP rights, access rights, and permitted usage.

  • Under which license models will data be provided?
  • Are there specific data-usage restrictions or access tiers?

LDT answer DRAFTED · owner: Nunsys + LogiNex + cities · due 26 Sep 2026

Decided Services critical to the initial use cases: the marketplace catalogue (Nunsys), CO₂ and emission analytics (LogiNex), scenario simulation (ESSIM/DEMkit for PED, LEZ what-ifs), the observer chatbot and agent stack, and citizen-engagement tooling (Aegean, HyEnSys). Detail in Value creation services.

Decided Compliance and consent are enforced technically rather than contractually where possible: ODRL policies at federated PEP/PDPs, credential-gated access, consent state as a policy information point where citizen data is in scope (GDPR handling per PD1), and an audit entry per decision.

Proposed Minimum data-quality standards — the scheme does not yet have any, and this is a real gap. The proposed minimum for any listed offering: a stated update frequency and the actual latency against it; a stated completeness or coverage level; a named source; and, for computed products, a documented method. Not a quality threshold but a quality declaration, so a consumer can judge fitness. A threshold would require measurement the scheme cannot perform.

Proposed Prioritisation: services that unblock a funded use case first (marketplace, CO₂ analytics), services that extend reach second (observer, engagement tooling).

Licence models and access tiers: see section 5 above.

Needs owner Nunsys + LogiNex: confirm the quality-declaration fields are producible.

6. User Support#

Purpose: Define helpdesk, training resources, and dedicated support channels.

  • How will support needs differ across stakeholders (public/private, technical/non-technical)?
  • Who will deliver these support services (in-house, third-party)?
  • How can support resources be tailored to different types of participants?
  • How can training ensure quality data contribution?

LDT answer DRAFTED · owner: Nunsys + LogiNex + cities · due 26 Sep 2026

Proposed Support needs differ along two axes at once in the LDT, and treating them as one is why data-space support usually fails:

  • Technical maturity — iLabs, Nunsys and FHC need API specifications and a sandbox. A municipal policy officer or a resident needs an interface and an explanation.
  • Public versus private — a municipality needs to satisfy administrative and procurement constraints before it can act; a commercial participant needs commercial terms. These are different conversations with different people.

Proposed Delivery: in-house to the consortium — iLabs for registry, credentials and ITB-S; Nunsys for the marketplace; iSHARE for scheme and legal questions; Aegean for citizen-facing engagement. No third-party support function is foreseen, and bounding it is the service agreements' job.

Proposed Tailoring: the ITB-S sandbox for technical participants (failing safely is better documentation than documentation), standard licence and ODRL templates so non-specialists choose rather than draft, the Observer role for those who need access without integration, and the observer chatbot as the non-expert entry point to the twins.

Training for quality contribution should focus on the one thing contributors reliably get wrong: writing a description that is policy-complete. Needs owner iLabs + Nunsys: confirm scope and capacity.

7. Interoperability#

Purpose: Alignment with EU-wide data infrastructures (Data4Sustainability, EUDR registries, Copernicus) and Common EU Data Spaces (CEADS, EMDS, etc). Define Standardised data formats and APIs.

  • Which external EU registries and frameworks should be integrated to ensure compliance and interoperability?
  • How will ongoing alignment with evolving EU data interoperability standards be ensured?


LDT answer DRAFTED · owner: Nunsys + LogiNex + cities · due 26 Sep 2026

Decided External alignment already fixed: DCAT-AP keeps the LDT harvestable by national and EU open-data portals where the cities want it; OASC MIM2 aligns city data with the wider minimal-interoperability community; eIDAS trust lists anchor identity beyond the scheme; the iSHARE scheme itself provides cross-data-space recognition; Gaia-X alignment is maintained at the descriptive level through offerings and self-descriptions.

Proposed Registries worth integrating but not yet decided: national open-data portals for the open tier (datos.gob.es, data.overheid.nl), and the EU Data Spaces catalogue where the LDT wants visibility. SIMPL is a watching brief with a deliberately thin adapter, not an integration commitment — the agent profile records SIMPL's instability as risk R4.

Proposed Staying aligned as standards evolve: each block names the normative version of the standards it adopts, so "we follow DCAT-AP" never becomes ambiguous in an audit; version changes enter through the scheme's change procedure; and upstream drift in the iSHARE framework is detected in CI (Alignment with the iSHARE Trust Framework). Standards outside iSHARE have no equivalent detection and are reviewed at TIPS quarterly instead.

Needs owner Both cities: whether open-tier offerings should be harvested by national portals. That is a municipal transparency decision, not a technical one.