4.1 Choosing a Participation Model: Distributed vs. Federated

ODS-RAM offers two implementation patterns: the "Distributed Service Model" (in which the organization directly implements and operates ODS Protocols) and the "Federated Service Model" (in which the organization participates via a managed service provider). Table 4 presents an overview of the Distributed, Federated, and Hybrid models, the last of which combines elements of both. For users, the federated model tends to lower the barriers to entry in the initial stages. It should be noted that even in the federated model, the data provider retains responsibility for data and ontology, and exercises usage control.

Table 4 Participation Models in ODS-RAM

Open Dataspaces is not a centralized platform but a distributed architectural paradigm in which multiple parties, centered on domain owners, each fulfill distinct roles and responsibilities. When evaluating entry and adoption, it is important to understand one's own position not from the perspective of "which entity to become", but rather "which functions and responsibilities to take on". (Table 5)

Table 5 Types of Users in Open Dataspaces

Participation in Open Dataspaces does not require uniform compliance with all requirements from the outset; phased adoption in line with the organization's own maturity is both realistic and effective. Table 6 presents the levels of phased adoption.

Table 6 levels of Phased Adoption

The key to successful participation in Open Dataspaces is to advance not from "abstract discussion of the framework" but in alignment with actual use cases. To progress participation in a phased manner, it is practical and effective to start by establishing the minimum necessary functions and governance structures within the use cases in which the organization has a direct stake.

The following questions are useful as a starting point for selecting use cases:

• Is the organization primarily a "data provider," a "data consumer," or both?

• What is the current level of cost and effort spent on individual API integrations and CSV-based data exchange? (Save Money perspective)

• How would data obtained through Open Dataspaces contribute to the organization's AI initiatives and BI/DI capabilities? (Make Money perspective)

The next chapter systematizes the entry evaluation process for organizing answers to these questions.

2.1 Industrial Structural Transformation

The structure of value creation has undergone significant change in recent years. A model in which value is continuously generated not only through performance and quality at the point of manufacture, but also through functional updates during operation and integration with external services, is becoming the norm. This shift is observed across many sectors, not just the automotive industry or manufacturing industry, and operations and services that leverage data and software are increasingly becoming the center of value competition.

2.2 Global Structural Change and the Reality of Platform Competition

In digital domains such as search, operating systems, social media, e-commerce, and cloud computing, platform-based businesses built on the accumulation of users and data have established competitive advantages. This is driven by a network effect: as more users join, more data accumulates, which enables service improvements, which in turn attracts even more users.

In the domain of industrial data collaboration that this document addresses, however, different dynamics prevail compared to consumer-facing platforms. Data exchanged between enterprises comes with prerequisites such as contractual terms, liability boundaries, confidentiality requirements, and regulatory compliance, meaning that centralized management or lock-in by a single entity is not necessarily rational. According to research by NEDO (New Energy and Industrial Technology Development Organization)*1, the digital-related market centered on applications and middleware for such industrial data is expected to continue expanding, with projections reaching approximately 1.2 trillion dollar globally by 2040.

2.3 The Structural Problem of "Data Exists But Cannot Be Used" and Data Access Capability

In value creation involving AI and other technologies, competitive advantage is determined less by what data a company possesses and more by whether it can access the necessary data under appropriate conditions — what can be called data access capability. Yet many enterprises have not made sufficient progress in leveraging external data. The root cause lies not in a lack of effort by individual companies, but in structural factors. The structural challenges that impede data collaboration are systematically documented in Design Philosophy. This document proceeds on the premise that these challenges exist.

The next chapter examines how Open Dataspaces differs from conventional data management frameworks and reviews the functional structure that users need to understand.

Footnotes

*1 New Energy and Industrial Technology Development Organization (NEDO). (2025). Market Size Study of Data Spaces and Impact Modeling & Scenario Analysis Report.

Chapter 5　The Process for Evaluating ODS Protocols Adoption

