FOR SHARE - JULY SNAPSHOT - Publication and Discovery services - Functional description

Created by

Last updated: 3 July 2023, 10:37

Early draft

Please be aware that the Data Spaces Blueprint content shared in these pages are a very early draft published on 2023-07-01. The current draft is incomplete and the content might still change.

SAVE-THE-DATE 01-10/09/2023: We will welcome your feedbacks to future improve the Data Spaces Blueprint during the Public consultation that will open on September the 1^st 2023 until September the 10^th. Please mark these dates in your calendar and get ready!

Introduction

As described in the Two-pages description, Publication- and Discovery services act as a Catalogue that contains Self-Descriptions of resources (such as Data Services) that are available in the Data Space. The Self-descriptions are created and stored in the Catalogue by Providers of these services, so that they become discoverable for Consumers. The Self-descriptions contain all required information for a Consumer to find best-match offerings as well as how to consume the resource, i.e., connect to the Provider of the resource for the actual data transaction.

The figure below shows the relationships to other DSSC building blocks. Please see the Two-pages description for additional information.

Purpose of the building block

The Catalogue is one of the Data Space building blocks that enables loose coupling between Providers and Consumers and facilitates dynamic data transactions between these Parties. The figure below shows the position of the Catalogue in between Provider(s) and Consumer(s).

Providers create (i.e. publish), update and delete Self-descriptions in the Catalogue. Consumers are able to find (i.e. discover) these resources in the Catalogue, find best-match offerings and acquire the information to connect to the Provider and consume the Resource. Once the Catalogue has provided the required information to the Consumer it no longer plays a role in the actual data transaction.

Key functions

The Two-pages description describes five key functions of the Catalogue, which relate to publication, discovery and governance of Self-descriptions:

Publication of Self-Descriptions by Providers,
Modification of Self-Descriptions by Providers,
Removal of Self-Descriptions by Providers,
Querying of Self-Descriptions by Consumers,
and -in addition- access control to Self-Descriptions.

The above key functions are the basis for the use cases, described in 'Functionality' below

Key stakeholders

The key stakeholders for the Catalogue are data Providers and -Consumers, as well as Catalogue or Data space governance authorities.

Conceptual Model

Concepts and relations

The figure below shows the conceptual model of the Catalogue in relation to Providers and Consumers and to the other building blocks in the ‘Data Value Creation’ category.

Providers create Self-Descriptions of their resources in the Catalogue, and -as part of the Self-Descriptions' lifecycle management- update and delete them. Consumers are then able to discover the Self-Descriptions in the Catalogue.

The Self-Descriptions are created according to a Self-Description model. This model is based on the input from the ‘Data Value Creation' building block 'Data, Services, and Offerings Descriptions’. In addition, the Catalogue is part of the Marketplace, as described in ‘Marketplaces & Usage Accounting’.

Constraints

The following constraints were identified:

A Provider may create many Self-Descriptions.
A Self-Description must refer to a unique Provider.
A Self-Description must refer to a unique resource.
Multiple Self-Descriptions may refer to a single resource.

Functionality

This section should provide a detailed description of the functions that the data space building block should acquire, including its intended features and capabilities. It must clearly describe what the building block is expected to do and its anticipated input/output interactions with other building blocks.

To ensure that different components can work together seamlessly, it is important to clearly define any assumptions being made about the interactions with other building blocks. These assumptions should be documented and clearly communicated to all stakeholders involved in the development and implementation of both building blocks. Interactions with other building blocks can be thought of as synchronization points, where data or functionality is exchanged between components of a data space.

In this section, a table is used to define the details of each function within a data space building block. Each row of the table represents a single function, and the columns represent various aspects of the function, such as its description, interactions with other building blocks, constraints or limitations, and dependencies.

Five use cases were defined for the Catalogue based on the five key functions that were described in the Two-pages description:

UC-1: Provider publishes a Self-Description.
UC-2: Provider updates a Self-Description.
UC-3: Provider deletes a Self-Description.
UC-4: Consumer queries the Self-Descriptions.
UC-5: Catalogue executes access control to Self-Descriptions.

The above use cases are described in the tables below.

UC-1	Provider publishes a Self-Description.
Primary Actor(s)	Provider, Catalogue.
Trigger	A Provider wishes to publish a new Resource Self-Description or Resource Offering Self-Description.
Pre-conditions	The Provider is a registered Data Space Participant, can be authenticated as such and is authorized to create the Self-Description in the Catalogue. The Provider has created one or more Self-Description(s) that it wants to publish in the Catalogue. The Catalogue is able to authenticate and authorize the Provider.
Post-conditions	A new Self-Description has been created in the Catalogue by the Provider. The Self-Description is discoverable by Consumers.
Main Success Scenario	The Provider sends a request to the Catalogue with the Self-Description to be created and offers its Provider credentials to the Catalogue. The Catalogue authenticates and authorizes the request based on the Provider’s credentials. The Catalogue creates the new Self-Description based on the Provider’s request. The Catalogue responds the result to the Provider.
Extensions	If Condition, then Alternative Steps <List any extended steps/ scenarios that occur, other than the main success scenario.>
Dependencies	<relations to other building blocks>
Special Requirements	<Any system related special requirements needed to fulfill the use case>
Open Questions	<Notes and questions>

