Skip to content

Guiding questions — Publication & discovery#

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

Building block V2 · owner(s) Nunsys + 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. Scope & Functionality of the Catalogue#

Purpose: Define the breadth and depth of the catalogue to balance discoverability, transparency, and accessibility.

  • What is the appropriate scope of the catalogue (minimal index or rich metadata repository)?
  • Should offerings be accessible to non-participants (public visibility) or only to registered participants?
  • What level of detail in metadata is required to ensure both discoverability and trustworthiness?
  • Will the catalogue manage service offerings, support dynamic data transactions, and enforce access management for offerings?

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

Proposed A rich metadata repository, not a minimal index — because the scheme has already made policy metadata mandatory, and a minimal index cannot carry an ODRL policy, a licence reference, a method reference and conformance evidence. The catalogue's job in the LDT is to let a consumer decide whether an offering is usable before requesting it, which a bare index cannot support.

Decided Visibility is tiered rather than uniform: open-tier offerings are publicly browsable (city transparency), while restricted and commercial tiers require authentication. The decision on whether the catalogue as a whole is public follows the scheme's own publication decision — and that scheme publication is currently public, repository and site alike (checked 29 October 2026), pending TIPS ratification in Organisational form & governance authority section 3.5.

Proposed Metadata depth required for both discoverability and trust is the mandatory field set in Descriptions section 3, plus the verification links in section 6 below.

Decided The catalogue manages service offerings as well as datasets, and enforces access management for offerings — listing requires a valid participant credential, a policy-complete description, and ITB-S conformance evidence for certified badges. Dynamic transactions are handled by the EDC control plane; the catalogue is the discovery surface, not the transfer path, and PD4 should keep that line clear.

2. Governance & Access Control#

Purpose: Clarify who manages the catalogue and how access rights are assigned, authenticated, and authorized.

  • Who governs the catalogue (central authority vs. distributed responsibility)?
  • How should access be managed, open, tiered (role-based), or restricted to use-case participants?
  • What mechanisms should be in place for authentication and authorization when publishing and discovering offerings?

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

Proposed Governance is distributed in responsibility, central in rules: Nunsys operates the catalogue under scheme rules and TIPS oversight; each provider is responsible for its own entries; eligibility rules are set by the scheme, not by the operator. An operator that could set its own listing rules would be setting market-entry conditions for a market it also sells into — the conflict named in Intermediaries & operators question 6.

Proposed Access is tiered and role-based: public read for the open tier, authenticated participant access for restricted, and use-case-group membership for offerings a group has scoped to itself. Publishing requires a valid participant credential plus the Data Provider role.

Decided Authentication and authorisation for both publishing and discovery use the same mechanism as everything else in the scheme — credential presentation over OpenID4VC, evaluated against registry state. The catalogue is not a separate access-control domain with its own accounts.

Needs owner Nunsys + iSHARE: how a rejected listing is appealed. The scheme gives the operator a rejection power and no appeal route, which is a governance gap rather than an oversight to leave to practice.

3. Catalogue Architecture (Centralised vs. Decentralised)#

Purpose: Decide whether the catalogue operates as a central service, a federated network, or a hybrid model.

  • Should a federated model, central broker model, or hybrid be adopted?
  • If federated, how should synchronisation work across distributed catalogues? (push, pull, gossip protocols).
  • If centralised: who operates and funds the central catalogue service, and what are the implications for neutrality and inclusivity?
  • How will cross-space interoperability for discovery be ensured (common APIs/profiles, conformity tests)?

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

Decided Hybrid, with the split now fixed by PD4 v1.0 §4. For offerings, the TM Forum product catalogue of the Marketplace of the EU LDT Toolbox is the single authoritative source: an offering is created and held there, not harvested from elsewhere, and is exposed read-only as DCAT-AP 3.0 (validated against the DCAT-AP SHACL shapes) and OGC API – Records. For data, each site keeps its own catalogue or context broker — the city twins already run NGSI-LD brokers — and remains the source of truth for its own datasets and their policy metadata. Pure federation gives no single place to search, which defeats the Marketplace's purpose; pure centralisation requires sites to surrender their own catalogues, which none of them will do and which the portability rule argues against. (Source: PD4 v1.0 §4 — text as in PD4 v0.96, 29 Oct 2026.)

Proposed Synchronisation, for the dataset descriptions that are not themselves offerings: pull-based harvesting on a schedule declared per source, with push notification where a site supports it. Gossip protocols solve a scale problem the LDT does not have. Harvesting must preserve the source's policy metadata unchanged — an index entry whose policy has drifted from the source is worse than no entry. Offerings are out of scope here: they live in the TM Forum catalogue by the answer above and are never harvested copies.