This chapter organizes the evaluation process by which user enterprises determine whether to enter dataspace-related businesses. The process proceeds in four steps: "(1) Identifying the organization's own challenges and use cases," "(2) Selecting an entry pattern," "(3) Validating feasibility," and "(4) Making the entry decision."

5.1 Step 1: Identifying the Organization's Own Challenges and Use Cases

It is important that entry evaluation begins not from "responding to Open Dataspaces as a technology" but from "solving the organization's own business challenges".

In the world of data management, the principle known as "Garbage-in, Garbage-out" illustrates that collecting large volumes of data without a clear purpose results in nothing more than mounting running costs, with ROI steadily worsening. Breaking free from the illusion that "something good will happen if we just collect data," and instead collecting only the data that is necessary — working backward from the purpose of solving a specific problem — will be the key to project success.

The questions shown in table 7 are examples of how to articulate specific challenges as a starting point for this discussion.

Table 7 Questions to Identify the Organization's Own Challenges

A users entry strategy can be organized as a combination of the following four axes. These axes are not independent — their combination gives concrete form to the entry approach.

Choose from: data provider, data consumer, or a combination of both. Even within the same function, which role the enterprise takes on changes how value is articulated and where responsibility boundaries lie.

Identify which of the following represents the organization's greatest pain: 'Where to Get' problem (DAD), 'What to Mean' problem (OSI), or 'Who and How to Use' problem (IUC).

Distributed (the organization implements and operates protocols in-house) or federated (using managed services). In the initial stages, the federated model tends to lower entry costs.

Determine whether the organization will design its own data provision scope, terms of use, and SLAs, or whether it will operate within the framework of a managed service.

In addition to a PoC (Proof of Concept) that confirms technical operability, a PoV (Proof of Value) that validates "whether this makes sense as a business" is indispensable. Table 8 presents the steps for feasibility validation.

Table 8 Steps for Feasibility Validation

Whether the organization can form its own hypothesis with a sense of the numbers for the following questions serves as one benchmark for deciding whether to proceed to full-scale entry.

• Relative to current individual integration costs, how much cost reduction (Save Money) can be expected after Open Dataspaces entry?

• To what extent will new revenue and competitive advantage (Make Money) emerge from the use of external data?

• Is the initial investment required for entry (human resources, technology investment, external service costs) acceptable within the business plan?

The next chapter organizes the implementation planning process following the decision to enter.

3.1 Concepts of Open Dataspaces

Open Dataspaces is neither an extension of an enterprise's internal data infrastructure nor a shared platform controlled by a single company. What matters is not "collecting all data in one place (Push and Ingest)," but rather "handling data in a distributed state — where it is, what it means, and who can use it and how (Serving and Pull)."

As an approach to distributed data management, "Data Mesh" has already attracted significant attention in the United States and elsewhere, with a growing number of companies adopting it. However, data mesh focuses on how to manage data scattered within an organization while keeping it distributed, and does not address data management that crosses organizations and national boundaries. Open Dataspaces is an approach designed to fill this gap.

There are various challenges in cross-organizational data management, and Open Dataspaces provides solutions addressing primarily the following three:

1. "Where to Get" Problem: Addresses the existence, identity, and discoverability of data. (e.g., Where does that data exist in the first place? Does that data refer to the same thing as this data?)

2. "What to Mean" Problem: Addresses the meaning, vocabulary, and semantic consistency of data. (e.g., What does that data mean? Is the meaning of that data consistent with the meaning of this data?)

3. "Who and How to Use" Problem: Addresses subject trust, access, and terms of use. (e.g., Who is attempting to access the data? Who is allowed to access that data? How must that data be used?)

These are organized as three pillars accordingly:

• （1）DAD（Data Addressability and Discoverability）

• （2）OSI（Ontology and Semantic Interoperability）

• （3）IUC（Identity and Usage Control）

The design philosophy, principles, and architectural implications of these three pillars are documented in Design Philosophy and ODS-RAM. This document limits its coverage to mapping the role of each pillar to the entry opportunities available to users.

Conventional data management has relied on two approaches:

