Content Interactive Delivery

Content Interactive Delivery est un protocole pour l'échange de documents et de métadonnées entre deux systèmes informatiques. CID définit comment un serveur doit décrire ses processus d'échanges de documents et métadonnées et comment un client doit exécuter ces processus.

Un processus CID est constitué d'un ensemble d'étapes qui peuvent être :

• un simple échange de données entre un client et un serveur, par exemple à travers une requête HTTP GET ou POST ;

• une interaction entre le serveur et l'utilisateur d'un client ;

• une requête spécifique contenant un document à uploader depuis le client vers le serveur.

CID permet de publier, télécharger ou gérer des documents distants sur une application serveur depuis une application cliente sans implémentation spécifique.

Trois grandes familles de systèmes participent au cycle de vie des documents :

• les systèmes de production comme les LCMS (Learning Content Management System), les CCMS (Component Content Management System) ou les chaînes éditoriales dont l'enjeu principal est d'optimiser la production des documents ;

• les systèmes d'exploitation pédagogiques comme les LMS (Learning Management System), les CMS (Content Management System) ou les MOOC (Massive Open Online Course) dont l'enjeu est de faciliter l' exploitation des documents ;

• les systèmes de gestion et d'archivage comme les logiciels de gestion électronique de documents (GED) ou les systèmes de gestion de bibliothèque dont l'enjeu est d'accompagner le cycle de vie des documents.

Pour assurer leur fonction, ces systèmes proposent des processus fonctionnels dédiés à leur métier (comme par exemple des processus de publication, de déploiement, d'archivage ou de mise à jour). Pour être opérationnels, les systèmes déployés dans un même environnement doivent communiquer entre eux des informations (comme par exemple des métadonnées) ou directement s'échanger des documents. Ces transactions sont assurées, soit manuellement par l'usager, soit par un module de connexion développé spécifiquement pour la liaison entre deux systèmes. Dans le premier cas, les transactions manuelles sont laborieuses et sources d'erreurs. Dans le second, les contraintes techniques relatives à chaque système imposent le développement et la maintenance d'un connecteur par paire de systèmes, voire d'une version de connecteur par version de paire de systèmes.

La solution idéale serait un protocole automatisant l'ensemble du processus. Cela reviendrait à disposer d'un bouton qui, une fois cliqué, assurerait l'ensemble de la transaction, quels que soient le système source, le type de communication et le système cible. Une telle automatisation est impossible à mettre en œuvre. La représentation des documents inhérente à chaque système, les métadonnées associées ainsi que les contraintes techniques relatives au métier ne permettent pas la mise en place d'un tel protocole universel.

La médiation entre deux systèmes ne peut se faire sans l'usager. C'est sa compréhension de chacun des systèmes qui lui permet d'ajuster les processus fonctionnels utilisés. Il est le seul à savoir ce que signifie l'arrivée d'un document dans son contexte. Par exemple, lui seul sait si le transfert d'un document depuis une chaîne éditoriale vers une LMS sert à alimenter un nouveau cours (qui vient de s'ouvrir en formation continue) ou à mettre à jour un ancien cours (en formation initiale, déjà démarré).

Il y a une forte tension entre un besoin d'encadrement et d'automatisation, un contexte fortement hétérogène, et une nécessité de médiation des transactions par les usagers. L'enjeu du protocole CID est d'adresser cette tension. Ces cas d'usage typiques sont l'upload, le déploiement, la mise à jour ou la récupération de documents entre deux systèmes.

Le serveur CID définit ses processus au sein d'un manifeste accessible par une simple requête HTTP GET non authentifiée.

Le client peut alors récupérer le manifeste, l'interpréter et exécuter les étapes qui y sont définies. Il y a trois types d'étapes :

Un manifeste CID peut définir plusieurs processus. Chaque processus définit un jeu de métadonnées et des étapes facultatives ou obligatoires. Chaque étape définit les métadonnées facultatives ou obligatoires ainsi que les métadonnées retournées par le serveur à l'issu de l'étape.

Quand le client récupère le manifeste, il doit déterminer :

• le processus à exécuter ;

• les étapes optionnelles à exécuter ;

• les valeurs des métadonnées ;

• les métadonnées optionnelles à envoyer.

Pour faire ces choix, le manifeste fournit des informations formelles pour automatiser les choix du client et descriptives pour que le client puisse déléguer ces choix à l'utilisateur et construire automatiquement une IHM de sélection.

Un attribut "is" peut être ajouté à un processus, une métadonnée ou une étape. Cet attribut doit contenir une ou plusieurs IRIs de description d'une action ou d'une donnée (il est par exemple possible d'utiliser des URIs de schema.org comme http://schema.org/SendAction ou du DublinCore comme http://purl.org/dc/elements/1.1/title). Cet attribut constitue la description formelle pour le client afin de sélectionner automatiquement une étape ou de compléter automatiquement une métadonnée.

Quand le client ne peut pas prendre une décision automatiquement (soit par ce qu'il ne reconnaît pas une IRI, soit par ce qu'aucune IRI n'est spécifiée), il peut utiliser le niveau descriptif (des labels localisés) afin de construire une IHM de sélection.

CID permet ainsi trois types d'interaction.

1. Des interactions entre le client et le serveur (les étapes d'échanges et d'upload du protocole). Ces interactions constituent le cœur du protocole. C'est par elles que les documents et métadonnées sont échangées.

2. Des interactions entre l'utilisateur (du client) et le serveur (l'étape d'interaction du protocole). Ces interactions prennent la forme de pages HTML construites par le serveur et affichées par le client à l'utilisateur dans un navigateur ou une frame web d'une page web existante.

3. Des interactions entre le client et l'utilisateur. Lorsque les modalités d'une transaction ne peuvent pas être automatiquement déterminées par le client, ce dernier doit alors proposer à l'usager des interfaces de sélection de processus, d'étapes et de complétion de métadonnées.