Proposed Operation and funding of the central index: Nunsys during the pilot, under WP6. Post-M18 this is unfunded, like the rest of the scheme layer, and it affects neutrality — an index funded by its operator's transaction fees has an interest in what it lists. Mitigation is objective listing rules plus an appeal route.

Decided Cross-space discovery interoperability through DCAT-AP and ITB-S conformance testing.

4. Interoperability & Standards#

Purpose: Adopt common metadata standards and align with EU infrastructures to ensure cross-data-space discoverability.

  • Which metadata standards (DCAT v3, ODRL, FAIR) should be mandatory?
  • How should the catalogue align with EU infrastructures (data.europa.eu, national catalogues, sectoral hubs)?
  • How to ensure cross-data-space discoverability while maintaining control over sensitive offerings?

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

Decided Mandatory: DCAT-AP (v3) for descriptions, ODRL (iSHARE profile) for policies, JSON-LD serialisation, SHACL validation, and FAIR as operationalised in Descriptions section 3. Mandatory means enforced at listing, not recommended.

Proposed Alignment with EU infrastructures: the open tier should be harvestable by data.europa.eu and the national portals (datos.gob.es, data.overheid.nl), which costs nothing extra given DCAT-AP and gives the cities the transparency outcome they want. Restricted and commercial tiers are never harvested.

Proposed Cross-data-space discoverability while keeping control of sensitive offerings rests on a distinction the catalogue must implement carefully: an offering's existence, its shape and its access conditions can be discoverable while its content is not. That is how a restricted dataset remains findable by a legitimate potential consumer without leaking. The limit — and it should be stated in PD4 rather than discovered by a city — is that existence itself is sometimes sensitive: the fact that a municipality holds a particular enforcement dataset can be disclosive. Where it is, the offering is not published at all, and that is a provider decision, not a catalogue setting.

Needs owner Both cities: which offerings fall into that last category.

5. Offering Lifecycle & Sustainability#

Purpose: Establish processes for managing, updating, and preserving catalogue entries with sustainability in mind.

  • How should providers manage the lifecycle of offerings (versioning, updates, retirement)?
  • Should sustainability attributes (e.g. environmental impact, CO₂ data quality) be part of metadata descriptions?
  • How do we ensure long-term persistence of identifiers (PIDs) to support reuse across data spaces?

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

Proposed Lifecycle management, with the state transitions named so a consumer can rely on them:

  • Versioning — semantic versioning on the description; a breaking change to the data model or the policy is a new version, not an edit. Silently changing a policy under an existing identifier is the failure mode this prevents.
  • Updating — a stated update frequency, with staleness flagged against it (Descriptions section 5).
  • Deprecation — marked deprecated with a successor reference and an end date, remaining discoverable during the window.
  • Retirement — removed from active search, with the identifier retained and resolving to a tombstone record.

Decided Sustainability attributes are part of the descriptions, including CO₂ data-quality and method references.

Proposed Persistent identifiers: identifiers must resolve after retirement, which is the whole point of persistence and the part usually dropped. A provenance record that cites a retired dataset is worthless if the identifier 404s — and the LDT has provenance records citing datasets precisely because its CO₂ claims depend on them. Identifiers should therefore be minted under a scheme-controlled namespace rather than a provider's own domain, since a provider that exits takes its domain with it.

Needs owner Nunsys + iLabs: the PID scheme. None exists.

6. User Experience & Trust#

Purpose: Ensure catalogue entries are reliable, searchable, and validated to build user confidence and usability.

  • What mechanisms ensure offerings are searchable, transparent, and reliable?
  • Should a data-space-wide search portal be provided for non-technical users?
  • How do we build confidence in entries (validation, certification, provenance)?
  • Will verification links be exposed for trust decisions?

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

Proposed Searchability and reliability rest on the mandatory field set being genuinely mandatory — SHACL-validated at listing — plus faceted search on the dimensions participants actually use: domain, geography, access tier, update frequency, and whether conformance evidence is current.

Proposed A data-space-wide search portal for non-technical users: yes, and the LDT already has two routes to it — the marketplace interface, and the observer chatbot, which is the better answer for a resident or a policy officer who does not know what to search for. The chatbot's retrieval boundary must keep it to open and authorised tiers only, which is an open design note on the agent profile.

Proposed Building confidence in entries, in descending order of strength: provenance (how a figure was derived, with its method), conformance evidence from the ITB-S, registry status of the provider, and validation (a listed entry passed SHACL). Certification is deliberately last — it is iSHARE Foundation's to grant, and the marketplace certified badge reflects evidence rather than conferring certification.

Decided Verification links are exposed: an entry links to the provider's registry record, its conformance evidence and its provenance, so a trust decision can be made from the catalogue without a side channel. That is the practical payoff of making the registry machine-readable.