Formats CIM

Le Cloud Information Model (CIM) a été conçu dès le départ comme un modèle de concepts métier basé sur des normes et indépendant des applications : clients, commandes, produits, comptes et les relations entre eux. Mais un modèle conceptuel n’est utile que si les systèmes qui en ont besoin peuvent réellement le consommer. C’est pourquoi le CIM n’est pas publié comme un artefact propriétaire unique, mais comme une famille de sérialisations, chacune ciblant une classe d’outils, un environnement d’exécution et un public différents.

Cette page explique ce qu’est chaque format CIM, à quoi il sert et comment choisir parmi eux. Si vous êtes un architecte de données d’entreprise, un ingénieur d’intégration ou ETL, un fournisseur d’applications ou de plateformes ou un contributeur open source, le format que vous choisirez en premier dépend de l’endroit où vous vous situez dans le pipeline.

Points clés à retenir

• Le CIM est distribué en deux familles : les formats du web sémantique (JSON-LD, RDF Schema, SHACL, R2RML) et les formats lisibles par l’homme/relationnels (vocabulaire AML, dialecte AML, types RAML, JSON Schema, SQL DDL).
• Le modèle conceptuel (concepts.*) décrit les entités et les relations ; le schéma canonique (schema.*) décrit les formes et les contraintes des données. Ce sont des artefacts distincts ayant des objectifs distincts.
• JSON-LD est la forme canonique lisible par machine ; AML est la forme lisible par l’homme du même contenu ; SQL DDL et JSON Schema sont les formes que la plupart des équipes d’applications et ETL consomment directement.
• R2RML est le pont : il mappe un schéma relationnel vers un graphe RDF, ce qui permet de connecter les bases de données SQL existantes à la couche sémantique.
• Le choix d’un format est une question de consommateur, et non de préférence : choisissez celui que votre chaîne d’outils cible ingère nativement et utilisez les autres comme vérifications croisées.

Pourquoi le CIM est livré dans plusieurs formats

La plupart des modèles de données sont publiés sous une seule forme : généralement un diagramme ER, une feuille de calcul ou un fichier de métadonnées spécifique au fournisseur. Cela fonctionne jusqu’à ce que vous ayez besoin de partager le modèle entre des organisations qui utilisent des piles technologiques différentes.

Une plateforme de vente au détail peut utiliser PostgreSQL et dbt ; un partenaire peut utiliser une base de données orientée graphe et un triple store ; un fournisseur SaaS peut exposer des API JSON et valider les charges utiles avec JSON Schema. Si le modèle partagé n’existe que dans l’un de ces dialectes, tous les autres doivent le traduire — et les traductions divergent.

La stratégie multiformat du CIM est une réponse délibérée à ce problème. Le modèle est rédigé une seule fois, puis traduit dans des formats qui correspondent précisément à des normes reconnues, afin que chaque consommateur adopte le CIM en utilisant les outils dont il dispose déjà.

C’est la même philosophie que celle des organismes de normalisation tels que le World Wide Web Consortium (W3C), qui publie des spécifications telles que RDF, SHACL et R2RML que le CIM réutilise plutôt que de les réinventer. Cela s’aligne également sur la mission d’interopérabilité plus large de la Linux Foundation, sous l’égide de laquelle le projet CIM opère.

Connexes : Fivetran — Le pipeline ELT entièrement géré qui continue de fonctionner.

L’avantage pratique est double : les entreprises utilisant des technologies variées peuvent adopter le CIM sans avoir à tout remplacer, et les contributeurs peuvent étendre le modèle dans le format correspondant à leur expertise, sachant que les autres sérialisations peuvent être régénérées.

Le modèle conceptuel vs le schéma canonique

Avant de comparer les formats de fichiers, il est utile de séparer deux couches que le CIM maintient distinctes — et que les nouveaux arrivants confondent fréquemment.

• Le modèle conceptuel répond à la question qu’est-ce qui existe et comment cela est-il lié. Il définit les entités (Client, Commande, Produit), leurs attributs et les relations entre elles. Il est intentionnellement proche du vocabulaire métier et délibérément léger sur les détails physiques.
• Le schéma canonique répond à la question à quoi ressemble une instance valide. Il ajoute des formes de données et des contraintes — cardinalité, types, champs obligatoires, plages de valeurs — qu’un système peut valider.

