"Layers" separate the DPQM into logical tiers according to functional purpose. ODS-RAM consists of four layers: (1) Data, (2) Transaction, (3) Identity, and (3) Semantics.

In ODS-RAM, each layer is independent of the others and fulfills its distributed data management functions in a loosely coupled manner. That is, ODS-RAM layers possess "detachability", allowing those who adopt ODS-RAM to selectively determine the number of layers required according to the nature and characteristics of each domain. For example, if the data addressability and semantics within a given cross-cutting domain are already clear, one may begin by implementing Data Product first using L3 through L1, omitting the implementation of Ontology Product — i.e., the set comprising L4 through L2.

ODS-RAM places a strong emphasis on flexibility tailored to each domain and use case, and by ensuring "backward compatibility", it allows for subsequent opt-in as needed, thereby providing options commensurate with the level of maturity. The following sections describe in detail the functions of each of the four layers.

3.1 Data Layer (L1)

The Data Layer (hereinafter "L1") is the layer that addresses the problems of Usage Control, Data Tampering, and Data Quality, and selectively adopts Closed World Assumption (CWA) behavior.

L1 requires functions for data usage control exercised by the data provider and for handling data with guaranteed integrity and quality:

• Regarding usage control exercised by data providers: opportunities for self-determination must be provided within the scope defined in data sharing agreements, and the exercise of such control must be appropriately reflected.

• Regarding data integrity and quality: the integrity and quality characteristics of each piece of data vary across target domains, and rather than establishing uniform standards, it is assumed that integrity and quality appropriate to the characteristics of the data will be guaranteed. Accordingly, the integrity and quality of data itself are not stipulated; only the methods and results of their evaluation and calculation must be provided in a form accessible to data consumers.

The Transaction Layer (hereinafter "L2") is the layer that addresses the problems of Modal, Query, and Protocol.

L2 must be capable of controlling the transaction process between data providers and data users in a manner that is agnostic to data modal (structured, semi-structured, unstructured, etc.) as well as to request and protocol type (synchronous, asynchronous, etc.).

The Identity Layer (hereinafter "L3") is the layer that addresses the problems of Authentication and Authorization.

L3 requires the necessary level of authentication and authorization through providing Credentials in a verifiable form:

• Verification of the existence of data providers and users and authentication must ensure the required level of trustworthiness.

• Access control based on the storage, usage conditions, and granularity self-determined by the data provider must ensure the required level of confidentiality.

The Semantics Layer (hereinafter "L4") is the layer that addresses the problems of Addressability and Semantics, and adopts Open World Assumption (OWA) behavior.

L4 requires semantic and ontological interoperability through providing Metadata in an accessible form:

• Metadata related to destinations must be provided in order to access data or services.

• Metadata related to meaning must be defined in a unique and accessible format with respect to the meaning of the information (input/output data) necessary to use the data or services.

This chapter organizes "what should be implemented" for readers who are in a position to implement Open Dataspaces technologies, refering to the design philosophy and architectural paradigm of ODS and the guidelines set out in its reference architecture model, "ODS-RAM (Open Data Spaces Reference Architecture Model)."

2.1 Design Philosophy of Open Dataspaces

Open Dataspaces is not merely a mechanism for sharing or publishing data; its purpose is to enable the management of data distributed across multiple enterprises and organizations while maintaining trust. The following A through E are essential to achieving this. For details on the design philosophy, refer to "Design Philosophy".

A. Distributed Data Management

Open Dataspaces does not assume that data is managed in a centralized manner by any specific party. Data remains under the management of each enterprise's or organization's own domain, and is provided as a product within the necessary scope and under defined conditions. Centralized management by any single party is not a premise. (Reference: Design Philosophy, Chapters 3 and 4)

B. Semantics and Ontology

Open Dataspaces explicitly separates "data structure and values (data model)" from "data meaning (information model)," and constrains domain-derived context through ontology, thereby enabling inference by data users. (Reference: Design Philosophy, Chapter 5)