1. consolidating data internally for management and analysis

2. establishing individual point-to-point connections with each required counterpart.

Open Dataspaces takes a different approach — neither consolidation nor individual negotiation — by handling existence, meaning, and terms of use while keeping data distributed. Table 2 presents a comparison with conventional data management approaches. For a more detailed comparison, please refer to "Design Philosophy".

Table 2 Comparison with Conventional Data Management Approaches

The reasons data providers hesitate to share data externally go beyond the risk of information leakage alone. Compounding problems include: "We cannot accurately communicate what our data means to external parties," "Our data may be conflated with other companies' data and misused," and "It is difficult to operationalize terms of use." Open Dataspaces enables the separate handling of issues related to data existence and identification, data meaning and vocabulary, and access and terms of use. This separation makes it easier for data providing enterprises to design external data sharing within the necessary scope and conditions, without needing to unify their internal systems or internal identifiers.

By separately handling discoverability, semantic organization, and the management of entities and terms of use, Open Dataspaces reduces the operational burden of "interpreting meaning, ensuring consistency, and confirming terms of use" after acquiring external data. This makes it easier for utilizing enterprises to incorporate external data into BI/DI analysis, business applications, and AI initiatives.

Entry opportunities for users in Open Dataspaces can be organized as shown in Table 4. These represent general business model perspectives applicable across industries and use cases.

Table 4 Entry Pattern to Open Dataspaces

It should be noted that in Open Dataspaces, N:N connectivity becomes a realistic option through a degree of discipline and interoperability. The scale of business value that cannot be achieved through one-to-one individual integrations represents the fundamental motivation for participation in Open Dataspaces.

Finally, the relationship between the AI industry and the Open Dataspaces market is examined. In AI applications — particularly in analytics based on operational data and the use of Agentic AI — the ability to continuously handle "data context, meaning, terms of use, and currency" is more important than simply having a large volume of data. The Design Philosophy also highlights that in the Agrntic AI era, unique context is the essence of data, and emphasizes the importance of domain owners explicitly providing that context as meaning (ontology). Open Dataspaces technology provides the technical foundation for addressing these challenges through endpoint discoverability, semantics and ontology, and identity and usage control.

As a result, the following kinds of benefits can be expected:

• It becomes easier to perform reasoning and interpretation that presupposes relationships and context between data points

• It becomes easier to construct AI pipelines that account for data provenance and currency

• It becomes easier to incorporate external data into AI applications without relying solely on individual integration efforts

The next chapter builds on this foundation to examine, from the perspective of participation structure, the positions that users can occupy.

This chapter organizes the standard process for users adopting Open Dataspaces. The process proceeds in four steps:

• (1) Organizing the project structure and architecture design

• (2) Selecting an implementation approach

• (3) Data handling agreements

• (4) Ensuring data trustworthiness

When launching an Open Dataspaces implementation project, begin by clarifying the following.

• Clarify the purpose and objectives of adoption (starting from the challenge identification in Section 5.1)

• Identify internal stakeholders (data management, IT, business units, legal) and build consensus

• Identify external stakeholders (partners, managed service providers, integration vendors)

Key deliverables:

• Project Proposals: Background of the challenge, business positioning, system configuration policy, legal/compliance considerations, and business process definitions

• Roles and Responsibilities Matrix: Delineation of areas handled by the organization itself versus those handled by managed service providers and integration vendors

Implementation approaches can be broadly divided into two patterns in ODS-RAM: in-house development (Pattern A) and use of managed services (Pattern B). Each is described below to provide a basis for deciding which to adopt.

An approach for organizations that have technical resources and wish to implement and operate ODS Protocols internally.

• Proceed with development while verifying that the implementation of ODS Protocols

• Leverage SDKs and reference implementation software (ODS Middleware), while developing business-specific logic in-house

• Deliverables include connectivity and API specifications implementing ODS Protocols, and operational procedures

When technical resources for implementing and operating ODS Protocols in-house are limited, or when minimizing entry costs at the PoC stage is a priority, the federated model — using services provided by managed service providers — becomes a realistic option.

