Skip to content

Guiding questions — Data, services & offerings descriptions#

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

Building block V1 · owner(s) Nunsys + LogiNex + iLabs · 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. Standardised Metadata Models#

Purpose: Ensure that all datasets, services, and offerings are described using common vocabularies, ontologies, and schemas, so that they can be understood and used across Member States and sectors.

  • Which metadata standards (e.g., DCAT-AP, schema.org, sector-specific ontologies) should be adopted as the baseline?
  • Do we need to extend existing metadata models with Green Deal–specific descriptors (e.g., CO₂ footprint, energy efficiency, circularity indicators)?
  • How can we ensure interoperability with other European Data Spaces (health, mobility, manufacturing)?
  • Will connector software manifests (root of trust, OS/app) be published to support supply-chain trust?
  • Which metadata standards (e.g., DCAT-AP, schema.org, sector-specific ontologies) should be adopted as the baseline?
  • Do we need to extend existing metadata models with Green Deal–specific descriptors (e.g., CO₂ footprint, energy efficiency, circularity indicators)?
  • How can we ensure interoperability with other European Data Spaces (health, mobility, manufacturing)?
  • Will connector software manifests (root of trust, OS/app) be published to support supply-chain trust?

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

(The template repeats its four questions in this section; they are answered once.)

Decided Baseline: DCAT-AP (v3) combined with iSHARE/Gaia-X self-descriptions, serialised as JSON-LD and validated with SHACL. schema.org is not adopted as a baseline — it buys search-engine visibility the LDT does not need and loses the precision DCAT-AP gives for distributions, licences and provenance.

Decided Green Deal descriptors are needed: CO₂ footprint and emission-method descriptors extend the baseline where relevant, carrying the LogiNex methodology reference. Energy-efficiency descriptors follow from the PED case. Circularity indicators are not currently required by any of the six use cases and should not be specified pre-emptively.

Proposed Interoperability with other European data spaces runs through DCAT-AP, which is the common currency of EU catalogues, plus the iSHARE layer for trust artefacts. For mobility specifically, ERTICO's advice should determine whether an additional sectoral profile is warranted.

Proposed Connector software manifests for supply-chain trust: not adopted for the pilot. It is a real concern and disproportionate here — the LDT runs a small number of known connectors operated by named consortium partners, and the DevSecOps assurance in Provenance addresses the delivery pipeline. Worth revisiting if the LDT admits connector operators it does not know.

Needs owner Nunsys + LogiNex + iLabs — the 🧩: the concrete field list, the SHACL shapes, and the CO₂ descriptor extension.

2. Policy-Aware Descriptions#

Purpose: Embed usage rights, data-sharing rules, and sustainability-related policies directly into dataset and service descriptions, so that participants can quickly understand the conditions of use.

  • What types of data usage policies (e.g., open, restricted, commercial, research-only) should be standardised?
  • How should sustainability obligations (e.g., alignment with EU taxonomy, compliance with CSRD or energy reporting) be represented in dataset metadata?
  • Should policy metadata be mandatory for all offerings, or only for those connected to regulated domains (like emissions reporting)?

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

Decided Standardised usage-policy categories map onto the scheme's three access tiers — open, restricted (consortium or use-case), commercial — with terms drawn from the iSHARE Licence Catalog. "Research-only" is not a separate tier; it is a purpose constraint expressed in ODRL within a tier, which is the more precise place for it.

Decided Policy metadata is mandatory for every offering in the LDT, not only for regulated domains. This is one of the scheme's firmer positions: a description that says what data is but not what may be done with it is incomplete, and an offering without an attached policy is not listable. Restricting the requirement to regulated domains would mean the catalogue's open tier carries no re-identification prohibition, which is exactly where citizen-derived data sits.

Proposed Representing sustainability obligations in metadata: through the method reference plus provenance, not through a compliance assertion. A dataset records the emission method used (LCMM / ISO 23795-1) and its lineage; whether that satisfies a participant's CSRD or taxonomy obligation is the participant's assessment to make. The scheme should not let a metadata field imply a regulatory conclusion it has not verified — that is the greenwashing failure mode in a different costume.

Decided The CO₂ field set and method reference format, previously an open request to LogiNex, is set by PD4 §4. The method chain is ISO 23795-1 trip-data extraction feeding ISO 14083 transport-chain calculation, reported against ISO 14064-1 boundaries, carried as SD-JWT verifiable credentials. Every cross-site comparison records location, reporting period, units, calculation method and version, source data, baseline and limitations, and distinguishes measured results from modelled scenarios. Each credential additionally carries a unique measurement identifier, references the credentials it builds on, and states its evidence class (self-declared, measured, third-party verified). The Aruba landside row of PD4 Table 2 shows the same set applied: trip/segment, CO₂e, method version, baseline. (Source: PD4 v1.0 §4 and Table 2 — text as in PD4 v0.96, 29 Oct 2026.)