C. Data Addressability and Discoverability

Open Dataspaces is designed so that data and ontology endpoints are globally identifiable and discoverable. (Reference: Design Philosophy, Chapter 6)

Open Dataspaces treats as design targets: "who can access data," "whether that party can be trusted," "under what conditions data can be provided and used," and "whether a given transaction can be considered to have been conducted correctly." The asymmetry of trust, security, and rights and obligations relationships is handled explicitly. (Reference: Design Philosophy, Chapter 7)

In ODS-RAM, "ODS Protocols (ODP)" are defined as the protocols to be relied upon in order to achieve connectivity across different enterprises, organizations, and legal jurisdictions. The design principle is to avoid dependence on any specific vendor, product, or legal framework. (Reference: Design Philosophy, Chapter 3)

ODS-RAM assumes two implementation patterns:

• Distributed Service Model: an approach in which domain owners themselves build a Self-Serve Data Platform and provide Data Product/Ontology Product based on DPQM

• Federated Service Model: an approach in which a managed service provider delivers the basic software stack that constitutes DPQM on behalf of the domain owner, while the domain owner retains responsibility for providing Data/Ontology Product.

It should be noted that even in the federated service model, data and ontology remain the responsibility of the data provider, who exercises usage control over them.

This section classifies the components that make up ODS — based on the ODP — into Common Functionalities,Fundamental Protocols,and Complementary Protocols,and provides an overview of what each is designed to enable.

Fundamental Protocols provide specifications for providing the core functions required to realize Open Dataspaces; protocols that must be adopted to realize the functions of the corresponding layer or perspective

• Common Functionalities:

  • Versioning: A function for managing changes to specifications, configurations, and components, and for maintaining interoperability among participants on a shared set of assumptions

  • Logging: A function that enables comprehensive recording and analysis of system communication status, processing results of each service, and overall monitoring and operational status, based on three categories: communication logs, service logs, and processing logs

Complementary Protocols provide specifications for providing supplementary functions required to realize Open Dataspaces; protocols that may be adopted as needed to realize the functions of the corresponding layer or perspective

• Heuristic Contracting: An interface function that supports the definition and agreement of terms of use and contractual conditions through third-party electronic contract applications (the contracting function itself is not included)

• Clearing and Payment: An interface function for recording and reconciling data transaction records through third-party electronic payment applications, and for processing settlement and billing/payment (the settlement and billing/payment function itself is not included)

• Marketplace: An interface function for forming a venue for data transactions among multiple participants and supporting distribution and transaction expansion (the marketplace function itself is not included)

An open and scalable foundation for distributed data, built on organizational and national diversity by design.

ODS-RAM (Open Data Spaces Reference Architecture Model) Repository

ODS-RAM is a reference document published under the design philosophy of Open Data Spaces, providing a reference architecture for distributed data management across enterprises, industries, and national borders. It encompasses the technical paradigm, layered structural model, protocol relationships, and related elements.

Relationship to the Previous Version

The Whitepaper (ODS-RAM V1) was published on the IPA website in 2025. https://www.ipa.go.jp/digital/architecture/reports/ouranos-ecosystem-dataspaces-ram-white-paper.html Copyright of ODS-RAM V1 belongs to METI (Ministry of Economy, Trade and Industry) and IPA.

Copyright

Copyright of ODS-RAM V2 belongs to IPA, METI, and NEDO. V2 was compiled and edited by IPA based on the outcomes of NEDO's "Project for the Development and Pilot of a Data Sharing System to Realize the Ouranos Ecosystem."

License

This document (ODS-RAM V2) is provided under the Creative Commons Attribution 4.0 International (CC BY 4.0). Full license text: https://creativecommons.org/licenses/by/4.0/

This site publishes documents related to Open Data Spaces (ODS).

→ Japanese Version

