What is CID?

Content Interactive Delivery is a web service protocol which provides rules to exchange contents such as documents and their metadata. CID defines how a server should describe its data exchange processes, and how a client should execute a process.

A CID process is a set of steps which can be: a regular request such as an HTTP GET or POST request; a direct interaction between the third party server and the user; a specific request such as a file upload.

Overview of the CID protocol

CID makes it possible to publish, download or manage remote contents in a standardized and thus interoperable way. Theoretically, it is transport/platform neutral (like SOAP), but in practice it has only been specified for HTTP.

Why another web service protocol?

Document software such as writing or management systems have to embed specific document handling mechanisms dedicated to their needs. Allowing automatic document exchanges requires specific developments to convert the content in the remote disposition.

CID is a protocol which allows direct interaction between the user and the third party server in order to prepare or conclude the exchange. The result of this interaction is a set of data forwarded to the client. This interaction could be used to select or fill content metadata.

CID typical use cases are content uploads, deployments, updates or retrieving.

How does it work ?

The CID server must define its processes in a manifest accessible through a simple GET HTTP request.

Download the manifest

Then, the client must interpret the manifest and follow its steps. Three kind of steps can be used :

Regular exchange
Direct interaction
Content upload

A generic way to operate document transaction

A CID manifest can define several processes. Each process defines a set of metadata and a set of required and optional steps. Each step defines the required, the optional and the returned metadata.

When the client receives the manifest, it must choose:

  • The process to execute

  • The optional steps to execute

  • The filling of metadata

  • The optional metadata to send

To make these choices, the manifest defines a level of formal information for the client software and a level of descriptive information for the user. An attribute "is" can be inserted on a process, a metadata or a step. This attribute contains one or more IRIs that define an action or a data (For example, IRIs from schema.org like http://schema.org/SendAction or from the DublinCore like http://purl.org/dc/elements/1.1/title). This information is formal and allows a client to automatically process some choices (change the process, pre-fill metadata, etc.).

When the client can not automatically make a decision, it can exploit the level of descriptive information (localized XML label and doc elements) to build a selection GUI.

CID allows three types of interaction:

  1. Interaction between the client and the server (exchange and upload steps of the protocol). These steps are the core features of the protocol. It is through them that the documents and metadata are exchanged.

  2. Interaction between the server and the user (the "interact" step of the protocol). This step is displayed by a client frame web, handled by the user and issued by the server.

  3. Interaction between the client and the user. When choosing the features of the transaction (process, optional steps, optional metadata and their content), the client can automatically determine these choices from the "is" attribute or it can provide a selection GUI to the user built with the label and the documentation elements of the manifest.