Specification
Last updated
Dataspace Protocol
Last updated
This document outlines the . The used terms are described .
odrl:hasPolicy
Support for hasPolicy attributes on a Distribution is optional. Implementations may choose not to support this feature, in which case they should return an appropriate error message to clients.
dspace:dataServiceType
If the Data Service refers to an endpoint that supports the Dataspace Protocol, it must include the property dspace:dataServiceType:
Definition
Specifies the service type
Domain
Type
xsd:string
Note
The value of this field is left intentionally open for future extension.
The following table lists well-know endpoint types:
dspace:connector
dcat:servesDataset
Sent by
Resulting state
TERMINATED
Response
Schema
Example
Diagram(s)
Sent by
Resulting state
TERMINATED
Response
Schema
Example
Diagram(s)
The ACK and ERROR response types are mapped onto a protocol such as HTTPS. A description of an error might be provided in protocol-dependent forms, e.g., for an HTTPS binding in the request or response body.
Sent by
Schema
Example
Diagram(s)
Sent by
Schema
Example
Diagram(s)
Sent by
Schema
Example
Diagram(s)
code
String
An optional implementation-specific error code.
reasons
Array[object]
An optional array of implementation-specific error objects.
The Catalog Protocol defines how a is requested from a by a using an abstract message exchange format. The concrete message exchange wire format is defined in the binding specifications.
This section describes how the DSP Information Model maps to resources.
A is a with the following attributes:
A must have 1..N hasPolicy attributes that contain an defining the associated with the . Offers must NOT contain any explicit target attributes. The target of an is the associated . This is in line with the semantics of hasPolicy as defined in the , explaining that the subject (here the Dataset) is automatically the target of each Rule. To prevent conflicts, the target attribute must not be set explicitely, for example, in the or Rules.
A may contain 0..N . 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 .
A Distribution may have 0..N hasPolicy attributes that contain an defining the associated with the and this explicit Distribution. must NOT contain any target attributes. The target of an is the that contains the distribution.
A Data Service may specify an endpoint supporting the Dataspace Protocol such as a .
A endpoint.
Note that the property dcat:servesDataset should be omitted from the DataService since are included as top-level entries. Clients are not required to process the contents of dcat:servesDataset.
The identifier of the participant providing the is specified using the dspace:participantId attribute on that .
The is a with the following restrictions:
Each must be unique to a since the target of the is derived from its enclosing context.
A must not have an odrl:hasPolicy attribute, since it is not intended to negotiate on the access to objects. An implementation might however regulate the visibility and/or the content of its dependent of the requester.
All messages must be serialized in JSON-LD compact form as specified in the . Further specifications may define additional optional serialization formats.
or
,
The Catalog Request Message is message sent by a to a . The must respond with a , which is a valid instance of a .
The message may have a filter property which contains an implementation-specific query or filter expression type supported by the .
The may require an authorization token. Details for including that token can be found in the protocol binding, e.g., . Similarly, pagination may be defined in the protocol binding.
or
,
The Dataset Request Message is message sent by a to a . The must respond with a , which is a valid instance of a .
The message must have a dataset property which contains the id of the .
The may require an authorization token. Details for including that token can be found in the protocol binding, e.g., .
,
The contains all which the requester shall see.
,
,
,
A Catalog Error is used when an error occurred after a or a and the cannot provide its to the requester.
A may support queries or filter expressions as an implementation-specific feature. However, it is expected that query capabilities will be implemented by the against the results of a , as the latter is an RDF vocabulary. Client-side querying can be scaled by periodically crawling the , caching the results, and executing queries against the locally-stored .
The is designed to be used by federated services without the need for a replication protocol. Each is responsible for issuing requests to 1..N , and managing the results. It follows that a specific replication protocol is not needed, or more precisely, each replicates data from catalog services by issuing .
The discovery protocol adopted by a particular defines how a discovers .
It is expected (although not required) that implement access control. A as well as individual may be restricted to trusted parties. The may require to include a security token along with a . The specifics of how this is done can be found in the relevant protocol binding, e.g., . The semantics of such tokens are not part of this specification.
When a contains protected the has two options: include all in the response and restrict access when a contract is negotiated; or, require one or more proofs when the is made and filter the accordingly. The latter option requires a mechanism for clients to discover the type of proofs that may be presented at request time. The specifics of proof types and presenting a proof during a request is outside the scope of the Dataspace Protocol. However, bindings should define a proof data endpoint for obtaining this information.
A may include Catalog Brokers. A Catalog Broker is a that has trusted access to 1..N upstream and advertises their respective as a single . The broker is expected to honor upstream access control requirements.