Open Data Spaces Reference Architecture Model V2 (ODS-RAM V2)

ODS-RAM is a reference architecture for distributed data management across enterprises, industries, and national boundaries —documented through technology paradigms, hierarchical structure models, and protocol relationships.

Read ODS-RAM v2: README

Open Data Spaces Protocols (ODP)

ODP is a set of technical specifications that provide the functions for realizing distributed data management based on ODS-RAM and ensure the interoperability of open dataspaces.

Read ODP: README

Open Data Spaces Introductory Guidebook for Users

Open Data Spaces Introductory Guidebook for Users is a guide for business practitioners and corporate planning staff at companies that use or implement data management and AI services, to evaluate entry into dataspace-related businesses from the perspectives of whether to enter, what roles they can fulfill, and how to approach initial investment.

Read Open Data Spaces Introductory Guidebook for Users:

Open Data Spaces Introductory Guidebook for Developers is a guide for developers who are in a position to adopt, implement, or provide services based on Open Dataspaces technologies, organizing the foundational concepts and minimum configuration for beginning design, implementation, and operations.

Read Open Data Spaces Introductory Guidebook for Developer:

"Perspectives" are logical viewpoints that fulfill cross-cutting functions in Open Dataspaces. ODS-RAM consists of four perspectives: (1) Service, (2) Governance, (3) Security, and (4) Trust.

In ODS-RAM, each perspective is interrelated with the others and exerts influence across all aspects of distributed data management.

4.1 Service Perspective (P1)

The Service Perspective is a perspective that bridges the technical domain — encompassing functions and operations — with the business domain.

4.1.1 Assumption of Service Models Envisioned in ODS-RAM

The most orthodox method of implementing the Open Dataspaces architecture is (1) an approach in which domain owners themselves build a Self-Serve Data Platform and provide Data Product/Ontology Product based on DPQM (referred to as the “Distributed Service Model”). This approach, however, is only feasible for large enterprises with significant digital resources that can build and operate their own environments. SMBs, for example, often lack the financial capacity to provide the functions necessary for compliance as a domain owner and face implementation challenges.

Therefore, the assumption of (2) an approach in which a managed service provider delivers the basic software stack that constitutes DPQM on behalf of the domain owner, while the domain owner retains responsibility for providing Data/Ontology Product (referred to as the “Federated Service Model”) has been made. In Open Dataspaces, the managed service business providing this core technology is called the Dataspace Service Provider (DSSP), following the terminology used in Classical Dataspaces.

Open Dataspaces calls the mixture of domain owners onboarding on their own and onboarding through DSSP intermediary a Hybrid Service Model (HSM). (Figure 3)

Figure 3: Types of Service Models

In ODS-RAM, services are classified, into three formats: (A)Dataspace Fundamental, (B)Dataspace Complementary, and (C)Industry.

A. Dataspace Fundamental Services (hereinafter "DFS") refers to services that provide, as managed services, the technical implementations of the functions required to realize the fundamental protocol requirements defined in ODP.

B. Dataspace Complementary Services (hereinafter "DCS") refers to services that provide, as managed services, the technical implementations of the functions required to realize the complementary protocol requirements defined in ODP.

C. Industry Services (hereinafter "IS") refers to services that provide business applications and business platforms specialized for specific industries and domain use cases. These generally correspond to application services already offered in existing businesses, such as AI, BI (Business Intelligence), and DI (Decision Intelligence).

The set of services envisioned in ODS-RAM is organized as shown in Figure 4. While not exhaustive, this section defines the most representative services within DFS and DCS. Technical specifications required for implementation in service provision are described in the protocols, while the approach to governance, trust, and security is presented in the perspectives P2 through P4.

Figure 4: Service Map

4.1.2.1 Dataspace Fundamental Services (DFS)