3. Machine-Readability and FAIR Compliance#

Purpose: Guarantee that descriptions are not only human-readable, but also machine-actionable to support automation in publication, discovery, and integration.

  • Which formats and APIs should be enforced for machine-readable descriptions?
  • How can FAIR principles be operationalised across sectors?
  • Should minimal mandatory metadata fields be defined?
  • Will policy/usage terms be machine-readable and linked to identity/trust artifacts?
  • Will JSON-LD be used to express metadata/context, and will SHACL validation rules be provided?

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

Decided Formats and APIs: JSON-LD for descriptions, SHACL for validation, DCAT-AP as the profile, exposed through the catalogue API of the Marketplace of the EU LDT Toolbox and through each site's own catalogue where it keeps one.

Proposed FAIR, operationalised rather than asserted:

  • Findable — persistent identifiers per offering; DCAT-AP records harvestable by EU and national portals for the open tier.
  • Accessible — a resolvable access URL plus the authorisation protocol; accessible in FAIR terms means the access conditions are clear, not that access is open, which is what lets restricted offerings remain FAIR.
  • Interoperable — JSON-LD with named models and linked controlled vocabularies.
  • Reusable — a licence from the Licence Catalog, an ODRL policy, a named source and a stated quality declaration.

Proposed Minimal mandatory fields: identifier, title, description, publisher, named data model, distribution with format and access URL, licence reference, ODRL policy, access tier, update frequency, stated quality level, and — for computed products — the method reference. SHACL enforces this mechanically; incomplete means not listable.

Decided Usage terms are machine-readable and linked to identity and trust artefacts: the ODRL policy is evaluated against the presented credential and registry state (Access & usage policies).

4. Sector-Specific Extensions:#

Purpose: Allow extensions of the base metadata model with domain-specific fields that address the unique needs of Green Deal–aligned use cases.

  • Which sustainability-related attributes should be mandatory in sector-specific extensions (e.g., building lifecycle data in construction, CO₂ intensity in energy)?
  • How do we balance general interoperability with the need for highly specialised descriptors?
  • Should governance rules for approving new sector-specific extensions be established, and by whom?

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

Proposed Mandatory sustainability attributes, by domain and only where the use cases require them:

  • Emissions / CO₂ products (LogiNex) — method reference and version, computation inputs, uncertainty or confidence where the method expresses it, and temporal and spatial scope. The method reference is the one that makes the figure auditable, and without it the token economy has no foundation.
  • Energy / PED (Almelo) — measurement boundary (building, district), temporal resolution, and whether a figure is measured or modelled. Conflating measured and modelled values is the error that discredits PED claims.
  • Mobility / LEZ (Cartagena) — spatial scope, aggregation level applied, and sensing method.

Proposed Balancing general interoperability against specialised descriptors: extensions are additive and namespaced, never redefinitions of baseline terms. A consumer that understands only DCAT-AP must still be able to use the record; a consumer that understands the extension gets more. This is the same rule as for vocabularies — extend, never fork.

Proposed Governance of new extensions: proposed by the owning block, impact-assessed, approved at TIPS, published in the LDT namespace. iSHARE-owned terms remain iSHARE Foundation's to change.

Needs owner LogiNex, Almelo Energie, Cartagena: confirm these attributes are producible from their systems. The list is derived from what the claims require, not from what the sites can emit.

5. Ecosystem Visibility and Transparency#

Purpose: Ensure that all participants have a transparent overview of what is available in the ecosystem, enabling efficient resource matching and value creation.

  • How can a unified catalogue or registry be maintained and updated?
  • What mechanisms (e.g., dashboards, registries, APIs) are needed to maintain transparency for participants?
  • Should there be obligations for providers to regularly update or validate their dataset/service descriptions to prevent outdated information?

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

Decided The marketplace catalogue (Nunsys, WP6) is the LDT's unified discovery surface; architecture leaning is federated publication with a central index, to be confirmed in Publication & discovery.

Proposed Transparency mechanisms, in order of how much they are actually used: the catalogue itself with its policy and provenance links exposed; the trust signals published from Provenance — conformance status, policy-check outcomes, incident statistics; the machine-readable Participant Registry; and the observer views and chatbot for non-expert stakeholders.

Proposed Obligations on providers to keep descriptions current — yes, and with a consequence, because an obligation without one is a preference. The proposed rule: a description carries a stated update frequency, and a distribution that has not updated within its stated frequency is flagged in the catalogue as stale rather than silently served. Conformance evidence lapses on its own schedule and takes the certified badge with it.

Flagging rather than delisting is deliberate: delisting hides the problem, while a visible stale marker lets a consumer judge fitness and gives the provider a reason to act.

Needs owner Nunsys: whether the catalogue can compute staleness against declared frequency. The mechanism assumes it can.