Information Model

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 Dataspace 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

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

The diagram below depicts the relationships between Participant Agent types:

2.2 Classes

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

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

A Catalog is a DCAT Catalog with the following attributes:

2.2.2 Dataset

A Dataset is a DCAT Dataset with the following attributes:

2.2.3 Offer

An Offer is an ODRL Offer with the following attributes:

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

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

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

2.2.4 Agreement

An Agreement is an ODRL Agreement with the following attributes:

Last updated

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