ⅰ. Core services refers to services within DFS that provide, as managed services, the core components playing a central role in each of layers L1 through L4. In ODS-RAM, third parties may provide managed services for core components — such as the semantics component, identity component, transaction component, and data store — within the scope of contractual relationships based on terms and conditions agreed upon by users.

ⅱ. Semantics modeling Service refers to services that provide, as services, the design of meta-models published by semantics providers in L4 and the assignment of such models to data.

ⅲ. Discovery and search service refers to a service that provides functionality for discovering and searching endpoints in L4.

ⅳ. Credential issuing service refers to a service that provides credential issuance as a service offering in L3.

4.1.2.2 Dataspace Complementary Services (DCS)

ⅰ. Heuristic contracting service refers to a service that provides functionality enabling newly discovered service users and service providers on the dataspace to enter into new contracts electronically, either independently or by leveraging third-party contracting services.

ⅱ. Clearing and payment service refers to services that provide functions enabling users who have newly discovered an endpoint to electronically establish a new contract with the service provider directly or through a third-party contract service.

ⅲ. Marketplace service refers to a service in which a third party provides functions related to the buying and selling of data, acting as an intermediary between data providers and data users, or a service in which a data provider or data user provides such functions.

The Governance Perspective is a perspective that establishes common rules and policies to achieve specific objectives within the ecosystem, and performs cross-cutting management, oversight, and administration.

Open Dataspaces are premised on a design that DOES NOT depend on the institutional or regulatory framework of any specific jurisdiction. This is because, given that Open Dataspaces targets distributed data management spanning countries, regions, and industries, incorporating any single legal framework or associated legal requirements into the protocols would risk falling into Institutional Lock-in — institutionally binding participants and erecting barriers to entry in global markets. Accordingly, ODP does not itself impose obligations to comply with specific legal requirements or impose techno-legal requirements.

However, a design that avoids institutional lock-in does not mean that ODS-RAM exempts participants from legal compliance obligations. For example, in order to support the various usage controls that exist legally and technically, ODS-RAM takes responsibility for providing the interface for Heuristic Contracting Protocol — a protocol related to electronic contracting — as an optional mechanism. This protocol DOES NOT include independent contract negotiation procedures relating to legal frameworks. Rather, it is designed to merely provide a connection point with third-party application services offering electronic contracting, for which a large market already exists. Legal and institutional localization concerning data sharing contracts is expected to be implemented as a complementary measure outside the data transaction process. In distributed data management across enterprises, industries, and national borders, different regulatory requirements exist for each applicable jurisdiction (data protection, privacy, security, export control, intellectual property, sector-specific regulations, etc.), and legal compliance should be implemented effectively in accordance with each applicable regulatory framework.

Regarding the organization of functions within the governance perspective, it is necessary to examine common rules and policies required at each of layers L1 through L4, including the generally anticipated functions of Standardization and Conformity assessment. Implementers of open dataspaces technologies are required to implement ODP and to conduct governance that reflects the legal requirements of the jurisdictions, industries, and use cases they target.

To facilitate efficient distributed data management, it is important to adopt a Unified Meta Identifier (UMI) as a common identification rule across open dataspaces. The unified meta identifier is developed in a form that abstracts identifier systems that have been individually optimized within enterprises and industries and exist as heterogeneous systems. The UMI can be understood as an important foundation for resolving compatibility, discoverability, and semantic interoperability in distributed data management. As a UMI, for example, IRI (International Resource Identifier) is assumed, and the specific specifications are defined in ODP.

The Security Perspective adopts Security by Design as its fundamental principle, treating security not as an assumption but as a design target. It also adopts a design that applies cyber-physical security requirements — including identification/authentication, data protection, availability, observability, and response/recovery — across layers, assuming a dynamic environment in which cyberspace and physical space interact with each other.

The Security Perspective upholds the following three principles, separating policy determination and enforcement to ensure consistency, explainability, and auditability:

1. Zero Trust (always verify)

2. Least Privilege (grant only the minimum authority required for operations)

