This chapter traces how the data space concept evolved from a computer science approach to data integration into a governance framework for trusted multi-party data sharing. It reviews emerging definitions and reference architectures and their convergence on data provider control. It then proposes a two-tier working definition, distinguishing a broad, architecture-agnostic formulation from a narrow one centred on federated governance, open interoperability and provider control, and uses this definition to situate data spaces relative to adjacent concepts and to functionally equivalent initiatives outside Europe.
Data Spaces between Co‑ordination Challenges, Financial Viability and Public Policy
Abstract
“Data space” has meant different things at different times. What began as a computer science abstraction now denotes a governance framework for multi-party data sharing backed by an estimated EUR 1.7 billion in public investment in the European Union (EU) alone. This chapter traces how the concept shifted; what the current formulation adds to earlier data-sharing approaches; and how data related to other comparable concepts.
The term “dataspace” originated in computer science as a response to a practical problem: traditional data integration requires complete schema alignment before any useful service can be provided. This imposes costs that scale with every new connection between semantically heterogeneous and administratively autonomous sources. Franklin, Halevy and Maier (2005[1]) proposed data spaces as an alternative paradigm that inverts this sequence. Rather than requiring upfront integration, a data space provides basic services immediately (cataloguing, search, browsing) across all participating sources, adds approximate query answering with minimal mappings, and invests in full semantic alignment only where the return justifies the cost. They called this “pay-as-you-go” integration: each level of integration delivers value, and organisations need not achieve full interoperability before extracting benefit.1
The Industrial Data Space (IDS), proposed by the Fraunhofer Institutes and Research Units and formalised in a Reference Architecture Model (RAM) (Otto et al., 2017[2]), was a significant shift from the previous paradigm. IDS transformed the dataspace concept by embedding governance and trust directly into the architecture. ETSI’s recent European standard for a data catalogue framework (EN 304 199) captures this shift in definitional form. It characterises a data space as an “environment enabling trusted data sharing between participating parties, based on an agreed governance framework, along with an agreed set of policies, semantic models, standardised protocols, processes and facilitating services” (ETSI, 2025[3]).
Two features mark the transition:
1. IDS adopts a federated approach:2 data remain with the provider, and access and use are mediated by certified connectors (i.e. software components deployed by each participant that govern what data are shared, with whom and under what conditions). Meanwhile, shared services (identity management, metadata brokering, certification) operate at the ecosystem level.
2. IDS introduces data usage control: the conditions under which connectors grant access are not merely contractual but machine-readable. That means data providers can attach usage rules specifying how shared data may be processed, aggregated and forwarded, and connectors can enforce these rules at the point of access. This combination of federated custody and enforceable usage control reflects a fundamentally different concern from the original dataspace concept: not how to query heterogeneous data, but how to enable its flow across organisational boundaries while still preserving data control among autonomous parties (Otto et al., 2017[2]).
More than one architectural approach now uses the term “data space”. IDS, and the ecosystem that developed around it (Eclipse Dataspace Protocol, European Data Spaces Support Centre Blueprint), prioritises the governance problem. As such, it focuses on embedding trust, identity and usage control via machine-readable contract negotiation into a connector architecture that presupposes co‑ordinated adoption of a shared protocol stack. ODS, a separate architecture developed by the Information-technology Promotion Agency (IPA) (METI/IPA, 2025[4]; IPA, 2026[5]), prioritises architectural decoupling. IPA describes ODS as “an open and scalable foundation for distributed data management, built on organisational and national diversity by design” (IPA, 2026[5]). ODS draws its data management architecture from two sources: the original dataspace concept of Franklin, Halevy and Maier (2005[1]); and Data Mesh principles (domain ownership, data-as-a-product, federated governance) that had been developed by Dehghani (2022[6]) for intra-organisational settings.
IPA organises its reference architecture around three loosely coupled pillars that can be independently replaced or upgraded (ontology and semantic interoperability; data addressability and discoverability; and identity and usage control; see Section 3.3.2 of Chapter 3). For its part, ODS engages with governance concepts that IDS had formalised, including usage control (Steinbuss et al., 2021[7]) and trust, and maintains a degree of logical compatibility with the IDS-RAM (METI/IPA, 2025[4]). However, it makes different architectural choices about how to implement them. Both approaches target inter-organisational and cross-border scope and diagnose the same governance challenges, but they differ in architectural foundations and in what they assume can be co‑ordinated ex ante (Section 3.3 of Chapter 3).
Usage control, however technically enforced, addresses how shared data may be processed but does not resolve who owns the value derived from them. Where data spaces are used to pool proprietary data for AI model training, this surfaces a distinct governance question: how to attribute ownership of resulting models, derived insights or downstream patent claims among data contributors, model developers and platform operators. Public-sector experience with multi-party data sharing for research and development includes the Materials Genome Initiative in the United States. The initiative has committed more than USD 1 billion in cumulative federal investment (NSF, 2023[8]). However, it has encountered persistent industry reluctance to contribute proprietary performance and testing data, which illustrates the practical weight of this question. Approaches such as privacy-enhancing technologies (PETs) for anonymised contribution and federated learning, as well as revenue-sharing coalitions, have addressed parts of the problem. Still, none has yet produced a widely adopted commercial model. As data spaces increasingly position themselves as substrates for AI training (Section 4.2.2 of Chapter 4), the absence of a clear framework for attributing intellectual property rights risks becoming a key constraint on participation, particularly for holders of high-value proprietary data.
No single universally agreed definition of “data space” exists. Instead, multiple institutional actors are arriving at overlapping definitions through different institutional pathways. ISO/IEC DIS 20151, the most broadly scoped definition under development, defines a data space as a “governance framework and supporting services to build trustworthiness and enable data sharing through an agreed set of policies, semantic models, protocols and processes” (ISO, 2025[9]). (See Box 2.1) This formulation is deliberately architecture-agnostic: it specifies neither centralisation nor decentralisation, neither a particular topology nor a distribution model. The European Data Spaces Support Centre (DSSC) adopts a similar architecturally neutral definition, converging with the ISO standard.
Definitions that embed specific structural requirements occupy the other end of this spectrum. For instance, IDSA defines a data space as “the total set of interoperable data-sharing applications by actors in a specific sector or domain [...] based on a distributed software infrastructure which provides the required software functionality for data sovereignty and trust” (IDSA, 2024[10]). This definition embeds two structural requirements absent from the ISO formulation: (i) a distributed infrastructure; and (ii) technically enforced “data sovereignty”.
The International Open Forum on Data Society (IOFDS) recommends a further definition. A standing forum convened by Japan’s Data Society Alliance, with participation from IDSA, Gaia-X, FIWARE and the Institute of Electrical and Electronics Engineers (IEEE), IOFDS advances interoperability between data space initiatives across regions. IOFDS defines a data space as “a decentralized ecosystem with common policy and rules defined by a governance framework that enables secure and trustworthy data transactions between participants while supporting trust and data sovereignty” (IOFDS, n.d.[11]).3
Despite their differences, these definitions converge on what the data spaces community calls “data sovereignty”. In this context, data sovereignty is understood as the ability of data providers to retain effective control over how their data are accessed and used after sharing.4 This shared commitment is operationalised through three major reference architectures (the IDSA-RAM, the ODS-RAM and the DSSC Blueprint), each reflecting a different model of public-private collaboration (Section 4.3 of Chapter 4).
Convergence between the three reference architectures is progressing. In March 2025, for example, IPA and Catena-X completed a cross-border interoperability proof of concept. This demonstrated product carbon footprint data exchange between the Ouranos Ecosystem and Catena-X for EU Battery Regulation compliance (IPA and Catena-X, 2025[12]) (Section 4.3 of Chapter 4). The trend towards convergence is being formalised through an active, multi-layered standardisation process (Box 2.1).
Four standardisation bodies are developing complementary standards for data spaces. At the international level, ISO JTC1 SC38 (Cloud Computing and Distributed Platforms) has three draft international standards: ISO/IEC DIS 20151-1 (dataspace concepts and characteristics); ISO/IEC DIS 26450 (Eclipse Dataspace Protocol, DSP); and ISO/IEC DIS 26451 (Eclipse Decentralised Claims Protocol, DCP). Upcoming work items include dataspace trust frameworks (ISO/IEC 20151-2), use cases (ISO/IEC 25850), switching by design and observability. The Eclipse Dataspace Protocol and Decentralised Claims Protocol appear in both the ISO and CEN/CENELEC pipelines. This positions them as the de facto technical baseline, with formal de jure status pending ISO/IEC approval of 26450 and 26451.
At the European level, CEN/CENELEC JTC25 is developing the EN 18235 series on Trusted Data Transactions: Part 1 (terms and definitions) is in publication as EN 18235-1:2026; Part 2 (trustworthiness requirements) is in its second editorial phase; Part 3 (interoperability requirements) is in preparation for enquiry. A technical specification on maturity assessment of Common European Data Spaces (CEN/CLC/TS 18331) is under vote. The EN 18235 conceptual model defines a transaction lifecycle (grant rights, publication, discovery, negotiation, data exchange, access and usage) that maps directly to the Eclipse DSP protocol flow. The EN 18235 series is explicitly framed for Data Act Article 33 compliance, making these standards commercially and legally significant for organisations.
ETSI is contributing Data Catalog Vocabulary profiles and extensions, with an implementation framework for semantic assets forthcoming. The Institute of Electrical and Electronics Engineers (IEEE) has published IEEE 3800-2024 (Data Trading System: overview, terminology and reference model), the only fully published standard in this landscape. Meanwhile, P3800.1 (protocol and object framework) is in development and 3800.2 (data space discovery protocol) was authorised in February 2026. The IEEE P3800 working group approaches data spaces from a data trading (marketplace-centric) perspective, complementing the provider-control-centric framing of the IDSA and ISO standards. Its chair is the Secretary General of Japan’s Data Society Alliance, illustrating how the Japanese institutional ecosystem bridges international standardisation tracks.
The diversity of definitions described above poses an analytical challenge. A framework broad enough to encompass a too-wide range of data-sharing arrangements as “data spaces”, such as the ISO/IEC DIS 20151 definition, risks losing the specificity needed to assess their distinctive value. Conversely, a narrow definition tied to a particular architecture risks excluding functionally equivalent arrangements that use different terminology or institutional pathways. To navigate this tension, this paper proposes a two-tier working definition.
The broad definition, informed by the architecture-agnostic formulations of ISO/IEC DIS 20151 and the DSSC Blueprint, defines a data space as
a data ecosystem in which participants share data through agreed common policies, standards, semantic models and processes, supported by enabling technical and organisational services that facilitate trusted and interoperable data sharing.
This formulation ensures that the OECD’s analytical framework remains inclusive of arrangements that exhibit some functional characteristics of data spaces without adopting the label. Examples include commercial data platforms such as Snowflake and Databricks, which provide cross-organisation data sharing and discovery services, and national statistical systems in which national statistical offices increasingly act as trusted data intermediaries (TDIs) (OECD, 2025[13]). The global statistical data exchange (SDMX) ecosystem illustrates how a mature data-sharing ecosystem can satisfy the broad definition without originating from the data spaces discussion (Box 2.2).
The narrow definition isolates the features whose distinctive value the remainder of this paper assesses. It defines a data space as
a data ecosystem characterised by (i) a federated or decentralised governance framework; (ii) open, standards-based interoperability services; and (iii) mutual trust and effective control between data providers and data users over how data are used.
Both definitions use the term “data ecosystem” as defined in the OECD Recommendation on Enhancing Access to and Sharing of Data [OECD/LEGAL/0463] (OECD, n.d.[14]), i.e. “the integration of and interaction between different relevant stakeholders, according to their different roles, responsibilities and rights, technologies and business models”. “Federated or decentralised” describes settings in which governance authority and data governance supporting services are not concentrated within a single organisation, without implying that all functions must be fully decentralised. “Open, standards-based interoperability” refers to shared technical services (e.g. identity management, data catalogues, semantic models) that enable participants to discover and exchange data without proprietary lock-in.
Data provider control extends beyond traditional access control (determining who may obtain data) to encompass post-access usage control, i.e. provider-defined conditions on purpose, duration, geographic scope and onward sharing (Reimsbach-Kounatze, 2021[15]). Their implementations exhibit a gradient of mechanisms – from contractual and purpose-bound restrictions to technically enforced usage constraints. In practice, effective provider control also implies a federated data architecture where data remain with the provider. They are accessed through interfaces such as connectors or other protocol-level endpoints rather than pooled into a central data repository.
Unless otherwise stated, “data spaces” in the remainder of this paper refers to the narrow definition. Figure 2.1 illustrates these features in a stylised architecture of a data space.5 The figure is functional rather than prescriptive. In particular, it leaves open where computation occurs,6 an architectural choice with direct implications for usage control enforceability and for the integration of complementary tools such as PETs discussed in Section 3.3.3 of Chapter 3.
Statistical Data and Metadata eXchange (SDMX, ISO 17369), sponsored by seven international organisations (BIS, ECB, Eurostat, IMF, OECD, United Nations, World Bank), has been operational for over two decades. It provides an information model, a standardised REST API, multiple exchange formats and content guidelines that harmonise the meaning of statistical concepts across jurisdictions. Hundreds of national statistical offices and international organisations use SDMX routinely to exchange macroeconomic, social and environmental statistics.
SDMX satisfies each element of the broad definition: agreed common policies (reporting obligations under international frameworks), standards (the SDMX Information Model and API, formalised as an ISO standard), semantic models (globally shared codelists and concept schemes), and processes (regular transmission cycles governed by release calendars). These are supported by enabling services such as the open-source .Stat Suite platform maintained by the Statistical Information System Collaboration Community (SIS-CC).
SDMX does not necessarily satisfy the narrow definition, but it does not have to do so. Aggregate official statistics are published openly, without the need for post-access usage control. The statistical community has developed complementary mechanisms where confidentiality is required for microdata. Such mechanisms include secure processing environments and the use of privacy-enhancing technologies through which code travels to the data rather than the reverse, a pattern functionally equivalent to federated data processing approaches explored in data space initiatives.
Note: BIS = Bank for International Settlements; ECB = European Central Bank; IMF = International Monetary Fund; REST API = Representational State Transfer Application Programming Interface.
Source: SDMX (2026[34]), SDMX – Statistical Data and Metadata eXchange, https://sdmx.org/.
Note: The figure illustrates the three defining features of the narrow definition used in this paper: federated data custody (data remain with the provider); open, standards-based interoperability (e.g. identity, discovery, vocabulary, trust services); and data provider control (e.g. usage rules govern the conditions of exchange). The “Interface” is an intentional abstraction with implementations varying in whether this function is performed by dedicated middleware (e.g. connectors), protocol-level endpoints, API gateways or other mechanisms.
Source: OECD based on IDSA (2024[10]), IDS Reference Architecture Model v4.2, https://github.com/International-Data-Spaces-Association/IDS-RAM_4_0; DSSC (2026[16]), Data Spaces Blueprint v3.0, https://dssc.eu/space/BVE/357074549/Data+Spaces+Blueprint+v3.0; IPA (2026[5]), Open Data Spaces Reference Architecture Model v2, https://open-dataspaces.gitbook.io/ods-docs/ods-ram/v2.
The two-tier approach clarifies the relationship between data spaces and adjacent concepts. Two patterns are relevant: some concepts share architectural principles with data spaces but lack the governance features that the narrow definition isolates, while others meet the narrow definition in practice without adopting its terminology.
2.4.1. Adjacent concepts
Commercial data platforms such as Snowflake and Databricks provide cross-organisation query, discovery and sharing services across heterogeneous datasets without requiring full semantic alignment. This is closer to the original dataspace concept by Franklin, Halevy and Maier (2005[1]) (Section 2.1) than to what “data spaces” now denotes. As such, it falls within the broad definition rather than the narrow one.
A related concept that has gained wide traction in data management practice, data mesh (Dehghani, 2019[17]; Dehghani, 2022[6]), arrives at the same destination from a different starting point. A decentralised sociotechnical approach for managing analytical data at scale, data mesh is organised around four principles: domain-oriented ownership, data-as-a-product, self-serve data infrastructure and federated governance. While data mesh was originally proposed for intra-organisational settings, its principles are increasingly applied across organisational boundaries.
Both data mesh and the dataspaces concept developed by Franklin, Halevy and Maier reject fully integrated architectures in favour of decentralisation, discoverability and progressive integration. However, data mesh adds what the original dataspace concept lacks: an organisational design layer with domain ownership as an accountability structure, data-as-a-product as a delivery contract and self-serve infrastructure as a platform responsibility.
When extended to inter-organisational settings, both concepts largely converge on the same model that commercial data platforms (Snowflake Marketplace, Databricks Delta Sharing) already implement: cross-organisational data products with platform-mediated governance. In the United States, for instance, an ecosystem of machine builders, manufacturers and integrators has pursued a similar extension under the label “data fabric”. This applies data mesh principles across organisational boundaries through open semantic standards but without the usage control layer (Box 2.3).
These adjacent approaches provide important practical benefits that have contributed to their wide adoption. In particular, they enable scalable and flexible data sharing across organisational boundaries without requiring full centralisation or harmonisation of data. By relying on decentralised ownership, shared semantic definitions and standards-based interoperability mechanisms, they can significantly reduce integration costs and accelerate development of cross-organisational data ecosystems. As such, these architectures often represent pragmatic pathways for organisations to realise value from data sharing.
However, neither the original dataspace concept, nor data mesh, nor inter-organisational data fabric approaches provide the data usage control and collectively governed trust infrastructure that characterise data spaces under the narrow definition. The ODS-RAM v2 explicitly positions itself as inheriting data mesh’s paradigm, extending it to inter-organisational scope. It adds the Identity and Usage Control pillar to address the governance complexity arising when domains cross organisational and national boundaries (Tsuda, 2026[18]).
The difference between data spaces and these adjacent concepts is thus not about decentralisation (these concepts all have that) or cross-organisational scope (commercial platforms and data mesh provide that). Rather, the differences lie in the features isolated by the narrow definition: whether governance is federated rather than platform-concentrated; whether interoperability is open and standards-based rather than proprietary; and whether data usage control remains with the data providers. The data fabric of the Clean Energy Smart Manufacturing Innovation Institute demonstrates that substantial value can be created from the interoperability layer alone (Box 2.3); data spaces in the narrow definition add governance and usage control layers on top.
The Clean Energy Smart Manufacturing Innovation Institute (CESMII), one of 20 Manufacturing USA institutes, was established in 2016 with USD 70 million by the US Department of Energy and an equivalent amount by the private sector. Bringing together over 200 member organisations, including machine builders, manufacturers and integrators, CESMII pursues a “data fabric” for manufacturing – an approach functionally equivalent to data mesh extended across organisational boundaries. Members contribute standardised data type definitions (Smart Manufacturing Profiles) that function as reusable, vendor-independent data-sharing agreements, which are supported by an open API specification (i3X) for data access.
A joint demonstrator with Germany’s “Platform Industrie 4.0” initiative has validated cross-border interoperability between SM Profiles and the European Asset Administration Shell for a carbon reporting use case. CESMII participates in the International Manufacturing-X (IM-X) Council, which brings together nine founding member organisations from Austria, Canada, France, Germany, Italy, Japan, Korea, the Netherlands and the United States. Spain and Australia participate as additional members.
SM Profiles specify what data mean and how they can be accessed, but not what may be done with them. Data control is achieved through semantic standardisation: the provider controls the model through which data are exposed, rather than through technically enforced data-use constraints. Participation is driven by the value proposition of reduced integration costs. Since 2020, original equipment manufacturers, system integrators and manufacturers have crowdsourced over 100 companion specifications. These cover equipment types across sectors including energy, as well as automotive and semiconductor manufacturing.
2.4.2. Equivalent initiatives
Parallel developments outside the international data spaces ecosystem have independently arrived at arrangements that share the defining features of the narrow definition without adopting its terminology. This was confirmed by participants at the OECD Expert Workshop, who observed that in the United States, for instance, intra-organisational data ecosystems appear to exist in business but are not named as data spaces. This development suggests the concept may need to be framed differently outside the European context where the terminology originated (Annex A).
The Trusted Exchange Framework and Common Agreement (TEFCA) operates as a federated “network of networks” for nationwide health information exchange in the United States, with approximately 500 million records exchanged (HHS, 2026[19]). Governance is collectively defined under a common agreement independent of any single platform operator, and qualified health information networks enforce usage conditions set by the data provider. In India, Data Empowerment and Protection Architecture (DEPA) provides a consent-based federated data-sharing framework built on India Stack. This is operational in financial services through the Account Aggregator framework, which intermediates consent-driven data flows across more than 270 million linked accounts; usage control is enforced structurally through the consent architecture.7
The iSHARE Trust Framework, originating in the Dutch logistics sector and used across multiple sectors and EU jurisdictions (iSHARE Foundation, n.d.[20]), is a further example. iSHARE provides a scheme-based approach to identity, authentication and authorisation for data sharing. As such, it uses operator certification rather than a mandated connector implementation, and a community-governed wiki model to develop shared use cases. iSHARE illustrates an alternative architectural emphasis: governance and trust scheme membership as the primary co‑ordination mechanism. Technical implementation choices are left more open to participants than in connector-centric models such as IDS.
TEFCA and DEPA were not designed as data spaces, yet both exhibit the defining features of the narrow definition: federated governance independent of any single platform operator; open and standards-based interoperability; and structurally enforced usage control. Their existence confirms the inclusive scope of the broad definition is warranted, and that the narrow definition identifies structural properties rather than a label (Section 4.1 of Chapter 4 examines the implications of this convergence for the co‑ordination problem).
References
[6] Dehghani, Z. (2022), Data Mesh: Delivering Data-Driven Value at Scale, O’Reilly.
[17] Dehghani, Z. (2019), “How to move beyond a monolithic data lake to a distributed data mesh”, https://martinfowler.com/articles/data-monolith-to-mesh.html (accessed on 15 April 2026).
[16] DSSC (2026), “Data Spaces Blueprint v3.0”, https://dssc.eu/space/BVE/357074549/Data+Spaces+Blueprint+v3.0 (accessed on 9 April 2026).
[3] ETSI (2025), “Draft ETSI EN 304 199 V1.0.0 (2026-03): Data Solutions (DATA); Data catalogue implementation framework; Guidelines for Data Catalogue Framework”, ETSI.
[1] Franklin, M., A. Halevy and D. Maier (2005), “From databases to dataspaces”, ACM SIGMOD Record, Vol. 34/4, pp. 27-33, https://doi.org/10.1145/1107499.1107502.
[23] Halevy, A., M. Franklin and D. Maier (2006), “Principles of dataspace systems”, Proceedings of the twenty-fifth ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems, pp. 1-9, https://doi.org/10.1145/1142351.1142352.
[19] HHS (2026), “TEFCA – America’s national interoperability network reaches nearly 500 million health records exchanged”, https://www.hhs.gov/press-room/tefca-americas-national-interoperability-network-reaches-nearly-500-million-health-records-exchanged.html (accessed on 7 April 2026).
[10] IDSA (2024), IDS Reference Architecture Model, Version 4.0, https://github.com/International-Data-Spaces-Association/IDS-RAM_4_0.
[11] IOFDS (n.d.), “International Open Forum on Data Society”, https://iofds.org/ (accessed on 13 April 2026).
[5] IPA (2026), “Open Data Spaces Reference Architecture Model (ODS-RAM)”, https://open-dataspaces.gitbook.io/ods-docs/ods-ram/v2 (accessed on 1 April 2026).
[12] IPA and Catena-X (2025), “Catena-X and Ouranos ecosystem successfully demonstrate data space interoperability”, https://catena-x.net/news/catena-x-and-ouranos-ecosystem-successfully-demonstrate-data-space-interoperability/ (accessed on 6 March 2026).
[20] iSHARE Foundation (n.d.), “Foundation History”, https://ishare.eu/about/the-foundation/foundation-history/ (accessed on 28 April 2026).
[9] ISO (2025), “ISO/IEC DIS 20151-1: Cloud computing and distributed platforms – Dataspaces – Part 1: Concepts and characteristics”, https://www.iso.org/standard/86589.html (accessed on 14 April 2026).
[22] Kernstock, P. et al. (2025), “Establishing and governing data ecosystems at the crossroads of centralization and decentralization”, Electronic Markets, Vol. 35/71, https://doi.org/10.1007/s12525-025-00810-x.
[4] METI/IPA (2025), Open Data Spaces Reference Architecture Model (ODS-RAM), Ministry of Economy, Trade and Industry (METI) and the Information-Technology Promotion Agency, Government of Japan.
[8] NSF (2023), NSF Efforts to Achieve the Nation’s Vision for the Materials Genome Initiative: Designing Materials to Revolutionize and Engineer Our Future (DMREF), National Academies Press, Washington, DC, https://doi.org/10.17226/26723.
[13] OECD (2025), “National statistical offices as emerging trusted intermediaries in data governance”, OECD Digital Economy Papers, No. 378, OECD Publishing, Paris, https://doi.org/10.1787/3721ec38-en.
[14] OECD (n.d.), Recommendation of the Council on Enhancing Access to and Sharing of Data, OECD/LEGAL/0463, https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0463 (accessed on 6 March 2023).
[2] Otto, B. et al. (2017), Reference Architecture Model for the Industrial Data Space, Fraunhofer-Gesellschaft, Germany, https://doi.org/10.24406/PUBLICA-FHG-298818.
[21] Peeters, S. (2013), “Beyond distributed and decentralized: What is a federated network?”, https://networkcultures.org/unlikeus/resources/articles/what-is-a-federated-network/ (accessed on 22 April 2026).
[15] Reimsbach-Kounatze, C. (2021), “Enhancing access to and sharing of data: Striking the balance between openness and control over data”, Data Access, Consumer Interests and Public Welfare, pp. 25-68, https://doi.org/10.5771/9783748924999-25.
[7] Steinbuss, S. et al. (2021), “Usage control in the international data spaces”, Position Paper, International Data Spaces Association, Dortmund, Germany, https://doi.org/10.5281/zenodo.5675884.
[18] Tsuda, M. (2026), Why Open Dataspaces: Design Philosophy and Architectural Paradigm, Information-technology Promotion Agency, Tokyo, https://www.ipa.go.jp/en/digital/architecture-guidelines/individual-link/p1o1lf000001xv4n-att/WhyOpenDataspaces_en.pdf.
← 1. Crucially, partial integration is treated as a legitimate resting state, not merely a waypoint towards full alignment; each participant invests in further integration only where the marginal return justifies the marginal cost. The subsequent formalisation of Dataspace Support Platforms (DSSPs) by Halevy, Franklin and Maier (2006[23]) sharpened the distinction: whereas traditional data integration systems require complete semantic mappings as a precondition, dataspaces emphasise coexistence, incrementalism and best-effort functionality.
← 2. Much of the data spaces literature uses “decentralised” to describe this architecture. This paper uses “federated” as the more precise term: participants retain autonomy over their data but rely on collectively governed shared services (identity, discovery, transaction logging) for co‑ordination (Peeters, 2013[21]). The IDS RAM v4.0 itself describes “a federated structure, in contrast to completely centralized or decentralized architectures” (IDSA, 2024[10]); Kernstock et al. (2025[22]) document empirically how governance functions are distributed along a gradient rather than located at either pole. The distinction matters analytically: federated architectures require collective investment in shared services, which is the source of the bootstrapping challenges discussed in Chapter 3.
← 3. The first version of Japan’s Open Data Spaces Reference Architecture Model adopted this definition verbatim in footnote 3 of METI and IPA (2025[4]); ODS-RAM v2 uses a different formulation.
← 4. The concept of data sovereignty is thus more specific and distinct from the geopolitical concept of sovereign jurisdiction over data flows. This paper uses the term “data provider control” to avoid conflation with the geopolitical usage.
← 5. The working definition and Figure 2.1 as adopted in this report is functional rather than architectural, with the aim to ground the policy analysis that follows. The working definition and Figure 2.1 are therefore limited to the scope of the report, which concerns the use of data spaces as typically foreseen in data sharing scenarios between entities, where the core functional elements are invariant: a data provider; a data user; a data transfer mechanism; a set of services that enable trust, interoperability and discoverability, and more; and this with the main purpose of discussing the viability and adoption challenges of data spaces.
← 6. A further architectural choice, not specific to data spaces but increasingly relevant within them, is the locus of computation. Three patterns coexist: (i) data-to-code, where data are transferred to the user’s environment for local processing; (ii) code-to-data, where queries or model-training rounds travel to the provider and only results return (e.g. federated learning); and (iii) computation in a neutral compute environment such as a trusted execution environment or data clean room operated as a shared service. The choice has direct implications for usage control enforceability (Section 3.3.3 of Chapter 3), the integration of privacy-enhancing technologies, and the distribution of compute costs among participants.
← 7. DEPA’s locus of control differs from the narrow definition in two respects. First, usage conditions are defined by the data subject (the individual) rather than the data provider (the financial institution). Second, governance is regulator-defined (RBI licensing) rather than collectively negotiated among participants. DEPA thus shares the architectural pattern (federation, structurally enforced usage control, no centralised data repository) while serving a different governance logic: data subject control, i.e. individual data empowerment, rather than data provider control. [See DSTI/DPC/DGP(2025)8/REV1.]