LogoLogo
How to Build Dataspaces?Main IDSA AssetsOther ResourcesManifesto for International Data Spaces
Dataspace Protocol
Dataspace Protocol
  • Overview
    • Dataspace Protocol 2024-1
    • Terminology
    • Information Model
  • Common Functionalities
    • Specification
    • Binding: HTTPS
  • Catalog
    • Specification
    • Binding: HTTPS
  • Contract Negotiation
    • Specification
    • Binding: HTTPS
  • Transfer Process
    • Specification
    • Binding: HTTPS
  • List of Files
    • Common
    • Figures
    • Messages
    • Schemes
    • Shapes
  • Best Practices
    • Introduction
    • Related Documents
Powered by GitBook
On this page
  • 2 Dataspace Information Model
  • 2.1 Dataspace Entity Relationships
  • 2.2 Classes
Edit on GitHub
  1. Overview

Information Model

Last updated 1 year ago

Links:

  • IDSA Website
  • IDSA Github
  • Legal Notice
  • Privacy Policy

© 2016 – 2025 | All Rights Reserved | International Data Spaces Association

2 Dataspace Information Model

The following sections outline the Dataspace Information Model, which form the foundation of this specification. Some aspects of this section describe additional concepts of Dataspaces and provide context for the Dataspace Protocol, those are considered as non-normative. Further information on the functional requirements of a Dataspace can be found for example in the IDSA Rulebook.

2.1 Dataspace Entity Relationships

2.1.1 Context of the Dataspace Protocol

In a broader context, the Dataspace Protocol enables the interaction between participants of a Dataspace. This may require additional concepts, which are not in the scope of this specification. The definitions below are therefore informative and not-normative. The relationships between the primary entities are defined as follows:

Note that all relationships are multiplicities unless specified. Dataspace Authority and Dataspace Registry are non-normative entities.

Further non-normative information on the context of the Dataspace Protocol can be found for example in the IDSA Rulebook.

2.1.2 Dataspace Protocol specific

2.2 Classes

Note 1: The classes and definitions used in the Dataspace Protocol are reused from different standards and specifications as much as possible, in particular, DCAT and ODRL. As, however, the external definitions allow different interpretations or provide more attributes than required, the Dataspace Protocol is leveraging profiles of the original definitions rather than the complete original expressiveness. A profile in this sense is a restriction or subset of an external definition, enforcing that every occurrence of an externally defined class is always conformant with the original definition. However, not every standard-compliant class might be compliant to the dataspace profile.

2.2.1 Catalog

2.2.2 Dataset

2.2.3 Offer

  • An ODRL uid is represented as an "@id" that is a unique identifier. (ODRL PROFILE)

2.2.4 Agreement

A manages one or more . This will include registration and may entail mandating business and/or technical requirements. For example, a may require to obtain some form of business certification. A may also impose technical requirements such as support for the technical enforcement of specific usage policies.

A records dataspace participants.

A is a member of one or more . A registers that perform tasks on its behalf.

A performs tasks such as publishing a or engaging in a . In order to accomplish these tasks, a may use a verifiable presentation generated from a credential obtained from a third-party . A may also use an ID token issued by a third-party . Note that a is a logical construct and does not necessarily correspond to a single runtime process.

An is a trust anchor that generates ID tokens used to verify the identity of a . Multiple identity providers may operate in a . The types and semantics of ID tokens are not part of this specification. An may be a third-party or a itself (for example, in the case of decentralized identifiers).

A issues verifiable credentials used by to allow access to and verify usage control.

The Dataspace Protocol shall enable the interactions between the in a Dataspace. The following concepts are therefore normative.

The diagram below depicts the relationships between types:

A is a that makes a DCAT Catalog available to other .

A contains one or more , which are DCAT Datasets. A also contains at least one DCAT DataService that references a where may be obtained.

A has at least one , which is an ODRL Offer describing the associated with the .

A is a that performs and operations with another . An outcome of a may be the production of an , which is an ODRL Agreement defining the agreed to for a .

Not all entities have a concrete technical materialization; some entities may exist as purely logical constructs. For example, a and a have no representation in the protocol message flows that constitute interactions. This section outlines the classes that comprise the concrete elements of the model, i.e., those that are represented in protocol message flows.

A is a DCAT Catalog with the following attributes:

0..N . Since a may be dynamically generated for a request based on the requesting credentials it is possible for it to contain 0 matching . (DCAT PROFILE)

1..N DCAT DataService that references a where may be obtained. (DCAT PROFILE)

A is a DCAT Dataset with the following attributes:

1..N hasPolicy attributes that contain an ODRL Offer defining the associated with the . Offers must NOT contain any target attributes. The target of an is the associated . (ODRL PROFILE)

1..N DCAT Distributions. Each distribution must have at least one DataService which specifies where the distribution is obtained. Specifically, a DataService specifies the endpoint for initiating a and . (DCAT PROFILE)

An is an ODRL Offer with the following attributes:

The must be unique to a since the target of the is derived from its enclosing context.

The value of the target attribute is the dataset id. Except if the [Offer] is used in an enclosing or , then the there must not be any target attribute set.

An is an ODRL Agreement with the following attributes:

The class must include one target attribute that is the identifier of the the is associated with. An is therefore associated with EXACTLY ONE . (ODRL PROFILE)

Dataspace Authority
Dataspaces
Participant
Dataspace Authority
Participants
Dataspace Authority
Dataspace Registry
Participant
Dataspaces
Participant
Participant Agents
Participant Agent
Catalog
Transfer Process
Participant Agent
Credential Issuer
Participant Agent
Identity Provider
Participant Agent
Identity Provider
Participant Agent
Dataspace
Identity Provider
Participant
Credential Issuer
Participant Agents
Datasets
Participant Agents
Participant Agent
Catalog Service
Participant Agent
Participants
Catalog
Datasets
Catalog
Connector
Datasets
Dataset
Offer
Usage Policy
Dataset
Connector
Participant Agent
Contract Negotiation
Transfer Process
Connector
Contract Negotiation
Agreement
Usage Policy
Dataset
Dataspace
Dataspace Authority
Participant Agent
Dataspace
Catalog
Datasets
Catalog
Participant's
Datasets
Connector
Datasets
Dataset
Usage Policy
Dataset
Offer
Dataset
Contract Negotiation
Transfer Process
Offer
Offer
Dataset
Offer
Catalog
Catalog
Dataset
Agreement
Agreement
Dataset
Agreement
Agreement
Dataset
Dataspace