Building the Global Dataspace to optimally support AI by applying FAIR Digital Objects.

For a complete architecture overview, we refer to the FDO One Architecture Report: Link

Primary Principles

  1. The experience with the Internet suggests that one single global integrated dataspace will emerge based on a unifying interoperability standard.
  2. International standards must work across country borders, and therefore must be transparent to legal and ethical conditions of data reusage and have a low entry level for worldwide users. Conditions of data reusage must be securely transferred to higher layers.

Abstraction is a Must

The user is acting in a universal space of FAIR Digital Objects, defined by persistent identifiers and metadata provided by common and trustworthy services. In general, the user is only interested in these metadata descriptions and not in the underlying technical service and storage details.

User Vision

The general user is interested to get answers to the following questions:

  • Are there data objects relevant for my intentions?
  • Are the found data objects indeed useful for me?
  • Are there software applications which I can apply on the data objects?
  • Am I allowed to use the data objects for the purposes I have in mind and the intended software?
  • What are the efforts and costs of all steps?

The benefit of FDOs is that they can immediately give answers to all these questions, since they bundle all information about data objects relevant for FAIR processing.

Basic Building Blocks

In the FDO One project we are making use of three basic technologies that are currently broadly discussed and used especially in European research and industry.

FAIR Digital Objects (FDO)

FDOs are simple atomic, secure and persistent machine actionable units of information that bundle all information that is necessary to enable FAIR processing of the data included, i.e. it is identifiable by global, unique, resolvable and persistent identifier which resolves to a FDO Record which contains attribute-value pairs that either contain values such as the type of the object or references to all kinds of metadata information including access conditions, smart contracts etc. as provided by the data owner.

To make this small unit machine actionable the set of attributes used by a specific data provider need to be specified in a profile and all attributes that are being used also need to be defined and registered. In addition to the few minimal mandatory attributes the data provider can add his own semantics as long as they are well-defined.

  • FDOs are not a new metadata standard but can incorporate any kind of provider defined metadata.
  • FDOs can include all types of data object types (data, metadata, configurations, assertions, software, etc.).
  • FDOs can be directly addressed worldwide due to the PID independent of any local technology stack. The global dataspace is acting as a gigantic “object store”.
  • Due to the unified model, it is possible to use one Digital Object Interface Protocol (DOIP) to access all FDOs.
  • FDOs will not handle access conditions but will transfer them in secure ways to the next layer.

FDO Overview: https://doi.org/10.5281/zenodo.7824713
FDO Specifications: https://doi.org/10.5281/zenodo.7781925
Data FDO: https://drive.google.com/file/d/1ySd4HB89nXYopUe0HK0bzCdbf8Zx5_Jl/view?usp=sharing
DOIP: https://www.dona.net/sites/default/files/2018-11/DOIPv2Spec_1.pdf 

Eclipse Dataspace Connector (EDC)

The EDC technology was developed to be able to tightly control the usage of shared data according to agreed contracts and licence conditions formalised as ODRL assertions. To achieve this control two connectors need to be installed – provider and consumer side, which then interact with each other and which interpret the ODRL assertions which have been defined by the producer. Of course some metadata can be exchanged with brokers for example who create search portals etc. If procedures are going to be used to operate on the data they can be taken from a jointly managed app store.

Using EDC requires to set up a Dataspace with a strict governance to agree on many aspects such as roles of users who have certain rights, correct interpretation of the ODRL assertions; checks on using certified connector software, liaisons with accepted brokers, defining the set of joint apps that are allowed, etc. This technology is currently being tested out in some dataspace projects such as Mobility Data Space and Catena-X.

Eclipse Data Connector: https://projects.eclipse.org/free-tags/dataspace-connector

Asset Administration Shell (AAS)

Asset Administration Shell (AAS) concept in Industry 4.0 (I4.0) was primarily developed as a flexible component-based metadata solution to describe physical machines in all details including a complete software stack to create, store, and maintain such metadata descriptions. In the meantime, it has been accepted as the basis of the International Digital Twin Association, and of course, it can be used to describe any asset, including digital ones. As indicated in the diagram below, it can be seen as a comprehensive and successful solution since it offers reusable templates for submodel descriptions and collaborates with initiatives such as ECLASS, which defines parameters of machines to increase semantic interoperability and interfaces to all its components and files being stored in company-owned registries.