3. Policy-Driven Control (dynamic evaluation based on purpose of use and context)

Taking interoperability and governance into consideration, the design incorporates the verification and explainability of semantics and ontology, lifecycle management, and transparent lineage.

The security perspective within each layer is organized as follows:

• Semantics Layer (L4): Clarify the responsibilities of destination resolution and semantic resolution, and operate with a role-separated interface and a trust verification framework. Semantics and ontology are managed based on minimization, anonymization, and appropriate handling policies, and provenance and auditability are ensured through explainability, propagation of changes and revocations, and observability metrics. Flexibility for extensibility in accordance with OWA is maintained while governance of interoperability is considered.

• Identity Layer (L3): Identification, authentication, and authorization are designed within a framework that realizes zero trust and least privilege, supporting dynamic access control based on attributes and relationships. Data providers' usage control is technically supported through policy-driven and context-based decision-making. The design ensures consistency and auditability through the separation of policy evaluation and enforcement.

The principles of the security perspective are premised on not being limited to technical measures, but on integrating the allocation of responsibilities among participants, operational rules, and audit and evaluation frameworks presented in the governance perspective. Governance to ensure interoperability, fairness, protection of trade secrets, and legal compliance is clearly defined, and flexibility to accommodate future expansion and technological evolution is maintained.

The Trust Perspective adopts Trust by Design as its fundamental principle, treating trust not as an assumption but as a design targeta design target. Not only within specific domains, but in data management across enterprises and national boundaries, trust is a quality that should be constructed through design. This is why ODS-RAM explicitly separates the Trust Perspective (P4) from the Identity Layer (L3).

ODS-RAM decomposes identity into three elements, assigning different responsibilities to each:

• Identity Proofing: Guarantees that the entity exists in the real world. That is: which real-world individual or organization does this entity correspond to?

• Authentication: Confirms the entity's claim. That is: is this entity the owner of the claimed identity?

• Authorization: Permits actions based on the relationship between the entity and the resource. That is: is this entity permitted to perform this operation on this resource right now?

The most important thing in the Trust Perspective is not to equate an "authenticated entity" with a "trustworthy entity".

In Open Dataspaces, the required trust level is agreed upon according to the risks and purposes of distributed data management, and a purpose-appropriate trust structure is constructed by combining means such as verification, signing, and timestamping. This enables Open Dataspaces to realize not complete unification, but trust interconnection based on order and a benign discipline.

5.1 Types of Protocols

Open Data Spaces Protocols (ODP) *2 are a set of technical agreements that provide the functionality to realize distributed data management and ensure interoperability. ODP consists of "Fundamental" and "Complementary" protocol groups. (Table 2)

Table 2: Protocol Types in ODS-RAM

The following is a list of the protocols that constitute ODP. (Table 3)

Table 3: List of Protocols

※ F = Fundamental (Mandatory), C = Complementary (Optional)

Details: For detailed specifications of each protocol, please refer to ODP.

Footnotes

*2 Open Data Spaces Protocols.

Purpose and Background

This protocol specification document (Open Dataspaces Protocol: ODP) aims to provide an abstract specification of interoperable communication procedures (Protocol) that references the Open Data Spaces Reference Architecture Model (ODS-RAM) and aligns with its design principles. It translates the functions of each layer and perspective described in ODS-RAM into an abstract protocol specification, providing implementers with technical development guidelines grounded in its design philosophy. Furthermore, it seeks to deliver an abstract specification with extensibility and generality that, while presenting reference implementation examples, offers implementers flexibility in their choice of technology stack.

Status of the Protocol Specification

This protocol specification is established as the official normative protocol specification within the ODS ecosystem and will be continuously updated in accordance with revisions to the ODS-RAM and related documents.

Scope

This specification covers the following domains and corresponds to each layer and perspective defined in the ODS-RAM.

Figure 1 Relationship Between Layers and Perspectives in ODS-RAM