When selecting a managed service, confirm the following five perspectives:

• Interoperability: Is ODP implemented and supported, and does the service offer interoperability with other products?

• SLA and Support Structure: Do incident response, protocol update tracking, and operational support meet the organization's requirements?

• Data Usage Control: Even in the federated model, can the organization retain control over the management and usage of its own data and ontology? (Is the service designed to avoid consolidating data with the service provider?)

Distributed data management through ODS requires both a reliable technical foundation and the legal compliance that underpins it. It is important to organize data handling agreements while taking the following considerations into account:

• Data Sharing Agreements: Clarify the roles, rights, and obligations among the three parties: "managed service provider," "data provider," and "data consumer." Customizing these to fit the organization's specific use case is an effective approach.

• Explicit Terms of Use and Prohibitions: Data providers shall establish terms of use covering the purpose of use, duration of use, and whether secondary use or third-party provision is permitted. Ownership of intellectual property rights and terms of use should also be clearly defined in contracts in advance.

• Traceability of Contract Execution and Performance: Ensure traceability of contract execution and performance through the use of digital contracts, smart contracts, etc..

To ensure the trustworthiness of entities and data, it is necessary to organize authentication schemes (Table 9) and provenance management.

Table 9 Authentication Schemes

When designing a provenance management, it is effective to organize it in the following phased process:

1. Visualize the data processing flow: Map the flow of data the organization provides and receives, the parties involved, and the points at which data is transformed or processed.

2. Identify risks: Identify the primary risks at each data handoff point (information leakage, misuse, violations of terms of use, etc.).

3. Select an authentication scheme: Determine which combination of self-declaration, mutual authentication, and third-party certification is appropriate, based on cost and the importance of the use case.

1.1 Purpose of This Document

The "Open Data Spaces Introductory Guidebook for Users (this document)" is not a technical manual or procedural guide explaining individual specifications or implementation steps, but rather focuses on providing the conceptual understanding and evaluation perspectives necessary for making entry decisions. It is important to develop this understanding while verifying what is possible with standard specifications using actual reference implementation software, and this is intended to be covered with concrete examples in the ODS Introductory Guidebook for Engineers. Accordingly, this document serves as a prerequisite step, aimed at helping users(both in private and public sector) understand the overall picture of Open Dataspaces from their perspective, identify where business opportunities lie, and distinguish what should be verified in implementation guides and reference implementations beyond that point.

1.2 Intended Readers

The users referred to in this document encompass a broad range of personas involving otganizations(both in private and public sectors) engaged in data management and AI service utilization:

• GTM strategy and digital transformation staff at organizations considering the use of external data (procurement, quality management, AI analysis, etc.)

• Data management and business development staff evaluating whether to provide or share their organization's data externally

• System and procurement department staff seeking to improve data collaboration with multiple business partners and supply chain partners

• Information systems and business reform staff considering the introduction of BI/DI analytics and AI services

• New business development staff considering the use (as a user) of Open-Dataspaces-related managed services and applications

This document focuses on the content necessary for users to decide whether to enter open dataspace-related businesses. Detailed specialized areas not directly relevant to that decision are not covered.

• Explanation of the concept for Open Dataspaces

• Entry axes and key evaluation points anticipated from the user perspective

• Practical considerations for small-start

• Explanation of design philosophy and architectural paradigms

• Support and practices related to services provided by specific products or specific vendors

• Compliance with legal systems, and legal or governance practices

Related documents to be consulted are listed below:

Table 1 Reference Documents

This document is structured to progressively deepen the understanding necessary for user enterprises to consider entry into dataspace-related businesses. Please read on, as each chapter covers the following topics:

• Chapter 2: Industrial Structural Transformation in the Agentic AI Era and the Strategic Value of Distributed Data Management

• Chapter 3: What is Open Dataspaces?

• Chapter 4: Participation in Open Dataspaces and the Position of Users

8.1 Summary

