4. Perspectives
"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
4.1.2 Assumption of Service Classifications in ODS-RAM
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.
4.2 Governance Perspective (P2)
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.
4.2.1 Unified Meta Identifier (UMI)
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.
4.3 Security Perspective (P3)
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:
Zero Trust (always verify)
Least Privilege (grant only the minimum authority required for operations)
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.
Transaction Layer (L2): Consistent control from discovery through transfer and audit trail management is provided through endpoint routing, request intermediation, and the technical reflection of policy automation and agreement conditions. Transparency and reliability of control flow are considered from operational and governance perspectives.
Data Layer (L1): Data confidentiality, integrity, and quality in accordance with the selective application of CWA are design priorities, with data handling policies, tamper-detectable audit trails, and the assessability and referenceability of data quality systematically ensured. Data usage control and storage/revocation rules are explicitly defined, and a balance between use and protection is maintained.
Common Functions (Audit, Observability, Operations): Audit trail management to ensure transparency and traceability, definition of observability metrics, and frameworks for threat detection and incident response are incorporated into the overall design. Resilience requirements such as availability, business continuity, and network isolation are also considered at the design stage.
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.
4.4 Trust Perspective (P4)
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.
Last updated