The primary readers of this specification include:

• System architects and engineers who design and operate Open Dataspaces

• Developers implementing transaction connector, identity infrastructures, and semantic infrastructures

• Data management departments engaged in cross-industry data collaboration

This repository manages the official protocol specification (Normative Document) that technically clarifies interoperable communication procedures (Protocols), with reference to the Open Dataspaces Reference Architecture Model (ODS-RAM) and in alignment with its design principles.

The purpose of this document is to translate the functional requirements defined in each layer of the ODS-RAM into concrete protocol specifications, thereby providing clear and implementable specifications to ensure consistent compliance by implementers.

Each protocol is defined using a two-layer structure consisting of a logical definition (Protocol) and an implementation example mapped to a specific technology stack (Binding).

• Protocol (Abstract Specification): Defines technology-agnostic logical message models, normative requirements, and state transitions.

This protocol defines the logging function within ODS-RAM.

Based on three categories—communication logs, service logs, and processing logs, the logging function aims to enable comprehensive recording and analysis of the system’s communication status, processing results of individual services, and overall monitoring and operational conditions. Each log category is designed and operated according to different retention requirements, security requirements, and intended purposes.

• The logging function SHALL consistently provide the capability to record events that occur within the components of Open Dataspaces and that require recording, by attaching 5W1H information based on the requirements of each event.

• When recording logs, mechanisms SHOULD be incorporated to appropriately protect information. In particular, for highly confidential information, mechanisms SHOULD be provided to implement measures such as tamper prevention.

This protocol defines the monitoring function within ODS-RAM.

The monitoring function continuously tracks the operational status of data transactions and provides functionality for the early detection of anomalies and failures. Based on data collected and aggregated through the logging function, this function enables real-time status awareness, system visualization, and early detection of anomalies.

• The system SHALL provide the capability to calculate metrics from data collected by the logging function.

  • Rationale: To enable appropriate monitoring of various conditions.

This protocol is a Fundamental Protocol corresponding to the L1 "Data Trust Assessment" of ODS-RAM, and is responsible for "an interface that enables the assessment and calculation of data integrity and non-tamperability (not including the functionality of the assessment and calculation of integrity and non-tamperability itself)."

The "Data Trust Assessment" Protocol Specification is scheduled for public release in fiscal year 2026.

The Notifier provides functionality for delivering notifications containing information to be shared between data providers and consumers regarding updates and receipt status related to data transactions.

This layer covers the following domains:

• Notification Destination List Management Provides functionality for managing notification destination lists required when a Data Provider notifies Data Consumers of the registration, update, or deletion of provided data.

• Notification Management Provides functionality for managing notifications issued by Data Providers and for enabling Data Consumers to review notification information.

This section describes a concrete communication binding (e.g., HTTPS, file transfer, WebSocket). All content in this section is non-normative and provided as an example implementation.

• This protocol uses HTTPS (TLS 1.2 or higher) and communicates via RESTful HTTP request/response.

• Endpoints: HTTP methods (GET, POST, PUT, DELETE) are used against specified URIs.

• This protocol uses HTTPS (TLS 1.2 or higher) and communicates via RESTful HTTP request/response.

• Endpoints: HTTP methods (GET, POST, PUT, DELETE) are used against specified URIs.

• Data Format: Request and response bodies use JSON format.

For each field used in this binding, the following information is provided:

This protocol is a Fundamental Protocol corresponding to the L1 "Data Trustworthiness and Quality Assessment" of ODS-RAM, and is responsible for "an interface that enables the assessment and calculation of data quality and trustworthiness (not including the functionality of the assessment and calculation of quality and trustworthiness itself)."

The "Data Trustworthiness and Quality Assessment" Protocol Specification is scheduled for public release in fiscal year 2026.

Dehghani Z. (2019). How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh.

Dehghani Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale. O’Reilly Media.