Dans la distribution CIM, ceux-ci correspondent à deux racines de noms de fichiers : concepts.* pour la couche conceptuelle et schema.* pour la couche canonique. Le fait de les garder séparés permet à un analyste métier de lire le modèle conceptuel sans s’encombrer de la syntaxe des contraintes, tandis qu’un ingénieur peut valider des charges utiles par rapport au schéma sans avoir besoin du récit conceptuel complet.

Notre sélection : Workato — iPaaS piloté par l'automatisation sur lequel les équipes commerciales peuvent réellement s'appuyer.

Les formats du Web sémantique

Ces formats expriment le CIM sous forme de graphe basé sur RDF. Ils constituent le bon choix lorsque vos consommateurs incluent des triple stores, des graphes de connaissances, des outils d’ontologie ou tout système capable de raisonner sur des données liées.

JSON-LD — concepts.json et schema.json

JSON-LD est du JSON avec un contexte de données liées, ce qui en fait le pont pragmatique entre les API Web ordinaires et le web sémantique. Le CIM publie deux artefacts JSON-LD :

• concepts.json — la description conceptuelle des entités et des relations, exprimée en RDF Schema.
• schema.json — les formes de données canoniques et les contraintes supplémentaires, exprimées en SHACL.

Comme il s’agit de JSON valide, concepts.json et schema.json peuvent être chargés par des outils JSON ordinaires, mais comme ils portent un @context, ils se développent également en triplets RDF complets. Cette double nature est la raison pour laquelle JSON-LD est souvent le meilleur choix par défaut pour les équipes qui souhaitent une fidélité sémantique sans adopter une pile RDF spécialisée dès le premier jour.

RDF Schema — schema.json

Le schéma RDF (RDFS) fournit le vocabulaire pour décrire les classes et les propriétés — les constructions rdfs:Class, rdfs:subClassOf et rdfs:domain/rdfs:range qui permettent à une machine de comprendre qu’une Commande est un document commercial et que sa propriété client pointe vers un Client. Le CIM utilise RDFS pour donner une sémantique formelle au modèle conceptuel, afin que les hiérarchies de sous-classes et les domaines de propriété soient interprétables par machine plutôt que simplement documentés.

SHACL — schema.json

Le Shapes Constraint Language (SHACL) est une norme du W3C permettant de valider des graphes RDF par rapport à un ensemble de conditions appelées formes (shapes). Là où RDFS indique ce qu’une classe est, SHACL indique ce qu’une instance valide doit satisfaire : propriétés requises, types de valeurs autorisés, limites de cardinalité. Les formes de données canoniques de CIM sont exprimées en SHACL, ce qui signifie que n’importe quel processeur SHACL peut valider des données conformes à CIM sans code personnalisé.

R2RML — schema.rdml

R2RML est la norme du W3C pour mapper un schéma de base de données relationnelle vers un graphe RDF. C’est le format qui importe le plus pour les ingénieurs d’intégration et ETL, car c’est le mécanisme par lequel une base de données SQL existante — avec ses tables, colonnes et clés étrangères — est exposée en tant que données liées conformes à CIM.

Connexes : Matillion — ELT push-down conçu pour les entrepôts de données cloud.

Plutôt que de remodeler manuellement votre base de données opérationnelle, vous écrivez (ou générez) un mappage R2RML qui déclare comment chaque table et colonne correspond aux entités et propriétés CIM. Le résultat est un graphe RDF virtuel sur vos données relationnelles existantes.

Les formats lisibles par l’homme et relationnels

Tous les consommateurs ne veulent pas de RDF. Les développeurs d’applications, les modélisateurs de données et les administrateurs de bases de données veulent souvent quelque chose qu’ils puissent lire dans un éditeur de texte ou charger directement dans une base de données. CIM les sert via les sérialisations AML, RAML, JSON Schema et SQL DDL.

AML — concepts.yaml, schema.yaml, schema.raml

AML, la lignée AnyLogic Modeling Language utilisée ici comme dialecte de modélisation, est l’expression lisible par l’homme de CIM. CIM publie trois artefacts AML :

Si vous faites du shopping : Boomi AtomSphere — Enterprise iPaaS pour l'intégration hybride cloud-on-premise.