I4.0 AAS was not primarily designed as a federation technology to exchange information in a standardized manner. Therefore, it is an excellent example of a comprehensive solution implementing dataspaces for specific purposes: different producers participating in developing complex machines, for example, contribute to their digital twins, store descriptions and references in secured registries, and exchange files with protected information.

Industry 4.0 AAS: https://www.plattform-i40.de/IP/Redaktion/DE/Downloads/Publikation/AAS-ReadingGuide_202201.pdf?__blob=publicationFile&v=1

Bridge Building

Basic Interoperability

Many dataspaces have already been setup during the last decades applying different regulations and technologies and new ones are in development in industry and science. It is already common practice that repositories in research and industry, which are managing large collections, are typically members of different dataspaces, partly due to international collaborations. As in the case of the Internet it is necessary to integrate these different “islands” by applying a basic interoperability standard. FDOs are extremely well suited for this task, since they are FAIR, technology independent and with the help of adapters existing dataspaces and repositories can be interconnected without the need to change the existing legacy. Users do not have to install anything to participate in the FDO domain which is important for SMEs and the public to participate.

Eclipse Dataspace Integration

The FDO Framework is transparent with respect to the control of who can use your data objects and therefore is an ideal basis for a global data infrastructure. This, however, does not mean that FDOs can only be used for open data. The FDO One project demonstrates that the combination of FDOs and the Eclipse Dataspace Connector (EDC) technologies leads to mutual benefits, since the latter is adding control about data usage which is often required by industry and medical applications for example. In such a scenario the IDSA EDC solution will be integrated with the help of an FDO-EDC Adapter into the global space.

In addition, a repository, which is integrated in the general FDO space and suddenly needs to offer protected data as well, can easily install the EDC-Connector and use the FDO-EDC adaptor to offer controlled access to specific data. All repositories including those that are part of EDC based dataspaces can offer their metadata and open data without additional efforts in the global dataspace and thus make them available to brokers.

It should be noted that for data usage control, we should assume that different security technologies will be applied worldwide.

I4.0 Asset Administration Shell Integration

The AAS model is now used broadly by industry to create digital twins of machines for advanced model building and simulations. The AAS technology includes a whole stack of software components allowing to share, exchange and reuse models and submodels, i.e. complex dataspaces are being created in manufacturing industry. Therefore, FDO One sees it as an important contribution to also include the domain of AAS models into the common basic dataspace and to develop an interface to an AAS server.

Summary

We can state that FDO adapters will integrate all interesting repositories and dataspaces into one virtual dataspace independent of the regularities and technologies they need to apply. With the help of an FDO-EDC interface, data objects hosted in dataspaces applying the EDC technology and with the help of an FDO-AAS interface, data objects hosted in dataspaces applying the AAS technology, can be made visible and if wished being shared using a low entry barrier. This unifying character of the FDOs to create a basic interoperability across dataspaces is indicated in the diagram which have been implemented by FDO One.

FDO Operations

A special objective of the FDO One project is to study and implement FDO Operations, i.e. to relate methods with data and thus make FDOs active which is a concept very well-known from object-oriented programming. The FDO Manager being developed in WP1 makes use of FDO Operations.

Using the above diagram, we can compare the principles of FDO Operations and the EDC integration of applications both with advantages and disadvantages. In the EDC domain dataspace partners agree on building an App store, agree on the kind of apps to integrate and carry out the usual tests on the software. If a user wants to apply software on data objects the provider connector (in interaction with the consumer connector) controls the actions/application of a software on the data and data flows that have been shared.

In the FDO domain operations (software) can be seen as methods of the object class defined by a type. The provider of the data object can maintain its own operations registry that links types with tested operations. Of course such registries can be shared also by communities which then would be comparable to the EDC solution, but more simple to implement. Going this way a hospital could specify that accepted users can only use a specific AI software on the personal data they store.

A completely new possibility would be opened to see FDOs not just as passive units, but as active units. Operations could be associated with FDOs such that FDOs are acting as autonomous agents exchanging signed events to ensure a high degree of security. This concept of ActiveFDOs has completely been worked out and conceptually applied to the system that could implement a system supporting Digital Product Passports, which are modelled with the help of I4.0 AAS. Of course, this mechanism of ActiveFDO could be applied to any supply chain challenge. Different than the Linked Data approach the relations between FDOs are procedures which offers completely new opportunities.

 

The White Paper (V0.2) can be found here: https://drive.google.com/file/d/1YtQRTnvaK-LQaVaNjWMHZg3ohZzcJGHz/view?usp=sharing