Franklin M, Halevy A, Maier D. (2005). From databases to dataspaces: a new abstraction for information management.

Halevy A, Franklin M, Maier D. (2006). Principles of Dataspace Systems.

Overview

This protocol is responsible for endpoint and process control as well as data transfer, and provides functionality that enables transactions to be established as the nexus connecting each layer.

The core component group of this protocol, referred to as the Transaction Component, serves as the junction point among protocols defined in ODP. It communicates with each layer and perspective (Common Functionalities, Fundamental Protocols, and Complementary Protocols).

This protocol defines the following transaction management.

• Data transfer

  Provides functionality to transfer data from a data store endpoint in response to requests from a Data Consumer.

  To support data transfers across different data structures (structured / unstructured) and processing modes (synchronous / asynchronous), the data plane modules are logically classified into the following four types:

  • Web API Transfer Module

    A data plane module specialized for transferring synchronous structured data (e.g., Web APIs).

  • Stream Transfer Module

    A data plane module specialized for transferring asynchronous structured data (streaming data).

• Authentication and Authorization Integration

  Provides request-level authentication and authorization control in coordination with a credential issuance service and the Identity & Trust（L3）.

• Logging Records historical information and information required for clearing and payment (DCS) in coordination with Logging (Common Functionalities).

The following concepts are required for this protocol:

This specification defines the Web API Transfer Module as a minimum implementation example.

• Data transfer within Open Dataspaces SHALL be performed through a data plane module.

  • Rationale: To ensure reliability and interoperability within Open Dataspaces.

• The architecture SHOULD maintain extensibility to support multiple data structures and transfer methods.

• The module SHOULD integrate with the Identity & Trust（L3) to perform request-level authentication and authorization control.

  • Rationale: To ensure consistent access control, security, and interoperability across Open Dataspaces.

• The module SHOULD be capable of recording the minimum data required by Dataspace Complementary Services (DCS).

The protocol handles the following types of messages:

Messages exchanged in this protocol consist of the following elements:

This section describes the states handled by this protocol.

This section describes the error handling used in this protocol.

This chapter describes the purpose, intended readers, and scope of ODS-RAM.

1.1 Purpose and Significance

"Open Data Spaces (ODS)" is an open and scalable foundation for distributed data, built on organizational and national diversity by design. “Open Dataspaces” as a general term in this document refers to a new-generation distributed data management approach and its constituent concepts. Its design draws on the original dataspace papers in the U.S. (Franklin et al., 2005; Halevy et al., 2006) and data mesh (Dehghani, 2019; Dehghani 2022) as its core, and incorporates verification through collaborative R&D with private companies and industry groups at a commercial level.

This document is a reference (Reference Architecture Model) presenting the technical paradigm for users of open dataspaces technology, including a layered structural model for ensuring interoperability. To realize the three pillars of the distributed architecture, Open Dataspaces adopts three core design principles: (1) Vendor-agnostic, (2) Institution-agnostic, and (3) Product-Like, Service-Oriented Design:

1. Vendor-agnostic: Open Dataspaces assumes multi-cloud and cloudless operation and adopts a vendor-agnostic design that does not depend on any specific company’s services or products.

2. Institution-agnostic: Open Dataspaces explicitly separates the institutional and regulatory requirements of specific jurisdictions from its technical specifications. It is designed for localization under various institutions and regulations and provides an architectural paradigm and technical specifications that are adaptable globally.

3. Product-Like, Service-Oriented Design: The problems to be solved and the functional requirements always reside in the market. Essential needs do not lie in legal systems, regulations, or the products of specific vendors. Designers must work backwards from the innovations the market latently demands and pursue Product Market Fit (PMF) through agile validation. Rigid technical specifications become obsolete, and the market rejects them. Open Dataspaces places high importance on the question of whether something contributes to Make Money, Save Money.

