%2520(2).png%3Falt%3Dmedia%26token%3Db98fb6fb-250c-4c0b-a287-91d8bfaab188){kind=logo}
%2520(2).png%3Falt%3Dmedia%26token%3Db98fb6fb-250c-4c0b-a287-91d8bfaab188){kind=logo}
Comment on page
Specification
This document outlines the catalog protocol. The following terms are used:
- A message type defines the structure of a message.
- A message is an instantiation of a message type.
- a catalog service is a provider participant agent that advertises offered assets
- A consumer is a participant agent that requests access to an offered asset.
The catalog protocol defines a how a
Catalog is requested from a catalog service by a consumer using an abstract message exchange format. The concrete message exchange wire format is defined in binding specifications.All messages must be serialized in JSON-LD compact form as specified in the JSON-LD 1.1 Processing Algorithms and API. Future IDS specifications may define additional optional serialization formats.
Sent by: Consumer
The
CatalogRequestMessage is message sent by a consumer to a catalog service. The catalog service must respond with a Catalog, which is a valid instance of a DCAT Catalog.The
CatalogRequestMessage may have a filter property which contains an implementation-specific query or filter expression type supported by the catalog service.The catalog service may require an authorization token. Details for including that token can be found in the relevant catalog binding specification. Similarly, pagination may be defined in the relevant catalog binding specification.
Sent by: Provider
Response: OK or ERROR
Sent by: Consumer or Provider
Response: OK or ERROR
A Catalog Error Message is used when an error occurred after a
CatalogRequestMessage and the provider can not provide its catalog to the requester.Sent by: Consumer
The
DatasetRequestMessage is message sent by a consumer to a catalog service. The catalog service must respond with a Dataset, which is a valid instance of a DCAT Dataset.The
DatasetRequestMessage must have a dataset property which contains the id of the dataset.The catalog service may require an authorization token. Details for including that token can be found in the relevant catalog binding specification.
Sent by: Provider
Response: OK or ERROR
This section describes how the IDS Information Model maps to DCAT resources.
An asset entry Dataset must have 1..N
hasPolicy attributes that contain an ODRL Offer defining the usage control policy associated with the asset. Offers must NOT contain any target attributes. The target of an offer is the asset associated with the containing asset entry.Note: Asodrl:hasPolicy rdfs:domain odrl:AssetandAssetEntry isA dcat:Dataset, eachAsset Entryis also anodrl:Assetfrom an ODRL perspective.
An asset may contain 0..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 ContractNegotiation and AssetTransfer.A Distribution may have 0..N
hasPolicy attributes that contain an ODRL Offer defining the usage control policy associated with the asset and this explicit Distribution. Offers must NOT contain any target attributes. The target of an offer is the asset entry that contains the distribution.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.A DataService may specify an IDS service endpoint such as a
Connector.If the DataService refers to an IDS service endpoint, it must include the property
dspace:dataServiceType:Category | Description |
|---|---|
Definition | Specifies the IDS 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 IDS endpoint types:
Value | Description |
|---|---|
dspace:connector | A Connector endpoint |
| |
Note that the property
dcat:servesDataset should be omitted from the DataService since DataSets are included as top-level entries. Clients are not required to process the contents of dcat:servesDataset.A catalog service may support catalog queries or filter expressions as an implementation-specific feature. However, it is expected that query capabilities will be implemented by the consumer against the results of a
CatalogRequestMessage, as the latter is an RDF vocabulary. Client-side querying can be scaled by periodically crawling provider catalog services, caching the results, and executing queries against the locally-stored catalogs.The catalog protocol is designed to be used by federated services without the need for a replication protocol. Each consumer is responsible for issuing requests to 1..N catalog services, and managing the results. It follows that a specific replication protocol is not needed, or more precisely, each consumer replicates data from catalog services by issuing
CatalogRequestMessages.The discovery protocol adopted by a particular dataspace defines how a consumer discovers catalog services.
It is expected (although not required) that catalog services implement access control. A catalog as well as individual catalog datasets may be restricted to trusted parties. The catalog service may require consumers to include a security token along with a
CatalogRequestMessage. The specifics of how this is done can be found in the relevant catalog binding specification. The semantics of such tokens are not part of this specification.When a catalog contains protected datasets the provider has two options: include all datasets in the catalog response and restrict access when a contract is negotiated; or, require one or more proofs when the catalog request is made and filter the datasets 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 catalog request is outside the scope of the Dataspace Protocol Specifications. However, binding specifications should define a proof data endpoint for obtaining this information.
A dataspace may include catalog brokers. A catalog broker is a consumer that has trusted access to 1..N upstream catalog services and advertises their respective catalogs as a single catalog service. The broker is expected to honor upstream access control requirements.
The catalog is a DCAT catalog with the following restrictions:
- 1.Each ODRL
Offermust be unique to a dataset since the target of the offer is derived from its enclosing context. - 2.Each ODRL
Offermust NOT include an explicittargetattribute.
Last modified 24d ago