• concepts.yaml — le vocabulaire AML, une version lisible par l’homme du modèle conceptuel.
• schema.yaml — le dialecte AML, une version lisible par l’homme des formes de données canoniques.
• schema.raml — le rendu des types de données RAML des formes canoniques.

La distinction entre vocabulaire et dialecte mérite d’être internalisée : le vocabulaire définit les termes (les noms et les verbes du modèle), tandis que le dialecte définit la manière dont ces termes sont combinés en structures valides. Si vous consultez CIM pour la première fois, concepts.yaml est généralement le point d’entrée le plus accessible.

JSON Schema — schema.json

JSON Schema est la norme de facto pour valider les documents JSON, prise en charge nativement ou via des bibliothèques dans pratiquement tous les langages modernes. L’artefact JSON Schema de CIM exprime les formes de données canoniques sous forme de JSON Schema, ce qui le rend directement utilisable dans les passerelles API, les courtiers de messages et les pipelines CI qui valident déjà les charges utiles JSON. Si votre surface d’intégration est REST ou JSON événementielle, c’est souvent le format que vous souhaitez.

SQL DDL — schema.sql

SQL DDL est l’ensemble des instructions CREATE TABLE, CREATE VIEW et des contraintes qui matérialisent les formes canoniques dans une base de données relationnelle. CIM cible la syntaxe SQL 2008, ce qui rend le DDL portable entre les principaux moteurs relationnels. C’est le format vers lequel les administrateurs de bases de données et les ingénieurs ETL se tournent lorsqu’ils souhaitent mettre en place un schéma physique conforme à CIM — par exemple, une base de données de staging ou d’intégration qui reflète le modèle canonique.

Choisir un format : un guide pratique

Il n’existe pas de format « correct » unique. Le bon choix est déterminé par qui ou quoi consomme le modèle ensuite. Utilisez le tableau ci-dessous comme aide à la décision.

Si votre consommateur est…	Commencez par…	Parce que…
Un analyste métier ou un modélisateur de données examinant le modèle	Vocabulaire AML (concepts.yaml)	Lisible par l’homme, priorité au vocabulaire métier
Un triple store, un graphe de connaissances ou un outil d’ontologie	JSON-LD (concepts.json, schema.json)	RDF natif avec une rampe d’accès JSON
Un validateur SHACL ou un pipeline sémantique de qualité des données	SHACL (schema.json)	Validation de contraintes standard sur RDF
Une base de données relationnelle existante que vous souhaitez exposer en tant que données liées	R2RML (schema.rdml)	Mappe les tables/colonnes aux entités CIM sans remodelage
Une API REST ou JSON pilotée par événements	JSON Schema (schema.json)	Valide directement les charges utiles JSON
Une base de données relationnelle que vous souhaitez rendre conforme à CIM	SQL DDL (schema.sql)	DDL SQL 2008 portable
Une API décrite par RAML	Types RAML (schema.raml)	Natif des chaînes d’outils RAML

Quelques mises en garde pratiques :

• Ne traitez pas les formats comme des modèles indépendants. Ce sont des sérialisations du même CIM sous-jacent. Si vous trouvez une divergence entre, disons, schema.json (JSON Schema) et schema.json (SHACL), il s’agit d’un bug ou d’un décalage de version, pas d’un choix de conception — signalez-le.
• Attention aux collisions de noms de fichiers. Plusieurs formats partagent le radical schema avec différentes extensions (schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml). Lors du téléchargement de la distribution complète, conservez les répertoires de formats séparés afin de ne pas écraser une sérialisation par une autre.
• Faites correspondre le format à l’étape de validation. Utilisez les formats conceptuels pour la révision lors de la conception et les formats canoniques pour la validation à l’exécution. Valider par rapport au modèle conceptuel n’a pas de sens — il lui manque les contraintes.
• Préférez la génération à l’édition manuelle. Si vous étendez CIM, étendez la source et régénérez les autres sérialisations plutôt que d’éditer chaque format à la main, sinon la famille de formats se désynchronisera.

Téléchargement de la distribution CIM complète

CIM est distribué sous forme de définition complète dans chaque format disponible, vous pouvez donc récupérer l’intégralité du modèle dans la sérialisation dont vous avez besoin plutôt que de l’assembler pièce par pièce. Les options de téléchargement publiées sont :