This document aims to ensure cross-cutting interoperability toward the realization of "Data Free Flow with Trust (DFFT)" *1 and to serve as a common reference model for distributed data management.

The primary readers of this document is engineers involved in the adoption, implementation, and planning of data management and AI-related technologies across a wide range of domestic and international industries:

• Architects and technical leads at companies responsible for deploying open dataspaces technologies

• Architects and technical leads at software companies and their technical divisions seeking to implement distributed data management services leveraging open dataspaces technologies

• Developers, academics, students, and others who wish to explore open dataspaces technologies.

Readers are expected to have a foundational knowledge of data management technology and business development.

This document is also intended to be referenced as a meta-architecture when designing new architectures or evaluating existing architectures for the adoption of distributed data management technologies across enterprises, industries, and national borders.

This document addresses technical approaches to distributed data management and covers the following items as a Reference Architecture Model:

In Scope:

Out of Scope: ODS-RAM is not a reference architecture that encompasses all data management, and therefore not all projects need to reference this document. This document also does not cover the following topics:

• Explanation of design philosophy and architectural paradigms

• Fundamental principles and industry requirements for architectural design (e.g. context catalog)

• Implementation and practices related to specific products and vendor-provided services

Table 1 Reference Documents

Footnotes

1 Proposed at the World Economic Forum Annual Meeting (Davos Forum) in Geneva, Switzerland in 2019, and incorporated into the Leaders' Declaration with the support of heads of state at the G20 Osaka Summit in June 2019. Digital Agency. Overview of DFFT.

Identity & Trust (L3) provides functionality that identifies participating entities and establishes the trust foundation ensuring that data exchange occurs only between legitimate entities and with authorized access to legitimate resources.

This protocol covers the following domains:

• Authentication

  Identifies and authenticates both natural persons (Human) and systems (Machine) as subjects, and enables authentication appropriate to the operational context.

This protocol is a fundamental protocol that corresponds to ODS-RAM L4 Metadata Exchange and facilitates the exchange of metadata relating to the location and semantics of data, enabling data discoverability and semantic interpretation in distributed environments.

RDF (Resource Description Framework) is adopted as the information model for metadata, and JSON-LD and Turtle are adopted as data model formats. By publishing this metadata, providers of data and services enable easier discovery, interpretation, and utilization of data and services. Furthermore, by using higher-level protocols such as Discovery and Search on top of this foundational protocol, even if data and services are distributed across a network, the entire Open Dataspaces can function transparently as a single system. This metadata is primarily intended to associate real-world entities such as mobility and supply chains with access to data and services in the cloud; however, the former is not mandatory.

Through the mandatory metadata concerning services and access, the external specifications of services are grounded in a globally resolvable manner, and the necessary information for access, including destination information, becomes explicit.

These metadata components are constructed on the side of general web application servers and clients. A metadata server statically or dynamically retrieves metadata from an application server.

• This protocol uses HTTPS (TLS 1.2 or higher) and communicates via RESTful HTTP request/response.

• Endpoints: HTTP methods (GET, POST, PUT, DELETE) are used against specified URIs.

• Data Format: Request and response bodies use JSON format.

• Asynchronous processing A form of communication — such as batch processing, file transfer, and streaming — in which processing continues without waiting for the result of an external call, and the result is received via a callback or similar mechanism. The receiving side continues to receive data until the calling side stops processing.

• Backward compatibility A state in which a newer means within the same family encompasses (is compatible with) the specifications and functions of older means.

This protocol is a fundamental protocol that corresponds to ODS-RAM L4 Discovery and Search and is responsible for the advancement of discovery and search based on metadata, and performs resource discovery and endpoint resolution using information published on the Metadata Exchange.

This section describes definitions when mapped to an actual communication method (e.g., HTTPS, file transfer, WebSocket). All content described below is non-normative (examples).

• Communication protocol: HTTPS (TLS 1.2 or higher)

• Message format: JSON-LD

• Encoding: UTF-8