This document was written with the aim of organizing the perspectives needed for users to evaluate entry into dataspaces-related businesses — specifically, whether to enter, what roles their organization can play, and how to allocate initial investment.

• Chapter 2 organized the changes in industrial structure and the background context that makes necessary of Open Dataspaces.

• Chapter 3 presented the fundamental concepts of Open Dataspaces and the significance of its three pillars (DAD, OSI, and IUC), and organized four entry patterns available to users.

• Chapter 4 organized the roles of participants in Open Dataspaces and the positioning of the organization itself, while Chapter 5 presented a four-step process for making the entry decision.

• Chapter 6 covered the implementation planning process, and Chapter 7!organized the three stages of Evaluation, Proof of Concept, and Rollout (GTM).

What this document has presented is neither a "universal architecture" nor "the one right answer." The focus has been on systematically organizing the points of uncertainty that users are likely to encounter, and providing a foundation for making informed decisions.

A consistent theme throughout this document has been the importance of clarifying "how far not to go" — even more so than "how far to go." Distinguishing the areas the organization itself will handle, the areas a managed service will handle, the areas integration partners will handle, and the areas to be added in the future — and clearly defining the boundaries between each — is what makes it possible to avoid excessive initial investment and sustain participation over time.

Unlike servicers, the first step for users is often to begin by "using" ODP-implemented managed services and applications. Before any technical implementation, it is an important prerequisite to understand "what it means to provide data" and "what conditions and responsibilities that entails."

Open Dataspaces may appear complex, but at its core it is a collection of simple activities — connecting, coordinating, and complementing. The three things users need to take their first step are:

1. Define the minimum use case the organization will take on

2. Rather than attempting to implement everything in-house from the outset, leverage managed services to advance incrementally

3. Learn through connections with integration partners, and expand the scope of participation in a phased manner

It is our hope that this document serves as a resource to support your evaluation and preparation, and as an opportunity to discover new possibilities for data collaboration and data utilization through Open Dataspaces.

This chapter organizes the implementation stages for users actually launching dataspace-related businesses into three phases (Table 10) :

1. Evaluation

2. Proof of Concept

3. Rollout (GTM, Go-to-Market)

These stages do not progress in a strictly linear fashion; they are advanced iteratively in light of PoC results and changes in the external environment.

Table 10 Implementation Stages of Open Dataspaces

Building on the entry pattern organized in Chapter 5, this phase gives concrete form to "what will and will not be built" as the construction scope. Table 11 presents the considerations to be addressed in this phase.

Table 11 Considerations in the Evaluation Stage

Confirm "whether the technical, business, and operational elements are viable" using a minimum viable configuration (MVP). The objective is not to achieve a high level of completeness, but to gain confidence that the system — including operations — can function end-to-end, with a design that structurally separates areas requiring external alignment from areas left to the organization's own discretion. Table 12 presents the considerations to be addressed in this phase.

Table 12 Considerations in the PoC Stage

Migrate to the production environment on the basis of the feasibility confirmed in the PoC stage. What matters here is not the success of a one-off PoC, but whether the system has the structural resilience to withstand updates to standard specifications, changes in operational requirements, and the expansion of integration partners. Table 13 presents the considerations to be addressed in this phase.

Table 13 Considerations in the Rollout Stage

Table 14 presents an implementation checklist to support the adoption readiness decision.

Table 14 Implementation Checklist

• Information-technology Promotion Agency, Japan. (2026). Open Data Spaces Reference Architecture Model.

• 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, Mayer D. (2005). From databases to dataspaces: a new abstraction for information management.

• Halevy A, Franklin M, Mayer D. (2006). Principle of dataspace systems.

• Information-technology Promotion Agency, Japan; Ministry of Economy, Trade and Industry. (2025). Whitepaper: Ouranos Ecosystem Dataspaces Reference Architecture Model (ODS-RAM).

• Tsuda M. (2026). Why Open Dataspaces: Design Philosophy and the Architectural Paradigm. Information-technology Promotion Agency.