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 oneDCAT 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.
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)
