Business and Organisational Building Blocks

1. Introduction

The Business and Organisational Building Blocks help data space initiatives and their participants to build (financially) sustainable, compliant, and value-driven systems. Business and organisational capabilities are organised across three key pillars: Business, Governance, and Legal (see Section 2) and four levers: Ecosystem, Data space, Use case and participant (see Section 3).

2. Overview of the pillars

These pillars shape the functionalities available to participants, guiding developers in creating robust data spaces and enabling users to effectively leverage the offerings within them (see Figure 1). The pillars are composed of 8 Business and Organisational building blocks that are explained in the sections 2.1-2.3.

2.1 Business Building Blocks

The Business Building Blocks are critical to ensure the market value of the data space. They are the starting point for stakeholders interested in developing a business plan for their data space. These building blocks help data space initiatives to optimise resources and design for value creation. They also help businesses sell their products and services. At the heart of these building blocks is the relationship between the data products and services available, their use by stakeholders and users, and the integration into a financially sustainable business model. This includes understanding the data space offerings, the packaging for use cases, and the role of intermediaries and operators who navigate regulatory requirements to add value.

The Business Model building block provides insight on how to construct the business model of the data space. The building block also indicates how a business model for a data space built by a public sector differ from one built by a private sector.
The Use Case Development building block shows how to identify, refine, implement and improve a use case.
The Data Space Offerings building block provides an understanding of the offerings from a business perspective and provides a strategy to develop and maintain them.
The Intermediaries and Operators building block explains the consequences of using a single operator model versus multiple data space intermediaries. It also indicates how a governance authority can determine whether an intermediary or operator model works best. The building block also covers key regulatory questions that might influence the choice around an operator or intermediary model.

2.2 Governance Building Blocks

Governance is essential to a data space as it ensures transparent decision-making, enforces data-sharing agreements, and maintains trust among participants. Strong governance frameworks also help to manage compliance with EU regulations, making data transactions secure and legally sound.

The Organisational Form and Governance Authority building block provides options for organisational forms of a data space, the type of legal entity the data space may have and aspects to be considered when establishing the governance framework. The building block also provides insights in the data space governance authority functions, such as setting the rules of a data space, defining the governance framework, ensuring compliance, and resolving conflicts, thereby fostering trust and data quality.
The Participation Management building block aims to identify participants of the data space and their rights and obligations. It provides insights on participant onboarding and offboarding, emphasising the risks associated with poorly managed participation, including data governance challenges and reduced collaboration. The building block highlights the need for clear rules, inclusive governance, and regulatory compliance.

2.3 Legal Building Blocks

Aligning the design of a data space with the rules and norms set out in the legislation is essential for ensuring trust, compliance, and smooth operations within a data space. The legislation sets out the rights and responsibilities of participants, sets the framework for the introduction of new rights and responsibilities (i.e., contractually), and determine the rules governing data-sharing. EU Data legislation incorporates important values to be reflected in data spaces, such as data sovereignty, legal interoperability, and is informed by the imperative to remove barriers across borders and has the effect of reducing transaction costs by harmonising the rules governing data spaces. The legal building blocks provide an introduction and guidance to the most relevant legislative frameworks, including governing contractual relationships and efforts at providing standard and modular contractual clauses for data sharing. This helps to ensure your data space adheres to relevant legal frameworks throughout its lifecycle.

The Regulatory Compliance building block indicates how to ensure compliance within the data space and outlines actions to be undertaken by data space participants or potential policies that the governance authority shall consider. The building block is focusing on legal triggers, i.e. elements, criteria or events that have occurred in a particular context of a data space and signals that a specific legal framework must or should be applied.
The Contractual Framework building block provides an overview of contracts that are essential for a data space, categorizing agreements according to their objects e.g.: institutional agreements, data sharing agreements, and service agreements. For each category of agreements, it highlights horizontal issues that are likely to emerge or to take into account common regulations to all sectors (e.g., the requirement of fairness in data contracts).

These legal building blocks provide a basic approach to organizing compliance within a data space, regardless of its specific characteristics. Regulatory and contractual requirements vary across sectors and depend on business, governance, and technical decisions. Consequently, these blocks are not intended to provide exhaustive detail or all-encompassing templates. They do, however, provide references to relevant resources and further reading and offer some initial guidance on navigating the legal landscape for data spaces.

1. Summary

The business model building block is composed of the following elements:

Element	Description
The value proposition	To develop a viable business model, you need to differentiate a data space from other data-sharing platforms or even peer-to-peer data sharing. While each data space will have a unique proposition, they likely share three commonalities: They provide efficiency gains They improve interoperability They increase sovereignty and control
A business model template	The value proposition is only one element of the business model, which needs to address questions around use cases, customers, providers, and governance. A business model template can be a useful tool to structure discussion and thoughts around the specifics of the business model.
A revenue model	The revenue model describes how to monetise the value created through data sharing, access, and services. It specifies who pays whom, for what type of data or service (e.g. access, usage, value-added processing), and under which conditions. These revenues can come from both the public and private sector.
A growth pathway	As data spaces grow, their business models also evolve. The business model of the data space should be monitored, reviewed, and adapted regularly to maximise its potential for growth and sustainable expansion.

1.1. Questions that will be answered

How is the business model of a data space distinct from a data-sharing platform?
What are some of the unique selling points for a data space that help differentiate it from other ways of sharing data, which become key to the business model?
What are some potential revenue models for the data space?
What templates can you use to construct the business model for the data space?

2. Purpose of the building block

Whether a data space is funded publicly or privately or whether it has a for-profit or not-for-profit orientation, it must have a business model that speaks to its long-term financial sustainability. The business model of a data space, however, is different from data-sharing platforms. Unlike traditional business models that underlie these platforms, a data space requires collaboration between multiple actors, balancing economic viability, governance, and trust.

This building block provides a structured approach to designing and evolving business models that ensure long-term success.

3. Elements of a business model and their key functions

3.1. What are the unique elements?

Data spaces share characteristics with data-sharing platforms, but what makes them unique is that they are not controlled by a single organisation. Also, data resides with the data owners themselves. Platforms accumulate data products and services to share between providers and recipients. But with a data space, it provides the connectors and services, but never takes control of the data itself.

Given that no one organisation controls a data space, developing the business model for a data space is also a collective exercise between its founding members, who form a governance authority. This makes strategic decision-making around business elements such as scope and pricing more complex and prone to compromise that could jeopardise the long-term viability of the data space. Having a cohesive governance authority with aligned interests is essential.

3.2. The value proposition

The value proposition of a data space differs from the value proposition of data sharing, and a key element to building a business model for a data space is to understand how it differs from other data-sharing platforms or even peer-to-peer data sharing. And as such, data spaces create value in three ways:

Efficiency gains: Reduce economic transaction costs by standardising interfaces and lowering integration efforts, especially across sectors and ecosystems.
Improved collaboration: Facilitate collaboration between data providers and consumers, which can improve interoperability.
Sovereignty & control: Ensure data owners maintain control over access and usage conditions, enhancing trust. This includes avoiding lock-in.

3.2.1. Efficiency gains

At their core, data spaces facilitate data sharing. But they also provide other benefits. They can support the development of applications, providing generic, reusable components and innovation-supporting services. Data spaces save developers time because they no longer need to develop specific interfaces for specific data sets. Data spaces provide standardised interfaces and connectors that make reusing data easier and less expensive. Furthermore, if sufficient data sources are connected, a data space can help reduce search costs.

If conditions of data usage are pre-specified and participants are verified, a data space can also help to reduce costs associated with bargaining and contracting. Trust is typically enhanced among organisations that are part of the same ‘club’, and collective action and representation can also be established within data space initiatives.

3.2.2. Improved collaboration

A governance authority coordinates the availability of data space offerings, federation and participant agent services, and value-creation services either in-house (as in the case of Djustconnect on the examples page); outsourced to data space intermediaries; or via a decentralised approach. They ensure that all of the necessary components of a data space are available and viable.

3.2.3. Sovereignty & control

Data spaces provide connectors, and do not centralise data on their own servers. Data is never copied from one location to another. In this sense, a data space allows data holders to fully control who gets access to data and under what conditions. Depending on how the governance is designed, data owners can even control or influence the decision-making process of the data space. This relates to the collective qualities of safety, security, and sovereignty.

3.3. Building out the business model

Figure 1 illustrates a template to support the development of an initial business model. Due to its collaborative nature, the business model template assists in defining who does what. It reflects participants, service providers, and members of the governance authority, as well as partners. (Please see this page for an introduction to business model innovation processes.) The numbering represents a suggested order in which the canvas can be filled.

While the template is straightforward, the assumptions that go into filling it out can be complex. Materials from other parts of this blueprint can help to develop a robust canvas around which the business model can be built. This would include:

Questions to consider	Building block
What are the promising ideas on which the data space will be built?	Use case development
What data is available and what services can make that data more useful and attractive?	Data space offerings
In which context and with whom is the data space being explored?	Organisational form and governance authority
Are there existing networks in which stakeholders already interact and by what rules are they already engaging with each other?	Participation management
What are the relevant legislation and developments in the domain for the data space?	Regulatory compliance

Other questions to consider, which are outside of the scope of this blueprint, would include:

Is there existing digital infrastructure on which the data space can draw?
What is the maturity level of the organisations involved?
Where is financing for the data space, both in its development and operational phases, coming from?

3.3.1 Elements of the business model template for data spaces

The following table describes the elements of the business model design template. In separate pages, we illustrate the elements of the data space business model alongside SCSN and Djustconnect.

Element of template		Description
1	Principles, Scope, Objectives	What is the thematic scope of the data space? What are its objectives, growth aspirations, and profit goals? These largely determine the types of use cases and participants to engage with, as well as the effort required to promote one side or the other.
2	Use Cases, Data Providers and Data Users	Which use cases are currently in scope, and which will be in the future? This operationalisation of the thematic scope aids in clarifying the data space's position and overall appeal. See Use Case Development. Who are the data providers and data recipients in these use cases?
3	Services and Providers	Which services does the data space have and which to offer? And who is providing them? We distinguish federation services, participant agent services and value creation services (See services). These services form part of the value proposition for use cases, data providers, and recipients. They can be supplied on behalf of the data space (i.e., the data space purchases services or hired personnel delivers them), or they can be provided by third parties. The governance authority may determine the number of service providers and the criteria they must meet. The different services may require different value propositions and revenue models.
4a	Governance Authority Bodies and Members	Who are the participants in the representative assembly of the governance authority? Who is eligible to join? What criteria should they meet? In certain cases, the composition of the governance authority is prescribed by law; in others, the initiative can establish procedures. Who are the participants in the execution body of the governance authority? Who is eligible to join? What criteria should they meet? How does the data space ensure that the individuals comprising the governance authority continue to fulfil their responsibilities? In some instances, the composition of the governance authority is prescribed by law; in other cases, the initiative may establish procedures.
4b	Stakeholders	Does the data space initiative need support from additional organizations, such as industry associations, governmental agencies, or non-governmental organizations? IT providers and other partners: Does the data space initiative procure services from parties that are not considered data space participants? What are their principles, and how dependent is the data space upon them?
5	People, Resources and Activities	What staff, resources, and activities are deployed by the data space to maintain operations? Cost model: What operational costs does the data space incur? The main cost factors include development costs, operational costs for data space enabling services, and costs related to the governance of the data space. For the data space to sustain itself, the revenue model must cover all expenses. What costs are associated with data space operations, and how are these costs managed? The revenues and costs must align with the data space's profit and growth strategies.
6a	Value Proposition to Service Providers	What does the data space offer to service providers? Services are part of the value proposition to attract use cases, but these service providers must also be drawn to the data space to deliver their services. Access to a large user base (e.g., data space participants) can be an attractor.
6b	Value Proposition to Use Cases, Data Providers and Data Recipients	How does the data space aim to help identify, attract, onboard, and develop use cases? This includes value propositions for both data providers and data recipients. Enabling services and value-added services are also of value to use cases.
6c	Revenue and Pricing (for Use Cases, Data Providers, Data Recipients)	How does the data space initiative generate revenue from use cases (and associated data providers and recipients), and what pricing strategy is used? How is this related to the different sides of the business model, such as use cases, data providers, data recipients, added value, and enabling service providers? How does it evolve over time (e.g., employing subsidies to establish network effects)? The income from the data space may originate from multiple sources, including public funding (project-based or ongoing subsidies) and participant fees (e.g., subscriptions, memberships, or transaction fees). The data space might also have additional external revenue and funding sources. The revenue model combines the different revenue mechanisms upon which the data space depends. What is the set of revenue models that covers the costs?
6d	Revenue and Pricing (to Service Providers)	How does the data space initiative build revenue from service providers, and what pricing strategy is used?
7	Network Effects	How does the data space aim to establish critical mass in use cases, data providers, data participants, and service providers? How does the data space aim to establish same-side and cross-side network effects? Same-side network effects arise when the presence of, for example, use cases attracts more use cases. Cross-side network effects occur when, for example, the availability of a set of value-added services attracts additional use cases or participants. We distinguish the following: How does the presence of use cases (and associated data providers and data recipients) attract other use cases? How does the presence of use cases attract service providers? How does the presence of service providers attract use cases? How does the presence of service providers attract other service providers? Establishing critical mass and network effects can be guided by temporary pricing and other incentives. For instance, in the early stages, value-added services might receive a 'sign-fee' (subsidy) to enhance their attractiveness for use cases, whereas later on, these services may be required to pay for participation.
8	Dynamic Capabilities	Monitoring: How does the data space keep track of necessary changes in the business model? Developments within the data space environment should be followed to determine whether changes in the business model are needed. Business Model Innovation Process: How does the data space identify the need to change its business model, redesign it, and implement these desired changes? Governance: How is the data space governed? While this aspect is quite broad, it may be sufficient to indicate the desired legal form and governance bodies.

The design of a business model should be supported by the ability to recognise the need for a new business model (or adaptation) and to agree upon and operationalise it.

3.4. The revenue model

While the business model canvas will help to shape the scope of the data space and points to where value is generated, it does not specifically address where revenues will come from to cover the costs or generate profits for the data space. Revenue, and the term 'business model', is sometimes interpreted as a concept exclusive to for-profit organisations. However, any data space must understand its income, revenue, and cost structure.

Not-for-profit endeavours, for example, may charge for services and accumulate funds to finance innovations, such as developing a standard for semantic interoperability, a dashboard to monitor activity in the data space, a marketing campaign, or a support line to help organisations participate. Such innovations require investment and benefit data space participants.

The table below provides a list of possible revenue models, including when it is best to use the model and what risks is presents. These revenue models are not exclusive and, in some cases, can be mixed an matched. In cases where a freemium option is possible, this has been indicated, including the type of limitation (e.g., transaction limits, usage quotas).

Revenue category	Specific model	What is paid for	Best used when	Risk	Freemium option
Membership & access	Basic subscription fees, tiered by organisation size and role	Right to join and participate in the data space	Stable governance authority with clear coordination value	May discourage high-value contributors if subscription fees are set too high	Yes (free tier for small organizations or trial periods)
	Accreditation or certification fees	Compliance and trust labels	Operating in regulated or high-trust environments	Limited revenue potential due to one-time or infrequent payments	No
	Premium ecosystem access	Access to curated networks of service providers, advanced tools, and matchmaking services	Large data space with diverse, high-quality participant network	Requires significant scale to be viable	Yes (basic access free, premium features paid)
Usage-based	Transaction fees	Each data exchange or contract executed	Mature data space with high levels of active exchange activity	May discourage early-stage experimentation and adoption	Yes (limited free transactions)
	Volume-based fees	Data volume transferred, frequency of exchanges, or connection time	Recovering operational costs of infrastructure	Pricing may not reflect actual business value created	Yes (free usage quotas)
Value-based	Commission-based pricing	Outcomes achieved or risks mitigated through data use	Clear value can be attributed to specific data exchanges	Complex to measure and enforce value attribution	No
	Revenue sharing	Percentage of downstream revenue generated	Commercial ecosystems with monetizable outputs	Difficult to track data usage and collect payments downstream	No
Service-layer	Onboarding and integration fees	Technical setup, legal agreements, and data structure alignment	Early phases of data space development or low-trust environments	Not scalable as primary revenue source long-term	Yes (basic onboarding free, complex integrations paid)
	Managed services	Quality assurance, Service Level Agreements (SLAs), identity management, and trust services	Participants lack internal operational capacity	May undermine perceived neutrality of the data space	Yes (self-service free, managed options paid)
Governance & institutional	Arbitration & rule services	Dispute resolution and rule interpretation	Contested environments or heavily regulated sectors	Revenue is unpredictable and difficult to sustain profitably	No
	Standard stewardship	Maintaining data formats and exchange standards	Fragmented or rapidly evolving technical domains	May be perceived as a "tax" if value is not clearly communicated	No
Public funding	Operational government funding	Continuous operation of public data infrastructure	Public-good or regulatory mandated domains	Creates political and budgetary dependency	n/a
	Procurement contracts	Service provision against Key Performance Indicators (KPIs)	Clear service requirements can be defined	Risk of vendor lock-in	n/a
	Programme-based funding	Delivery of defined public outcomes	Multi-year policy initiatives with stable objectives	Limited flexibility to adapt scope	n/a
Compliance driven	Regulatory mandate funding	Industry-funded infrastructure to meet government compliance requirements	Compliance-heavy sectors where regulation mandates data sharing or reporting (e.g., finance, healthcare, environmental)	Risk of minimum-viable approach; potential pushback on costs; over-specification of requirements	No

These can be used not only to generate direct revenue to sustain data space operations but also to fund another side of the business model that is not gaining sufficient adoption. Pricing will change over time, as it is used to stimulate adoption on one side over the other. Furthermore, freemium models are frequently used to build a large user base.

3.5. Evolving the business model

As data spaces grow, their business models also evolve. The business model of the data space should be monitored, reviewed, and adapted regularly to maximise its potential for growth and sustainable expansion. It is important to leverage the strengths and synergies of the existing and potential data space participants to identify growth opportunities while addressing potential challenges and ensuring long-term viability. For instance, it may occasionally be necessary to identify and develop use cases, potentially involving the subsidisation of fees; conversely, at other times, it may be essential to attract service providers with specific capabilities that add value to these use cases. The dynamics of pricing and conditions, alongside balancing supply and demand, are pivotal to successful business models.

3.5.1. A sample development pathway from SCSN

The SCSN case is an example here. Part of the operation of the SCSN data space is provided as a service by a commercial digital service provider to the SCSN foundation. However, it did not start out that way. The following development stages can be identified:

Initial Context: Several proprietary service providers facilitated interconnectivity between ERP systems, assisting specific OEMs with their supply chain coordination (e.g., invoicing and production planning) and compelling suppliers to connect to multiple platforms.
Feasibility Research: A research project was conducted to demonstrate the feasibility of creating open interoperability among these platforms.
Standard Establishment: Open interoperability standards were developed, replacing some proprietary functionalities to foster inclusivity.
Governance Formation: A governing body was created to oversee the data space, leveraging the existing organisation of manufacturing entities. The provision of federation services was transferred from a research institute to an external IT service provider.
Platform User Benefits: Service platforms adopted standardised features, allowing users to connect with a broader range of supply-chain participants.
Current Challenges: To enhance the data space's overall value, efforts now focus on increasing interactions and expanding use cases.

SCSN can essentially be seen as a privately driven initiative. Private service providers were convinced that interoperability could enhance value for supply chains. By focusing on interoperability at foundational levels while also addressing specific user benefits, the proprietary service providers balanced collective value with the potential for individual value capture.

3.5.2. A sample development pathway from DjustConnect

In a context with a large unlocked potential for data-driven applications, such as digital farming, having a semantically interoperable collection of data sources is essential for development and testing. A component of the growth involves attracting app developers who can experiment with various useful data combinations. DjustConnect serves as a noteworthy example here. DjustConnect currently manages the data space in-house through one of the founding organisations.

The development of JoinData, a data-sharing initiative for agricultural applications, followed a different development pathway. This initiative began as Smart Dairy Farming and adhered to data space principles by placing the farmer in control of data sharing while establishing interoperability and data sharing. This initiative later served as a model for the DJustConnect initiative, which was originally established by the same actors.

Proof of Concept: Initial technology-driven project demonstrating the fusion of on-farm data and sensors for precision farming.
Vision Development: Research organisations and dairy cooperatives collaborated to define a vision for efficient, farmer-controlled data sharing to enable sustainable dairy farming.
Dual Strategy Implementation: Focused on connecting existing data sources (supply) while conducting R&D projects to develop demand-driven applications.
Revenue Model Establishment: Introduced a fixed fee per farmer, initially paid by cooperatives, with a core value proposition of managing data-sharing authorisations.
Governance Evolution: Transitioned from a foundation to a cooperative structure, expanding the scope beyond dairy farming to general agriculture.
Refinement and Expansion: Shifted focus from novel applications to authorisation management for existing services, with key applications in tax, accountancy, and legal compliance.

4. Co-creation questions

In the previous section, we highlighted a few key strategic considerations. Here, we highlight a few that affect the development pathway.

Theme and scope of the data space

What is the data space’s thematic scope? (Step 1.1)
What are the objectives of the data space? (Step 1.2)
What are the data space’s growth ambitions? (Step 1.3)
What are the data space’s profit ambitions? (Step 1.4)

Use cases

How do these use cases contribute to the overarching goals and scope of the data space initiative? (Step 2.2)
How will the data space attract and expand its user base, data providers, and service offerings to achieve critical mass—where it reaches a sufficient scale to sustain itself and generate significant value? (Step 2.3)
Which use cases should the data space focus on first, and which are to be developed in the future? (Step 2.3)
What benefits do these use cases offer to these participants?

Service providers

What are the core services required within the data space, and how do they relate to the business models of the use cases and data space itself? (Step 3.1)
Which parties will provide which services? (Step 3.1)

Governance authority

What is the business model for the data space authority and its participants?
Which activities will the governance authority perform to run the data space?
What processes should the governance authority follow to fulfil its duties, and how should it be monitored and reviewed?
How does the data space identify the need to change its business model, redesign it, and implement these desired changes? (Step 2.3)
How will growth ambitions be realized? (Step 1.3)

5. Further reading

Boonstra, J., & Eguiguren, M. (2023). Alliances for sustainable futures: Creating and managing purpose-driven alliances. Edward Elgar Publishing. – This book provides guidelines on the development and governance of organizational networks that aim to establish collective values.
Gilsing, R., Berkers, F., Lamerichs, G., Dalmolen, S., Cornelisse, E., Van den Berg, W., Van Houwelingen, G., Trifkovic, K., Bunderla, M. (2023) Deliverable D2.6 Methodology and learnings from the prototype kit. ZeroW Project, Grant Agreement no. 101036388 – This project report describes a practical approach for developing collaborative business models for data spaces in conjunction with governance. (Available through https://bit.ly/ZerowD2_6 )
Grefen, P. W. P. J. (2015). Service-dominant business engineering with Base/X: business modeling handbook. Amazon. – This book provides clear instructions and examples for developing (Service-Dominant) collaborative business models. (a preceding working paper)
Osterwalder, A., Pigneur, Y., Bernarda, G., & Smith, A. (2015). Value proposition design: How to create products and services customers want. John Wiley & Sons. - This book provides instructions to develop value propositions for specific segments.
Parker, G. G., Van Alstyne, M. W., & Choudary, S. P. (2016). Platform revolution: How networked markets are transforming the economy and how to make them work for you. WW Norton & Company. – This book provides insights into key business strategic considerations for platform strategy and multi-sided business models.
Reillier, L. C., & Reillier, B. (2017). Platform strategy: How to unlock the power of communities and networks to grow your business. Taylor & Francis. – This book provides clear guidelines for developing multi-sided business models for platforms, considering user journey.
Stolwijk, C., Berkers, F. Scalability and agility of the Smart Connected Supplier Network approach. TNO report TNO 2020 R11179 – This report presents the logic and quantification of network effects based on interoperability among service platforms.
Stolwijk, C., Punter, M., Timan, T., Berkers, F., Georgieva, I., Gilsing, R., Bastiaansen, H., Hoekstra, M., Yagafarova, A., Mulder, W., Dalmolen, S., Joosten, R. Bridging the Dutch and European Digital Sovereignty gap. TNO report TNO 2022 R10507 – This report explains the necessity and principles for a collective approach to digital sovereignty.
Strnadl, C. F. (2023). A Formal Transaction Cost-Based Analysis of the Economic Feasibility of Data Spaces and Service Ecosystems. arXiv preprint arXiv:2310.03157. – This paper mathematically analyses under which circumstances data spaces are economically preferred and stable from the perspectives of different data space participants.
Teece, D. J., Pisano, G., & Shuen, A. (1997). Dynamic capabilities and strategic management. Strategic management journal, 18(7), 509-533.

Documents and guidelines to implement the building blocks

Business Model design tool for the Data Space Business Model - See above.
Business Model Radar - This is a tool to support the development of collaborative business models. See Grefen, P. W. P. J. (2015) for more details on this tool.
Several tools related to business modelling are also addressed in the Co-Creation Method.

6. Glossary

Term	Definition / Description
Business Model	A description of the way an organisation creates, delivers, and captures value. Such a description typically includes for whom value is created (customer) and what the value proposition is. Typically, a tool called business model canvas is used to describe or design a business model, but alternatives that are more suitable for specific situations, such as data spaces, are available.
Collaborative Business Model	A description of the way multiple organizations collectively create, deliver and capture value. Typically, this level of value creation would not be achievable by a single organization. A collaborative business model is better suited to express a value creation system consisting of multiple actors. Intangible values such as sovereignty, solidarity, and security cannot be expressed through a transactional approach (which is common in firm-centric business models) but require a system perspective.
Governance	A description of how a group of organizations (necessary for a data space) is managed, organised, and regulated by agreements and processes, as well as how the partners control and influence its evolution and performance over time. Due to the collaborative nature of a data space business model, governance of affiliated and non-affiliated actors can be seen as strongly complementary to the business model and other building blocks.
Multi-Sided Business Model	A business model is said to be multi-sided if an organization serves different segments, and those segments also interact. An example is Airbnb, where apartments are offered to travellers. This is also referred to as a ‘platform business model’. A data space differs in two important ways from a platform business model: In order to establish sovereignty and avoid undesired ‘winner-takes-all’ effects, control of the sharing of data essentially lies with the data owner and the infrastructure is distributed.
Value Proposition	A value proposition reflects the benefits for a segment of customers when adopting an offer. Benefits are typically associated with so-called pains and gains and are, therefore, fundamentally linked to key customer processes. In the case of a data space, a lack of control by data owners (sovereignty) represents one potential pain; other pains include the inaccessibility of data and non-interoperable data sources, which drive up the costs of innovative data-driven applications.

Example 1: Smart Connected Supplier Network (SCSN)

Elements of Business Model Building Block	Smart Connected Supplier Network
Principles, Scope, Objectives (1)	Principles: Sovereignty: self-determination of who will receive data Safe exchange of data Increased efficiency in supply chains Scope: Supply chain in the manufacturing industry Invoice, order, product information data Objectives: 20% higher productivity of the supply chain by fast, safe, and interoperable exchange of information Expand both horizontally and vertically in the value chain, initially on a European Scale No profit ambitions for the SCSN foundation
Use Cases, Data Providers and Data Users (2)	One use case currently: Connecting ERP and other order systems to create efficient and robust supply chains. This leads to a reduction in administrative costs and a reduction in human error while sending and processing orders. Interoperability is established through a jointly developed standard. According to its foundational documents, maintenance of this standard is the core task of the SCSN foundation. Future use cases: price updates, stock information, and others.
Value Proposition to Use Cases, Data Providers and Data Recipients (5)	Choices for the development agenda are made in conjunction with service providers. (In the context of SCSN, the term service provider refers to the role of an intermediary that connects some of its customers to the SCSN network.) These service providers have discussions with their clients (the data space participants). There is, however, no formal power for service providers to vote on the type of use case that needs to be developed. Functionality for users of the proprietary platform of the service provider is typically more extensive than functionality related to users of interoperable platforms. This allows service providers to focus on specific niches and capture value while establishing interoperability with co-competing service providers.
Revenue and Pricing (for Use Cases, Data Providers, Data Recipients) (5b)	Use case participants pay fees to service providers, not directly to the data space. The participants usually already have a service contract with the service providers for use of their private platforms.
Services and Providers (3)	On behalf of the SCSN foundation, the executive body of the governance authority arranges for a broker service and identity provisioning (which is outsourced to KPN). This service provider also provides a vocabulary hub in which the data model is specified. Service providers provide services and platforms to parts of the supply chains.
Value Proposition to Service Providers (5)	Each service provider has their own client base that could be of value to the network. It is important to note that purely having a number of clients does not mean they are automatically connected to the SCSN data space. The service providers themselves add SCSN to their existing services.
Revenue and Pricing (to Service Providers) (5b)	SCSN foundation gets a predetermined fixed contribution per service provider. The contribution depends on the number of connected users. The governance authority (SCSN Foundation) gets a fixed amount of money from the service providers for connection to the network, which is amended by a fee per end user. The end-users pay the service providers, who set their own prices for the end-users.
Network Effects (8)	End-users get more out of their subscription to SCSN once more customers and/or suppliers join the network, as they can automate a larger part of their purchase-to-pay process through SCSN. Service providers enhance the appeal of their services with a larger network to connect to, increasing savings for their clients. The expansion strategy is mainly aimed at the service providers adding end-users through their client base and connecting them to SCSN.
Governance Authority bodies and members (4)	According to the foundational documents, the highest level of governance consists of one representative from the service providers, one from the manufacturing industry, one knowledge institute and one industry association. There should be at least one director. Previously, in-kind services were provided by a knowledge institute but are now outsourced. The owner of the data space is the sector association. Therefore, they exist to ensure the progression of the sector.
Dynamic Capabilities (7)	The governance authority is in constant discussion with the service providers and gives feedback on whether it is necessary to alter or change the business model. The board looks for ways in which to break even. There is no structural process in place to evaluate and monitor the business model. No structural process for innovating the business model is in place There is a board and a supervisory board, and there are three documents which define the governance of the data space: Statutes or Articles of Association of SCSN Accession Agreement Code of Conduct
People, Resources and Activities (6)	A director and several board members. Operations are outsourced to TNO and KPN. Cost Model: A director, operations are outsourced to TNO and KPN.
Stakeholders (4)	Over time, SCSN has received support from stakeholders such as the regional development agency (BOM), the province of Noord-Brabant, the European Commission, and the cooperative Brainport Industry Campus.

Example 2: Djustconnect

Elements of Business Model Building Block	Djustconnect
Principles, Scope, Objectives (1)	Principles: Respect for ownership and decision-making power Transparency about who requests and receives data Trust is earned by only exchanging data with permission Scope: Agricultural Sector: Farmers and horticulturists, agricultural data providers, agricultural data receivers Objectives: Provide a platform to increase the efficiency of actors in the agricultural sector Expansion is only in the agricultural sector in Flanders
Use Cases, Data Providers and Data Users (2)	Currently, 36 applications for farmers. All are aimed at increasing the efficiency of primary processes. Examples include applications for: Water usage and quality Monthly milk production and price overviews Carbon footprint Agricultural machines Use cases can be added to the data space by participants
Value Proposition to Use Cases, Data Providers and Data Recipients (5)	The data space initiative does not actively support the development of new use cases. By design, the platform offers different data sources and data types. Data receivers and data providers can create new applications that support use cases within the data space.
Revenue and Pricing (for Use Cases, Data Providers, Data Recipients) (5b)	The governance authority (board of EV-ILVO and executive personnel) receives an annual fixed fee from data providers and data receivers. They hold the farmers' data at no cost to the farmer.
Services and Providers (3)	ILVO provides connectors on behalf of Djustconnect. These connectors are API management, API market, access control, authorization, a vocabulary hub, data authorization, and a clearing house. All of this is hosted in-house.
Value Proposition to Service Providers (5)	The service providers are larger cooperatives who are data holders for the farmers. Thus, they connected their databases to allow for the creation of data space. They immediately unlock the data potential of all farmers involved. However, the data will enter into the network only if the farmers indicate they want their data shared.
Revenue and Pricing (to Service Providers) (5b)	n/a
Network Effects (8)	The farmers are the main owners of the data which is shared and analysed in the data space. The more farmers are able to share their data, the more interesting it becomes for data recipients and data providers to join the network. Expansion is focused on contacting new data providers and data receivers to increase the number of applications.
Governance Authority bodies and members (4)	EV ILVO owns Djustconnect as a non-profit. It was founded by a number of associations and subsidised with EFRO funding. The organisation is managed and staffed by EV ILVO. The host and governance authority is the owner of the data space.
Dynamic Capabilities (7)	The governance authority is in constant discussion with service providers, who provide feedback on whether it is necessary to change the business model. The board makes an effort to look for ways to break even. There are no structural processes in place to evaluate and monitor the business model. Currently, there is no structural process to innovate the business model. EV ILVO hosts and maintains the Djustconnect platform. The Steering Committee of Cooperatives ensures the farmers are represented in strategic decisions (some cooperatives are also agricultural businesses such as Milcobel). The External Advisory Board represents the wider ecosystem, which contributes to the mission and vision. Governance documents: Code of Conduct: based on the European Code of Conduct for data sharing in agriculture User Agreement Privacy Statement
People, Resources and Activities (6)	A team of about 6, including developers, a marketer, and a director (not all full-time), to run and operate the data space. Cost model: A team of about 6, including developers, a marketeer, and a director (not all full-time) to run and operate the data space.
Stakeholders (4)	n/a

1. Summary

The value of a data space stems from its use cases. Data space use cases are settings where two or more participants create business, societal or environmental value from data sharing. Use case development amplifies such value of a data space.

Use case development falls into three initial steps, and continuous improvement throughout the life cycle of the use case as the overarching process model (Figure 1):

Identifying and tracking use case scenarios is your starting point, where you generate new ideas and understand better the needs of the users that would benefit from a potential use case.
Refining use case scenarios is where you spend more of your time, giving detail to the use case so that you can test its viability. This includes, at the minimum, the purpose and value of the use case, the use case participants, and the necessary data flows.
Implementing use cases is where you take the best ideas and move from the drawing board to putting the ideas into reality.
Continuous improvement process is the overarching process throughout the life cycle of a use case where you analyze its performance, identify improvement opportunities, plan and implement changes.

Use case development is particularly important for data spaces in their early phases, as use cases attract users and participants that are essential for growth. An established data space with well-functioning use cases may opt out of use case development. However, it risks becoming obsolete as its business environment evolves and competitors develop new and improved use cases.

1.1. Questions that will be answered

When does the data space need an use case orchestrator and who will do it?
How should the governance authority track the development of potential use cases?
What are some of the templates that can be refined to help guide orchestrators?

2. Purpose of the building block

Use cases create value, which can be economic, social, or environmental. More value is created with more and better use cases. Use Case Development aims to amplify this value by fostering the creation, support, and scaling of use cases.

This building block provides guidance on developing and deploying use cases for data space initiatives. It provides guidelines on how to support participants in exploring, developing, and onboarding use cases. A data space can offer support services like brokering between partners or other resources, such as templates containing use case criteria.

3. Concepts

3.1 Use case and use case scenario

A data space use case is a clearly defined situation where participants exchange and use data to achieve a measurable outcome or solve a problem. The value that is created could lead to, for example, increased revenue, reduced costs, improved public services, or lower environmental impact.

Use cases vary in complexity, from one-off transactions between two parties (such as suppliers in a chain sharing data) to complex, multi-party interactions (such as the creation of a digital product passport). Complex use cases can be built with the support of multiple, simpler use cases.

Example of simple use cases helping build a complex one

Imagine a component manufacturer that needs information from its suppliers on available materials. The component manufacturer can use this information for multiple purposes, such as quality assurance, product development, or sustainability reporting. Another simple use case could be the component manufacturer sharing sustainability data with the final product manufacturer. These two use cases, which already provide value to the participants, could be leveraged for the more complex use case of the product passport.

The term use case refers to an operational use case. When referring to a planned or envisioned setting that is not yet operational, we use the term use case scenario.

3.2 Cross data space use case

A cross data space use case is a use case where the data sharing extends to two or more data spaces. They may use data products and services from several data spaces or even from other data sharing infrastructures, such as a platforms.

For example, a use case around a better travel experience might use data from tourism and mobility data spaces to combine public transport data with tourism experiences. Another example could be to combine data from several local transport data spaces to offer travel services that cover a wider geographic area.

3.3 Use case orchestrator

A use case orchestrator is the entity that represents and is accountable for a specific use case within the governance framework. The orchestrator establishes and enforces the rules that make the use case work. They also assemble and manage a network to develop the use case. This orchestrator can be the governance authority or a participant.

An orchestrator is particularly necessary with many inter-related simple use cases or for complex use cases. Simple transactions between a data provider and recipient can be done without orchestration.

4. Elements to develop use cases and their key functions

Successful use cases are the heart of a data space, and as such, assigning someone to ‘orchestrate’ them can be essential. The governance authority has different options for organising the orchestration.

Use cases will generally be moderated by the governance authority as per the data space rulebook. The governance authority can act as a use case orchestrator or it can nominate one or more participants. These roles can be formalised or done on an ad-hoc, case-by-case basis. In either scenario, the governance authority should support participants who are conducting orchestration to ensure consistency and quality.

This question of who orchestrates is not an either-or scenario. The governance authority can take responsibility for some use cases and appoint participants to manage others.

The main question in either case is whether the idea is good enough and whether an orchestrator--whether the governance authority or the participant--is willing to invest resources to refine the scenario and start orchestrating.

4.1 Questions that a use case needs to answer

Use cases need to answer basic questions around the purpose of sharing data and what value it aims to create. Consider, for example, a use case scenario where a data space wants to help employers verify diplomas and professional certificates issued in Europe without contacting each institution manually. Developing the use case would need to answer at least the following questions, some of which are generic and applicable to any use case, and others that are more specific:

The purpose and value of having a repository for validating educational credentials
- Who uses it, whether it be employers, employees, education providers, trainers, or service providers?
- Why do these users need it?
- How does the passport fit into existing workflows or change them?
What kind of data and services are shared
Who provides the data
Who are the participants involved in this activity
- What are their roles and responsibilities
- What is the value they expect to get out of the activity
- What user journeys or lifecycle stages (production, use, repair, recycling) rely on the digital product passport?
What is the role of personal data and natural persons in the use case? (For more information, see Personal data and natural persons in data space design and operation)
What kind of value does the use case create for the data space and how does it fit its value proposition?
- What measurable KPIs or outcomes define success (e.g., reduced material waste, faster compliance reporting)?

Answering these types of questions on the use case is an iterative process that may repeatedly address issues such as data products, services, or potential customers. Design decisions may also need to change. In fact, continuous improvement is needed throughout the life cycle of a use case, even after the use case becomes operational and right until its end-of-life.

It can also be useful to seek inspiration from other data spaces. For example, there could be several manufacturing supply chains that would like to share data across the chain for production planning and control. If one supply chain is successful, it can inspire other supply chains. They can then modify the example and develop their own use case scenario.

4.1.1. The key stages in use case development

The central stages to answer these questions are as follows.

Key stages of use case development	Description
Identifying and tracking use case scenarios	Collecting ideas for use case scenarios through activities such as observing potential users’ needs and analysing other data spaces and platforms.
Refining use case scenarios	Refining the description and design of use case scenarios using templates like the Data Cooperation Canvas, Use Case Playbook, or self-created templates.
Implementing use cases	Implementing use cases both from organisational and business perspectives (e.g., agreements) and from technical perspectives (e.g., vocabularies, APIs, connectors).
Continuous improvement process	Continuously analyzing the performance of use cases, identifying improvement opportunities, and planning and implementing changes in a systematic and managed way throughout the life cycle of a use case.

4.2 Identifying and tracking use case scenarios

Ideas for new use cases can come from examining the needs of current and potential data space participants and their end uses, other data spaces, platform businesses, and other data-sharing contexts. When discussing with potential consumers, orchestrators can make clear that working with a data space is not exclusive. For example, data from public authorities may already be shared on their own platforms, but this does not exclude creating data products or offerings for a use case.

Data spaces also benefit from tracking the progress of use case scenarios, keeping a record of how they have developed. This would include recording the following:

A short description of the scenarios
The scenario’s development stage, including
- Exploring
- Scoping & Defining
- Feasibility Assessment / Stage-gate Screening
- Refining
- Developing
- Piloting
- Implemented
- Abandoned (and the reasons why, such as lack of market demand or challenges in implementation)
The revenue potential of the use case (from very high to very low)
The strategic fit of the use case (from very high to very low)
Required data products and services
- Potential providers of those products and services, including whether they are currently participants in the data space

This information can be used as inspirational examples and sources of good practice. The data space can recognise patterns for successful use cases, and avoid repeating mistakes by tracking those that have been abandoned.

In addition to tracking use cases, it also makes sense to keep track of data products and value creation services available on the market – also outside one’s own data space. Data products and value creation services offered by other data spaces could be used for cross data space use cases or the ideas could be copied for the data space and its own use cases.

An example of working outside one's data space

To generate better forecasts on crop yields could benefit from joining data from a data space focused on agriculture and one on earth observation. An organisation wanting to offer crop-yield forecasts could join both data spaces to create a cross data space use case. This can become inefficient in cases where the data resides in many data spaces, requiring different rules, contracts, standards, and participant agent services. Making (and possibly shaping) all of the relevant data products into one data space can reduce complexity, while not precluding those data products from residing in their ‘home’ data spaces.

In such situations, it makes sense to consider if the use case is best covered within a single data space or as a cross data space use case. More information on interoperability can be found in the section cross data space interoperability considerations in data space design and operation.

Gathering a library of use case scenarios, tracking their progress, and screening the best ideas for the refining stage should be carried out centrally. Someone else can do this if the governance authority does not want this task, but the governance authority should handle the nomination procedure.

4.2.1. When to commit to refining a use case

Not every scenario should be taken to the potentially laborious refinement stage. Instead, promising ideas should undergo an initial stage-gate screening to decide which ones should be further developed. This applies to use cases orchestrated by the governance authority or by participants that require a commitment of resources.

Before committing resources, a data space would be interested in how well the use case fits the data space’s value proposition and business plan. This would include questions about the scope and objectives of the data space and its market potential. Some use cases may be critical to reach the wider objectives of a data space. Ranking use cases in terms of strategic fit and revenue potential can help determine where to focus effort.

It is also good to give some initial thought to the data and service providers needed for a use case before progressing to the refinement phase. What data and services are needed, and which parties could provide them? Which other participants would be needed? Does the data space already have such parties, or does it need to attract new parties to join?

4.3 Refining (complex) use case scenarios

Once the government authority has initially screened and found a use case to be promising, the orchestrator can refine the use case scenario. The more complex the scenario, the greater the importance of the orchestrator that needs to to facilitate and coordinate the design process.

While having a considerable role in the refinement phase, the orchestrator does not work alone. It orchestrates together with potential participants. In cases where the governance authority is not the orchestrator, they can provide structured approaches and templates to further explore and refine the use case scenario. These might include customised version of the following template:

The existing approaches differ, but they do share characteristics, which form the core structure of the scenario. They reflect on the following elements, which allows the scenario to be improved and refined.

The participants and their role or activity
The flow of data (products) and services
The value for participants, and
The joint purpose or value of the use case.

4.3.1. Design elements when refining use case scenarios

Modularity

Efficiency and network effects can be improved if the data products and services are modular so that they can serve multiple use cases. See the data space offering building block for more discussion on this point.

Cost basis

The implementation and operational costs of individual use cases might be fully or partially covered by the data space. If use cases build on common infrastructure covered by the governance authority, sharing data products and offerings across use cases would lower overhead and make scaling easier.

The challenge of cost sharing and how the governance authority can help

Often, the idea and motivation for a use case come from those who want to use the data. On the other hand, data providers and rights holders face costs and risks, such as investments in data quality and tools. Furthermore, organisations often fear losing strategic control over data and its value. The viability of use cases depends on the willingness of data rights holders to share data. Some use cases and participants may be financially supported due to the high value they bring to the data space or use case through other means (e.g., essential data products or services). Agreeing on compensation and fees while balancing the monetary and non-monetary costs and benefits in a manner that benefits all parties is crucial.

Regulation

Regulation typically needs to be considered at an early stage when refining use case scenarios. As explained in the Regulatory Compliance Building Block, certain characteristics of a use case may trigger legal requirements. These could be, for example, the type of data, the nature of the participants, or the domain. Depending on the use case, different horizontal, sectoral, and national regulations may apply.

Existing infrastructure and participants

A use case may require specific data models or services provided. Further boundaries are set by the willingness of the use case participants to participate in the role suggested for them and in the general setting of the use case.

Contracts

Use cases function under the general institutional agreements and governance framework of a data space. In many cases these contract types can be sufficient for the purposes of developing use cases. However, a lawyer should examine in the refinement stage whether other agreements or contracts are necessary for the use case.

Security

Some important security related regulations that use cases must comply with are, among others, NIS2 (Network and Information Security Directive 2), CRA (Cyber Resilience Act), and the DSA (Digital Services Act). Different use case may impose different security needs. Security should always be a priority but may be particularly important in critical industries covered by the NIS2 Directive or sectors covered by other legislation. Also, a higher security level may be required if the use case involves processing sensitive data. Threat modelling can be used tosystematically identify and evaluate potential threats to an application, system, or organisation. For those use cases where the information contained is considered critical, periodic security audits may be advisable, along with the necessary backups to prevent data loss.

More support for security can be found in the Data Sharing Canvas and the Rulebook for Fair Data Economy.

4.4 Implementing use cases

Before a use case can become operational, all the preconditions need to be met, namely:

The data space infrastructure needs to be operational,
The use case participants need to have joined and connected to the data space.
The necessary contracts for the use case need to have been made
The necessary data products and value creation services need to have been developed and made available.

Once these conditions are met, the use case orchestrator can continue discussion with the potential participants, ensuring their ongoing commitment. Based on the needs identified during refinement, the data space may also need to further develop the data space infrastructure, create the necessary data space offerings, add new participants, make new agreements, and set up connectors.

The use case orchestrator acts as the process owner, arranging and agreeing on the implementation details with relevant participants. If the governance authority does not act as the orchestrator, it still needs to support this activity, especially regarding the readiness of the data space infrastructure and ensuring that the rulebook is followed.

The implementation of complex use cases typically takes place in a stepwise manner. The use case orchestrator may want to start by implementing a minimum viable use case that includes only essential functionality and allows at least part of participants to use it. This functionality is created by implementing specific central data products and services. Further development can be done through prototypes that are used to test the technical feasibility of certain aspects of the design and whether the use case fulfills the needs of the user and any other expectations set for it.

An example of deployEMDS using a stepwise implementation process

The EU co-funded project deployEMDS (Deployment of Mobility Data Space in Europe) has carried out a stepwise implementation process in the Barcelona-based use case “Multi-operator data governance ecosystem for bus fleets and demand-responsive transport”. Deliverable D4.2 presents how they set their objectives based on an analysis of the use case’s context and its challenges and opportunities for value creation. They explored the possible implementation pathways in more detail by inspecting the most ideal implementation in an idealised, fictional scenario. The ideal use case was broken into sub-cases, and the focus was first set on low-hanging fruit. Then, they identified barriers to the ideal implementation stemming from the real world and planned alternate pathways to address them.

4.4 Continuous improvement process

The development work does not stop when a use case has been implemented according to its original design. Continuous improvement is needed due to changes in technology, available data, and market conditions – or to simply make the use case function better. Changes in one aspect of a use case--such as a data product, a value creation service, a participant, or an agreement--may have implications on the other aspects and participants.

Once the use case is at least partly operational and has its first real users, this can also lead to changes, helping to further identify useful data products, services, and participants. During this process, the use case may also change completely, something which should be noted in the use case tracking document (as described earlier). All use cases have a life cycle, and as their usefulness lessens, the data products and services can still serve other use cases.

Change management is also needed in all the phases of the life cycle. The more important the use case is for the data space, the more important it is to have effective change management and continuous improvement processes in place. It is the use case orchestrator that has overall responsibility for these tasks, but they should work in collaboration with all the essential participants. Managing the change and the continuous improvement process starts with a clear shared vision of the use case. The essential participants need to have a say in the changes. They need to see the changes as valuable and to feel themselves safe while changes are made. When there are multiple changes to be made, they need to be prioritized and a roadmap made. The success of the use case and the changes made needs to be measured and further actions planned based on the analysis.

5. Co-creation questions

What high-level use cases should the data space support?
Which use cases should the data space focus on first, and which are to be developed in the future?
What is the purpose or problem to be solved by the use case (business, societal, and/or environmental value)?
Which participants or actors are directly involved in which use cases, and what roles do they play?
What benefits do use cases offer to their participants?
How does a use case utilize data within the data space and/or across data spaces, and what types of data are essential for its operation?

6. Further reading

Documents and guidelines to implement building blocks
Further reading on some tools that can be used for refining use case scenarios:

Business Model Radar: Starter Kit for Data Space Designers | Version 1.0 | March 2023 - Starter Kit - Data Spaces Support Centre (dssc.eu)
Data Space Canvas: Rulebook for a fair data economy - Sitra
Data Cooperation Canvas: The Data Cooperation Canvas
Data Sharing Canvas: Tools - Centre of Excellence for Data Sharing & Cloud (coe-dsc.nl)
Use Case Playbook: Tools - Centre of Excellence for Data Sharing & Cloud (coe-dsc.nl)
Use Case Blueprint: Tools - Centre of Excellence for Data Sharing & Cloud (coe-dsc.nl)

Other reading

Deliverable D4.2 Barcelona - Detailed Implementation Plan (Part A) of the EU co-funded project deployEMDS (Deployment of Mobility Data Space in Europe)
Multi-sided platforms: Parker, G. G., Van Alstyne, M. W., & Choudary, S. P. (2016). Platform revolution: How networked markets are transforming the economy and how to make them work for you. WW Norton & Company.

7. Glossary

Term	Definition
Data space use case	A specific setting in which two or more participants use a data space to create value (business, societal or environmental) from data sharing. Explanatory text: By definition, a data space use case is operational. When referring to a planned or envisioned setting that is not yet operational we can use the term use case scenario. Use case scenario is a potential use case envisaged to solve societal, environmental or business challenges and create value. The same use case scenario, or variations of it, can be implemented as a use case multiple times in one or more data spaces.
Cross data space use case	A specific setting in which participants of multiple data spaces create value (business, societal or environmental) from sharing data across these data spaces.
Use case orchestrator	A data space participant that represents and is accountable for a specific use case in the context of the governance framework. The orchestrator establishes and enforces business rules and other conditions to be followed by the use case participants. [role]
Use case participant	A data space participant that is engaged with a specific use case. [role]
Use case development	A strategic approach to amplify the value of a data space by fostering the creation, support and scaling of use cases.
Data space value	The cumulative value generated from all the data transactions and use cases within a data space as data space participants collaboratively use it. Explanatory text: The definition of “data space value” is agnostic to value sharing and value capture. It just states where the value is created (in the use cases). The use case orchestrator should establish a value-sharing mechanism within the use case to make all participants happy. Furthermore, to avoid the free rider problem, the data space governance authority may also want to establish a value capture mechanism (for example, a data space usage fee) to get its part from the value created in the use cases.

1. Summary

A data space offering bundles data products and services in a way that a potential consumer can interact with. This building block provides data space initiatives with an understanding of these offerings from a business perspective, proposing a strategy to develop and maintain them. The elements of a data space offering strategy are the following:

Identify and onboard data products and services that serve existing and future use cases;
Develop, maintain, and enforce the rules that govern data space offerings; and
Support the participants to develop and offer high-quality data products and services.

1.1. Questions that will be answered

Why is it important to think about selling data products rather than just data?
Who is responsible for packaging and improving data products and services into a compelling offering?
Why do the participants responsible for shaping data space offerings need to think about the needs of overlapping use cases?

2. Purpose of the building block

The Data Space Offering building block provides the reader with an understanding of offerings from a business perspective. It proposes a strategy for offerings identification, management and governance. In particular, this building block recommends the governance authorities:

consider what data products and services their data space offers to the participants;
establish governance rules for the offered data products and services;
prioritise onboarding of relevant data products and services to foster network effects; and
guide participants in creating and providing data products and services via use cases.

3. Concepts

In this section, we will describe the key concepts of the building block, namely what are data products, the associated data services, and how they fit into a data space offering for consumers.

3.1. Data products

A data product is more than just data. Turning data into a product means transforming and packaging it into something that is consumable and marketable. These products should meet consumer needs and have a clear purpose, potentially fitting into a specific use case, though could be offered on a self-serve basis.

CEN CENELEC definition of a data product

The definition of a data product is still evolving. Currently, the CEN CENELEC Trusted Data Transactions Workshop Agreement defines data products as “data sharing units, packaging data and metadata, and any associated license terms”. This definition considers data products as the object of data transactions.

Thinking about data products rather than just about data helps make them easier to use because it bundles data policies, business and contractual information. It makes it easier to identify common rules of various data sets, making lifecycle management, quality assurance, policy enforcement, and regulatory compliance more straightforward and transparent.

While the content of data products may vary, it typically includes:

the data;
the metadata describing access and usage terms as well as the following aspects in a structured, machine-readable format, including:
- plain-language description of what the data is, what it represents, and why it exists;
- quality, format, frequency, duration and other requirements the data product fulfills;
- access and control rights (e.g., allowed purposes of use, attribution, Intellectual Property Rights; liabilities, geographical limitations, usability for training AI models);
- delivery options (e.g., APIs, SMTP, web interface);
- information about data provenance and lineage;
- pricing and billing information; and
- other information (e.g., ethical considerations)

One example is data products offered by Copernicus, the Earth observation component of the European Union’s Space programme, via their catalogue. The data products are described in both a human-readable form and via metadata. They are also available for direct download.

Thinking of data as a product will, for many organisations, require a different mindset: the idea of managing data with reuse in mind.

3.2. Data space offering

While data products can be shared and sold on their own, they can also be bundled with data services. This might include data visualization, anonymization, data quality assessment and assurance, data processing, or connection-enabling services to external infrastructures or applications. The service can be something as simple as an API. This bundling of data with data services is a data space offering.

These offerings are published by the data space participants or the governance authority in a catalogue to make them discoverable.

4. Elements of a data space offering and their key functions

This building block outlines a strategy for identifying, managing, and governing data space offerings. The key elements of this strategy are:

Identify and priority onboard data products and services that serve existing and future use cases
Develop, maintain, and enforce the governance rules of the data space offering
Support the participants to develop and offer high-quality data products or data space offerings, depending on the business model.

4.1. Identify and priority onboard data products and services that serve existing and future use cases

Use cases, propositions, scenarios—they all capture the idea that a data space offering serves a specific consumer need. And a data space will generally support a number of use cases, which will be composed of one or more data space offerings.

Different use cases often require the same resources. Data spaces can accelerate the development of use cases by proactively identifying and attracting data products or services that overlap with multiple use cases. New data products and services can enhance existing data space offerings or constitute new ones. These new data space offerings can then lead to new use cases, which furthers enhances the network effects of the data space.

Figure 1 provides an example of three use cases that share common data space products and offerings. For example, thinking of the European Mobility Data Space: three potential use cases could all be supported by one data product, namely public transport data. This data product could enable travelers to plan a trip on any vehicle. The data could also be used to plan efficient evacuation routes in case of natural disasters or in crafting policies aimed at improving public transport systems.

Use cases can not only share data products, but also data services and offerings. This ability to mix and match data products and services provides strength and flexibility in being able to support various market segments, improving existing offerings while creating new ones.

Who takes the lead in identifying and attracting these resources? The governance authority or a participant who is driving a specific use case (an ‘orchestrator’) can look to invest in this process. Who takes this responsibility depends on the data space’s business model. If the business model allows, investing resources to onboard resources that are in high demand have the potential to drive growth.

If a data service is offered by the governance authority, a key business consideration is the cost of these data services, and whether to develop these in house or procure them from service providers. These considerations are part of developing a data space offering strategy.

4.2. Develop, maintain, and enforce the rules around a data space offering

While some data products and services are provided by the data space participants themselves, the governance authority sets the boundaries that will govern which data products and services can be offered. These rules--including standards and guidelines--ensure the coherence of the data space’s value proposition, making it easier to attract new data products and services. These rules also lay out basic conditions around quality, trustworthiness, security, privacy, interoperability, and ethics. Setting, maintaining and enforcing these rules also increases data space participants' trust in the data space.

The governance authority should develop rules around the following for data products and offerings:

What types of data space offerings (requiring what kind of data products and services) can be offered through the data space, such as domain-specific data products, supporting also streaming data or AI models.
Requirements to access data products (irrespective of the data space offerings). Article 33 of the Data Act requires that “dataset content, use restrictions, licenses, data collection methodology, data quality and uncertainty shall be sufficiently described, where applicable, in a machine-readable format, to allow the recipient to find, access and use the data”. But details on how those principles should be addressed needs to be clarified by setting quality requirements, which can include the following elements:
- Quality, utility, or ethical labels;
- Availability conditions;
- The format and content requirements for human-readable descriptions;
- Provenance data requirements; and
- Delivery options.

For the rules related to the metadata, and the supported standards, it is worth to reading the Data, Service, Offerings Descriptions building block.

License terms specifying the access and usage rules of the data product or service, such as attribution, Intellectual Property Rights, liabilities, and geographical limitations.
Commercial aspects, such as pricing and billing information.
Delivery options, such as APIs, SMTP, web interface, and mapping tools.
Supporting and maintenance services

4.3. Supporting participants to bring high-quality data space offerings

The governance authority may provide tools and processes to lower the barrier for participants to start providing data space offerings.

For data products, the governance authority can use long-established product management practices to plan, develop and govern the data product over its life cycle. This is important to ensure that the data product remains relevant and updated throughout its lifecycle, especially as the needs of use cases (and consumers) change.

The governance authority can also provide documentation to data product owners on the use cases, so that data products can be altered to better fit one or multiple use cases. Data product owners may also wish to provide multiple products built on the same data, for example providing different license terms, delivery options, or commercial / technical requirements. This applies equally to providers of a data space offering, for which data products are a key component.

This documentation on the use cases is equally relevant to service providers, as it can allow them to better tailor the data services according to the needs of multiple use cases.

The following key tasks are required for developing and providing data space offerings, which can be carried out iteratively:

Identify the purpose of the data product or service in the context of use cases. Data space offerings (and their components) should satisfy consumers' needs with reuse in mind. Data space offerings should start on the consumers' side to clarify the expected value. A key consideration is the type of value the data space offerings deliver, which can lead either directly or indirectly to revenue.
Developing data products and services. Developing data products and services might require developing several candidates and then choosing the one that gets the best score after evaluation (see the next step). The data space product or service candidate development consists of the following steps:
- When the owner defines the purpose of a data product or service, they need to identify the data sources that provide the data ingredients .
- All licensing terms, commercial aspects, delivery options, consumption pattern, information about data provenance and lineage, requirements and various policies needs to be decided.
- The necessary metadata needs to be created using the suitable standard.
- Finally, all these required information needs to be bundled into a consumable form, using a suitable standard.
Quality assurance, evaluation and validation. The data product or service needs proper testing, as well as validation that it fulfills its requirements and intended purposes.
Publishing data space offerings via catalogue services. As a last step, a data space offering should be made available for consumers. Please refer to the Publication and Discovery building block for the technical details.
Maintenance and supporting services. The provider is responsible for maintaining and supporting services throughout the whole lifecycle.

5. Co-creation questions

When developing a data space offering strategy, the Governance Authority should consider the following questions:

What types of data products and services are being offered in the data space?
What value-creation service(s) should the governance authority provide to their participants?
What rules should govern the metadata, licensing conditions, quality and other requirements of the offerings?
How and when should the governance framework enforce common standards and/ or policies for data products?
What is the data space' strategy for incentivizing and helping the participants to invest in developing and offering high-quality data products and services?
What is the data space' strategy for supporting synergies between use cases or different data spaces through common data products?

6. Further reading

Due to the novelty of the topic, we cannot recommend literature that exactly matches the data product concept as described here in this building block. However, the data product concept originally comes from data mesh architectures and therefore, the literature on the data mesh architectures can be consulted for further information. In this context, we suggest the following articles:

Hasan, M. R., & Legner, C. (2023, May). Data Product Canvas: A visual inquiry tool supporting data product design. In International Conference on Design Science Research in Information Systems and Technology (pp. 191-205). Cham: Springer Nature Switzerland.
Hasan, M. R., & Legner, C. (2023). Understanding data products: Motivations, definition, and categories. https://aisel.aisnet.org/ecis2023_rp/229/
Machado, I. A., Costa, C., & Santos, M. Y. (2022). Data Mesh: Concepts and Principles of a Paradigm Shift in Data Architectures. Procedia Computer Science, 196, 263–271. https://doi.org/10.1016/j.procs.2021.12.013

7. Glossary

Term	Definition
Data space offering	A bundling of data products and services together with the offering description. Explanatory text: Offerings can be put to a catalogue. Multiple offerings can be offered with the same or variant combinations of data products and services.
Offering description	A text that specifies the terms, conditions and other specifications, according to which an offering will be provided and can be consumed. Explanatory text: Offering descriptions contain all the information needed for a potential consumer to make a decision whether to consume the data product(s) and/or the service(s) or not. This may include information such as description, provider, pricing, license, data format, access rights, etc. The offering description can also detail the structure of the offering, how data products and services can be obtained, and applicable rights and duties. Typically offering descriptions are machine-readable metadata.
Data product	Data sharing units, packaging data and metadata, and any associated license terms. Explanatory text: We borrow this definition from the CEN Workshop Agreement Trusted Data Transactions. The data product may include, for example, the data products' allowed purposes of use, quality and other requirements the data product fulfils, access and control rights, pricing and billing information, etc.
Data product owner	A party that develops, manages and maintains a data product. Explanatory text: The data product owner can be the same party as the data rights holder, or it can receive the right to process the data from the data rights holder (the right can be obtained through a permission, consent or license and may be ruled by a legal obligation or a contract). A data product owner is not necessarily a data space participant.
Data product provider	A party that acts on behalf of a data product owner in providing, managing and maintaining a data product in a data space. Explanatory text: The data product provider can be referred to as the data provider. In general use that is fine, but in specific cases the data product provider might be a different party than the data rights holder and different than the data product owner. A data product provider is a data space participant. For reference, the definition from the CEN Workshop Agreement Trusted Data Transactions: a party that has the right or duty to make data available to data users through data products. Note: a data provider carries out several activities, ie.: - non-technical, on behalf of a data rights holder, including the description of the data products, data licence terms, the publishing of data products in a data product catalogue, the negotiation with the data users, and the conclusion of contracts, - technical, with the provision of the data products to the data users.
Data product consumer	A party that commits to a data product contract concerning one or more data products. Explanatory text: A data product consumer is a data space participant. The data product consumer can be referred to as the data user. In principle, the data product consumer could be a different party than the eventual data user, but in many cases these parties are the same and the terms are used exchangeably.
Data product contract	A legal contract that specifies a set of rights and duties for the respective parties that will perform the roles of the data product provider and data product consumer.

1. Summary

A core design choice that data spaces need to make is on the configuration of service providers that allow a data space to function. While the data space governance authority (DSGA) and data space participants can provide these services themselves, there are many business (and governance) reasons why procuring services provides benefits.

Within the ecosystem, intermediaries and operators can provide these enabling services. Data space can have one operator or multiple enabling service providers (intermediaries). Whether to design a data space with a single operator or multiple intermediaries is a data space business design question where the risks and benefits of a single provider versus multiple providers must be weighed.

The effectiveness of intermediaries and operators is ultimately a balance between four dimensions: (1) to streamline and make trusted data sharing easier and more economical; (2) to improve data space accessibility and usability; (3) to contribute to the data space’s scalability, and to (4) enable interoperability both within and between data spaces.

Risks associated with procurement of services are often related to the vendor lock-in, additional costs associated with vendor management, and potential loss of sovereignty depending on the kind of provider selected.

1.1. Questions that will be answered

What are the consequences of using a single operator model versus multiple data space intermediaries?
How can a governance authority best break down to analyse whether an intermediary or operator model works best?
What are some key regulatory questions that might influence the choice around an operator or intermediary model?

2. Purpose of the building block

This building block examines the core characteristics of service providers that provide enabling services that allow a data space to function. The building block helps governance authorities and designers of individual data spaces understand whether they should rely on a single operator or a series of data space intermediaries. It is important to consider this building block in conjunction with the Business Model building block.

3. Elements to consider when selecting intermediaries or an operator, and their key functions

3.1. Running a data space with a single operator or multiple intermediaries

An operator model for a data space implies that a single service provider provides the vast majority of enabling services, while a data space serviced by different specialised providers uses an intermediary model.

The most common roles of intermediaries and operators are to provide neutral and trusted federation and participant agent services, but intermediaries and operators may also facilitate growth by easing accessibility to the data space, enable cross-data space interoperability, and offer business and organisational services to the data space.

There might also be cases in which an enabling service provider also provides value creation services or acts as a data source or data provider providers within the data space. Data space governance framework (which may be documented in a rulebook) or legal frameworks may limit how enabling services may be bundled with value creation services, and there might be reasons why such bundles are not favourable for the neutral and scalable operations of intermediaries.

3.1.1. Role of the business and revenue model

Business model characteristics describe how service providers contribute to the overall economics of the data space, enable business model or enable business viability of the data space. For example, agency intermediaries are directly incentivised to acquire new customers, and while doing this, they are primarily inviting new participants to the data space. In the case of multiple agency intermediaries, they have an incentive to differentiate and develop more value for their customers.

There are multiple options for revenue models that can also coexist with each other:

Fixed participation fees (from participant to intermediary, or from intermediary to data space);
Dynamic fees based on service usage;
Revenue sharing arrangements between the intermediary and the data space;
Transaction-dependent fees (data transaction, trust transaction, financial transaction, etc.)

3.1.2. Role of interoperability requirements

Intermediary interoperability and collaboration within a data space is an important design aspect when creating and governing resilient and scalable data spaces. The collaboration between intermediaries and operators can be divided into:

Collaboration between intermediaries providing different enabling services
Collaboration between intermediaries providing the same enabling services
Collaboration between operators to facilitate interoperability between data spaces

Collaboration between intermediaries that provide different enabling services (for example, one providing registry services and another an observability service) requires technical integration planning and governance for this integration. This is a common setup for data spaces and in essence has similar enterprise architectural characteristics as any multi-vendor enterprise architecture. However, following the technical guidelines of blueprint will facilitate integration of multiple service providers to function together.

Collaboration between intermediaries that provide the same services may occur, for example, in the context of having multiple connected registry or catalogue services (e.g., country-specific registries) or multiple credential-issuing services. This collaboration requires that the different intermediaries must be compatible with each other by conforming to the use of the standards and frameworks adopted by the data space in its governance framework. These should include standards and frameworks described in the technical part of this blueprint.

There may of course also be competition between intermediaries that provide the same services. For example, a data space may recognise multiple approved providers of participant agent services and give participants the freedom to choose between these competing service providers. These providers can compete with different aspects of the service offering, but must always be fungible, or interchangeable.

3.1.3. Role of operator efficiencies (and operator capture)

A common concern with a single operator model is that the operator may take a too central role within the data space. Switching costs from one operator to another can be costly, allowing operators to extract excess revenues from the data space. At the same time, a single operator reduces the complexity to manage and operate the data space.

Data space designers can reduce the risk of being ‘captured’ by an operator by establishing good governance, applying and enforcing standards and use of open source technologies, and designing data spaces that take into account changing operators and or moving to an intermediary model to distribute vendor dependency risks.

3.2. Breaking down operator and intermediary roles for easier (business) analysis

The following pragmatic approach provides illustrative examples of service providers' characteristics that can be considered by a DSGA as they design the business model, governance framework, regulatory compliance support, and interoperability aspects of their data space.

3.2.1. Data space service model characteristics

Intermediaries and operators can offer technical federation services, participant agent services, and in some cases, value creation services that enhance the data space's functionality and accessibility, as well as non-technical services. They can provide these services directly to data space participants or the services can be procured by the governance authority for participants.

The governance framework and the data space registry should include information regarding all service providers in the data space describing the following characteristics:

Type of service(s) provided (e.g. federation services, policy information point (PIP) services, participant agent service, value adding service, etc.);
Procurement model, i.e., whether the governance authority or individual participants pay the service provider for the use of the service;
Users: i.e., whether the contractor is also the service user or whether the service is contracted by the governance authority for the use of participants.

DSGA needs to make decision do they want to enforce services providers to commit to the data space rulebook, and write contractual agreements on participating in the data space.

Enforcing participation allows DSGA to govern service provision and enable collaborative business models for the DSGA and service providers. Then again allowing independent service providers to operate in data space may be attractive for some service providers who do not want to be governed, and such service providers may be able to provide software service with competitive terms otherwise. DSGA should evaluate the benefits and downsides of enforcing enabling service providers to commit to the rulebook because this may have impact on the economics, resilience and growth of the data space.

3.2.2. Governance characteristics

The governance framework of a data space is an essential way to manage how intermediaries provide value and how risks are managed. Intermediaries and operators are participants of a data space and as such subject to the governance framework (rulebook) of that data space. This framework may define different kinds of rights and responsibilities for the providers of different services, such as how these services may be bundled and delivered, so that they remain compliant with data space principles of neutrality and scalability.

Governance-related characteristics may include:

Operator / intermediary status, also possibly some intermediary sub-type status such as personal data intermediary;
Exclusivity status, i.e., whether the service provider has exclusive rights to provide a service in the data space or whether there is a competitive market for the service;
Mandatory / optional status, i.e., whether it’s mandatory for participants to use this service provider for a specific service or whether they have multiple approved providers to choose from.
Bundling allowance: e.g., whether the service provider must provide exclusively some specific service in order to maintain its neutrality, or whether it may also bundle other services in its offering in the data space;
Auditing requirement or possibility: e.g. DSGA may have right to audit service providers technical capabilities or business accounts
Business conditions: e.g., whether the provider is subject to fee or revenue-sharing obligations;
Motivation for inclusion: i.e., why is this service included in the data space: does it, e.g., provide critical enabling services, increase data space accessibility to new participants by offering targeted onboarding services, contribute to efficiency gains by offering a commonly needed and commonly outsourced service, does it support intra- and cross-data space interoperability, etc

3.2.3. Service provider and DSGA responsibilities

Service providers and DSGA have different kinds of responsibilities to ensure collaboration and functional governance of service provisioning. Fulfilling these responsibilities are also relevant (and potentially more complex) in the context of federation and interoperability between data spaces. These topics are also related to the services management framework, which is covered in the Value creation services.

	Data space governance authority responsibility	Service provider responsibility
Service level agreements and performance metrics	Provide clear mappings between their own service level requirements and common industry standards, and establish mechanisms for recognising compliance certifications from other data spaces to reduce redundant assessments.	Implement monitoring and reporting systems that can track and demonstrate compliance with the most stringent requirements across all relevant frameworks, while maintaining transparency about any variation in service levels between data spaces.
Security requirements	Maintain detailed crosswalks between their security requirements and major security frameworks, and participate in cross-data space working groups to harmonise security standards where possible.	Implement controls that satisfy the highest common denominator of all applicable requirements, while maintaining clear documentation of how their security measures map to each data space's specific requirements.
Data privacy and confidentiality	Document how requirements fulfill standards and legal frameworks, and if there are some specific areas where their privacy requirements exceeds common standards. Provide adequate clarification on how all privacy requirements can be fulfilled in practice.	Implement adaptive data handling processes that can automatically apply the appropriate standards based on the origin and destination data spaces of each transaction, while ensuring compliance with all applicable frameworks.
Incident response and business continuity plans	Establish clear protocols for cross-data space incident coordination, maintain contact networks with other authorities, and provide templates for incident response plans that account for multi-framework obligations.	Develop integrated incident response procedures that account for multi-framework obligations, including coordinated notification processes and recovery procedures that consider the interdependencies between data spaces.
Audit and monitoring requirements	Define transparency and audit requirements, coordinate audit schedules with other data spaces, accept audit results from recognised third parties to avoid duplicate audits, and provide standardised reporting templates that facilitate efficient compliance demonstration.	Implement comprehensive monitoring systems that can generate framework-specific reports while maintaining an integrated view of their operations across all data spaces, potentially including cross-framework audit capabilities.
Exit strategies and data portability provisions	Define fungibility requirements, establish clear guidelines for managing exits that impact multiple data spaces, provide standard procedures for data portability, and maintain communication channels with other authorities to coordinate transitions.	Develop coordinated transition plans that ensure continuity of service across all affected data spaces, with clear processes for data portability that respect the varying requirements of each framework.

3.3. A word on regulatory compliance

Intermediaries (and operators) are subject to broader legal frameworks, which potentially adds financial burdens on the data space to achieve compliance, which can become complex when dealing with a web of intermediaries. Key regulatory characteristics of service providers might include the applicability of requirements imposed by:

Competition law (e.g., DMA);
Intellectual property law;
Data protection (e.g., GDPR);
Digital services regulations (e.g., DSA, DGA, eIDAS)
Sector-specific regulatory compliance (e.g., EHDS)
Specific national and regional regulatory frameworks.

The Data Governance Act (DGA) requires Data Intermediation Service Providers (DISPs) to act as neutral intermediaries, ensuring secure, transparent, and privacy-compliant data sharing. DISPs must facilitate data sovereignty, maintain accountability, and comply with data protection laws like GDPR. They ensure fair access and control over data usage. DGA is designed as an enabling law that creates a market for trusted service providers that can ensure sovereignty of data exchange.

Not all intermediaries fall under the applicability of the DGA. Some services may not be considered as DISP when, for instance, they do not aim to establish commercial relationships for data sharing, or where they facilitate transactions between determined number of data subjects, data holders, and users. That means that DISPs are a narrower category of intermediaries - any DISP who intends to provide the data intermediation services referred to in Article 10 DGA, shall submit a notification to the competent authority for data intermediation services, and shall be subject to conditions laid down in art. 12 DGA.

For more information on triggers for the applicability of different regulatory mechanisms, see Regulatory Compliance.

3.4. Examples and practice

We have created examples of data space intermediaries to concretise their characteristics and role in the data space design. These examples will illustrate why an operator or intermediaries might be engaged in the data space and how the different characteristics of the enabling service providers described in the earlier section can come in different combinations. While the case examples are fictional there are companies that act in existing data spaces and data sharing ecosystems in aligned roles. Whether these companies are available for providing their services for specific data space depends on each case. These examples can also motivate businesses or entrepreneurs to start intermediary or operator business activities.

4. Co-creation questions

Which functionalities of the data space could or should be provided by dedicated intermediary service providers?
Which parties will offer what services?

5. Further reading

Bobev, Tervel et al. 2023. “White Paper on the Definition of Data Intermediation Services.” doi:10.2139/ssrn.4589987.
“Data Intermediaries and the DGA: Understanding and Complying with the DISP Label.” European Big Data Value Forum. https://european-big-data-value-forum.eu/session/data-intermediaries-and-the-dga-understanding-and-complying-with-the-disp-label/.
“European Data Governance Act | Shaping Europe’s Digital Future.” 2024. https://digital-strategy.ec.europa.eu/en/policies/data-governance-act.
Gras, Nora. 2023. “IDSA Position Paper Explores Data Governance Act and Data Intermediaries.” International Data Spaces. https://internationaldataspaces.org/idsa-position-paper-explores-data-governance-act-and-data-intermediaries/.
Langford, J., Poikola, A., Janssen, W., Lähteenoja, V., & Rikken, M. (2020). Understanding MyData Operators. MyData Global.
Micheli, Marina et al. 2023. “Mapping the Landscape of Data Intermediaries.” JRC Publications Repository. doi:10.2760/261724.
“Peppol Interoperability Framework.” OpenPeppol. https://peppol.org/learn-more/peppol-interoperability-framework/.

6. Glossary

Term	Definition
Operator	Service provider that provides enabling services that are common to all participants of the data space. In common usage interchangeable with ‘intermediary’. Explanatory text: We use typically the term ‘operator’ when a single actor is assigned by the governance authority to manage the enabling services and when it is responsible for the operation of the data space, ensuring functionality and reliability as specified in the governance framework.
Intermediary	Service provider who provides an enabling service or services in a data space. In common usage interchangeable with ‘operator'.
Enabling services	refer mutually to federated services and participant agent services, hence services that are needed to enable trusted data transaction in data spaces.

Introduction

On this page we give concrete but fictional examples of different types of intermediaries and operators and their roles in their respective data spaces. These examples will illustrate why an operator or intermediaries might be engaged in the data space and how the different tags described in the earlier section can come in different combinations.

Example 1: Operator company “DataSpace Operator Ltd”

DataSpace Operator Ltd is specialised in being the sole operator for data spaces, and it provides enabling services for multiple data spaces irrespective of sector or domain. It is a new company focused on data spaces business without other industrial branches or operations.

The governance authority of the flowers data space has procured provisioning of federated services and participant management services from DataSpace Operator. As part of the procurement agreement, DataSpace Operator has committed to the flowers data space rulebook and is considered a participant of the flowers data space.

DataSpace Operator provides policy information point, data space registry, data catalog, vocabulary, and observability services. They use the data from their observability services also to determine participation fees for the data space. The rulebook of the flowers data space defines the parameters for how federated services must be provided. DataSpace Operator subcontracts certain components of the federation services it offers, including the trust registry, from vendors who are not participants of the flowers data space, and a special allowance for this is included in the flowers data space rulebook.

DataSpace operator has a fixed management fee for its core services on top of which it charges the data space governance authority dynamic fees based on the number of participants and the number of data transactions. These fees are considered success fees and they incentivise DataSpace Operator to promote the data spaces it provides services for, like the flowers data space.

DataSpace Operator’s services currently support only use cases that do not process personal data, and so it cannot provide its services to data spaces with use cases involving personal data.

DataSpace Operator has been granted the status of DGA-compliant data intermediation service provider (DISP) and they have built their solutions to provide federated services on top of Simpl middleware.

Characteristics of DataSpace Operator:

Federation service provider, participation management services provider
Specialised data space operator,
Contracted by the governance authority,
DGA-compliant DISP,
Mixed revenue (flat fee + usage-based fees).

Design considerations:

Does DataSpace Operator also provide participant agent services? If so, should the flowers data space procure also those services from DataSpace Operator for its participants? Or should participants be required to procure their own services if they are required? In which case, should DataSpace Operator be somehow recommended for participants?
DataSpace Operator is DGA-compliant DISP, but does the contracting party, i.e., the flowers data space governance authority, also notify themselves as a DISP?
How does the flowers data space remain sufficiently independent of DataSpace Operator and avoid vendor lock-in? What are the provisions it should make in its rulebook to ensure interchangeability with another operator company?
How can DataSpace Operator enable interoperability between other data spaces, also ones where it is not providing its services?
Does the flowers data space governance authority also want to outsource its executive and management functions, such as the management of the governance framework and rulebook, to DataSpace Operator? Or is it preferable that DataSpace Operator is a participant like all others and participates in the governance of the flowers data space like all other participants, and that another party takes on the executive functions of the governance authority?

Example 2: Agency intermediary “ParticipantConnect GmbH”

ParticipantConnect GmbH is a B2B company that provides various ICT services for companies. Its primary business is to provide ERP services for enterprises operating in the manufacturing supply chain, and it has realised that the ManuData data space in the manufacturing sector can significantly enhance its core ICT services by providing vital data for the core processes of its clients.

As a result of this insight, ParticipantConnect has started providing its clients access to the ManuData data space via participant agent services, including credential stores, onboarding and participation management services, and data space connectors, which are needed to operate on the ManuData data space control plane.

ParticipantConnect’s primary business model is to enhance their current ERP-centric business offering and consolidate their position as a trusted service provider for their clients. They also process data on behalf of their clients and have capabilities to map the data models from various data sources within the ManuData data space against the models used by the business processes that their clients expect.

ParticipantConnect is actively looking to new data spaces and other countries to expand its business offering around data spaces.

Overall, there are 15 different participant agent intermediaries like ParticipantConnect that provide services in the ManuData data space. The ManuData data space governance framework requires that all participant agent service providers must commit to the rulebook and become participants of the data space. In essence, the ManuData is operating based on a four-corner model where each participant has a free choice to select their participant agent service provider from among the 15 intermediaries in the ManuData data space.

The governance framework also includes a mandatory subscription fee applicable to all participants of the ManuData data space, including participant agent service providers like ParticipantConnect. The governance framework of the ManuData data space also requires that all participants that intend to engage in data transactions, i.e., provide or receive data, must connect to the data space through a participant agent service provider.

All participant agent service providers in the ManuData data space actively promote the data space and form a business community that works together to develop and scale the ManuData data space.

Characteristics of ParticipantConnect GmbH:

Participant contracted,
Agency intermediary,
Technical interoperability enabler

Design considerations:

Should the data space governance framework require that all participant agent intermediaries are qualified DGA-compliant DISPs?
Should ParticipantConnect design its participant agency service offering so that it would qualify as a DGA-compliant DISP and operate those services through a subsidiary or similar (as required by the separation of concerns provisions in the DGA)? What would be the benefits to the company? Would it gain an advantage against other participant agent intermediaries who are not recognised DISPs?
What would be an appropriate level of participation fees for participant agent intermediaries? Should that fee be collected via a proportional revenue sharing mechanism or as a fixed fee?
How should the data space governance framework ensure fair competition between participant agent intermediaries and make the ManuData data space an attractive market for new ones to enter?
Are the cases where the governance authority should require the use of some specific participant agent intermediary? Or recommend some over others?
What are the implications of the governance framework’s requirement that all data providing and receiving participants use participant agent services to engage in data transactions via the data space? When is this requirement beneficial and when not? Can this design provide benefits for data space business model, governance framework design for the data space? Or does this design violate some fundamental data space principle?

Example 3: Personal data intermediary “WithHumanData SA”

WithHumanData is a B2C and B2B service provider specialised in providing personal data management services for consumers to connect with data spaces. WithHumanData provides services for three different data spaces that have use cases with personal data: public transport data space in the mobility domain, kindergarten data space in the skills domain, and urban planning data space in the smart cities domain. Each of these data spaces has an operator with whom WithHumanData works to provide consent management services for the data space participants in the use cases involving personal data and for the individuals whose personal data is processed for those use cases.

The consumer-facing user interface and service portfolio of WithHumanData includes also personal data storage and wallet services, but these are not used in all data space use cases. Consumers who use WithHumanData services can manage their data across the three different data spaces and their use cases through a single interface.

Characteristics for WithHumanData SA:

Participant contracted,
Personal data intermediary,
Wallet provider,
DGA, GDPR, and eIDAS applicability.

Design considerations:

How will the collaboration between the data space operator and WithHumanData work in practice? Is there a direct relationship or is it mediated by the governance authority? Or can they each offer their services without the need to collaborate at all?
How do consumer-facing user interfaces and usability function in practice when the application is provided by WithHumanData? Should WithHumanData provide a white-labelling option where each data space can brand the consumer app according to their own brand, or is it viable for all the three data spaces to use a WithHumanData-branded application?
How are the identity management and policy decision functionalities necessary for each of the three data spaces integrated as a seamless and well functioning consumer-facing user experience? Will eIDAS wallets be useful or necessary?
Does all the revenue for WithMyData come from the fees it changes the different data space data space governance authorities, or can there be also fees for data space participants based for example on consent transactions? Or could there even be a cost to the consumers who use the service?
Is it possible to build a model where multiple personal data intermediaries provide services in the same data space and consumers have the choice of which service provider to trust and whose user experience to prefer?

Example 4: Domain-specific operator “HealthDataXchange Oy”

HealthDataXchange is a provider of federated services in a specialised domain, namely healthcare. As a data space operator, it has a similar role to DataSpace Operator Ltd in Example 1, but as a domain-specific operator it has a more specific business and functional focus in the health domain.

HealthDataXchange also provides privacy-preserving data analytics as a value creation service. These services are especially relevant in health data spaces, where participant-to-participant data sharing is not always an option with highly sensitive data but it is critically important that the data is processed by multiple parties.

While many technical capabilities and standards related to data transactions are the same across data spaces, some domains like health also have domain-specific regulatory, standards-related, and other needs and requirements. In practice, this means that domain specialisation will occur as it can result in competitive advantage.

Following this logic, HealthDataXchange has specialised in catering to health-related data spaces that require their service providers to handle the regulatory requirements for audit and certification, specialised standards and vocabularies, and specific requirements for handling consent and identity management that apply in the health domain. They count on the fact that this specialisation provides significant enough business benefits in terms of usability of their services, marketing, and sales to counter the effects of a smaller pool of potential data space clients.

While the health sector is clearly a specialised domain, it is not the only domain with special characteristics which is likely to favour sector-specialisation from its enabling service providers. For example, agriculture and finance have similar regulatory and standards environments and requirements which tend to speak in favour of preferring sector-specialisation. For the specialised intermediaries and operators, on the other hand, these characteristics of their specialised services are not restrictive in the sense that they would be indefinitely limited to providing their services to these sectors only.

Characteristics of HealthDataXchange:

Operator,
Personal data intermediary,
Value creation service provider,
Potential DGA applicability to the provision of some services,
Sector-specific compliance requirements.

Design considerations:

In addition to the design considerations in Example 1, consider:

Are there any legal implications if the same service provider provides all of federated services, personal data intermediary services, and value creation services? Can personal data intermediary services be provided by companies who do not qualify as DISPs? If they come attached with value creation services such as analytics services?
If competing domain-specific operators provide services to different data spaces in that domain, what is the business rationale for providing for cross-data space interoperability? While the domain-specific technical standards might enable semantic and technical interoperability, and the shared regulatory environment might enable legal interoperability, are there business logics that are likely to emerge that would limit, disincentivise, or even block cross-data space interoperability?

1. Summary

This building block encompasses key decision-making points for the effective establishment and operation of a data space, namely the determination of an organisation's form and the establishment of a data space, the creation of a governance authority and the creation and realisation of a data space governance framework.

The building block describes the options of creating a data space as an unincorporated (i.e. without legal personhood) and incorporated (i.e. as a legal person) entity and discusses most important consequences of these choices in a comparative way. The choice of legal of form of a data space impacts the type and role of a governance authority, the ability of a data space to develop and implement its governance framework and, ultimately, data space’s overall development and sustainability.

Determining the organisational form and establishing the governance authority should be completed before the data space enters the operational phase. At least in the most essential parts, a data space governance framework should be created in parallel to support the functioning of the new data space. The organisational form, type of governance authority and its role, and the governance framework may evolve over time due to legal requirements or business and technological developments.

1.1 Questions that will be answered

What factors do organisations consider when determining the organisational form of a data space?
What are the characteristics, advantages, and challenges of an unincorporated (no legal personality) data space?
What are the characteristics, advantages, and implications of establishing an incorporated (legal personality) data space?
How is a governance authority and governance framework created and maintained within a data space?
How do organisational form and governance framework influence the relationships among data space members and third parties?

2. Purpose of the building block

This building block aims to help the members of a data space initiative understand their options for its legal formalisation. A data space's business model and technical arrangements require legal formalisation to fully unfold their functionalities, ensure legal rights and business interests, and minimise risks for all data space participants. This building block provides basic information regarding creating a data space, its governance authority and governance framework.

3. Elements and their key functions

3.1 Determining an organisational form and establishing a data space

A data space usually starts when several organisations have data sharing needs (i.e., a data space initiative). As one of the first steps, the members of a data space initiative need to reach several basic agreements such as that they all want to work towards establishing a data space, what sector or sectors of the economy they want to target and how they would work together to achieve it. These agreements do not need to be formalised but can be a simple understanding or informal agreement between the committed members of a data space initiative.

The committed members then continue working together on the business model of the future data space Business Model (original). While developing the business model, they also consider the following non-exhaustive list of questions that are decisive for the organisational form of the future data space:

Should the future data space be a permanent or temporary (even if multiyear) establishment?
Should the future data space have a legal personality?
Does the future data space aim to generate profits for its members (i.e. the legal entities that create it)?
What country will be the primary place of establishment (i.e. headquarters) of the future data space?
What level of involvement do the members of the data space initiative want to have in managing and operating the future data space?

The answers to these questions should help the committed members of a data space initiative shape the space's business model and decide on appropriate legal arrangements (Figure 1, also see Establish Organisational Form in the Co-Creation Method).

3.1.1 Data space without legal personality (unincorporated data space)

If there is uncertainty about the permanent establishment or disagreement about the legal form at the beginning of a data space initiative, the committed members of a data space initiative can use various contractual arrangements to give structure to the data space as a multiyear project. For instance, some European Union Member States allow the creation of joint ventures that are not separate legal forms (i.e. participants of a joint venture simply share resources and knowledge). It is also possible to sign other types of cooperation/ collaboration agreements, such as strategic alliance agreements or consortium agreements. For simplicity, all such agreements are called founding agreements and the parties to the founding agreements are called data space members in the text below. By signing the founding agreements, data space members created special obligations towards each other with regard to achieving the goals of their cooperation.

These founding agreements are governed by national civil law that may have specific requirements for their content and form (e.g. simple written form or notarised). Such agreements typically describe the goal of the common project and outline the roles and responsibilities of different members, profit sharing and compensation arrangements, remedies for failure to deliver, applicable law and dispute resolution rules and termination provisions. It is important to underscore that unincorporated joint venture, consortium and other similar cooperation are temporary arrangements that are created to achieve a certain goal. Therefore, the founding agreement must contain provisions on when the agreement is terminated (e.g. upon reaching the goal, after a certain time, upon occurrence of a certain event). Due to the complexity of the arrangements, a written recording of any such agreements is strongly advisable, but no other actions (e.g. authentication by a notary or registration) are usually necessary.

New members can join unincorporated joint ventures, consortia and other types of cooperation only if all current members agree to it and only after the prospective member signs the founding agreement. In such a case, the founding agreement may need amendment because the new member is likely to assume a new role and responsibilities.

3.1.1.1 Consequences of this organisational option and contractual safeguards

Unincorporated joint ventures, consortia and other types of cooperation do not have their own resources and rely solely on the resources, capacities and capabilities of their members. They are tightly controlled by their members, which sometimes might hamper their activities, especially if one of the members does not fully pull its weight and refuses to be replaced. Therefore, it is advisable to expressly allocate in the contract different roles and tasks to be performed by each of the members. A single description of the overall work by each member minimises the risk of scope gaps and the potential for internal disagreements.

Because data management of third parties is expected, the founding agreement must include clauses addressing data management. In particular, if a data space handles personal data, it is necessary to determine which member within this data space is a data processor as required by the GDPR (for more details see Regulatory Compliance). Even if a data space does not handle personal data, it is still necessary to determine which member(s) is(are) responsible for data security and what their responsibilities are. Due to the importance and likely complexity of data management involved, it is advisable for members to design and sign a separate data management agreement.

Because no legal person is created as a result of this cooperation, legal liabilities and ownership remain by default with the individual members and must be specified in the founding agreements.

In particular, usually all results of the conducted work are owned by the party that generates these results (e.g. if a member X creates software X, this software remains member X’s property). Members can agree in the founding agreements on joint ownership of all or only certain results from the cooperation. In this case, they need to agree how exactly they will dispose of joint property rights, including transferring, licencing and distributing the royalties.

Typically, members are solely liable for their actions towards each other, but in the founding agreement they can limit their liability proportionally to their total share in the cooperation. In relations to third parties (i.e. those who are not a member of the founding agreement), members are solely liable for their actions in fulfilling their responsibilities under the founding agreement, and no limitations by the founding contract is possible. Also, agreements need to be negotiated regarding the liability for the assets commonly used or created (e.g. who is paying for the electricity used by the data space; who will do maintenance; who will pay for the necessary software licences; etc.).

An unincorporated entity must also decide on who represents the data space towards other data space participants such as data transaction participants and providers of enabling services as well as third parties. This is of huge importance because the unincorporated data space itself is not able to conclude any agreements in its name. Instead all agreements must run via individual members, but it is likely that the data space interests should be represented or considered in the agreement negotiation.

Addition of any new members requires the agreement (consent) of all existing members. If a new member joins an unincorporated data space, a change of the founding agreement is necessary to determine the role, rights and obligations of the new member. In connection with this, a substantial re-negotiation of the contractual roles, ownership arrangements, liabilities and other issues among all members is likely because a new member brings new dynamics into the existing cooperation.

3.1.1.2 Creation of Governance Authority

Unincorporated joint venture, consortium and other types of cooperation are completely member-driven, which requires strong governance arrangements to align and coordinate individual activities. These governance arrangements are dedicated to achieving the commonly defined purpose of the cooperation (e.g. by generating all of the intended deliverables). The governance arrangements do not extend to actually managing any of the resources (because these remain at the full disposal of the members) or controlling and managing any of the results (because the ownership of those lies with the members).

Members of an unincorporated data space can set up a governance authority for their cooperation according to their needs and wishes. There are no legal requirements for equal or any other specific representation in decision-making, which may lead to power imbalances between contracting parties. Therefore, it would be important to follow the best practices of corporate governance. The governance authority typically consists of all members of the consortium/ joint venture and is ultimately responsible for decision-making and achieving the goals of the cooperation. It can be called “general assembly”, “steering group”, or else. The decisions by this governance authority are adopted unanimously and are binding on the members of the founding agreement. The members then decide separately and for themselves how they implement these decisions to achieve the goals of the cooperation.

It shall be underscored that any individuals active in the governance authority in any capacity remain employees on the payroll of individual members and are subject to the direction of and supervision by these members.

In sum, founding agreements are relatively easy to change depending on the project's needs and circumstances. They can be prolonged, if the original goal has not been achieved. A conversion to a permanent legal person can be done at a later stage of the data space development cycle (e.g. in the implementation stage) once the business model of the data space matures. At the same time, they are very complex documents that must contain safeguards regarding any eventuality. Unincorporated data space is unlikely to be sustainable over time, develop beyond a certain initial point to become truly stand-alone and develop an own dynamic. For this, a data space should become incorporated.

3.1.2 Data space with legal personality (incorporated data space)

When the decision is reached to establish a data space as a permanent structure, establishing a new legal person or creating a data space based on an existing legal person is necessary. Currently existing data spaces that do not have profit-making as their purpose have frequently established themselves as associations and sometimes as foundations. A limited liability company is the most popular legal form for data spaces with profit-making objectives. For-profit legal entity may acquire a special status of “benefit corporations” in some countries (e.g. Italy, France and Germany), which means that a company combines the goal of generating profit with the beneficial purpose of creating positive societal and environmental impacts and operates in a transparent, responsible and sustainable way.

Examples of data spaces and their legal forms

Europeana, the Common European Data Space for cultural heritage, is founded as a foundation under Dutch law (“stichting” in Dutch).
Catena X, a data space in the automotive sector, is created as an association under German law (“eingetragener Verein” in German). This legal form under German law is not allowed to pursue commercial purposes.
Mobility Data Space (aka DRM Datenraum Mobilität) is a limited liability company under German law (“Gesellschaft mit beschränkter Haftung” in German).

If the committed members of a data space initiative decide on an establishment under national law, they will have great flexibility to choose from dozens of various legal forms across 27 EU Member States. Each of those legal forms has its advantages and disadvantages and needs to be considered in detail depending on the data space business model, use cases and more general considerations related to the business location (e.g. availability of the necessary infrastructure, skilled staff, tax rules, business-friendliness, red tape). At the same time, the choice of the business location and legal form is likely to require adjustments to the business model.

In addition, legal forms created under EU law could be particularly attractive for data space targeting cross-border markets and for Common European Data Spaces. Legal forms under EU law allow a company to operate as a single entity throughout the EU and be subject to harmonised rules. One can choose from:

European Digital Infrastructure Consortium (a special legal form created for Common European Data Spaces and special multi-country projects);
European Company (a for-profit legal entity, similar to the limited liability company);
European Cooperative Society (a non-profit with characteristics of a cooperative and public limited company); and
European Economic Interest Grouping (a non-profit legal entity similar to a partnership).

More information on European Digital Infrastructure Consortium

European Digital Infrastructure Consortia can be created only for the purpose of implementing multi-country projects. A European Digital Infrastructure Consortium must have at least three Member States as members. The characteristic of a member is that it provides financial (money) or non-financial (assets) contributions to the European Digital Infrastructure Consortium. The consequence of being a European Digital Infrastructure Consortium member is that a Member State has voting rights in the assembly of members, meaning that it can directly influence the most important decisions about the functioning of a data space.

A European Digital Infrastructure Consortium is created via a decision of the European Commission. Member States that are members must submit an application to the European Commission that includes a technical description of the multi-country project, the proposed statutes of the European Digital Infrastructure Consortium and a declaration from the host Member State on whether it recognises the EDIC as an international body and international organisation. The European Commission assesses the application and approves or rejects it. If the application is rejected, the Member States in question may still form a consortium and implement the intended project without the benefits allotted to a European Digital Infrastructure Consortium.

There are several benefits to European Digital Infrastructure Consortia. Firstly, a European Digital Infrastructure Consortium is a legal entity that will be subject to virtually the same legal rules in all EU Member States as it is a product of EU law. Still, it should be noted that Member States will have to adopt national law to govern those issues of European Digital Infrastructure Consortia that are not covered by EU law. Secondly, there might be some tax benefits for European Digital Infrastructure Consortia if the host Member State recognises European Digital Infrastructure Consortia as international bodies or organisations. Thirdly, European Digital Infrastructure Consortia membership is quite diverse, and besides EU Member States, it may include third states, international organisations, and private actors. Fourthly, because of the above, European Digital Infrastructure Consortia may be more effective investment vehicles, leveraging government funding, but able to gather and tie up financial means from a variety of sources. This may ultimately lead to more effective implementation of multi-country projects.

Several issues should be considered when thinking about the establishment of a data space as a European Digital Infrastructure Consortium (non-exhaustive list):

A European Digital Infrastructure Consortium must have at least 3 European Union Member States as members (represented by their public authorities) that provide financial or non-financial contributions. By contrast, there is no need to involve Member States in the creation of any other legal person as they can just be created by legal persons and/or natural persons.
Member States are the driving force behind European Digital Infrastructure Consortia. It depends on them to apply for a Commission’s decision; they define the status of European Digital Infrastructure Consortia within their jurisdictions; they are the main decision-takers throughout the life of multi-country projects.
The creation of a European Digital Infrastructure Consortium is in the hands of the European Commission, which assesses the application and decides whether to set up the Consortium or reject the application. By contrast, any other legal form is created by an agreement (in the form of a statute or articles of association) among its members. There is no need for any approvals by a governmental authority.
The participation of states and the European Commission in the assembly of European Digital Infrastructure Consortia members next to private actors will create different dynamics for negotiations concerning decision-making. The European Commission will have a veto right over actions financed under centrally-managed Union programmes (such as the Digital Europe Programme, Horizon Europe and similar).

Once the members of a data space initiative agree on the legal form for the intended data space, they need to sign a founding agreement (usually called a statute, articles of incorporation or articles of association). Its form and minimum contents are regulated by the national law of the respective EU Member State or by EU law. They vary slightly depending on the exact legal form in question, but the main elements are name and address of the registered office, purpose and intended activities, method of convening of the general assembly and appointment and dismissal of directors, powers of representation to the third parties, certain monetary obligations between the organisation and its members, admission of new members and what happens to the organisation’s property in the case of dissolution. Natural and legal persons that have signed the founding agreement are called data space members. Data space members are in contract (i.e. founding agreement) with each other for the purpose of the establishment of a data space and, to this end, have special rights and obligations.

While the choice of legal form and business location for a data space is a serious matter, it can be changed later on. However, such a change is not a trivial task and cannot be done very often. In particular, converting from a for-profit legal form (e.g. limited liability company) to a non-profit (e.g. foundation) is rather difficult due to the change in the applicable taxation rules. Also, a company created under the national law of one EU Member State cannot, in most cases, move its headquarters to another EU Member State without first dissolving and re-establishing itself in the new location under the new national law.

3.1.2.1 Consequences of this organisational option

The execution of this organisational option leads to the creation of a data space as a legal person that is separate from its members. This means that the said data space can own property, enter into contractual relationships with other legal entities, be beneficiary of legal rights, be responsible and liable for its own obligations and employ own staff. Results of any work performed by such data spaces are their own (intellectual) property, of which they can dispose freely. Once the founding agreement is signed, such data spaces can develop their own dynamics, gradually becoming more autonomous from their members.

In relation to their members, such data spaces maintain certain obligations, depending on the exact company form. For example, a for-profit data space may have an obligation to distribute profits to its shareholders. Members have the right to participate in the main governance body – e.g. general assembly – and decide on the most important, strategic questions of the data space development (e.g. admission of new members). However, the control by members over the data space is rarely comprehensive: it is unlikely to extend to all activities of the data space and, even for the most important issues, a majority decision is sufficient. By contrast, third parties may participate in a data space as data providers, service providers, data recipients and have contractual relationship with the data space, but they do not have decision rights.

The process of and requirements to the addition of new members depend on the legal form of the incorporated data space and are defined by law and further specified by the founding agreement. In some cases, the agreement of all existing members is required, while in others it suffices that the new member buys shares of the company. No substantial changes to the founding agreement or re-negotiation of rights and obligations are usually necessary.

3.1.2.2 Creation of governance authority

Incorporated data spaces need bodies to create, maintain, and enforce their internal rules and manage the data spaces’ day-to-day operations. A body is a differentiated structure of an organisation that performs specialised functions. For example, if a data space is created as a non-profit in the legal form of an association, it will have to comply with a legal requirement to have two bodies: a general assembly of members and a management board. The general assembly of members is a representative body consisting of all members and makes the most important decisions regarding the association. All members vote for decisions, although not all decisions must be taken unanimously. The management board is an executive body that puts into practice the decisions of the general assembly of members. The management board is appointed or elected by the general assembly and is accountable to it for its activities. The management board effectively runs the association on a daily basis. It is not representative and may include staff specifically hired by the data space for their management skills. Data space’s bodies jointly constitute a data space governance authority; however, data spaces may choose a different name for such an institution. A data space governance authority's form, composition and competencies are determined jointly by the founding members (i.e. legal and natural persons that established the data space). In addition, a data space governance authority is strongly impacted by the business model and legal form of the data space.

Figure 2 provides a visual illustration of the governance authority of an incorporated data space.

The members of a data space can decide on the size and composition of the data space governance authority within the limits set by law and depending on the size and needs of the data space. For small data spaces, the executive body may consist of a few people or even one person. Common European Data Spaces in the form of a European Digital Infrastructure Consortium will be large entities requiring a lot of management work and, therefore, need many personnel. They are also more likely to need additional specialised bodies (e.g. working groups or committees) for specific tasks. For instance, due to the high number of participants in a Common European Data Space, there might be a need for a separate committee on participation management.

The legal and natural persons that established a data space (i.e. data space members) can determine the competences of the data space governance authority within the limits of the law (e.g. rules on competencies of the executive body, rules on the representation of the data space in dealings with third parties, rules on the creation of working groups and committees).

If members of a data space want to involve third parties (i.e. stakeholders that are not data space members) in the governance of this data space, they can foresee special bodies for this. Whatever the names of such bodies (e.g. advisory board, community board), it is important to remember that they cannot take binding decisions over a data space - only the assembly of the data space member can. However, such bodies may provide their opinions, views and observations to the decision-making body. The provisions on such a body are decided by the data space members and entered either in the founding agreement or later bylaws. These provisions must regulate who the members of such a body are and how they are chosen or appointed, what topics can be discussed, how often the body meets, what type of documents can be adopted and how these documents are taken into account by the decision-making body.

If a data space is created based on an already existing legal person and this person runs different business operations besides a data space, it is advisable to create a separate body solely for managing the data space. However, this decision would be within the remit of such a legal person, depending on its business model and the data space size.

To summarise the discussion of unincorporated and incorporated data spaces, Table 1 below provides a concise comparative overview of their main features.

	Unincorporated data space	Incorporated data space
Temporal existence	Data space is a temporary establishment, although it may exist for several years. The termination is pre-determined by the founding agreement.	Data space is a permanent establishment, its termination is not pre-determined by the founding agreement.
Legal personality	Data space is not a legal person.	Data space is a legal person, separate from its members.
Ability to enter into contracts	Data space cannot conclude contracts with third parties in its own name. Only members can conclude contracts.	Data space can conclude contracts in its own name with third parties.
Ownership of property	All property is owned and disposed of by members, individually or jointly.	Data space owns (intellectual) property and disposes of it.
Liability	Members are liable for their actions. Data space cannot bear any liability.	Data space bears liability for the actions of its governance bodies.
Complexity of the founding agreement	The founding agreement is a highly complex document regulating various aspects of relationships between members.	The founding agreement is fairly simple document establishing the data space and regulating only certain monetary relationships between the data space and its members.
Control over the data space	Members are in complete control of the data space.	Data space is in control of itself through its governance bodies.
Addition of new members	The process requires consent of all existing members and re-negotiation of the founding agreement.	The process varies depending on the legal form, but usually does not require re-negotiation of the founding agreement.

Table 1. Summary comparison of unincorporated and incorporated data spaces

3.2. Data space governance framework

A governance framework of an organisation sets out roles, responsibilities and procedures for its effective and efficient operation. It consists of organisation’s internal objectives, values, policies, practices and accountabilities. In short, a governance framework is a set of rules on the functioning of an organisation and its presentation of the wider world.

An organisation’s governance framework is influenced by and based on external legal and regulatory rules (see Regulatory Compliance). Some legal rules are mandatory (e.g. the requirement that an organisation in the legal form of association must have at least two bodies: a general assembly and a management board) and must be reflected in the governance framework. What rules are mandatory for an organisation’s governance framework strongly depends on its business case (e.g. if an organisation is a qualified trust service provider, it is subject to high security requirements and, hence, must have special (cyber)security policy and guidelines on how to select trustworthy systems for data storage; if an organisation processes personal data on a large scale, it must have a data protection officer as per GDPR).

3.2.1. Elements of a data space governance framework

It is practical to distinguish between at least two different elements of a data space governance framework:

Rules defining purely internal roles, responsibilities and procedures: these rules define the relationships only within the data space and have only an indirect influence on the relationships with third parties (e.g. data providers, data recipients, service providers), and
Rules that also directly define data space’s relationships with third parties (e.g. data providers, data recipients, service providers).

Importantly, terms and conditions of use of a data space, and contracts between the data space and its service providers and other participants (e.g. data providers, data recipients) are not part of the data space governance framework. These agreements are operational and relate only to a concrete relationship between a data space and a third party. They do not influence roles, responsibilities and procedures within a data space. Instead, such agreements are based on, and result from, the governance framework of a data space. Such agreements are concluded by the data space body with powers of representation, in the absolute majority of cases without any involvement of the representative body (like a general assembly).

Data product contracts and data services contracts are also not part of a data space governance framework because they are contracts between third parties (e.g. data provider and data recipient) and do not involve a data space as a contract party at all.

3.2.1.1. Internal rules of a data space

The rules that define purely internal roles, responsibilities and procedures are contained in the founding agreement of a data space and in data space bylaws. As described above in this building block, the founding agreement contains the fundamental rules related to the internal organisation and decision-making of a data space. Data space bylaws contain important procedures that keep the organisation running, such as the number of members constituting quorum for a general assembly meeting; how and when to gather an extraordinary general assembly meeting; details on the voting procedures – including depending on the matter discussed; how to appoint and dissolve a committee or a working group; rules on decision-making by the executive body of a data space; rules for approval of large contracts; and others procedures.

The common feature of all these internal rules is that they are indispensable for a data space to function, and that they do not influence in any direct way third parties to a data space (i.e. those data space participants who are not data space members). At the same time, these rules define by whom and how relationships with such third parties are entered and exited (e.g. who is allowed to conclude a contract in the name of a data space). Violation of these internal rules may invalidate legal relations with third parties (i.e. nullify contracts) and lead to civil law liability of a data space or its members. The latter is particularly the case if provisions of the founding agreement are violated.

It is very important not to mix up the founding agreement with any other internal rules. The reason for this is that any change to the founding agreement must be reported to the registry of legal entities in the country where the data space is established. Founding agreements are very stable documents that are extremely rarely changed.

3.2.1.2. Rules that directly define relations with third parties

Within the framework of the founding agreement and applicable laws, each data space can draw up various policies, statements, guidelines and related procedures (to be called policies for simplicity). Some of these policies are required by law, while others can be determined by the organisational or business needs of a data space. An example of the must-have a policy is privacy and data protection policy, which is mandatory for any organisation processing or controlling personal data. A great number of policies are needs-based. Examples of this are a policy on technical specifications (standards, APIs, semantic models, provenance and traceability) used by a data space, or cybersecurity policy defining internal data space measures and expectations towards data space service providers. A very large data space with many participants selling and buying data may consider adopting a competition policy and a dispute resolution policy and mechanism. A policy can also be adopted due to strategic objectives of a data space, for instance, a sustainability policy or a stakeholder-engagement policy. In sum, each data space can decide what policies they need to draw based on their legal obligations (see Regulatory Compliance) and on their business case.

The common feature of all these rules is that they have an internal and external function. On the one hand, they represent a commitment by a data space to behave in a certain way. This commitment may be legally imposed on a data space (e.g. by the GDPR), but may also be a non-binding unilateral declaration by a data space (e.g. specific sustainability commitments). On the other hand, these rules directly influence data space’s relationships with third parties. They signal to third parties what standards a data space uses and expects them to use if they choose to join as participants. They signal to potential service providers what is expected from them in terms of cybersecurity levels and standards. Any contracts between a data space and third parties (e.g. service providers, data providers) are based on these policies, or the policies are made annexes to the contracts. Lastly, unless a policy is mandated by law, a data space can change or withdraw it completely without any legal consequences.

3.2.2. Creation, maintenance and realisation of a data space governance framework

All documents comprising the governance framework should be prepared and discussed by the executive body of the data space governance authority or by specially created working groups within the governance authority (depending on the organisational structure of a data space). The decision on the adoption of the said documents should be taken by the representative body of a data space (e.g. for an association - a general assembly of all members with the right to vote). The general representative body can also adopt rules (which will become a part of a governance framework) allowing the executive body to adopt certain policies or changes to policies. This is advisable for technical issues where quick decision-making is necessary. Such an approach is not only in compliance with the legal requirements but also follows the principles of good corporate governance of representation and inclusion, but also allows for more flexibility in the operation of a data space.

Once approved, the data space governance framework shall be documented. The actual artefact can be called any suitable name (currently, the term “rulebook” is popular – see IDSA Rule Book or SITRA Rulebook) and should be expressed in a human-readable and, if possible, machine-readable format.

A data space governance framework must be kept up to date meaning that it may need regular adjustments based on new legal requirements and/or changing business, economic or technological circumstances. The task of monitoring of the new developments that may require such adjustments lies with the executive body of the data space authority. Actual changes to the governance framework in some situations may be done by the same executive body, but in other cases may need a decision by the representative body of a data space (e.g. changes to the founding agreement due to the change of business model).

Realisation of a data space governance framework is the responsibility of the executive body of the data space authority. The data space governance authority realises the governance framework through its own actions, such as finding suppliers and service providers, concluding contracts with them, identifying or developing standards, creating a catalogue and other actions.

4. Co-creation questions

Do the organisations involved want to establish a data space?
Which participants or actors are directly involved in which use cases, and what roles do they play?
What are the roles and the responsibilities of the data space founders that will become part of the governance authority?
What organisational form is chosen for the data space?
What Governance Authority will be established?
What needs to be considered for the creation of the rulebook for a data space?
Which activities will the governance authority perform to run the data space?
What are the processes through which the governance authority should perform its duties, and how should they be monitored and reviewed?

5. Further reading

European Commission, European Digital Infrastructure Consortium User Guide, 2023.
European Commission, Setting up a European Company (SE).
Many countries and organisations publish model cooperation/ collaboration agreements that can be used by data space members and adjusted to the needs of their data space initiative. Some of the most renowned model agreements are the DESCA Model Consortium Agreement, the International Chamber of Commerce Model Joint Venture Agreement, and the UN ITC contractual joint venture model agreements.
European Corporate Governance Institute publishes corporate governance codes for various European countries. While these codes are oriented primarily at for-profit listed companies, principles and recommendations are best practices and can be followed by other legal entities as well.
IDSA, IDSA Rule Book, 2021.
Sitra, Sitra Rulebook, 2022.

6. Glossary

Term	Definition
Common European data spaces	Sectoral/domain-specific data spaces established in the European single market with a clear EU-wide scope that adheres to European rules and values.
Data space	Interoperable framework, based on common governance principles, standards, practices and enabling services, that enables trusted data transactions between participants.
Data space development cycle	The sequence of stages that a data space initiative passes through during its progress and growth. In each stage, the initiative has different needs and challenges, and when progressing through the stages, it evolves regarding knowledge, skills and capabilities.
Data space governance authority	The body of a particular data space, consisting of participants that is committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework.
Data space initiative	A collaborative project of a consortium or network of committed partners to initiate, develop and maintain a data space.
Data space participant	A party committed to the governance framework of a particular data space and having a set of rights and obligations stemming from this framework.

1. Summary

The Participation Management building block outlines governance processes for managing participant engagement in data spaces. This includes:

identifying participants,
setting rules for data transactions and service provision,
onboarding,
offboarding.

In addition, it provides guidelines for efficient and secure participation by integrating relationships with other governance aspects like regulatory compliance and identity management.

1.1 Questions that will be answered

Who can be a participant in a data space, and how do they differ from candidates or external stakeholders?
How are roles like data providers, recipients, intermediaries, and data rights holders defined, and what responsibilities do they have?
What internal governance mechanisms does an organisation need to implement in order to participate in a data space in a responsible way?
What processes and criteria govern the onboarding of new participants?
How do governance authorities balance inclusiveness with strict interoperability and quality requirements when setting admission rules?
What mechanisms ensure that participants remain compliant and engaged as the data space scales?
Under what circumstances can a participant be offboarded, and how is this process managed?
How does the offboarding process ensure that data rights, obligations, and access are properly terminated?

2. Purpose of the building block

According to the DSSC Glossary, data space participants are those committed to the governance framework of a particular data space and having a set of rights and obligations stemming from this framework. It concerns all organizations and individuals who join to engage in data transactions, facilitate transactions via service offerings, or act as data rights holders.

Before formally joining, potential participants are referred to as candidates. Their interest in joining a data space can stem from a variety of reasons, often tied to specific business objectives, distinct requirements, and individual expectations for participation.

Participants join a data space to share and use data under the consideration of rights and obligations related to the data. In addition to the technical building blocks internal data governance processes need to be implemented and aligned with the overarching data governance framework of a data space. The internal data governance framework needs to address relevant aspects including the management of data rights, data quality, observability of data transactions, data provenance, and tracing of shared data under consideration of regulatory compliance and contractual framework.

The Participation Management building block describes the operational processes but some of them may need to be put into practice via the technical building blocks.

While the data space governance authority consists of data space members as well, it is out of the scope of this building block to handle the participation processes within the data space governance authority, since they are discussed in the Organisational Form and Governance Authority building block.

Participation Management is closely connected to other governance dimensions that ensure trust and compliance in data spaces. These include:

Regulatory Compliance: Adherence to GDPR and DGA for data protection and lawful data sharing.
Contractual Frameworks: General Terms and Conditions and agreements that define rights, obligations, and exit procedures.
Identity and Verification: Identification and attestation mechanisms for onboarding and lifecycle management.
Technical Interoperability: Standards for APIs, data formats, and security protocols to enable seamless integration.
Data Quality and Observability: Processes for monitoring data transactions, provenance, and audit trails.
Trust Anchors and Conformity Schemes: Mechanisms to verify compliance and maintain transparency.

3. Elements and their key functions

Effective participation management is essential for ensuring the smooth operation and governance of data spaces. This process involves clearly defining the roles and responsibilities of participants, managing their onboarding and integration, facilitating secure and compliant data transactions, the provision of services, and overseeing the offboarding process.

3.1 Roles and Responsibilities of Data Space Participants

The roles within a data space can vary depending on the specific context. For example, a participant may act as a provider of a data product in one transaction and as a consumer in another. Some of these roles are a more detailed breakdown of these roles and are outlined in the Data Space Rulebook, which serves as the documentation of the data space governance framework for operational use. The Rulebook is described in more detail in the introduction of the Blueprint.

Data Providers are organisations that supply data to the data space. They generate and share data sets that can be used by others.
Data Recipients consume data from the data space for various purposes such as analysis, decision-making or product development and therefore directly engage in the process of data transaction. For both types of participants, participation management needs to ensure the management of permissions, support of data quality standards, but also mechanisms to monitor and report data utilization.
Intermediaries and Operators facilitate the exchange of data between providers and users. They enable and intermediate data exchange as (value creation) service providers. Even though they do not engage in data transactions, they are crucial participants to the data space, which is why participation management should facilitate data intermediaries and operators to ensure adherence of interoperability standards.
Data Rights Holders are individuals or organizations that hold the rights to the data. They decide the terms and conditions under which their data can be shared and used within the data space.
Data space governance authority might formulate more specific roles per data space, documented in the data space’s rulebook.

For some data spaces, distinguishing between participants who form the data space governance authority and those who do not, might be needed. Role differentiation could help in clarifying responsibilities, maintaining trust and transparency. So for instance, data space members can be introduced as an additional role for organisations that found the data space, sign the founding agreements and create the data space governance authority.

Note: to be considered additionally
External stakeholders are organizations not directly involved in the data space, but might significantly be affected by or having impact to the data space ecosystem. For instance, farmers can be external stakeholders of an agricultural data space without being direct participants. For example, a data space might bring together agritech companies, equipment manufacturers, governments, and research institutions to exchange data on soil health, yields, and weather patterns. Even if individual small-scale farmers are not members, they are still affected by the outcomes: market prices and quality standards may be shaped by shared insights, governments may design subsidies or environmental rules based on aggregated data, and larger participants can gain competitive advantages from optimized farming practices.
While in that example the farmers are not particularly participants of the data space, they might have interests and requirements that affect participation management and should therefore be taken into consideration, as well. This requires the data space governance authority to understand concerns and needs of external stakeholders and foster transparency by considering the potential impact and consequences of the data space on their activities.

3.2 Internal Governance Processes supporting Participation Management

To participate effectively and responsibly in data spaces, organisations must establish internal governance processes that ensure clarity of roles, legal and technical accountability, and alignment with broader trust requirements. These processes should enable consistent decision-making and risk management in line with both strategic objectives and stakeholder expectations. They are part of Data Space Governance Framework, described more in detail in Organisational Form and Governance Authority Building Block.

The ISO/IEC international standard 38500 “Governance of IT for the organisation” provides a relevant foundation for this work. It outlines how governance mechanisms should direct and control the use of digital capabilities. In the context of data spaces, this means ensuring that internal processes are in place to manage responsibilities across the legal, operational, and technical dimensions of participation.

A key aspect of readiness is the internal definition and communication of roles related to data space engagement. This includes determining:

who has authority to act on behalf of the organization,
how decisions are taken regarding data access and sharing, and
how responsibilities are distributed across teams managing legal compliance, data stewardship, and IT integration.

Such role clarity supports efficient collaboration and reduces the risk of uncoordinated or non-compliant activity.

Internal governance frameworks should also support the management of specific trust-related functions. These include the definition and enforcement of data rights, particularly where data rights holders and data providers are not the same entity. Mechanisms should exist to verify who is allowed to share, access, or reuse data, under which conditions, and with what limitations.

In addition, governance processes must ensure that data quality is monitored and maintained throughout the data lifecycle. This involves assigning accountability for ensuring that shared or consumed data is accurate, complete, and suitable for its intended use, and that appropriate quality controls are applied.

Observability is another essential governance function. Processes should enable monitoring of data transactions, detection of anomalies, and provision of audit trails when needed. This includes maintaining visibility into how data is accessed, by whom, and under what terms, supporting both transparency and regulatory compliance.

Effective governance must also provide the ability to document and track data provenance and lineage. This involves capturing where data originated, how it has been transformed, and by which systems or actors. Together with mechanisms for tracing data flows and ensuring contractually agreed usage conditions are respected, these capabilities form the basis for reliable, accountable data exchange.

To remain effective over time, internal governance should include continuous review of participation-related processes. Regular assessment helps ensure that engagement practices evolve with changing legal frameworks, technical standards, and organizational priorities. Adjustments based on internal feedback and audit findings further support sustainability and trust.

Establishing these governance capabilities positions participants to meet the expectations of data space operators, other participants, and regulators alike. It also supports interoperability with shared trust frameworks, and contributes to the overall robustness and transparency of the data ecosystem.

Note: This guidance reflects governance principles also outlined in the upcoming CEN/CENELEC Workshop Agreement “Trusted Data Transaction – Part 2: Trustworthiness Requirements”, which is currently under expert consultation and expected to be published soon. The document details how internal structures and responsibilities contribute to trusted and compliant data transactions within federated environments.

Participation Management spans two layers:

Operational Processes: Human-driven governance activities such as:
- Defining roles and responsibilities (data providers, recipients, data intermediaries, data rights holders).
- Onboarding and offboarding workflows, including eligibility checks and contractual acceptance.
- Decision-making on compliance, risk management, and participant obligations.
- Continuous review and adaptation of governance frameworks.
Technical Processes: Implemented via building blocks (BBs) and automated systems, such as:
- Registries: Maintaining authoritative participant lists and trust anchors.
- Identification and Attestation Systems: Credential issuance, verification, and lifecycle management.
- Onboarding Tooling: Digital acceptance of terms, automated compliance checks, and secure credential provisioning.
- Monitoring and Audit Services: Observability of transactions, anomaly detection, and traceability.

3.2.1 Onboarding

Efficient onboarding of participants is critical for the seamless functioning of a data space. It ensures that participants can quickly integrate while adhering to compliance and technical standards, minimizing risks of inefficiency or data misuse, and fostering a trustworthy and collaborative environment.

The data space governance authority defines the minimum requirements for participation, which are outlined in the General Terms and Conditions (see Contractual Framework Building Block for more information). These cover the rules for joining, including identity verification, compliance checks, attestations (first-, second-, or third-party), technical standards (e.g., APIs, data formats, languages), and baseline security requirements. They also clarify roles, responsibilities, and obligations for all participants.

To join, a candidate submits an application that specifies their intended role and use of the data space. The Governance Authority reviews the application against the established criteria and decides whether to grant or deny access. Alternatively, the authority may allow direct participation for any candidate that accepts the General Terms and Conditions and fulfills the admission criteria, without requiring a formal application process. In both approaches, participants must be notified of the decision, and in cases of denial, reasons should be communicated.

Once approved, participants formally accept the General Terms and Conditions, either by signing an agreement or through digital confirmation. The method of acceptance may depend on the candidate’s role (e.g., data provider, service provider, or transaction partner). Upon acceptance, membership credentials are issued to enable interaction with the data space and other participants.

The onboarding process is supported by the Data Space Registry, which provides visibility into data space rules, trust anchors, and conformity schemes used to verify compliance. The Rulebook complements the General Terms and Conditions by describing technical and operational standards in more detail.

Ongoing monitoring is essential to ensure that participants continue to comply with the rules and obligations of the data space. In addition to onboarding, the General Terms and Conditions should also address data protection policies, offboarding procedures, and mechanisms for updating requirements as the data space evolves.

Rules for participation may vary depending on the type of data being exchanged and the applicable legal framework (see Regulatory Compliance). For example, personal data must be handled in accordance with GDPR, which may impose different obligations on data providers and recipients. While additional internal policies can be introduced to ensure proper functioning, they should avoid creating unnecessary hurdles for participation and maintain a balance between accessibility and interoperability.

3.2.1.1 Conditions to join a data space

Admission policies within the General Terms and Conditions describe the conditions and eligibility criteria that third parties need to meet in order to join a data space. This entails identity verification, compliance check, technical requirements, access control setup, data quality standards or security policies. The data space governance authority must balance lowering barriers to entry (flexible rules) and promoting interoperability and data quality (strict rules).

Lowering barriers to entry means keeping the admission requirements accessible so that smaller companies, startups, or public agencies can also participate. If the rules are too strict, they may struggle to join because they lack the resources to meet all requirements—for example, a small logistics company might not be able to afford enterprise-grade certification if it were mandatory.

Promoting interoperability and data quality, on the other hand, requires rules that prevent fragmentation and ensure trust. If the requirements are too relaxed, participants may use incompatible technical formats, contribute poor-quality data, or introduce security risks. For instance, if each company used its own data schema without validation, data sharing across the data space would not work smoothly.

Once the candidate agrees to the General Terms and Conditions and meets all admission criteria, a process for accepting the General Terms and Conditions needs to be implemented. This can be realized by e.g. mutually signing an agreement or by letting the participant accept the General Terms and Conditions digitally.

The General Terms and Conditions should include requirements for verifying participants (e.g., strong identification) and setting requirements for the products and services available in the data space (e.g., language, data formats etc.). Depending on the Governance Framework of the data space, the Data Space Governance Authority must provide mechanisms to check if all admission/eligibility criteria are fulfilled by the candidate.

To join the data space, the candidate submits an application, detailing the role and intended use of the data space to the Data Space Governance Authority, which in turn reviews the applicant’s compliance with legal, technical, and operational standards, ensuring they meet all conditions. Alternatively, the Data Space Governance Authority can decide to refrain from an application process, but grant access to every participant that accepts the General Terms and Conditions and meets all conditions. Both options require constant monitoring that all participants act in accordance to the data spaces' rules and obligations. In both cases, the candidate needs to receive a notification once the Data Space Governance Authority decides on the application status.

In cases where the Data Space Governance Authority decides on denying access, the applicant should be informed about reasons.

As described in the Identity and Attestation building block, upon approval, credentials are issued, enabling participants to interface with the data space. The Data Space Registry, managed by the Data Space Governance Authority, supports the onboarding process by listing data space rules, Trust Anchors, but also conformity schemes formulated to assess compliance. The latter should be described in the data space’s Rulebook.

3.2.2 Participation management in operational and scaling phase

Successful integration is realized with verified access to the necessary data and resources with ensured technical interoperability. Technical onboarding by the data space governance authority is a process to enable new participants a seamless connection and instant readiness to actively engage in the data space. This can be for instance aided with initial data integration support by the data space governance authority to ensure data or services meet quality format and standards.

Active monitoring extends beyond initial onboarding, with continuous oversight to ensure participants adhere to data space policies and standards. This ongoing monitoring helps identify areas where the onboarding process can be improved, ensuring that the data space evolves to meet participant needs and emerging challenges. Feedback from participants is crucial in this process, enabling the data space governance authority to make data-driven adjustments to onboarding procedures, enhancing both security and participant satisfaction.

In the operational and scaling stage of a data space, the number of participants and use cases grows organically. The data space governance framework defines roles, responsibilities, and policies for data management, while the task of the data space governance authority is to enable seamless interaction among the participants. While use cases are executed and data products and data requests are published by the participants, the data space governance authority must carefully consider imbalances between supply and demand and consequently establish means to attract new participants to the data space to tackle the imbalances.

As the data space grows, the data space governance authority needs to regularly screen the governance framework and eventually adapt it to address emerging needs and challenges. These adaptations may arise from various factors, such as regulatory changes that impose new requirements on participants, or the strategic goal of expanding the data space to include new industries, companies, or countries with distinct regulations and standards. To successfully accommodate such expansions, the governance framework must remain flexible and inclusive, enabling the integration of diverse stakeholders while maintaining robust compliance, security, and interoperability. Potential adaptations must remain in line with the data space’s central mission/vision.

3.2.3 Offboarding

3.2.3.1 Reasons for offboarding

Different reasons for offboarding exist. In the regular case that a participant simply wants to exit the data space, the structured way of offboarding, described below applies.

A different reason might be the forced exit, caused e.g. by the participant not complying with the data spaces rules. In such a case, the Data Space Governance Authority needs to formulate rules and processes of how to enforce an exit.

Another scenario is the exception handling when a participating company e.g. goes bankrupt and cannot fulfill its obligations anymore. In such a case, the Data Space Governance Authority needs to inform all affected parties and enforce the exit.

A general overview of the onboarding and offboarding process in a data space is depicted in Figure 1.

3.2.3.2 Offboarding process

Offboarding participants requires careful consideration of obligations and responsibilities toward the data space and other participants. The governance framework, especially its Terms and Conditions, guides the exit process, ensuring a smooth transition while safeguarding the interests of all involved parties.

The offboarding process is designed to uphold the integrity and continuity of the data space by addressing issues such as data rights/holdings, data transfer, and termination of access. Exiting the data space requires proof that all contracts made with other participants have been fulfilled and no contractual obligations remain open. According to the General Terms and Conditions, the participant informs the data space governance authority about the desired exit of the data space. However it is stated in the Terms and Conditions, this can be realized digitally or in a written form. After checking whether all offboarding criteria mentioned below are met, the data space governance authority confirms the exit to the participant.

Criteria and elements that ensure careful and efficient offboarding are:

Documentation of exit procedures: Establishing and following a documented offboarding procedure that helps to ensure consistency and completeness in the process. This documentation should include detailed steps for data transfer, access termination, and contract closure. This entails for instance a continuous life cycle management of credentials, such as defined in the Identity and Attestation building block.
Data Transfer and Deletion Protocols: Implementing clear protocols for the secure transfer or deletion of data is essential. This includes ensuring that data is either transferred to another party or securely deleted, in accordance with the corresponding licenses agreed upon, but also with the data space policies and any applicable legal requirements.
Notification: Providing timely and clear notifications to all relevant parties about the participant’s exit helps prevent misunderstandings and ensures that all stakeholders are aware of possible changes. This communication should include details about data transfer, access termination, and any remaining obligations.
Verification of compliance: Conducting a thorough review to verify that all contractual and compliance obligations have been met before finalizing the offboarding process. This includes ensuring that any financial or legal obligations are settled and that all agreements with other participants are fulfilled.
Offboarding support: Offering support during the transition period to address any issues or questions that may arise. This can include providing assistance with data transfer or answering queries about remaining obligations.
Periodic Framework Reviews: Conducting periodic and thorough reviews of the data space governance framework and incorporating necessary updates in response to legislative changes helps ensure the ongoing sustainability and effectiveness of the data space ecosystem during the off- and onboarding process.

Catena-X example: best-practice for data space onboarding

Structured onboarding is essential for establishing secure, interoperable, and trusted participation in data spaces. The Catena-X initiative offers a clearly defined seven-step onboarding process, particularly tailored for large enterprises. These steps, as outlined in the Catena-X Onboarding Guide (v1.1), align closely with the participation management concepts described above.

1. Initial Contact & Opportunity Assessment

The onboarding journey begins with an initial assessment of whether participation in the data space aligns with an organization's strategic goals. This step often involves outreach via ecosystem networks, industry events, or onboarding service providers. Internal alignments focus on assessing organizational readiness, particularly in areas such as data management, IT capabilities, and legal compliance.

2. Business Value Definition

Organizations define which Catena-X use cases are most relevant to them, such as traceability, sustainability, or quality improvement. Establishing a clear value proposition not only justifies participation but also helps structure internal alignment across departments. This aligns with the DSSC Blueprint's emphasis on use case–driven participation and internal stakeholder engagement.

3. Organizational & Technical Preparation

Enterprises then prepare internally for technical and governance integration. Key activities include:

Appointing onboarding leads and integration coordinators.
Clarifying internal roles and processes for data sharing.
Deciding on the operating model for the required technical infrastructure, such as deploying the Eclipse Data Space Connector (EDC) in-house or via an Enablement Service Provider (ESP).

This stage ensures alignment with internal compliance, risk management, and IT governance frameworks.

4. Registration & Identity Verification

Participants must undergo formal registration and identity verification to establish trust within the ecosystem. In Catena-X, this involves:

Submitting organizational master data.
Verification via a Gaia-X-compliant Clearing House.
Receiving a Business Partner Number (BPN) and corresponding verifiable credentials for secure digital identity management.

This step operationalizes trust, one of the key pillars in data space governance.

5. Connector and Service Configuration

This stage focuses on setting up the technical components that enable secure and interoperable data exchange. Participants:

Install and configure the EDC.
Integrate registry services (e.g., for digital twins or asset metadata).
Define trust policies, access controls, and auditing functions.

The configuration must comply with ecosystem-wide technical and semantic standards to ensure interoperability.

6. Integration, Testing & Conformance

Before going live, enterprises perform thorough testing and validation:

Functional and technical tests verify system behavior and data compatibility.
Conformance checks ensure adherence to security, interoperability, and governance standards.
Optional certification by Conformity Assessment Bodies (CABs) may be pursued to formalize compliance and build trust among partners.

These activities correspond to the DSSC Blueprint’s recommendation to incorporate assurance mechanisms and lifecycle governance into participation management.

7. Go-Live & Ongoing Operation

After successful validation, participants become fully operational in the data space. They are expected to:

Maintain active system monitoring and incident response procedures.
Manage the lifecycle of credentials, connectors, and policy updates.
Engage in ecosystem-wide governance and use case evolution.

This phase reflects the operationalization of participation and emphasizes the importance of long-term commitment and adaptability within the data space.

4. Co-creation questions

Who are the stakeholders affected directly and indirectly by the data space operations?
Who of these stakeholders will actually participate within the data space?
What are the relevant identities in the data space?

5. Future topics

Internal communication streams - Vital for fostering collaboration, transparency, and adaptability within an organisation. They ensure swift information exchange, promoting employee engagement and overall organisational effectiveness.
Failure to incorporate participation management - it poses several risks, including data governance challenges, lack of accountability, reduced collaboration and, consequently, loss of trust. Without effective participation management, there is a risk of inadequate access control and a lack of alignment with organisational goals, compromising the overall integrity and utility of the data space.

6. Further reading

IDSA Rulebook
Sitra Rulebook for a Fair Data Economy Section 3 & 4
Data Sharing Coalition Blueprint V1.0
Towards a Holistic EU Data Governance - Sitra
JRC report: Mapping the landscape of data intermediaries
OECD: best practices of corporate governance
ISO/IEC 38500, Information technology - Governance of IT for the organization (access required)
CEN/CLC/JTC 25 Trusted Data Transaction - Part 2: Trustworthiness requirements (to be published shortly)

6.1 Documents and guidelines to implement the building blocks

7. Glossary

Term	Description
Candidate	A party interested in joining a data space as a participant.
Data space participant	A party committed to the governance framework of a particular data space and having a set of rights and obligations stemming from this framework. Explanatory text: Depending on the scope of the said rights and obligations, participants may perform in (multiple) different roles, such as: data space members, data space users, data space service providers and others as described in this glossary.
Data space	Interoperable framework, based on common governance principles, standards, practices and enabling services, that enables trusted data transactions between participants.
Data space governance authority (DSGA)	The body of a particular data space, consisting of participants that is committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework.
Data transaction	A structured interaction between data space participants for the purpose of providing and obtaining/using a data product. An end-to-end data transaction consists of various phases, such as contract negotiation, execution, usage, etc.
Data space role	A distinct and logically consistent set of rights and duties (responsibilities) within a data space, that are required to perform specific tasks related to a data space functionality, and that are designed to be performed by one or more participants. Explanatory text: The governance framework of a data space defines the data space roles. Parties can perform (be assigned, or simply ‘be’) multiple roles, such as data provider, transaction participant, data space intermediary, etc.. In some cases, a prerequisite for performing a particular role is that the party can already perform one or more other roles. For example, the data provider must also be a data space participant.

1. Summary

This building block aims to guide the data space governance authority in applying legal rules to a data space's design and operation. Specifically, it helps to properly define some participant roles and responsibilities, establish internal policies, and continuously monitor the regulatory compliance of a data space. In addition, it assists data space participants in understanding their rights and obligations under regulatory frameworks that are relevant to their role in a data space or to a specific data transaction. It also provides guidance on relevant legislation to those interested in setting up or joining a data space, including developers, policymakers and others.

Key elements of this building block include:

Triggers: Elements, criteria or events (e.g. data type, nature of participant or domain) that have occurred in a particular context of a data space and signals that a specific legal framework must or should be applied.
Data space requirements: Regulatory provisions that explicitly refer to data spaces.
Additional legal considerations: This element highlights other important legal considerations to be aware of when setting up or operating a data space, e.g. cybersecurity law.
LegalTech and RegTech: Technical tools or techniques designed to address certain legal requirements (such as smart contracts, secure processing environment, privacy-enhancing technologies etc.).
Regulatory Compliance Flowcharts: A step-by-step guidance helping to assess the applicability of a specific legal framework, operationalizing the triggers.

1.1 Questions that will be answered

What triggers (e.g. data type, participant category, or sectoral use case) determine which legal frameworks apply, and how are these operationalised through the Regulatory Compliance Flowcharts?
What data-space-specific requirements and additional legal considerations must be addressed, including Data Act interoperability obligations (Article 33), European Health Data Space Regulation (EHDSR) interoperability, cybersecurity, and the protection of intellectual property, trade secrets, and database rights?
How can LegalTech and RegTech tools support compliance implementation, enabling automated policy enforcement, contract execution, auditability, and “compliance by design” within the data space infrastructure?
How should data space governance authorities and participants demonstrate and maintain ongoing compliance, ensuring transparency, accountability, monitoring, and alignment with evolving EU and national legislation, standards, and guidance?

2. Purpose of the building block

The Regulatory Compliance building block encompasses a range of activities designed to ensure compliance with relevant regulatory frameworks. These activities involve understanding the legal requirements for data spaces and ensuring that all elements and functions of the data space comply with the regulatory framework. Regulatory compliance is an ongoing practice throughout the data space lifecycle.

Implementing the Regulatory Compliance building block requires the data space governance authority to identify the legal rules relevant to its operation.

The graphic below (Figure 1) shows a sector-agnostic mapping of legislation that could apply to data spaces, data space participants or the data and services offered by data space participants. It constitutes a preliminary analysis allowing for the identification of provisions relevant to the data space as a whole or in particular circumstances. An example of this is the AI Act, which is not likely to be directly applicable to a data space but could be relevant because data used to train high-risk AI systems or general-purpose AI systems may be sourced through data spaces. Depending on the context, the legal frameworks in Figure 1 may apply simultaneously.

While it falls outside the remit of the blueprint to provide an exhaustive listing of such legal frameworks, it is fitting to highlight a number of EU frameworks of particular importance to data spaces. However, it is up to the sectoral data spaces to do a further mapping and identify additional legal requirements from sectoral legislation*. In addition, relevant national legislation must be analysed accordingly.

For more information about key legislative frameworks for the development of data spaces, please check Legal Summaries [link to be added], providing a brief overview of a selection of relevant legislative frameworks, highlighting their importance for data spaces and considering how parties operating within a data space may be affected by them, as well as their present or future impact on data spaces. It complements other efforts of the DSSC in offering guidance and clarity on navigating data spaces through an increasingly complex legislative framework and is intended to be read in conjunction with the Blueprint, in particular - this building block. Legal Summaries are addressed to non-legal professionals and legal professionals looking for more information about EU legal frameworks applicable to data spaces.

In this building block, we decided to make an exception for the upcoming European Health Data Space Regulation (EHDSR) due to its impact on interoperability with other Common European Data Spaces, especially those relevant for health. More information about it can be found in the Data Space Requirements section. We also mention some sector-specific regulatory frameworks in the Examples of domain-specific use cases section.

*While ePrivacy Directive aims to provide for the harmonisation of the national provisions ensuring an equivalent level of protection of fundamental rights and freedoms, respecting at the same time the processing of personal data in the electronic communication sector, it may also apply to non-personal data. As explained in the recent EDPB Guidelines 2/2023, it is especially the case in the art. 5(3) ePrivacy Directive imposing on Member States the obligation to ensure that ‘the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user’ is only allowed on the basis of consent or necessity for specific purposes set out in that Article. According to the Guidelines, and following the CJEU Planet 49 judgment, “the protection applies to any information stored in such terminal equipment, regardless of whether or not it is personal data, and is intended, in particular, as is clear from that recital, to protect users from the risk that hidden identifiers and other similar devices enter those users’ terminal equipment without their knowledge”.

The main objectives of this building block revolve around:

Guiding data space initiatives on organising compliance with relevant legislation and ensuring that regulatory compliance is maintained throughout the lifecycle of data space development;
Supporting data space governance authorities in identifying relevant legal issues that may warrant the adoption of strategies, procedures and mechanisms to facilitate compliance within the data space;
Helping identify legal entitlements to data, and the rights and obligations of data space participants in relation to them;
Providing an overview of additional resources to help data spaces and data space participants assess their obligations under EU law (e.g., guidelines adopted by the European Commission or relevant competent authorities).

3. Elements and their key functions

The Regulatory Compliance building block is composed of three interrelated elements:

Triggers,
Data space requirements,
Additional legal considerations.

This building block focuses on analysing EU legal frameworks that are relevant to all data spaces. Given the possible impact of the European Health Data Space Regulation (EHDSR), as well as the planned implementing acts establishing interoperability of HealthData@EU infrastructure with other relevant data spaces, an analysis of the impact of the EHDSR, despite its sectoral nature, has been included in this legislative framework. You can read about the EHDSR impact on other (relevant) Common European Data Spaces in “Data Space Requirements” section of this building block.

3.1 The concept of triggers within a data space

Navigating the complexity of regulatory frameworks requires developing an approach to address the legal requirements stemming from them. This process starts with identifying elements, criteria, and/or events in the data space that flag the need, within particular contexts, to apply or comply with a particular framework.

An element, criterion or event that has occurred in a particular context of a data space is referred to as a 'trigger' for the purposes of this building block. It signals that a particular legal framework must or should be applied.

The triggers may be classified into different categories, such as:

Types of data: This category pertains to data that is available in a certain context. Depending on the precise kinds of data, it may trigger the need to comply with, for example, the GDPR or Data Act requirements.
Types of data space participants: Another category pertains to the legal status of participants. Depending on that legal status, such as being a public or specific private body, different regulations may apply. For example, the Data Governance Act regulates the operation of data intermediation services providers or data altruism organisations, which might be active as data space participants.
Types of use cases: A third category is about domains and/or use cases, such as health, mobility, etc., where domain-specific regulations would apply.

The figure presented below (Figure 2.) visualises the triggers that have been chosen as a priority for this version of the Blueprint. The criterion for selection was based on the necessity to address specific aspects of the operation of these elements within the governance or contractual framework of a data space.

3.1.1 Types of data

While the current classification of data types within the EU digital regulatory framework lacks methodological consistency, a key distinction is usually made between personal and non-personal data. However, it is important to remember that this distinction is imperfect and should often be subject to a broader discussion about the category that certain data will fall under.

While the EU data framework seeks to create a single market for data, increasing its availability for use in the economy and society, certain categories of data may be subject to particular protection regimes, imposing restrictions or specific conditions on access or processing. These “protection” regimes include:

Personal data protection: According to GDPR, Charter of Fundamental Rights of the European Union of the Treaty on the Functioning of the European Union (TFEU), the protection of natural persons regarding the processing of personal data is a fundamental right. Thus, personal data protection legislation aims to provide data subjects with relevant rights and adequate organisational and technical safeguards. Due to the particularly sensitive aspect of special categories of data, and significant risks to the fundamental rights and freedoms that their processing might pose, they enjoy specific protection under the GDPR. The special categories of data mentioned in Figure 3 are discussed in more detail in a subpage regarding types of data as a trigger.
Intellectual property and trade secrets: Besides the categories related to the potential identifiability of an individual, there are legal frameworks granting protection to certain datasets due to the specific attributes they possess. These are primarily intellectual property rights (namely copyright), sui generis database rights, or rights granted to trade secret holders. The classification of certain datasets as either personal or non-personal data or the nature of the ownership of (private/public) datasets does not impact the potential application of other protection regimes, in which the originality and individuality of the work, substantial investment or secrecy of a dataset, among others, are relevant. Thus, there might be datasets containing personal data (e.g., customer information) that are kept by an entity as a trade secret, or personal data databases that enjoy the copyright and/or sui generis database protection. In these situations, the data protection principles and data subjects’ rights provided by the GDPR will still be applicable.

The EU data legislation (notably Data Act, Data Governance Act, Open Data Directive, Regulation on the free flow of non-personal data) is meant to bring about a shift in the accessibility of data, opening up considerably more data for use by a variety of parties. That being said, the “access” regime largely depends on the nature of a data holder, imposing different requirements on the access to:

Privately-held data: This includes categories of data governed by specific legal frameworks, mainly the Data Act. It imposes requirements on certain entities, such as the obligation to make product and related services data (IoT data) accessible to users (as specified in Article 3 of the Data Act) or to provide data based on an exceptional need expressed by a public sector body (Business-to-government; B2G) (as specified in Article 14 of the Data Act).
Data held by public sector bodies (PSB): These types of data can be distinguished based on their level of openness to the general public. High-value datasets are of particular importance for society, the environment and the economy, therefore they can be re-usable for any purpose. On the other hand, the Data Governance Act (DGA) outlines the conditions under which public sector bodies can allow the reuse of certain protected data (for example, data protected on grounds of commercial confidentiality, including business, professional and company secrets).

Knowing that navigating a long document of descriptions can be challenging, we direct the reader to the sub-pages of the Blueprint, as we want to keep this building block accessible and user-friendly. Within the subpages, the reader will be able to see the description and assessment of impact of the legal requirements concerning different types of triggers.

Click here if you want to read more about data as a trigger: Types of data

3.1.2 Types of participants

Some data space participants will simultaneously be entities whose very existence or specific functions in the ecosystem have been regulated by law and who may have specific requirements imposed on them. The data space participants fall into two main groups: private and public entities. EU regulations, both horizontal and sectoral, as well as various national laws, impose specific rights and obligations depending on whether an entity operates as a public sector organisation, a private company, or a consumer. In the latest EU data regulatory frameworks, the distinction between private and public entities is becoming blurred, introducing rules that apply to entities from both sectors under certain conditions. This is evident for, for instance, data intermediation service providers under the Data Governance Act (DGA). When they facilitate the sharing of non-public sector data to establish commercial relationships, they are subject to the same legal regime as any other data intermediary, provided they offer a ‘service’. Therefore, the dichotomy of participant types should be presented within the spectrum below, from the types of participants considered (most likely) to fall under the category of private entities on the left side (such as gatekeepers), through the borderline or uncertain cases in the middle (such as data altruism organisations), to the types of participants falling under the category of public entities (such as public sector bodies).

Click here if you want to read more about participant as a trigger: Types of participants

3.1.3 Sector-specific use cases

Although several EU regulations apply broadly to data spaces, specific sectoral regulations may also impact the development of a particular use case. While a complete catalogue of all use cases for individual sectoral data spaces is not feasible, we highlight selected opportunities below for using data to develop different technologies, using the infrastructure of common European data spaces and noting specific legal requirements that may be triggered.

In some situations, it will be important to analyse the sectoral regulations and the broader, horizontal framework. A good example of mapping the legal landscape for developing specific use cases could be the overview prepared by the Green Deal Data Space.

Click here if you want to read more about examples of domain-specific use cases: Types of Use Cases

3.2 Data space requirements

The category of data space requirements encompasses legislation that directly regulates data spaces. While the current list of such regulations is limited, there could be various legislative proposals aimed at specific sectoral data spaces, such as the case of the proposed European Health Data Space. In the context of data space requirements, the provisions from the legislative frameworks described below focus on ensuring interoperability both within and between data spaces.

3.2.1 Data Act

A key piece of legislation that directly regulates data spaces is the Data Act. This act requires data space participants who offer data or data services to meet essential requirements to ensure data interoperability, effective data-sharing mechanisms, and the proper functioning of Common European Data Spaces.

Whereas the Data Act specifically targets participants of data spaces, the obligations of Article 33 of the Data Act, by their very nature, should be considered as intrinsically linked to the infrastructure and governance framework of the data space. The essential requirements to facilitate interoperability should be addressed by the data space governance authority at the level of the data space, taking into account available (harmonised) standards and any potential further delegated acts or guidance adopted by the European Commission. Adequate implementation of the building blocks related to Data Interoperability (Data Models, Data Exchange and Provenance & Traceability building blocks) should also ensure compliance with the provisions of Article 33 of the Data Act. Currently, however, on the basis of art. 3(4) Data Act, the Commission requested relevant European standardisation organisations to draft harmonised standards that satisfy the essential requirements laid down in paragraph 1 of this Article.

3.2.1 European Health Data Space Regulation

The European Health Data Space Regulation is currently the only legal instrument setting in place a common European data space. It aims to establish a pan-European infrastructure for trustworthy health data sharing for primary and secondary use. In the context of secondary use, the Regulation also addresses the importance of connecting various Common European Data Spaces, especially by providing interoperability between the European Health Data Space and data spaces from other sectors, such as the environmental, social, and agricultural sectors that may be relevant for additional insights on health determinants. According to art. 52 (12) EHDSr, Member States and the Commission shall seek to ensure interoperability of HealthData@EU with other relevant Common European Data Spaces as referred to in the Data Governance Act and Data Act. In addition, by implementing acts, the European Commission may set out common specifications for the interoperability and architecture of HealthData@EU with other relevant Common European Data Spaces.

3.3 Additional legal considerations

In addition to the legal frameworks outlined above relevant to specific data types, participants and domains, it's crucial to consider additional legal aspects stemming from, for instance, cybersecurity legislative frameworks. Ensuring robust cybersecurity measures is essential to protect data integrity and privacy promotes fair access and innovation within the data space. These considerations play a vital role in maintaining a secure and equitable environment for data management and sharing.

Cybersecurity law

The NIS-2 Directive lays down risk management measures and reporting obligations building resilience and incident response capacities across the Union, with a view to achieve a high common level of cybersecurity.

It applies to medium and large entities, as well as to to an entity of any size that:

Is a public administration entity,
Is the sole provider of a service in a member state,
Could have an impact on public safety, security or health if its services are disrupted,
Could induce systemic risks or have cross-border impacts if its services are disrupted,
Is a critical entity because of its importance at the regional or national level for its sector or type of service,
Provides services by public electronic communications networks, publicly available electronic communications services, trust service providers, or top-level domain name registries and domain name system service providers.

The directive introduces also the new classification of the essential and important entities, related to the covered organization's industry. Entities of any size that meet any of the first five criteria, and medium-size entities that meet the sixth criteria, are considered essential entities. For example, essential entities are covered organizations in the energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, public administration and space industries. Important entities, on the other hand, are covered organisations in, for example, waste management, chemical production and distribution, manufacturers of medical devices, electrical equipment, transport equipment, digital providers of online marketplaces, search engines and social networking platforms.

While certain data space members or participants might fall under the categories of entities for highly critical or other critical sectors (such as producers of electricity, operators of Intelligent Transport Systems, healthcare providers, trust service providers), and therefore, will be obliged to implement relevant cybersecurity requirements, it should be further analysed whether data spaces as a whole can be considered as one of the critical infrastructures itself in one of the mentioned sectors. If that is the case, it is important to remember that the provisions of the Directive are primarily addressed to be transposed by the Member States on a national level. Entities falling within the scope of this Directive shall be considered to fall under the jurisdiction of the Member State in which they are established (with several exceptions). However, respective entities can prepare already for the requirements laid down in the art. 21 (2) NIS-2 with the minimum catalogue of risk-management measures, such as:

policies on risk analysis and information system security;
incident handling;
business continuity, such as backup management and disaster recovery, and crisis management;
supply chain security;
security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;
policies and procedures to assess the effectiveness of cybersecurity risk-management measures;
basic cyber hygiene practices and cybersecurity training;
policies and procedures regarding the use of cryptography and, where appropriate, encryption;
human resources security, access control policies and asset management;
the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.

For more information about compliance requirements laid down in NIS-2: nis2-directive-101-chart.pdf (iapp.org)

One of the category listed in the Annex II of NIS-2 Directive concerns “digital providers”, namely providers of online marketplaces, online search engines, and social networking services platforms. In the light of this, it should be further examined whether a data space can be considered a “provider of online marketplace”. According to the Unfair Commercial Practices Directive, “online marketplace” means a service using software, including a website, part of a website or an application, operated by or on behalf of a trader which allows consumers to conclude distance contracts with other traders or consumers. Although most data spaces will be considered as enablers of B2B relations in the context of data transactions, there may be domains where ''consumers'' will also wish to access data (for example, the Green Deal Data Space allows consumers of relevant resources to participate in specific use cases supported by the data space, targeting objectives at different levels and sharing in the value created through a variety of business models). There are no technical or legal restrictions for a data space to allow only the professionally oriented transactions, thus such consideration remains open to explore.

3.4 Legal Tech and RegTech in the context of data spaces

Within a data space ecosystem, participants assume distinct roles which may come with a number of general or specific legal requirements. The absence of established compliance practices for new legislative frameworks related to the data economy adds complexity, particularly given their interaction with the pre-existing body of regulation (both with a general or digital economy-specific scope, sector-specific and national laws).

Given this complexity and the numerous interconnected decisions within a data space, efficiently addressing certain requirements may warrant using technical tools, aside from the commonly deployed organisational and contractual measures.

3.4.1 Legal Tech

The term “legal tech” has no settled legal definition but broadly refers to the use of technology to deliver or support legal services. There are three stages of its development:

Legal Tech 1.0: tools that assist legal professionals with routine tasks;
Legal Tech 2.0: systems that automate specific legal processes;
Legal Tech 3.0: technologies that employ artificial intelligence to perform autonomous decision-making.

For the purposes of data spaces, Legal Tech 2.0 is the most relevant. Unlike Legal Tech 1.0, which remains largely administrative, or Legal Tech 3.0, which raises unresolved accountability issues, Legal Tech 2.0 provides practical applications such as contract automation, licensing enforcement, and compliance monitoring. By embedding legal obligations into technical infrastructures, these tools enhance trust, efficiency, and compliance within data-sharing ecosystems.

3.4.1.2 Categories of Legal Tech per functionality

Automated Contract Management Systems: tools translating contractual terms into machine-readable workflows, ensuring licensing conditions, access rights, and confidentiality clauses are consistently applied. By reducing negotiation time and costs, while enabling real-time monitoring and flagging of non-compliance, they turn contracts into operational instruments that govern day-to-day data flows and produce audit-ready compliance reports.
Smart Contracts: Smart contracts embed compliance directly into data-space infrastructure by self-executing and enforcing terms when preset conditions are met. Built on DLT, they automate data-sharing agreements, providing features like restricting use, triggering payments, and supporting breach handling via auditor-based voting. While they can improve transparency and efficiency, their immutability requires governance to ensure reversibility and alignment with EU obligations.
Compliance Automation Platforms: platforms automating GDPR-related workflows such as privacy-by-design, impact assessments, and record-keeping. In data spaces, they would ensure that contractual execution remains legally sound, transparent, and demonstrable to supervisory authorities, while reducing manual compliance effort.

3.4.2 Legal Tech vs RegTech

While Legal Tech broadly refers to the use of technology in the delivery of legal services, RegTech (regulatory technology) focuses specifically on embedding regulatory compliance into digital infrastructures.

RegTech (“regulatory technology”)refers to the use of digital technologies and especially data analytics and automation, to make regulatory monitoring, reporting, and compliance more effective and efficient for firms and regulators. Typical RegTech tools include eKYC/identity verification and screening, transaction monitoring, regulatory reporting & filings, policy and obligation management, and audit capabilities, which operationalize compliance-by-design.

In the context of data spaces, RegTech tools serve as the operational backbone for ensuring that legal norms are directly enforceable within day-to-day data transactions.

3.4.2.1 Categorisation of RegTech tools: how the tool’s functionality supports compliance within a data space? (work in progress)

3.4.2.1.1 Table 1: RegTech tools that are not (yet) part of the DSSC Toolbox

Core information			Application domain			Other
Name	Description	Purpose	Functional	Geographical	Sector	Type
My DATA Control Technologies (Fraunhofer IESE)	Software from Fraunhofer IESE that enforces data-usage policies at system interfaces, filtering/masking data and applying purpose, time, and context limits to support data sovereignty in data spaces.	Attaches and enforces machine-readable usage rules so shared data is released only as permitted (e.g., masked/anonymized, time-/purpose-limited), supporting compliant sharing in data spaces.	Usage Control, Policy enforcement, Compliance	EU data sharing contexts	Cross Industry; manufacturing, banking, public sector	Commercial
IDSA Rulebook	A common rulebook that defines how organisations can set up and run a trustworthy data space	Provides mandatory and optional rules, processes and legal guidance so participants can align and assess conformance while setting up a data space	Provides governance framework and legal templates (roles, agreements, compliance rules)	Global	Cross-sectorial	Open Source
ODRL (Open Digital Rights Language)	A standard language for writing machine-readable rules about data use, what’s allowed, forbidden, or required, so those rules can travel with the data and be checked by different systems.	Expresses interoperable usage-control policies that travel with data and can be enforced across participants.	Policy language	Global	Cross Industry; media, market data, privacy & consent, data spaces	Open Source
Alyne	A cloud-based and AI emabled GRC (Governance, Risk, Compliance.platform with a large, pre-mapped control library and templates to manage risks, map obligations to standards/laws, run assessments, and produce reports.	Streamlines regulatory compliance and risk management through standardised protocols, automated assessments Nd reporting	Compliance automation	Global	Cross Industry; finance, cybersecurity, IT, regulated enterprises	Commercial
LegalRuleML	A standard that represents legal norms and rules (from laws, regulations, contracts, case law) with features for obligations, exceptions, time/jurisdiction, and provenance, so rules are machine-readable and suitable for automated reasoning and compliance checking.	Encodes legal and policy logic in a standardised format so systems can evaluate applicability, compare interpretations and automate compliance across organisations	Machine- readable legal rules	Global	Cross Industry; finance, governance, public sector, RegTech	Open Source

3.4.2.1.2 Table 2: RegTech tools that are part of the DSSC Toolbox

Tool	Functional Role(s)	Regulatory Domains	Goal	Relevant Building Block
iSHARE Participant Registry	Authorisation, Authenticatio Identity Management Trust Registry, Data sovereignty, Interoperability	GDPR Data Act eIDAS	Maintains trusted participant identities and compliance levels	Participation Management
iSHARE Authorization Registry	Authorization, Trust, Authenticatio Policy Enforcement Data sovereignty, Interoperability	GDPR Data Act	Manages and verifies delegation and access rights within the data sharing ecosystem	Technical Building Block - Identity & Attestation Management
Gaia-X Registry	Identity & Attestation, Registry, Accessibility	eIDAS GDPR	Compliance assessment, Stores definitions and trust anchors for credential validation
Gaia-X Compliance Service	Compliance Assessment, Verification, and Labelling, Trust, Validation, Data Policy Enforcement and Negotiation	GDPR NIS2 eIDAS	Issues signed compliance credentials, compliance assessment, Automation of the data space governance and conformity assessment procedures
Sitra Rulebook model	Offers Templates, Contract/Rulebook Creation, checklists, Ethical maturity models,	GDPR Data Act DGA	Provides governance frameworks, templates for onboarding, governance models, accession agreements ToU, terms and conditions and legal scaffolding, simplifies collaboration and data sharing	Legal Building Blocks- Regulatory Compliance, Contractual Framework Business Building Blocks Governance Building Blocks Technical Building Blocks -Value creation
PETSpaces	Secure Processing and Computations, Privacy enhancement, Data sovereignty, Regulatory compliance	GDPR	Enables privacy-enhancing computations in Data Spaces (PETs), uses anonymization techniques, allows participants to process and compute encrypted data, preserving data privacy and enhancing data owners’ sovereignty over their data	Technical Building Blocks– Trust Framework, Access & Usage, Value creation
TNO Security Gateway (TSG)	Secure Processing, Auditability, Data sovereignty, Trusted Data Sharing	NIS2 GDPR	Ensures secure data transfer and exchange of information with compliance-focused control	Technical Building Blocks - Data Models, Provenance, Identity & Attestation, Publication and Discovery
Apache Syncope	Digital Identities & Attestation, Access Management, API Management	GDPR	Manages identities and provisioning in enterprise settings	Identity and Attestation Management
Fair Data Publisher	Registry, Data Space connector & Data Intermediary, Data Publication & Discovery, Access Control, Contract Negotiation	Data Act GDPR	A bridging service for publishing and accessing asset meta in the FDO (FAIR Digital Object) global data space data from within an EDC or AAS-based data space	Technical Building Blocks – Data Models, Data Exchange, Data, Service, Offerings Descriptions
Ocean Enterprise Catalogue	Registry, Discovery, Traceability, Smart Contracts, Incentivizes participation through its federated operation	GDPR Data Act	Fully self-sovereign: distributed, tamper-proof, self-sovereign storage of Data, Services, and Offerings Descriptions. Metadata records are stored as signed Verifiable Credentials utilizing Ocean Enterprise smart contracts.  Uses VCs and DLT to catalog offerings and ensure traceability.	Technical Building Blocks – Data Models, Provenance & Traceability, Publication & Discovery
Data Privacy Vocabulary (DPV)	Consent management, Compliance Verification	GDPR DGA	Supplies a semantic framework to describe personal data categories, processing purposes and legal bases. Facilitates interoperability and automated compliance checking	Data Space Offerings? Intermediaries and Operators
ODRL (Open Digital Rights Language)	Licensing, Compliance, Usage restrictions	GDPR Data Act DGA	Enables contractual and regulatory conditions (e.g., licensing, purpose limitation, disclosure restrictions) to be encoded and enforced in data spaces. Supports data sovereignty and “compliance by design.”	Technical Building Block – Access and Usage Policies Enforcement Legal Building Blocks
LegalRuleML	Legal rule encoding Compliance automation	GDPR Data Act DGA	Represents legal norms, rights, obligations, and prohibitions in machine-readable form. Facilitates automation of legal compliance checks, translation of contracts into computable rules, and verifiable governance in data-sharing ecosystems.	Legal Building Blocks – Regulatory Compliance, Contractual Framework Governance Building Blocks

3.5 Regulatory Compliance Flowcharts

As highlighted above, regulatory compliance within a data space requires not only mapping relevant regulations but also identifying triggers, data space requirements, or other legal considerations. These help determine which aspects, elements, or criteria in the development or operation of a data space must be aligned with specific legal provisions.

The recently announced European Data Union Strategy (EDUS) aims to streamline existing data rules, making the EU legal framework clearer and more coherent for businesses and administrations, thereby enabling seamless data flows, including within data spaces.

In recent years, there has been a surge in EU digital legislation, complicating the interaction between older frameworks like the GDPR and newer instruments such as the Data Act, Data Governance Act, and AI Act. While GDPR implementation has been supported by extensive guidance (e.g., from the WP29, the European Data Protection Board (EDPB), and case law), there is limited support for the practical application of newer laws, particularly in the context of Common European Data Spaces. Few resources exist on regulatory interaction or definitions (e.g., ENISA, 2024; AEPD, 2023; Bobev et al., 2023; Lalova-Spinks et al., 2023).

A key solution to this issue is the development of user-friendly tools for the data-sharing ecosystem that guide specific actors (namely data space participants) through the rights and obligations imposed by relevant regulatory frameworks. This need is heightened by the multidimensional nature of data spaces, which complicates the allocation of legal responsibility - for example, fulfilling Article 33 of the Data Act, applying the GDPR accountability principle, or navigating liability rules for data collection and use, particularly in the cybersecurity context.

In this context, the DSSC developed Regulatory Compliance Flowcharts (“decision trees”). These flowcharts provide simplified guidance for both data space governance authorities and participants, helping them identify relevant triggers in data space development and operation that must be addressed in an appropriate manner.

Once the applicability of a given framework or requirement is identified, the flowcharts refer the entity to a potential “checklist” with additional questions to consider in order to effectively address the requirements associated with the trigger. In some cases, the flowcharts may also link to additional resources to help deepen understanding of compliance requirements. However, they do not aim to definitively assign roles. Instead, they provide guidance on appropriate organizational, legal, or technical tools that can help relevant entities independently determine their responsibilities.

The visuals presented below are not a reflection of decisions that specific entities must make. Rather, they illustrate how the existence of particular triggers might condition the subsequent actions required (Figures 7–10).

The Regulatory Compliance Flowcharts will be complemented by the Legal Compass - a step-by-step guidance tool designed to assess the applicability of specific legal frameworks (including the GDPR and its interplay with the DA and DGA) and to identify the requirements relevant to particular entities. Its main objective is to operationalise the triggers and structure the interplay of the elements outlined above.

The Legal Compass will be available as part of the final version of the DSSC Toolbox.

4. Co-creation questions

How does the data space manage legal aspects such as privacy policy, data protection policy and cybersecurity policy?
Which legislative frameworks/triggers must be considered for the internal rules?
Do any of the parties involved in the data space function as a data intermediary or collaborate with one?
Are there intermediaries or gatekeepers involved in the data transactions of this data space?

5. Future topics

Given the complexity of data spaces, which involve multiple actors and fit into a variety of existing legal and emerging digital policy frameworks, it is challenging to analyse each regulation in a way that sets uniform obligations for all common European data spaces. Therefore, future versions will continue to provide more user-centric guidance to help navigate the legal landscape.

6. Further reading

European Commission (2024), Second staff working document on data spaces | Shaping Europe’s digital future. https://digital-strategy.ec.europa.eu/en/library/second-staff-working-document-data-spaces
Dietrich M., Gutiérrez David M., (2024), D4.2 Final Governance Requirements and Endorsed Governance Scheme, Green Deal Data Space and Foundation and its Community of Practice (GREAT). D4.2-Final-Governance-Requirements-and-Endorsed-Governance-Scheme.pdf (greatproject.eu)
Drexl, J. (2018), Data Access and Control in the Era of Connected Devices. Data Access and Control in the area of connected devices (beuc.eu)
Leistner, M., & Antoine, L. (2022). IPR and the Use of Open Data and Data Sharing Initiatives by Public and Private Actors. SSRN Electronic Journal. https://doi.org/10.2139/ssrn.4125503
Bobev, T., Dessers, V. K., Ducuing, C., Fierens, M., Palumbo, A., Peeters, B., & Stähler, L. (2023). White paper on the definition of data intermediation services. SSRN. https://doi.org/10.2139/ssrn.4589987
Zingales, N. (2021). Data Collaboratives, Competition Law and the Governance of EU Data Spaces (SSRN Scholarly Paper 3897051). https://doi.org/10.2139/ssrn.3897051
Zenner K., Scott Marcus J., Sekut K., (2024) A dataset on EU legislation for the digital world. (n.d.). https://www.bruegel.org/dataset/dataset-eu-legislation-digital-world
De Noyette E., (2024), Trade Secrets in the EHDS. Trade secrets in the EHDS - CiTiP blog (kuleuven.be)
Penedo, A. C. (2024). The Regulation of Data Spaces under the EU Data Strategy: Towards the ‘Act-ification’ of the Fifth European Freedom for Data? European Journal of Law and Technology, 15(1). https://ejlt.org/index.php/ejlt/article/view/995
Mylly, U.-M. (2024). Trade secrets and the Data Act. IIC - International Review of Intellectual Property and Competition Law, 55(3), 368–393. https://doi.org/10.1007/s40319-024-01432-0
Centre for Information Policy Leadership (2024), Data Sharing Obligations Under the DMA: Challenges and Opportunities. data_sharing_obligations_under_the_dma_-_challenges_and_opportunities_-_may24.pdf (informationpolicycentre.com)
Directorate-General for Research and Innovation (European Commission) (2024). Improving access to and reuse of research results, publications and data for scientific purposes: Study to evaluate the effects of the EU copyright framework on research and the effects of potential interventions and to identify and present relevant provisions for research in EU data and digital legislation, with a focus on rights and obligations. Publications Office of the European Union. https://data.europa.eu/doi/10.2777/633395
Wisselink, Dr. F., Steinbuss, S., & Koen, P. (2024). Data Spaces for the Al Act – Analysis of the Standardization Request Regarding the European Al Act in the Context of Data Spaces (Version 1.0). International Data Spaces Association. https://doi.org/10.5281/ZENODO.10839129
Publications Office of the European Union., Capgemini Invent., & European Data Portal. (2020). High-value datasets: Understanding the perspective of data providers. Publications Office. https://data.europa.eu/doi/10.2830/363773
The new “Generative AI and Data Spaces" white paper of the Strategic Stakeholder Forum is now available - News - Data Spaces Support Centre
Fierens M, Pandit HJ, Tamo-Larrieux A and Garcia K, ‘A Solid Use Case to Empower and Protect Data Subjects: Responsibilities under GDPR for Governance of Personal Data Stores’ (2025) Computer Law & Security Review 106133 https://doi.org/10.1016/j.clsr.2025.106133
Pastor Sempere, C. (2025). The Legal Framework for New Digital Assets, Identities, and Data Spaces. Introduction. In C. Pastor Sempere (Ed.), Governance and Control of Data and Digital Economy in the European Single Market: Legal Framework for New Digital Assets, Identities and Data Spaces (pp. 3–21). Springer Nature Switzerland. https://doi.org/10.1007/978-3-031-74889-9_1
Richter, H. (2023). Looking at the Data Governance Act and Beyond: How to Better Integrate Data Intermediaries in the Market Order for Data Sharing. GRUR International, 72(5), 458–470. https://doi.org/10.1093/grurint/ikad014
Marcus, J. S. (2022). Achieving Joined-Up Digital Policy in the EU (SSRN Scholarly Paper 4074019). Social Science Research Network. https://doi.org/10.2139/ssrn.4074019
Fierens, M. (2025). Initiating interdisciplinary research for future-proof data protection in the context of Data Spaces and semantic interoperable data sharing.
Lundahl, J. (n.d.). Report on existing regulatory frameworks and governance mechanisms for mobility data sharing.
Ryan, M., Gürtler, P., & Bogucki, A. (2024). Will the real data sovereign please stand up? An EU policy response to sovereignty in data spaces. International Journal of Law and Information Technology, 32, eaae006. https://doi.org/10.1093/ijlit/eaae006
Legal Summaries [LINK TO TO BE ADDED]
Brodahl L., De Boel L., Jużak J., (2022), Belgian Data Protection Authority Clarifies Key Rules on Biometric Data Processing. Belgian Data Protection Authority Clarifies Key Rules on Biometric Data Processing | The Data Advisor (wsgrdataadvisor.com)
Agencia Española Protección de Datos (2023), Approach to Data Spaces From GDPR Perspective. approach-to-data-spaces-from-gdpr-perspective.pdf (aepd.es)
European Union Agency for Cybersecurity (2024), Engineering Personal Data Protection in EU Data Spaces. (n.d.). [Report/Study]. https://www.enisa.europa.eu/publications/engineering-personal-data-protection-in-eu-data-spaces ENISA report
Palumbo A., (2024) Data Spaces As Enablers For AIA Compliance, https://data-week.eu/wp-content/uploads/2024/06/FINAL-slides_Session-Value-Creation.pdf
European Data Protection Board (2025), Guidelines 01/2025 on Pseudonymisation, edpb_guidelines_202501_pseudonymisation_en.pdf
Relevant guidelines, recommendations and best practices are issued by the European Data Protection Board and national data protection authorities. The latter are tasked with supervision of compliance.

7. Glossary

Term	Definition
Data	any digital representation of acts, facts or information and any compilation of such acts, facts or information, including in the form of sound, visual or audiovisual recording; (DGA Article 2(1)) Explanatory text: The definition is the same in the Open Data Directive and the Data Act.
Data sharing	the provision of data by a data subject or a data holder to a data user for the purpose of the joint or individual use of such data, based on voluntary agreements or Union or national law, directly or through an intermediary, for example under open or commercial licences subject to a fee or free of charge; (DGA Article 2(10)) Explanatory text: In the context of data spaces, data sharing refers to a full spectrum of practices related to sharing any kind of data, including all relevant technical, financial, legal, and organisational requirements.
Data holder	a legal person, including public sector bodies and international organisations, or a natural person who is not a data subject with respect to the specific data in question, which, in accordance with applicable Union or national law, has the right to grant access to or to share certain personal data or non-personal data; (DGA Article 2(8)) a natural or legal person that has the right or obligation, in accordance with this Regulation, applicable Union law or national legislation adopted in accordance with Union law, to use and make available data, including, where contractually agreed, product data or related service data which it has retrieved or generated during the provision of a related service;(DA Article 2(13)) Explanatory text: In general context we use data holder within the meaning of DGA Art. 2(8) and in case the word data holder is used in the context of DA (IoT data), we identify it with DA at the end of the term. Please note that data rights holder has a specific and different meaning than data holder and is used especially in data transactions.
Data recipient (Data Act)	a natural or legal person, acting for purposes which are related to that person’s trade, business, craft or profession, other than the user of a connected product or related service, to whom the data holder makes data available, including a third party following a request by the user to the data holder or in accordance with a legal obligation under Union law or national legislation adopted in accordance with Union law; (DA Article 2(14)) Explanatory text: Data recipient has a broader (not limited to IoT) meaning in the context of data transactions enabled by data space: ''A transaction participant to whom data is, or is to be technically supplied by a data provider in the context of a specific data transaction''. When we use data recipient in the meaning of DA (IoT data), we specify it with DA at the end of the word.
Data user	a natural or legal person who has lawful access to certain personal or non-personal data and has the right, including under Regulation (EU) 2016/679 in the case of personal data, to use that data for commercial or noncommercial purposes; (DGA Article 2(9))
Data intermediation service	a service that is legally defined in the Data Governance Act and enforced by national agencies. An operator in a data space may qualify as a data intermediation service provider, depending on the scope of the services. DGA definition (simplified): ‘Data intermediation service’ means a service which aims to establish commercial relationships for the purposes of data sharing between an undetermined number of data subjects and data holders on the one hand and data users on the other through technical, legal or other means, including for the purpose of exercising the rights of data subjects in relation to personal data. (DGA Article 2 (11)) Explanatory text: Services that fall within this definition will be bound to comply with a range of obligations. The most important two are: (1) Service providers cannot use the data for other purposes than facilitating the exchange between the users of the service; (2) Services of intermediation (e.g. catalogue services, app stores) have to be separate from services providing applications. Both rules are meant to provide for a framework of truly neutral data intermediaries.
Data altruism	the voluntary sharing of data on the basis of the consent of data subjects to process personal data pertaining to them, or permissions of data holders to allow the use of their non-personal data without seeking or receiving a reward that goes beyond compensation related to the costs that they incur where they make their data available for objectives of general interest as provided for in national law, where applicable, such as healthcare, combating climate change, improving mobility, facilitating the development, production and dissemination of official statistics, improving the provision of public services, public policy making or scientific research purposes in the general interest; (DGA Article 2(16))
Personal data	any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; (GDPR Article 4(1))
Non-personal data	data other than personal data; (DGA Article 2(4))
Data subject	an identified or identifiable natural person that personal data relates to. (GDPR Article 4(1)) Explanatory text: Data subject is implicitly defined in the definition of ‘personal data’. In the context of data spaces we use the broader term data rights holder, to refer to the party that has (legal) rights and/or obligations to use, grant access to or share certain personal or non-personal data. For personal data, this would equal the data subject.
Consent	any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her; (GDPR Article 4(11))
Permission	giving data users the right to the processing of non-personal data; (Data Governance Act Article 2(6))
DMA Gatekeeper	an undertaking providing core platform services, designated by the European Commission if: it has a significant impact on the internal market; it provides a core platform service which is an important gateway for business users to reach end users; and it enjoys an entrenched and durable position, in its operations, or it is foreseeable that it will enjoy such a position in the near future (art. 3 (1) DMA). An undertaking shall be presumed to satisfy the respective requirements in paragraph 1: as regards paragraph 1, point (a), where it achieves an annual Union turnover equal to or above EUR 7,5 billion in each of the last three financial years, or where its average market capitalisation or its equivalent fair market value amounted to at least EUR 75 billion in the last financial year, and it provides the same core platform service in at least three Member States; as regards paragraph 1, point (b), where it provides a core platform service that in the last financial year has at least 45 million monthly active end users established or located in the Union and at least 10 000 yearly active business users established in the Union, identified and calculated in accordance with the methodology and indicators set out in the Annex; as regards paragraph 1, point (c), where the thresholds in point (b) of this paragraph were met in each of the last three financial years. (art. 3 (2) DMA).
Core platform service	a service that means any of the following: online intermediation services; online search engines; online social networking services; video-sharing platform services; number-independent interpersonal communications services; (f) operating systems; web browsers; virtual assistants; cloud computing services; online advertising services, including any advertising networks, advertising exchanges and any other advertising intermediation services, provided by an undertaking that provides any of the core platform services listed in points (1) to (9);
Public sector body	the State, regional or local authorities, bodies governed by public law or associations formed by one or more such authorities, or one or more such bodies governed by public law (art. 2 (17) DGA).
Sui Generis Database Right	right for the maker of a database which shows that there has been qualitatively and/or quantitatively a substantial investment in either the obtaining, verification or presentation of the contents to prevent extraction and/or re-utilization of the whole or of a substantial part, evaluated qualitatively and/or quantitatively, of the contents of that database (art. 7 Directive 96/9/EC Of The European Parliament And Of The Council of 11 March 1996 on the legal protection of databases).
Trade Secret	information which meets all of the following requirements: it is secret in the sense that it is not, as a body or in the precise configuration and assembly of its components, generally known among or readily accessible to persons within the circles that normally deal with the kind of information in question; it has commercial value because it is secret; it has been subject to reasonable steps under the circumstances, by the person lawfully in control of the information, to keep it secret. (art. 2 (1) Trade Secrets Directive).
High-risk AI system	'AI system’ means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments (Art. 3 (1) AIA). AI system shall be considered to be high-risk where both of the following conditions are fulfilled: the AI system is intended to be used as a safety component of a product, or the AI system is itself a product, covered by the Union harmonisation legislation listed in Annex I; the product whose safety component pursuant to point (a) is the AI system, or the AI system itself as a product, is required to undergo a third-party conformity assessment, with a view to the placing on the market or the putting into service of that product pursuant to the Union harmonisation legislation listed in Annex I (art. 6 (1); art. 6 (2) AIA). Explanatory text: In addition to the high-risk AI systems referred above, AI systems referred to in Annex III shall be considered to be high-risk, such as: biometrics, in so far as their use is permitted under relevant Union or national law; critical infrastructures (e.g. transport), that could put the life and health of citizens at risk; educational or vocational training, that may determine the access to education and professional course of someone’s life (e.g. scoring of exams); safety components of products (e.g. AI application in robot-assisted surgery); employment, management of workers and access to self-employment (e.g. CV-sorting software for recruitment procedures); essential private and public services (e.g. credit scoring denying citizens opportunity to obtain a loan); law enforcement that may interfere with people’s fundamental rights (e.g. evaluation of the reliability of evidence); migration, asylum and border control management (e.g. automated examination of visa applications); administration of justice and democratic processes (e.g. AI solutions to search for court rulings).
Connected product	an item that obtains, generates or collects data concerning its use or environment and that is able to communicate product data via an electronic communications service, physical connection or on-device access, and whose primary function is not the storing, processing or transmission of data on behalf of any party other than the user (art. 2 (5) DA). Explanatory text: This term is defined as per the Data Act. This clarification ensures that the definition is understood within the specific regulatory context of the Data Act while allowing the same term to be used in other contexts with different meanings.
Related service	means a digital service, other than an electronic communications service, including software, which is connected with the product at the time of the purchase, rent or lease in such a way that its absence would prevent the connected product from performing one or more of its functions, or which is subsequently connected to the product by the manufacturer or a third party to add to, update or adapt the functions of the connected product (art. 2 (6) DA). Explanatory text: This term is defined as per the Data Act. This clarification ensures that the definition is understood within the specific regulatory context of the Data Act while allowing the same term to be used in other contexts with different meanings.
High-Value Datasets (HVDs)	data held by a public sector body associated with important benefits for society, the environment, and the economy when reused (Open Data Directive). The thematic categories of high-value datasets are: geospatial data; earth observation and environment data; meteorological data; statistics; companies and company ownership data; mobility data (Annex I, Open Data Directive). Explanatory text: These datasets are suitable for creating value-added services, applications, and new jobs, and are made available free of charge in machine-readable format documents, the reuse of high-value datasets is associated with important benefits for the society and economy. They are subject to a separate set of rules ensuring their availability free of charge, in machine readable formats. They are provided via Application Programming Interfaces (APIs) and, where relevant, as a bulk download. The thematic scope of high-value datasets is provided in an Annex to the Directive.
FAIR principles	a collection of guidelines by which to improve the Findability, Accessibility, Interoperability, and Reusability of data objects. These principles emphasize discovery and reuse of data objects with minimal or no human intervention (i.e. automated and machine-actionable), but are targeted at human entities as well (Common Fund Data Ecosystem Documentation). Explanatory text: In 2016, the ‘FAIR Guiding Principles for scientific data management and stewardship’ were published in Scientific Data. The authors intended to provide guidelines to improve the Findability, Accessibility, Interoperability, and Reuse of digital assets. The principles emphasise machine-actionability (i.e., the capacity of computational systems to find, access, interoperate, and reuse data with none or minimal human intervention) because humans increasingly rely on computational support to deal with data as a result of the increase in volume, complexity, and creation speed of data (GO FAIR Initiative)
Research data	documents in a digital form, other than scientific publications, which are collected or produced in the course of scientific research activities and are used as evidence in the research process, or are commonly accepted in the research community as necessary to validate research findings and results (art. 2 (9) PSI Directive).
Interoperability (DA)	means the ability of two or more data spaces or communication networks, systems, connected products, applications, data processing services or components to exchange and use data in order to perform their functions (art. 2 (40) DA).
HealthData@EU	cross-border infrastructure for secondary use of electronic health data established by the European Health Data Space Regulation (art. 52 (2) EHDS).
Trigger	An element, criteria or an event that has occurred in a particular context of a data space, that signals that a particular legal framework must or should be applied.

While the overview presented below aims to provide an exhaustive taxonomy of data types within the applicable EU regulatory frameworks, the classification of relevant data types remains a work in progress and may be adjusted or further developed in the next version of the Blueprint.

The following table lists different types of data that may trigger the need for compliance with various legal frameworks. The second column describes the actual needs (for the data space governance authority, data space participants or other stakeholders in the data space) in various circumstances.

Types of data	Description and assessment of the impact
Personal data	Legal landscape relevant to personal data: The data protection legal framework, including the GDPR, as well as the Law Enforcement Directive and the e-Privacy Directive (if particular circumstances apply), remains fully applicable to the processing of personal data within the context of a data space, so that parties involved in the processing activities of personal data will need to ensure compliance with relevant legal provisions. Parties affected: Neither the involvement of a data space, nor that of a personal data intermediary, relinquishes the parties involved in such processing of their duties as data controllers or processors. The clear establishment of the roles of data controller and data (sub-)processor should also be a priority, taking into account the essential criterion of decision-making powers regarding purpose and means of processing. Continuous compliance: Issues of data protection should be an important consideration from the very start of the design of a data space and throughout all of its development stages. Applicability to data spaces: In the context of data spaces, the GDPR is highly (or most) relevant for use cases. For example, if a use case or transaction involves any information relating to an identified or identifiable natural person ('data subject'), the use case or data transaction participants will need to ensure compliance with data protection legislation, most notably the principles relating to the processing of personal data. The GDPR also applies to mixed datasets (comprised of both non-personal and personal data). This remains valid also if personal data represents only a small part of the dataset. The concept of the “purpose” under data protection law should be given particular attention, as it is fundamental to clearly define any personal data processing activity. Consideration of how to ensure accountability within a data space and how compliance with data protection principles, such as lawfulness, transparency, and purpose limitation, should be facilitated. Additional resources: The Spanish Data Protection Authority, in reference also to the EDPB-EDPS Joint Opinion 03/2022 on the Proposal for a Regulation on the European Health Data Space, highlights the importance of a data protection policy, which should state “how the principles and rights set out in the data protection regulation and the guidelines in this document are to be implemented in a concrete, practical and effective manner.” Spanish data protection authority: "Approach to data spaces from GDPR perspective" Some of the most important elements to be considered for a data protection policy that the Spanish Data Protection Authority lists in its report (p. 89-97) include the involvement of data protection officers (DPOs) and advisors in the design of data spaces; implementation of procedures for authorising the processing of personal data within the data space; a precise definition of the purposes of data processing; and risk management, including data protection impact assessments (DPIAs) coordinated between involved parties. Synthetic data (sometimes referred to as “fake data”) can be understood as data artificially generated from original data, preserving the statistical properties of said original data. Some data may also be completely artificially created without an underlying real-world data asset (e.g. virtual gaming environments). From a technical perspective, the primary purpose of its generation is to increase the amount of data. This solves an issue of insufficiency in datasets or improves the variability of available data. It also serves as a way to mitigate risks to the fundamental rights of individuals. According to the Spanish Data Protection Authority, the use of synthetic data, along with other techniques such as generalisation, suppression, or the use of Secure Processing Environments, can be the way to comply with data minimisation or privacy by design/default principles. It is important to remember that when personal data is being used to generate synthetic data, it will be considered part of a processing operation and, therefore, subject to compliance with the GDPR. However, depending on the original data, the model and additional techniques applied, the synthetic data can be anonymous data. The report also emphasizes the role of traceability in data spaces for providing control mechanisms relevant for the processing activities within data spaces. In that regard, data traceability should help to identify roles and implement access control and access logging policies. It should help to facilitate fulfilling particular objectives set by the GDPR, in particular addressing the transparency requirements to data subjects, enabling the effective exercise of data subjects’ rights, such as the management of consent, facilitating excercising the obligations of the controller (e.g., to ensure the principles of restriction of processing, purposes compliant with the legal bases or of processors/sub-processors), and allowing Supervisory Authorities to exercise their powers in accordance with Article 58(1) of the GDPR. More specifically, keeping of log of accesses and data space participants' actions performed within a data space could be a way to implement the obligations laid down by art. 32 (1) GDPR requiring from controller and processor the implementation of appropriate technical and organisational measures to ensure a level of security appropriate to the risk of varying likelihood and severity for the rights and freedoms of natural persons. To read more about Provenance and Traceability in data spaces, please check the Provenance and Traceability Building Block. Technical implementation: As part of the personal data protection arrangements, a relevant solution could be to implement the W3C’s Data Privacy Vocabulary that enables the expression of machine-readable metadata about the use and processing of personal data based on legislative requirements such as the GDPR. More details about the W3C Standards/Credentials can be found in the Identity and Attestation Management building block. Special categories of personal data (“sensitive” data) According to art. 9 (1) GDPR, personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data processed solely to identify a human being, health-related data, data concerning a person’s sex life or sexual orientation, shall be considered special categories of personal data, the processing of which is generally prohibited, unless one of the strictly enumerated legal bases set out in paragraph (2) occurs. They shall be strictly interpreted and considered separately for each processing activity. If one of the legal bases is applicable, it is important to remember that processing of such data still needs to be compliant with the principles, rights and obligations established in the GDPR. As indicated by the Spanish Data Protection Authority, in the case of processing of these data, it should be demonstrated that the conditions for lifting the prohibition of such processing set out in Article 9(2) of the GDPR are met. Processing special categories of data referred to in Article 9(2)(g) (essential public interest), (h) (purposes of preventive or occupational medicine, assessment of the worker’s capacity to work, medical diagnosis, provision of health or social care or treatment, or management of health and social care systems and services) and (i) (public interest in the field of public health) of the GDPR has to provide appropriate safeguards and has to be covered by a regulation having the force of law. The GDPR also requires assessing the following: The necessity of processing the data (This also includes appropriateness. For example, when processing is necessary to protect the data subject's vital interests or for reasons of substantial public interest based on Union or Member State law). The proportionality of the processing (for example, when data is processed under essential public interest, archiving purposes in the public interest, scientific or historical research purposes, or statistical purposes). Whether the processing activity can be considered “high-risk processing” or not. If this is the case, there must be an appropriate data protection impact assessment that will manage the high risk and demonstrates passing the assessment of necessity, appropriateness and strict proportionality. One of the types of sensitive data is biometric data. Biometric data can allow for the authentication, identification or categorisation of natural persons and for the recognition of emotions of natural persons. It is defined in Art. 4 (14) GDPR as personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data. As it’s considered one of the special categories of data under GDPR, the processing of biometric data is prohibited in principle, providing only a limited number of conditions for the lawful processing of such data. Due to the increased use of biometric data in AI development and the immutability of physiological traits, the AI Act regulates the use of such data. In accordance with the AI Act, AI systems used for biometric categorisation based on sensitive attributes (protected under Article 9(1) GDPR) and emotion recognition should be classified as high-risk, in so far as these are not prohibited under this regulation. Biometric systems which are intended to be used solely for the purpose of enabling cybersecurity and personal data protection measures should not be considered high-risk AI systems.
Intellectual Property Rights/ Trade Secret-Protected Data(sets)	Intellectual property (IP) law can confer rights over datasets, often through copyright and the sui generis database right. Data may also be protected by trade secrets, which constitute a separate legal regime. It is the responsibility of each data space participant to ensure legal compliance and to have an authorisation and/or legal basis for data sharing if data is protected by copyright, sui generis or trade secrets. Copyright law: Protects creative works like text, images, video, and sound. It also protects software (e.g., source code) and databases (e.g., a collection of independent data protected). Copyright does not protect data itself - it differs from other works, which are protected due to specific qualifying conditions, such as being an author’s original creation. To be protected by copyright, a database has to be original, reflect the author's intellectual creation, and be fixed in tangible form. In the context of databases, a specific test of originality reflecting the special characteristic of databases is required (whether the selection or arrangement of their contents constitutes the author’s own intellectual creation). Purely factual information is usually not eligible for protection (Article 2, InfoSoc Directive). Sui Generis Database Right (EU Database Directive 96/9/EC): Databases could be protected by the sui generis database right in addition to copyright protection. Grants sui generis database rights to creators who made qualitatively and/or quantitatively substantial investment in obtaining, verifying, or presenting contents. Provides right to prevent unauthorized extraction or re-utilisation. Defines databases as collections arranged systematically and individually accessible. Trade Secret Protection (EU Trade Secrets Directive 2016/943): Encompasses various data types, requiring secrecy and commercial value. Enforceable rights against unlawful use and misappropriation without conferring property rights Secrecy is preserved as long as persons having access to information are bound by confidentiality agreements. Solutions to be implemented on a data space level The acknowledgement of intellectual property and quasi-IP rights (trade secrets), both for identifying existing assets and creating new ones, should be addressed in the intellectual property policy within the general terms & conditions and the intellectual property clauses of particular data product contracts. More details can be found in the Contractual Framework building block. Data holders are responsible for providing information about the IP rights and/or trade secrets they possess over particular datasets before sharing them with potential data recipients. Specific legal provisions concerning trade secrets’ aspects in the context of data sharing can be found in the Data Act (primarily in the context of business-to-consumer and business-to-business data sharing). Examples of possible legal, organisational and technical measures to preserve intellectual property rights or trade secrets can be found in the recently adopted European Health Data Space Regulation. Such measures could include data access contractual arrangements, specific obligations in relation to the rights granted to the data recipient, or pre-processing the data to generate derived data that protects a trade secret but still has utility for the user or configuration of the secure processing environment so that such data is not accessible by the data recipient (recital 60, art. 53 EHDS-R).
Non-personal data
IoT Data	The Data Act lays down a harmonised framework specifying the rules for using product data or related service data, including data from Internet of Things devices, smartphones, and cars. It imposes the obligation on data holders to make data available to users and third parties of the user’s choice in certain circumstances. It also ensures that data holders make data available to data recipients in the Union under fair, reasonable and non-discriminatory terms and conditions and in a transparent manner. These provisions apply to the data of specific origin, irrespective of the personal/non-personal character of the data. If the processing of personal data is involved, it is important to remember that the GDPR still applies. Data spaces should pay attention to Chapter II of the Data Act, especially in the context of data transactions involving the processing of product data and related service data. More specifically, data spaces should consider the rights of the users of connected products or related services that they hold towards the data they produce by using these products or services. These rights include access to and use of the data for any lawful purpose. There are some exceptions to access rights (for example, if the data user requests access to personal data of which he is not a data subject). The data provided to the user should be of the same quality as the data available to the data holder and should be provided easily, securely, free of charge, and in a comprehensive, structured, commonly used and machine-readable format. If the data transaction is supposed to be concluded without the data user directly involved, it is important to remember that the scope of such transactions is predefined by the contract with the user. Data holders shall not make available non-personal product data to third parties for commercial or non-commercial purposes other than the fulfilment of such a contract. Data holders can also decide to make their data available via a third parties of their choice (for example, data intermediation service providers as defined by the DGA) for commercial purposes. These third parties hold then certain obligations towards the data they receive on behalf of the user. For example, they should be able to transfer the data access rights granted by the user to other third parties, including in exchange for compensation. Data intermediation services may support users or third parties in establishing commercial relations with an undetermined number of potential counterparties for any lawful purpose falling within the scope of the Data Act, providing that users remain in complete control of whether to provide their data to such aggregation and the commercial terms under which their data are to be used.
High-Value Datasets (HVDs)	High-Value Datasets (HVDs) are defined in the Open Data Directive as “documents held by a public sector body, the reuse of which is associated with important benefits for society, the environment and the economy”. HVDs can be re-usable for any purpose (as is the case for open data). Public sector bodies are not allowed to charge fees for the reuse of HVDs. In the context of data transactions within a data space, it is important to remember that the reuse of documents should not be subject to conditions, but some cases are justified by a public interest objective. In these situations, public sector bodies might issue a license imposing conditions on the reuse by the licensee dealing with issues such as liability, the protection of personal data, the proper use of documents, guaranteeing non-alteration and the acknowledgement of source. In addition to the above, there are categories of data for which we do not know the legal status of the data. Therefore, they are de facto under the control of the data holder.

Participants	Description and assessment of the impact
Gatekeepers	The Digital Markets Act defines gatekeepers as undertakings providing so-called “core platform services”, such as online search engines, social networking services, video-sharing platform services, number-independent interpersonal communications services, operating systems, web browsers, etc. According to Art. 3 (1) DMA, for an undertaking to be designated by the European Commission as a “gatekeeper”, it has to have a significant impact on the internal market; provide a core platform service which is an important gateway for business users to reach end users; and it enjoys an entrenched and durable position in its operations, or it is foreseeable that it will enjoy such a position in the near future. It also has to meet the requirements regarding an annual turnover above the threshold determined by the regulation. So far, the European Commission has designated the following gatekeepers: Alphabet, Amazon, Apple, Booking, ByteDance, Meta, and Microsoft. This position is determined in relation to a specific core platform service (for instance, Booking has been designated a gatekeeper for its online intermediation service “http://Booking.com ” ). While the DMA does not aim to establish a framework for data sharing, it challenges the “data monopoly” of gatekeepers. Specific data-related obligations addressed to gatekeepers that may be relevant in the context of a data space include: Ban on data combination - For example, combining personal data from one core platform service with personal data from any further core platform services, or from any other services provided by the gatekeeper or with personal data from third-party services (art. 5(2) (b) DMA); Data silos - Prohibition to use, in competition with business users, not publicly available data generated or provided by those business users in the context of their use of the relevant core platform services (art. 6(2) DMA); Data portability - Obligation to provide end users and third parties authorised by an end user with effective portability of data provided by the end user or generated through the activity of the end user in the context of the use of the relevant core platform service (Article 6(9) DMA); Access to data generated by users - Obligation to provide business users and third parties authorised by a business user access and use of aggregated/non-aggregated data, including personal data, that is provided for or generated in the context of the use of the relevant core platform services (Article 6(10) DMA); Access search data for online search engines - Providing online search engines fair, reasonable and non-discriminatory terms to ranking, query, click and view data in relation to free and paid search generated by end users on its online search engines (Article 6(11) DMA). More information about the data-sharing obligations of the gatekeepers can be found here: data_sharing_obligations_under_the_dma_-_challenges_and_opportunities_-_may24.pdf (informationpolicycentre.com)
Data Intermediation Service Providers (DISPs)	The recent Data Governance Act (DGA) sets out specific requirements for providing data intermediation services. Certain service functions in data spaces are likely to qualify as data intermediation services (see: Data Intermediation Service Provider Flowchart). A data space governance authority should also evaluate to what extent it organises any services that may qualify as data intermediation services under the DGA. If this is the case, it will need to ensure compliance with the provisions of the DGA. Data Intermediation Service under the Data Governance Act Under the Data Governance Act, a “data intermediation service” (“DIS”) is defined as a service aiming to establish commercial relationships for the purposes of data sharing between an undetermined number of data subjects and data holders on the one hand and data users on the other. Data intermediation service providers intending to provide data intermediation services are required under the DGA to submit a notification to the competent national authority for data intermediation services. The provision of data intermediation services is subject to a range of conditions, including a limitation on the use by the provider of the data for which it provides data intermediation services. The European Commission hosts a register of data intermediation services recognised in the European Union: https://digital-strategy.ec.europa.eu/en/policies/data-intermediary-services Providers of data intermediation services and data space intermediaries/operators Intermediary services are covered more broadly in “https://dataspacessupportcentre.atlassian.net/wiki/spaces/BV15/pages/367298597”. The term “data space intermediary” refers to “a data space participant that provides one or more enabling services while not directly participating in the data transactions”. Enabling services refers to “a service that implements a data space functionality that enables data transactions for the transaction participants and/or operational processes for the governance authority.” (see the DSSC Glossary for more information) It is important to note that not all data space intermediaries would be subject to the provisions of the DGA by default. First of all, some of the potential enabling services they provide may not be aimed at establishing commercial relationships for the purposes of data sharing. It may also be the case that, in the circumstances at hand, the services may not result in commercial relationships between an undetermined number of data subjects and data holders on the one hand and data users on the other. Data intermediation services and personal data The services of data intermediation service providers may also relate to personal data. In such cases, it is important to appropriately consider the different roles and responsibilities under the DGA and the GDPR. For a transaction facilitated by a provider of data intermediation services, it is difficult to establish who is acting as the controller, whether there are multiple controllers acting as joint controllers, whether there is a processor and whether data users are data recipients. It may be important to clarify the respective responsibilities of particular data space participants by offering guidance to help ensure overall compliance with obligations under the DGA and the GDPR.
Data Altruism Organisations (DAOs)	In the context of data spaces, DAOs can take on a variety of roles as data space participants. They can be data providers, transaction participants, and data space intermediaries (e.g., personal data intermediaries). It is important to address their participation in the data space, especially regarding the value distribution aspects and their potential sponsoring by the data space.
Researchers	Researchers may join data spaces to make better use of their rights under legal frameworks, leveraging the EU legal frameworks that facilitate data access and explore how data spaces can enhance access and sharing of data. In the data-sharing context, they can be both data recipients and data providers. Researchers in the EU benefit from a number of legal frameworks that facilitate access to data, including provisions in the Open Data Directive that promote the re-use of public sector information. In addition, research exceptions in intellectual property law, such as the text and data mining exception of Art. 3 Copyright in the Digital Single Market Directive, and recently introduced measures such as Art. 40 of the Digital Services Act, introduce greater access to data for researchers (under specific circumstances mentioned in the Art. 8 DSA, and purposes of, among other things, detection, identification and understanding of systemic risks and assessment of their risk mitigation). The European Data Strategy and the creation of common data spaces demonstrate general mechanisms for increased data sharing and opening up privately-held data, including for researchers. Initiatives such as Horizon Europe further support open science and data sharing, and guidelines for ethical data management and sharing agreements foster a supportive scientific research and innovation environment. For a comprehensive analysis, see:https://data.europa.eu/doi/10.2777/633395
Public Sector Bodies	Public sector bodies perform legally defined duties for the benefit of the public interest. They can be subject to specific obligations to share certain categories of data, not only with data space participants but with other potential users outside of the data space as well. The data held by public sector bodies can be of structural relevance for a data space ecosystem.

Examples of domain-specific use cases	Description
Mobility	The common European mobility data space (EMDS) aims to facilitate data access, pooling and sharing for more efficient, safe, sustainable and resilient transport. One of the possible use cases to be developed using the data obtained through the EMDS is Mobility as a Service (MaaS). It is a service that provides users with a comprehensive tool to plan, book and pay for different types of transport based on several criteria and by using a single interface. It helps the user to choose the best way to move from one place to another and keep all the information about the journey in one place. To operate properly, MaaS collects different categories of data. This data is held by companies and individuals in the public and private sectors and includes: Public transport data, Geographical data, Other transport data, including from private operators, Booking and payment data, Ticketing data, User input data. Besides the requirement to comply with the horizontally applicable regulations (such as GDPR), it might be necessary to consider sector-specific regulations in order to comply with certain technical or organisational requirements. One of the most important legislations for the mobility sector is the Intelligent Transport Systems (ITS) directive that aims to make high-quality and timely data available for services, such as multimodal journey planners, navigation platforms, and emergency services. More information about the applicable legal framework can be found here: 2024-03-19-deliverable-d3.1-analysis-report-v3.pdf (mobilitydataspace-csa.eu)
Health	European Cancer Imaging Initiative (EUCAIM) provides a robust, trustworthy platform for researchers, clinicians, and innovators to access diverse cancer images, enabling the benchmarking, testing, and piloting of AI-driven technologies. It aims to capitalize on the recent advances and successes of Artificial Intelligence systems in helping medical professionals detect and diagnose cancers. Potential use case developed with data from the data space: Due to the necessity to safeguard the rights and freedoms of respective data subjects, as well as the highly sensitive nature of the health sector, cancer images used to train and/or test algorithms or AI systems will have to comply with the GDPR provisions, especially with regards to the processing of special categories of data. Apart from that, AI developers need to take into account the legal requirements applicable to AI in the healthcare sector, especially the following legislations: The European Medical Devices Regulation (EU MDR) and In Vitro Diagnostic Medical Devices Regulation (EU IVDR) laying down the safety rules for AI in healthcare domain, The Artificial Intelligence Act requirements for high-risk AI systems - applicable to a safety component of a medical device. More information about the applicable legal framework can be found here: Meszaros et. al., 2023
Research and Innovation	The research and innovation data space, EOSC (European Open Science Cloud), has a specific objective of deploying core services and expanding the EOSC federation of existing research data infrastructures in Europe. Potential use case developed with data from the data space: One of the use cases enabled by the EOSC is The Blue Cloud Initiative, which was developed as the ecosystem for marine research according to FAIR principles. It benefits from EOSC funding and policies, as well as from using EOSC as a multiplier to reach secondary users. It directly supports the Green Deal Data Space and the Horizon Europe mission ‘Restore our Oceans and Waters’. For developing use cases within the framework provided by EOSC, it is important to look at the research-specific requirements, especially regarding the researchers’ access to data, as mentioned above.
Language	European Language Data Space builds a trustworthy and effective data market for exchanging language resources in the public and private sectors. Potential use case developed with data from the data space: One of the most important use cases is developing LLM technologies using language data from datasets available through the data space infrastructure. LLMs are largely used in generative AI systems, which are a typical example of a general-purpose AI model regulated under the AI Act. Under specific circumstances (listed in Annex III of the AI Act), these models can fall under the high-risk category. Therefore, requirements for general-purpose AI systems and high-risk AI will apply cumulatively. Due to their adverse impact on fundamental rights and people’s safety, providers of high-risk AI systems have a number of requirements that they need to comply with. One of the key requirements relates to ensuring access by certain actors (such as providers, European Digital Innovation Hubs, TEFs and researchers) to high-quality datasets for training, validation and testing of AI systems within the fields of activities of those actors related to the scope of the AI Act. As stated in recital 68 of the Regulation, “European common data spaces will be instrumental to provide trustful, accountable and non-discriminatory access to high-quality data for the training, validation and testing of AI systems”. In light of this, data spaces can be understood as enablers for compliance requirements concerning quality criteria referred to in Art. 10, paragraphs 2 to 5. These requirements refer to specific technical and governance building blocks offered by DSSC. For example, tracking of data sharing and data provenance in a data space is a key instrument for compliance with data quality requirements set in Art. 10 AIA, such as: Relevant design choices (Article 10(2)(a)); Data collection processes and the origin of data, and in the case of personal data, the original purpose of the data collection (Article 10(2)(b)); An assessment of the availability, quantity and suitability of the data sets that are needed (Article 10(2)(e)); Identification and mitigation of biases (Article 10(2)(f),(g)).
Cultural Heritage	The common European data space for cultural heritage is designed to accelerate the digital transformation of the cultural heritage sector and maximise the positive benefits of accessing and using cultural heritage data. Potential use case developed with data from the data space: One of the possible use cases with the data obtained through Europeana PRO could concern developing an extended reality (XR) game using certain collections or other objects protected as cultural heritage. For this use case, it will be important to assess whether the items or collections (also understood as datasets in this case) used by the developers enjoy copyright protection. Many works shared by cultural heritage institutions are already in the public domain. This means they were never protected by copyright, their copyright protection has expired, or the copyright was expressly waived. In addition, for the possibility to use these items, it is also relevant to check whether the user (in this case a game developer) will be able to use one of the exceptions provided for in the Copyright in the Digital Single Market Directive.

1. Summary

The Contractual Framework building block describes the legally enforceable agreements that underlie the operation of a data space, as entered into by different parties in a relationship with the data space.
Agreements may be classified into the following three categories, based on the nature of their subject matter:
• Institutional agreements
• Data-sharing agreements
• Services agreements
These types of agreements differ with respect to the parties involved, their function, and the elements covered by the agreement.
Institutional agreements implement the governance of a data space and are an essential component of the Rulebook. They outline the general terms and conditions for participation in a data space, constitute the legal document bringing them into existence and establish a legal basis for its operations. Data-sharing agreements establish the legal basis for the data transactions that occur among participants in the data space. Services agreements refer to all agreements related to the provision of services to data spaces.
The identified categories serve as working concepts covering various agreements, such as data product contracts. The present building block provides a selection of the most important agreements, describing their functionalities, and highlighting their main elements, along with examples. Additionally, the building block outlines common legal issues to consider within the Contractual Framework and directs to existing resources in the Further Reading section to address these concerns. The general structure of the Contractual Framework is illustrated in Figure 1 below.

1.1 Questions that will be answered

What are the main types of agreements required to establish and operate a data space?
What are the essential elements and functions of each type of agreement within the contractual framework?
Which parts of these agreements are mandatory under governance or regulation, and which can be adapted by participants?

2. Purpose of the building block

The Contractual Framework building block supports data space participants and governing authorities by translating legally relevant elements (e.g., responsibilities, liability, rules on onboarding and offboarding, and commitments related to data transactions) into clear, legally valid, and enforceable agreements.
It promotes awareness among data space governing authorities about the need to enable interoperable, automated, and scalable agreements, ensuring consistency across different levels (ecosystem, data space, use case, participant).
It categorises and outlines the main agreements in a data space, highlighting their most important elements.
It identifies mandatory/non-negotiable elements of the contractual framework (e.g., conditions imposed by regulatory compliance or governance), alongside distinguishing negotiable terms (e.g., conditions relating to transactions of data products). This is done in coordination with the Regulatory Compliance building block, which provides guidance to participants on issues to consider in the contract drafting process.

3. Elements and their key functions

3.1 General remarks

The term ‘agreement' should be understood here as the document, whether in physical or digital form, serving as evidence of a contract. It is a legally binding agreement between two or more parties with a shared interest, establishing mutual obligations enforceable by law. Different types and categories of agreements exist, subject to various factors, including the organisational form of a data space (e.g., unincorporated vs incorporated data space). For guidance on how to choose the appropriate organisational form and a description of the options available, see the Organisational Form and Governance Authority Building Block).

Figure N. 1 provides a broad categorisation of data space agreements, based on the function they serve. In practice, these agreements may take different forms based on several factors affecting their structure and content. These factors may include, amongst others, the regulatory and business context (for more details, see the Regulatory Compliance building block). The contractual framework may vary depending on the specific business model that the data space adopts (see the Business Model building block for descriptions and examples of different business models) or the relationship between data transaction participants. When direct competition exists in other markets between transaction participants, specific requirements must be met to ensure compliance with competition law rules during the cooperation (the case of Oxelösund serves as an example of a data space initiative involving participants competing in the same markets).

Explicatively, the Founding agreement may take the specific form of either a statute or articles of association (thus establishing a legal entity) or a consortium agreement (unincorporated collaboration). The choice will depend on whether the data space itself will be constituted as a separate legal entity or whether the collaboration will be purely regulated by contract. The contractual framework building block will inevitably need to continue evolving and responding to developments in operating data spaces.

3.2 Overview Contractual Framework

The Contractual Framework encompasses all agreements that govern the operation and activities of a data space and its participants. It defines the relationships, contractual rights, and obligations within the data space, implementing its governance framework. It additionally renders part of its rules legally enforceable among data space participants, members, and enabling service providers.
Beyond data space governance, the Contractual Framework empowers data space participants, particularly data providers and, indirectly, data rights holders, to exercise their data sovereignty. It enables the addition of specific conditions to the baseline governance framework provided by the data space governing authority. The scope of the Contractual Framework is wide, and it is essential to retain conceptual clarity. Consequently, the agreements can be categorised by their subject matter into:
• Institutional Agreements - Define the foundational governance and common rules binding all data space participants.
• Data-Sharing Agreements – Regulate rights and obligations between parties exchanging or accessing data.
• Services Agreements - Set terms for providing and using data-related or enabling services within the data space.

The current division is based on SITRA Rulebook model for a fair data economy, with differences reflecting the different scope of the document and the level of generality of presentation of the agreements.

Institutional agreements -

Institutional agreements provide the foundation for the creation of data spaces and establish a minimum mandatory governance framework at the data space level applicable to all participants. These agreements set out the rules regulating the relationship between all data space participants and members, directly or indirectly binding them to a specific governance framework. Institutional agreements could therefore be broadly understood as a tool for implementing the governance framework.
Institutional agreements may affect different levels of the contractual framework. At a high level, they serve as a common set of rules regulating the relationships between data space participants. At a more granular level, they mandate specific terms & conditions to be included in data product contracts. Explicatively, they may define and specify a limited number of predefined and standardised contractual clauses and/or licenses to be used by data providers (regulating the use case/data product level). It could specify the terms and conditions by which all data space participants entering into a data transaction would need to abide by, providing common governance for data transactions and ensuring regulatory compliance. In other words, institutional agreements allow the introduction of common elements (e.g., standardised clauses) across the data space giving legal effect to the organisational and business decisions that apply to the data space as a whole. Institutional agreements can thus be used to establish the common elements of a data space. They may limit a data space participant's (particularly the data provider's) freedom to enter into data-sharing agreements, with the aim of reducing transaction costs and complexity while enhancing legal interoperability. An example of institutional agreements, including terms and conditions, can be found in SITRA Rulebook 3.0.

Data-sharing agreements -

Data-sharing agreements focus on the sharing of data. Within the present document, data sharing will be used as a general term referring to a heterogeneous range of actions performed on data. These actions may include:

Supply of data – the generic notion of making data available to another party, which may occur in various forms;
Transfer of data – a specific form of supply where control over the data is passed to the recipient;
Porting of data – a specific form of supply initiated by the data subject or controller, whereby data controlled by another party is transferred to themselves or to a designated third party; and
Remote or decentralized access and processing – arrangements where data remain under the control of the provider, but authorized users can access, query, or process the data (for example, to extract statistics or insights) without obtaining a copy of the data itself.

(For detailed definitions of supply, transfer, and porting, see ALI-ELI Principles for a Data Economy).

Data-sharing agreements are not binding on all data space participants; instead, they only bind data transaction participants.

It should be noted that data-sharing agreements only bind data transaction participants. Unlike institutional agreements, they are not binding on all data space participants.
While different models may be employed, typically the data provider will set the terms and conditions under which a data product is made available to the data user, reflecting the principle of data sovereignty. Alternative models may exist. For example, a fixed and closed list of clauses may be provided directly by the data space, to then be selected by the data provider or data recipient. In other cases, agreements can be negotiated starting from a standard data product contract template made available by the data space. This approach may however reduce the legal interoperability and scalability of the data space. In both scenarios, the tools provided by the data space support data providers’ data sovereignty.

The data product contract provides a specification of a data-sharing agreement. It outlines the terms and conditions attached to the data product, defined as “data-sharing units, packaging resources (data and/or value creation services), and metadata that describes the resources, the associated license terms, and other information (e.g., delivery method)” (see the Data Space Offering Building Block for more details).

Services agreements -

Service agreements relate to the provision of services within a data space (i.e., Federation Services, Participant Agent Services, and Value Creation Services - for more details on the taxonomy of technical services, see Services for Implementing Technical Building Blocks). In the context of a data space, these agreements can be further distinguished into two types:

Agreements for services related to data (e.g., Data Exchange & Interoperability Services); and
Agreements related to enabling services (e.g., Identity & Access Management Agreements).

Services related to data include all services that have data sharing as the subject matter of the agreement. Different types of services can be provided: data processing, data trust, data escrow, and data intermediation services (known in the ALI-ELI Principles as data marketplace contracts). These services typically allocate responsibilities and legal obligations among the parties, including default rules, fiduciary duties, and compliance with applicable law. For instance, data trust contracts impose fiduciary duties on trustees to act for the benefit of entrusters or beneficiaries (Principle 13), data escrow contracts restrict the powers of data holders via a trusted third party to ensure regulatory compliance (Principle 14), and data marketplace contracts ensure intermediaries facilitate transactions without using the data for their own purposes (Principle 15).

Data intermediation services are the most relevant in the context of data spaces. It includes multiple types of services, defined in Art (2)11 DGA as a “service which aims to establish commercial relationships for the purposes of sharing data between an undetermined number of data subjects and data holders on the one hand and data users on the other, through technical, legal or other means, including for the purpose of exercising the rights of data subjects in relation to personal data”. Examples of these services include data-sharing pools, data marketplaces, personal information management systems (PIMS), data cooperatives, etc. (see JRC’s Mapping the landscape of data intermediaries).

Enabling services to data spaces support individual data space participants or the data space as a whole, providing functionalities within the data space. These services are outlined in the Services for Implementing Technical Building Blocks section and include federation services, participant agent services, and value creation services. While these services do not directly involve data sharing, they enable the proper functioning, governance, and coordination of services in the data space, ensuring compliance, interoperability, and efficient operations.

3.3 Additional distinguishing factors in categorising agreements

Mandatory vs Non-Mandatory agreements

A further distinction can be made between mandatory and non-mandatory agreements. The specific clauses within agreements can additionally vary based on the involved parties’ intentions or the duties and rights to be governed by the agreement. It is important to recognise that this should not be understood as a rigid binary distinction, but rather a spectrum. Data spaces may exercise some discretion in how specific legal obligations are implemented. Establishing the contractual framework first requires an assessment of the regulatory framework (mandatory obligations imposed on data spaces as a whole or on data space participants themselves). This assessment serves to determine which rules need to be complied with and addressed in the contractual framework. The Regulatory Compliance Building Block provides an initial mapping of triggers and identifies classes of rules (obligations, liabilities, and conditions). These findings must then be incorporated into the contractual framework. Once this process is completed, the partners initiating the data space as part of the data space initiative are free to define the remaining clauses according to the governance framework they wish to establish. It should be noted that understanding data types (e.g., personal data - see the taxonomy of data in the Regulatory Compliance Building Block)remains equally relevant, as the non-mandatory rules do not exist in a vacuum and can only be valid and effective as long as they are consistent with the regulatory framework.

3.4 Functional descriptions of the contractual framework

3.4.1 Institutional agreements

Founding agreement	The founding agreement establishes the data space and its governance authority. The agreement is entered into by the founding members of the data space initiative (i.e., the initial data space participants). It sets out the purpose for which the data space is created. Different organisational forms are possible, and different specific legal instruments can be used depending on the organisational form, including: Articles of Association or Statutes - these are used to establish the data space as a separate legal entity. The statute may allow the onboarding of new members by allowing external parties to sign the statute. Consortium agreements, joint ventures, strategic cooperation, and other cooperation agreements - the data space is not incorporated, with no new legal entity created for that purpose. Any natural or legal person may become a member of the data space by signing a founding agreement (e.g., Consortium agreement). For further information, see the Organisational Form and Governance Authority building block. The agreement-specific clauses may include: Background and purpose (why the data space is created) Identification of the parties (members of the data space initiative) General responsibilities and liability (in some cases - e.g., in joint ventures) Reference to the chosen governance models. The admission policy for data space members—the Founding agreement identifies the initial data space members, as outlined in the signatories (i.e., the parties of the data space initiative), who will be part of the governing body of the data space. It may also allow additional members to join the governance of the data space in the future, specifying the necessary conditions, qualifications, and requirements. The manner in which this is implemented in practice depends on the specific legal form that a data space assumes. An example of an artefact used to signal the intention to join a data space as a member can be the Accession agreement (SITRA Rulebook).
General Terms and Conditions	The general terms and conditions serve as an agreement providing legal enforceability to various elements of the governance framework (e.g., mandating compliance with a specific process). These terms make it binding on all data space participants. In some instances, they can be included in the founding agreement or at least directly referenced by it. The general terms and conditions allow data spaces to regulate interactions at the data space level. They create and define the roles and responsibilities of the data space participants, including: the data space governance authority, data provider, data recipient, and service providers (data-related services, trust framework provider, management of identities, etc.). When a data space is established as a legal entity, the agreement may cover both the liability between the data space participants and the liability between the participant and the legal entity. The general terms and conditions can serve as the framework for data transactions, namely the interactions (i.e. rights, responsibilities, liabilities, and obligations) of the data transaction participants. They do so by introducing common elements (e.g., a limited set of standard clauses or typologies of licences—see further in the data transaction agreements section) to improve legal interoperability and reduce transaction costs, ultimately reducing complexity and the possibility of conflict. The areas that the general terms and conditions regulate at the data space level include: · Admission policy for data space participants. This describes whether new participants are accepted, the conditions and eligibility criteria that parties must meet to join a data space, the conditions to remain a data space participant, and the procedures for the removal of an existing participant. Data space participants join a data space by accepting the terms and conditions. · Intellectual property policy. At a minimum, this specifies that none of these agreements should be construed as an assignment of IP rights; instead, non-exclusive licenses are granted. If new IP rights may emerge from collaboration (e.g., sui generis rights for databases), then clauses to regulate ownership of IP rights could be included. Data protection policy. This describes the data protection policy at a data space level, referring to the obligations of the data space as a controller when processing the data of the data space participants. Additionally, this policy may also include references to the potential role of data spaces as processors of personal data to be shared within the data space, identifying the corresponding responsibilities of the parties and the data space as prescribed by law. The data space may provide a technical framework that ensures the processing operations in the data space comply with GDPR by design. Adherence to this framework can additionally be made legally binding. Templates for Data Processing agreements (e.g., iSHARE) or Data Exchange agreements (e.g., iSHARE) can also be provided. Technical standards. These outline and/or enforce specific technical standards for participants in the data space. The general terms and conditions may also restrict the data models and formats to be used in the data space. Cybersecurity and risk management policies. These describe the rules and procedures for the protection of technology and information assets that need to be protected, along with other identified risks to the data space infrastructure or participants. Complaints policy and dispute resolution rules. These describe the rules and procedures for filing a complaint. Rules can also be included for resolving disputes between data space participants, including with the data space governing authority. The areas that the general terms and conditions regulate at the transaction level include (for example): Common elements in the terms and conditions of a data contract—Data spaces can coordinate and harmonise the terms and conditions of Data-Sharing agreements and Service agreements by introducing common elements (e.g., a limited set of data licenses or including only open data licenses) or prohibiting certain clauses (e.g., the inability to charge for the use of data). Examples of the agreement-specific clauses in the general terms and conditions are listed below. For conceptual clarity, we distinguish between the general terms that relate to the data space level and the data transaction level. Agreement-specific clauses related to the data space level Definitions (defining the roles of data space participants as well as potential third parties) Role-specific conditions (rights and obligations corresponding to the role), Responsibilities Fees and costs Confidentiality IP rights Data protection Accession policy (whether new data participants can join a data space, what eligibility criteria they need to meet, whether there is a maximum number of participants, etc.) Technical standards and commitments (technical standards with which a party has to comply to make transactions and activities in the data spaces) Cybersecurity and risk management policies Complaints policy and dispute resolution rules Agreement-specific clauses related to the transaction level General conditions for data sharing Standardised licences model for data usage rights – the general terms and conditions may limit the choice of licence or offer data providers a limited set of standardised licences. Standardisation refers to limiting the number or content of clauses. The advantage of including standardised licences is the reduction of transaction costs and increased scalability of the data space. Examples of types of licences may include: No limitations (the data product can be used without restrictions) Resharing with data space participants/internal use only Non-commercial use only Data enrichment before resharing Data can be enriched with the data recipient’s own data Data can be enriched with data from others Data can be enriched with the data recipient’s own data before resharing on a non-commercial basis Data can be enriched with data of others before resharing on a non-commercial basis Ad hoc-licenses (as determined by the parties) Standardised terms and conditions for data products - the agreement establishes mandatory terms and conditions to be included in the data product contract. It ensures that transactions between data provider and user take place on the basis of common terms and conditions, reducing transaction costs and increasing legal interoperability between transactions. Any terms and conditions can be the object of standardisation, from clauses on fees to clauses related to the rights of third parties on data. Mechanisms to calculate fees (if applicable)
Agreements related to enabling Service	As part of the provision of the technical infrastructure constituting the data space, Data Space Governing Authority could provide different distinctive services as part of the capabilities offered by the data space. The Blueprint adopts a technical understanding of services as the implementation of capabilities. These are classified as Federation Services, Participant Agent Services, and Value Creation Services (see Services for Implementing Technical Building Blocks for more details). When looking at it from a contractual perspective, it remains often to the parties to characterise a transaction as “provision of services”, and the substance of the term may vary depending on the legal context in which the term is used (e.g., under tax law, the characterisation of a transaction as a service is defined more narrowly and with defined cretaria than may be the case for other purposes). Services can be generally understood as performance of actions, immaterial and are generally a residual category negatively defined (e.g., under Art 57 TFEU, services are defined as economic transactions not “goverened by the provisions relating to freedom of movement for goods, capital and persons”). For present purposes, it is relevant to specify that “technical services” within the meaning of the Blueprint may not be the object of a contractual relationship (i.e., covered by the General Terms & Conditions). This is the case when they are considered ancillary to the main purpose of a contract - e.g., technical functionalities necessary to provide access to a data space. Alternatively, they may be mentioned as part of the contractual obligations that the Data Governance Authority commits to as part of the contract (i.e., with clauses in this case including provisions typical for Service-Level Agreements). A different scenario, discussed under the term “Agreements related to Enabling Services”, is services that are externalised to third parties. These services reflect the variety of services included in the above taxonomy. The general clauses that may be found in such contracts are discussed below in Service agreements.

Founding agreement

The founding agreement establishes the data space and its governance authority. The agreement is entered into by the founding members of the data space initiative (i.e., the initial data space participants). It sets out the purpose for which the data space is created. Different organisational forms are possible, and different specific legal instruments can be used depending on the organisational form, including:

Articles of Association or Statutes - these are used to establish the data space as a separate legal entity. The statute may allow the onboarding of new members by allowing external parties to sign the statute.
Consortium agreements, joint ventures, strategic cooperation, and other cooperation agreements - the data space is not incorporated, with no new legal entity created for that purpose. Any natural or legal person may become a member of the data space by signing a founding agreement (e.g., Consortium agreement).

For further information, see the Organisational Form and Governance Authority building block.

The agreement-specific clauses may include:

Background and purpose (why the data space is created)
Identification of the parties (members of the data space initiative)
General responsibilities and liability (in some cases - e.g., in joint ventures)
Reference to the chosen governance models.
The admission policy for data space members—the Founding agreement identifies the initial data space members, as outlined in the signatories (i.e., the parties of the data space initiative), who will be part of the governing body of the data space. It may also allow additional members to join the governance of the data space in the future, specifying the necessary conditions, qualifications, and requirements. The manner in which this is implemented in practice depends on the specific legal form that a data space assumes. An example of an artefact used to signal the intention to join a data space as a member can be the Accession agreement (SITRA Rulebook).

General Terms and Conditions

The general terms and conditions serve as an agreement providing legal enforceability to various elements of the governance framework (e.g., mandating compliance with a specific process). These terms make it binding on all data space participants. In some instances, they can be included in the founding agreement or at least directly referenced by it.

The general terms and conditions allow data spaces to regulate interactions at the data space level. They create and define the roles and responsibilities of the data space participants, including: the data space governance authority, data provider, data recipient, and service providers (data-related services, trust framework provider, management of identities, etc.). When a data space is established as a legal entity, the agreement may cover both the liability between the data space participants and the liability between the participant and the legal entity.

The general terms and conditions can serve as the framework for data transactions, namely the interactions (i.e. rights, responsibilities, liabilities, and obligations) of the data transaction participants. They do so by introducing common elements (e.g., a limited set of standard clauses or typologies of licences—see further in the data transaction agreements section) to improve legal interoperability and reduce transaction costs, ultimately reducing complexity and the possibility of conflict.

The areas that the general terms and conditions regulate at the data space level include:

· Admission policy for data space participants. This describes whether new participants are accepted, the conditions and eligibility criteria that parties must meet to join a data space, the conditions to remain a data space participant, and the procedures for the removal of an existing participant. Data space participants join a data space by accepting the terms and conditions.

· Intellectual property policy. At a minimum, this specifies that none of these agreements should be construed as an assignment of IP rights; instead, non-exclusive licenses are granted. If new IP rights may emerge from collaboration (e.g., sui generis rights for databases), then clauses to regulate ownership of IP rights could be included.

Data protection policy. This describes the data protection policy at a data space level, referring to the obligations of the data space as a controller when processing the data of the data space participants. Additionally, this policy may also include references to the potential role of data spaces as processors of personal data to be shared within the data space, identifying the corresponding responsibilities of the parties and the data space as prescribed by law. The data space may provide a technical framework that ensures the processing operations in the data space comply with GDPR by design. Adherence to this framework can additionally be made legally binding. Templates for Data Processing agreements (e.g., iSHARE) or Data Exchange agreements (e.g., iSHARE) can also be provided.

Technical standards. These outline and/or enforce specific technical standards for participants in the data space. The general terms and conditions may also restrict the data models and formats to be used in the data space.
Cybersecurity and risk management policies. These describe the rules and procedures for the protection of technology and information assets that need to be protected, along with other identified risks to the data space infrastructure or participants.
Complaints policy and dispute resolution rules. These describe the rules and procedures for filing a complaint. Rules can also be included for resolving disputes between data space participants, including with the data space governing authority.

The areas that the general terms and conditions regulate at the transaction level include (for example):

Common elements in the terms and conditions of a data contract—Data spaces can coordinate and harmonise the terms and conditions of Data-Sharing agreements and Service agreements by introducing common elements (e.g., a limited set of data licenses or including only open data licenses) or prohibiting certain clauses (e.g., the inability to charge for the use of data).

Examples of the agreement-specific clauses in the general terms and conditions are listed below. For conceptual clarity, we distinguish between the general terms that relate to the data space level and the data transaction level.

Agreement-specific clauses related to the data space level

Definitions (defining the roles of data space participants as well as potential third parties)
Role-specific conditions (rights and obligations corresponding to the role),
Responsibilities
Fees and costs
Confidentiality
IP rights
Data protection
Accession policy (whether new data participants can join a data space, what eligibility criteria they need to meet, whether there is a maximum number of participants, etc.)
Technical standards and commitments (technical standards with which a party has to comply to make transactions and activities in the data spaces)
Cybersecurity and risk management policies
Complaints policy and dispute resolution rules

Agreement-specific clauses related to the transaction level

General conditions for data sharing
Standardised licences model for data usage rights – the general terms and conditions may limit the choice of licence or offer data providers a limited set of standardised licences. Standardisation refers to limiting the number or content of clauses. The advantage of including standardised licences is the reduction of transaction costs and increased scalability of the data space. Examples of types of licences may include:
- No limitations (the data product can be used without restrictions)
- Resharing with data space participants/internal use only
- Non-commercial use only
- Data enrichment before resharing
Data can be enriched with the data recipient’s own data
Data can be enriched with data from others
Data can be enriched with the data recipient’s own data before resharing on a non-commercial basis
Data can be enriched with data of others before resharing on a non-commercial basis
Ad hoc-licenses (as determined by the parties)
Standardised terms and conditions for data products - the agreement establishes mandatory terms and conditions to be included in the data product contract. It ensures that transactions between data provider and user take place on the basis of common terms and conditions, reducing transaction costs and increasing legal interoperability between transactions. Any terms and conditions can be the object of standardisation, from clauses on fees to clauses related to the rights of third parties on data.
Mechanisms to calculate fees (if applicable)

Agreements related to enabling Service

As part of the provision of the technical infrastructure constituting the data space, Data Space Governing Authority could provide different distinctive services as part of the capabilities offered by the data space. The Blueprint adopts a technical understanding of services as the implementation of capabilities. These are classified as Federation Services, Participant Agent Services, and Value Creation Services (see Services for Implementing Technical Building Blocks for more details). When looking at it from a contractual perspective, it remains often to the parties to characterise a transaction as “provision of services”, and the substance of the term may vary depending on the legal context in which the term is used (e.g., under tax law, the characterisation of a transaction as a service is defined more narrowly and with defined cretaria than may be the case for other purposes). Services can be generally understood as performance of actions, immaterial and are generally a residual category negatively defined (e.g., under Art 57 TFEU, services are defined as economic transactions not “goverened by the provisions relating to freedom of movement for goods, capital and persons”).

For present purposes, it is relevant to specify that “technical services” within the meaning of the Blueprint may not be the object of a contractual relationship (i.e., covered by the General Terms & Conditions). This is the case when they are considered ancillary to the main purpose of a contract - e.g., technical functionalities necessary to provide access to a data space. Alternatively, they may be mentioned as part of the contractual obligations that the Data Governance Authority commits to as part of the contract (i.e., with clauses in this case including provisions typical for Service-Level Agreements).

A different scenario, discussed under the term “Agreements related to Enabling Services”, is services that are externalised to third parties. These services reflect the variety of services included in the above taxonomy. The general clauses that may be found in such contracts are discussed below in Service agreements.

3.4.2 Data-sharing agreements

Data-sharing agreements encompass all agreements exclusively binding the parties involved in a specific data transaction and regulating their mutual obligations and rights. The Blueprint introduces a particular type of data-sharing agreement: the data product contract. However, it should be noted that any agreement concerning the sharing of data should be considered under this category, and the information provided below may, therefore, be relevant when drafting such an agreement. In the following paragraphs, exclusive reference is made to the data product contract.

3.4.2.1 Data product contract

The data product contract is a legal agreement that sets out the terms and conditions under which a data product is made available. In turn, a data product is defined as “a data-sharing unit, bundling resources (data and/or value-creation services) and metadata that describes the license terms, the resources, and other information in a machine-readable way.” (see the Data Space Offering building block).

The agreement is closely linked to the Data Product building block and the Access & Usage Policies Enforcement building block. In most cases, data providers will make data available subject to specific terms and conditions, or, as an alternative, the data space may include a list of possible data licences in the general terms and conditions from which either the data provider or data recipient can choose. In other instances, a potential data consumer might request access to energy consumption data and specify their preferred predefined licence. Following the request, the data provider can either approve or decline the sharing of the data. Concrete examples of a data product agreement with instructions on its technical implementation, see Data Usage Agreement by GAIA-X.

Some clauses to be included:

Identification of the data
Acceptable purposes (purposes for which the data product can be used)
Restrictions of use for the data product
Usage rights of the data product
Termination of the contract
Terms related to the use of derived material
Fees and monetisation
Data security
Clauses related to third-party rights (data protection, intellectual property rights, confidentiality)

Legal aspects to consider when designing data products:

Lawful source of data/content: when the data represents copyright-protected content, under certain circumstances, the data space may be liable for copyright infringement. Various contractual clauses address the risks associated with this liability: warranties (e.g., the data provider warrants that there are no third-party claims over the data and that all due diligence procedures have been carried out to verify this), allocation of liability, and indemnities. These clauses may be included in the accession agreement when vetting new participants or in the data product contract itself. Regardless of how liability is allocated, uncertainty regarding third-party claims over the data can deter data sharing and reduce trust.
Processing of personal data: (see the Regulatory Compliance building block)
Compulsory B2B data-sharing contracts: if data holders make data available in accordance with an obligation under EU law, the terms and conditions for making this data available must be FRAND (fair, reasonable and non-discriminatory) (Chapter 3 Data Act). It also regulates other important clauses, such as compensation, dispute settlement provisions and technical protection measures.
Unilateral-imposed B2B (private) data sharing: unilateral terms and conditions regarding data availability (regulating access as well as, inter alia, liability or remedies) are non-binding to the extent that they are deemed unfair (Chapter 4 Data Act). To determine whether a clause is unfair, refer to Art 13.
Applicability of sectoral regulation: (Chapter 2 of the Data Act for IoT data) or the need for compliance with horizontal regulations (e.g., competition law - see Regulatory Compliance).
Jurisdiction and applicable law: There are various rules concerning which law applies to the contract—i.e., choice of law—and which courts have jurisdiction over potential disputes—i.e., choice of forum. Each contract should include clauses that regulate both aspects, and the parties to a contract can generally agree among themselves. These choices can significantly impact how the contract underlying the data transaction is interpreted. However, it is important that there is alignment between, for example, data product contracts and the general terms and conditions of a data space, which are likely to be directly referenced in the data product contract itself. For this reason, it may be desirable to harmonise matters of jurisdiction and applicable law across all agreements within the contractual framework. Divergences, however, are possible. The following considerations should be noted:
- Jurisdiction: there is a free choice of jurisdiction unless the contract is deemed null and void under the law of the selected state, or unless the contract is concluded with a consumer and the commercial party conducts activities in the consumer's domicile. If a contract is deemed null and void, or if the parties fail to specify the jurisdiction, then jurisdiction is determined by law (see Brussels Ibis Regulation).
- Applicable law: the parties are free to determine the law governing their contract. In the case of contracts with consumers, the choice of law will not have the effect of derogating from the mandatory consumer protection provisions in the state where the consumer has their habitual residence. In the absence of a choice, the applicable law will be determined by legislation (see Rome I Regulation).
Smart contracts: Smart contracts can help establish trust in a data space by automatically enforcing legal obligations through technical means. They are particularly useful in enhancing trust among parties involved in a data transaction, mitigating the risks of contractual breaches, increasing efficiency, and reducing costs. The term 'smart contract' can also be misleading. A smart contract does not presuppose the existence of a legally valid and enforceable contract, whether in natural language or otherwise; rather, it enables the technical enforceability of contracts and can be used to formalise legal agreements, contract negotiation, and execution. Smart contracts can also serve as a technical protection measure to prevent unauthorised access to data. When smart contracts are used in the context of executing an agreement to make data accessible, the Data Act now imposes a set of essential requirements that the data provider must comply with (Data Act Art 36 - Regulatory Compliance BB). In some jurisdictions, the deployment of a smart contract may suffice to support the existence of a legal relationship—e.g., the parties can fulfil the requirements of national contract law by relying on the smart contract as evidence of the offer, acceptance, and intention to be legally binding. The prevailing practice in the respective sector may be used as external evidence to support the intention to enter into a legally binding agreement (e.g., some sectors may routinely use smart contracts to exchange data). In any case, it is advisable for the sake of legal certainty to always generate a separate document written in natural, concise and simple language that outlines the main elements of the contract and the mutual obligations that the contract supports. In this regard, it should be noted that smart contracts often only enforce certain obligations of the underlying contract (provided such a contract exists). For this reason, relying on contracts offers additional benefits in expanding access to judicial mechanisms and providing a broader range of enforcement options (i.e., courts). If smart contracts are deployed in a data space, they must comply with the essential requirements of Art 33 of the Data Act, aimed at enabling interoperability of tools for automating the execution of data-sharing agreements (see in particular Art 33(1)(d)), as well as Art 36 of the Data Act, which mandates a series of essential requirements for smart contracts (e.g., robustness and access control, safe termination and interruption etc.).

3.4.3 Services agreements

Services Agreements need to define the terms between service providers and consumers. These agreements establish clear, mutually agreed-upon conditions regarding the provision, access, use, and compliance of services, formalising the terms under which services are provided. Due to the wide range of services available in a data spaces - i.e., services related to data or to enabling functionalities - service agreements can vary significantly in their content. As a result, the clauses for service agreements are described in more general terms below.

Key elements encompassed in Services Agreements include:

Scope of Services:
A typical Service Agreement encompasses a comprehensive description of the scope of services, precisely defining the nature, purpose, and boundaries of the services provided. This includes the types of data to be processed, functional capabilities of the services, interface standards, and technical interoperability requirements. Services may span data discovery, access, transformation, enrichment, or analytics.
Roles and Responsibilities:
The agreement clearly articulates the roles and responsibilities of involved entities—namely, the service providers, data consumers, and intermediaries. These roles are tied to specific operational duties, including service provisioning, compliance enforcement, and auditability.
Access and Usage Rights:
Specifies authorized access procedures and use limitations, ensuring usage aligns with predefined policies and adheres to legal frameworks such as the GDPR and the Data Governance Act, fostering responsible data stewardship.
Service Level Agreements (SLAs):
To ensure service reliability and accountability, the agreement incorporates explicit Service Level Agreements (SLAs). These define performance metrics such as availability, latency, throughput, maintenance windows, incident handling procedures, and service restoration times. Remedies or compensations are also outlined in cases where service levels are not met.
Data Protection and Security:
Robust data protection and security measures are specified, including both technical (e.g., encryption, secure API gateways, identity verification) and organizational safeguards. This section also describes the processes for security incident response, data breach notifications, and continuous monitoring, thereby ensuring that data confidentiality, integrity, and availability are upheld at all times.
Compliance and Liability:
To support trust and ensure compliance with applicable laws and standards, the agreement outlines the parties’ obligations around regulatory compliance and liability. This includes audit rights, obligations for third-party subcontractors, mechanisms for dispute resolution, and any limitations or exclusions of liability—especially relevant in cross-border or multi-jurisdictional contexts.
Term, Termination, and Amendments:
Finally, the DSA defines contractual lifecycle elements, including the term and duration, renewal or extension clauses, termination rights, and the formal procedures for modifying the agreement. This adaptability is critical in dynamic data ecosystems where services and regulatory landscapes evolve continuously.

In some cases, the conditions under which a service is provided may be directly regulated in the General Terms and Conditions (this solution is adopted in SITRA Rulebook).

4. Co-creation questions

Which participants or actors are directly involved in which use cases, and what roles do they play?
What legal agreements are necessary for governing data sharing, usage rights, and liabilities across different use cases?
What are the data space agreements necessary for the foundation of the data space?
Which legislative frameworks are relevant when drafting contractual clauses?
What are the basic organisational policies that need to be implemented by the governance authority in the Rulebook?

5. Further reading

Sitra, ‘Rulebook for a fair data economy Part 1 & 2’ (2022) Rulebook for a fair data economy - Sitra.
Steinbuss et al., ‘IDSA Rule Book’ (2020) International Data Spaces Association https://doi.org/10.5281/zenodo.5658294.
ELI, ‘ALI-ELI Principles for a Data Economy - Data Transactions and Data Rights' (2017) ELI Final Council Draft
Support Center for Data Sharing, 'B.1 - Report on collected model contract terms' (2019) SMART 2018/1009.
Data Sharing Coalition, 'Data Sharing Canvas - a stepping stone towards cross-domain data sharing at scale' data-sharing-canvas.pdf (coe-dsc.nl).
United Nations Commission on International Trade Law, ‘Default rules for data provision contracts’ (2023) Working Group IV https://documents.un.org/doc/undoc/gen/v24/066/85/pdf/v2406685.pdf.
United Nations Commission on International Trade Law, ‘UNCITRAL Model Law on Automated Contracting finalized by the UN Commission on International Trade Law’ (2024) (adopted but still to be published) - temporary link https://unis.unvienna.org/unis/en/pressrels/2024/unisl362.html

5.1 Literature on data sharing

Katy McKinney-Bock, Data Sharing, Licenses, and Agreements, Research Report A Better Deal for Data	2023	2310-data_sharing_licenses.pdf
Australian Research Data Commons, Data sharing agreement development guidelines, Research Report	2023	Data sharing agreement development guidelines
Misha Benjamin, Paul Gagnon, Negar Rostamzadeh, Chris Pal, Yoshua Bengio, Alex Shee, Towards Standardization of Data Licenses: The Montreal Data License	2019	[1903.12262] Towards Standardization of Data Licenses: The Montreal Data License
Alexandra Giannopoulou, ‘’Understanding Open Data Regulation: An Analysis of the Licensing Landscape’’ in: van Loenen, B., Vancauwenberghe, G., Crompvoets, J. (eds) Open Data Exposed. Information Technology and Law Series, vol 30.	2018	Understanding Open Data Regulation: An Analysis of the Licensing Landscape \| SpringerLink
Paul Jurcys, Chris Donewald, Jure Globocnik, Markus Lampinen, ‘’My Data, My Terms: A Proposal for Personal Data Use Licenses’’, Harvard Journal of Law & Technology Volume 33	2020	Microsoft Word - [1.4 Production Edited] Paulius Data licenses-HJOLTDigest-Feb20.docx
Emad Alamoudi, Rashid Mehmood, Wajdi Aljudaibi, Aiiad Albeshri & Syed Hamid Hasan ‘’Open Source and Open Data Licenses in the Smart Infrastructure Era: Review and License Selection Frameworks’’ in: Mehmood, R., See, S., Katib, I., Chlamtac, I. (eds) Smart Infrastructure and Applications.	2019	Open Source and Open Data Licenses in the Smart Infrastructure Era: Review and License Selection Frameworks \| SpringerLink
Martynas Mockus and Monica Palmirani, ‘’Open Government Data Licensing Framework’’, in: Kő, A., Francesconi, E. (eds) Electronic Government and the Information Systems Perspective.	2015	978-3-319-22389-6_21
Yaniv Benhamou & Mélanie Dulong de Rosnay, ‘’Open Licensing and Data Trust for Personal and Non-Personal Data: A Blueprint to Support the Commons and Privacy’’, IIC	2025	Open Licensing and Data Trust for Personal and Non-Personal Data: A Blueprint to Support the Commons and Privacy \| IIC - International Review of Intellectual Property and Competition Law
Eleonora Bassi, Marco Ciurcina, Juan Carlos De Martin, Selina Fenoglietto , Licensing of digital commons including personal data, DECODE project deliverable	2018	Licensing of digital commons including personal data
Xiaohua Zhu(B) , Christy Thomas, Jenny C. Moore , and Summer Allen, ‘’Open Government Data Licensing: An Analysis of the U.S. State Open Government Data Portals’’ In: Toeppe, K., Yan, H., Chu, S.K.W. (eds) Diversity, Divergence, Dialogue.	2021	Open Government Data Licensing: An Analysis of the U.S. State Open Government Data Portals
Sam Grabus and Jane Greenberg, ‘’The Landscape of Rights and Licensing Initiatives for Data Sharing’’, Data Science Journal 18	2019	The Landscape of Rights and Licensing Initiatives for Data Sharing
Stefan Reichenbach and Debbie Lawrence ‘’Does AI change everything in data licensing? ‘’, Journal of Securities Operations & Custody	2025	Does AI change everything in data licensing? - EBSCO
Data.europa, Report on licence usage on the http://data.europa.eu portal	2025	Report on licence usage on the data.europa.eu portal \| data.europa.eu
Paige Backlund Jarquín, Data Sharing: Creating Agreements, Community Health Data and Monitoring Committee Report	2012	tips_for_creating_data_sharing_agreements_for_partnerships.pdf

5.2 Documents and guidelines to implement the building blocks

Commission Recommendation on non-binding model contractual terms on data access and use and non-binding standard contractual clauses for cloud computing contracts.
Data contract automation tools
- For data contract generation - Prometheus-X (Contract)
Data license selection tool
- ELRA License Wizard - http://wizard.elda.org/principal.php
- Licence Selector License Selector (ufal.github.io)
- List of Model Contractual Clauses
  - This work is complemented by references to templates and practical guidance for drafting contracts within data spaces. A key supporting tool is the List of Contractual Clauses, which compiles existing standard clauses relevant to data sharing and classifies them according to their main characteristics—such as commercial or non-commercial use, attribution requirements and permissions to modify the data.
    To facilitate navigation, the licenses are colour-coded to indicate their relative position along a spectrum of openness: permissive (green), copyleft (blue), private pool (yellow), and restrictive (red). This categorisation follows the broad framework developed by the Reusable Data Project1, which defines:
    Permissive: Licenses that allow modification and redistribution for both commercial and non-commercial purposes without substantial restrictions or obligations.
    Copyleft: Licenses that permit re-use but require derivative works to be distributed under the same license.
    Private pool: Licenses that require data users to contribute their own data to access the licensed data or to make derivative data available only within a specific community of users.
    Restrictive: Licenses that grant only limited rights for access or re-use, prohibiting modification or imposing specific conditions on how the data may be used.
    The adopted classification enables comparison across different licensing models, helping stakeholders identify the most appropriate license for a given data-sharing context/data space and the specific needs of intended users.
  - The list can be found here: List of Contractual Clauses

6. Glossary

Term	Definition
Contract	A formal, legally binding agreement between two or more parties with a common interest in mind that creates mutual rights and obligations enforceable by law.
Contractual framework	The set of legally binding agreements that regulates the relationship between data space participants and the data space (institutional agreements), transactions between data space participants (data-sharing agreements) and the provision of services (service agreements) within the context of a single data space.
Data product contract	A legal contract that specifies a set of rights and duties for the respective parties that will perform the roles of the data product provider and data product consumer.
Data space agreement	A contract that states the rights and duties (obligations) of parties that have committed to (signed) it in the context of a particular data space. These rights and duties pertain to the data space and/or other such parties.
General terms and conditions	An agreement defining the roles, relationships, rights and obligations of data space participants.
Smart contract	A computer program used for the automated execution of an agreement or part thereof, using a sequence of electronic data records and ensuring their integrity and the accuracy of their chronological ordering (Art 2(39) Data Act)

License Name	Description	License text	Attribution	Commercial use	Modify
Open Data Commons Open Database License (ODbL)	Allows: · To copy, distribute and use the database. · To produce works from the database. · To modify, transform and build upon the database. Requires: · Attribution · Offering of any adapted database or works under the ODbl. · Distribution of a version of the database without technological measures, if one distributes also a version implementing technological measures.	https://opendatacommons.org/licenses/odbl/1-0/	Yes	Yes	Yes
Open Data Commons Attribution License (ODC-By)	Allows: To copy, distribute and use the database. To produce works from the database. To modify, transform and build upon the database. Requires: · Attribution	https://opendatacommons.org/licenses/by/1-0/	Yes	Yes	Yes
Open Data Commons Public Domain Dedication and License (PDDL)	Allows: To copy, distribute and use the database. To produce works from the database. To modify, transform and build upon the database. No further requirements	https://opendatacommons.org/licenses/pddl/1-0/	No	Yes	Yes
EtaLab Open License	Allows: · To reproduce, copy the information. · To adapt, modify, retrieve and transform the information in order to create “derived information”, products and services. · To share, disseminate, redistribute, publish and transmit the information. · To exploit it for commercial purposes, e.g., by combining it with other information, or by including it in his/her own product or application. Requires: · Attribution	https://www.etalab.gouv.fr/wp-content/uploads/2018/11/open-licence.pdf	Yes	Yes	Yes
UK Open Government License	Allows: · To copy, publish, distribute and transmit the Information; · To adapt the Information; · To exploit the Information commercially and non-commercially for example, by combining it with other Information, or by including it in your own product or application. Requires: · Attribution	https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/	Yes	Yes	Yes
UK Non Commercial Government License	Allows: · To copy, publish, distribute and transmit the Information; · To adapt the Information; · To exploit the Information for Non-Commercial purposes for example, by combining it with other information in your own product or application. Prohibits: · The exercise any of the rights granted to you by the licence in any manner that is primarily intended for or directed toward commercial advantage or private monetary compensation.	https://www.nationalarchives.gov.uk/doc/non-commercial-government-licence/version/2/	No	No	Yes
Open data license Statistics Belgium	Allows: · To reproduce, copy, publish and transfer the "Information"; - To disseminate and redistribute the "Information"; · to use the "Information" to edit, update, extract and modify information, in particular to "create derivative data"; · To use the "Information" for commercial purposes, e.g. by combining it with other "data" or by using it in one's own product or application. Requires: · Attribution	https://statbel.fgov.be/sites/default/files/files/opendata/Licence%20open%20data_EN.pdf	Yes	Yes	Yes
Ishare General license: Unrestricted	Allows: · Data to be used and (re-)shared without further limitations and/or conditions No further requirements		No	Yes
Ishare General license: Resharing with Adhering Parties	Allows: · Data labeled with this License to exclusively be (re-)shared with and used by Adhering Parties Requires: · Adherence to the rules of the iSHARE Framework.		No
Ishare General license: Internal use	Allows: · Data labeled with this License to be used for internal use only Requires: · Data not be shared with or used by any other party, for both commercial and non-commercial purposes The above limitation applies to the Data or Dataset itself, and does not extend to any products and/or services developed or generated by such internal use of the Data. Such products or services may be put to commercial use.		No	No
Ishare General license: Internal use generated insights/know how	Allows: Data labeled with this License to be used for internal use only Requires: Data not be shared with or used by any other party, for both commercial and non-commercial purposes The above limitation applies to the Data or Dataset itself, and does not extend to any products and/or, services, insights/know-how or similar developed or generated by such internal use of the Data. Such insights/know-how or similar may be put to commercial use.		No	No
Ishare General license: Non Commercial use	Allows: · Data labeled with this License to be used and (re-)shared freely, provided that such use or sharing occurs for strictly non-commercial purposes. Prohibits: · commercial use of or (end-)purpose for the Data is. This includes without limitation: · any use and/or (re-)sharing of the Data for the purpose of receiving compensation or generating revenue; and · use and/or (re-)sharing of the Data for the purpose of developing products, services or similar for commercial use.		No	No
Ishare General License: Enrich with own data	Allows: · Data to be enriched, but only with data generated by the direct recipient of the Data. Prohibits: · Enrichment using data provided by third parties is strictly prohibited unless such is allowed under another applicable License.
Ishare General License: Enrich with data generated directly by third parties	Allows: · Data to be enriched, but only with data generated by the discloser and/or the direct provider of the Data. Data provided by third parties may be used for enrichment but only if the data was generated by such third parties directly. Prohibits: Enrichment using data provided by third parties that was not generated by such third parties, unless such is allowed under another applicable License.
Ishare General License: Enrich with data provided by third parties	Allows: · Data to be enriched, but only with data generated by third parties. Prohibits: · Enrichment using data generated by the direct recipient of the Data, unless such is allowed under another applicable License.
Ishare General License : Use to service Entitled Party	Allows: · Data to only be used and processed insofar this is strictly necessary for the provision of the specific service(s) to an Entitled Party under an agreement in the context of which the Data is shared. Prohibits: · Any other use or processing
Ishare General License : Determined between Parties	Allows: · Data to be shared under specific conditions and under the applicability of specific provisions agreed to between the exchanging parties in a separate agreement. Requires: · Care to be taken at all times to reference the relevant agreement and act in full compliance with the relevant agreement.
Ishare Country License: Use And process in a country	Allows: · Data to only be used and processed within the country/countries corresponding to the specified ISO 3166-1 alpha-2 two-letter country code (e.g. NL, BE).		No	Yes
Ishare Industry License: Use and process within industry	Allows: Data labeled to only be used and processed within the industry corresponding to the specified ISIC industry code.		No
Ishare Certification License: Use and process in full compliance with ISO 27001	Allows: · Data to only be used and processed in full compliance with the ‘ISO 27001 - Information Security Management’ certification standard, by organizations that maintain such certification.
Ishare Certification License: Use and process in full compliance with ISO 9001	Allows: · Data to only be used and processed in full compliance with the ‘ISO 9001 - Quality Management’ certification standard, by organizations that maintain such certification.
Ishare Certification License: Use and process in full compliance with ISO 14001	Allows: · Data to only be used and processed in full compliance with the ‘ISO 14001 - Environmental Management’ certification standard, by organizations that maintain such certification.
Ishare Certification License: Use and process in full compliance with ISO 45001	Allows: · Data to only be used and processed in full compliance with the ‘ISO 45001 - Occupational Health and Safety’ certification standard, by organizations that maintain such certification.
Ishare Certification License: Use and process in full compliance with ISO 22000	Allows: · Data to only be used and processed in full compliance with the ‘ISO 22000 - Food Safety Management’ certification standard, by organizations that maintain such certification.
Ishare Certification License: Use and process in full compliance with GDPR	Allows: · Data to only be used and processed in full compliance with the ‘GDPR Certification’ standard as meant in article 42 of the European General Data Protection Regulation, by organizations that maintain such certification.
Ishare Certification License: Utilize in case HIPAA Compliance is in place	Allows: Data to only be utilized in case certification HIPAA Compliance - Health Insurance Portability and Accountability Act is in place
Ishare Certification License: Use and process in full compliance with SOC 2	Allows: · Data to only be used and processed in full compliance with the ‘SOC 2 - Service Organization Control Type 2’ certification, by organizations that maintain such certification.
Ishare Certification License: Use and process in full compliance with PCI DSS	Allows: · Data to only be used and processed in full compliance with the ‘PCI DSS - Payment Card Industry Data Security Standard’ certification, by organizations that maintain such certification.
Ishare Certification License: Use and process in full compliance with CSA STAR	Allows: · Data to only be used and processed in full compliance with the ‘CSA STAR - Cloud Security Alliance Security Trust Assurance and Risk’ certification, by organizations that maintain such certification.
Montreal Data License	Allows: · Access the Data, where access means to access, view and/or download the Data · view and evaluate data (evaluation algorithms may be exposed to it, but no Untrained Models). · Creation of Tagged Data. · Distribution of the Data, i.e. to make all or part of the Data available to Third Parties under the same terms as those of this License. · Creation of a Representation of the Data. Licensed Rights in Conjunction with Models. · Benchmark: To access the Data, use the Data as training data to evaluate the efficiency of different Untrained Models, algorithms and structures, but excludes reuse of the Trained Model, except to show the results of the Training. This includes the right to use the dataset to measure performance of a Trained or Untrained Model, without however having the right to carry-over weights, code or architecture or implement any modifications resulting from the Evaluation. · Research: To access the Data, use the Data to create or improve Models, but without the right to use the Output or resulting Trained Model for any purpose other than evaluating the Model Research under the same terms. · Publish: To make available to Third Parties the Models resulting from Research, provided however that third parties accessing such Trained Models have the right to use them for Research or Publication only. · Internal Use: To access the Data, use the Data to create or improve Models and resulting Output, but without the right to Output Commercialization or Model Commercialization. The Output can be used internally for any purpose, but not made available to Third Parties or for their benefit. · Output Commercialization: To access the Data, use the Data to create or improve Models and resulting Output, with the right to make the Output available to Third Parties or to use it for their benefit, without the right to Model Commercialization. · Model Commercialization: Make a Trained Model itself available to a Third Party, or embodying the Trained Model in a product or service, with or without direct access to the Output for such Third Party.	https://arxiv.org/pdf/1903.12262	No	Not for data itself, but for the derived ai models and output	No
Community Data License Agreement – Permissive – Version 2.0	Allows: · A Data Recipient to use, modify, and share the Data. Requires: · A Data Recipient can share Data, with or without modifications, so long as the Data Recipient makes available the text of the agreement with the shared Data.	https://cdla.dev/permissive-2-0/	No	Yes	Yes
Community Data License Agreement – Sharing – Version 1.0	Allows: · To Use Data · To Publish Data. Requires: · If You Publish Data You Receive or Enhanced Data: i. The Data (including the Enhanced Data) must be Published under this Agreement in accordance with this Section 3; and ii. You must cause any Data files containing Enhanced Data to carry prominent notices that You have changed those files; and iii. If You Publish Data You Receive, You must preserve all credit or attribution to the Data Provider(s). Such retained credit or attribution includes any of the following to the extent they exist in Data as You have Received it: legal notices or metadata; identification of the Data Provider(s); or hyperlinks to Data to the extent it is practical to do so. · You may not restrict or deter the ability of anyone who Receives the Data (a) to Publish the Data in a publicly-accessible manner or (b) if the project has designated a Ledger for recording Data or grants of rights in Data for purposes of this Agreement, to record the Data or grants of rights in Data in the Ledger. · If You Publish Data You Receive, You must do so under an unmodified form of this Agreement and include the text of this Agreement, the name of this Agreement and/or a hyperlink or other method reasonably likely to provide a copy of the text of this Agreement. You may not modify this Agreement or impose any further restrictions on the exercise of the rights granted under this Agreement, including by adding any restriction on commercial or non-commercial Use of Data (including Your Enhanced Data) or by limiting permitted Use of such Data to any particular platform, technology or field of endeavor. Notices that purport to modify this Agreement shall be of no effect.	https://cdla.dev/sharing-1-0/	Yes	Yes	No
Open Use of Data Agreement, Version 1.0 O-UDA	Allows: · To use, modify, and distribute the Data Requires: To include with any Data redistributed all credit or attribution information received with the Data, and any Downstream Recipient to do the same	https://cdla.dev/open-use-of-data-agreement-v1-0/	Yes	Yes	Yes
Computational Use of Data Agreement v1.0 C-UDA	Allows: · To use, modify, and distribute the Data made available by the Data Provider for Computational Use Requires: · use of the Data solely for Computational Use. · Include include with any Data redistributed all credit or attribution information that received with the Data, and any Downstream Recipient to do the same · each recipient to whom the Data is redistributed is bound to the terms of the C-UDA.	https://cdla.dev/computational-use-of-data-agreement-v1-0/	Yes	Yes, for computational use	Yes, for computational use
Norwegian License for Open Government Data (NLOD)	Allows: · copying the information and distributing the information to others, · modifying the information and/or combining the information with other information, and · copying and distributing such changed or combined information. Requires: · Attribution	https://data.norge.no/nlod/en/2.0	Yes	Yes	Yes
Taiwan Government Data Open License - Version 1	Allows: · Data to be used by authorized users for any purpose, time, and region, non-exclusive, irrevocable, and fee-free, and the methods of use include reproduction, distribution, public transmission, public broadcasting, public dictation, public screening, public performance, editing, and adaptation, including but not limited to the development of derivatives of various products or services Requires: · The use of open data and subsequent derivatives provided by the user in accordance with these terms shall clearly indicate the relevant statement of the original data provider in a manner that meets the requirements of the "Disclaimer" shown in the attachment. Failure to fulfill the obligation to disclose the name shall be deemed to have not obtained the authorization of the open data from the beginning.	https://data.gov.tw/en/license	No	Yes	Yes
CC BY	Allows: · To Share — copy and redistribute the material in any medium or format for any purpose, even commercially. · To Adapt — remix, transform, and build upon the material for any purpose, even commercially. Requires: · Attribution	https://creativecommons.org/licenses/by/4.0/legalcode.en	Yes	Yes	Yes
CC BY-SA	Allows: To Share — copy and redistribute the material in any medium or format for any purpose, even commercially. To Adapt — remix, transform, and build upon the material for any purpose, even commercially. Requires: · Attribution · Share-alike when distributing adapted material	https://creativecommons.org/licenses/by-sa/4.0/legalcode.en	Yes	Yes	Yes
CC BY-NC	Allows: · To Share — copy and redistribute the material in any medium or format for non commercial purposes only · To Adapt — remix, transform, and build upon the material for non commercial purposes only Requires: · Attribution · No commercial uses	https://creativecommons.org/licenses/by-nc/4.0/legalcode.en	Yes	No	Yes
CC BY-NC-SA	Allows: To Share — copy and redistribute the material in any medium or format for non commercial purposes only To Adapt — remix, transform, and build upon the material for non commercial purposes only Requires: Attribution No commercial uses Share-alike when distributing adapted material	https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.en	Yes	No	Yes
CC BY-ND	Allows: To Share — copy and redistribute the material in any medium or format for any purpose, even commercially. Requires: Attribution No Derivatives/modifications	https://creativecommons.org/licenses/by-nd/4.0/legalcode.en	Yes	Yes	No
CC BY-NC-ND	Allows: To Share — copy and redistribute the material in any medium or format for non commercial purposes only Requires: Requires: Attribution No Derivatives/modifications No commercial uses	https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode.en	Yes	No	No
CC0	Public domain waiver, including all related and neighboring rights, to the extent allowed by law.	https://creativecommons.org/publicdomain/zero/1.0/legalcode.en	No	Yes	Yes
Data license Germany - Zero - Version 2.0	Allows: · Data to be copied, printed, presented, altered, processed and transmitted to third parties; · Data to be merged with own data and with the data of others and be combined to form new and independent datasets; · Data to be integrated in internal and external business processes, products and applications in public and non-public electronic networks. · Covers both commercial and non commercial use	https://www.govdata.de/dl-de/zero-2-0	No	Yes	Yes
Data license Germany – attribution – version 2.0	Allows: Data to be copied, printed, presented, altered, processed and transmitted to third parties; Data to be merged with own data and with the data of others and be combined to form new and independent datasets; Data to be integrated in internal and external business processes, products and applications in public and non-public electronic networks. Covers both commercial and non commercial use Requires: · Attribution · the annotation "Data licence Germany – attribution – Version 2.0" or "dl-de/by-2-0" referring to the licence text available at http://www.govdata.de/dl-de/by-2-0 , and · a reference to the dataset (URI).	https://www.govdata.de/dl-de/by-2-0	Yes	Yes	Yes
Flemish Government Data License	Allows: · To reuse the data for any lawful purpose, including reproducing, transmitting, publishing, adapting and commercially exploiting the product. Requires: · Attribution	https://www.vlaanderen.be/digitaal-vlaanderen/onze-diensten-en-platformen/open-data/voorwaarden-voor-het-hergebruik-van-overheidsinformatie/modellicentie-gratis-hergebruik	Yes	Yes	Yes
INSPIRE End User License	Allows: Personal, Non-commercial use only of data, excludes use internally within a business	https://www.ordnancesurvey.co.uk/documents/licensing/inspire-end-user-licence.pdf	No	No	Yes
Opendata.swiss Free Use license	Allows: · Data to be used for non-commercial and commercial purposes. · A reference to the source is recommended (author, title and link to the dataset).	https://opendata.swiss/de/terms-of-use#terms_open	No	Yes	Yes
Opendata.swiss Free use. Must provide the source.	Allows: Data to be used for non-commercial and commercial purposes. Requires: · A reference to the source(author, title and link to the dataset).	https://opendata.swiss/de/terms-of-use#terms_open	Yes	Yes	Yes
Opendata.swiss Free use. Use for commercial purposes requires permission of the data owner.	Allows: · Data to be used for non-commercial · Data to be used for commercial purposes, provided permission has been obtained from the data provider. · A reference to the source is recommended (author, title and link to the dataset). Requires: · Permission from data provider for commercial uses	https://opendata.swiss/de/terms-of-use#terms_open	No	Yes, with permission from provider	Yes
Opendata.swiss Free use. Must provide the source. Use for commercial purposes requires permission of the data owner.	Allows: · Data to be used for non-commercial · Data to be used for commercial purposes, provided permission has been obtained from the data provider. Requires: · A reference to the source (author, title and link to the dataset). · Requires: · Permission from data provider for commercial uses	https://opendata.swiss/de/terms-of-use#terms_open	Yes	Yes, with permission from provider	Yes
CME Group licence	Allows: · To receive the Information from CME and the Data Provider; · To use the Information as permitted in the Schedules · To create limited derivative works based on the Information solely for its internal business purposes in accordance with the Information Policies, provided that each Licensee Group entity may only disclose any such derivative works internally and may not distribute any such derivative work to any third party without the prior written consent of CME. · CME may license the right to create or distribute certain derivative works beyond the scope of this Agreement under a separate license agreement Requires: · attribution	https://www.openbanking.org.uk/wp-content/uploads/Open-Licence.pdf	Yes	No	Yes
Open Banking Limited – Open Licence	Allows: · To copy, re-use, publish and distribute the Open Data · To exploit the Open Data for commercial and non-commercial purposes by, for example combining it with other information, or including it in your own products or services · To adapt the Open Data into different formats for the purposes of data mapping (or otherwise for display or presentational purposes). Requires: · Attribution · Not to change the content of any Open Data · Not to use or present the Open Data or any analysis of it in a way that is unfair or misleading, · Not call any API, or use or present the Open Data, in any way or for any purpose which is in breach of any rights of any third party	https://www.openbanking.org.uk/wp-content/uploads/Open-Licence.pdf	Yes	Yes	Yes (but no changes to the Open Data may be made)
Data Use Agreement for Open AI Model Development (DUA-OAI)	Allows: · Data User to use the Training Data solely for the purpose of Training the AI Model. · Data User to retain the Training Data for the duration of this Agreement. Requires: · Data User to delete all Training Data from its systems and records on termination of this Agreement (or based on the retention period set forth in Attachment A, if specified), except as required by applicable law. · Data User to make Trained Model publicly available under an Open Source License that includes a general disclaimer of liability in favor of the Data Provider	https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/msc/documents/presentations/CSR/DUA-OAI-1.pdf	No	Yes, if necessary for the purpose of training an identified AI Model	Yes, if necessary for the purpose of training an identified AI Model
Data Use Agreement for Data Commons (DUA-DC)	Allows: · Use of Contributor Data, solely for the purpose of providing the Services in accordance with the Agreement, including without limitation, to enable the Permitted Purposes set forth in Attachment H. · To access and use the Database and Database APIs for the Permitted Purpose (the “Database Right”) Prohibits: · The Operator from granting usage rights to any entity except other Commons Contributors, solely for purposes of enabling such Commons Contributors to exercise their rights in the Database (as defined in Section 5.2).	https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/msc/documents/presentations/CSR/DUA-DC-0.pdf	No	Yes, if solely for the purpose of providing the Services in accordance with the Agreement	Yes, if solely for the purpose of providing the Services in accordance with the Agreement

Term	Definition
Data Model	A structured representation of data elements and relationships used to facilitate semantic interoperability within and across domains, encompassing vocabularies, ontologies, application profiles and schema specifications for annotating and describing data sets and services. These abstraction levels may not need to be hierarchical; they can exist independently.
Data element	the smallest units of data that carry a specific meaning within a dataset. Each data element has a name, a defined data type (such as text, number, or date), and often a description that explains what it represents.
Data model provider	An entity responsible for creating, publishing, and maintaining data models within data spaces. This entity facilitates the management process of vocabulary creation, management, and updates.
Vocabulary service	A technical component providing facilities for publishing, editing, browsing and maintaining vocabularies and related documentation.
Meta-standard	A standard designed to define or annotate data models within a particular domain or across multiple domains. These meta-standards provide a framework or guidelines for creating and annotating other standards (data models), ensuring consistency, interoperability, and compatibility.
Vocabulary	A data model that contains basic concepts and relationships expressed as terms and definitions within a domain or across domains, typically described in a meta-standard like SKOS.
Ontology	A data model that defines knowledge within and across domains by modelling information objects and their relationships, often expressed in open metamodel standards like OWL, RDF, or UML.
Application Profile	A data model that specifies the usage of information in a particular application or domain, often customised from existing data models (e.g., ontologies) to address specific application needs and domain requirements.
Reference datasets	Reference data, such as code lists and authority tables, means data that are used to characterise or relate to other data. Such a reference data, defines the permissible values to be used in a specific field for example as metadata. Reference data vocabularies are fundamental building blocks of most information systems. Using common interoperable reference data is essential for achieving interoperability.
Data Schema	A data model that defines the structure, data types, and constraints. Such a schema includes the technical details of the data structure for the data exchange, usually expressed in metamodel standards like JSON or XML Schema.

Term	Definition
Consensus Protocol	The data exchange protocol that is globally accepted in a domain Explanatory Text: In some domains the data exchange protocols are ‘de facto’ standards (e.g. NGSI for smart cities).
Federated data spaces	A data space that enables seamless data transactions between the participants of multiple data spaces based on agreed common rules, typically set in a governance framework. Explanatory Text: The definition of a federation of data spaces is evolving in the data space community. A federation of data spaces is a data space with its own governance framework, enabled by a set of shared services (federation and value creation) of the federated systems, and participant agent services that enable participants to join multiple data spaces with a single onboarding step.
Geoquerying	Query involving geographical boundaries Explanatory Text: Data querying frequently needs to be restricted to a geographical area.
Transfer Process (TP)	A process that manages the lifecycle of data exchange between a provider and a consumer, involving, in example, states, as a minimum, REQUESTED, STARTED, COMPLETED, SUSPENDED, and TERMINATED.
Pull Transfer	A data transfer initiated by the consumer, where data is retrieved from the provider.
Push Transfer	A data transfer initiated by the provider, where data is sent to the consumer.
Non-Finite Data	Data that is defined by an infinite set or has no specified end, such as continuous streams.
Finite Data	Data that is defined by a finite set, such as a fixed dataset.

Term	Definition
Provenance	The place of origin or earliest known history of something. Usually it is the backwards-looking direction of a data value chain which is also referred to as provenance tracking
Traceability	The quality of having an origin or course of development that may be found or followed
Observability	The ability to monitor, measure and understand the internal states of processes through its outputs such as logs, metrics and traces.
Dataspace Protocol	The Eclipse data space Protocol is a set of specifications that enable secure, interoperable data sharing between independent entities by defining standardized models, contracts, and processes for publishing, negotiating, and transferring data within data space s. The current specification can be found at: https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol
Data Space Governance Authority	A governance authority refers to bodies of a data space that are composed of and by data space participants responsible for developing and maintaining as well as operating and enforcing the internal rules.

Dataspace Protocol States		What can be observed?
Catalog	A participant's interactions with the catalog, such as requesting the list of data products or viewing the details of a specific dataset.	For market analysis and business intelligence to, for example, track the popularity of data offerings Example: A data provider analyses which organizations are viewing its data products to identify potential new customers.
Contract Negotiation	The complete state cycle of the negotiation process, from the initial offer and counter-offers to the final acceptance and verification of the agreement.	Essential for legal evidence, audits, and dispute resolution. Example: In a conflict over usage rights, the log serves as irrefutable proof of the agreed-upon terms.
Transfer Process	The state changes of the transfer process on the Control Plane, such as 'requested', 'started', 'completed', or 'terminated'.	Links the contract to the technical execution; crucial for operational monitoring and billing. Example: A pay-per-use model uses the 'completed' state as the trigger for a billing cycle.

Entity	Criterion	Attribute/Claim	Possible Trust Sources
Participant (Legal Person - all roles)	The participant shall be uniquely identified.	Registration number of the legal person (typically issued by national bodies), which identifies one specific legal entity.	Trusted data sources: EORI (European Commission API) LEI Code (Global Legal Entity Identifier (GLEIF) API OpenCorporate API VAT Information Exchange System (VIES) API Notary services: Alternatively, notary services can be used. By providing more services and service level agreements, these services eventually also consult the trusted data sources quoted above.
Participant (Legal Person - all roles)	Proof of Data Space Membership is required	Data Space Membership Credential	Data Space Governance Authority
Participant (Legal Person - Provider)	The physical location of the Participant’s headquarters shall be provided.	ISO 3166-2 code	eIDAS TSP (declaration)
Participant (Legal Person - Provider)	The physical location of the Participant's legal registration shall be provided	ISO 3166-2 code	eIDAS TSP (declaration)
Service	The Provider shall ensure there are provisions governing the rights of the parties to use the service and any Customer Data therein.	This criterion is attested through the following three attributes: `LegallyBindingAct`, `CustomerDataProcessingTerms` and `CustomerDataAccessTerms`	eIDAS TSP (declaration) Assessment and Monitoring Bodies for BSI C5, CISPE and EU Codes of Conducts, CSA CCM (certification)
Participant (Provider)	The Provider shall clearly define if and to what extent sub-processors will be involved, and the measures that are in place regarding sub-processors management.	If the attribute `possiblePersonalDataTransfers` is declared, then the `DataTransfer` attribute is also provided in the credential.	eIDAS TSP (declaration) Assessment and Monitoring Bodies for SecNumCloud, CISPE and EU Codes of Conducts (certification)
Participant (Data Provider)	The Data Provider shall have the legal authorization from the Data Producer to include the data in the Data Product	links to authorization documents which are signed through a data space-accredited Trust Service Provider.	Data Space Governance Authority
Data Product	For each Data Product, the Data Provider shall provide in the Data Product Description a Data License defining the usage policy in ODRL for all data in this Data Product.	The Data Product Description shall include a data license expressed as a valid ODRL document containing at least indication whether or not the data product contains licensed data.	eIDAS TSP (declaration)

Terms	Definition
Policy	A machine-readable rule that expresses permissions, prohibitions, or obligations regarding data access and usage. Policies are encoded in ODRL and implement the terms and conditions defined in data product contracts. See 3.4.2.1 Data product contract in Contractual Framework building block.
Policy Negotiation	The process through which a data provider and consumer agree on machine-readable policies for data sharing. The provider offers policies, the consumer may propose alternatives, resulting in a mutually acceptable data product contract.
Policy Validation	The process of verifying that policies are syntactically correct (valid ODRL), semantically meaningful, internally consistent, and compliant with data space mandatory rules.
Machine-Readable Policy	A policy expressed in a standard format (ODRL) that computers can automatically process, evaluate, and enforce.
Access Control	Technical mechanisms that enforce who can access data resources based on permissions in policies. Evaluated before data transfer.
Usage Control	Technical mechanisms that enforce how data can be used after access, based on obligations and prohibitions in policies.
Policy Validation	The process of verifying that policies are correctly structured, consistent, and free from conflicts.
Access Control	Systems and policies that regulate who can access specific data resources and under what conditions.
Usage Control	Mechanisms that specify and enforce how data can be used after access has been granted.
Trust Service	A service that verifies claims used in policy evaluation (e.g., participant credentials, certifications). Examples include identity providers and credential verification services.

Terms	Definition
Data space	Interoperable framework, based on common governance principles, standards, practices and enabling services, that enables trusted data transactions between participants.
Data Space Participant	A party committed to the governance framework of a particular data space and having a set of rights and obligations stemming from this framework. Explanatory text: Depending on the scope of the said rights and obligations, participants may perform in (multiple) different roles, such as: data space members, data space users, data space service providers and others as described in this glossary.
Data Space Intermediary	A data space intermediary is a service provider who provides an enabling service or services in a data space. In common usage interchangeable with ‘operator'.
Service Description	A service description is composed of attributes related to data services, including endpoint description and endpoint URL. Additionally, it may encompass a wide range of attributes related to value-added technical- and support services such as software-, platform-, infrastructure-, security-, communication-, and managed services. These services are used for various purposes, such as data quality, analysis, and visualisation.
Dataset Description	A description of a dataset includes various attributes, such as spatial, temporal, and spatial resolution. The description encompasses attributes related to distribution of datasets such as data format, packaging format, compression format, frequency of updates, download URL, and more. These attributes provide essential metadata that enables data recipients to understand the nature and usability of the datasets.
Offering	Data product(s), service(s), or a combination of these, and the offering description. Explanatory text: Offerings can be put to a catalogue.
Offering Description	A text that specifies the terms, conditions and other specifications, according to which an offering will be provided and can be consumed. Explanatory text: Offering descriptions contain all the information needed for a potential consumer to make a decision whether to consume the data product(s) and/or the service(s) or not. This may include information such as description, provider, pricing, license, data format, access rights, etc. The offering description can also detail the structure of the offering, how data products and services can be obtained, and applicable rights and duties. Typically offering descriptions are machine-readable metadata.

	Metadata Dimensions	Attributes
1	Discoverability, usability, and interoperability	Dataset attributes include identifier, name, description, relation, creator/owner, contact information, timestamp, current version, language, publisher, and related datasets.
2	Distribution attributes include format, access URL, Download URL, and size
3	Data Service attributes include, endpoint URL, endpoint description, serves data
4	Regulatory compliance	Conformance to regulatory standards (e.g., GDPR)
5	Data governance, usability, and interoperability	Source (data lineage), access rights, rights, license, and conformance to standards, version history
6	Data quality	Accuracy, completeness, and consistency

Term	Definition
Catalogue	A functional component to provision and discover offerings of data and services in a data space.
Data Consumer	A consumer of data or service.
Data Provider	A provider of data or service.
Offering	Data product(s), service(s), or a combination of these, and the offering description. Offerings can be put into a catalogue.

Term	Definition
Value creation services	(technical) elements or components designed to unlock, generate and maximize the value of data shared within a data space, providing additional functionalities on top of the core process of data sharing or data transaction. Explanatory Text: This value is delivered both for (i) data space participants (by enabling services and applications that operate on top of data exchanges and transactions), and (ii) for the data space itself (supporting and enhancing core functionalities, such as semantic interoperability, data quality, discoverability, trust mechanisms and others) Value creation services act over data products, and are combined with them in data space offerings, to perfom the functionalities required by the defined use cases. Value creation services complement the capabilities provided by the “federation services” and the “participant agent” services This value creation can come from different sides: complementing the essential capabilities of the data space, acting directly over datasets that these services are tied to, as part of data products, adding value on top of data products and data transactions, enabling the connection to external infrastructures, required to, among others, process, store and collect data, either as part of the normal operation of the data space or as needed by some use cases, enabling the connection to external applications, which are required for the complete development of use cases, facilitating by any other means the materialization of the business models considered in the data space.

Principle 1 – Data-centric	Principle 2 – Data sharing	Principle 3 – Purpose-driven / generic	Principle 4 - Value creation
At its core, a marketplace manages data products Its entire functionality is about publishing, discovering, exchanging data products, negotiate pricing, licencing, access control and usage of the data products	A marketplace only creates value if multiple participants share data products through it. If operated by a single party in isolation, it degenerates into a private repository and loses its marketplace nature. The very essence of the service depends on data sharing across participants	Its recognizable functional need is clear: to facilitate the exchange of data products under agreed conditions. However, a marketplace can be instantiated in many domains (mobility, health, manufacturing, energy, smart cities) with minimal adaptation, as the core mechanisms (catalogue, search, pricing, policy enforcement) remain the same.	For data product providers, it comes directly from the monetization of the data products included in the marketplace For data product users, value comes from the specific application they give to the data product

Principle 1 – Data-centric	Principle 2 – Data sharing	Principle 3 – Purpose-driven / generic	Principle 4 - Value creation
Collect and analyze data from multiple sources, and produce output data in the form of failure patterns, maintenance schedule and failure notifications	The service collects data across the whole value chain of the system By leveraging data from multiple participants, the service increases its efficiency identifying early warnings that would be invisible to a single participant	Its main purpose is to optimize the maintenance activities and resources, and increase the system lifetime Can be applied to multiple sectors, like manufacturing, transport, energy, health, etc ...	Lower maintenance costs, access to predictive insights from the system behaviour, extended lifetime of the system and safety improvement

Principle 1 – Data-centric	Principle 2 – Data sharing	Principle 3 – Purpose-driven / generic	Principle 4 - Value creation
Continuously consumes, analyzes, and updates shared data (availability, capacity, priorities, demand, etc.) Produces new data in the form of coordinated decisions, potential schedules and system-level insights	Requires access to multi-party data (from suppliers, operators, clients, or infrastructure owners), since local data alone is not enough	Specific purpose: optimize schedule or any structured task or process under different constraints and for a concrete objective Scheduling is a universal optimization problem — reusable in transport, manufacturing, healthcare, energy, etc.	Increased utilization / capacity of shared and limited resources (vehicles, machines, energy, personnel). Reduced idle times, delays, and conflicts. Enhanced predictability in multi-party operations

Principle 1 – Data-centric	Principle 2 – Data sharing	Principle 3 – Purpose-driven / generic	Principle 4 - Value creation
Processes large volumes of shared operational, contextual, and model data Generates new and high-value data assets (synthetic datasets and scenario features)	Accurate simulation requires input data and models from multiple participants, along the different stages and dimensions of the process to simulate	Simulation and impact evaluation are applicable for different use cases (e.g. digotal twin) and across domains (mobility, energy, manufacturing, environment, health, etc.)	Optimization, forecasting, or digital twin services Enables reproducibility and comparison & benchmarking Supports decision making and model improvement

Framework capability	Specifications
Trusted execution	Allign with the trust framework of the data space, and on its capabilities to identify, autenticate and authorize users Ensure, for the execution, compliance with the data space rulebook and existing regulations If required and possible, consider the use of hardware-based Trusted Execution Environments (TEE), to ensure that code and data are protected during execution, and / or virtualization based security tools.
Services provisioning and delivery	Depending on the requirements and storage resources in the data space, consider the containerization of services for their provisioning and deployment, to ensure portability, scalability, and resource efficiency. API gateway, to implement client requests to services. To consider if those requests can be included in the data plane of the data space Artifact repository, to store, manage, and distribute the services, to facilitate version control, dependency management, and services retrieval.
Services management	Dedicated services registry as part of the general data space registry / data space wallet Connection with data space catalogue, to enable mechanisms to register and locate services, with detailed descriptions, usage instructions, and access policies. Use specific tools for services orchestration to manage the deployment, scaling, and operation of services, and for load balancing Implement workflow automation tools to coordinate complex service interactions. Include alerting systems to notify administrators of service issues or performance degradation Apply tools like service mesh or dependency graphs to manage dependencies and relationships between services
Security	Align with authentication mechanisms of the data space and the service itself to secure service access. Include security audits and vulnerability assessments Ensure data at rest and in motion is encrypted Implement necessary controls
Scalability	Elastic access to compute resources, that enable their dynamically allocation Consider at governance / legal level to include auto-scaling policies, that based on metrics can automatically adjust resource allocation and service usage Resource quotas to ensure fair distribution of resources and use of services
Performance, monitoring and logging	Centralized monitoring system to collect, aggregate, and visualize performance metrics from all services and infrastructure components Align with the provenance and traceability components of the data space for logs for services use, performance, access attempts, and configuration changes, incoprorating aggregation, search and visualization functionalities Tools for real time monitorig and visualization Define global performance metrics Define Service Level Indicators (SLI) to measure the availability and performance of a service. Define Service Level Objectives (SLO) to guide internal process towards the Service Level Agreements. Regular reports on system performance, service usage, and security incidents
Maintenance	Regular maintenance schedule for updates Version control for all service components Back-up and recovery
Deployment and use of services	Deployment models suitable for the data space, depending on objectives, scalability and operational requirements (cloud-native architectures, hybrid cloud solutions, in-premises, serverless deployment) Define and adhere to Service Level Agreements that specify service availability, performance metrics, and support response times. Consider the SLA baseline of the specific service. Intuitive user interfaces (UI) and user experience design to make services easy to use and navigate

Glossary

This glossary establishes consistent and coherent terminology for DSSC communication and publications.

The list of concepts listed under sections 1 to 11 includes the key concepts as introduced in the Key Concepts of Data Spaces section. This is limited to the highest level concepts and more detailed terms can be defined in the glossary sections in each building block. The Alphabetical List of All Defined Terms includes all the terms of this central glossary as well as any additional terms defined at the building block level.

The various documents produced by the DSSC originate from different contexts, such as business, legal, application, technical, and architectural. This makes it challenging to guarantee coherence and consistent use of terms. However, the fact that all authors of such documents are expected to use the terminology from this glossary helps ensure such coherence and consistency will exist. Consequently, readers will find such documents much easier to understand and experience less confusion and misunderstandings.

Beyond the DSSC, this glossary also supports information sharing and co-development between the different standards development initiatives, the various data space initiatives and people involved and working with the DSSC. We hope that terminology from the glossary naturally spreads to the community of practice around data spaces, and we hope to get feedback and change requests from the community when needed.

The context of this glossary is the implementation and development of data spaces. Each context needs its terminology. For example, almost every law and contract start by defining its terms; such a term may deviate from what it means in other laws or contracts. Software engineers refer to the different contexts as ‘namespaces’ or ‘schemas’. Terms described here may have different meanings in other contexts, and terms with particular meanings elsewhere, e.g. in laws, standards, etc., may not have that meaning within DSSC.

The scope of this glossary – what is included and why. The primary criterion for inclusion is that every term is used in the DSSC documents. As a principle, we intend to keep this glossary as concise as possible but still include all terms that have a specific meaning in the context of DSSC. We do not include generic terms.

Legal definitions regarding European data economy concepts. Another related context is the EU data policies and regulations. One objective of the glossary is to help people understand and comply with this common foundation. In the eleventh section of the glossary, we cover the foundational legal terms and definitions related to the European data economy. The word “definition” in this glossary refers to these legal definitions adopted verbatim from the respective laws. Elsewhere in the glossary, we use the word “description” to refer to the term descriptions we crafted.

Alignment with other terminologies. We adopt terminology from relevant sources and describe terms as much as possible in an inclusive and non-contradictory way with EU law and with European as well as international standards. Adopting terminology, however, is not automatically direct copying. It means that, where needed, we craft terms and descriptions from reliable sources to fit in the context of data space development. We also make the descriptions criteria-based and modular (see below). This process of adopting (not copying) terms should result in consistent and coherent terminology.

Terms are described with criteria. The descriptions of the terms in this glossary are compact, focusing mainly on the criteria. The idea is that different people can agree on whether something is an instance or example of the term by verifying the criteria written in the glossary description. We supplement the short descriptions with explanatory texts that include further descriptions and alignment with other sources when needed.

Terminology is modular and interlinked. The terms in this glossary are heavily interlinked. Within the descriptions, we use other terms from the glossary and mark these with bolded font. Consequently, the reader may need to follow some of the links to other terms to understand the first term fully. The terms in this glossary are not in alphabetical order. Instead, the terms are grouped in distinct chapters, so the linked terms are close to each other.

Conceptual models are closely aligned with the glossary. Conceptual models add more context and meaning to the terms than what can be expressed in the glossary tables. A conceptual model specifies a small set of concepts (ideas), their relationships, and constraints that apply. A conceptual model is distinct from an architectural model. For example, in city planning, conceptual models introduce concepts like 'house', 'shop', 'mall', 'road', etc., and the architectural models of individual cities will tell you whether or not there are malls, where the houses are, how the roads connect them, etc. Similarly, in data spaces, the conceptual models introduce terms such as 'governance framework', 'data transaction', 'data space infrastructure', etc. How these concepts are implemented in practice is part of the data space architecture. In this blueprint version, the highest level conceptual model is in the Introduction section on Key Concepts of Data Spaces, and more detailed conceptual models are part of the building blocks.

Flexibility for communications. Different writing styles are necessary for different target audiences. There may be situations where the glossary terms and definitions do not fit perfectly for a specific communication purpose. In such cases, the authors may use other wording instead of copying from the glossary. However, the authors should always maintain the original meaning of the glossary definition.

Root word ‘data space’ in many terms. Many terms in the glossary start with ‘data space’; for example, data space governance framework, data space infrastructure, data space use case, etc. We chose this approach to maintain the specificity of the terms compared to their generic counterparts. When the terms are used in texts (including the term descriptions in this glossary), it is not necessary to always repeat the preceding words ‘data space’, but it is recommended to use the full term at least once in a given text or when there is a risk of confusion between the specific and more generic use of the term.

Data space roles versus instances performing the roles. Some terms, such as ‘data space participant’ or ‘data provider’, can refer to a data space role and to instances that perform the role. The glossary descriptions of such dual-usage terms are written in the format that fits for the instances rather than the role, as this is the dominant usage.

This section describes the essential terms to express what data spaces are and offers a starting point for defining the governance frameworks for data space initiatives. A common understanding of these core concepts is critical for the convergence and interoperability of different data space architectures, -standards and -initiatives. The relevance of, and the relationships between, these terms are introduced and explained in the Introduction - Key Concepts of Data Spaces section.

Term	Description
Data space	Interoperable framework, based on common governance principles, standards, practices and enabling services, that enables trusted data transactions between participants. Explanatory text: Note for users of V0.5 and V1.0 of this blueprint: we have adopted this new definition from CEN Workshop Agreement Trusted Data Transactions, in an attempt to converge with ongoing standardisation efforts. Please note that further evolution might occur in future versions. For reference, the previous definition was: “Distributed system defined by a governance framework that enables secure and trustworthy data transactions between participants while supporting trust and data sovereignty. A data space is implemented by one or more infrastructures and enables one or more use cases.” Note: some parties write dataspace in a single word. We prefer data space in two words and consider that both terms mean exactly the same.
Data space governance framework	The structured set of principles, processes, standards, protocols, rules and practices that guide and regulate the governance, management and operations within a data space to ensure effective and responsible leadership, control, and oversight. It defines the functionalities the data space provides and the associated data space roles, including the data space governance authority and participants. Explanatory text: Functionalities include, e.g., the maintenance of the governance framework the functioning of the data space governance authority and the engagement of the participants. The responsibilities covered in the governance framework include assigning the governance authority and formalising the decision-making powers of participants. The data space governance framework specifies the procedures for enforcing the governance framework and conflict resolution. The operations may also include business and technology aspects.
Data space rulebook	The documentation of the data space governance framework for operational use. Explanatory text: The rulebook can be expressed in human-readable and machine-readable formats.
Data space governance authority	The body of a particular data space, consisting of participants that is committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework. Explanatory text: A ‘body’ is a group of parties that govern, manage, or act on behalf of a specific purpose, entity, or area of law. This term, which has legal origins, can encompass entities like legislative bodies, governing bodies, or corporate bodies. The data space governance authority does not replace the role of public regulation and enforcement authorities. Establishing the initial data space governance framework is outside the governance authority's scope and needs to be defined by a group of data space initiating parties. After establishment, the governance authority performs the governing function (developing and maintaining the governance framework) and the executive function (operating and enforcing the governance framework). Depending on the legal form and the size of the data space, the governance and executive functions of a data space governance authority may or may not be performed by the same party.
Data space participant	A party committed to the governance framework of a particular data space and having a set of rights and obligations stemming from this framework. Explanatory text: Depending on the scope of the said rights and obligations, participants may perform in (multiple) different roles, such as: data space members, data space users, data space service providers and others as described in this glossary.
Party	A natural person or a legal person Explanatory text: Parties are organisations (enterprises, governmental bodies, not-for-profits) or human beings, i.e. entities that set their own objectives and that ‘sovereignly’ decide what they do and do not do.
Data space role	A distinct and logically consistent set of rights and duties (responsibilities) within a data space, that are required to perform specific tasks related to a data space functionality, and that are designed to be performed by one or more participants. Explanatory text: The governance framework of a data space defines the data space roles. Parties can perform (be assigned, or simply ‘be’) multiple roles, such as data provider, transaction participant, data space intermediary, etc.. In some cases, a prerequisite for performing a particular role is that the party can already perform one or more other roles. For example, the data provider must also be a data space participant.
Data space functionality	A specified set of tasks that are critical for operating a data space and that can be associated with one or more data space roles. Explanatory text: The data space governance framework specifies the data space functionalities and associated roles. Each functionality and associated role consist of rights and duties for performing tasks related to that functionality.
Data space infrastructure (deprecated term)	A technical, legal, procedural and organisational set of components and services that together enable data transactions to be performed in the context of one or more data spaces. Explanatory text: This term was used in the data space definition in previous versions of the Blueprint. It is replaced by the governance framework and enabling services, and may be deprecated from this glossary in a future version.
Data space services	Functionalities for implementing data space capabilities, offered to participants of data spaces. Explanatory text: We distinguish three classes of technical services which are further defined in section 4 of this glossary: Participant Agent Services, Facilitating Services, Value-Creation Services. Technical (software) components are needed to implement these services. Also on the business and organisational side, services may exist to support participants and orchestrators of data spaces, further defined in section 4 of this glossary and discussed in the Business and Organisational building blocks introduction. Please note that a Data Service is a specific type of service related to the data space offering, providing access to one or more datasets or data processing functions.
Data transaction	A structured interaction between data space participants for the purpose of providing and obtaining/using a data product. An end-to-end data transaction consists of various phases, such as contract negotiation, execution, usage, etc. Explanatory text: In future work we may align further with the definition from CEN Workshop Agreement Trusted Data Transactions: result of an agreement between a data provider and a data user with the purpose of exchanging, accessing and using data, in return for monetary or non-monetary compensation. A data transaction implies data transfer among involved participants and its usage on a lawful and contractual basis. It relates to the technical, financial, legal and organisational arrangements necessary to make a data set from Participant A available to Participant B. The physical data transfer may or may not happen during the data transaction. Prerequisites: the specification of data products and the creation and publication of data product offerings so parties can search for offerings, compare them and engage in data transactions to obtain the offered data product. Key elements related to data transactions are: negotiation (at the business level) of a contract between the provider and user of a data product, which includes, e.g., pricing, the use of appropriate intermediary services, etc. negotiation (at the operational level) of an agreement between the provider and the user of a data product, which includes, e.g., technical policies and configurations, such as sending ensuring that parties that provide, receive, use, or otherwise act with the data have the rights/duties they need to comply with applicable policies and regulations (e.g. from the EU) accessing and/or transferring the data (product) between provider, user, and transferring this data and/or meta-data to (contractually designated) other participants, such as observers, clearing house services, etc. Data access and data usage by the data consumer. All activities listed above do not need to be conducted in every transaction and that parts of the activities may be visited in loops or conditional flows.
Data product	Data sharing units, packaging data and metadata, and any associated license terms. Explanatory text: We borrow this definition from the CEN Workshop Agreement Trusted Data Transactions. The data product may include, for example, the data products' allowed purposes of use, quality and other requirements the data product fulfils, access and control rights, pricing and billing information, etc.
Data space use case	A specific setting in which two or more participants use a data space to create value (business, societal or environmental) from data sharing. Explanatory text: By definition, a data space use case is operational. When referring to a planned or envisioned setting that is not yet operational we can use the term use case scenario. Use case scenario is a potential use case envisaged to solve societal, environmental or business challenges and create value. The same use case scenario, or variations of it, can be implemented as a use case multiple times in one or more data spaces.

Term	Description
Use case orchestrator	A data space participant that represents and is accountable for a specific use case in the context of the governance framework. The orchestrator establishes and enforces business rules and other conditions to be followed by the use case participants. [role]
Use case participant	A data space participant that is engaged with a specific use case. [role]
Use case development	A strategic approach to amplify the value of a data space by fostering the creation, support and scaling of use cases.
Data space value	The cumulative value generated from all the data transactions and use cases within a data space as data space participants collaboratively use it. Explanatory text: The definition of “data space value” is agnostic to value sharing and value capture. It just states where the value is created (in the use cases). The use case orchestrator should establish a value-sharing mechanism within the use case to make all participants happy. Furthermore, to avoid the free rider problem, the data space governance authority may also want to establish a value capture mechanism (for example, a data space usage fee) to get its part from the value created in the use cases.
Synergy between data spaces	The gained efficiency, increased impact or other benefits of two or more data spaces working together that are greater than if the data spaces were working separately. The synergies between data spaces can be enabled by common practices, communication concepts, services and/or components, which increase data space interoperability and enable harmonised processes of using different data spaces.
Cross data space use case	A specific setting in which participants of multiple data spaces create value (business, societal or environmental) from sharing data across these data spaces.

This section introduces relevant terminology for writing texts that deal with creating, maintaining and further evolving a data space initiative. This includes deploying and maintaining a specific data space and the development of use cases and pilots for that.

Term	Description
Data space initiative	A collaborative project of a consortium or network of committed partners to initiate, develop and maintain a data space.
Data space development processes	A set of essential processes the stakeholders of a data space initiative conduct to establish and continuously develop a data space throughout its development cycle.
Data space operational processes	A set of essential processes a potential or actual data space participant goes through when engaging with a functioning data space that is in the operational stage or scaling stage. The operational processes include attracting and onboarding participants, publishing and matching use cases, data products and data requests and eventually data transactions.
Data space pilot	A planned and resourced implementation of one or more use cases within the context of a data space initiative. A data space pilot aims to validate the approach for a full data space deployment and showcase the benefits of participating in the data space.
Development cycle	The sequence of stages that a data space initiative passes through during its progress and growth. In each stage, the initiative has different needs and challenges, and when progressing through the stages, it evolves regarding knowledge, skills and capabilities.
Exploratory stage	The stage in the development cycle in which a data space initiative starts. Typically, in this stage, a group of people or organisations starts to explore the potential and viability of a data space. The exploratory activities may include, among others, identifying and attracting interested stakeholders, collecting requirements, discussing use cases or reviewing existing conventions or standards.
Preparatory stage	The stage in the development cycle that starts when a data space initiative has a critical mass of committed stakeholders and there is an agreement to move forward with the initiative and proceed towards creating a data space. It is typical for this stage that such partners jointly develop use cases and prepare to implement the data space.
Implementation stage	The stage in the development cycle that starts when a data space initiative has a sufficiently detailed project plan, milestones and resources (funding and other) for developing its governance framework and infrastructure in the context of a data space pilot. It is typical for this stage that the parties involved in the pilot and the value created for each are also clearly identified.
Operational stage	The stage in the development cycle that starts when a data space initiative has a tested implementation of infrastructure(s) and governance framework, and the first use case becomes operational (data flowing between data providers and data recipients and use case providing the intended value).
Scaling stage	The stage in the development cycle that starts when a data space initiative has been proven to consistently and organically gain new participants and embrace new use cases. In this stage, the data space can realistically be expected to be financially and operationally sustainable, respond to market changes, and grow over time.
Data spaces information model	A classification scheme used to describe, analyse and organise a data space initiative according to a defined set of questions.
Data space maturity model	Set of indicators and a self-assessment tool allowing data space initiatives to understand their stage in the development cycle, their performance indicators and their technical, functional, operational, business and legal capabilities in absolute terms and in relation to peers.
Data spaces radar	A publicly accessible tool to provide an overview of the data space initiatives, their sectors, locations and approximate development stages.

Term	Description
Data space services	Functionalities for implementing data space capabilities, offered to participants of data spaces. Explanatory text: We distinguish three classes of technical services which are further defined in section 4 of this glossary: Participant Agent Services, Federation Services, Value-Creation Services. Technical (software) components are needed to implement these services. Also on the business and organisational side, services may exist to support participants and orchestrators of data spaces, further defined in section 4 of this glossary and discussed in the Business and Organisational building blocks introduction. Please note that a Data Service is a specific type of service related to the data space offering, providing access to one or more datasets or data processing functions.
Participant agent services	Services to enable an individual participant to interact within the data space, facilitate the sharing (providing or using) of data, specify access and usage policies, and more. Explanatory Text: The participant agent services provide operations on the control plane that are executing the data services on the data plane. The control plane and data plane should work together to manage the data transfer process. After contract negotiation, the technical transfer process can take place.
Facilitating services	Services which facilitate the interplay of participants in a data space, enabling them to engage in (commercial) data-sharing relationships of all sorts and shapes. Explanatory Text: They are sometimes also called ‘federation services’.
Value-creation services	(Technical) elements or components designed to unlock, generate and maximize the value of data shared within a data space, providing additional functionalities on top of the core process of data sharing or data transaction. Explanatory Text: This value is delivered both for (i) data space participants (by enabling services and applications that operate on top of data exchanges and transactions), and (ii) for the data space itself (supporting and enhancing core functionalities, such as semantic interoperability, data quality, discoverability, trust mechanisms and others) Value creation services act over data products, and are combined with them in data space offerings, to perfom the functionalities required by the defined use cases. Value creation services complement the capabilities provided by the “federation services” and the “participant agent” services This value creation can come from different sides: complementing the essential capabilities of the data space, acting directly over datasets that these services are tied to, as part of data products, adding value on top of data products and data transactions, enabling the connection to external infrastructures, required to, among others, process, store and collect data, either as part of the normal operation of the data space or as needed by some use cases, enabling the connection to external applications, which are required for the complete development of use cases, facilitating by any other means the materialization of the business models considered in the data space.
Data service	A collection of operations that provides access to one or more datasets or data processing functions. For example, data selection, extraction, data delivery. Explanatory text: This definition is as specified by the DCAT standard, which predates the data space concepts. In practice, the term implies services within a participant’s system and services in the data plane of the data sharing services within a data space. The latter are part of the participant agent services. In the CEN Workshop Agreement Trusted Data Transactions the data service enables data sharing or data exchange (synonyms). The use of the data can be synchronous or asynchronous. Data can be shared, for example, (i) by allowing access to the original data set, or (ii) by giving a copy of the data to the interested entity.
Participant agent	A technology system used to conduct activities in a data space on behalf of a party. Explanatory text: The participant agent can offer technical modules that implement data interoperability functions, authentication interfacing with trust services and authorisation, data product self-description, contract negotiation, etc. A ‘connector’ is an implementation of a participant agent service.
Operator	Service provider that provides enabling services that are common to all participants of the data space. In common usage interchangeable with ‘intermediary’. Explanatory text: We use typically the term ‘operator’ when a single actor is assigned by the governance authority to manage the enabling services and when it is responsible for the operation of the data space, ensuring functionality and reliability as specified in the governance framework.
Intermediary	Service provider who provides an enabling service or services in a data space. In common usage interchangeable with ‘operator'.
Enabling services	Refer mutually to facilitating services and participant agent services, hence the technical services that are needed to enable trusted data transaction in data spaces.

Term	Description
Data product	Data sharing units, packaging data and metadata, and any associated license terms. Explanatory text: We borrow this definition from the CEN Workshop Agreement Trusted Data Transactions. The data product may include, for example, the data products' allowed purposes of use, quality and other requirements the data product fulfils, access and control rights, pricing and billing information, etc.
Data product owner	A party that develops, manages and maintains a data product. Explanatory text: The data product owner can be the same party as the data rights holder, or it can receive the right to process the data from the data rights holder (the right can be obtained through a permission, consent or license and may be ruled by a legal obligation or a contract). A data product owner is not necessarily a data space participant.
Data provider	A synonym of data product provider
Data product provider	A party that acts on behalf of a data product owner in providing, managing and maintaining a data product in a data space. Explanatory text: The data product provider can be referred to as the data provider. In general use that is fine, but in specific cases the data product provider might be a different party than the data rights holder and different than the data product owner. A data product provider is a data space participant. For reference, the definition from the CEN Workshop Agreement Trusted Data Transactions: a party that has the right or duty to make data available to data users through data products. Note: a data provider carries out several activities, ie.: - non-technical, on behalf of a data rights holder, including the description of the data products, data licence terms, the publishing of data products in a data product catalogue, the negotiation with the data users, and the conclusion of contracts, - technical, with the provision of the data products to the data users.
Data consumer	A synonym of data product consumer
Data product consumer	A party that commits to a data product contract concerning one or more data products. Explanatory text: A data product consumer is a data space participant. The data product consumer can be referred to as the data user. In principle, the data product consumer could be a different party than the eventual data user, but in many cases these parties are the same and the terms are used exchangeably.
Data user	a natural or legal person who has lawful access to certain personal or non-personal data and has the right, including under Regulation (EU) 2016/679 in the case of personal data, to use that data for commercial or noncommercial purposes; (DGA Article 2(9)) Explanatory text: In many cases the data user is the same party as the data consumer or data product consumer, but exceptions may exist where these roles are separate. For reference, the definition from the CEN Workshop Agreement Trusted Data Transactions which considers the term to be synonymous with data consumer: person or organization authorized to exploit data (ISO 5127:2017) Note 1: Data are in the form of data products. Note 2: Data consumer is considered as a synonym of data user.
Data product contract	A legal contract that specifies a set of rights and duties for the respective parties that will perform the roles of the data product provider and data product consumer.
Data rights holder	A party with legitimate interests to exercise rights under Union law affecting the use of data or imposing obligations on other parties in relation to the data. Explanatory text: This party can be a data space participant, but not necessarily, when the party provides permission/consent for a data provider or data product provider to act on its behalf and participate in the actual data sharing. Previous definition (for reference): A party that has legal rights and/or obligations to use, grant access to or share certain personal or non-personal data. Data rights holders may transfer such rights to others. For reference, the definition from the CEN Workshop Agreement Trusted Data Transactions: a natural or legal person that has legal rights or obligations to use, grant access to or share certain data, or transfer such rights to others

Term	Description
Data policy	A set of rules, working instructions, preferences and other guidance to ensure that data is obtained, stored, retrieved, and manipulated consistently with the standards set by the governance framework and/or data rights holders. Explanatory text: Data policies govern aspects of data management within or between data spaces, such as access, usage, security, and hosting.
Data access policy	A specific data policy defined by the data rights holder for accessing their shared data in a data space. Explanatory text: A data access policy that provides operational guidance to a data provider for deciding whether to process or reject a request for providing access to specific data. Data access policies are created and maintained by the data rights holders.
Data usage policy	A specific data policy defined by the data rights holder for the usage of their data shared in a data space. Explanatory text: Data usage policy regulates the permissible actions and behaviours related to the utilisation of the accessed data, which means keeping control of data even after the items have left the trust boundaries of the data provider.
Policy definition language	A machine-processable mechanism for representing statements about the data policies, e.g., Open Digital Rights Language (ODRL)
Data policy enforcement	A set of measures and mechanisms to monitor, control and ensure adherence to established data policies. Explanatory text: Policies can be enforced by technology or organisational manners.
Data policy negotiation	The process of reaching agreements on data policies between a data rights holder, a data provider and a data recipient. The negotiation can be fully machine-processable and immediate or involve human activities as part of the workflow.

Term

Description

Data space interoperability

The ability of participants to seamlessly exchange and use data within a data space or between two or more data spaces.

Explanatory text:

Interoperability generally refers to the ability of different systems to work in conjunction with each other and for devices, applications or products to connect and communicate in a coordinated way without effort from the users of the systems. On a high-level, there are four layers of interoperability: legal, organisational, semantic and technical (see the European Interoperability Framework [EIF]).

Legal interoperability: Ensuring that organisations operating under different legal frameworks, policies and strategies are able to work together.
Organisational interoperability: The alignment of processes, communications flows and policies that allow different organisations to use the exchanged data meaningfully in their processes to reach commonly agreed and mutually beneficial goals.
Semantic interoperability: The ability of different systems to have a common understanding of the data being exchanged.
Technical interoperability: The ability of different systems to communicate and exchange data.

Also the ISO/IEC 19941:2017 standard [20] is relevant here.

Note: As per Art. 2 r.40 of the Data Act: ‘interoperability’ means the ability of two or more data spaces or communication networks, systems, connected products, applications, data processing services or components to exchange and use data in order to perform their functions. We describe this wider term as cross-data space interoperability.

Intra-data space interoperability

The ability of participants to seamlessly access and/or exchange data within a data space. Intra-data space interoperability addresses the governance, business and technical frameworks (including the data space protocol and the data models) for individual data space instances.

Cross-data space interoperability

The ability of participants to seamlessly access and/or exchange data across two or more data spaces. Cross-data spaces interoperability addresses the governance, business and technical frameworks to interconnect multiple data space instances seamlessly.

Explanatory text:

Inter-data space interoperability is an alternative term and both terms can be used interchangeably.

Term	Description
Assurance	An artefact that helps parties make trust decisions about a claim, such as certificates, commitments, contracts, warranties, etc. Explanatory Text: Also defined as: grounds for justified confidence that a claim has been or will be achieved [ISO/IEC/IEEE 15026-1:2019, 3.1.1]
Claim	an assertion made about a subject. (ref. Verifiable Credentials Data Model v2.0 (w3.org)
Trust anchor	An authoritative entity for which trust is assumed and not derived. Each Trust Anchor is accepted by the data space governance authority in relation to a specific scope of attestation.
Trust decision	A judgement made by a party to rely on some statement being true without requiring absolute proof or certainty.
Attestation	Issue of a statement, based on a decision, that fulfilment of specified requirements has been demonstrated (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Trust framework	A composition of policies, rules, standards, and procedures designed for trust decisions in data spaces based on assurances. Trust framework is part of the data space governance framework. Explanatory text: A trust framework is comprised of: (business-related) policies, rules, and standards collected and documented in the rulebook. procedures for automation and implementation of the business-related components.
Validation	Confirmation of plausibility for a specific intended use or application through the provision of objective evidence that specified requirements have been fulfilled (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Verification	Confirmation of truthfulness through the provision of objective evidence that specified requirements have been fulfilled (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )

Term	Description
Data spaces blueprint	A consistent, coherent and comprehensive set of guidelines to support the implementation, deployment and maintenance of data spaces. Explanatory text: The blueprint contains the conceptual model of data space, data space building blocks, and recommended selection of standards, specifications and reference implementations identified in the data spaces technology landscape.
Data space building block	A description of related functionalities and/or capabilities that can be realised and combined with other building blocks to achieve the overall functionality of a data space. Explanatory text: In the data space blueprint the building blocks are divided into organisational and business building blocks and technical building blocks. In many cases, the functionalities are implemented by Services
Data space component	A specification for a software or other artefact that realises one service or a set of services that fulfil functionalities described by one or more building blocks. Explanatory text: For technical components, that would typically be software, but for business components, this could consist of processes, templates or other artefacts.
Data space component architecture	An overview of all the data space components and their interactions, providing a high-level structure of how these components are organised and interact within data spaces.
Implementation of a data space component	The result of translating/converting a data space component into a functional and usable artefact, such as executable code or other tool.

This section defines terms relevant within the context of the DSSC itself, ensuring that their meanings are understood similarly by all people working for and with the DSSC. This section contains terms for the main resources (DSSC assets), such as the blueprint, building blocks etc.

Term	Description
Data Spaces Support Centre	The virtual organisation and EU-funded project which supports the deployment of common European data spaces and promotes the reuse of data across sectors.
DSSC asset	A sustainable open resource that is developed and governed by the Data Spaces Support Centre. The assets can be used to develop, deploy and operationalise data spaces and to enable knowledge sharing around data spaces. The DSSC also develops and executes strategies to provide continuity for the main assets beyond the project funding.
Conceptual model of data space	A consistent, coherent and comprehensive description of the concepts and their relationships that can be used to unambiguously explain what data spaces and data space initiatives are about.
DSSC glossary	A limited set of data spaces related terms and corresponding descriptions. Each term refers to a concept, and the term description contains a criterion that enables people to determine whether or not something is an instance (example) of that concept.
DSSC toolbox	A catalogue of data space component implementations curated by the Data Space Support Centre.
Data spaces technology landscape	A repository of standards (de facto and de jure), specifications and open-source reference implementations available for deploying data spaces. The Data Space Support Centre curates the repository and publishes it with the blueprint.
Data spaces starter kit	A document that helps organisations and individuals in the network of stakeholders to understand the requirements for creating a data space.
Community heartbeat	The regular release of the data spaces blueprint, data spaces building blocks, other DSSC assets and supporting activities, as outlined in a public roadmap. The regular releases aim to engage the community of practice into a rhythm of communication, co-learning and continuous improvement.
Community of practice	The set of existing and emerging data space initiatives in all sectors and the set of (potential) data space component implementers. DSSC prioritises the data space projects funded by the Digital Europe Programme and other relevant programmes and will later expand to additional data space initiatives.
Relationship manager	A person from the Data Spaces Support Centre who serves as the dedicated DSSC contact point for a data space initiative or another member of the community of practice.
Network of stakeholders	The group of parties relevant to the development of data spaces and with whom the Data Spaces Support Centre proactively engages in achieving its purpose and objectives. The community of practice is the core subset of this network of stakeholders and the primary focus group for the DSSC.
Strategic stakeholder forum	The designated group of experts that provide strategic support for the DSSC and make recommendations for the governance and sustainability of the DSSC assets. The strategic stakeholder forum is composed of a large variety of stakeholders with a balanced geographical distribution and will evolve progressively.
Data space support organisation	An organisation, consortium, or collaboration network that specifies architectures and frameworks to support data space initiatives. Examples include Gaia-X, IDSA, FIWARE, iSHARE, MyData, BDVA, and more.

This section provides EU legislative instruments and policy terms relevant to data spaces (in the first table) and legal definitions regarding European data economy concepts (in the second table). Having them here offers people who work with data spaces a means to quickly lookup such terms without searching relevant EU sources.

Relevant legislative instruments and policy terms

Term	Description
European strategy for data	A vision and measures (a strategy) that contribute to a comprehensive approach to the European data economy, aiming to increase the use of, and demand for, data and data-enabled products and services throughout the Single Market. It presents the vision to create a European single market for data.
Digital Europe Programme	An EU funding programme that funds several data space related projects, among other topics. The programme is focused on bringing digital technology to businesses, citizens and public administrations.
Horizon Europe Programme	An EU funding programme that funds data space related research and innovation projects, among other topics.
European single market for data	A genuine single market for data – open to data from across the world – where personal and non-personal data, including sensitive business data, are secure and businesses also have easy access to high-quality industrial data, boosting growth and creating value. Explanatory text: Source: European strategy for data
Common European Data Spaces	Sectoral/domain-specific data spaces established in the European single market with a clear EU-wide scope that adheres to European rules and values. Explanatory text: Common European Data Spaces are mentioned in the EU data strategy and introduced in the EC Staff Working Document on Common European Data Spaces and on this site: https://digital-strategy.ec.europa.eu/en/policies/data-spaces . It is furthermore referenced in the Data Governance Act with the following description: Purpose-, sector-specific or cross-sectoral interoperable frameworks of common standards and practices to share or jointly process data for, inter alia, development of new products and services, scientific research or civil society initiatives. Such sectoral/domain-specific Common European Data Spaces are being supported through EU-funding programmes, e.g. DIGITAL, Horizon Europe. In some domains (Health, Procurement) specific regulations towards the establishment of such data spaces are forthcoming.
Data sovereignty	The ability of individuals, organisations, and governments to have control over their data and exercise their rights on the data, including its collection, storage, sharing, and use by others. Explanatory text: Data sovereignty is a central concept in the European data strategy and recent European laws and regulations are expanding upon these rights and controls. EU law applies to data collected in the EU and/or about data subjects in the EU.
Data Governance Act	A European regulation that aims to create a framework to facilitate European data spaces and increase trust between actors in the data market. The DGA entered into force in June 2022 and applies from Sept 2023. The DGA defines the European Data Innovation Board (EDIB).
European Data Innovation Board	The expert group established by the Data Governance Act (DGA) to assist the European Commission in the sharing of best practices, in particular on data intermediation, data altruism and the use of public data that cannot be made available as open data, as well as on the prioritisation of cross-sectoral interoperability standards, which includes proposing guidelines for Common European Data Spaces (DGA Article 30). The European Data Innovation Board received additional additional assignments under the Data Act (DA Article 42).
Guidelines for Common European Data Spaces	The Data Governance Act (DGA Article 30(h)) defines that the European Data Innovation Board will propose guidelines for common European data spaces. The guidelines shall address, among other things: (i) cross-sectoral standards for data sharing, (ii) counter barriers to market entry and avoiding lock-in effects and ensuring fair competition and interoperability, (iii) protection for lawful data transfers to third countries, (iv) non-discriminatory representation of relevant stakeholders in the governance of Common European Data Spaces and (v) adherence to cybersecurity requirements.
Data Act	A European regulation that establishes EU-wide rules for access to the product or related service data to the user of that connected product or service. The regulation also includes essential requirements for the interoperability of data spaces (Article 33) and essential requirements for smart contracts to implement data sharing agreements (Article 36). Explanatory text: More info can be found here: Data Act explained \| Shaping Europe’s digital future and the Data Act Frequently-asked-questions.

Legal definitions regarding European data economy concepts

Terms and definitions in this section are adopted verbatim from the Data Governance Act (DGA), General Data Protection Regulation (GDPR) and the Data Act (DA). These terms represent the fundamental concepts in the European data economy. The explanatory texts under the definitions explain links to similar and related terms if such exist in the other glossary sections.

Term	Legal definition (verbatim)
Data	any digital representation of acts, facts or information and any compilation of such acts, facts or information, including in the form of sound, visual or audiovisual recording; (DGA Article 2(1)) Explanatory text: The definition is the same in the Open Data Directive and the Data Act.
Data sharing	the provision of data by a data subject or a data holder to a data user for the purpose of the joint or individual use of such data, based on voluntary agreements or Union or national law, directly or through an intermediary, for example under open or commercial licences subject to a fee or free of charge; (DGA Article 2(10)) Explanatory text: In the context of data spaces, data sharing refers to a full spectrum of practices related to sharing any kind of data, including all relevant technical, financial, legal, and organisational requirements.
Data holder	a legal person, including public sector bodies and international organisations, or a natural person who is not a data subject with respect to the specific data in question, which, in accordance with applicable Union or national law, has the right to grant access to or to share certain personal data or non-personal data; (DGA Article 2(8)) a natural or legal person that has the right or obligation, in accordance with this Regulation, applicable Union law or national legislation adopted in accordance with Union law, to use and make available data, including, where contractually agreed, product data or related service data which it has retrieved or generated during the provision of a related service;(DA Article 2(13)) Explanatory text: In general context we use data holder within the meaning of DGA Art. 2(8) and in case the word data holder is used in the context of DA (IoT data), we identify it with DA at the end of the term. Please note that data rights holder has a specific and different meaning than data holder and is used especially in data transactions.
Data recipient	a natural or legal person, acting for purposes which are related to that person’s trade, business, craft or profession, other than the user of a connected product or related service, to whom the data holder makes data available, including a third party following a request by the user to the data holder or in accordance with a legal obligation under Union law or national legislation adopted in accordance with Union law; (DA Article 2(14)) a natural or legal person, public authority, agency or another body, to which the personal data are disclosed, whether a third party or not. However, public authorities which may receive personal data in the framework of a particular inquiry in accordance with Union or Member State law shall not be regarded as recipients; the processing of those data by those public authorities shall be in compliance with the applicable data protection rules according to the purposes of the processing; (GDPR Article 4(9)) Explanatory text: Data recipient has a broader (not limited to IoT) meaning in the context of data transactions enabled by data space: ''A transaction participant to whom data is, or is to be technically supplied by a data provider in the context of a specific data transaction''. When we use data recipient in the meaning of DA (IoT data), we specify it with DA at the end of the word.
Data user	a natural or legal person who has lawful access to certain personal or non-personal data and has the right, including under Regulation (EU) 2016/679 in the case of personal data, to use that data for commercial or noncommercial purposes; (DGA Article 2(9))
Data intermediation service	a service that is legally defined in the Data Governance Act and enforced by national agencies. An operator in a data space may qualify as a data intermediation service provider, depending on the scope of the services. DGA definition (simplified): ‘Data intermediation service’ means a service which aims to establish commercial relationships for the purposes of data sharing between an undetermined number of data subjects and data holders on the one hand and data users on the other through technical, legal or other means, including for the purpose of exercising the rights of data subjects in relation to personal data. (DGA Article 2 (11)) Explanatory text: Services that fall within this definition will be bound to comply with a range of obligations. The most important two are: (1) Service providers cannot use the data for other purposes than facilitating the exchange between the users of the service; (2) Services of intermediation (e.g. catalogue services, app stores) have to be separate from services providing applications. Both rules are meant to provide for a framework of truly neutral data intermediaries.
Data altruism	the voluntary sharing of data on the basis of the consent of data subjects to process personal data pertaining to them, or permissions of data holders to allow the use of their non-personal data without seeking or receiving a reward that goes beyond compensation related to the costs that they incur where they make their data available for objectives of general interest as provided for in national law, where applicable, such as healthcare, combating climate change, improving mobility, facilitating the development, production and dissemination of official statistics, improving the provision of public services, public policy making or scientific research purposes in the general interest; (DGA Article 2(16))
Personal data	any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; (GDPR Article 4(1))
Non-personal data	data other than personal data; (DGA Article 2(4))
Data subject	an identified or identifiable natural person that personal data relates to. (GDPR Article 4(1)) Explanatory text: Data subject is implicitly defined in the definition of ‘personal data’. In the context of data spaces we use the broader term data rights holder, to refer to the party that has (legal) rights and/or obligations to use, grant access to or share certain personal or non-personal data. For personal data, this would equal the data subject.
Consent	any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her; (GDPR Article 4(11))

This page lists all terms that have been specified in the glossary tables that exist in the building blocks or other pages of the Blueprint v3.0. Each entry shows a term as it is defined, and the building blocks or pages where the definition came from (the Source). A term will have multiple entries in this table if it has been defined in a different way in different building blocks or pages (note that typos or punctuation changes may also trigger an additional entry).

Please note that all “Data Space” terms are listed twice in the table, with and without the “Data Space” prefix, to simply the search (example: Agreement and Data Space Agreement).

For all readers, the purpose of this page is to provide a full alphabetical overview of all terms defined in the Blueprint. For all authors, this page allows to check whether the terms they rely on are already in use somewhere, and if so, where that is, so that they can start harmonising terms if they think that is necessary.

DSSC Glossary (Blueprint Vsn 3.0)

Term	Description
Access Control Source : Access & Usage Policies Enforcement	Systems and policies that regulate who can access specific data resources and under what conditions.
Accreditation Sources : - Identity & Attestation Management - Trust Framework	third-party attestation related to a conformity assessment body, conveying formal demonstration of its competence, impartiality and consistent operation in performing specific conformity assessment activities (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Accreditation Body Source : Trust Framework	Authoritative body that performs accreditation (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Agreement Source : Contractual Framework	A contract that states the rights and duties (obligations) of parties that have committed to (signed) it in the context of a particular data space. These rights and duties pertain to the data space and/or other such parties. Note : This term was automatically generated as a synonym for: data-space-agreement
Application Profile Source : Data Models	A data model that specifies the usage of information in a particular application or domain, often customised from existing data models (e.g., ontologies) to address specific application needs and domain requirements.
Assurance Source : 8 Identity and Trust	An artefact that helps parties make trust decisions about a claim, such as certificates, commitments, contracts, warranties, etc. Explanatory Text : Also defined as: grounds for justified confidence that a claim has been or will be achieved [ISO/IEC/IEEE 15026-1:2019, 3.1.1]
Attestation Sources : - 8 Identity and Trust - Identity & Attestation Management - Trust Framework	Issue of a statement, based on a decision, that fulfilment of specified requirements has been demonstrated (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Blueprint Source : 9 Building Blocks and Implementations	A consistent, coherent and comprehensive set of guidelines to support the implementation, deployment and maintenance of data spaces. Explanatory Text : The blueprint contains the conceptual model of data space, data space building blocks, and recommended selection of standards, specifications and reference implementations identified in the data spaces technology landscape. Note : This term was automatically generated as a synonym for: data-spaces-blueprint
Building Block Source : 9 Building Blocks and Implementations	A description of related functionalities and/or capabilities that can be realised and combined with other building blocks to achieve the overall functionality of a data space. Explanatory Texts : - In the data space blueprint the building blocks are divided into organisational and business building blocks and technical building blocks. - In many cases, the functionalities are implemented by Services Note : This term was automatically generated as a synonym for: data-space-building-block
Business Model Source : Business Model	A description of the way an organisation creates, delivers, and captures value. Such a description typically includes for whom value is created (customer) and what the value proposition is.Typically, a tool called business model canvas is used to describe or design a business model, but alternatives that are more suitable for specific situations, such as data spaces, are available.
Candidate Source : Participation Management	A party interested in joining a data space as a participant.
Catalogue Source : Publication and Discovery	A functional component to provision and discover offerings of data and services in a data space.
Certification Source : Identity & Attestation Management	third-party attestation related to an object of conformity assessment, with the exception of accreditation (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Claim Sources : - 8 Identity and Trust - Identity & Attestation Management - Trust Framework	an assertion made about a subject . (ref. Verifiable Credentials Data Model v2.0 (w3.org)
Collaborative Business Model Source : Business Model	A description of the way multiple organizations collectively create, deliver and capture value. Typically, this level of value creation would not be achievable by a single organization.A collaborative business model is better suited to express a value creation system consisting of multiple actors. Intangible values such as sovereignty, solidarity, and security cannot be expressed through a transactional approach (which is common in firm-centric business models) but require a system perspective.
Common European Data Spaces Source : 11 Foundation of the European Data Economy Concepts	Sectoral/domain-specific data spaces established in the European single market with a clear EU-wide scope that adheres to European rules and values. Explanatory Texts : - Common European Data Spaces are mentioned in the EU data strategy and introduced in the EC Staff Working Document on Common European Data Spaces and on this site: https://digital-strategy.ec.europa.eu/en/policies/data-spaces . - It is furthermore referenced in the Data Governance Act with the following description: Purpose-, sector-specific or cross-sectoral interoperable frameworks of common standards and practices to share or jointly process data for, inter alia, development of new products and services, scientific research or civil society initiatives. - Such sectoral/domain-specific Common European Data Spaces are being supported through EU-funding programmes, e.g. DIGITAL, Horizon Europe. In some domains (Health, Procurement) specific regulations towards the establishment of such data spaces are forthcoming.
Community Heartbeat Source : 10 DSSC Specific Terms	The regular release of the data spaces blueprint, data spaces building blocks, other DSSC assets and supporting activities, as outlined in a public roadmap. The regular releases aim to engage the community of practice into a rhythm of communication, co-learning and continuous improvement.
Community Of Practice Source : 10 DSSC Specific Terms	The set of existing and emerging data space initiatives in all sectors and the set of (potential) data space component implementers. DSSC prioritises the data space projects funded by the Digital Europe Programme and other relevant programmes and will later expand to additional data space initiatives.
Compliance Service Source : Identity & Attestation Management	Service taking as input the Verifiable Credentials provided by the participants, checking them against the SHACL Shapes available in the Data Space Registry and performing other consistency checks based on rules in the data space conformity assessment scheme.
Component Source : 9 Building Blocks and Implementations	A specification for a software or other artefact that realises one service or a set of services that fulfil functionalities described by one or more building blocks. Explanatory Text : For technical components, that would typically be software, but for business components, this could consist of processes, templates or other artefacts. Note : This term was automatically generated as a synonym for: data-space-component
Component Architecture Source : 9 Building Blocks and Implementations	An overview of all the data space components and their interactions, providing a high-level structure of how these components are organised and interact within data spaces. Note : This term was automatically generated as a synonym for: data-space-component-architecture
Conceptual Model Of Data Space Source : 10 DSSC Specific Terms	A consistent, coherent and comprehensive description of the concepts and their relationships that can be used to unambiguously explain what data spaces and data space initiatives are about.
Conformity Assessment Source : Identity & Attestation Management	demonstration that specified requirements are fulfilled (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Conformity Assessment Body Sources : - Identity & Attestation Management - Trust Framework	A body that performs conformity assessment activities, excluding accreditation (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Conformity Assessment Scheme Source : Identity & Attestation Management	set of rules and procedures that describe the objects of conformity assessment, identifies the specified requirements and provides the methodology for performing conformity assessment. (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles ).
Consensus Protocol Source : Data Exchange_	The data exchange protocol that is globally accepted in a domain Explanatory Text : In some domains the data exchange protocols are ‘de facto’ standards (e.g. NGSI for smart cities).
Continuous Improvement Process Source : Use Case Development	Continuously analyzing the performance of use cases, identifying improvement opportunities, and planning and implementing changes in a systematic and managed way throughout the life cycle of a use case.
Contract Source : Contractual Framework	A formal, legally binding agreement between two or more parties with a common interest in mind that creates mutual rights and obligations enforceable by law.
Contractual Framework Source : Contractual Framework	The set of legally binding agreements that regulates the relationship between data space participants and the data space (institutional agreements), transactions between data space participants (data-sharing agreements) and the provision of services (service agreements) within the context of a single data space.
Credential Schema Source : Identity & Attestation Management	In the W3C Verifiable Credentials Data Model v2.0. the value of the “credentialSchema” property must be one or more data schemas that provide verifiers with enough information to determine whether the provided data conforms to the provided schema(s). (ref: https://www.w3.org/TR/vc-data-model-2.0/#data-schemas )
Credential Store Source : Identity & Attestation Management	A service used to issue, store, manage, and present Verifiable Credentials.
Cross Data Space Use Case Source : 2 Data Space Use Cases and Business Model	A specific setting in which participants of multiple data spaces create value (business, societal or environmental) from sharing data across these data spaces.
Cross Use Case Source : 2 Data Space Use Cases and Business Model	A specific setting in which participants of multiple data spaces create value (business, societal or environmental) from sharing data across these data spaces. Note : This term was automatically generated as a synonym for: cross-data-space-use-case
Cross- Interoperability Source : 7 Interoperability	The ability of participants to seamlessly access and/or exchange data across two or more data spaces. Cross-data spaces interoperability addresses the governance, business and technical frameworks to interconnect multiple data space instances seamlessly. Explanatory Text : Inter-data space interoperability is an alternative term and both terms can be used interchangeably. Note : This term was automatically generated as a synonym for: cross-data-space-interoperability
Cross-data Space Interoperability Source : 7 Interoperability	The ability of participants to seamlessly access and/or exchange data across two or more data spaces. Cross-data spaces interoperability addresses the governance, business and technical frameworks to interconnect multiple data space instances seamlessly. Explanatory Text : Inter-data space interoperability is an alternative term and both terms can be used interchangeably.
Data Access Policy Source : 6 Data Policies and Contracts	A specific data policy defined by the data rights holder for accessing their shared data in a data space. Explanatory Text : A data access policy that provides operational guidance to a data provider for deciding whether to process or reject a request for providing access to specific data. Data access policies are created and maintained by the data rights holders.
Data Act Source : 11 Foundation of the European Data Economy Concepts	A European regulation that establishes EU-wide rules for access to the product or related service data to the user of that connected product or service. The regulation also includes essential requirements for the interoperability of data spaces (Article 33) and essential requirements for smart contracts to implement data sharing agreements (Article 36). Explanatory Text : More info can be found here: Data Act explained \| Shaping Europe’s digital future and the Data Act Frequently-asked-questions.
Data Consumer Source : 5 Data Products and Transactions	A synonym of data product consumer
Data Consumer Source : Publication and Discovery	A consumer of data or service.
Data Element Source : Data Models	the smallest units of data that carry a specific meaning within a dataset. Each data element has a name, a defined data type (such as text, number, or date), and often a description that explains what it represents.
Data Governance Act Source : 11 Foundation of the European Data Economy Concepts	A European regulation that aims to create a framework to facilitate European data spaces and increase trust between actors in the data market. The DGA entered into force in June 2022 and applies from Sept 2023. The DGA defines the European Data Innovation Board (EDIB).
Data Model Source : Data Models	A structured representation of data elements and relationships used to facilitate semantic interoperability within and across domains, encompassing vocabularies, ontologies, application profiles and schema specifications for annotating and describing data sets and services.These abstraction levels may not need to be hierarchical; they can exist independently.
Data Model Provider Source : Data Models	An entity responsible for creating, publishing, and maintaining data models within data spaces. This entity facilitates the management process of vocabulary creation, management, and updates.
Data Policy Source : 6 Data Policies and Contracts	A set of rules, working instructions, preferences and other guidance to ensure that data is obtained, stored, retrieved, and manipulated consistently with the standards set by the governance framework and/or data rights holders. Explanatory Text : Data policies govern aspects of data management within or between data spaces, such as access, usage, security, and hosting.
Data Policy Enforcement Source : 6 Data Policies and Contracts	A set of measures and mechanisms to monitor, control and ensure adherence to established data policies. Explanatory Text : Policies can be enforced by technology or organisational manners.
Data Policy Negotiation Source : 6 Data Policies and Contracts	The process of reaching agreements on data policies between a data rights holder, a data provider and a data recipient. The negotiation can be fully machine-processable and immediate or involve human activities as part of the workflow.
Data Product Sources : - 1 Key Concept Definitions - 5 Data Products and Transactions	Data sharing units, packaging data and metadata, and any associated license terms. Explanatory Texts : - We borrow this definition from the CEN Workshop Agreement Trusted Data Transactions. - The data product may include, for example, the data products' allowed purposes of use, quality and other requirements the data product fulfils, access and control rights, pricing and billing information, etc.
Data Product Consumer Source : 5 Data Products and Transactions	A party that commits to a data product contract concerning one or more data products. Explanatory Texts : - A data product consumer is a data space participant. - The data product consumer can be referred to as the data user. In principle, the data product consumer could be a different party than the eventual data user, but in many cases these parties are the same and the terms are used exchangeably.
Data Product Contract Sources : - 5 Data Products and Transactions - Contractual Framework	A legal contract that specifies a set of rights and duties for the respective parties that will perform the roles of the data product provider and data product consumer.
Data Product Owner Source : 5 Data Products and Transactions	A party that develops, manages and maintains a data product. Explanatory Texts : - The data product owner can be the same party as the data rights holder, or it can receive the right to process the data from the data rights holder (the right can be obtained through a permission, consent or license and may be ruled by a legal obligation or a contract). - A data product owner is not necessarily a data space participant.
Data Product Provider Source : 5 Data Products and Transactions	A party that acts on behalf of a data product owner in providing, managing and maintaining a data product in a data space. Explanatory Texts : - The data product provider can be referred to as the data provider. In general use that is fine, but in specific cases the data product provider might be a different party than the data rights holder and different than the data product owner. - A data product provider is a data space participant. - For reference, the definition from the CEN Workshop Agreement Trusted Data Transactions: a party that has the right or duty to make data available to data users through data products. Note: a data provider carries out several activities, ie.: - non-technical, on behalf of a data rights holder, including the description of the data products, data licence terms, the publishing of data products in a data product catalogue, the negotiation with the data users, and the conclusion of contracts, - technical, with the provision of the data products to the data users.
Data Provider Source : 5 Data Products and Transactions	A synonym of data product provider
Data Provider Source : Publication and Discovery	A provider of data or service.
Data Rights Holder Source : 5 Data Products and Transactions	A party with legitimate interests to exercise rights under Union law affecting the use of data or imposing obligations on other parties in relation to the data. Explanatory Texts : - This party can be a data space participant, but not necessarily, when the party provides permission/consent for a data provider or data product provider to act on its behalf and participate in the actual data sharing. - Previous definition (for reference): A party that has legal rights and/or obligations to use, grant access to or share certain personal or non-personal data. Data rights holders may transfer such rights to others. - For reference, the definition from the CEN Workshop Agreement Trusted Data Transactions: a natural or legal person that has legal rights or obligations to use, grant access to or share certain data, or transfer such rights to others
Data Schema Source : Data Models	A data model that defines the structure, data types, and constraints. Such a schema includes the technical details of the data structure for the data exchange, usually expressed in metamodel standards like JSON or XML Schema.
Data Service Source : 4 Data Space Services	A collection of operations that provides access to one or more datasets or data processing functions. For example, data selection, extraction, data delivery. Explanatory Text : In the CEN Workshop Agreement Trusted Data Transactions the data service enables data sharing or data exchange (synonyms). The use of the data can be synchronous or asynchronous. Data can be shared, for example, (i) by allowing access to the original data set, or (ii) by giving a copy of the data to the interested entity.
Data Sovereignty Source : 11 Foundation of the European Data Economy Concepts	The ability of individuals, organisations, and governments to have control over their data and exercise their rights on the data, including its collection, storage, sharing, and use by others. Explanatory Text : Data sovereignty is a central concept in the European data strategy and recent European laws and regulations are expanding upon these rights and controls. EU law applies to data collected in the EU and/or about data subjects in the EU.
Data Space Sources : - 1 Key Concept Definitions - Data, Services, and Offerings Descriptions - Participation Management	Interoperable framework, based on common governance principles, standards, practices and enabling services, that enables trusted data transactions between participants. Explanatory Texts : - Note for users of V0.5 and V1.0 of this blueprint: we have adopted this new definition from CEN Workshop Agreement Trusted Data Transactions, in an attempt to converge with ongoing standardisation efforts. Please note that further evolution might occur in future versions. For reference, the previous definition was: “Distributed system defined by a governance framework that enables secure and trustworthy data transactions between participants while supporting trust and data sovereignty. A data space is implemented by one or more infrastructures and enables one or more use cases.” - Note: some parties write dataspace in a single word. We prefer data space in two words and consider that both terms mean exactly the same.
Data Space Agreement Source : Contractual Framework	A contract that states the rights and duties (obligations) of parties that have committed to (signed) it in the context of a particular data space. These rights and duties pertain to the data space and/or other such parties.
Data Space Building Block Source : 9 Building Blocks and Implementations	A description of related functionalities and/or capabilities that can be realised and combined with other building blocks to achieve the overall functionality of a data space. Explanatory Texts : - In the data space blueprint the building blocks are divided into organisational and business building blocks and technical building blocks. - In many cases, the functionalities are implemented by Services
Data Space Component Source : 9 Building Blocks and Implementations	A specification for a software or other artefact that realises one service or a set of services that fulfil functionalities described by one or more building blocks. Explanatory Text : For technical components, that would typically be software, but for business components, this could consist of processes, templates or other artefacts.
Data Space Component Architecture Source : 9 Building Blocks and Implementations	An overview of all the data space components and their interactions, providing a high-level structure of how these components are organised and interact within data spaces.
Data Space Development Processes Source : 3 Evolution of Data Space Initiatives	A set of essential processes the stakeholders of a data space initiative conduct to establish and continuously develop a data space throughout its development cycle.
Data Space Functionality Source : 1 Key Concept Definitions	A specified set of tasks that are critical for operating a data space and that can be associated with one or more data space roles. Explanatory Text : The data space governance framework specifies the data space functionalities and associated roles. Each functionality and associated role consist of rights and duties for performing tasks related to that functionality.
Data Space Governance Authority Source : 1 Key Concept Definitions	The body of a particular data space, consisting of participants that is committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework. Explanatory Texts : - A ‘body’ is a group of parties that govern, manage, or act on behalf of a specific purpose, entity, or area of law. This term, which has legal origins, can encompass entities like legislative bodies, governing bodies, or corporate bodies. - The data space governance authority does not replace the role of public regulation and enforcement authorities. - Establishing the initial data space governance framework is outside the governance authority's scope and needs to be defined by a group of data space initiating parties. - After establishment, the governance authority performs the governing function (developing and maintaining the governance framework) and the executive function (operating and enforcing the governance framework). - Depending on the legal form and the size of the data space, the governance and executive functions of a data space governance authority may or may not be performed by the same party.
Data Space Governance Authority Sources : - Identity & Attestation Management - Trust Framework	The body of a particular data space, consisting of participants that are committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework.
Data Space Governance Authority Source : Provenance, Traceability & Observability	A governance authority refers to bodies of a data space that are composed of and by data space participants responsible for developing and maintaining as well as operating and enforcing the internal rules.
Data Space Governance Authority (DSGA) Source : Participation Management	The body of a particular data space, consisting of participants that is committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework.
Data Space Governance Framework Source : 1 Key Concept Definitions	The structured set of principles, processes, standards, protocols, rules and practices that guide and regulate the governance, management and operations within a data space to ensure effective and responsible leadership, control, and oversight. It defines the functionalities the data space provides and the associated data space roles, including the data space governance authority and participants. Explanatory Texts : - Functionalities include, e.g., the maintenance of the governance framework the functioning of the data space governance authority and the engagement of the participants. - The responsibilities covered in the governance framework include assigning the governance authority and formalising the decision-making powers of participants. - The data space governance framework specifies the procedures for enforcing the governance framework and conflict resolution. - The operations may also include business and technology aspects.
Data Space Infrastructure (deprecated Term) Source : 1 Key Concept Definitions	A technical, legal, procedural and organisational set of components and services that together enable data transactions to be performed in the context of one or more data spaces. Explanatory Text : This term was used in the data space definition in previous versions of the Blueprint. It is replaced by the governance framework and enabling services, and may be deprecated from this glossary in a future version.
Data Space Initiative Source : 3 Evolution of Data Space Initiatives	A collaborative project of a consortium or network of committed partners to initiate, develop and maintain a data space.
Data Space Intermediary Source : Data, Services, and Offerings Descriptions	A data space intermediary is a service provider who provides an enabling service or services in a data space. In common usage interchangeable with ‘operator'.
Data Space Interoperability Source : 7 Interoperability	The ability of participants to seamlessly exchange and use data within a data space or between two or more data spaces. Explanatory Texts : - Interoperability generally refers to the ability of different systems to work in conjunction with each other and for devices, applications or products to connect and communicate in a coordinated way without effort from the users of the systems. On a high-level, there are four layers of interoperability: legal, organisational, semantic and technical (see the European Interoperability Framework [EIF]). - Legal interoperability: Ensuring that organisations operating under different legal frameworks, policies and strategies are able to work together. - Organisational interoperability: The alignment of processes, communications flows and policies that allow different organisations to use the exchanged data meaningfully in their processes to reach commonly agreed and mutually beneficial goals. - Semantic interoperability: The ability of different systems to have a common understanding of the data being exchanged. - Technical interoperability: The ability of different systems to communicate and exchange data. - Also the ISO/IEC 19941:2017 standard [20] is relevant here. - Note: As per Art. 2 r.40 of the Data Act: ‘interoperability’ means the ability of two or more data spaces or communication networks, systems, connected products, applications, data processing services or components to exchange and use data in order to perform their functions. We describe this wider term as cross-data space interoperability.
Data Space Maturity Model Source : 3 Evolution of Data Space Initiatives	Set of indicators and a self-assessment tool allowing data space initiatives to understand their stage in the development cycle, their performance indicators and their technical, functional, operational, business and legal capabilities in absolute terms and in relation to peers.
Data Space Operational Processes Source : 3 Evolution of Data Space Initiatives	A set of essential processes a potential or actual data space participant goes through when engaging with a functioning data space that is in the operational stage or scaling stage. The operational processes include attracting and onboarding participants, publishing and matching use cases, data products and data requests and eventually data transactions.
Data Space Participant Sources : - 1 Key Concept Definitions - Data, Services, and Offerings Descriptions - Participation Management	A party committed to the governance framework of a particular data space and having a set of rights and obligations stemming from this framework. Explanatory Text : Depending on the scope of the said rights and obligations, participants may perform in (multiple) different roles, such as: data space members, data space users, data space service providers and others as described in this glossary.
Data Space Pilot Source : 3 Evolution of Data Space Initiatives	A planned and resourced implementation of one or more use cases within the context of a data space initiative. A data space pilot aims to validate the approach for a full data space deployment and showcase the benefits of participating in the data space.
Data Space Role Sources : - 1 Key Concept Definitions - Participation Management	A distinct and logically consistent set of rights and duties (responsibilities) within a data space, that are required to perform specific tasks related to a data space functionality, and that are designed to be performed by one or more participants. Explanatory Texts : - The governance framework of a data space defines the data space roles. - Parties can perform (be assigned, or simply ‘be’) multiple roles, such as data provider, transaction participant, data space intermediary, etc.. In some cases, a prerequisite for performing a particular role is that the party can already perform one or more other roles. For example, the data provider must also be a data space participant.
Data Space Rulebook Source : 1 Key Concept Definitions	The documentation of the data space governance framework for operational use. Explanatory Text : The rulebook can be expressed in human-readable and machine-readable formats.
Data Space Service Offering Credential Source : Identity & Attestation Management	A service description that follows the schemas defined by the Data Space Governance Authority and whose claims are validated by the Data Space Compliance Service.
Data Space Services Sources : - 1 Key Concept Definitions - 4 Data Space Services	Functionalities for implementing data space capabilities, offered to participants of data spaces. Explanatory Texts : - We distinguish three classes of technical services which are further defined in section 4 of this glossary: Participant Agent Services, Facilitating Services, Value-Creation Services. Technical (software) components are needed to implement these services. - Also on the business and organisational side, services may exist to support participants and orchestrators of data spaces, further defined in section 4 of this glossary and discussed in the Business and Organisational building blocks introduction. - Please note that a Data Service is a specific type of service related to the data space offering, providing access to one or more datasets or data processing functions.
Data Space Support Organisation Source : 10 DSSC Specific Terms	An organisation, consortium, or collaboration network that specifies architectures and frameworks to support data space initiatives. Examples include Gaia-X, IDSA, FIWARE, iSHARE, MyData, BDVA, and more.
Data Space Use Case Source : 1 Key Concept Definitions	A specific setting in which two or more participants use a data space to create value (business, societal or environmental) from data sharing. Explanatory Texts : - By definition, a data space use case is operational. When referring to a planned or envisioned setting that is not yet operational we can use the term use case scenario. - Use case scenario is a potential use case envisaged to solve societal, environmental or business challenges and create value. The same use case scenario, or variations of it, can be implemented as a use case multiple times in one or more data spaces.
Data Space Value Source : 2 Data Space Use Cases and Business Model	The cumulative value generated from all the data transactions and use cases within a data space as data space participants collaboratively use it. Explanatory Text : The definition of “data space value” is agnostic to value sharing and value capture. It just states where the value is created (in the use cases). The use case orchestrator should establish a value-sharing mechanism within the use case to make all participants happy. Furthermore, to avoid the free rider problem, the data space governance authority may also want to establish a value capture mechanism (for example, a data space usage fee) to get its part from the value created in the use cases.
Data Spaces Blueprint Source : 9 Building Blocks and Implementations	A consistent, coherent and comprehensive set of guidelines to support the implementation, deployment and maintenance of data spaces. Explanatory Text : The blueprint contains the conceptual model of data space, data space building blocks, and recommended selection of standards, specifications and reference implementations identified in the data spaces technology landscape.
Data Spaces Information Model Source : 3 Evolution of Data Space Initiatives	A classification scheme used to describe, analyse and organise a data space initiative according to a defined set of questions.
Data Spaces Radar Source : 3 Evolution of Data Space Initiatives	A publicly accessible tool to provide an overview of the data space initiatives, their sectors, locations and approximate development stages.
Data Spaces Starter Kit Source : 10 DSSC Specific Terms	A document that helps organisations and individuals in the network of stakeholders to understand the requirements for creating a data space.
Data Spaces Support Centre Source : 10 DSSC Specific Terms	The virtual organisation and EU-funded project which supports the deployment of common European data spaces and promotes the reuse of data across sectors.
Data Spaces Technology Landscape Source : 10 DSSC Specific Terms	A repository of standards (de facto and de jure), specifications and open-source reference implementations available for deploying data spaces. The Data Space Support Centre curates the repository and publishes it with the blueprint.
Data Transaction Sources : - 1 Key Concept Definitions - Participation Management	A structured interaction between data space participants for the purpose of providing and obtaining/using a data product. An end-to-end data transaction consists of various phases, such as contract negotiation, execution, usage, etc. Explanatory Texts : - In future work we may align further with the definition from CEN Workshop Agreement Trusted Data Transactions: result of an agreement between a data provider and a data user with the purpose of exchanging, accessing and using data, in return for monetary or non-monetary compensation. - A data transaction implies data transfer among involved participants and its usage on a lawful and contractual basis. It relates to the technical, financial, legal and organisational arrangements necessary to make a data set from Participant A available to Participant B. The physical data transfer may or may not happen during the data transaction. - Prerequisites: - the specification of data products and the creation and publication of data product offerings so parties can search for offerings, compare them and engage in data transactions to obtain the offered data product. - Key elements related to data transactions are: - negotiation (at the business level) of a contract between the provider and user of a data product, which includes, e.g., pricing, the use of appropriate intermediary services, etc. - negotiation (at the operational level) of an agreement between the provider and the user of a data product, which includes, e.g., technical policies and configurations, such as sending - ensuring that parties that provide, receive, use, or otherwise act with the data have the rights/duties they need to comply with applicable policies and regulations (e.g. from the EU) - accessing and/or transferring the data (product) between provider, user, and transferring this data and/or meta-data to (contractually designated) other participants, such as observers, clearing house services, etc. - Data access and data usage by the data consumer. - All activities listed above do not need to be conducted in every transaction and that parts of the activities may be visited in loops or conditional flows.
Data Usage Policy Source : 6 Data Policies and Contracts	A specific data policy defined by the data rights holder for the usage of their data shared in a data space. Explanatory Text : Data usage policy regulates the permissible actions and behaviours related to the utilisation of the accessed data, which means keeping control of data even after the items have left the trust boundaries of the data provider.
Data User Source : 5 Data Products and Transactions	a natural or legal person who has lawful access to certain personal or non-personal data and has the right, including under Regulation (EU) 2016/679 in the case of personal data, to use that data for commercial or noncommercial purposes; ( DGA Article 2 (9)) Explanatory Texts : - In many cases the data user is the same party as the data consumer or data product consumer, but exceptions may exist where these roles are separate. - For reference, the definition from the CEN Workshop Agreement Trusted Data Transactions which considers the term to be synonymous with data consumer: person or organization authorized to exploit data (ISO 5127:2017) Note 1: Data are in the form of data products. Note 2: Data consumer is considered as a synonym of data user.
Dataset Description Source : Data, Services, and Offerings Descriptions	A description of a dataset includes various attributes, such as spatial, temporal, and spatial resolution. The description encompasses attributes related to distribution of datasets such as data format, packaging format, compression format, frequency of updates, download URL, and more. These attributes provide essential metadata that enables data recipients to understand the nature and usability of the datasets.
Dataspace Protocol Source : Provenance, Traceability & Observability	The Eclipse data space Protocol is a set of specifications that enable secure, interoperable data sharing between independent entities by defining standardized models, contracts, and processes for publishing, negotiating, and transferring data within data space s.The current specification can be found at: https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol
Declaration Source : Identity & Attestation Management	first-party attestation (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Development Cycle Source : 3 Evolution of Data Space Initiatives	The sequence of stages that a data space initiative passes through during its progress and growth. In each stage, the initiative has different needs and challenges, and when progressing through the stages, it evolves regarding knowledge, skills and capabilities.
Development Processes Source : 3 Evolution of Data Space Initiatives	A set of essential processes the stakeholders of a data space initiative conduct to establish and continuously develop a data space throughout its development cycle. Note : This term was automatically generated as a synonym for: data-space-development-processes
Digital Europe Programme Source : 11 Foundation of the European Data Economy Concepts	An EU funding programme that funds several data space related projects, among other topics. The programme is focused on bringing digital technology to businesses, citizens and public administrations.
DSSC Asset Source : 10 DSSC Specific Terms	A sustainable open resource that is developed and governed by the Data Spaces Support Centre. The assets can be used to develop, deploy and operationalise data spaces and to enable knowledge sharing around data spaces. The DSSC also develops and executes strategies to provide continuity for the main assets beyond the project funding.
DSSC Glossary Source : 10 DSSC Specific Terms	A limited set of data spaces related terms and corresponding descriptions. Each term refers to a concept, and the term description contains a criterion that enables people to determine whether or not something is an instance (example) of that concept.
DSSC Toolbox Source : 10 DSSC Specific Terms	A catalogue of data space component implementations curated by the Data Space Support Centre.
EIDAS 2 Regulation Source : Identity & Attestation Management	It is an updated version of the original eIDAS regulation, which aims to further enhance trust and security in cross-border digital transactions with the EU.
EIDAS Regulation Source : Identity & Attestation Management	The EU Regulation on electronic identification and trust services for electronic transactions in the internal market
Enabling Services Source : 4 Data Space Services	Refer mutually to facilitating services and participant agent services, hence the technical services that are needed to enable trusted data transaction in data spaces.
European Data Innovation Board Source : 11 Foundation of the European Data Economy Concepts	The expert group established by the Data Governance Act (DGA) to assist the European Commission in the sharing of best practices, in particular on data intermediation, data altruism and the use of public data that cannot be made available as open data, as well as on the prioritisation of cross-sectoral interoperability standards, which includes proposing guidelines for Common European Data Spaces (DGA Article 30 ). The European Data Innovation Board received additional additional assignments under the Data Act (DA Article 42 ).
European Digital Identification (EUDI) Wallet Source : Identity & Attestation Management	The European Digital Identity Regulation introduces the concepts of EU Digital Identity Wallets. They are personal digital wallets that allow citizens to digitally identify themselves, store and manage identity data and official documents in electronic format. These documents may include a driving licence, medical prescriptions or education qualifications.
European Single Market For Data Source : 11 Foundation of the European Data Economy Concepts	A genuine single market for data – open to data from across the world – where personal and non-personal data, including sensitive business data, are secure and businesses also have easy access to high-quality industrial data, boosting growth and creating value. Explanatory Text : Source: European strategy for data
European Strategy For Data Source : 11 Foundation of the European Data Economy Concepts	A vision and measures ( a strategy ) that contribute to a comprehensive approach to the European data economy, aiming to increase the use of, and demand for, data and data-enabled products and services throughout the Single Market. It presents the vision to create a European single market for data.
Evidence Source : Trust Framework	Evidence can be included by an issuer to provide the verifier with additional supporting information in a verifiable credential (ref. Verifiable Credentials Data Model v2.0 (w3.org) )
Exploratory Stage Source : 3 Evolution of Data Space Initiatives	The stage in the development cycle in which a data space initiative starts. Typically, in this stage, a group of people or organisations starts to explore the potential and viability of a data space. The exploratory activities may include, among others, identifying and attracting interested stakeholders, collecting requirements, discussing use cases or reviewing existing conventions or standards.
Facilitating Services Source : 4 Data Space Services	Services which facilitate the interplay of participants in a data space, enabling them to engage in (commercial) data-sharing relationships of all sorts and shapes. Explanatory Text : They are sometimes also called ‘federation services’.
Federated Data Spaces Source : Data Exchange_	A data space that enables seamless data transactions between the participants of multiple data spaces based on agreed common rules, typically set in a governance framework. Explanatory Texts : - The definition of a federation of data spaces is evolving in the data space community. - A federation of data spaces is a data space with its own governance framework, enabled by a set of shared services (federation and value creation) of the federated systems, and participant agent services that enable participants to join multiple data spaces with a single onboarding step.
Finite Data Source : Data Exchange_	Data that is defined by a finite set, such as a fixed dataset.
First-party Conformity Assessment Activity Source : Identity & Attestation Management	conformity assessment activity that is performed by the person or organization that provides or that is the object of conformity assessment (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Functionality Source : 1 Key Concept Definitions	A specified set of tasks that are critical for operating a data space and that can be associated with one or more data space roles. Explanatory Text : The data space governance framework specifies the data space functionalities and associated roles. Each functionality and associated role consist of rights and duties for performing tasks related to that functionality. Note : This term was automatically generated as a synonym for: data-space-functionality
General Terms And Conditions Source : Contractual Framework	An agreement defining the roles, relationships, rights and obligations of data space participants.
Geoquerying Source : Data Exchange_	Query involving geographical boundaries Explanatory Text : Data querying frequently needs to be restricted to a geographical area.
Governance Source : Business Model	A description of how a group of organizations (necessary for a data space) is managed, organised, and regulated by agreements and processes, as well as how the partners control and influence its evolution and performance over time.Due to the collaborative nature of a data space business model, governance of affiliated and non-affiliated actors can be seen as strongly complementary to the business model and other building blocks.
Governance Authority Source : 1 Key Concept Definitions	The body of a particular data space, consisting of participants that is committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework. Explanatory Texts : - A ‘body’ is a group of parties that govern, manage, or act on behalf of a specific purpose, entity, or area of law. This term, which has legal origins, can encompass entities like legislative bodies, governing bodies, or corporate bodies. - The data space governance authority does not replace the role of public regulation and enforcement authorities. - Establishing the initial data space governance framework is outside the governance authority's scope and needs to be defined by a group of data space initiating parties. - After establishment, the governance authority performs the governing function (developing and maintaining the governance framework) and the executive function (operating and enforcing the governance framework). - Depending on the legal form and the size of the data space, the governance and executive functions of a data space governance authority may or may not be performed by the same party. Note : This term was automatically generated as a synonym for: data-space-governance-authority
Governance Authority Sources : - Identity & Attestation Management - Trust Framework	The body of a particular data space, consisting of participants that are committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework. Note : This term was automatically generated as a synonym for: data-space-governance-authority
Governance Authority Source : Provenance, Traceability & Observability	A governance authority refers to bodies of a data space that are composed of and by data space participants responsible for developing and maintaining as well as operating and enforcing the internal rules. Note : This term was automatically generated as a synonym for: data-space-governance-authority
Governance Authority (dsga) Source : Participation Management	The body of a particular data space, consisting of participants that is committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework. Note : This term was automatically generated as a synonym for: data-space-governance-authority-dsga
Governance Framework Source : 1 Key Concept Definitions	The structured set of principles, processes, standards, protocols, rules and practices that guide and regulate the governance, management and operations within a data space to ensure effective and responsible leadership, control, and oversight. It defines the functionalities the data space provides and the associated data space roles, including the data space governance authority and participants. Explanatory Texts : - Functionalities include, e.g., the maintenance of the governance framework the functioning of the data space governance authority and the engagement of the participants. - The responsibilities covered in the governance framework include assigning the governance authority and formalising the decision-making powers of participants. - The data space governance framework specifies the procedures for enforcing the governance framework and conflict resolution. - The operations may also include business and technology aspects. Note : This term was automatically generated as a synonym for: data-space-governance-framework
Guidelines For Common European Data Spaces Source : 11 Foundation of the European Data Economy Concepts	The Data Governance Act (DGA Article 30(h )) defines that the European Data Innovation Board will propose guidelines for common European data spaces. The guidelines shall address, among other things: (i) cross-sectoral standards for data sharing, (ii) counter barriers to market entry and avoiding lock-in effects and ensuring fair competition and interoperability, (iii) protection for lawful data transfers to third countries, (iv) non-discriminatory representation of relevant stakeholders in the governance of Common European Data Spaces and (v) adherence to cybersecurity requirements.
Holder Source : Identity & Attestation Management	A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. A holder is often, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories . (ref. Verifiable Credentials Data Model v2.0 (w3.org) )
Horizon Europe Programme Source : 11 Foundation of the European Data Economy Concepts	An EU funding programme that funds data space related research and innovation projects, among other topics.
Identifying And Tracking Use Case Scenarios Source : Use Case Development	Collecting ideas for use case scenarios through activities such as observing potential users’ needs and analysing other data spaces and platforms.
Identity Source : Identity & Attestation Management	an Identity is composed of a unique Identifier , associated with an attribute or set of attributes that uniquely describe an entity within a given context and policies determining the roles, permissions, prohibitions, and duties of the entity in the data space
Implementation Of A Component Source : 9 Building Blocks and Implementations	The result of translating/converting a data space component into a functional and usable artefact, such as executable code or other tool. Note : This term was automatically generated as a synonym for: implementation-of-a-data-space-component
Implementation Of A Data Space Component Source : 9 Building Blocks and Implementations	The result of translating/converting a data space component into a functional and usable artefact, such as executable code or other tool.
Implementation Stage Source : 3 Evolution of Data Space Initiatives	The stage in the development cycle that starts when a data space initiative has a sufficiently detailed project plan, milestones and resources (funding and other) for developing its governance framework and infrastructure in the context of a data space pilot. It is typical for this stage that the parties involved in the pilot and the value created for each are also clearly identified.
Implementing Use Cases Source : Use Case Development	Implementing use cases both from organisational and business perspectives (e.g., agreements) and from technical perspectives (e.g., vocabularies, APIs, connectors).
Information Model Source : 3 Evolution of Data Space Initiatives	A classification scheme used to describe, analyse and organise a data space initiative according to a defined set of questions. Note : This term was automatically generated as a synonym for: data-spaces-information-model
Infrastructure (deprecated Term) Source : 1 Key Concept Definitions	A technical, legal, procedural and organisational set of components and services that together enable data transactions to be performed in the context of one or more data spaces. Explanatory Text : This term was used in the data space definition in previous versions of the Blueprint. It is replaced by the governance framework and enabling services, and may be deprecated from this glossary in a future version. Note : This term was automatically generated as a synonym for: data-space-infrastructure-deprecated-term
Initiative Source : 3 Evolution of Data Space Initiatives	A collaborative project of a consortium or network of committed partners to initiate, develop and maintain a data space. Note : This term was automatically generated as a synonym for: data-space-initiative
Intermediary Source : 4 Data Space Services	Service provider who provides an enabling service or services in a data space. In common usage interchangeable with ‘operator'.
Intermediary Source : Data, Services, and Offerings Descriptions	A data space intermediary is a service provider who provides an enabling service or services in a data space. In common usage interchangeable with ‘operator'. Note : This term was automatically generated as a synonym for: data-space-intermediary
Interoperability Source : 7 Interoperability	The ability of participants to seamlessly exchange and use data within a data space or between two or more data spaces. Explanatory Texts : - Interoperability generally refers to the ability of different systems to work in conjunction with each other and for devices, applications or products to connect and communicate in a coordinated way without effort from the users of the systems. On a high-level, there are four layers of interoperability: legal, organisational, semantic and technical (see the European Interoperability Framework [EIF]). - Legal interoperability: Ensuring that organisations operating under different legal frameworks, policies and strategies are able to work together. - Organisational interoperability: The alignment of processes, communications flows and policies that allow different organisations to use the exchanged data meaningfully in their processes to reach commonly agreed and mutually beneficial goals. - Semantic interoperability: The ability of different systems to have a common understanding of the data being exchanged. - Technical interoperability: The ability of different systems to communicate and exchange data. - Also the ISO/IEC 19941:2017 standard [20] is relevant here. - Note: As per Art. 2 r.40 of the Data Act: ‘interoperability’ means the ability of two or more data spaces or communication networks, systems, connected products, applications, data processing services or components to exchange and use data in order to perform their functions. We describe this wider term as cross-data space interoperability. Note : This term was automatically generated as a synonym for: data-space-interoperability
Intra- Interoperability Source : 7 Interoperability	The ability of participants to seamlessly access and/or exchange data within a data space. Intra-data space interoperability addresses the governance, business and technical frameworks (including the data space protocol and the data models) for individual data space instances. Note : This term was automatically generated as a synonym for: intra-data-space-interoperability
Intra-data Space Interoperability Source : 7 Interoperability	The ability of participants to seamlessly access and/or exchange data within a data space. Intra-data space interoperability addresses the governance, business and technical frameworks (including the data space protocol and the data models) for individual data space instances.
Issuer Sources : - Identity & Attestation Management - Trust Framework	A role an entity can perform by asserting claims about one or more subjects , creating a verifiable credential from these claims , and transmitting the verifiable credential to a holder . (ref. Verifiable Credentials Data Model v2.0 (w3.org) )
LOTL (List Of Trusted Lists) Source : Trust Framework	List of qualified trust service providers in accordance with the eIDAS Regulation published by the Member States of the European Union and the European Economic Area (EU/EEA)
Machine-Readable Policy Source : Access & Usage Policies Enforcement	A policy expressed in a standard format (ODRL) that computers can automatically process, evaluate, and enforce.
Maturity Model Source : 3 Evolution of Data Space Initiatives	Set of indicators and a self-assessment tool allowing data space initiatives to understand their stage in the development cycle, their performance indicators and their technical, functional, operational, business and legal capabilities in absolute terms and in relation to peers. Note : This term was automatically generated as a synonym for: data-space-maturity-model
Membership Credential Source : Identity & Attestation Management	credential issued by the Data Space Governance Authority after having assessed compliance of an entity to its rules. This credential attest participation in a data space.
Meta-standard Source : Data Models	A standard designed to define or annotate data models within a particular domain or across multiple domains. These meta-standards provide a framework or guidelines for creating and annotating other standards (data models), ensuring consistency, interoperability, and compatibility.
Multi-Sided Business Model Source : Business Model	A business model is said to be multi-sided if an organization serves different segments, and those segments also interact. An example is Airbnb, where apartments are offered to travellers. This is also referred to as a ‘platform business model’.A data space differs in two important ways from a platform business model: In order to establish sovereignty and avoid undesired ‘winner-takes-all’ effects, control of the sharing of data essentially lies with the data owner and the infrastructure is distributed.
Network Of Stakeholders Source : 10 DSSC Specific Terms	The group of parties relevant to the development of data spaces and with whom the Data Spaces Support Centre proactively engages in achieving its purpose and objectives. The community of practice is the core subset of this network of stakeholders and the primary focus group for the DSSC.
Non-Finite Data Source : Data Exchange_	Data that is defined by an infinite set or has no specified end, such as continuous streams.
Notary Source : Trust Framework	Notaries are entities accredited by the Data Space, which perform validation based on objective evidence from a data space Trusted Data source, digitalising an assessment previously made.
Object Of Conformity Assessment Source : Identity & Attestation Management	entity to which specified requirements apply (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Observability Source : Provenance, Traceability & Observability	The ability to monitor, measure and understand the internal states of processes through its outputs such as logs, metrics and traces.
Offering Source : Data, Services, and Offerings Descriptions	Data product(s), service(s), or a combination of these, and the offering description. Explanatory Text : Offerings can be put to a catalogue.
Offering Source : Publication and Discovery	Data product(s), service(s), or a combination of these, and the offering description. Offerings can be put into a catalogue.
Offering Description Source : Data, Services, and Offerings Descriptions	A text that specifies the terms, conditions and other specifications, according to which an offering will be provided and can be consumed. Explanatory Texts : - Offering descriptions contain all the information needed for a potential consumer to make a decision whether to consume the data product(s) and/or the service(s) or not. - This may include information such as description, provider, pricing, license, data format, access rights, etc. - The offering description can also detail the structure of the offering, how data products and services can be obtained, and applicable rights and duties. - Typically offering descriptions are machine-readable metadata.
Ontology Source : Data Models	A data model that defines knowledge within and across domains by modelling information objects and their relationships, often expressed in open metamodel standards like OWL, RDF, or UML.
Operational Processes Source : 3 Evolution of Data Space Initiatives	A set of essential processes a potential or actual data space participant goes through when engaging with a functioning data space that is in the operational stage or scaling stage. The operational processes include attracting and onboarding participants, publishing and matching use cases, data products and data requests and eventually data transactions. Note : This term was automatically generated as a synonym for: data-space-operational-processes
Operational Stage Source : 3 Evolution of Data Space Initiatives	The stage in the development cycle that starts when a data space initiative has a tested implementation of infrastructure(s) and governance framework, and the first use case becomes operational (data flowing between data providers and data recipients and use case providing the intended value).
Operator Source : 4 Data Space Services	Service provider that provides enabling services that are common to all participants of the data space. In common usage interchangeable with ‘intermediary’. Explanatory Text : We use typically the term ‘operator’ when a single actor is assigned by the governance authority to manage the enabling services and when it is responsible for the operation of the data space, ensuring functionality and reliability as specified in the governance framework.
Participant Sources : - 1 Key Concept Definitions - Data, Services, and Offerings Descriptions - Participation Management	A party committed to the governance framework of a particular data space and having a set of rights and obligations stemming from this framework. Explanatory Text : Depending on the scope of the said rights and obligations, participants may perform in (multiple) different roles, such as: data space members, data space users, data space service providers and others as described in this glossary. Note : This term was automatically generated as a synonym for: data-space-participant
Participant Agent Source : 4 Data Space Services	A technology system used to conduct activities in a data space on behalf of a party. Explanatory Text : The participant agent can offer technical modules that implement data interoperability functions, authentication interfacing with trust services and authorisation, data product self-description, contract negotiation, etc. A ‘connector’ is an implementation of a participant agent service.
Participant Agent Services Source : 4 Data Space Services	Services to enable an individual participant to interact within the data space, facilitate the sharing (providing or using) of data, specify access and usage policies, and more. Explanatory Text : The participant agent services provide operations on the control plane that are executing the data services on the data plane. The control plane and data plane should work together to manage the data transfer process. After contract negotiation, the technical transfer process can take place.
Party Source : 1 Key Concept Definitions	A natural person or a legal person Explanatory Text : Parties are organisations (enterprises, governmental bodies, not-for-profits) or human beings, i.e. entities that set their own objectives and that ‘sovereignly’ decide what they do and do not do.
Pilot Source : 3 Evolution of Data Space Initiatives	A planned and resourced implementation of one or more use cases within the context of a data space initiative. A data space pilot aims to validate the approach for a full data space deployment and showcase the benefits of participating in the data space. Note : This term was automatically generated as a synonym for: data-space-pilot
Policy Source : Access & Usage Policies Enforcement	A machine-readable rule that expresses permissions, prohibitions, or obligations regarding data access and usage. Policies are encoded in ODRL and implement the terms and conditions defined in data product contracts. See 3.4.2.1 Data product contract in Contractual Framework building block.
Policy Definition Language Source : 6 Data Policies and Contracts	A machine-processable mechanism for representing statements about the data policies, e.g., Open Digital Rights Language (ODRL)
Policy Negotiation Source : Access & Usage Policies Enforcement	The process through which a data provider and consumer agree on machine-readable policies for data sharing. The provider offers policies, the consumer may propose alternatives, resulting in a mutually acceptable data product contract.
Policy Validation Source : Access & Usage Policies Enforcement	The process of verifying that policies are correctly structured, consistent, and free from conflicts.
Preparatory Stage Source : 3 Evolution of Data Space Initiatives	The stage in the development cycle that starts when a data space initiative has a critical mass of committed stakeholders and there is an agreement to move forward with the initiative and proceed towards creating a data space. It is typical for this stage that such partners jointly develop use cases and prepare to implement the data space.
Provenance Source : Provenance, Traceability & Observability	The place of origin or earliest known history of something. Usually it is the backwards-looking direction of a data value chain which is also referred to as provenance tracking
Pull Transfer Source : Data Exchange_	A data transfer initiated by the consumer, where data is retrieved from the provider.
Push Transfer Source : Data Exchange_	A data transfer initiated by the provider, where data is sent to the consumer.
Reference Datasets Source : Data Models	Reference data, such as code lists and authority tables, means data that are used to characterise or relate to other data. Such a reference data, defines the permissible values to be used in a specific field for example as metadata. Reference data vocabularies are fundamental building blocks of most information systems. Using common interoperable reference data is essential for achieving interoperability.
Refining Use Case Scenarios Source : Use Case Development	Refining the description and design of use case scenarios using templates like the Data Cooperation Canvas, Use Case Playbook, or self-created templates.
Relationship Manager Source : 10 DSSC Specific Terms	A person from the Data Spaces Support Centre who serves as the dedicated DSSC contact point for a data space initiative or another member of the community of practice.
Rulebook Source : 1 Key Concept Definitions	The documentation of the data space governance framework for operational use. Explanatory Text : The rulebook can be expressed in human-readable and machine-readable formats. Note : This term was automatically generated as a synonym for: data-space-rulebook
Scaling Stage Source : 3 Evolution of Data Space Initiatives	The stage in the development cycle that starts when a data space initiative has been proven to consistently and organically gain new participants and embrace new use cases. In this stage, the data space can realistically be expected to be financially and operationally sustainable, respond to market changes, and grow over time.
Scope Of Attestation Source : Identity & Attestation Management	range or characteristics of objects of conformity assessment covered by attestation .
Second-party Conformity Assessment Activity Source : Identity & Attestation Management	conformity assessment activity that is performed by a person or organization that has a user interest in the object of conformity assessment (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Service Description Source : Data, Services, and Offerings Descriptions	A service description is composed of attributes related to data services, including endpoint description and endpoint URL. Additionally, it may encompass a wide range of attributes related to value-added technical- and support services such as software-, platform-, infrastructure-, security-, communication-, and managed services. These services are used for various purposes, such as data quality, analysis, and visualisation.
Service Offering Credential Source : Identity & Attestation Management	A service description that follows the schemas defined by the Data Space Governance Authority and whose claims are validated by the Data Space Compliance Service. Note : This term was automatically generated as a synonym for: data-space-service-offering-credential
Services Sources : - 1 Key Concept Definitions - 4 Data Space Services	Functionalities for implementing data space capabilities, offered to participants of data spaces. Explanatory Texts : - We distinguish three classes of technical services which are further defined in section 4 of this glossary: Participant Agent Services, Facilitating Services, Value-Creation Services. Technical (software) components are needed to implement these services. - Also on the business and organisational side, services may exist to support participants and orchestrators of data spaces, further defined in section 4 of this glossary and discussed in the Business and Organisational building blocks introduction. - Please note that a Data Service is a specific type of service related to the data space offering, providing access to one or more datasets or data processing functions. Note : This term was automatically generated as a synonym for: data-space-services
Smart Contract Source : Contractual Framework	A computer program used for the automated execution of an agreement or part thereof, using a sequence of electronic data records and ensuring their integrity and the accuracy of their chronological ordering (Art 2(39) Data Act)
Starter Kit Source : 10 DSSC Specific Terms	A document that helps organisations and individuals in the network of stakeholders to understand the requirements for creating a data space. Note : This term was automatically generated as a synonym for: data-spaces-starter-kit
Strategic Stakeholder Forum Source : 10 DSSC Specific Terms	The designated group of experts that provide strategic support for the DSSC and make recommendations for the governance and sustainability of the DSSC assets. The strategic stakeholder forum is composed of a large variety of stakeholders with a balanced geographical distribution and will evolve progressively.
Subject Source : Identity & Attestation Management	thing about which claims are made (ref. Verifiable Credentials Data Model v2.0 (w3.org) )
Support Organisation Source : 10 DSSC Specific Terms	An organisation, consortium, or collaboration network that specifies architectures and frameworks to support data space initiatives. Examples include Gaia-X, IDSA, FIWARE, iSHARE, MyData, BDVA, and more. Note : This term was automatically generated as a synonym for: data-space-support-organisation
Synergy Between Data Spaces Source : 2 Data Space Use Cases and Business Model	The gained efficiency, increased impact or other benefits of two or more data spaces working together that are greater than if the data spaces were working separately. The synergies between data spaces can be enabled by common practices, communication concepts, services and/or components, which increase data space interoperability and enable harmonised processes of using different data spaces.
Technology Landscape Source : 10 DSSC Specific Terms	A repository of standards (de facto and de jure), specifications and open-source reference implementations available for deploying data spaces. The Data Space Support Centre curates the repository and publishes it with the blueprint. Note : This term was automatically generated as a synonym for: data-spaces-technology-landscape
Third-party Conformity Assessment Activity Source : Identity & Attestation Management	conformity assessment activity that is performed by a person or organization that is independent of the provider of the object of conformity assessment and has no user interest in the object (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Traceability Source : Provenance, Traceability & Observability	The quality of having an origin or course of development that may be found or followed
Transfer Process (TP) Source : Data Exchange_	A process that manages the lifecycle of data exchange between a provider and a consumer, involving, in example, states, as a minimum, REQUESTED, STARTED, COMPLETED, SUSPENDED, and TERMINATED.
Trust Anchor Source : 8 Identity and Trust	An authoritative entity for which trust is assumed and not derived. Each Trust Anchor is accepted by the data space governance authority in relation to a specific scope of attestation .
Trust Anchor Source : Trust Framework	An entity for which trust is assumed and not derived. Each Trust Anchor is accepted by the data space governance authority in relation to a specific scope of attestation .
Trust Decision Source : 8 Identity and Trust	A judgement made by a party to rely on some statement being true without requiring absolute proof or certainty.
Trust Framework Source : 8 Identity and Trust	A composition of policies, rules, standards, and procedures designed for trust decisions in data spaces based on assurances. Trust framework is part of the data space governance framework. Explanatory Texts : - A trust framework is comprised of: - (business-related) policies, rules, and standards collected and documented in the rulebook. - procedures for automation and implementation of the business-related components.
Trust Framework Source : Trust Framework	A trust framework is comprised of:(business-related) policies, rules, and standards collected and documented in the rulebook.procedures for automation and implementation of the business-related components.
Trust Service Source : Access & Usage Policies Enforcement	A service that verifies claims used in policy evaluation (e.g., participant credentials, certifications). Examples include identity providers and credential verification services.
Trust Service Provider Source : Trust Framework	Trust Service Providers (also referred to as Trusted Issuers) are legal or natural persons deriving their trust from one or more Trust Anchors and designated by the data space governance authority as parties eligible to issue attestations about specific objects.
Trusted Data Source Source : Trust Framework	Source of the information used by the issuer to validate attestations. The data space defines the list of Trusted Data Sources for the Data Space Conformity Assessment Scheme/s.
Usage Control Source : Access & Usage Policies Enforcement	Mechanisms that specify and enforce how data can be used after access has been granted.
Use Case Source : 1 Key Concept Definitions	A specific setting in which two or more participants use a data space to create value (business, societal or environmental) from data sharing. Explanatory Texts : - By definition, a data space use case is operational. When referring to a planned or envisioned setting that is not yet operational we can use the term use case scenario. - Use case scenario is a potential use case envisaged to solve societal, environmental or business challenges and create value. The same use case scenario, or variations of it, can be implemented as a use case multiple times in one or more data spaces. Note : This term was automatically generated as a synonym for: data-space-use-case
Use Case Development Source : 2 Data Space Use Cases and Business Model	A strategic approach to amplify the value of a data space by fostering the creation, support and scaling of use cases.
Use Case Orchestrator Source : 2 Data Space Use Cases and Business Model	A data space participant that represents and is accountable for a specific use case in the context of the governance framework. The orchestrator establishes and enforces business rules and other conditions to be followed by the use case participants. [role]
Use Case Participant Source : 2 Data Space Use Cases and Business Model	A data space participant that is engaged with a specific use case. [role]
Validation Sources : - 8 Identity and Trust - Identity & Attestation Management	Confirmation of plausibility for a specific intended use or application through the provision of objective evidence that specified requirements have been fulfilled (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Value Creation Services Source : Value creation services	(technical) elements or components designed to unlock, generate and maximize the value of data shared within a data space, providing additional functionalities on top of the core process of data sharing or data transaction. Explanatory Texts : - This value is delivered both for (i) data space participants (by enabling services and applications that operate on top of data exchanges and transactions), and (ii) for the data space itself (supporting and enhancing core functionalities, such as semantic interoperability, data quality, discoverability, trust mechanisms and others) - Value creation services act over data products, and are combined with them in data space offerings, to perfom the functionalities required by the defined use cases. - Value creation services complement the capabilities provided by the “federation services” and the “participant agent” services - This value creation can come from different sides: complementing the essential capabilities of the data space, acting directly over datasets that these services are tied to, as part of data products, adding value on top of data products and data transactions, enabling the connection to external infrastructures, required to, among others, process, store and collect data, either as part of the normal operation of the data space or as needed by some use cases, enabling the connection to external applications, which are required for the complete development of use cases, facilitating by any other means the materialization of the business models considered in the data space.
Value Proposition Source : Business Model	A value proposition reflects the benefits for a segment of customers when adopting an offer.Benefits are typically associated with so-called pains and gains and are, therefore, fundamentally linked to key customer processes. In the case of a data space, a lack of control by data owners (sovereignty) represents one potential pain; other pains include the inaccessibility of data and non-interoperable data sources, which drive up the costs of innovative data-driven applications.
Value-creation Services Source : 4 Data Space Services	(Technical) elements or components designed to unlock, generate and maximize the value of data shared within a data space, providing additional functionalities on top of the core process of data sharing or data transaction. Explanatory Texts : - This value is delivered both for (i) data space participants (by enabling services and applications that operate on top of data exchanges and transactions), and (ii) for the data space itself (supporting and enhancing core functionalities, such as semantic interoperability, data quality, discoverability, trust mechanisms and others) - Value creation services act over data products, and are combined with them in data space offerings, to perfom the functionalities required by the defined use cases. - Value creation services complement the capabilities provided by the “federation services” and the “participant agent” services - This value creation can come from different sides: complementing the essential capabilities of the data space, acting directly over datasets that these services are tied to, as part of data products, adding value on top of data products and data transactions, enabling the connection to external infrastructures, required to, among others, process, store and collect data, either as part of the normal operation of the data space or as needed by some use cases, enabling the connection to external applications, which are required for the complete development of use cases, facilitating by any other means the materialization of the business models considered in the data space.
Verifiable Credential Sources : - Identity & Attestation Management - Trust Framework	A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations , which can also be cryptographically verified (ref. https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential )
Verifiable ID Source : Identity & Attestation Management	It refers to a type of Verifiable Credential that a natural person or legal entity can use to demonstrate who they are. This verifiableID can be used for Identification and Authentication. (ref. Verifiable Attestation for ID - EBSI Specifications - ( http://europa.eu/ ))
Verifiable Presentation Source : Identity & Attestation Management	A tamper-evident presentation of information encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but does not contain, the original verifiable credentials (for example, zero-knowledge proofs). (ref. Verifiable Credentials Data Model v2.0 (w3.org) )
Verification Sources : - 8 Identity and Trust - Identity & Attestation Management	Confirmation of truthfulness through the provision of objective evidence that specified requirements have been fulfilled (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Verifier Source : Identity & Attestation Management	A role an entity performs by receiving one or more verifiable credentials , optionally inside a verifiable presentation for processing. Other specifications might refer to this concept as a relying party. (ref. Verifiable Credentials Data Model v2.0 (w3.org) )
Vocabulary Source : Data Models	A data model that contains basic concepts and relationships expressed as terms and definitions within a domain or across domains, typically described in a meta-standard like SKOS.
Vocabulary Service Source : Data Models	A technical component providing facilities for publishing, editing, browsing and maintaining vocabularies and related documentation.

Note: this page is not intended and not useful for first time readers.

This page lists all terms that have been specified in the alphabetical list of all defined terms of bv30 (Blueprint v3.0) and bv20 (Blueprint v2.0).

For readers of the previous Blueprint version, this page helps to detect the changes between the terms in the two latest blueprint versions, which can be done by inspecting the sources of each of the definitions. Please note that all “Data Space” terms are listed twice in the table, with and without the “Data Space” prefix, to simply the search (example: Agreement and Data Space Agreement).

If the definition remained the same, both bv20 and bv30 are listed in the Source field (example: Accreditation). If the definitions changed, separate entries are added to this table (example: Business Model). Please note that typo’s and punctuation may also trigger new entries (example: Agreement).

DSSC Glossary of All Terms

Term	Description
Access Control Sources (vsn) : - Access & Usage Policies Enforcement (bv20) - Access & Usage Policies Enforcement (bv30)	Systems and policies that regulate who can access specific data resources and under what conditions.
Accreditation Sources (vsn) : - Identity & Attestation Management (bv30) - Trust Framework (bv30)	third-party attestation related to a conformity assessment body, conveying formal demonstration of its competence, impartiality and consistent operation in performing specific conformity assessment activities (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Accreditation Body Source (vsn) : Trust Framework (bv30)	Authoritative body that performs accreditation (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Agreement Source (vsn) : Contractual Framework (bv30)	A contract that states the rights and duties (obligations) of parties that have committed to (signed) it in the context of a particular data space. These rights and duties pertain to the data space and/or other such parties. Note : This term was automatically generated as a synonym for: data-space-agreement
Agreements Related To Enabling Services Source (vsn) : Contractual Framework (bv20)	These agreements are entered into by the data space governance authority to provide the services necessary for the data space to operate. They can be classified as data-related services, agreements for the provision of trust framework services, and agreements for the management of identities.
Application Profile Sources (vsn) : - Data Models (bv20) - Data Models (bv30)	A data model that specifies the usage of information in a particular application or domain, often customised from existing data models (e.g., ontologies) to address specific application needs and domain requirements.
Assurance Source (vsn) : 8 Identity and Trust (bv20)	An artefact that helps parties make trust decisions, such as certificates, commitments, contracts, warranties, etc.
Assurance Source (vsn) : 8 Identity and Trust (bv30)	An artefact that helps parties make trust decisions about a claim, such as certificates, commitments, contracts, warranties, etc. Explanatory Text : Also defined as: grounds for justified confidence that a claim has been or will be achieved [ISO/IEC/IEEE 15026-1:2019, 3.1.1]
Attestation Sources (vsn) : - 8 Identity and Trust (bv30) - Identity & Attestation Management (bv30) - Trust Framework (bv30)	Issue of a statement, based on a decision, that fulfilment of specified requirements has been demonstrated (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Blueprint Sources (vsn) : - 9 Building Blocks and Implementations (bv20) - 9 Building Blocks and Implementations (bv30)	A consistent, coherent and comprehensive set of guidelines to support the implementation, deployment and maintenance of data spaces. Explanatory Text : The blueprint contains the conceptual model of data space, data space building blocks, and recommended selection of standards, specifications and reference implementations identified in the data spaces technology landscape. Note : This term was automatically generated as a synonym for: data-spaces-blueprint
Building Block Sources (vsn) : - 9 Building Blocks and Implementations (bv20) - 9 Building Blocks and Implementations (bv30)	A description of related functionalities and/or capabilities that can be realised and combined with other building blocks to achieve the overall functionality of a data space. Explanatory Texts : - In the data space blueprint the building blocks are divided into organisational and business building blocks and technical building blocks. - In many cases, the functionalities are implemented by Services Note : This term was automatically generated as a synonym for: data-space-building-block
Business Model Source (vsn) : Business Model (bv30)	A description of the way an organisation creates, delivers, and captures value. Such a description typically includes for whom value is created (customer) and what the value proposition is.Typically, a tool called business model canvas is used to describe or design a business model, but alternatives that are more suitable for specific situations, such as data spaces, are available.
Candidate Source (vsn) : Participation Management (bv30)	A party interested in joining a data space as a participant.
Catalogue Source (vsn) : Publication and Discovery (bv30)	A functional component to provision and discover offerings of data and services in a data space.
Certification Source (vsn) : Identity & Attestation Management (bv30)	third-party attestation related to an object of conformity assessment, with the exception of accreditation (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Claim Sources (vsn) : - 8 Identity and Trust (bv30) - Identity & Attestation Management (bv30) - Trust Framework (bv30)	an assertion made about a subject . (ref. Verifiable Credentials Data Model v2.0 (w3.org)
Collaborative Business Model Source (vsn) : Business Model (bv30)	A description of the way multiple organizations collectively create, deliver and capture value. Typically, this level of value creation would not be achievable by a single organization.A collaborative business model is better suited to express a value creation system consisting of multiple actors. Intangible values such as sovereignty, solidarity, and security cannot be expressed through a transactional approach (which is common in firm-centric business models) but require a system perspective.
Common European Data Spaces Sources (vsn) : - 11 Foundation of the European Data Economy Concepts (bv20) - 11 Foundation of the European Data Economy Concepts (bv30)	Sectoral/domain-specific data spaces established in the European single market with a clear EU-wide scope that adheres to European rules and values. Explanatory Texts : - Common European Data Spaces are mentioned in the EU data strategy and introduced in the EC Staff Working Document on Common European Data Spaces and on this site: https://digital-strategy.ec.europa.eu/en/policies/data-spaces. - It is furthermore referenced in the Data Governance Act with the following description: Purpose-, sector-specific or cross-sectoral interoperable frameworks of common standards and practices to share or jointly process data for, inter alia, development of new products and services, scientific research or civil society initiatives. - Such sectoral/domain-specific Common European Data Spaces are being supported through EU-funding programmes, e.g. DIGITAL, Horizon Europe. In some domains (Health, Procurement) specific regulations towards the establishment of such data spaces are forthcoming.
Community Heartbeat Source (vsn) : 10 DSSC Specific Terms (bv30)	The regular release of the data spaces blueprint, data spaces building blocks, other DSSC assets and supporting activities, as outlined in a public roadmap. The regular releases aim to engage the community of practice into a rhythm of communication, co-learning and continuous improvement.
Community Of Practice Source (vsn) : 10 DSSC Specific Terms (bv30)	The set of existing and emerging data space initiatives in all sectors and the set of (potential) data space component implementers. DSSC prioritises the data space projects funded by the Digital Europe Programme and other relevant programmes and will later expand to additional data space initiatives.
Compliance Service Source (vsn) : Identity & Attestation Management (bv30)	Service taking as input the Verifiable Credentials provided by the participants, checking them against the SHACL Shapes available in the Data Space Registry and performing other consistency checks based on rules in the data space conformity assessment scheme.
Component Sources (vsn) : - 9 Building Blocks and Implementations (bv20) - 9 Building Blocks and Implementations (bv30)	A specification for a software or other artefact that realises one service or a set of services that fulfil functionalities described by one or more building blocks. Explanatory Text : For technical components, that would typically be software, but for business components, this could consist of processes, templates or other artefacts. Note : This term was automatically generated as a synonym for: data-space-component
Component Architecture Sources (vsn) : - 9 Building Blocks and Implementations (bv20) - 9 Building Blocks and Implementations (bv30)	An overview of all the data space components and their interactions, providing a high-level structure of how these components are organised and interact within data spaces. Note : This term was automatically generated as a synonym for: data-space-component-architecture
Conceptual Model Of Data Space Source (vsn) : 10 DSSC Specific Terms (bv30)	A consistent, coherent and comprehensive description of the concepts and their relationships that can be used to unambiguously explain what data spaces and data space initiatives are about.
Conformity Assessment Source (vsn) : Identity & Attestation Management (bv30)	demonstration that specified requirements are fulfilled (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Conformity Assessment Body Sources (vsn) : - Identity & Attestation Management (bv30) - Trust Framework (bv30)	A body that performs conformity assessment activities, excluding accreditation (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Conformity Assessment Scheme Source (vsn) : Identity & Attestation Management (bv30)	set of rules and procedures that describe the objects of conformity assessment, identifies the specified requirements and provides the methodology for performing conformity assessment. (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles ).
Connected Product Source (vsn) : Regulatory Compliance (bv20)	an item that obtains, generates or collects data concerning its use or environment and that is able to communicate product data via an electronic communications service, physical connection or on-device access, and whose primary function is not the storing, processing or transmission of data on behalf of any party other than the user (art. 2 (5) DA). Explanatory Text : This term is defined as per the Data Act. This clarification ensures that the definition is understood within the specific regulatory context of the Data Act while allowing the same term to be used in other contexts with different meanings.
Connector Source (vsn) : 4 Data Space Services (bv20)	A technical component that is run by (or on behalf of) a participant and that provides participant agent services, with similar components run by (or on behalf of) other participants. Explanatory Text : A connector can provide more functionality than is strictly related to connectivity. The connector can offer technical modules that implement data interoperability functions, authentication interfacing with trust services and authorisation, data product self-description, contract negotiation, etc. We use “participant agent services” as the broader term to define these services. Note : This term was automatically generated as a synonym for: data-space-connector
Consensus Protocol Sources (vsn) : - Data Exchange (bv20) - Data Exchange_ (bv30)	The data exchange protocol that is globally accepted in a domain Explanatory Text : In some domains the data exchange protocols are ‘de facto’ standards (e.g. NGSI for smart cities).
Consent Source (vsn) : Regulatory Compliance (bv20)	any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her;( GDPR Article 4(11) )
Consent Management Source (vsn) : Access & Usage Policies Enforcement (bv20)	The process of obtaining, recording, managing, and enforcing user consent for data processing and sharing.
Continuous Improvement Process Sources (vsn) : - Use Case Development (bv20) - Use Case Development (bv30)	Continuously analyzing the performance of use cases, identifying improvement opportunities, and planning and implementing changes in a systematic and managed way throughout the life cycle of a use case.
Contract Source (vsn) : Contractual Framework (bv30)	A formal, legally binding agreement between two or more parties with a common interest in mind that creates mutual rights and obligations enforceable by law.
Contractual Framework Source (vsn) : Contractual Framework (bv30)	The set of legally binding agreements that regulates the relationship between data space participants and the data space (institutional agreements), transactions between data space participants (data-sharing agreements) and the provision of services (service agreements) within the context of a single data space.
Core Platform Service Source (vsn) : Regulatory Compliance (bv20)	a service that means any of the following: online intermediation services; online search engines; online social networking services; video-sharing platform services; number-independent interpersonal communications services; (f) operating systems;web browsers; virtual assistants; cloud computing services; online advertising services, including any advertising networks, advertising exchanges and any other advertising intermediation services, provided by an undertaking that provides any of the core platform services listed in points (1) to (9);
Credential Schema Source (vsn) : Identity & Attestation Management (bv30)	In the W3C Verifiable Credentials Data Model v2.0. the value of the “credentialSchema” property must be one or more data schemas that provide verifiers with enough information to determine whether the provided data conforms to the provided schema(s). (ref: https://www.w3.org/TR/vc-data-model-2.0/#data-schemas )
Credential Store Source (vsn) : Identity & Attestation Management (bv30)	A service used to issue, store, manage, and present Verifiable Credentials.
Cross Data Space Use Case Source (vsn) : 2 Data Space Use Cases and Business Model (bv30)	A specific setting in which participants of multiple data spaces create value (business, societal or environmental) from sharing data across these data spaces.
Cross Use Case Source (vsn) : 2 Data Space Use Cases and Business Model (bv30)	A specific setting in which participants of multiple data spaces create value (business, societal or environmental) from sharing data across these data spaces. Note : This term was automatically generated as a synonym for: cross-data-space-use-case
Cross- Interoperability Source (vsn) : 7 Interoperability (bv30)	The ability of participants to seamlessly access and/or exchange data across two or more data spaces. Cross-data spaces interoperability addresses the governance, business and technical frameworks to interconnect multiple data space instances seamlessly. Explanatory Text : Inter-data space interoperability is an alternative term and both terms can be used interchangeably. Note : This term was automatically generated as a synonym for: cross-data-space-interoperability
Cross-data Space Interoperability Source (vsn) : 7 Interoperability (bv30)	The ability of participants to seamlessly access and/or exchange data across two or more data spaces. Cross-data spaces interoperability addresses the governance, business and technical frameworks to interconnect multiple data space instances seamlessly. Explanatory Text : Inter-data space interoperability is an alternative term and both terms can be used interchangeably.
Data Source (vsn) : Regulatory Compliance (bv20)	any digital representation of acts, facts or information and any compilation of such acts, facts or information, including in the form of sound, visual or audiovisual recording;( DGA Article 2(1) ) Explanatory Text : The definition is the same in the Open Data Directive and the Data Act.
Data Access Policy Source (vsn) : 6 Data Policies and Contracts (bv30)	A specific data policy defined by the data rights holder for accessing their shared data in a data space. Explanatory Text : A data access policy that provides operational guidance to a data provider for deciding whether to process or reject a request for providing access to specific data. Data access policies are created and maintained by the data rights holders.
Data Act Sources (vsn) : - 11 Foundation of the European Data Economy Concepts (bv20) - 11 Foundation of the European Data Economy Concepts (bv30)	A European regulation that establishes EU-wide rules for access to the product or related service data to the user of that connected product or service. The regulation also includes essential requirements for the interoperability of data spaces (Article 33) and essential requirements for smart contracts to implement data sharing agreements (Article 36). Explanatory Text : More info can be found here: Data Act explained \| Shaping Europe’s digital future and the Data Act Frequently-asked-questions.
Data Altruism Source (vsn) : Regulatory Compliance (bv20)	the voluntary sharing of data on the basis of the consent of data subjects to process personal data pertaining to them, or permissions of data holders to allow the use of their non-personal data without seeking or receiving a reward that goes beyond compensation related to the costs that they incur where they make their data available for objectives of general interest as provided for in national law, where applicable, such as healthcare, combating climate change, improving mobility, facilitating the development, production and dissemination of official statistics, improving the provision of public services, public policy making or scientific research purposes in the general interest;( DGA Article 2(16) )
Data Altruism Organisations (DAOs) Source (vsn) : Types of Participants (Participant as a Trigger) (bv20)	In the context of data spaces, DAOs can take on a variety of roles as data space participants. They can be data providers, transaction participants, and data space intermediaries (e.g., personal data intermediaries). It is important to address their participation in the data space, especially regarding the value distribution aspects and their potential sponsoring by the data space .
Data Consumer Source (vsn) : 5 Data Products and Transactions (bv30)	A synonym of data product consumer
Data Consumer Source (vsn) : Publication and Discovery (bv30)	A consumer of data or service.
Data Element Source (vsn) : Data Models (bv30)	the smallest units of data that carry a specific meaning within a dataset. Each data element has a name, a defined data type (such as text, number, or date), and often a description that explains what it represents.
Data Governance Source (vsn) : Access & Usage Policies Enforcement (bv20)	framework of policies, processes, and standards that ensure effective management, quality, security, and proper use of data within an organization.
Data Governance Act Sources (vsn) : - 11 Foundation of the European Data Economy Concepts (bv20) - 11 Foundation of the European Data Economy Concepts (bv30)	A European regulation that aims to create a framework to facilitate European data spaces and increase trust between actors in the data market. The DGA entered into force in June 2022 and applies from Sept 2023. The DGA defines the European Data Innovation Board (EDIB).
Data Holder Source (vsn) : Regulatory Compliance (bv20)	a legal person, including public sector bodies and international organisations, or a natural person who is not a data subject with respect to the specific data in question, which, in accordance with applicable Union or national law, has the right to grant access to or to share certain personal data or non-personal data;( DGA Article 2(8) ) a natural or legal person that has the right or obligation, in accordance with this Regulation, applicable Union law or national legislation adopted in accordance with Union law, to use and make available data, including, where contractually agreed, product data or related service data which it has retrieved or generated during the provision of a related service;( DA Article 2(13)) Explanatory Text : In general context we use data holder within the meaning of DGA Art. 2(8) and in case the word data holder is used in the context of DA (IoT data), we identify it with DA at the end of the term. Please note that data rights holder has a specific and different meaning than data holder and is used especially in data transactions.
Data Intermediation Service Source (vsn) : Regulatory Compliance (bv20)	a service that is legally defined in the Data Governance Act and enforced by national agencies. An operator in a data space may qualify as a data intermediation service provider, depending on the scope of the services.DGA definition (simplified): ‘Data intermediation service’ means a service which aims to establish commercial relationships for the purposes of data sharing between an undetermined number of data subjects and data holders on the one hand and data users on the other through technical, legal or other means, including for the purpose of exercising the rights of data subjects in relation to personal data.( DGA Article 2 (11) ) Explanatory Text : Services that fall within this definition will be bound to comply with a range of obligations. The most important two are: (1) Service providers cannot use the data for other purposes than facilitating the exchange between the users of the service; (2) Services of intermediation (e.g. catalogue services, app stores) have to be separate from services providing applications. Both rules are meant to provide for a framework of truly neutral data intermediaries.
Data Intermediation Service Providers (DISPs) Source (vsn) : Types of Participants (Participant as a Trigger) (bv20)	The recent Data Governance Act (DGA) sets out specific requirements for providing data intermediation services. Certain service functions in data spaces are likely to qualify as data intermediation services (see: Data Intermediation Service Provider Flowchart ). A data space governance authority should also evaluate to what extent it organises any services that may qualify as data intermediation services under the DGA. If this is the case, it will need to ensure compliance with the provisions of the DGA.Data Intermediation Service under the Data Governance ActUnder the Data Governance Act, a “data intermediation service” (“DIS”) is defined as a service aiming to establish commercial relationships for the purposes of data sharing between an undetermined number of data subjects and data holders on the one hand and data users on the other.Data intermediation service providers intending to provide data intermediation services are required under the DGA to submit a notification to the competent national authority for data intermediation services. The provision of data intermediation services is subject to a range of conditions, including a limitation on the use by the provider of the data for which it provides data intermediation services.The European Commission hosts a register of data intermediation services recognised in the European Union: https://digital-strategy.ec.europa.eu/en/policies/data-intermediary-services Providers of data intermediation services and data space intermediaries/operatorsIntermediary services are covered more broadly in “ Data Space Intermediaries and Operators ”. The term “data space intermediary” refers to “a data space participant that provides one or more enabling services while not directly participating in the data transactions”. Enabling services refers to “a service that implements a data space functionality that enables data transactions for the transaction participants and/or operational processes for the governance authority.” (see the DSSC Glossary for more information)It is important to note that not all data space intermediaries would be subject to the provisions of the DGA by default. First of all, some of the potential enabling services they provide may not be aimed at establishing commercial relationships for the purposes of data sharing. It may also be the case that, in the circumstances at hand, the services may not result in commercial relationships between an undetermined number of data subjects and data holders on the one hand and data users on the other.Data intermediation services and personal dataThe services of data intermediation service providers may also relate to personal data. In such cases, it is important to appropriately consider the different roles and responsibilities under the DGA and the GDPR. For a transaction facilitated by a provider of data intermediation services, it is difficult to establish who is acting as the controller, whether there are multiple controllers acting as joint controllers, whether there is a processor and whether data users are data recipients. It may be important to clarify the respective responsibilities of particular data space participants by offering guidance to help ensure overall compliance with obligations under the DGA and the GDPR.
Data Model Sources (vsn) : - Data Models (bv20) - Data Models (bv30)	A structured representation of data elements and relationships used to facilitate semantic interoperability within and across domains, encompassing vocabularies, ontologies, application profiles and schema specifications for annotating and describing data sets and services.These abstraction levels may not need to be hierarchical; they can exist independently.
Data Model Provider Sources (vsn) : - Data Models (bv20) - Data Models (bv30)	An entity responsible for creating, publishing, and maintaining data models within data spaces. This entity facilitates the management process of vocabulary creation, management, and updates.
Data Policy Source (vsn) : 6 Data Policies and Contracts (bv30)	A set of rules, working instructions, preferences and other guidance to ensure that data is obtained, stored, retrieved, and manipulated consistently with the standards set by the governance framework and/or data rights holders. Explanatory Text : Data policies govern aspects of data management within or between data spaces, such as access, usage, security, and hosting.
Data Policy Enforcement Source (vsn) : 6 Data Policies and Contracts (bv30)	A set of measures and mechanisms to monitor, control and ensure adherence to established data policies. Explanatory Text : Policies can be enforced by technology or organisational manners.
Data Policy Negotiation Source (vsn) : 6 Data Policies and Contracts (bv30)	The process of reaching agreements on data policies between a data rights holder, a data provider and a data recipient. The negotiation can be fully machine-processable and immediate or involve human activities as part of the workflow.
Data Processing Source (vsn) : Access & Usage Policies Enforcement (bv20)	Collection, manipulation, and transformation of raw data into meaningful information or results.
Data Product Sources (vsn) : - 1 Key Concept Definitions (bv30) - 5 Data Products and Transactions (bv30) - Data Space Offering (bv20)	Data sharing units, packaging data and metadata, and any associated license terms. Explanatory Texts : - We borrow this definition from the CEN Workshop Agreement Trusted Data Transactions. - The data product may include, for example, the data products' allowed purposes of use, quality and other requirements the data product fulfils, access and control rights, pricing and billing information, etc.
Data Product Consumer Sources (vsn) : - 5 Data Products and Transactions (bv30) - Data Space Offering (bv20)	A party that commits to a data product contract concerning one or more data products. Explanatory Texts : - A data product consumer is a data space participant. - The data product consumer can be referred to as the data user. In principle, the data product consumer could be a different party than the eventual data user, but in many cases these parties are the same and the terms are used exchangeably.
Data Product Contract Sources (vsn) : - 5 Data Products and Transactions (bv30) - Contractual Framework (bv30) - Data Space Offering (bv20)	A legal contract that specifies a set of rights and duties for the respective parties that will perform the roles of the data product provider and data product consumer.
Data Product Owner Sources (vsn) : - 5 Data Products and Transactions (bv30) - Data Space Offering (bv20)	A party that develops, manages and maintains a data product. Explanatory Texts : - The data product owner can be the same party as the data rights holder, or it can receive the right to process the data from the data rights holder (the right can be obtained through a permission, consent or license and may be ruled by a legal obligation or a contract). - A data product owner is not necessarily a data space participant.
Data Product Provider Sources (vsn) : - 5 Data Products and Transactions (bv30) - Data Space Offering (bv20)	A party that acts on behalf of a data product owner in providing, managing and maintaining a data product in a data space. Explanatory Texts : - The data product provider can be referred to as the data provider. In general use that is fine, but in specific cases the data product provider might be a different party than the data rights holder and different than the data product owner. - A data product provider is a data space participant. - For reference, the definition from the CEN Workshop Agreement Trusted Data Transactions: a party that has the right or duty to make data available to data users through data products. Note: a data provider carries out several activities, ie.: - non-technical, on behalf of a data rights holder, including the description of the data products, data licence terms, the publishing of data products in a data product catalogue, the negotiation with the data users, and the conclusion of contracts, - technical, with the provision of the data products to the data users.
Data Provider Source (vsn) : 5 Data Products and Transactions (bv30)	A synonym of data product provider
Data Provider Source (vsn) : Publication and Discovery (bv30)	A provider of data or service.
Data Recipient (Data Act) Source (vsn) : Regulatory Compliance (bv20)	a natural or legal person, acting for purposes which are related to that person’s trade, business, craft or profession, other than the user of a connected product or related service, to whom the data holder makes data available, including a third party following a request by the user to the data holder or in accordance with a legal obligation under Union law or national legislation adopted in accordance with Union law;( DA Article 2(14) ) Explanatory Texts : - Data recipient has a broader (not limited to IoT) meaning in the context of data transactions enabled by data space: ''A transaction participant to whom data is, or is to be technically supplied by a data provider in the context of a specific data transaction''. - When we use data recipient in the meaning of DA (IoT data), we specify it with DA at the end of the word.
Data Rights Holder Sources (vsn) : - 5 Data Products and Transactions (bv30) - Access & Usage Policies Enforcement (bv20)	A party with legitimate interests to exercise rights under Union law affecting the use of data or imposing obligations on other parties in relation to the data. Explanatory Texts : - This party can be a data space participant, but not necessarily, when the party provides permission/consent for a data provider or data product provider to act on its behalf and participate in the actual data sharing. - Previous definition (for reference): A party that has legal rights and/or obligations to use, grant access to or share certain personal or non-personal data. Data rights holders may transfer such rights to others. - For reference, the definition from the CEN Workshop Agreement Trusted Data Transactions: a natural or legal person that has legal rights or obligations to use, grant access to or share certain data, or transfer such rights to others
Data Schema Sources (vsn) : - Data Models (bv20) - Data Models (bv30)	A data model that defines the structure, data types, and constraints. Such a schema includes the technical details of the data structure for the data exchange, usually expressed in metamodel standards like JSON or XML Schema.
Data Service Sources (vsn) : - 4 Data Space Services (bv30) - 5 Data Products and Transactions (bv20)	A collection of operations that provides access to one or more datasets or data processing functions. For example, data selection, extraction, data delivery.
Data Sharing Source (vsn) : Regulatory Compliance (bv20)	the provision of data by a data subject or a data holder to a data user for the purpose of the joint or individual use of such data, based on voluntary agreements or Union or national law, directly or through an intermediary, for example under open or commercial licences subject to a fee or free of charge;( DGA Article 2(10) ) Explanatory Text : In the context of data spaces, data sharing refers to a full spectrum of practices related to sharing any kind of data, including all relevant technical, financial, legal, and organisational requirements.
Data Sovereignty Sources (vsn) : - 11 Foundation of the European Data Economy Concepts (bv20) - 11 Foundation of the European Data Economy Concepts (bv30)	The ability of individuals, organisations, and governments to have control over their data and exercise their rights on the data, including its collection, storage, sharing, and use by others. Explanatory Text : Data sovereignty is a central concept in the European data strategy and recent European laws and regulations are expanding upon these rights and controls. EU law applies to data collected in the EU and/or about data subjects in the EU.
Data Space Sources (vsn) : - 1 Key Concept Definitions (bv30) - Data, Services, and Offerings Descriptions (bv20) - Data, Services, and Offerings Descriptions (bv30) - Participation Management (bv30)	Interoperable framework, based on common governance principles, standards, practices and enabling services, that enables trusted data transactions between participants. Explanatory Texts : - Note for users of V0.5 and V1.0 of this blueprint: we have adopted this new definition from CEN Workshop Agreement Trusted Data Transactions, in an attempt to converge with ongoing standardisation efforts. Please note that further evolution might occur in future versions. For reference, the previous definition was: “Distributed system defined by a governance framework that enables secure and trustworthy data transactions between participants while supporting trust and data sovereignty. A data space is implemented by one or more infrastructures and enables one or more use cases.” - Note: some parties write dataspace in a single word. We prefer data space in two words and consider that both terms mean exactly the same.
Data Space Agreement Source (vsn) : Contractual Framework (bv30)	A contract that states the rights and duties (obligations) of parties that have committed to (signed) it in the context of a particular data space. These rights and duties pertain to the data space and/or other such parties.
Data Space Building Block Sources (vsn) : - 9 Building Blocks and Implementations (bv20) - 9 Building Blocks and Implementations (bv30)	A description of related functionalities and/or capabilities that can be realised and combined with other building blocks to achieve the overall functionality of a data space. Explanatory Texts : - In the data space blueprint the building blocks are divided into organisational and business building blocks and technical building blocks. - In many cases, the functionalities are implemented by Services
Data Space Component Sources (vsn) : - 9 Building Blocks and Implementations (bv20) - 9 Building Blocks and Implementations (bv30)	A specification for a software or other artefact that realises one service or a set of services that fulfil functionalities described by one or more building blocks. Explanatory Text : For technical components, that would typically be software, but for business components, this could consist of processes, templates or other artefacts.
Data Space Component Architecture Sources (vsn) : - 9 Building Blocks and Implementations (bv20) - 9 Building Blocks and Implementations (bv30)	An overview of all the data space components and their interactions, providing a high-level structure of how these components are organised and interact within data spaces.
Data Space Connector Source (vsn) : 4 Data Space Services (bv20)	A technical component that is run by (or on behalf of) a participant and that provides participant agent services, with similar components run by (or on behalf of) other participants. Explanatory Text : A connector can provide more functionality than is strictly related to connectivity. The connector can offer technical modules that implement data interoperability functions, authentication interfacing with trust services and authorisation, data product self-description, contract negotiation, etc. We use “participant agent services” as the broader term to define these services.
Data Space Development Processes Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	A set of essential processes the stakeholders of a data space initiative conduct to establish and continuously develop a data space throughout its development cycle.
Data Space Functionality Source (vsn) : 1 Key Concept Definitions (bv30)	A specified set of tasks that are critical for operating a data space and that can be associated with one or more data space roles. Explanatory Text : The data space governance framework specifies the data space functionalities and associated roles. Each functionality and associated role consist of rights and duties for performing tasks related to that functionality.
Data Space Governance Authority Source (vsn) : 1 Key Concept Definitions (bv30)	The body of a particular data space, consisting of participants that is committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework. Explanatory Texts : - A ‘body’ is a group of parties that govern, manage, or act on behalf of a specific purpose, entity, or area of law. This term, which has legal origins, can encompass entities like legislative bodies, governing bodies, or corporate bodies. - The data space governance authority does not replace the role of public regulation and enforcement authorities. - Establishing the initial data space governance framework is outside the governance authority's scope and needs to be defined by a group of data space initiating parties. - After establishment, the governance authority performs the governing function (developing and maintaining the governance framework) and the executive function (operating and enforcing the governance framework). - Depending on the legal form and the size of the data space, the governance and executive functions of a data space governance authority may or may not be performed by the same party.
Data Space Governance Authority Source (vsn) : Provenance, Traceability & Observability (bv30)	A governance authority refers to bodies of a data space that are composed of and by data space participants responsible for developing and maintaining as well as operating and enforcing the internal rules.
Data Space Governance Authority Sources (vsn) : - Identity & Attestation Management (bv30) - Trust Framework (bv30)	The body of a particular data space, consisting of participants that are committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework.
Data Space Governance Authority (DSGA) Source (vsn) : Participation Management (bv30)	The body of a particular data space, consisting of participants that is committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework.
Data Space Governance Framework Source (vsn) : 1 Key Concept Definitions (bv30)	The structured set of principles, processes, standards, protocols, rules and practices that guide and regulate the governance, management and operations within a data space to ensure effective and responsible leadership, control, and oversight. It defines the functionalities the data space provides and the associated data space roles, including the data space governance authority and participants. Explanatory Texts : - Functionalities include, e.g., the maintenance of the governance framework the functioning of the data space governance authority and the engagement of the participants. - The responsibilities covered in the governance framework include assigning the governance authority and formalising the decision-making powers of participants. - The data space governance framework specifies the procedures for enforcing the governance framework and conflict resolution. - The operations may also include business and technology aspects.
Data Space Infrastructure (deprecated Term) Source (vsn) : 1 Key Concept Definitions (bv30)	A technical, legal, procedural and organisational set of components and services that together enable data transactions to be performed in the context of one or more data spaces. Explanatory Text : This term was used in the data space definition in previous versions of the Blueprint. It is replaced by the governance framework and enabling services, and may be deprecated from this glossary in a future version.
Data Space Initiative Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	A collaborative project of a consortium or network of committed partners to initiate, develop and maintain a data space.
Data Space Intermediary Sources (vsn) : - Data, Services, and Offerings Descriptions (bv20) - Data, Services, and Offerings Descriptions (bv30)	A data space intermediary is a service provider who provides an enabling service or services in a data space. In common usage interchangeable with ‘operator'.
Data Space Interoperability Source (vsn) : 7 Interoperability (bv30)	The ability of participants to seamlessly exchange and use data within a data space or between two or more data spaces. Explanatory Texts : - Interoperability generally refers to the ability of different systems to work in conjunction with each other and for devices, applications or products to connect and communicate in a coordinated way without effort from the users of the systems. On a high-level, there are four layers of interoperability: legal, organisational, semantic and technical (see the European Interoperability Framework [EIF]). - Legal interoperability: Ensuring that organisations operating under different legal frameworks, policies and strategies are able to work together. - Organisational interoperability: The alignment of processes, communications flows and policies that allow different organisations to use the exchanged data meaningfully in their processes to reach commonly agreed and mutually beneficial goals. - Semantic interoperability: The ability of different systems to have a common understanding of the data being exchanged. - Technical interoperability: The ability of different systems to communicate and exchange data. - Also the ISO/IEC 19941:2017 standard [20] is relevant here. - Note: As per Art. 2 r.40 of the Data Act: ‘interoperability’ means the ability of two or more data spaces or communication networks, systems, connected products, applications, data processing services or components to exchange and use data in order to perform their functions. We describe this wider term as cross-data space interoperability.
Data Space Maturity Model Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	Set of indicators and a self-assessment tool allowing data space initiatives to understand their stage in the development cycle, their performance indicators and their technical, functional, operational, business and legal capabilities in absolute terms and in relation to peers.
Data Space Offering Source (vsn) : Data Space Offering (bv20)	The set of offerings provided through the data space that aim to bring value to participants.
Data Space Operational Processes Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	A set of essential processes a potential or actual data space participant goes through when engaging with a functioning data space that is in the operational stage or scaling stage. The operational processes include attracting and onboarding participants, publishing and matching use cases, data products and data requests and eventually data transactions.
Data Space Participant Sources (vsn) : - 1 Key Concept Definitions (bv30) - Data, Services, and Offerings Descriptions (bv20) - Data, Services, and Offerings Descriptions (bv30) - Participation Management (bv30)	A party committed to the governance framework of a particular data space and having a set of rights and obligations stemming from this framework. Explanatory Text : Depending on the scope of the said rights and obligations, participants may perform in (multiple) different roles, such as: data space members, data space users, data space service providers and others as described in this glossary.
Data Space Pilot Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	A planned and resourced implementation of one or more use cases within the context of a data space initiative. A data space pilot aims to validate the approach for a full data space deployment and showcase the benefits of participating in the data space.
Data Space Role Sources (vsn) : - 1 Key Concept Definitions (bv30) - Participation Management (bv30)	A distinct and logically consistent set of rights and duties (responsibilities) within a data space, that are required to perform specific tasks related to a data space functionality, and that are designed to be performed by one or more participants. Explanatory Texts : - The governance framework of a data space defines the data space roles. - Parties can perform (be assigned, or simply ‘be’) multiple roles, such as data provider, transaction participant, data space intermediary, etc.. In some cases, a prerequisite for performing a particular role is that the party can already perform one or more other roles. For example, the data provider must also be a data space participant.
Data Space Rulebook Source (vsn) : 1 Key Concept Definitions (bv30)	The documentation of the data space governance framework for operational use. Explanatory Text : The rulebook can be expressed in human-readable and machine-readable formats.
Data Space Service Offering Credential Source (vsn) : Identity & Attestation Management (bv30)	A service description that follows the schemas defined by the Data Space Governance Authority and whose claims are validated by the Data Space Compliance Service.
Data Space Services Sources (vsn) : - 1 Key Concept Definitions (bv30) - 4 Data Space Services (bv30)	Functionalities for implementing data space capabilities, offered to participants of data spaces. Explanatory Texts : - We distinguish three classes of technical services which are further defined in section 4 of this glossary: Participant Agent Services, Facilitating Services, Value-Creation Services. Technical (software) components are needed to implement these services. - Also on the business and organisational side, services may exist to support participants and orchestrators of data spaces, further defined in section 4 of this glossary and discussed in the Business and Organisational building blocks introduction. - Please note that a Data Service is a specific type of service related to the data space offering, providing access to one or more datasets or data processing functions.
Data Space Support Organisation Source (vsn) : 10 DSSC Specific Terms (bv30)	An organisation, consortium, or collaboration network that specifies architectures and frameworks to support data space initiatives. Examples include Gaia-X, IDSA, FIWARE, iSHARE, MyData, BDVA, and more.
Data Space Use Case Source (vsn) : 1 Key Concept Definitions (bv30)	A specific setting in which two or more participants use a data space to create value (business, societal or environmental) from data sharing. Explanatory Texts : - By definition, a data space use case is operational. When referring to a planned or envisioned setting that is not yet operational we can use the term use case scenario. - Use case scenario is a potential use case envisaged to solve societal, environmental or business challenges and create value. The same use case scenario, or variations of it, can be implemented as a use case multiple times in one or more data spaces.
Data Space Value Source (vsn) : 2 Data Space Use Cases and Business Model (bv30)	The cumulative value generated from all the data transactions and use cases within a data space as data space participants collaboratively use it. Explanatory Text : The definition of “data space value” is agnostic to value sharing and value capture. It just states where the value is created (in the use cases). The use case orchestrator should establish a value-sharing mechanism within the use case to make all participants happy. Furthermore, to avoid the free rider problem, the data space governance authority may also want to establish a value capture mechanism (for example, a data space usage fee) to get its part from the value created in the use cases.
Data Spaces Blueprint Sources (vsn) : - 9 Building Blocks and Implementations (bv20) - 9 Building Blocks and Implementations (bv30)	A consistent, coherent and comprehensive set of guidelines to support the implementation, deployment and maintenance of data spaces. Explanatory Text : The blueprint contains the conceptual model of data space, data space building blocks, and recommended selection of standards, specifications and reference implementations identified in the data spaces technology landscape.
Data Spaces Information Model Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	A classification scheme used to describe, analyse and organise a data space initiative according to a defined set of questions.
Data Spaces Radar Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	A publicly accessible tool to provide an overview of the data space initiatives, their sectors, locations and approximate development stages.
Data Spaces Starter Kit Source (vsn) : 10 DSSC Specific Terms (bv30)	A document that helps organisations and individuals in the network of stakeholders to understand the requirements for creating a data space.
Data Spaces Support Centre Source (vsn) : 10 DSSC Specific Terms (bv30)	The virtual organisation and EU-funded project which supports the deployment of common European data spaces and promotes the reuse of data across sectors.
Data Spaces Technology Landscape Source (vsn) : 10 DSSC Specific Terms (bv30)	A repository of standards (de facto and de jure), specifications and open-source reference implementations available for deploying data spaces. The Data Space Support Centre curates the repository and publishes it with the blueprint.
Data Storage Source (vsn) : Access & Usage Policies Enforcement (bv20)	Process of saving digital data in a physical or virtual location for future retrieval and use.
Data Subject Source (vsn) : Regulatory Compliance (bv20)	an identified or identifiable natural person that personal data relates to.( GDPR Article 4(1) ) Explanatory Text : Data subject is implicitly defined in the definition of ‘personal data’. In the context of data spaces we use the broader term data rights holder, to refer to the party that has (legal) rights and/or obligations to use, grant access to or share certain personal or non-personal data. For personal data, this would equal the data subject.
Data Transaction Sources (vsn) : - 1 Key Concept Definitions (bv30) - Participation Management (bv30)	A structured interaction between data space participants for the purpose of providing and obtaining/using a data product. An end-to-end data transaction consists of various phases, such as contract negotiation, execution, usage, etc. Explanatory Texts : - In future work we may align further with the definition from CEN Workshop Agreement Trusted Data Transactions: result of an agreement between a data provider and a data user with the purpose of exchanging, accessing and using data, in return for monetary or non-monetary compensation. - A data transaction implies data transfer among involved participants and its usage on a lawful and contractual basis. It relates to the technical, financial, legal and organisational arrangements necessary to make a data set from Participant A available to Participant B. The physical data transfer may or may not happen during the data transaction. - Prerequisites: - the specification of data products and the creation and publication of data product offerings so parties can search for offerings, compare them and engage in data transactions to obtain the offered data product. - Key elements related to data transactions are: - negotiation (at the business level) of a contract between the provider and user of a data product, which includes, e.g., pricing, the use of appropriate intermediary services, etc. - negotiation (at the operational level) of an agreement between the provider and the user of a data product, which includes, e.g., technical policies and configurations, such as sending - ensuring that parties that provide, receive, use, or otherwise act with the data have the rights/duties they need to comply with applicable policies and regulations (e.g. from the EU) - accessing and/or transferring the data (product) between provider, user, and transferring this data and/or meta-data to (contractually designated) other participants, such as observers, clearing house services, etc. - Data access and data usage by the data consumer. - All activities listed above do not need to be conducted in every transaction and that parts of the activities may be visited in loops or conditional flows.
Data Transaction Source (vsn) : Participation Management (bv20)	In the operational and scaling stage of a data space, the number of participants and use cases grows organically. The Data Space Governance Framework defines roles, responsibilities, and policies for data management, while the task of the Data Space Governance Authority is to enable seamless interaction among the participants. While use cases are executed and data products and data requests are published by the participants, the Data Space Governance Authority must carefully consider imbalances between supply and demand and consequently establish means to attract new participants to the data space to tackle the imbalances.As the data space grows, the Data Space Governance Authority needs to regularly screen the governance framework and eventually adapt it to address emerging needs and challenges. These adaptations may arise from various factors, such as regulatory changes that impose new requirements on participants, or the strategic goal of expanding the data space to include new industries, companies, or countries with distinct regulations and standards. To successfully accommodate such expansions, the governance framework must remain flexible and inclusive, enabling the integration of diverse stakeholders while maintaining robust compliance, security, and interoperability. Potential adaptations must remain in line with the data space’s central mission/vision.
Data Usage Policy Source (vsn) : 6 Data Policies and Contracts (bv30)	A specific data policy defined by the data rights holder for the usage of their data shared in a data space. Explanatory Text : Data usage policy regulates the permissible actions and behaviours related to the utilisation of the accessed data, which means keeping control of data even after the items have left the trust boundaries of the data provider.
Data User Source (vsn) : Regulatory Compliance (bv20)	a natural or legal person who has lawful access to certain personal or non-personal data and has the right, including under Regulation (EU) 2016/679 in the case of personal data, to use that data for commercial or noncommercial purposes;( DGA Article 2 (9))
Data User Source (vsn) : 5 Data Products and Transactions (bv30)	a natural or legal person who has lawful access to certain personal or non-personal data and has the right, including under Regulation (EU) 2016/679 in the case of personal data, to use that data for commercial or noncommercial purposes; ( DGA Article 2 (9)) Explanatory Texts : - In many cases the data user is the same party as the data consumer or data product consumer, but exceptions may exist where these roles are separate. - For reference, the definition from the CEN Workshop Agreement Trusted Data Transactions which considers the term to be synonymous with data consumer: person or organization authorized to exploit data (ISO 5127:2017) Note 1: Data are in the form of data products. Note 2: Data consumer is considered as a synonym of data user.
Dataset Description Sources (vsn) : - Data, Services, and Offerings Descriptions (bv20) - Data, Services, and Offerings Descriptions (bv30)	A description of a dataset includes various attributes, such as spatial, temporal, and spatial resolution. The description encompasses attributes related to distribution of datasets such as data format, packaging format, compression format, frequency of updates, download URL, and more. These attributes provide essential metadata that enables data recipients to understand the nature and usability of the datasets.
Dataspace Protocol Source (vsn) : Provenance, Traceability & Observability (bv30)	The Eclipse data space Protocol is a set of specifications that enable secure, interoperable data sharing between independent entities by defining standardized models, contracts, and processes for publishing, negotiating, and transferring data within data space s.The current specification can be found at: https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol
Declaration Source (vsn) : Identity & Attestation Management (bv30)	first-party attestation (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Deployment And Use Of Services Source (vsn) : Value creation services (bv20)	Deployment models suitable for the data space, depending on objectives, scalability and operational requirements (cloud-native architectures, hybrid cloud solutions, in-premises, serverless deployment)Define and adhere to Service Level Agreements that specify service availability, performance metrics, and support response times. Consider the SLA baseline of the specific service.Intuitive user interfaces (UI) and user experience design to make services easy to use and navigate
Development Cycle Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	The sequence of stages that a data space initiative passes through during its progress and growth. In each stage, the initiative has different needs and challenges, and when progressing through the stages, it evolves regarding knowledge, skills and capabilities.
Development Processes Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	A set of essential processes the stakeholders of a data space initiative conduct to establish and continuously develop a data space throughout its development cycle. Note : This term was automatically generated as a synonym for: data-space-development-processes
Digital Europe Programme Sources (vsn) : - 11 Foundation of the European Data Economy Concepts (bv20) - 11 Foundation of the European Data Economy Concepts (bv30)	An EU funding programme that funds several data space related projects, among other topics. The programme is focused on bringing digital technology to businesses, citizens and public administrations.
DMA Gatekeeper Source (vsn) : Regulatory Compliance (bv20)	an undertaking providing core platform services, designated by the European Commission if: it has a significant impact on the internal market;it provides a core platform service which is an important gateway for business users to reach end users; andit enjoys an entrenched and durable position, in its operations, or it is foreseeable that it will enjoy such a position in the near future (art. 3 (1) DMA). An undertaking shall be presumed to satisfy the respective requirements in paragraph 1: as regards paragraph 1, point (a), where it achieves an annual Union turnover equal to or above EUR 7,5 billion in each of the last three financial years, or where its average market capitalisation or its equivalent fair market value amounted to at least EUR 75 billion in the last financial year, and it provides the same core platform service in at least three Member States;as regards paragraph 1, point (b), where it provides a core platform service that in the last financial year has at least 45 million monthly active end users established or located in the Union and at least 10 000 yearly active business users established in the Union, identified and calculated in accordance with the methodology and indicators set out in the Annex;as regards paragraph 1, point (c), where the thresholds in point (b) of this paragraph were met in each of the last three financial years. (art. 3 (2) DMA).
DSSC Asset Source (vsn) : 10 DSSC Specific Terms (bv30)	A sustainable open resource that is developed and governed by the Data Spaces Support Centre. The assets can be used to develop, deploy and operationalise data spaces and to enable knowledge sharing around data spaces. The DSSC also develops and executes strategies to provide continuity for the main assets beyond the project funding.
DSSC Glossary Source (vsn) : 10 DSSC Specific Terms (bv30)	A limited set of data spaces related terms and corresponding descriptions. Each term refers to a concept, and the term description contains a criterion that enables people to determine whether or not something is an instance (example) of that concept.
DSSC Toolbox Source (vsn) : 10 DSSC Specific Terms (bv30)	A catalogue of data space component implementations curated by the Data Space Support Centre.
Dynamic Capabilities (7) Source (vsn) : Examples (bv20)	The governance authority is in constant discussion with the service providers and gives feedback on whether it is necessary to alter or change the business model.The board looks for ways in which to break even. There is no structural process in place to evaluate and monitor the business model.No structural process for innovating the business model is in placeThere is a board and a supervisory board, and there are three documents which define the governance of the data space:Statutes or Articles of Association of SCSNAccession AgreementCode of Conduct
EIDAS 2 Regulation Source (vsn) : Identity & Attestation Management (bv30)	It is an updated version of the original eIDAS regulation, which aims to further enhance trust and security in cross-border digital transactions with the EU.
EIDAS Regulation Source (vsn) : Identity & Attestation Management (bv30)	The EU Regulation on electronic identification and trust services for electronic transactions in the internal market
Enabling Services Source (vsn) : 4 Data Space Services (bv30)	Refer mutually to facilitating services and participant agent services, hence the technical services that are needed to enable trusted data transaction in data spaces.
European Data Innovation Board Source (vsn) : 11 Foundation of the European Data Economy Concepts (bv20)	The expert group established by the Data Governance Act (DGA) to assist the European Commission in the sharing of best practices, in particular on data intermediation, data altruism and the use of public data that cannot be made available as open data, as well as on the prioritisation of cross-sectoral interoperability standards, which includes proposing guidelines for common European data spaces (DGA Article 30 ). The European Data Innovation Board (EDIB) will have additional competencies under the Data Act.
European Data Innovation Board Source (vsn) : 11 Foundation of the European Data Economy Concepts (bv30)	The expert group established by the Data Governance Act (DGA) to assist the European Commission in the sharing of best practices, in particular on data intermediation, data altruism and the use of public data that cannot be made available as open data, as well as on the prioritisation of cross-sectoral interoperability standards, which includes proposing guidelines for Common European Data Spaces (DGA Article 30 ). The European Data Innovation Board received additional additional assignments under the Data Act (DA Article 42 ).
European Digital Identification (EUDI) Wallet Source (vsn) : Identity & Attestation Management (bv30)	The European Digital Identity Regulation introduces the concepts of EU Digital Identity Wallets. They are personal digital wallets that allow citizens to digitally identify themselves, store and manage identity data and official documents in electronic format. These documents may include a driving licence, medical prescriptions or education qualifications.
European Single Market For Data Sources (vsn) : - 11 Foundation of the European Data Economy Concepts (bv20) - 11 Foundation of the European Data Economy Concepts (bv30)	A genuine single market for data – open to data from across the world – where personal and non-personal data, including sensitive business data, are secure and businesses also have easy access to high-quality industrial data, boosting growth and creating value. Explanatory Text : Source: European strategy for data
European Strategy For Data Sources (vsn) : - 11 Foundation of the European Data Economy Concepts (bv20) - 11 Foundation of the European Data Economy Concepts (bv30)	A vision and measures ( a strategy ) that contribute to a comprehensive approach to the European data economy, aiming to increase the use of, and demand for, data and data-enabled products and services throughout the Single Market. It presents the vision to create a European single market for data.
Evidence Source (vsn) : Trust Framework (bv30)	Evidence can be included by an issuer to provide the verifier with additional supporting information in a verifiable credential (ref. Verifiable Credentials Data Model v2.0 (w3.org) )
Exploratory Stage Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	The stage in the development cycle in which a data space initiative starts. Typically, in this stage, a group of people or organisations starts to explore the potential and viability of a data space. The exploratory activities may include, among others, identifying and attracting interested stakeholders, collecting requirements, discussing use cases or reviewing existing conventions or standards.
Facilitating Services Source (vsn) : 4 Data Space Services (bv30)	Services which facilitate the interplay of participants in a data space, enabling them to engage in (commercial) data-sharing relationships of all sorts and shapes. Explanatory Text : They are sometimes also called ‘federation services’.
FAIR Principles Source (vsn) : Regulatory Compliance (bv20)	a collection of guidelines by which to improve the Findability, Accessibility, Interoperability, and Reusability of data objects. These principles emphasize discovery and reuse of data objects with minimal or no human intervention (i.e. automated and machine-actionable), but are targeted at human entities as well ( Common Fund Data Ecosystem Documentation) . Explanatory Text : In 2016, the ‘FAIR Guiding Principles for scientific data management and stewardship’ were published in Scientific Data. The authors intended to provide guidelines to improve the Findability, Accessibility, Interoperability, and Reuse of digital assets. The principles emphasise machine-actionability (i.e., the capacity of computational systems to find, access, interoperate, and reuse data with none or minimal human intervention) because humans increasingly rely on computational support to deal with data as a result of the increase in volume, complexity, and creation speed of data (GO FAIR Initiative)
Federated Data Spaces Sources (vsn) : - Data Exchange (bv20) - Data Exchange_ (bv30)	A data space that enables seamless data transactions between the participants of multiple data spaces based on agreed common rules, typically set in a governance framework. Explanatory Texts : - The definition of a federation of data spaces is evolving in the data space community. - A federation of data spaces is a data space with its own governance framework, enabled by a set of shared services (federation and value creation) of the federated systems, and participant agent services that enable participants to join multiple data spaces with a single onboarding step.
Federation Services Source (vsn) : 4 Data Space Services (bv20)	Services which facilitate the interplay of participants in a data space, enabling them to engage in (commercial) data-sharing relationships of all sorts and shapes. They perform an intermediary role in the data space.
Finite Data Sources (vsn) : - Data Exchange (bv20) - Data Exchange_ (bv30)	Data that is defined by a finite set, such as a fixed dataset.
First-party Conformity Assessment Activity Source (vsn) : Identity & Attestation Management (bv30)	conformity assessment activity that is performed by the person or organization that provides or that is the object of conformity assessment (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Functionality Source (vsn) : 1 Key Concept Definitions (bv30)	A specified set of tasks that are critical for operating a data space and that can be associated with one or more data space roles. Explanatory Text : The data space governance framework specifies the data space functionalities and associated roles. Each functionality and associated role consist of rights and duties for performing tasks related to that functionality. Note : This term was automatically generated as a synonym for: data-space-functionality
Gatekeepers Source (vsn) : Types of Participants (Participant as a Trigger) (bv20)	The Digital Markets Act defines gatekeepers as undertakings providing so-called “core platform services”, such as online search engines, social networking services, video-sharing platform services, number-independent interpersonal communications services, operating systems, web browsers, etc. According to Art. 3 (1) DMA, for an undertaking to be designated by the European Commission as a “gatekeeper”, it has to have a significant impact on the internal market; provide a core platform service which is an important gateway for business users to reach end users; and it enjoys an entrenched and durable position in its operations, or it is foreseeable that it will enjoy such a position in the near future. It also has to meet the requirements regarding an annual turnover above the threshold determined by the regulation. So far, the European Commission has designated the following gatekeepers: Alphabet, Amazon, Apple, Booking, ByteDance, Meta, and Microsoft. This position is determined in relation to a specific core platform service (for instance, Booking has been designated a gatekeeper for its online intermediation service “ http://Booking.com ” ). While the DMA does not aim to establish a framework for data sharing, it challenges the “data monopoly” of gatekeepers. Specific data-related obligations addressed to gatekeepers that may be relevant in the context of a data space include:Ban on data combination - For example, combining personal data from one core platform service with personal data from any further core platform services, or from any other services provided by the gatekeeper or with personal data from third-party services (art. 5(2) (b) DMA);Data silos - Prohibition to use, in competition with business users, not publicly available data generated or provided by those business users in the context of their use of the relevant core platform services (art. 6(2) DMA);Data portability - Obligation to provide end users and third parties authorised by an end user with effective portability of data provided by the end user or generated through the activity of the end user in the context of the use of the relevant core platform service (Article 6(9) DMA);Access to data generated by users - Obligation to provide business users and third parties authorised by a business user access and use of aggregated/non-aggregated data, including personal data, that is provided for or generated in the context of the use of the relevant core platform services (Article 6(10) DMA);Access search data for online search engines - Providing online search engines fair, reasonable and non-discriminatory terms to ranking, query, click and view data in relation to free and paid search generated by end users on its online search engines (Article 6(11) DMA). More information about the data-sharing obligations of the gatekeepers can be found here: data_sharing_obligations_under_the_dma_-_challenges_and_opportunities_-_may24.pdf (informationpolicycentre.com)
General Terms & Conditions Source (vsn) : Contractual Framework (bv20)	The general terms and conditions are an Agreement that contributes to providing legal enforceability to some elements of the governance framework (e.g., making compliance with a specific process mandatory) and makes it binding on all data space participants. In some cases, it can be part of the founding agreement or at least directly referenced by it.The general terms and conditions allow data spaces to regulate interactions at the data space level. They create and define the roles and responsibilities of the data space participants: the data space governance authority, data provider, data recipient, and service providers (data-related services, trust framework provider, management of identities, etc.). When a data space is established as a legal entity, the agreement may cover both the liability between the data space participants and the liability between the participant and the legal entity. The general terms and conditions can serve as the framework for data transactions, namely the interactions (rights, responsibilities, liabilities, and obligations) of the data transaction participants. They do so by introducing common elements (e.g., a limited set of standard clauses or typologies of licences—see further in the data transaction agreements section) to improve legal interoperability and reduce transaction costs, ultimately reducing complexity and the possibility of conflict. The areas that the general terms and conditions regulate at the data space level are (for example):Admission policy for data space participants. This describes whether new participants are accepted, the conditions and eligibility criteria that parties must meet to join a data space, the conditions to remain a data space participant, and the procedures for the removal of an existing participant. Data space participants join a data space by accepting the terms and conditions.Intellectual property policy. At a minimum, this would specify that none of these agreements should be construed as an assignment of IP rights; instead, non-exclusive licenses are granted. If new IP rights may emerge from collaboration (e.g., sui generis rights for databases), then clauses to regulate ownership of IP rights could be included.Data protection policy. This describes the data protection policy at a data space level, referring to the obligations of the data space as a controller when processing the data of the data space participants. Additionally, this policy may also include references to the potential role of data spaces as processors of personal data to be shared within the data space, identifying the corresponding responsibilities of the parties and the data space as prescribed by law. The data space may provide a technical framework that ensures the processing operations in the data space comply with GDPR by design and adherence to this framework can be made binding. Templates for Data Processing Agreements (e.g., iSHARE ) or Data Exchange Agreements (e.g., iSHARE ) can also be provided.Technical standards. These outline and/or enforce specific technical standards for participants in the data space. The general terms and conditions may also restrict the data models and formats to be used in the data space. Cybersecurity and risk management policies. These describe the rules and procedures for the protection of technology and information assets that need to be protected, along with other identified risks to the data space infrastructure or participants.Complaints policy and dispute resolution rules. These describe the rules and procedures for filing a complaint. Rules can also be included for resolving disputes between data space participants, including with the data space governing authority.The areas that the general terms and conditions regulate at the transaction level include (for example):Common elements in the terms and conditions of a data contract—Data spaces can coordinate and harmonise the terms and conditions of Data-Sharing Agreements and Service Agreements by introducing common elements (e.g., a limited set of data licenses or including only open data licenses) or prohibiting certain clauses (e.g., the inability to charge for the use of data). Examples of the agreement-specific clauses in the general terms and conditions are listed below. For conceptual clarity, we distinguish between the general terms that relate to the data space level and the data transaction level. Agreement-specific clauses related to the data space levelDefinitions (defining the roles of data space participants as well as potential third parties)Role-specific conditions (rights and obligations corresponding to the role),ResponsibilitiesFees and costsConfidentialityIP rightsData protectionAccession policy (whether new data participants can join a data space, what eligibility criteria they need to meet, whether there is a maximum number of participants, etc.)Technical standards and commitments (technical standards with which a party has to comply to make transactions and activities in the data spaces)Cybersecurity and risk management policiesComplaints policy and dispute resolution rules Agreement-specific clauses related to the transaction levelGeneral conditions for data sharingStandardised licences model for data usage rights – the general terms and conditions may limit the choice of licence or offer data providers a limited set of standardised licences. Standardisation refers to limiting the number or content of clauses. The advantage of including standardised licences is the reduction of transaction costs and increased scalability of the data space. Examples of types of licences may include:No limitations (the data product can be used without restrictions)Resharing with data space participants/internal use onlyNon-commercial use onlyData enrichment before resharingData can be enriched with the data recipient’s own dataData can be enriched with data from othersData can be enriched with the data recipient’s own data before resharing on a non-commercial basisData can be enriched with data of others before resharing on a non-commercial basisAd hoc-licenses (as determined by the parties)Standardised terms and conditions for data products - the agreement establishes mandatory terms and conditions to be included in the data product contract. It ensures that transactions between data provider and user take place on the basis of common terms and conditions, reducing transaction costs and increasing legal interoperability between transactions. Any terms and conditions can be the object of standardisation, from clauses on fees to clauses related to the rights of third parties on data.Mechanisms to calculate fees (if applicable)
General Terms And Conditions Source (vsn) : Contractual Framework (bv30)	An agreement defining the roles, relationships, rights and obligations of data space participants.
Geoquerying Sources (vsn) : - Data Exchange (bv20) - Data Exchange_ (bv30)	Query involving geographical boundaries Explanatory Text : Data querying frequently needs to be restricted to a geographical area.
Governance Source (vsn) : Business Model (bv30)	A description of how a group of organizations (necessary for a data space) is managed, organised, and regulated by agreements and processes, as well as how the partners control and influence its evolution and performance over time.Due to the collaborative nature of a data space business model, governance of affiliated and non-affiliated actors can be seen as strongly complementary to the business model and other building blocks.
Governance Authority Source (vsn) : 1 Key Concept Definitions (bv30)	The body of a particular data space, consisting of participants that is committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework. Explanatory Texts : - A ‘body’ is a group of parties that govern, manage, or act on behalf of a specific purpose, entity, or area of law. This term, which has legal origins, can encompass entities like legislative bodies, governing bodies, or corporate bodies. - The data space governance authority does not replace the role of public regulation and enforcement authorities. - Establishing the initial data space governance framework is outside the governance authority's scope and needs to be defined by a group of data space initiating parties. - After establishment, the governance authority performs the governing function (developing and maintaining the governance framework) and the executive function (operating and enforcing the governance framework). - Depending on the legal form and the size of the data space, the governance and executive functions of a data space governance authority may or may not be performed by the same party. Note : This term was automatically generated as a synonym for: data-space-governance-authority
Governance Authority Source (vsn) : Provenance, Traceability & Observability (bv30)	A governance authority refers to bodies of a data space that are composed of and by data space participants responsible for developing and maintaining as well as operating and enforcing the internal rules. Note : This term was automatically generated as a synonym for: data-space-governance-authority
Governance Authority Sources (vsn) : - Identity & Attestation Management (bv30) - Trust Framework (bv30)	The body of a particular data space, consisting of participants that are committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework. Note : This term was automatically generated as a synonym for: data-space-governance-authority
Governance Authority (dsga) Source (vsn) : Participation Management (bv30)	The body of a particular data space, consisting of participants that is committed to the governance framework for the data space, and is responsible for developing, maintaining, operating and enforcing the governance framework. Note : This term was automatically generated as a synonym for: data-space-governance-authority-dsga
Governance Authority Bodies And Members (4) Source (vsn) : Examples (bv20)	According to the foundational documents, the highest level of governance consists of one representative from the service providers, one from the manufacturing industry, one knowledge institute and one industry association.There should be at least one director. Previously, in-kind services were provided by a knowledge institute but are now outsourced.The owner of the data space is the sector association. Therefore, they exist to ensure the progression of the sector.
Governance Framework Source (vsn) : 1 Key Concept Definitions (bv30)	The structured set of principles, processes, standards, protocols, rules and practices that guide and regulate the governance, management and operations within a data space to ensure effective and responsible leadership, control, and oversight. It defines the functionalities the data space provides and the associated data space roles, including the data space governance authority and participants. Explanatory Texts : - Functionalities include, e.g., the maintenance of the governance framework the functioning of the data space governance authority and the engagement of the participants. - The responsibilities covered in the governance framework include assigning the governance authority and formalising the decision-making powers of participants. - The data space governance framework specifies the procedures for enforcing the governance framework and conflict resolution. - The operations may also include business and technology aspects. Note : This term was automatically generated as a synonym for: data-space-governance-framework
Guidelines For Common European Data Spaces Sources (vsn) : - 11 Foundation of the European Data Economy Concepts (bv20) - 11 Foundation of the European Data Economy Concepts (bv30)	The Data Governance Act (DGA Article 30(h )) defines that the European Data Innovation Board will propose guidelines for common European data spaces. The guidelines shall address, among other things: (i) cross-sectoral standards for data sharing, (ii) counter barriers to market entry and avoiding lock-in effects and ensuring fair competition and interoperability, (iii) protection for lawful data transfers to third countries, (iv) non-discriminatory representation of relevant stakeholders in the governance of common European data spaces and (v) adherence to cybersecurity requirements.
HealthData@EU Source (vsn) : Regulatory Compliance (bv20)	cross-border infrastructure for secondary use of electronic health data established by the European Health Data Space Regulation (art. 52 (2) EHDS).
High-risk AI System Source (vsn) : Regulatory Compliance (bv20)	'AI system’ means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments (Art. 3 (1) AIA). AI system shall be considered to be high-risk where both of the following conditions are fulfilled: the AI system is intended to be used as a safety component of a product, or the AI system is itself a product, covered by the Union harmonisation legislation listed in Annex I; the product whose safety component pursuant to point (a) is the AI system, or the AI system itself as a product, is required to undergo a third-party conformity assessment, with a view to the placing on the market or the putting into service of that product pursuant to the Union harmonisation legislation listed in Annex I (art. 6 (1); art. 6 (2) AIA). Explanatory Texts : - In addition to the high-risk AI systems referred above, AI systems referred to in Annex III shall be considered to be high-risk, such as: - biometrics, in so far as their use is permitted under relevant Union or national law; - critical infrastructures (e.g. transport), that could put the life and health of citizens at risk; - educational or vocational training, that may determine the access to education and professional course of someone’s life (e.g. scoring of exams); - safety components of products (e.g. AI application in robot-assisted surgery); - employment, management of workers and access to self-employment (e.g. CV-sorting software for recruitment procedures); - essential private and public services (e.g. credit scoring denying citizens opportunity to obtain a loan); - law enforcement that may interfere with people’s fundamental rights (e.g. evaluation of the reliability of evidence); - migration, asylum and border control management (e.g. automated examination of visa applications); - administration of justice and democratic processes (e.g. AI solutions to search for court rulings).
High-Value Datasets (HVDs) Source (vsn) : Types of data (Data as a Trigger) (bv20)	High-Value Datasets (HVDs) are defined in the Open Data Directive as “documents held by a public sector body, the reuse of which is associated with important benefits for society, the environment and the economy”.HVDs can be re-usable for any purpose (as is the case for open data).Public sector bodies are not allowed to charge fees for the reuse of HVDs.In the context of data transactions within a data space, it is important to remember that the reuse of documents should not be subject to conditions, but some cases are justified by a public interest objective. In these situations, public sector bodies might issue a license imposing conditions on the reuse by the licensee dealing with issues such as liability, the protection of personal data, the proper use of documents, guaranteeing non-alteration and the acknowledgement of source. In addition to the above, there are categories of data for which we do not know the legal status of the data. Therefore, they are de facto under the control of the data holder.
High-Value Datasets (HVDs) Source (vsn) : Regulatory Compliance (bv20)	data held by a public sector body associated with important benefits for society, the environment, and the economy when reused (Open Data Directive). The thematic categories of high-value datasets are: geospatial data; earth observation and environment data; meteorological data; statistics; companies and company ownership data; mobility data (Annex I, Open Data Directive). Explanatory Text : These datasets are suitable for creating value-added services, applications, and new jobs, and are made available free of charge in machine-readable format documents, the reuse of high-value datasets is associated with important benefits for the society and economy. They are subject to a separate set of rules ensuring their availability free of charge, in machine readable formats. They are provided via Application Programming Interfaces (APIs) and, where relevant, as a bulk download. The thematic scope of high-value datasets is provided in an Annex to the Directive.
Holder Source (vsn) : Identity & Attestation Management (bv30)	A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. A holder is often, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories . (ref. Verifiable Credentials Data Model v2.0 (w3.org) )
Horizon Europe Programme Sources (vsn) : - 11 Foundation of the European Data Economy Concepts (bv20) - 11 Foundation of the European Data Economy Concepts (bv30)	An EU funding programme that funds data space related research and innovation projects, among other topics.
Identifying And Monitoring Use Case Scenarios Source (vsn) : Use Case Development (bv20)	Collecting ideas for use case scenarios through activities such as observing potential customers’ needs and analysing other data spaces and platforms.
Identifying And Tracking Use Case Scenarios Source (vsn) : Use Case Development (bv30)	Collecting ideas for use case scenarios through activities such as observing potential users’ needs and analysing other data spaces and platforms.
Identity Source (vsn) : Identity & Attestation Management (bv30)	an Identity is composed of a unique Identifier , associated with an attribute or set of attributes that uniquely describe an entity within a given context and policies determining the roles, permissions, prohibitions, and duties of the entity in the data space
Implementation Of A Component Sources (vsn) : - 9 Building Blocks and Implementations (bv20) - 9 Building Blocks and Implementations (bv30)	The result of translating/converting a data space component into a functional and usable artefact, such as executable code or other tool. Note : This term was automatically generated as a synonym for: implementation-of-a-data-space-component
Implementation Of A Data Space Component Sources (vsn) : - 9 Building Blocks and Implementations (bv20) - 9 Building Blocks and Implementations (bv30)	The result of translating/converting a data space component into a functional and usable artefact, such as executable code or other tool.
Implementation Stage Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	The stage in the development cycle that starts when a data space initiative has a sufficiently detailed project plan, milestones and resources (funding and other) for developing its governance framework and infrastructure in the context of a data space pilot. It is typical for this stage that the parties involved in the pilot and the value created for each are also clearly identified.
Implementing Use Cases Sources (vsn) : - Use Case Development (bv20) - Use Case Development (bv30)	Implementing use cases both from organisational and business perspectives (e.g., agreements) and from technical perspectives (e.g., vocabularies, APIs, connectors).
Information Model Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	A classification scheme used to describe, analyse and organise a data space initiative according to a defined set of questions. Note : This term was automatically generated as a synonym for: data-spaces-information-model
Infrastructure (deprecated Term) Source (vsn) : 1 Key Concept Definitions (bv30)	A technical, legal, procedural and organisational set of components and services that together enable data transactions to be performed in the context of one or more data spaces. Explanatory Text : This term was used in the data space definition in previous versions of the Blueprint. It is replaced by the governance framework and enabling services, and may be deprecated from this glossary in a future version. Note : This term was automatically generated as a synonym for: data-space-infrastructure-deprecated-term
Initiative Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	A collaborative project of a consortium or network of committed partners to initiate, develop and maintain a data space. Note : This term was automatically generated as a synonym for: data-space-initiative
Intellectual Property Rights/ Trade Secret-Protected Data(sets) Source (vsn) : Types of data (Data as a Trigger) (bv20)	Intellectual property (IP) law can confer rights over datasets, often through copyright and the sui generis database right. Data may also be protected by trade secrets, which constitute a separate legal regime. It is the responsibility of each data space participant to ensure legal compliance and to have an authorisation and/or legal basis for data sharing if data is protected by copyright, sui generis or trade secrets. Copyright law:Protects creative works like text, images, video, and sound. It also protects software (e.g., source code) and databases (e.g., a collection of independent data protected). Copyright does not protect data itself - it differs from other works, which are protected due to specific qualifying conditions, such as being an author’s original creation.To be protected by copyright, a database has to be original, reflect the author's intellectual creation, and be fixed in tangible form. In the context of databases, a specific test of originality reflecting the special characteristic of databases is required (whether the selection or arrangement of their contents constitutes the author’s own intellectual creation).Purely factual information is usually not eligible for protection (Article 2, InfoSoc Directive ).Sui Generis Database Right ( EU Database Directive 96/9/EC ):Databases could be protected by the sui generis database right in addition to copyright protection.Grants sui generis database rights to creators who made qualitatively and/or quantitatively substantial investment in obtaining, verifying, or presenting contents.Provides right to prevent unauthorized extraction or re-utilisation.Defines databases as collections arranged systematically and individually accessible.Trade Secret Protection ( EU Trade Secrets Directive 2016/943 ):Encompasses various data types, requiring secrecy and commercial value.Enforceable rights against unlawful use and misappropriation without conferring property rightsSecrecy is preserved as long as persons having access to information are bound by confidentiality agreements.Solutions to be implemented on a data space levelThe acknowledgement of intellectual property and quasi-IP rights (trade secrets), both for identifying existing assets and creating new ones, should be addressed in the intellectual property policy within the general terms & conditions and the intellectual property clauses of particular data product contracts. More details can be found in the Contractual Framework building block.Data holders are responsible for providing information about the IP rights and/or trade secrets they possess over particular datasets before sharing them with potential data recipients.Specific legal provisions concerning trade secrets’ aspects in the context of data sharing can be found in the Data Act (primarily in the context of business-to-consumer and business-to-business data sharing).Examples of possible legal, organisational and technical measures to preserve intellectual property rights or trade secrets can be found in the recently adopted European Health Data Space Regulation. Such measures could include data access contractual arrangements, specific obligations in relation to the rights granted to the data recipient, or pre-processing the data to generate derived data that protects a trade secret but still has utility for the user or configuration of the secure processing environment so that such data is not accessible by the data recipient (recital 60, art. 53 EHDS-R ) .
Intermediary Source (vsn) : 4 Data Space Services (bv30)	Service provider who provides an enabling service or services in a data space. In common usage interchangeable with ‘operator'.
Intermediary Sources (vsn) : - Data, Services, and Offerings Descriptions (bv20) - Data, Services, and Offerings Descriptions (bv30)	A data space intermediary is a service provider who provides an enabling service or services in a data space. In common usage interchangeable with ‘operator'. Note : This term was automatically generated as a synonym for: data-space-intermediary
Interoperability Source (vsn) : 7 Interoperability (bv30)	The ability of participants to seamlessly exchange and use data within a data space or between two or more data spaces. Explanatory Texts : - Interoperability generally refers to the ability of different systems to work in conjunction with each other and for devices, applications or products to connect and communicate in a coordinated way without effort from the users of the systems. On a high-level, there are four layers of interoperability: legal, organisational, semantic and technical (see the European Interoperability Framework [EIF]). - Legal interoperability: Ensuring that organisations operating under different legal frameworks, policies and strategies are able to work together. - Organisational interoperability: The alignment of processes, communications flows and policies that allow different organisations to use the exchanged data meaningfully in their processes to reach commonly agreed and mutually beneficial goals. - Semantic interoperability: The ability of different systems to have a common understanding of the data being exchanged. - Technical interoperability: The ability of different systems to communicate and exchange data. - Also the ISO/IEC 19941:2017 standard [20] is relevant here. - Note: As per Art. 2 r.40 of the Data Act: ‘interoperability’ means the ability of two or more data spaces or communication networks, systems, connected products, applications, data processing services or components to exchange and use data in order to perform their functions. We describe this wider term as cross-data space interoperability. Note : This term was automatically generated as a synonym for: data-space-interoperability
Interoperability (DA) Source (vsn) : Regulatory Compliance (bv20)	means the ability of two or more data spaces or communication networks, systems, connected products, applications, data processing services or components to exchange and use data in order to perform their functions (art. 2 (40) DA).
Intra- Interoperability Source (vsn) : 7 Interoperability (bv30)	The ability of participants to seamlessly access and/or exchange data within a data space. Intra-data space interoperability addresses the governance, business and technical frameworks (including the data space protocol and the data models) for individual data space instances. Note : This term was automatically generated as a synonym for: intra-data-space-interoperability
Intra-data Space Interoperability Source (vsn) : 7 Interoperability (bv30)	The ability of participants to seamlessly access and/or exchange data within a data space. Intra-data space interoperability addresses the governance, business and technical frameworks (including the data space protocol and the data models) for individual data space instances.
IoT Data Source (vsn) : Types of data (Data as a Trigger) (bv20)	The Data Act lays down a harmonised framework specifying the rules for using product data or related service data, including data from Internet of Things devices, smartphones, and cars. It imposes the obligation on data holders to make data available to users and third parties of the user’s choice in certain circumstances. It also ensures that data holders make data available to data recipients in the Union under fair, reasonable and non-discriminatory terms and conditions and in a transparent manner. These provisions apply to the data of specific origin, irrespective of the personal/non-personal character of the data. If the processing of personal data is involved, it is important to remember that the GDPR still applies.Data spaces should pay attention to Chapter II of the Data Act, especially in the context of data transactions involving the processing of product data and related service data. More specifically, data spaces should consider the rights of the users of connected products or related services that they hold towards the data they produce by using these products or services. These rights include access to and use of the data for any lawful purpose. There are some exceptions to access rights (for example, if the data user requests access to personal data of which he is not a data subject). The data provided to the user should be of the same quality as the data available to the data holder and should be provided easily, securely, free of charge, and in a comprehensive, structured, commonly used and machine-readable format. If the data transaction is supposed to be concluded without the data user directly involved, it is important to remember that the scope of such transactions is predefined by the contract with the user. Data holders shall not make available non-personal product data to third parties for commercial or non-commercial purposes other than the fulfilment of such a contract.Data holders can also decide to make their data available via a third parties of their choice (for example, data intermediation service providers as defined by the DGA) for commercial purposes. These third parties hold then certain obligations towards the data they receive on behalf of the user. For example, they should be able to transfer the data access rights granted by the user to other third parties, including in exchange for compensation. Data intermediation services may support users or third parties in establishing commercial relations with an undetermined number of potential counterparties for any lawful purpose falling within the scope of the Data Act, providing that users remain in complete control of whether to provide their data to such aggregation and the commercial terms under which their data are to be used.
Issuer Sources (vsn) : - Identity & Attestation Management (bv30) - Trust Framework (bv30)	A role an entity can perform by asserting claims about one or more subjects , creating a verifiable credential from these claims , and transmitting the verifiable credential to a holder . (ref. Verifiable Credentials Data Model v2.0 (w3.org) )
LOTL (List Of Trusted Lists) Source (vsn) : Trust Framework (bv30)	List of qualified trust service providers in accordance with the eIDAS Regulation published by the Member States of the European Union and the European Economic Area (EU/EEA)
Machine-Readable Policy Source (vsn) : Access & Usage Policies Enforcement (bv30)	A policy expressed in a standard format (ODRL) that computers can automatically process, evaluate, and enforce.
Maintenance Source (vsn) : Value creation services (bv20)	Regular maintenance schedule for updatesVersion control for all service componentsBack-up and recovery
Maturity Model Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	Set of indicators and a self-assessment tool allowing data space initiatives to understand their stage in the development cycle, their performance indicators and their technical, functional, operational, business and legal capabilities in absolute terms and in relation to peers. Note : This term was automatically generated as a synonym for: data-space-maturity-model
Membership Credential Source (vsn) : Identity & Attestation Management (bv30)	credential issued by the Data Space Governance Authority after having assessed compliance of an entity to its rules. This credential attest participation in a data space.
Meta-standard Sources (vsn) : - Data Models (bv20) - Data Models (bv30)	A standard designed to define or annotate data models within a particular domain or across multiple domains. These meta-standards provide a framework or guidelines for creating and annotating other standards (data models), ensuring consistency, interoperability, and compatibility.
Multi-Sided Business Model Source (vsn) : Business Model (bv30)	A business model is said to be multi-sided if an organization serves different segments, and those segments also interact. An example is Airbnb, where apartments are offered to travellers. This is also referred to as a ‘platform business model’.A data space differs in two important ways from a platform business model: In order to establish sovereignty and avoid undesired ‘winner-takes-all’ effects, control of the sharing of data essentially lies with the data owner and the infrastructure is distributed.
Network Effects (8) Source (vsn) : Examples (bv20)	End-users get more out of their subscription to SCSN once more customers and/or suppliers join the network, as they can automate a larger part of their purchase-to-pay process through SCSN. Service providers enhance the appeal of their services with a larger network to connect to, increasing savings for their clients. The expansion strategy is mainly aimed at the service providers adding end-users through their client base and connecting them to SCSN.
Network Of Stakeholders Source (vsn) : 10 DSSC Specific Terms (bv30)	The group of parties relevant to the development of data spaces and with whom the Data Spaces Support Centre proactively engages in achieving its purpose and objectives. The community of practice is the core subset of this network of stakeholders and the primary focus group for the DSSC.
Non-Finite Data Sources (vsn) : - Data Exchange (bv20) - Data Exchange_ (bv30)	Data that is defined by an infinite set or has no specified end, such as continuous streams.
Non-personal Data Source (vsn) : Types of data (Data as a Trigger) (bv20)	WARNING: This term was created, but not actually defined by the source.
Non-personal Data Source (vsn) : Regulatory Compliance (bv20)	data other than personal data;( DGA Article 2(4) )
Non-Provenance Traceability Source (vsn) : Provenance & Traceability (bv20)	All other traceability data useful for other then provenance data.
Notary Source (vsn) : Trust Framework (bv30)	Notaries are entities accredited by the Data Space, which perform validation based on objective evidence from a data space Trusted Data source, digitalising an assessment previously made.
Object Of Conformity Assessment Source (vsn) : Identity & Attestation Management (bv30)	entity to which specified requirements apply (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Observability Source (vsn) : Provenance, Traceability & Observability (bv30)	The ability to monitor, measure and understand the internal states of processes through its outputs such as logs, metrics and traces.
Observability Services Source (vsn) : Provenance & Traceability (bv20)	A service that stores the audit data of data sharing transactions within the data space and provide services related to observability.
Offboarding Source (vsn) : Participation Management (bv20)	Reasons for Offboarding Different reasons for offboarding exist. In the regular case that a participant simply wants to exit the data space, the structured way of offboarding, described below applies. A different reason might be the forced exit, caused e.g. by the participant not complying with the data spaces rules. In such a case, the Data Space Governance Authority needs to formulate rules and processes of how to enforce an exit. Another scenario is the exception handling when a participating company e.g. goes bankrupt and cannot fulfill its obligations anymore. In such a case, the Data Space Governance Authority needs to inform all affected parties and enforce the exit.A general overview of the onboarding and offboarding process in a data space is depicted in Figure 1. Offboarding process Offboarding participants requires careful consideration of obligations and responsibilities toward the data space and other participants. The governance framework, especially its Terms and Conditions, guides the exit process, ensuring a smooth transition while safeguarding the interests of all involved parties. The offboarding process is designed to uphold the integrity and continuity of the data space by addressing issues such as data rights/holdings, data transfer, and termination of access. Exiting the data space requires proof that all contracts made with other participants have been fulfilled and no contractual obligations remain open. Accordning to the General Terms and Conditions, the participant informs the Data Space Governance Authority about the desired exit of the data space. However it is stated in the Terms and Conditions, this can be realized digitally or in a written form. After checking whether all offboarding criteria are met, the Data Spaces Governance Authority confirms the exit to the participant.Elements that ensure careful and efficient offboarding are:Documention of exit procedures: Establishing and following a documented offboarding procedure that helps to ensure consistency and completeness in the process. This documentation should include detailed steps for data transfer, access termination, and contract closure. This entails for instance a continous life cycle management of credentials, such as defined in the Identity and Attestation building block.Data Transfer and Deletion Protocols: Implementing clear protocols for the secure transfer or deletion of data is essential. This includes ensuring that data is either transferred to another party or securely deleted, in accordance with the corresponding licenses agreed upon, but also with the data space policies and any applicable legal requirements.Notification: Providing timely and clear notifications to all relevant parties about the participant’s exit helps prevent misunderstandings and ensures that all stakeholders are aware of possible changes. This communication should include details about data transfer, access termination, and any remaining obligations.Verification of compliance: Conducting a thorough review to verify that all contractual and compliance obligations have been met before finalizing the offboarding process. This includes ensuring that any financial or legal obligations are settled and that all agreements with other participants are fulfilled.Offboarding support: Offering support during the transition period to address any issues or questions that may arise. This can include providing assistance with data transfer or answering queries about remaining obligations.Periodic Framework Reviews: Conducting periodic and thorough reviews of the data space governance framework and incorporating necessary updates in response to legislative changes helps ensure the ongoing sustainability and effectiveness of the data space ecosystem during the off- and onboarding process.
Offering Sources (vsn) : - Data Space Offering (bv20) - Data, Services, and Offerings Descriptions (bv20) - Data, Services, and Offerings Descriptions (bv30)	Data product(s), service(s), or a combination of these, and the offering description. Explanatory Text : Offerings can be put to a catalogue.
Offering Source (vsn) : Publication and Discovery (bv30)	Data product(s), service(s), or a combination of these, and the offering description. Offerings can be put into a catalogue.
Offering Description Sources (vsn) : - Data Space Offering (bv20) - Data, Services, and Offerings Descriptions (bv20) - Data, Services, and Offerings Descriptions (bv30)	A text that specifies the terms, conditions and other specifications, according to which an offering will be provided and can be consumed. Explanatory Texts : - Offering descriptions contain all the information needed for a potential consumer to make a decision whether to consume the data product(s) and/or the service(s) or not. - This may include information such as description, provider, pricing, license, data format, access rights, etc. - The offering description can also detail the structure of the offering, how data products and services can be obtained, and applicable rights and duties. - Typically offering descriptions are machine-readable metadata.
Onboarding Source (vsn) : Participation Management (bv20)	Efficient onboarding of participants is critical for a seamless functioning data space. It ensures that participants can quickly integrate into the data space while adhering to necessary compliance and technical standards. This process minimizes the risk of operational inefficiencies and potential data misuse, thus fostering a trustworthy and collaborative environment essential for a thriving data space ecosystem. The Data Space Governance Authority sets the minimum requirements for data space participation. This process involves defining General Terms and Conditions of the data space. These terms and conditions outline the rules for joining, ensuring a clear understanding of roles, responsibilities, and compliance requirements. This includes rules for proving identity, as well as how attestations are issued (first-, second-, or third-party). The terms and conditions clearly need to cover all relevant rules and regulations such as admission policies, technical standards, data protection policies, but also offboarding regulations. The level of rules and requirements for joining and participating in a data space might vary depending on several factors. As further described in the Regulatory Compliance building block, for example, some domains might require more stringent rules than others. Also, the type of data handled within the data space calls for different rules. In case the data space handles for instance personal data, the rules and requirements for participating in the data space need to be in line with all relevant legal provisions, such as the GDPR.The General Terms & Conditions must hence clearly formulate the requirements for joining, which are specified in the conformity schema of the data space’s governance framework. Adhering to stringent rules can raise the bar for potential data providers to participate. The way rules are made in a data space affects how data transactions work. This is closely tied to the data space's purpose and mission. A data space can introduce additional internal rules and policies, as necessary for its functionality. While introducing such additional rules, it should avoid creating unnecessary hurdles for participation in the data space and contribute to smooth its functioning.Since reasons for joining a data space vary (business interest, legal requirements etc.), the Data Space Governance Authority must ensure that the data space is discoverable for interested parties (or candidates) and that General Terms and Conditions are accessible and understandable for them.Onboarding is linked to pre- and post-conditions which are essential to ensure smooth and secure operation. Pre-conditions Admission policies within the General Terms and Conditions describe the conditions and eligibility criteria that third parties need to meet in order to join a data space. This entails identity verification, compliance check, technical requirements, access control setup, data quality standards or security policies. Once the candidate agrees to the General Terms and Conditions and meets all admission criteria, a process for accepting the General Terms and Conditions needs to be implemented. This can be realized by e.g. mutually signing an agreement or by letting the participant accept the General Terms and Conditions digitally. The form of accepting the General Terms and Conditions depends on the role (transaction party, service provider etc.) a candidate wants to take in the data space.. The General Terms and Conditions should include requirements for verifying participants (e.g., strong identification) and setting requirements for the products and services available in the data space (e.g., language, data formats, etc.). The Data Space Governance Authority must balance lowering barriers to entry (flexible rules) and promoting interoperability and data quality (strict rules). Depending on the Governance Framework of the data space, the Data Space Governance Authority must provide mechanisms to check if all admission/eligibility criteria are fulfilled by the candidate. To join the data space, the candidate submits an application, detailling the role and intended use of the data space to the Data Space Governance Authority, which in turn reviews the applicant’s compliance with legal, technical, and operational standards, ensuring they meet all conditions. Alternatively, the Data Space Governance Authority can decide to refrain from an application process, but grant access to every participant that accepts the General Terms and Conditions and meets all conditions. Both options require constant monitoring that all participants act in accordance to the data spaces' rules and obligations. In both cases, the candidate needs to receive a notification once the Data Space Governance Authority decides on the application status.In cases where the Data Space Governance Authority decides on denying access, the applicant should be informed about reasons.As described in the Identity and Attestation building block, upon approval, access credentials are issued, enabling participants to interface with the data space. The Data Space Registry, managed by the Data Space Governance Authority, supports the onboarding process by listing data space rules, Trust Anchors, but also conformity schemes formulated to assess compliance. The latter should be described in the data space’s Rulebook. Post-conditions Successful integration is realized with verified access to the necessary data and resources with ensured technical interoperability. Technical onboarding by the Data Space Governance Authority is a process to enable new participants a seamless connection and instant readiness to actively engage in the data space. This can be for instance aided with initial data integration support by the Data Space Governance Authority to ensure data or services meet quality format and standards.Active monitoring extends beyond initial onboarding, with continuous oversight to ensure participants adhere to data space policies and standards. This ongoing monitoring helps identify areas where the onboarding process can be improved, ensuring that the data space evolves to meet participant needs and emerging challenges. Feedback from participants is crucial in this process, enabling the Data Space Governance Authority to make data-driven adjustments to onboarding procedures, enhancing both security and participant satisfaction.
Ontology Sources (vsn) : - Data Models (bv20) - Data Models (bv30)	A data model that defines knowledge within and across domains by modelling information objects and their relationships, often expressed in open metamodel standards like OWL, RDF, or UML.
Operational Processes Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	A set of essential processes a potential or actual data space participant goes through when engaging with a functioning data space that is in the operational stage or scaling stage. The operational processes include attracting and onboarding participants, publishing and matching use cases, data products and data requests and eventually data transactions. Note : This term was automatically generated as a synonym for: data-space-operational-processes
Operational Stage Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	The stage in the development cycle that starts when a data space initiative has a tested implementation of infrastructure(s) and governance framework, and the first use case becomes operational (data flowing between data providers and data recipients and use case providing the intended value).
Operator Source (vsn) : 4 Data Space Services (bv30)	Service provider that provides enabling services that are common to all participants of the data space. In common usage interchangeable with ‘intermediary’. Explanatory Text : We use typically the term ‘operator’ when a single actor is assigned by the governance authority to manage the enabling services and when it is responsible for the operation of the data space, ensuring functionality and reliability as specified in the governance framework.
Participant Sources (vsn) : - 1 Key Concept Definitions (bv30) - Data, Services, and Offerings Descriptions (bv20) - Data, Services, and Offerings Descriptions (bv30) - Participation Management (bv30)	A party committed to the governance framework of a particular data space and having a set of rights and obligations stemming from this framework. Explanatory Text : Depending on the scope of the said rights and obligations, participants may perform in (multiple) different roles, such as: data space members, data space users, data space service providers and others as described in this glossary. Note : This term was automatically generated as a synonym for: data-space-participant
Participant Agent Source (vsn) : 4 Data Space Services (bv30)	A technology system used to conduct activities in a data space on behalf of a party. Explanatory Text : The participant agent can offer technical modules that implement data interoperability functions, authentication interfacing with trust services and authorisation, data product self-description, contract negotiation, etc. A ‘connector’ is an implementation of a participant agent service.
Participant Agent Intermediary Source (vsn) : 4 Data Space Services (bv20)	A party who provides participant agent services for the data space participants as defined by the data space governance framework.
Participant Agent Services Source (vsn) : 4 Data Space Services (bv30)	Services to enable an individual participant to interact within the data space, facilitate the sharing (providing or using) of data, specify access and usage policies, and more. Explanatory Text : The participant agent services provide operations on the control plane that are executing the data services on the data plane. The control plane and data plane should work together to manage the data transfer process. After contract negotiation, the technical transfer process can take place.
Participants Source (vsn) : Participation Management (bv20)	Participants in a data space comprise different entities. Data Providers are organizations that supply data to the data space. They generate and share data sets that can be used by others. Data Users consume data from the data space for various purposes such as analysis, decision-making or product development and therefore directly engage in the process of data transaction. For both types of participants, participation management needs to ensure the management of permissions, support of data quality standards, but also mechanisms to monitor and report data utilization. Intermediaries and Operators facilitate the exchange of data between providers and users. They enable and intermediate data exchange as (value creation) service providers. Even though they do not engage in data transactions, they are crucial participants to the data space, which is why participation management should facilitate data intermediaries and operators to ensure adherance of interoperability standards. Data Rights Holders are individuals or organizations that hold the rights to the data. They decide the terms and conditions under which their data can be shared and used within the data space. Data Space Governance Authorities might formulate more specific roles per data space, documented in the data space’s rulebook. Example: For some data spaces, distinguishing between participants who form the Data Space Governance Authority and those who do not, might be needed. Role differentiation could help in clarifying responsiblities, maintaining trust and transparency. So for instance, Data Space Members can be introduced as an additional role for organisations that found the data space, sign the founding agreements and create the Data Space Governance Authority. Note: to be considered additionally External stakeholders are organizations not directly involved in the data space, but might significantly be affected by or having impact to the data space ecosystem. While they are not particularly participants of the data space, they might have interests and requirements that affect participation management and should therefore be taken into consideration, as well. This requires the data space governance authority to understand concerns and needs of external stakeholders and foster transparency by considering the potential impact and consequences of the data space on their activities.
Party Source (vsn) : 1 Key Concept Definitions (bv30)	A natural person or a legal person Explanatory Text : Parties are organisations (enterprises, governmental bodies, not-for-profits) or human beings, i.e. entities that set their own objectives and that ‘sovereignly’ decide what they do and do not do.
People, Resources And Activities (6) Source (vsn) : Examples (bv20)	A director and several board members. Operations are outsourced to TNO and KPN.Cost Model: A director, operations are outsourced to TNO and KPN.
Performance, Monitoring And Logging Source (vsn) : Value creation services (bv20)	Centralized monitoring system to collect, aggregate, and visualize performance metrics from all services and infrastructure componentsAlign with the provenance and traceability components of the data space for logs for services use, performance, access attempts, and configuration changes, incoprorating aggregation, search and visualization functionalitiesTools for real time monitorig and visualizationDefine global performance metrics Define Service Level Indicators (SLI) to measure the availability and performance of a service.Define Service Level Objectives (SLO) to guide internal process towards the Service Level Agreements. Regular reports on system performance, service usage, and security incidents
Permission Source (vsn) : Regulatory Compliance (bv20)	giving data users the right to the processing of non-personal data; (Data Governance Act Article 2(6))
Personal Data Source (vsn) : Types of data (Data as a Trigger) (bv20)	Legal landscape relevant to personal data: The data protection legal framework, including the GDPR , as well as the Law Enforcement Directive and the e-Privacy Directive (if particular circumstances apply), remains fully applicable to the processing of personal data within the context of a data space, so that parties involved in the processing activities of personal data will need to ensure compliance with relevant legal provisions. Parties affected: Neither the involvement of a data space, nor that of a personal data intermediary, relinquishes the parties involved in such processing of their duties as data controllers or processors.The clear establishment of the roles of data controller and data (sub-)processor should also be a priority, taking into account the essential criterion of decision-making powers regarding purpose and means of processing. Continuous compliance: Issues of data protection should be an important consideration from the very start of the design of a data space and throughout all of its development stages.Applicability to data spaces: In the context of data spaces, the GDPR is highly (or most) relevant for use cases. For example, if a use case or transaction involves any information relating to an identified or identifiable natural person ('data subject'), the use case or data transaction participants will need to ensure compliance with data protection legislation, most notably the principles relating to the processing of personal data.The GDPR also applies to mixed datasets (comprised of both non-personal and personal data). This remains valid also if personal data represents only a small part of the dataset.The concept of the “purpose” under data protection law should be given particular attention, as it is fundamental to clearly define any personal data processing activity.Consideration of how to ensure accountability within a data space and how compliance with data protection principles, such as lawfulness, transparency, and purpose limitation, should be facilitated. Additional resources: The Spanish Data Protection Authority , in reference also to the EDPB-EDPS Joint Opinion 03/2022 on the Proposal for a Regulation on the European Health Data Space , highlights the importance of a data protection policy, which should state “how the principles and rights set out in the data protection regulation and the guidelines in this document are to be implemented in a concrete, practical and effective manner.” Spanish data protection authority: "Approach to data spaces from GDPR perspective"Some of the most important elements to be considered for a data protection policy that the Spanish Data Protection Authority lists in its report (p. 89-97) include the involvement of data protection officers (DPOs) and advisors in the design of data spaces; implementation of procedures for authorising the processing of personal data within the data space; a precise definition of the purposes of data processing; and risk management, including data protection impact assessments (DPIAs) coordinated between involved parties.Synthetic data (sometimes referred to as “fake data”) can be understood as data artificially generated from original data, preserving the statistical properties of said original data. Some data may also be completely artificially created without an underlying real-world data asset (e.g. virtual gaming environments). From a technical perspective, the primary purpose of its generation is to increase the amount of data. This solves an issue of insufficiency in datasets or improves the variability of available data. It also serves as a way to mitigate risks to the fundamental rights of individuals. According to the Spanish Data Protection Authority, the use of synthetic data, along with other techniques such as generalisation, suppression, or the use of Secure Processing Environments, can be the way to comply with data minimisation or privacy by design/default principles. It is important to remember that when personal data is being used to generate synthetic data, it will be considered part of a processing operation and, therefore, subject to compliance with the GDPR. However, depending on the original data, the model and additional techniques applied, the synthetic data can be anonymous data.The report also emphasizes the role of traceability in data spaces for providing control mechanisms relevant for the processing activities within data spaces. In that regard, data traceability should help to identify roles and implement access control and access logging policies. It should help to facilitate fulfilling particular objectives set by the GDPR, in particular addressing the transparency requirements to data subjects, enabling the effective exercise of data subjects’ rights, such as the management of consent, facilitating excercising the obligations of the controller (e.g., to ensure the principles of restriction of processing, purposes compliant with the legal bases or of processors/sub-processors), and allowing Supervisory Authorities to exercise their powers in accordance with Article 58(1) of the GDPR.More specifically, keeping of log of accesses and data space participants' actions performed within a data space could be a way to implement the obligations laid down by art. 32 (1) GDPR requiring from controller and processor the implementation of appropriate technical and organisational measures to ensure a level of security appropriate to the risk of varying likelihood and severity for the rights and freedoms of natural persons.To read more about Provenance and Traceability in data spaces, please check the Provenance and Traceability Building Block . Technical implementation: As part of the personal data protection arrangements, a relevant solution could be to implement the W3C’s Data Privacy Vocabulary that enables the expression of machine-readable metadata about the use and processing of personal data based on legislative requirements such as the GDPR. More details about the W3C Standards/Credentials can be found in the Identity and Attestation Management building block. Special categories of personal data (“sensitive” data)According to art. 9 (1) GDPR, personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data processed solely to identify a human being, health-related data, data concerning a person’s sex life or sexual orientation, shall be considered special categories of personal data, the processing of which is generally prohibited, unless one of the strictly enumerated legal bases set out in paragraph (2) occurs. They shall be strictly interpreted and considered separately for each processing activity.If one of the legal bases is applicable, it is important to remember that processing of such data still needs to be compliant with the principles, rights and obligations established in the GDPR. As indicated by the Spanish Data Protection Authority, in the case of processing of these data, it should be demonstrated that the conditions for lifting the prohibition of such processing set out in Article 9(2) of the GDPR are met. Processing special categories of data referred to in Article 9(2)(g) (essential public interest), (h) (purposes of preventive or occupational medicine, assessment of the worker’s capacity to work, medical diagnosis, provision of health or social care or treatment, or management of health and social care systems and services) and (i) (public interest in the field of public health) of the GDPR has to provide appropriate safeguards and has to be covered by a regulation having the force of law.The GDPR also requires assessing the following: The necessity of processing the data (This also includes appropriateness. For example, when processing is necessary to protect the data subject's vital interests or for reasons of substantial public interest based on Union or Member State law).The proportionality of the processing (for example, when data is processed under essential public interest, archiving purposes in the public interest, scientific or historical research purposes, or statistical purposes).Whether the processing activity can be considered “high-risk processing” or not. If this is the case, there must be an appropriate data protection impact assessment that will manage the high risk and demonstrates passing the assessment of necessity, appropriateness and strict proportionality.One of the types of sensitive data is biometric data. Biometric data can allow for the authentication, identification or categorisation of natural persons and for the recognition of emotions of natural persons. It is defined in Art. 4 (14) GDPR as personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data. As it’s considered one of the special categories of data under GDPR, the processing of biometric data is prohibited in principle, providing only a limited number of conditions for the lawful processing of such data. Due to the increased use of biometric data in AI development and the immutability of physiological traits, the AI Act regulates the use of such data. In accordance with the AI Act, AI systems used for biometric categorisation based on sensitive attributes (protected under Article 9(1) GDPR) and emotion recognition should be classified as high-risk, in so far as these are not prohibited under this regulation. Biometric systems which are intended to be used solely for the purpose of enabling cybersecurity and personal data protection measures should not be considered high-risk AI systems.
Personal Data Source (vsn) : Regulatory Compliance (bv20)	any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;( GDPR Article 4(1) )
Personal Data Access Source (vsn) : Access & Usage Policies Enforcement (bv20)	Covers the necessary aspects regarding personal data access and consent.
Personal Data Intermediary Source (vsn) : 4 Data Space Services (bv20)	A specific participant agent intermediary that is focused on providing services for natural persons.
Pilot Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	A planned and resourced implementation of one or more use cases within the context of a data space initiative. A data space pilot aims to validate the approach for a full data space deployment and showcase the benefits of participating in the data space. Note : This term was automatically generated as a synonym for: data-space-pilot
Policy Source (vsn) : Access & Usage Policies Enforcement (bv30)	A machine-readable rule that expresses permissions, prohibitions, or obligations regarding data access and usage. Policies are encoded in ODRL and implement the terms and conditions defined in data product contracts. See 3.4.2.1 Data product contract in Contractual Framework building block.
Policy Definition Language Source (vsn) : 6 Data Policies and Contracts (bv30)	A machine-processable mechanism for representing statements about the data policies, e.g., Open Digital Rights Language (ODRL)
Policy Negotiation Source (vsn) : Access & Usage Policies Enforcement (bv20)	The support and enforcement of policy negotiation among participants in their business operations and data transactions occurring in Data Spaces.
Policy Negotiation Source (vsn) : Access & Usage Policies Enforcement (bv30)	The process through which a data provider and consumer agree on machine-readable policies for data sharing. The provider offers policies, the consumer may propose alternatives, resulting in a mutually acceptable data product contract.
Policy Validation Sources (vsn) : - Access & Usage Policies Enforcement (bv20) - Access & Usage Policies Enforcement (bv30)	The process of verifying that policies are correctly structured, consistent, and free from conflicts.
Preparatory Stage Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	The stage in the development cycle that starts when a data space initiative has a critical mass of committed stakeholders and there is an agreement to move forward with the initiative and proceed towards creating a data space. It is typical for this stage that such partners jointly develop use cases and prepare to implement the data space.
Principles, Scope, Objectives (1) Source (vsn) : Examples (bv20)	Principles:Sovereignty: self-determination of who will receive dataSafe exchange of dataIncreased efficiency in supply chainsScope:Supply chain in the manufacturing industryInvoice, order, product information dataObjectives:20% higher productivity of the supply chain by fast, safe, and interoperable exchange of informationExpand both horizontally and vertically in the value chain, initially on a European ScaleNo profit ambitions for the SCSN foundation
Provenance Source (vsn) : Provenance, Traceability & Observability (bv30)	The place of origin or earliest known history of something. Usually it is the backwards-looking direction of a data value chain which is also referred to as provenance tracking
Provenance Traceability Source (vsn) : Provenance & Traceability (bv20)	Any traceability data used to determine the provenance
Public Sector Bodies Source (vsn) : Types of Participants (Participant as a Trigger) (bv20)	Public sector bodies perform legally defined duties for the benefit of the public interest. They can be subject to specific obligations to share certain categories of data, not only with data space participants but with other potential users outside of the data space as well. The data held by public sector bodies can be of structural relevance for a data space ecosystem.
Public Sector Body Source (vsn) : Regulatory Compliance (bv20)	the State, regional or local authorities, bodies governed by public law or associations formed by one or more such authorities, or one or more such bodies governed by public law (art. 2 (17) DGA).
Pull Transfer Sources (vsn) : - Data Exchange (bv20) - Data Exchange_ (bv30)	A data transfer initiated by the consumer, where data is retrieved from the provider.
Push Transfer Sources (vsn) : - Data Exchange (bv20) - Data Exchange_ (bv30)	A data transfer initiated by the provider, where data is sent to the consumer.
Reference Datasets Source (vsn) : Data Models (bv20)	Reference data, such as code lists and authority tables, means data that are used to characterise or relate to other data. Such a reference data, defines the permissible values to be used in a specific field for example as metadata. Reference data vocabularies are fundamental building blocks of most information systems. Using common interoperable reference data is essential for achieving interoperability.
Reference Datasets Source (vsn) : Data Models (bv30)	Reference data, such as code lists and authority tables, means data that are used to characterise or relate to other data. Such a reference data, defines the permissible values to be used in a specific field for example as metadata. Reference data vocabularies are fundamental building blocks of most information systems. Using common interoperable reference data is essential for achieving interoperability.
Refining Use Case Scenarios Source (vsn) : Use Case Development (bv20)	Refining the description and design of use case scenarios using templates like the Data Cooperation Canvas, Use Case Playbook, or self created templates.
Refining Use Case Scenarios Source (vsn) : Use Case Development (bv30)	Refining the description and design of use case scenarios using templates like the Data Cooperation Canvas, Use Case Playbook, or self-created templates.
Related Service Source (vsn) : Regulatory Compliance (bv20)	means a digital service, other than an electronic communications service, including software, which is connected with the product at the time of the purchase, rent or lease in such a way that its absence would prevent the connected product from performing one or more of its functions, or which is subsequently connected to the product by the manufacturer or a third party to add to, update or adapt the functions of the connected product (art. 2 (6) DA). Explanatory Text : This term is defined as per the Data Act. This clarification ensures that the definition is understood within the specific regulatory context of the Data Act while allowing the same term to be used in other contexts with different meanings.
Relationship Manager Source (vsn) : 10 DSSC Specific Terms (bv30)	A person from the Data Spaces Support Centre who serves as the dedicated DSSC contact point for a data space initiative or another member of the community of practice.
Research Data Source (vsn) : Regulatory Compliance (bv20)	documents in a digital form, other than scientific publications, which are collected or produced in the course of scientific research activities and are used as evidence in the research process, or are commonly accepted in the research community as necessary to validate research findings and results (art. 2 (9) PSI Directive).
Researchers Source (vsn) : Types of Participants (Participant as a Trigger) (bv20)	Researchers may join data spaces to make better use of their rights under legal frameworks, leveraging the EU legal frameworks that facilitate data access and explore how data spaces can enhance access and sharing of data. In the data-sharing context, they can be both data recipients and data providers. Researchers in the EU benefit from a number of legal frameworks that facilitate access to data, including provisions in the Open Data Directive that promote the re-use of public sector information. In addition, research exceptions in intellectual property law, such as the text and data mining exception of Art. 3 Copyright in the Digital Single Market Directive, and recently introduced measures such as Art. 40 of the Digital Services Act, introduce greater access to data for researchers (under specific circumstances mentioned in the Art. 8 DSA, and purposes of, among other things, detection, identification and understanding of systemic risks and assessment of their risk mitigation). The European Data Strategy and the creation of common data spaces demonstrate general mechanisms for increased data sharing and opening up privately-held data, including for researchers. Initiatives such as Horizon Europe further support open science and data sharing, and guidelines for ethical data management and sharing agreements foster a supportive scientific research and innovation environment.For a comprehensive analysis, see: https://data.europa.eu/doi/10.2777/633395
Revenue And Pricing (for Use Cases, Data Providers, Data Recipients) (5b) Source (vsn) : Examples (bv20)	Use case participants pay fees to service providers, not directly to the data space. The participants usually already have a service contract with the service providers for use of their private platforms.
Revenue And Pricing (to Service Providers) (5b) Source (vsn) : Examples (bv20)	SCSN foundation gets a predetermined fixed contribution per service provider. The contribution depends on the number of connected users.The governance authority (SCSN Foundation) gets a fixed amount of money from the service providers for connection to the network, which is amended by a fee per end user.The end-users pay the service providers, who set their own prices for the end-users.
Rulebook Source (vsn) : 1 Key Concept Definitions (bv30)	The documentation of the data space governance framework for operational use. Explanatory Text : The rulebook can be expressed in human-readable and machine-readable formats. Note : This term was automatically generated as a synonym for: data-space-rulebook
Scalability Source (vsn) : Value creation services (bv20)	Elastic access to compute resources, that enable their dynamically allocation Consider at governance / legal level to include auto-scaling policies, that based on metrics can automatically adjust resource allocation and service usageResource quotas to ensure fair distribution of resources and use of services
Scaling Stage Source (vsn) : 3 Evolution of Data Space Initiatives (bv30)	The stage in the development cycle that starts when a data space initiative has been proven to consistently and organically gain new participants and embrace new use cases. In this stage, the data space can realistically be expected to be financially and operationally sustainable, respond to market changes, and grow over time.
Scope Of Attestation Source (vsn) : Identity & Attestation Management (bv30)	range or characteristics of objects of conformity assessment covered by attestation .
Second-party Conformity Assessment Activity Source (vsn) : Identity & Attestation Management (bv30)	conformity assessment activity that is performed by a person or organization that has a user interest in the object of conformity assessment (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Security Source (vsn) : Value creation services (bv20)	Align with authentication mechanisms of the data space and the service itself to secure service access.Include security audits and vulnerability assessmentsEnsure data at rest and in motion is encryptedImplement necessary controls
Service Description Sources (vsn) : - Data, Services, and Offerings Descriptions (bv20) - Data, Services, and Offerings Descriptions (bv30)	A service description is composed of attributes related to data services, including endpoint description and endpoint URL. Additionally, it may encompass a wide range of attributes related to value-added technical- and support services such as software-, platform-, infrastructure-, security-, communication-, and managed services. These services are used for various purposes, such as data quality, analysis, and visualisation.
Service Offering Credential Source (vsn) : Identity & Attestation Management (bv30)	A service description that follows the schemas defined by the Data Space Governance Authority and whose claims are validated by the Data Space Compliance Service. Note : This term was automatically generated as a synonym for: data-space-service-offering-credential
Services Sources (vsn) : - 1 Key Concept Definitions (bv30) - 4 Data Space Services (bv30)	Functionalities for implementing data space capabilities, offered to participants of data spaces. Explanatory Texts : - We distinguish three classes of technical services which are further defined in section 4 of this glossary: Participant Agent Services, Facilitating Services, Value-Creation Services. Technical (software) components are needed to implement these services. - Also on the business and organisational side, services may exist to support participants and orchestrators of data spaces, further defined in section 4 of this glossary and discussed in the Business and Organisational building blocks introduction. - Please note that a Data Service is a specific type of service related to the data space offering, providing access to one or more datasets or data processing functions. Note : This term was automatically generated as a synonym for: data-space-services
Services And Providers (3) Source (vsn) : Examples (bv20)	On behalf of the SCSN foundation, the executive body of the governance authority arranges for a broker service and identity provisioning (which is outsourced to KPN). This service provider also provides a vocabulary hub in which the data model is specified. Service providers provide services and platforms to parts of the supply chains.
Services Management Source (vsn) : Value creation services (bv20)	Dedicated services registry as part of the general data space registry / data space wallet Connection with data space catalogue, to enable mechanisms to register and locate services, with detailed descriptions, usage instructions, and access policies. Use specific tools for services orchestration to manage the deployment, scaling, and operation of services, and for load balancing Implement workflow automation tools to coordinate complex service interactions.Include alerting systems to notify administrators of service issues or performance degradationApply tools like service mesh or dependency graphs to manage dependencies and relationships between services
Services Provisioning And Delivery Source (vsn) : Value creation services (bv20)	Depending on the requirements and storage resources in the data space, consider the containerization of services for their provisioning and deployment, to ensure portability, scalability, and resource efficiency.API gateway, to implement client requests to services. To consider if those requests can be included in the data plane of the data spaceArtifact repository, to store, manage, and distribute the services, to facilitate version control, dependency management, and services retrieval.
Smart Contract Source (vsn) : Contractual Framework (bv30)	A computer program used for the automated execution of an agreement or part thereof, using a sequence of electronic data records and ensuring their integrity and the accuracy of their chronological ordering (Art 2(39) Data Act)
Stakeholders (4) Source (vsn) : Examples (bv20)	Over time, SCSN has received support from stakeholders such as the regional development agency (BOM), the province of Noord-Brabant, the European Commission, and the cooperative Brainport Industry Campus.
Starter Kit Source (vsn) : 10 DSSC Specific Terms (bv30)	A document that helps organisations and individuals in the network of stakeholders to understand the requirements for creating a data space. Note : This term was automatically generated as a synonym for: data-spaces-starter-kit
Strategic Stakeholder Forum Source (vsn) : 10 DSSC Specific Terms (bv30)	The designated group of experts that provide strategic support for the DSSC and make recommendations for the governance and sustainability of the DSSC assets. The strategic stakeholder forum is composed of a large variety of stakeholders with a balanced geographical distribution and will evolve progressively.
Subject Source (vsn) : Identity & Attestation Management (bv30)	thing about which claims are made (ref. Verifiable Credentials Data Model v2.0 (w3.org) )
Sui Generis Database Right Source (vsn) : Regulatory Compliance (bv20)	right for the maker of a database which shows that there has been qualitatively and/or quantitatively a substantial investment in either the obtaining, verification or presentation of the contents to prevent extraction and/or re-utilization of the whole or of a substantial part, evaluated qualitatively and/or quantitatively, of the contents of that database (art. 7 Directive 96/9/EC Of The European Parliament And Of The Council of 11 March 1996 on the legal protection of databases).
Support Organisation Source (vsn) : 10 DSSC Specific Terms (bv30)	An organisation, consortium, or collaboration network that specifies architectures and frameworks to support data space initiatives. Examples include Gaia-X, IDSA, FIWARE, iSHARE, MyData, BDVA, and more. Note : This term was automatically generated as a synonym for: data-space-support-organisation
Synergy Between Data Spaces Source (vsn) : 2 Data Space Use Cases and Business Model (bv30)	The gained efficiency, increased impact or other benefits of two or more data spaces working together that are greater than if the data spaces were working separately. The synergies between data spaces can be enabled by common practices, communication concepts, services and/or components, which increase data space interoperability and enable harmonised processes of using different data spaces.
Technology Landscape Source (vsn) : 10 DSSC Specific Terms (bv30)	A repository of standards (de facto and de jure), specifications and open-source reference implementations available for deploying data spaces. The Data Space Support Centre curates the repository and publishes it with the blueprint. Note : This term was automatically generated as a synonym for: data-spaces-technology-landscape
Third-party Conformity Assessment Activity Source (vsn) : Identity & Attestation Management (bv30)	conformity assessment activity that is performed by a person or organization that is independent of the provider of the object of conformity assessment and has no user interest in the object (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Traceability Source (vsn) : Provenance, Traceability & Observability (bv30)	The quality of having an origin or course of development that may be found or followed
Trade Secret Source (vsn) : Regulatory Compliance (bv20)	information which meets all of the following requirements: it is secret in the sense that it is not, as a body or in the precise configuration and assembly of its components, generally known among or readily accessible to persons within the circles that normally deal with the kind of information in question;it has commercial value because it is secret;it has been subject to reasonable steps under the circumstances, by the person lawfully in control of the information, to keep it secret. (art. 2 (1) Trade Secrets Directive).
Transfer Process (TP) Sources (vsn) : - Data Exchange (bv20) - Data Exchange_ (bv30)	A process that manages the lifecycle of data exchange between a provider and a consumer, involving, in example, states, as a minimum, REQUESTED, STARTED, COMPLETED, SUSPENDED, and TERMINATED.
Trigger Source (vsn) : Regulatory Compliance (bv20)	An element, criteria or an event that has occurred in a particular context of a data space, that signals that a particular legal framework must or should be applied.
Trust Anchor Source (vsn) : 8 Identity and Trust (bv20)	Trust Anchors are bodies, parties, i.e., Conformity Assessment Bodies or technical means accredited by the data space governance authority to be parties eligible to issue attestations about specific claims.
Trust Anchor Source (vsn) : 8 Identity and Trust (bv30)	An authoritative entity for which trust is assumed and not derived. Each Trust Anchor is accepted by the data space governance authority in relation to a specific scope of attestation .
Trust Anchor Source (vsn) : Trust Framework (bv30)	An entity for which trust is assumed and not derived. Each Trust Anchor is accepted by the data space governance authority in relation to a specific scope of attestation .
Trust Decision Sources (vsn) : - 8 Identity and Trust (bv20) - 8 Identity and Trust (bv30)	A judgement made by a party to rely on some statement being true without requiring absolute proof or certainty.
Trust Framework Sources (vsn) : - 8 Identity and Trust (bv20) - 8 Identity and Trust (bv30)	A composition of policies, rules, standards, and procedures designed for trust decisions in data spaces based on assurances. Trust framework is part of the data space governance framework.
Trust Framework Source (vsn) : Trust Framework (bv30)	A trust framework is comprised of:(business-related) policies, rules, and standards collected and documented in the rulebook.procedures for automation and implementation of the business-related components.
Trust Service Source (vsn) : Access & Usage Policies Enforcement (bv30)	A service that verifies claims used in policy evaluation (e.g., participant credentials, certifications). Examples include identity providers and credential verification services.
Trust Service Provider Source (vsn) : Trust Framework (bv30)	Trust Service Providers (also referred to as Trusted Issuers) are legal or natural persons deriving their trust from one or more Trust Anchors and designated by the data space governance authority as parties eligible to issue attestations about specific objects.
Trusted Data Source Source (vsn) : Trust Framework (bv30)	Source of the information used by the issuer to validate attestations. The data space defines the list of Trusted Data Sources for the Data Space Conformity Assessment Scheme/s.
Trusted Execution Source (vsn) : Value creation services (bv20)	Allign with the trust framework of the data space, and on its capabilities to identify, autenticate and authorize usersEnsure, for the execution, compliance with the data space rulebook and existing regulationsIf required and possible, consider the use of hardware-based Trusted Execution Environments (TEE), to ensure that code and data are protected during execution, and / or virtualization based security tools.
Usage Control Sources (vsn) : - Access & Usage Policies Enforcement (bv20) - Access & Usage Policies Enforcement (bv30)	Mechanisms that specify and enforce how data can be used after access has been granted.
Use Case Source (vsn) : 1 Key Concept Definitions (bv30)	A specific setting in which two or more participants use a data space to create value (business, societal or environmental) from data sharing. Explanatory Texts : - By definition, a data space use case is operational. When referring to a planned or envisioned setting that is not yet operational we can use the term use case scenario. - Use case scenario is a potential use case envisaged to solve societal, environmental or business challenges and create value. The same use case scenario, or variations of it, can be implemented as a use case multiple times in one or more data spaces. Note : This term was automatically generated as a synonym for: data-space-use-case
Use Case Development Source (vsn) : 2 Data Space Use Cases and Business Model (bv30)	A strategic approach to amplify the value of a data space by fostering the creation, support and scaling of use cases.
Use Case Orchestrator Source (vsn) : 2 Data Space Use Cases and Business Model (bv30)	A data space participant that represents and is accountable for a specific use case in the context of the governance framework. The orchestrator establishes and enforces business rules and other conditions to be followed by the use case participants. [role]
Use Case Participant Source (vsn) : 2 Data Space Use Cases and Business Model (bv30)	A data space participant that is engaged with a specific use case. [role]
Use Cases, Data Providers And Data Users (2) Source (vsn) : Examples (bv20)	One use case currently: Connecting ERP and other order systems to create efficient and robust supply chains. This leads to a reduction in administrative costs and a reduction in human error while sending and processing orders.Interoperability is established through a jointly developed standard. According to its foundational documents, maintenance of this standard is the core task of the SCSN foundation. Future use cases: price updates, stock information, and others.
Validation Sources (vsn) : - 8 Identity and Trust (bv20) - 8 Identity and Trust (bv30) - Identity & Attestation Management (bv30)	Confirmation of plausibility for a specific intended use or application through the provision of objective evidence that specified requirements have been fulfilled (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Value Creation Services Source (vsn) : Value creation services (bv30)	(technical) elements or components designed to unlock, generate and maximize the value of data shared within a data space, providing additional functionalities on top of the core process of data sharing or data transaction. Explanatory Texts : - This value is delivered both for (i) data space participants (by enabling services and applications that operate on top of data exchanges and transactions), and (ii) for the data space itself (supporting and enhancing core functionalities, such as semantic interoperability, data quality, discoverability, trust mechanisms and others) - Value creation services act over data products, and are combined with them in data space offerings, to perfom the functionalities required by the defined use cases. - Value creation services complement the capabilities provided by the “federation services” and the “participant agent” services - This value creation can come from different sides: complementing the essential capabilities of the data space, acting directly over datasets that these services are tied to, as part of data products, adding value on top of data products and data transactions, enabling the connection to external infrastructures, required to, among others, process, store and collect data, either as part of the normal operation of the data space or as needed by some use cases, enabling the connection to external applications, which are required for the complete development of use cases, facilitating by any other means the materialization of the business models considered in the data space.
Value Proposition Source (vsn) : Business Model (bv30)	A value proposition reflects the benefits for a segment of customers when adopting an offer.Benefits are typically associated with so-called pains and gains and are, therefore, fundamentally linked to key customer processes. In the case of a data space, a lack of control by data owners (sovereignty) represents one potential pain; other pains include the inaccessibility of data and non-interoperable data sources, which drive up the costs of innovative data-driven applications.
Value Proposition To Service Providers (5) Source (vsn) : Examples (bv20)	Each service provider has their own client base that could be of value to the network. It is important to note that purely having a number of clients does not mean they are automatically connected to the SCSN data space. The service providers themselves add SCSN to their existing services.
Value Proposition To Use Cases, Data Providers And Data Recipients (5) Source (vsn) : Examples (bv20)	Choices for the development agenda are made in conjunction with service providers. (In the context of SCSN, the term service provider refers to the role of an intermediary that connects some of its customers to the SCSN network.) These service providers have discussions with their clients (the data space participants). There is, however, no formal power for service providers to vote on the type of use case that needs to be developed. Functionality for users of the proprietary platform of the service provider is typically more extensive than functionality related to users of interoperable platforms. This allows service providers to focus on specific niches and capture value while establishing interoperability with co-competing service providers.
Value-creation Service Source (vsn) : 4 Data Space Services (bv20)	Any service aimed to create value out of the data shared in the data space. Explanatory Texts : - Value creation services complement the capabilities provided by the “federation services” and the “participant agent” services - This value creation can come from different sides: complementing the essential capabilities of the data space, acting directly over datasets that these services are tied to, as part of data products, adding value on top of data products and data transactions, enabling the connection to external infrastructures, required to, among others, process, store and collect data, either as part of the normal operation of the data space or as needed by some use cases, enabling the connection to external applications, which are required for the complete development of use cases, facilitating by any other means the materialisation of the business models considered in the data space.
Value-creation Services Source (vsn) : 4 Data Space Services (bv30)	(Technical) elements or components designed to unlock, generate and maximize the value of data shared within a data space, providing additional functionalities on top of the core process of data sharing or data transaction. Explanatory Texts : - This value is delivered both for (i) data space participants (by enabling services and applications that operate on top of data exchanges and transactions), and (ii) for the data space itself (supporting and enhancing core functionalities, such as semantic interoperability, data quality, discoverability, trust mechanisms and others) - Value creation services act over data products, and are combined with them in data space offerings, to perfom the functionalities required by the defined use cases. - Value creation services complement the capabilities provided by the “federation services” and the “participant agent” services - This value creation can come from different sides: complementing the essential capabilities of the data space, acting directly over datasets that these services are tied to, as part of data products, adding value on top of data products and data transactions, enabling the connection to external infrastructures, required to, among others, process, store and collect data, either as part of the normal operation of the data space or as needed by some use cases, enabling the connection to external applications, which are required for the complete development of use cases, facilitating by any other means the materialization of the business models considered in the data space.
Verifiable Credential Sources (vsn) : - Identity & Attestation Management (bv30) - Trust Framework (bv30)	A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build verifiable presentations , which can also be cryptographically verified (ref. https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential )
Verifiable ID Source (vsn) : Identity & Attestation Management (bv30)	It refers to a type of Verifiable Credential that a natural person or legal entity can use to demonstrate who they are. This verifiableID can be used for Identification and Authentication. (ref. Verifiable Attestation for ID - EBSI Specifications - ( http://europa.eu/ ))
Verifiable Presentation Source (vsn) : Identity & Attestation Management (bv30)	A tamper-evident presentation of information encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but does not contain, the original verifiable credentials (for example, zero-knowledge proofs). (ref. Verifiable Credentials Data Model v2.0 (w3.org) )
Verification Sources (vsn) : - 8 Identity and Trust (bv20) - 8 Identity and Trust (bv30) - Identity & Attestation Management (bv30)	Confirmation of truthfulness through the provision of objective evidence that specified requirements have been fulfilled (ref. ISO/IEC 17000:2020(en), Conformity assessment — Vocabulary and general principles )
Verifier Source (vsn) : Identity & Attestation Management (bv30)	A role an entity performs by receiving one or more verifiable credentials , optionally inside a verifiable presentation for processing. Other specifications might refer to this concept as a relying party. (ref. Verifiable Credentials Data Model v2.0 (w3.org) )
Vocabulary Sources (vsn) : - Data Models (bv20) - Data Models (bv30)	A data model that contains basic concepts and relationships expressed as terms and definitions within a domain or across domains, typically described in a meta-standard like SKOS.
Vocabulary Service Sources (vsn) : - Data Models (bv20) - Data Models (bv30)	A technical component providing facilities for publishing, editing, browsing and maintaining vocabularies and related documentation.

Transaction object: Sharing roles:	Personal data	Non-personal data or anonymised data
B2B	Address the legal basis for personal data sharing, by consent or other legal bases.	For anonymised data: prepare to demonstrate how data is and stays anonymised across use cases. Expect natural persons as representatives to exercise data subject rights.
B2C	[Practically not relevant scenario.]	Manage consumer participation in the data space. Is a special enabling service provider needed for connecting to the consumer?
C2B	Manage direct participation of natural persons and address the legal basis for personal data processing.	A legal basis to anonymise and a proper anonymisation capability or service is needed.
C2I2B	Intermediary must have means to manage consent or other legal grounds for handling the exchange of personal data on behalf of natural persons.	Intermediary must have an anonymisation capability that can proof effective anonymisation in cross-organisational data processing.

Events (suggestions!)	Type of data	What can be observed?	Why?
Pre transfer
Data Creation	Provenance	Information about the data origin, creation date, ownership, and data usage rights.	Essential for assessing the reliability and legal validity of the data. Example: An AI company must be able to demonstrate the origin of training data to comply with the AI Act.
During transfer
Data Access	Provenance & Traceability	Logs that a consumer connects to the provider's endpoint and starts the data transfer.	Proves that the data was actually requested; starting point of the 'chain of custody'. Example: In logistics, logging access to freight documents is crucial for tracking goods.
Data Transfer	Provenance & Traceability	Logs the successful completion or failure of the transfer, including metadata such as size and timestamp.	Serves as proof of (non-)delivery Example: A financial institution must prove that some reports has been successfully delivered.
Post transfer
Data Lineage	Traceability	Logs (by the consumer) that the data has been processed or combined. This is mainly traceability for the original data and for provenance related to new data. The transformation of data can be performed by value added services, as explained in that building block.	Mandatory for data lineage, especially under the AI Act. Example: An AI company logs that Dataset_A was used to train Model_B, making the model's origin verifiable.
Data Deletion	Traceability	Logs (by the consumer) the deletion of the data, which can be essential for GDPR compliance .	To comply with privacy legislation and contractual agreements on data retention. Example: an organization logs the deletion of personal data as proof for GDPR compliance.

Feature	OID4VC	DCP
Based on	OAuth 2.0	n/a
Self-Issuance protocol	SIOPv2	Base Identity Protocol (BIP)
VC issuance protocol	OID4VCi	Credential Issuance Protocol (CIP)
VC Presentation protocol	OID4VP	Verifiable Presentation Protocol (VPP)
Has asynchronous issuance	via polling*	via callback*
allows Human-to-Machine communications	Yes	No
allows Machine-to-Machine (or Service-to-Service) communications	Yes	Yes
Supported VC formats	agnostic	agnostic
Target domain	General trusted transactions in data spaces and digital ecosystems	Data Space trusted data transactions on top of DSP Protocol

I. Publication of an Offering
Primary Actor(s)	Data provider, catalogue
Trigger	A data provider wishes to publish an offering.
Pre-conditions	The data provider is a registered data space participant, can be authenticated as such, and is authorized to publish the offering in the catalogue. The data provider has one or more offering(s) available to publish.
Post-conditions	The data provider has added and published a new offering in the catalogue. Potential data consumers can discover the offering. If necessary, it could be made accessible only to a subset of data space participants (e.g., those participating in the use case that includes this specific dataset or service). The offering should be assigned a global unique resolvable persistent identifier (PID) to facilitate potential discovery from other data spaces.
Main Success Scenario	The data provider selects the offering(s) it wants to publish. The data provider publishes the offering(s) and access rules in the catalogue. The catalogue processes the publication of offering(s) and informs the data provider of the publication.
Extensions	2a. The data provider is not authenticated and/or authorized. The catalogue denies publication of the offering(s).
Dependencies	Data, Services and Offerings Descriptions

II. Update of an Offering
Primary Actor(s)	Data provider, catalogue
Trigger	A data provider wishes to update an existing offering.
Pre-conditions	The data provider is a registered data space participant, can be authenticated as such and is authorized to modify the offering in the catalogue. The specific offering has previously been published in the catalogue.
Post-conditions	The data provider has updated the specific offering in the catalogue.
Main Success Scenario	The data provider selects the offering(s) that it wants to update. The data provider updates the offering(s) and access rules in the catalogue. The catalogue processes the updates of the offering(s) and informs the data provider of the update.
Extensions	2a. The data provider is not authenticated and/or authorized. The catalogue denies the update of the offering.
Dependencies	Data, Services and Offerings Descriptions

III. Removal of an Offering
Primary Actor(s)	Data provider, catalogue
Trigger	A data provider wishes to remove an existing offering from the catalogue.
Pre-conditions	The data provider is a registered data space participant, can be authenticated as such and is authorized to modify the offering in the catalogue. The specific offering has previously been published in the catalogue.
Post-conditions	The data provider has removed an existing offering from the catalogue. The removed offering is no longer discoverable by data consumers.
Main Success Scenario	The data provider selects the offering(s) it wants to remove. The data provider removes the offering(s) and access rules in the catalogue. The catalogue processes the removal of the offering(s) and informs the data provider of the removal.
Extensions	2a. The data provider is not authenticated and/or authorized. The catalogue denies the removal of the offering.
Dependencies	Data, Services and Offerings Descriptions

IV. Discovery of an Offering
Primary Actor(s)	Data consumer, catalogue
Trigger	A data consumer wishes to find offering(s) in the catalogue.
Pre-conditions	The data consumer is a registered data space participant.
Post-conditions	The catalogue provides the data consumer with a collection of relevant offerings.
Main Success Scenario	The data consumer sends a request to the catalogue that includes the parameters to search the offerings in the catalogue. The catalogue composes a collection of relevant offerings based on the request. The catalogue sends the resulting collection of offerings to the data consumer.
Extensions	2a. The data consumer is not authenticated and/or authorized. The catalogue denies access to the offering(s) and does not collect relevant offerings based on the request. When an external party that is not a participant in the data space where this offering was initially published holds a global unique resolvable PID for the offering, that party may use a service to resolve this identifier to a metadata record. This may be the offering itself, if it was intended to be open, or a record directing to the catalogue entry of the offering that explains, in a machine-actionable manner, any further prerequisites that must be met. Access to the data or service itself would require subsequent onboarding of the external party into the data space.
Dependencies	Data, Services and Offerings Descriptions

#	Question	Building Block Provides	Potential Outcomes
1	What is the data space’s thematic scope?	The Business Model building block explains the importance of understanding the type of problem (industrial, supply chain, or societal) that the data space intends to resolve.	A thematic scope is a general idea (preferably a consensus) among the participants as to what the data space will address. For example: “The data space will help to reduce the administrative burden in the manufacturing value chain” (SCSN), or “The data space will assist the Belgian agrifood sector in decreasing administrative burdens and improving the (primary) business process of the participants” (DjustConnect).
2	What are the objectives of the data space?	The Business Model building block explains how data spaces create value by supporting one or more use case scenario's. Identifying the primary goals and objectives of the data space aids in guiding the space regarding which types of use case scenario's are relevant and the impact those use case scenario's should have.	The high-level objectives that allow for steering in use case selection include, for example, “Farmers should be able to see how much milk they produce throughout the year” and “energy consumption should be reduced by at least 20%." There is no immediate need to explain how these objectives will be achieved. Naturally, there may be multiple objectives for each data space.
3	What are the data space’s growth ambitions?	TheBusiness Model (original)Business Model building block distinguishes diverse ways the data space could expand. Defining the ambitions of the data space for each method of expansion provides direction. Ensure clarity on which party is responsible for monitoring and reviewing these ambitions and adapt strategies and/or policies as necessary.	An ambition on whether the data space wants to expand through: the number of participants the number of service providers the number of use case scenario's the number of data products growing into other countries servicing different industries cross-data space interoperability considerations in data space design and operation etc.
4	What are the data space’s profit ambitions?	The Business ModelBusiness Model (original)building block specifies elements of the business model, such as profit ambitions, which affect the financial model and stakeholder engagement. An important practical consideration is determining whether the data space will operate on a for-profit or non-profit basis.	Which parties should make a profit? The data space authority or the parties in it? The participants of the data space? The service providers? Other involved parties? Answers could vary from nobody to everybody to something more specific, like the participants should, but the governance authority should not.

#	Question	Building Block Provides	Potential Outcomes
1	What high-level use case scenario's should the data space support?	The Use Case Development building block offers guidance on identifying and describing high-level use case scenario's that demonstrate the data space's practical value and applications.	Outcomes could be the governance authority has full control over which use case scenario's are developed, delivered, and monetised or that the data space is a fully open platform where anyone can create and add use case scenario's. Hybrid models are also possible, in which the governance authority vets external service providers that deliver use case scenario's, for example.
2	How do these use case scenario's contribute to the overarching goals and scope of the data space initiative?	The Business Model building block provides an understanding of the overarching goals and strategic decisions of the data space. It emphasises the importance of defining how each identified use case supports and advances the broader goals, mission, scope, effects, and impacts defined for the data space.	This relates to the mechanism by which the use case supports the objectives of the data space. For example, SCSN provides purchase order messages and purchase order confirmations to reduce the administrative burden on the procurement departments of first, second, and third-tier suppliers by at least 20%.
3	How will the data space attract and scale its user base, data providers, and service offerings to achieve critical mass, where it reaches a sufficient scale to sustain itself and generate significant value?	The Business Model building block offers guidance on aligning the value propositions of multiple organisations. This aids in understanding the strategy for growing the user base, attracting data providers, and expanding service offerings.	Depending on the ambitions outlined, the scaling strategy needs to be determined as they are closely linked. An option could be to add more use case scenario's and value-added services to the platform, ensuring relevance to a broader range of users.

#	Question	Building Block Provides	Potential Outcomes
1	Who are the stakeholders that are directly and indirectly affected by the data space?	The Participation Management building block provides guidance on identifying all relevant stakeholders and their relationship to the data space.	The Participation Management building block identifies different roles: data providers, data consumers, data rights holders, intermediaries, operators, etc. Providing a list of stakeholders, which are categorised according to these roles, gives insights into who should be included in further discussions.
2	Who of these stakeholders will actually participate in the data space?	The Participation Management building block provides guidance on identifying which stakeholders are willing to engage and clarifying their roles. Identifying the roles of different stakeholders helps organise effective collaboration within the data space.	Identify the interested parties that might actually want to join and be part of, for example, the data space authority, participants that would want to become (paying) members of the data space (and under what conditions), and participants that are interested but are indirectly connected to the data space. See also the onboarding/offboarding infographic at the bottom of chapter 3.
3	What are the objectives of participation?	The Participation Management building block provides guidance on defining goals and expectations for stakeholder participation. It is important to define these for every stakeholder that participates in the data space.	Determine per type of participant why they would want to join and what their interest is. This could be a profit motive, data consumption, data sales, or use case scenario's that provide value.

#	Question	Building Block Provides	Potential Outcomes
1	Which use case scenario's should the data space focus on first, and which are to be developed in the future?	The Business Model and Use Case Development building blocks explain that a data space generates value by enabling the creation of value in use case scenario's. It is important to identify and prioritise the use case scenario's that create enough value for the data space to get started.	The list of high-level use case scenario's drafted in Align Stakeholders on the Data Space Scope - Step 2, needs to be refined and ranked according to: Value created: consider the cost of development and margins Easy of development Stakeholder interests Other parameters agreed upon by the stakeholders Once the list is complete, select the top use case(s) to further develop in the data space.
2	What is the purpose or problem to be solved by the use case (business, societal, and/or environmental value)?	The Use Case Development building block explains how the purpose and value of a use case are integral to its core design and how these aspects are validated during the refinement step.	For each use case, it is important to define the problem that it addresses and its intended purpose. The purpose of the use case should align with the purpose and scope of the data space. It should be written in a way that brings together the relevant stakeholders. For example, in SCSN: ”The purpose of sharing order data is to decrease the administrative costs of customers and suppliers by reducing errors, streamlining communication channels, and aligning product portfolios”. This provides insights into the use case's direct goal of “decreasing costs” by solving three problems.
3	Which participants or actors are directly involved in which use case scenario's, and what roles do they play?	The Contractual Framework building block enables interoperable, automated, and scalable agreements, while the Organizational Form and Governance Authority building block outlines the roles, responsibilities, and relationships of participants to ensure effective collaboration and governance. The Use Case Development building block describes a process for agreeing on the participants of a specific use case and their roles within that use case.	A comprehensive description of the use case and preferably a value network analysis. This allows participants to see their position relative to one another in each of the use case scenario's. The offerings of data products and services between the participants should be detailed, including, if applicable, the physical flows of goods and services and monetary transactions. This presents a complete picture of the business relationships between the participants. Compare this analysis with the roles defined in Align Stakeholders on the Data Space Scope - Step 3 - Question 4: relevant identities.
4	What benefits do these use case scenario's offer to these participants?	The Business Model building block outlines how the value propositions of participants influence the business model of the data space. It is important to outline the tangible benefits, value propositions, and expected outcomes that participants can derive from their involvement in each use case, providing insights into individual and collaborative business models. Therefore, establish the business model for each participant and determine how these models contribute to the collaborative value created. The Use Case Development building block describes how the value propositions for use case participants are part of the core design of a use case and how these are confirmed in the refinement step. (see: process for XX in Use Case Development building block).	For each participant, there should be a clear value proposition for each use case. This should include: The value the participant adds to the use case. The actions each participant undertakes to deliver that value (e.g. to whom the participant offers what). The cost model of delivery, including the expenses associated with executing the activities. The revenue model of delivery, detailing the revenue generated by the activities. The recipients of the participant’s offerings. The business model radar serves as a useful tool in this context.

#	Question	Building Block Provides	Potential Outcomes
1	What are the core services required within the data space, and how do they relate to the business models of the use case scenario's and data space itself?	The core services are the minimum services necessary to facilitate the functioning of the data space and its (initial) use case(s). These may include federation, participant agent, value creation services, or any combination thereof. The Business Model building blocks differentiate between federation, participant agent, and value creation services. Services are defined as the mechanisms through which value is created and are an essential part of the business model.	Define a list of services that the data space and its participants need to offer to one another in order to ensure the data space can exist. Refer to the services outlined for the Business and Organisational building blocks and Technical building blocks for inspiration. Each data space possesses its own core service. For SCSN core services are: SCSN foundation: Maintaining and developing new messages SCSN foundation: Maintaining and updating the data standard/models SCSN foundation: Monitoring and updating the rulebook Service Providers: Delivering participant agents (thus enabling access to the data space and the ability to send messages)
2	What value creation services are considered in the data space?	The Value Creation Services building block provides an approach for managing services that extend the core functionality required by the use case scenario's to create additional value. These services might include data processing, integration, or user experience to maximise the value generated.	Define a list of services that the data space and its participants need to offer one another to facilitate the provision of use case scenario's. Review the services defined for the Business and Organisational building blocks and Technical building blocks for inspiration. Value-added services vary from one data space to another. The aspects of answering this include: How do value creation services relate to the business model and use case(s) of the data space? How are they governed (who provides them and under what conditions)? Will value creation services be visible and available to all data space participants? or specific subsets of services will be restricted to just a group of participants?
3	Which parties will offer what services?	The Business Model building block shows how this question leads to a make-or-buy decision. There might be parties and/or data spaces in the market that offer the services needed to make the data space work. Use the canvas under Elements and their key functions to record which party provides which service. The Intermediaries and Operators building block helps to identify to whom these services would be provided: only to companies and organisations, or also to individuals?	This, in particular, focuses on the business requirements of the data space. Understanding the technical requirements and determining whether these should be bought or made. Defining how critical these services are for your data space informs the strategic decision for the data space orchestrator. Identifying the essential parties for your business model and the power dynamics between the participants, the service providers, and the data space authority is crucial.
4	How is data used by each use case within the data space and/or across data spaces, and what types of data are essential for its operation?	The Data Space Offering building block provides guidance for data space participants in creating resources and data product offerings. It helps determine data sources, formats, and quality requirements necessary to support use case activities. The Use Case Development building block explains how such data products can either be developed within the data space or obtained from another data space for a cross-data space joint use case.	After this question, you should have a complete picture of how data services and data products move around in your data space (if not, try to resolve this before proceeding). The outcome here should be a clear description of the data products that move throughout the data space, from whom to whom. Connecting this to the use case scenario's and services offered in the data space should give you an overview of how various parties interact within the data space.

#	Question	Building Block Provides	Potential Outcomes
1	What are the roles and responsibilities of the data space founders?	As explained in the Organisational Form and Governance Authority building block, the establishment of the data space requires the parties involved to agree to commit funds, capital, or in-kind contributions (e.g. intellectual property, IT capabilities).	Here, the partners commit resources to one another. The manner in which these resources are brought in, informs the decision regarding the organisational form made in step 2. It should be clear what each partner contributes to the foundation and maintenance of the data space.
2	What is the business model for the data space governed by the governance authority?	The Business Model building block provides guidelines for new business models and successfully developing one, outlining financial and sustainability strategies for the data space.	Here, the divisions of profits and losses are agreed upon. Once again, this informs the decision regarding the organisational form. It is important to agree on how money is spent (e.g. paid out as dividends to shareholders, reinvested in the data space) and who will contribute which amounts of resources in case the data space requires additional funding.

#	Question	Building Block Provides	Potential Outcomes
1	What organisational form is chosen for the data space?	The Organisational Form and Governance Authority building block offers an overview in the form of a decision tree to help the members of a data space initiative understand their options for legal structures. It also outlines potential organisational models for the data space.	The decision regarding the organisational form is made here. A letter of intent or a memorandum of understanding may be signed by the founders to confirm their intention to formalise their commitment in the future.
2	What are the data space agreements necessary for the establishment of the data space?	The Contractual Framework and Organisational Form and Governance Authority building blocks describe the different data space agreements that must be signed by the founders to create the data space and what additional steps might be necessary (e.g. entry into a company registry, notary’s verification).	The necessary foundational agreement (e.g. articles of association, statute) is signed between the founders. The data space as a company is entered into a company registry (depending on a country of establishment). The data space can start its activities (e.g. sign necessary agreements with service providers, accept participant to exchange data).
3	What governance structure of the data space should be established?	The Organisational Form and Governance Authority building block offers an overview of governance authority’s structure based on the legal organisational form. This aids in the creation of different bodies of the governance authority of a data space. Please note that the agreements made in step 2 of this development process are put into effect within this structure.	Here, the legally required governance authority of the data space organisation are created and effectuated. Additionally, if necessary or desired, additional bodies (e.g. task forces, working groups, committees) can be determined and created.

#	Question	Building Block Provides	Potential Outcomes
1	Which types of identities need to be supported in your data space? And what are the conditions for their issuing?	The Identity and Attestation Management building block provides an approach for managing identities and attestations while ensuring interoperability, security, and trust based on widely recognised technical standards and regulatory frameworks.	Concrete outcomes should be a list of identities coming out for the data space. This can relate to the identity of organisations, individuals and/or services or other digital assets. The division can be created with use of the technical roles within a data space: data provider, data holder, data consumer, etc. Or it can be created with the business roles: for example manufacturer and OEM. With each identity a list of conditions for issuing should be made.
2	Which other types of attestations are needed? And what are the conditions for their issuing?	The Identity and Attestation Management building block provides a division in three types of functional dimensions for identity and attestations. Additionally, it has best practices described and refers to technical standards for data spaces.	The outcome should be As a minimum, this includes a data space membership credential. What is needed for obtaining such a credential? This is linked to the participation management building block. The data space membership credential provides proof that the entity adheres to the data space rulebook. In addition to the data space membership credential, other types of attestations may be needed, for example, to prove compliance with policies related to data rights, consent, and security.
3	Which processes need to be in place to verify and enforce compliance with the Rulebook?	The Trust Framework building block provides general elements of the trust framework and a defining format of claims to making it machine readable, including a conformity assessment workflow.	For each of the credentials identified in the Identity and Attestation management building block, processes need to be in place for their issuing. For instance: membership credentials and other conformity credentials. Data space participants can use in their bilateral exchange. Processes can include for instance the signing of legal documents or automated verifications (e.g. credit score).
4	For each of the processes: how will the roles of Trust Anchors and Trust Services be implemented?	The Trust Framework building block provides the types of roles needed to ensure this trust, and explains what their breadth of scope is exactly.	Which trust anchors exist as core trusted entities which are trusted in a data space? This can stem from legislation, contractual conditions or the general accepted position of a certain entity in the data space. And furthermore: which trust services are available to implement their role in the digital world and issue credentials on their behalf? Note that for a single trust anchor, multiple trust services can be operated. And a single trust service can operate for multiple trust anchors.

#	Question	Building Block Provides	Potential Outcomes
1	For which (categories of) data products does the data space need to manage semantics?	The Data Models building block offers guidance on designing, reusing, and governing data models to enable common data sharing.	Inventory of necessary standards and guidelines for consistent data interpretation and integration.
2	Which data models are already available and can be re-used? Which new (shared) data models need to be created?	The Data Models building block provides an explainer on the abstraction levels of data models for semantically annotating the data being shared in the data space and explains how to implement this building block.	Determine if you should reuse current data models or develop new ones, and clearly define the levels of abstraction required to semantically describe your data products.
3	What kind of meta-standard will be used to express the data models in the data space?	The Data Models building block offers a list of best practices for metamodels to establish and/or annotate a domain-specific data model.	Align with one or more meta-standards to describe your data models, depending on the necessary levels of abstraction. For instance, RDF or JSON Schema.
4	What are the data space specific requirements for standardized data exchange protocols?	The Data Exchange building block offers guidance on ensuring that data is exchanged according to the specified semantics within the data model.	A list of functional requirements for protocols and interfaces to ensure compatibility and integration with the data models. Follow the plan of steps in chapter 3 of the building block.
5	Which protocols meet these requirements?	The Data Exchange building block elaborates on the process on how to chose the exchange protocols and provides best practices.	A list of exchange protocols for the exchange of data that can be implemented in the data space. Identify whether existing protocols can be used or whether new ones are necessary.
6	How will data models be managed within the data space?	The Data Models building block describes how different abstraction levels of data models can be used in actual protocols for data exchange.	Data exchanged via the data exchange protocol are semantically compliant with the data models. For instance, a data schema (e.g., JSON Schema) can be used in the data exchange protocols during data transfer to provide technical validation.
7	How will the data space manage the agreed data exchange protocols?	The Data Exchange building block offers specifications and capabilities which can be used to design policies to manage the data exchange protocols.	Technical agreements need to be governed. This starts by publishing the data exchange protocol (such as an OpenAPI specification) in a vocabulary service. Furthermore, a strategy for maintenance and updates of the protocol needs to be defined (version management).

4	Question	Building Block Provides	Potential Outcomes
1	For which data products is provenance, traceability and observability required? And what needs to be recorded?	The Provenance, Traceability & Observability building block provides a process and best practices to implementing provenance, transaction traceability and transaction observability.	Determine why and what needs to be logged within the data space, when it comes to traceability of data. For each offering, define what type of observability, provenance and traceability is possible and/or required.
2	Which data model will be used for recording and storing provenance, traceability and observability data?	The Provenance, Traceability & Observability building block offers specific information on the meta data models used in data space.	A chosen open standard data model for structuring the logs of the data transactions in the data space, which is to be amended if the standard is insufficient in use for the data space.
3	How will the logs be stored securely, and who can access them?	The Provenance, Traceability & Observability building block provides a path in how to decide this with some standard architectures in the best practices.	A storage architecture, which determines where and how logs will be stored, as well as defining the rules of when and how parties can access these rules.
4	How will the agreements on provenance, traceability and observability be governed?	The Provenance, Traceability & Observability building block

#	Question	Building Block Provides	Potential Outcomes
1	Which discovery services are needed? And who is providing them?	The Publication and Discovery building block addresses how the Dataspace Protocol for managing the exchange of catalogue entries is set-up.	A clear overview of the discovery services needed and a specific party which is responsible for providing these services. These services can be centralised in a single party, or decentralised by providing them through multiple parties.
2	How will catalogue services be implemented in the data space?	The Publication and Discovery building block provides an explainer of catalogues in the Dataspace Protocol.	Provide a specification of the Dataspace Protocol, defining the schemas and protocols necessary for the participants to negotiate agreements, access data, and publish and discover metadata.
3	What is the minimum set of metadata which needs to be provided for the (types of) data products provided in a data space?	The Data, Services, and Offerings Descriptions building block provides an overview of how the metadata could be implemented. Including an explainer of metadata in data spaces.	The Data Act, through article 33, provides a minimum set of metadata to be provided for each data product by data providers in a data space. Determine this minimum set of metadata for the data products offered in the data space. The rulebook of a data space can provide further (domain specific) attributes for the (types of) data products shared in the data space. The outcomes need to be documented in the rulebook of the data space.
4	Which functionalities of the data space could or should be provided by dedicated intermediary service providers?	The Intermediaries and Operators building block outlines the existence of intermediary service providers that allow participants without their own participant agent to join a data space. This building block will assist in defining the services that these intermediary service providers may offer.	Design the functionalities for each specific service provider and the data space authority. Consider the business models defined in Develop Use Cases and Identify Functional Requirements, as well as the agreements made in Establish Organisational Form, to ensure the technical design aligns with the business and legal requirements.

1. What is a data space?

1.1 What about a definition?

2. Which key concepts should I learn about?

2.1 Participants

2.2 Data space offerings

2.3 Services in data spaces

2.4 Rulebooks and data space governance frameworks

3. How is this reflected in the DSSC Blueprint?

3.1 Glossary

3.2 Building Blocks, the capabilities you need & specifications you can use

3.3 Our Co-creation method to guide you

3.4 Creating synergies with other data spaces

3.4 Personal data

1. Introduction

2. How can natural persons be involved?

3. Personal data and natural person related data sharing scenarios

3.1 B2B data sharing personal data considerations

3.2 B2C data sharing

3.3 C2B data sharing

3.4 C2I2B data sharing

Summary table of data sharing scenarios and core challenges

4. Conclusions for the data space designer

1. Why do we need interoperable data spaces?

2. What is cross-data space interoperability and how to achieve that?

2.1 Cross-data space interoperability and its benefits

2.2 Interoperability-by-design

2.3 The importance of interoperability governance

2.4 Investing in interoperability is a strategic decision

3. Collaboration between data spaces starts with a shared objective: a need for cross-data space use case(s)

4. Business considerations of collaborating data spaces

4.1 Collaboration between the data spaces

4.2 The governance authorities can build data sharing features across data spaces

5. Technical considerations of collaborating data spaces

6. Legal aspects of collaborating data spaces

6.1 Regulatory compliance of collaborating data spaces

6.1.1 Legal interoperability by design: enablers of cross-data space interoperability

6.1.2 Legal requirements for cross-data space interoperability

6.2 Agreements between data spaces

7. Future work

7.1 Federation of data spaces: a multi-faceted term

7.2 The role of service providers

7.3 Possible governance aspects

8. Conclusions

The DSSC as Part of the European Strategy for Data

Blueprint as Part of the Asset-Based Approach

Timeline of the Data Spaces Blueprint

We Value Your Feedback

Data Spaces Building Block requirements

Authors and Contributors of Blueprint V3.0

Architecture Board

1. Introduction

2. Overview of the pillars

2.1 Business Building Blocks

2.2 Governance Building Blocks

2.3 Legal Building Blocks

1. Summary

1.1. Questions that will be answered

2. Purpose of the building block

3. Elements of a business model and their key functions

3.1. What are the unique elements?

3.2. The value proposition

3.2.1. Efficiency gains

3.2.2. Improved collaboration

3.2.3. Sovereignty & control

3.3. Building out the business model

3.3.1 Elements of the business model template for data spaces

3.4. The revenue model

3.5. Evolving the business model

3.5.1. A sample development pathway from SCSN

3.5.2. A sample development pathway from DjustConnect

4. Co-creation questions

5. Further reading

6. Glossary

Example 1: Smart Connected Supplier Network (SCSN)

Example 2: Djustconnect

1. Summary

1.1. Questions that will be answered

2. Purpose of the building block

3. Concepts

3.1 Use case and use case scenario