• AML (vocabulaire) — le modèle conceptuel lisible par l’homme.
• AML (dialecte) — les formes canoniques lisibles par l’homme.
• JSON-LD (vocabulaire et schéma) — le modèle sémantique lisible par machine.
• R2RML — le mappage relationnel vers RDF.
• Types RAML — les formes canoniques en tant que types de données RAML.
• SQL DDL — les formes canoniques en SQL portable.

Chaque téléchargement contient la définition complète du CIM dans ce format, ce qui signifie que vous pouvez adopter le CIM progressivement : commencez par le format pris en charge par votre chaîne d’outils actuelle et ajoutez-en d’autres à mesure que vos besoins d’interopérabilité augmentent.

Contribuer à travers les formats

Le CIM étant un projet ouvert, les contributions sont les bienvenues — et la structure multiformat façonne le fonctionnement des contributions. Les contributeurs se répartissent généralement en deux groupes :

• Les contributeurs de modèles proposent de nouvelles entités, relations ou contraintes. Ces modifications sont créées une seule fois, puis propagées aux autres sérialisations.
• Les contributeurs de format améliorent la fidélité ou l’outillage d’une sérialisation spécifique — par exemple, en affinant les mappages R2RML ou la portabilité SQL DDL.

Si vous contribuez, la règle pratique est de comprendre quelle couche vous modifiez (conceptuelle vs canonique) et quels formats doivent être régénérés en conséquence. Les référentiels GitHub et le formulaire Web des contributeurs du projet sont les points d’entrée pour s’impliquer.

Questions fréquemment posées

Quelle est la différence entre concepts.json et schema.json dans CIM ?

concepts.json est le modèle conceptuel — les entités et les relations dans CIM, exprimées en JSON-LD avec la sémantique RDF Schema. schema.json est le schéma canonique — les formes de données et les contraintes supplémentaires, exprimées en JSON-LD avec la sémantique SHACL. En bref, concepts décrit ce qui existe ; schema décrit à quoi doit ressembler une instance valide.

Pourquoi le CIM publie-t-il le même modèle dans autant de formats ?

Parce que différents consommateurs utilisent des technologies différentes. Un triple store a besoin de RDF ; une API JSON a besoin de JSON Schema ; un DBA a besoin de SQL DDL ; un analyste métier a besoin de quelque chose de lisible par l’homme. La publication de CIM dans plusieurs formats standards permet à chacun de ces publics d’adopter le modèle avec les outils dont ils disposent déjà, plutôt que d’imposer une seule pile technologique à tout le monde.

À quoi sert R2RML dans CIM ?

R2RML est la norme du W3C pour mapper un schéma de base de données relationnelle à un graphe RDF. Dans CIM, c’est le pont qui expose les bases de données SQL existantes en tant que données liées conformes au CIM, afin que vous puissiez connecter les systèmes relationnels opérationnels à la couche sémantique sans les remodeler manuellement.

L’AML est-il identique aux formats JSON-LD ?

Non. AML est l’expression lisible par l’homme de CIM — le vocabulaire (concepts.yaml) et le dialecte (schema.yaml, schema.raml). JSON-LD est l’expression lisible par machine, basée sur RDF. Ils décrivent le même modèle mais ciblent des publics et des chaînes d’outils différents.

Par quel format CIM dois-je commencer ?

Cela dépend de votre profil d’utilisateur. Si vous examinez le modèle, commencez par le vocabulaire AML. Si vous créez une API JSON, commencez par JSON Schema. Si vous connectez une base de données relationnelle, commencez par R2RML ou SQL DDL. Si vous travaillez avec un graphe de connaissances, commencez par JSON-LD et SHACL.

Puis-je modifier un format CIM sans mettre à jour les autres ?

Vous pouvez, mais vous ne devriez pas. Les formats sont des sérialisations d’un seul modèle sous-jacent, donc la modification manuelle d’un seul format entraîne une désynchronisation de l’ensemble. Étendez le modèle source et régénérez les autres sérialisations à la place.

Lectures complémentaires

• World Wide Web Consortium (W3C) — l’organisme de normalisation derrière RDF, RDF Schema, SHACL et R2RML, les spécifications sur lesquelles s’appuie CIM.
• Shapes Constraint Language (SHACL) — informations générales sur le langage de contraintes utilisé pour les formes de données canoniques du CIM.
• Linux Foundation — la fondation sous laquelle fonctionne le projet CIM.