Building-Blocks-Catalog
Last updated
Last updated
This is the repository to list the building blocks developed in OPEN DEI project.
The different building blocks can be specified and developed independently of each other. When doing so, existing norms, standards, and best practices should be used to ensure cohesion of building blocks. Each data space solution can integrate multiple building blocks, as long as they are in line with data space reference architectures (e.g., the IDS Reference Architecture Model v4.0). The building blocks presented in this chapter are core elements of any data space. As such, they can be considered sector-agnostic. Nevertheless, they can be used in sector-specific scenarios (see e.g. seaport scenarios). Data space stakeholders may also define additional building blocks to support innovative features and functions. For instance, data space architects may introduce building blocks that enable novel types of data space architectures combining centralised and decentralised approaches. Likewise, business stakeholders may introduce building blocks that enable novel forms of smart contracts to be agreed upon by participants of a data space, thereby facilitating business model innovations. Hence, the building blocks presented in this chapter are not exhaustive, but rather indicative of the elements of a data space. In general, each building block consists of reusable, generic components (i.e. which can be used across domains and industries) and more specific components (i.e. to meet requirements and regulations that are specific for certain industries, domains, or even concrete use cases). This allows individual participants to join different data spaces, use data in multiple contexts and scenarios, and be part of multiple data value chains.
The taxonomy of building blocks constituting a data space will benefit various stakeholders:
Data space architects and integrators will be provided with a structured way for identifying the components required for their specific architecture.
Building block developers will be a given a clear description on how their components can fit into the specific architecture of a data space.
Business managers will be able to identify business model candidates for data sharing and exchange (including data monetisation) in the context of a specific data space.
Data space policy managers will have access to building blocks that can be used to specify and enforce data space related policies (e.g., data access policies, privacy control policies).
These building blocks should be deployed by all data providers and data consumers participating in a data space. This way, each data provider can be sure that any data published can be technically consumed by any data consumer entitled to do so, while each data consumer can be sure they are able to technically access and use any data made available by any data provider selected. The following building blocks belong to this category:
Data sovereignty and trust Building Blocks regaining control over their data, and as data becomes portable between providers on a user-controlled consent basis. Users can switch between providers without losing their data and vendor lock-in will become a phenomenon of the past. For participants in data spaces, data sovereignty means two things:
Benefit from enhanced possibilities to view, process, manage, and secure their data.
Stay in control over their data when making it accessible to other parties.
These building blocks include the data ownership policies that require agile and standardised ICT capabilities when such agreements are to be negotiated dynamically. We need to establish a semantic interoperability of policies and behavioural interoperability of policies.
The building blocks that provides data sovereignty and trust are:
These building blocks cover essential aspects to handle data as an economic asset:
The building blocks subsumed under this category refer to business, operational and organisational agreements among data spaces participants. These agreements are enforced through legal frameworks participants have to adhere to, or via technical building blocks:
Several companies have already reported their thoughts, improvements and results when using building blocks:
Building blocks are usually combined with others, giving as a result a complete product or service. Amongst other qualities, data sovereignty and interoperability tend to be a powerful asset which makes the difference with other initiatives of the sector.
agreements comprise service level agreement (SLA), data usage and access control policies as well as specified standards.
Visit for more information.
Visit for more information.
is a vendor-neutral, open-source machine-readable data product metadata model. This specification is developed openly under the . The Open Data Product Specification aims for the same impact in the Data Economy as what OpenAPI specification did for the API Economy. The data products and data as a service solutions are spread around increasing amount of market places, tool stack for the data product design, development and management is a wild west, consumers have a hard time knowing what they are purchasing or how to compare data products to find a best possible fit in their situation. In short, the data economy lacks a data product standard. By working together and openly, we can increase interoperability, growth, and data reuse with help of shared specification. International standards are a vital tool in ensuring products and services are interchangeable and compatible across borders, removing barriers to trade, reducing production and supply chain costs and building confidence in business services and protecting consumers.
It consists of a highly accurate sleep monitoring device that can comfortably record sleep at your home. A comprehensive sleep dataset will be created using using 's new technology, incorporating a multitude of physiological and environmental sensors. Based on data collected in controlled and uncontrolled environments, robust AI-powered sleep analysis algorithms with medical-grade accuracy will be implemented.
The objective of the experiment consists of the monitoring of sea water quality in different areas of a port. In essence, different datasets (geoposition data on water quality, AIS navigation real-time data, etc..) will be shared in iGreenPort data space to create several data packages at different levels of the ‘data value chain’ to be utilised by iGreenPort partners and external entities, particularly authorities with environmental competencies in ports, their suppliers, and research groups in the field.
The mobility community has created several hubs for international GTFS sources over the years. There have been consistent issues with sustaining these platforms in the long term, and creating community processes so it's clear how decisions are made and how stakeholders across the mobility industry can contribute to the platform. That's the need is working to meet with the , so more stakeholders can trust the longevity of this platform and it can become an increasingly valuable source for creating and improving mobility data as a community.