1.  Introduction

This document aims to guide the expert groups through the process of writing functional specification for data space building blocks. A functional specification is a description of the functionality of a given building block, i.e. it describes how a building block should behave on a high-level. In the context of DSSC, functional specification serves as the Data Spaces Blueprint for creating interoperable and reusable components that can be used to build data spaces.

This document provides templates that the expert groups can use to create a functional specification for data space building blocks. By following the guidelines outlined in this document and using these templates, in particular, WP5 of the DSSC will be able to create clear and concise input for the Data Spaces Blueprint that captures the requirements and design for the Blueprint.

2.  Functional Specification Template Building Blocks

2.1.                 Front matter

To ensure consistency, it is recommended to reuse the existing DSSC word template for papers with covers, imprint, and content[1].   However, it should be extended to include important details such as the name/number of the expert group, the names of the reviewers, the date it was created, and the date it was last updated. This will provide a structured format for the front matter of the document.

Title: [Title of the document]

Publisher: [Name of the publisher]

Copyright: [Copyright information]

Consortium: [Name of the consortium]

Contact: [Contact information]

Author(s): [Name(s) of the author(s)]

Expert Group: [Name of the expert group]

Reviewers: [Name(s) of the reviewers]

Created On: [Date the document was created]

Last Updated: [Date the document was last updated]

2.2.                 Introduction

A brief introduction of the building block

[Illustrative image or figure describing the building block]

Interrelationships: An overview of how the building block relates to other building blocks in the OpenDEI DSSC framework. This should include any dependencies, shared functionalities, and potential conflicts with other building blocks.

2.3.                 Purpose of the Building Block

This section should provide an introduction to the technical specification of the data space building block. A technical specification is a detailed and comprehensive document that describes all technical produces related to the building block. The introduction should explains its purpose, use cases, and intended functionalities. In addition, the introduction of the document should also contain a summary of the problem, including the context, suggested solution and the key stakeholder.

A very brief introduction (max 5 sentences): Provide an introduction of the technical specification for a technical data space building block by explaining the context in which the building block will be used.

Purpose and problem: Explain the purpose of the building block and how it relates to the specific problem or need that it is intended to address.

Use cases: Describe the potential use cases of the building block. It involves identifying and explain the various ways in which the building block can be used to solve specific problems or achieve certain goals.

Suggested solution: Provide a suggested solution or approach to address the problem. It is important to be clear and concise, and to provide enough details to allow key stakeholders to understand how the approach of the solution will address the problem.

Key stakeholders: Identify all stakeholders involved in the development, implementation, and usage of the building block to ensure their needs and expectations are taken into account.

When to use the building block? When not?

2.4.                 Definitions and Vocabulary

In this section, all terms and vocabulary used throughout the technical specification are defined and explained, which is a subset of the DSSC Glossary and thus fully aligned with the content of the DSSC Glossary.  

For terms that are included in the DSSC Glossary, please refer to that section for their definitions. If new terms are introduced, they should be provided with a criterion as its description. The idea is that different people (in the context of DSSC and data space initiatives) will make the same judgments when they use criteria in some (relevant) context - i.e. they would agree on whether or not something is (not) an instance (example) of the term. By following this process, it is also possible to propose generic terms to the DSSC Glossary that were not initially included. The DSSC Glossary team will analize and approve/reject the proposed terms.

2.5.                 Conceptual Model

This section should provide a high-level conceptual model of the data space building block, including all the concepts and relations between them. A conceptual model can be used to clarify and communicate these technical specifications. It establishes a shared understanding among key stakeholders. The conceptual model can be seen as a highlighted subset of the DSSC conceptual model, optionally enriched with BB-specific concepts. It may function as input for the conceptual model expert group.

A conceptual model represents (a part of) a single mental model, and typically consists of specifications for:

• concepts, i.e. (named) classes of entities that have similar properties, e.g. 'data space', 'party', 'person', etc.

• properties, i.e. (named) characteristics that can be attributed a value to every instance of a specific concept. For example, the concept 'person' can have a property named 'gender', with values such as 'M' (for male) or 'F' (female).

• relations between such concepts, i.e. meaningful (characteristic) links that can exist between (instances of) these concepts, e.g. '[party] is the governance authority of [data space]' or '[person] is the mother of [person]'.

• constraints, i.e. logical expressions composed of concepts, their properties and/or relations, that are expected to be (made) true. For example:

o   every person has precisely one other person as its mother, and that person has gender 'F' (this is always true);

o   every data space must have precisely one party that is its governance authority (if this is not true, it must be made true).

Figure : the Concepts and Relations within a Conceptual Model

To define a concept, its properties, or a relation between concepts, a criterion should be provided as a description in the glossary table.

**[Illustrative image or figure describing the Conceptual Model]** 

2.6.                 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.

 

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.

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.