UC-2	Provider updates a Self-Description.
Primary Actor(s)	Provider, Catalogue.
Trigger	A Provider wishes to modify an existing Resource Self-Description or Resource Offering Self-Description.
Pre-conditions	The Provider is a registered Data Space Participant, can be authenticated as such and is authorized to modify the Self-Description in the Catalogue. The Provider has previously created the specific Self-Description. The Catalogue is able to authenticate and authorize the Provider to modify the specific Self-Description.
Post-conditions	The specific Self-Description has been updated in the Catalogue by the Provider. The updated Self-Description is discoverable by Consumers. (Please note that this may be dependent on the nature of the update and its relation to lifecycle management of the Self-Description).
Main Success Scenario	The Provider sends a request to the Catalogue to update a specific Self-Description, includes the information to be updated, and includes its Provider credentials. The Catalogue authenticates and authorizes the request based on the Provider’s credentials. The Catalogue updates the existing Self-Description based on the request. The Catalogue responds the result to the Provider.
Extensions	If Condition, then Alternative Steps <List any extended steps/ scenarios that occur, other than the main success scenario.>
Dependencies	<relations to other building blocks>
Special Requirements	<Any system related special requirements needed to fulfill the use case>
Open Questions	<Notes and questions>

UC-3	Provider deletes a Self-Description.
Primary Actor(s)	Provider, Catalogue.
Trigger	A Provider wishes to remove an existing Resource Self-Description or Resource Offering Self-Description from the Catalogue.
Pre-conditions	The Provider is a registered Data Space Participant, can be authenticated as such and is authorized to remove the Self-Description from the Catalogue. The Provider has previously created the specific Self-Description. The Catalogue is able to authenticate and authorize the Provider to remove the Self-Description.
Post-conditions	An exiting Self-Description has been removed from the Catalogue by the Provider. The removed Self-Description is no longer discoverable by Consumers.
Main Success Scenario	The Provider sends a request to the Catalogue to delete a specific Self-Description and includes its Provider credentials. The Catalogue authenticates and authorizes the request based on the Provider’s credentials. The Catalogue removes the existing Self-Description based on the request. The Catalogue responds the result to the Provider.
Extensions	If Condition, then Alternative Steps <List any extended steps/ scenarios that occur, other than the main success scenario.>
Dependencies	<relations to other building blocks>
Special Requirements	<Any system related special requirements needed to fulfill the use case>
Open Questions	UC-3 could be a specific implementation of UC-2, where a status property of the Self-Description is updated so that the Self-Description is no longer discoverable by Consumers and is, for instance, actually removed after 30 days by an automated process. This, however depends on business requirements and policies, either domain-specific or data space generic.

UC-4	Consumer queries the Self-Descriptions
Primary Actor(s)	Consumer, Catalogue
Trigger	A Consumer wishes to find a Resource Self-Description or Resource Offering Self-Description in the Catalogue.
Pre-conditions	The Consumer is a registered Data Space Participant, can be authenticated as such and is authorized to query the Self-Descriptions in the Catalogue.
Post-conditions	The Catalogue provides the Consumer with a collection of relevant Self-Descriptions.
Main Success Scenario	The Consumer sends a request to the Catalogue that includes the parameters to search the Self-Descriptions in the Catalogue, and includes the Consumer’s credentials. The Catalogue authenticates and authorizes the request based on the Consumer’s credentials. The Catalogue creates a collection relevant of Self-Description based on the request. The Catalogue responds the resulting collection of Self-Descriptions to the Consumer.
Extensions	If Condition, then Alternative Steps <List any extended steps/ scenarios that occur, other than the main success scenario.>
Dependencies	<relations to other building blocks>
Special Requirements	<Any system related special requirements needed to fulfill the use case>
Open Questions	<Notes and questions>

UC-5	Catalogue executes access control to Self-Descriptions.
Primary Actor(s)	Catalogue, Identity Provider
Trigger	A Provider wishes to publish one or more Self-Descriptions in the Catalogue that are only discoverable by Consumers under certain conditions, e.g.: To certain types of Consumers, To specific Consumer IDs, Other conditions.
Pre-conditions	The Catalogue has the ability to authenticate and authorize Consumers. Note: the Catalogue might not do the authentication and authorization itself but invoke the appropriate Data Space components/building blocks to do so. The Self-Description data model allows for defining the access conditions. The Provider of the Self-Description has included information in the Self-Description that allows the Catalogue to determine access rights to the Self-Description, based on the Consumer’s credentials.
Post-conditions	The Catalogue allows or denies the Consumer access to each Self-Description. From a Consumer perspective this will result in a collection of relevant Self-Description that the Consumer is allowed to see.
Main Success Scenario	The Consumer sends a request to the Catalogue that includes the parameters to search the Self-Descriptions in the Catalogue, and includes the Consumer’s credentials (similar to UC-4). The Catalogue authenticates and authorizes the request based on the Consumer’s credentials. The Catalogue authenticates and authorizes Consumer for access to each of the self-description that are relevant and potentially part of the result collection. The Catalogue creates a collection relevant of Self-Description based on the request that the Consumer is allowed to access. The Catalogue responds the resulting collection of Self-Descriptions to the Consumer.
Extensions	If Condition, then Alternative Steps <List any extended steps/ scenarios that occur, other than the main success scenario.>
Dependencies	<relations to other building blocks>
Special Requirements	<Any system related special requirements needed to fulfill the use case>
Open Questions	<Notes and questions>

2.7. Open Challenges – Future Roadmap

This section highlights any open challenges or future directions for the data space building block, including potential improvements. Potential challenges for a building block may arise in its interactions with other building blocks, making compliance a crucial consideration. This section should provide an overview of potential challenges and opportunities for future development of the building block.

The main functionalities of the Publication & Discovery services are described in the preceding sections. These specifications may need to be refined at later stages to cater for different architectural options (i.e. central, federated, peer-to-peer catalogues etc.). An important outlook is also the enhancement of discovery services based on the semantic interoperability specifications with regard to the Self-Description models and the potential interlinking of vocabularies and ontologies used in them.

2.8. Conclusions

~~Short statements about the current state-of-the-art, how this matches with the defined requirements and functionality (gap analysis), and some final remarks.~~