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 is a DCAT catalog offered by a provider
- 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
Example: CatalogRequestMessage
Response: Catalog containing the DCAT catalog.
Schema: CatalogRequestMessageShape and the CatalogRequestMessage JSON Schema
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
Example: Catalog
Response: OK or ERROR
Schema: CatalogShape and the Catalog JSON Schema
The catalog contains all Asset Entries which the requester shall see.
Sent by: Consumer or Provider
Example: CatalogError
Response: OK or ERROR
Schema: CatalogErrorShape and the CatalogError JSON Schema
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
Example: DatasetRequestMessage
Response: Dataset containing the DCAT Dataset.
Schema: DatasetRequestMessageShape and the DatasetRequestMessage JSON Schema
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.
This section describes how the IDS Information Model maps to DCAT resources.
An Asset Entry is a DCAT Dataset with the following attributes:
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: As
odrl: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 | dcat:DataService |
| 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.
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:
- Each ODRL
Offermust be unique to a dataset since the target of the offer is derived from its enclosing context. - Each ODRL
Offermust NOT include an explicittargetattribute.