CIM-Formate

Das Cloud Information Model (CIM) wurde von Anfang an als standardbasiertes, anwendungsunabhängiges Modell von Geschäftskonzepten konzipiert – Kunden, Bestellungen, Produkte, Konten und die Beziehungen zwischen ihnen. Ein konzeptionelles Modell ist jedoch nur dann nützlich, wenn die Systeme, die es benötigen, es tatsächlich nutzen können. Aus diesem Grund wird CIM nicht als einzelnes proprietäres Artefakt veröffentlicht, sondern als eine Familie von Serialisierungen, die jeweils auf eine andere Klasse von Tooling, Laufzeiten und Zielgruppen abzielen.

Auf dieser Seite wird erläutert, was die einzelnen CIM-Formate sind, wozu sie dienen und wie Sie zwischen ihnen wählen können. Wenn Sie ein Unternehmensdatenarchitekt, ein Integrations- oder ETL-Ingenieur, ein Anwendungs- oder Plattformanbieter oder ein Open-Source-Mitwirkender sind, hängt das Format, zu dem Sie zuerst greifen, davon ab, wo in der Pipeline Sie sich befinden.

Wichtige Erkenntnisse

• CIM wird in zwei Familien verteilt: Semantic-Web-Formate (JSON-LD, RDF Schema, SHACL, R2RML) und menschenlesbare/relationale Formate (AML-Vokabular, AML-Dialekt, RAML-Typen, JSON Schema, SQL DDL).
• Das konzeptionelle Modell (concepts.*) beschreibt Entitäten und Beziehungen; das kanonische Schema (schema.*) beschreibt Datenformen und Einschränkungen. Es handelt sich um separate Artefakte mit unterschiedlichen Zwecken.
• JSON-LD ist die kanonische maschinenlesbare Form; AML ist die menschenlesbare Form desselben Inhalts; SQL DDL und JSON Schema sind die Formate, die die meisten Anwendungs- und ETL-Teams direkt nutzen.
• R2RML ist die Brücke: Es bildet ein relationales Schema auf einen RDF-Graphen ab, wodurch bestehende SQL-Datenbanken mit der semantischen Ebene verbunden werden.
• Die Wahl eines Formats ist eine Frage des Konsumenten, nicht der Präferenz – wählen Sie das Format aus, das Ihre Ziel-Toolchain nativ aufnimmt, und verwenden Sie die anderen als Gegenprüfungen.

Warum CIM in mehreren Formaten geliefert wird

Die meisten Datenmodelle werden in genau einer Form veröffentlicht – normalerweise als ER-Diagramm, als Tabellenkalkulation oder als herstellerspezifische Metadatendatei. Das funktioniert so lange, bis Sie das Modell über Organisationen hinweg teilen müssen, die unterschiedliche Stacks verwenden.

Eine Einzelhandelsplattform könnte PostgreSQL und dbt einsetzen; ein Partner könnte eine Graphdatenbank und einen Triple Store betreiben; ein SaaS-Anbieter stellt möglicherweise JSON-APIs bereit und validiert Payloads mit JSON Schema. Wenn das gemeinsame Modell nur in einem dieser Dialekte existiert, müssen alle anderen es übersetzen – und Übersetzungen driften auseinander.

Die Multiformat-Strategie von CIM ist eine bewusste Antwort auf dieses Problem. Das Modell wird einmal erstellt und dann in Formate übersetzt, die sauber auf anerkannte Standards abgebildet werden, sodass jeder Konsument CIM mit Tools einführen kann, die er bereits besitzt.

Dies ist die gleiche Philosophie, die auch Standardisierungsgremien wie dem World Wide Web Consortium (W3C) zugrunde liegt, das Spezifikationen wie RDF, SHACL und R2RML veröffentlicht, die CIM wiederverwendet, anstatt sie neu zu erfinden. Es steht auch im Einklang mit der umfassenderen Interoperabilitätsmission der Linux Foundation, unter der das CIM-Projekt operiert.

Verwandte: Fivetran — Die vollständig verwaltete ELT-Pipeline, die einfach weiterläuft.

Der praktische Vorteil ist zweifach: Unternehmen mit unterschiedlichen Technologien können CIM ohne einen kompletten Austausch („rip-and-replace“) einführen, und Mitwirkende können das Modell in dem Format erweitern, das ihrer Expertise entspricht, im Wissen, dass die anderen Serialisierungen regeneriert werden können.

Das konzeptionelle Modell vs. das kanonische Schema

Vor dem Vergleich von Dateiformaten ist es hilfreich, zwei Ebenen zu trennen, die CIM getrennt hält – und die Neulinge häufig vermischen.

• Das konzeptionelle Modell beantwortet, was existiert und wie es zusammenhängt. Es definiert Entitäten (Kunde, Bestellung, Produkt), ihre Attribute und die Beziehungen zwischen ihnen. Es orientiert sich bewusst am Geschäftsvokabular und verzichtet bewusst auf physische Details.
• Das kanonische Schema beantwortet, wie eine gültige Instanz aussieht. Es fügt Datenformen und Einschränkungen hinzu – Kardinalität, Typen, erforderliche Felder, Wertebereiche –, gegen die ein System validieren kann.

In der CIM-Distribution werden diese auf zwei Dateinamenstämme abgebildet: concepts.* für die konzeptionelle Ebene und schema.* für die kanonische Ebene. Wenn man sie getrennt hält, kann ein Geschäftsanalyst das konzeptionelle Modell lesen, ohne sich durch die Einschränkungssyntax wühlen zu müssen, während ein Ingenieur Payloads anhand des Schemas validieren kann, ohne die vollständige konzeptionelle Erzählung zu benötigen.

Wenn Sie einkaufen: Boomi AtomSphere — Enterprise iPaaS für die Hybrid-Cloud-to-On-Premise-Integration.

Die Semantic-Web-Formate

Diese Formate drücken CIM als RDF-basierten Graphen aus. Sie sind die richtige Wahl, wenn Ihre Konsumenten Triple Stores, Wissensgraphen, Ontologie-Tooling oder ein beliebiges System sind, das über Linked Data schließt.

JSON-LD — concepts.json und schema.json

JSON-LD ist JSON mit einem Linked-Data-Kontext, was es zur pragmatischen Brücke zwischen gewöhnlichen Web-APIs und dem Semantic Web macht. CIM veröffentlicht zwei JSON-LD-Artefakte:

• concepts.json — die konzeptionelle Beschreibung von Entitäten und Beziehungen, ausgedrückt als RDF Schema.
• schema.json — die kanonischen Datenformen und zusätzlichen Einschränkungen, ausgedrückt in SHACL.

Da es sich um gültiges JSON handelt, können concepts.json und schema.json mit gewöhnlichem JSON-Tooling geladen werden, aber da sie einen @context tragen, lassen sie sich auch zu vollständigen RDF-Triples erweitern. Aufgrund dieser Doppelnatur ist JSON-LD oft die beste Standardwahl für Teams, die semantische Treue wünschen, ohne am ersten Tag einen spezialisierten RDF-Stack einzuführen.

RDF Schema — schema.json

RDF Schema (RDFS) stellt das Vokabular zur Beschreibung von Klassen und Eigenschaften bereit – die Konstrukte rdfs:Class, rdfs:subClassOf sowie rdfs:domain/rdfs:range, die einer Maschine erkennen lassen, dass eine Bestellung ein Geschäftsdokument ist und dass ihre Kundeneigenschaft auf einen Kunden verweist. CIM verwendet RDFS, um dem konzeptionellen Modell eine formale Semantik zu verleihen, sodass Unterklassenhierarchien und Eigenschaftsdomänen maschineninterpretierbar und nicht nur dokumentiert sind.

SHACL — schema.json

Die Shapes Constraint Language (SHACL) ist ein W3C-Standard zur Validierung von RDF-Graphen gegen einen Satz von Bedingungen, sogenannte Shapes. Während RDFS definiert, was eine Klasse ist, definiert SHACL, was eine gültige Instanz erfüllen muss – erforderliche Eigenschaften, zulässige Wertetypen, Kardinalitätsgrenzen. Die kanonischen Datenformen von CIM werden in SHACL ausgedrückt, was bedeutet, dass jeder SHACL-Prozessor CIM-konforme Daten ohne benutzerdefinierten Code validieren kann.

R2RML — schema.rdml

R2RML ist der W3C-Standard zum Mapping eines relationalen Datenbankschemas auf einen RDF-Graphen. Dies ist das Format, das für Integrations- und ETL-Ingenieure am wichtigsten ist, da es der Mechanismus ist, mit dem eine bestehende SQL-Datenbank – mit ihren Tabellen, Spalten und Fremdschlüsseln – als CIM-konforme Linked Data bereitgestellt wird.

Verwandte: Matillion — Push-Down-ELT für Cloud-Data-Warehouses.

Anstatt Ihre operative Datenbank manuell neu zu modellieren, schreiben (oder generieren) Sie ein R2RML-Mapping, das festlegt, wie jede Tabelle und Spalte den CIM-Entitäten und -Eigenschaften entspricht. Das Ergebnis ist ein virtueller RDF-Graph über Ihren vorhandenen relationalen Daten.

Die menschenlesbaren und relationalen Formate

Nicht jeder Konsument möchte RDF. Anwendungsentwickler, Datenmodellierer und DBAs möchten häufig etwas, das sie in einem Texteditor lesen oder direkt in eine Datenbank laden können. CIM stellt ihnen die Serialisierungen AML, RAML, JSON Schema und SQL DDL zur Verfügung.

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

AML, die hier als Modellierungsdialekt verwendete Abstammungslinie der AnyLogic Modeling Language, ist der menschenlesbare Ausdruck von CIM. CIM veröffentlicht drei AML-Artefakte:

Unsere Wahl: Workato — Automatisierungsgesteuertes iPaaS, auf dem Geschäftsteams tatsächlich aufbauen können.

• concepts.yaml — das AML-Vokabular, eine menschenlesbare Version des konzeptionellen Modells.
• schema.yaml — der AML-Dialekt, eine menschenlesbare Version der kanonischen Datenformen.
• schema.raml — die Darstellung der kanonischen Formen als RAML-Datentypen.

Die Unterscheidung zwischen Vokabular und Dialekt ist wichtig: Das Vokabular definiert die Begriffe (die Substantive und Verben des Modells), während der Dialekt definiert, wie diese Begriffe zu gültigen Strukturen kombiniert werden. Wenn Sie CIM zum ersten Mal prüfen, ist concepts.yaml normalerweise der zugänglichste Einstiegspunkt.

JSON Schema — schema.json

JSON Schema ist der De-facto-Standard zur Validierung von JSON-Dokumenten, der nativ oder über Bibliotheken in praktisch jeder modernen Sprache unterstützt wird. Das JSON-Schema-Artefakt von CIM drückt die kanonischen Datenformen als JSON Schema aus, wodurch es direkt in API-Gateways, Message-Brokern und CI-Pipelines einsetzbar ist, die bereits JSON-Payloads validieren. Wenn Ihre Integrationsfläche REST oder ereignisgesteuertes JSON ist, ist dies oft das gewünschte Format.

SQL DDL — schema.sql

SQL DDL ist die Menge an CREATE TABLE, CREATE VIEW und Constraint-Statements, die die kanonischen Formen in einer relationalen Datenbank materialisieren. CIM zielt auf die SQL 2008-Syntax ab, wodurch die DDL über die wichtigsten relationalen Engines portabel bleibt. Dies ist das Format, zu dem DBAs und ETL-Ingenieure greifen, wenn sie ein physisches Schema aufbauen wollen, das CIM entspricht – zum Beispiel eine Staging- oder Integrationsdatenbank, die das kanonische Modell widerspiegelt.

Ein Format auswählen: Ein praktischer Leitfaden

Es gibt kein einzelnes „richtiges“ Format. Die richtige Wahl hängt davon ab, wer oder was das Modell als Nächstes konsumiert. Nutzen Sie die folgende Tabelle als Entscheidungshilfe.

Wenn Ihr Konsument…	Beginnen Sie mit…	Weil…
Ein Business-Analyst oder Datenmodellierer, der das Modell prüft	AML-Vokabular (concepts.yaml)	Menschenlesbar, Business-Vokabular zuerst
Ein Triple Store, Knowledge Graph oder Ontologie-Tool	JSON-LD (concepts.json, schema.json)	Natives RDF mit JSON-On-Ramp
Ein SHACL-Validator oder eine semantische Datenqualitätspipeline	SHACL (schema.json)	Standard-Constraint-Validierung über RDF
Eine vorhandene relationale Datenbank, die Sie als Linked Data bereitstellen möchten	R2RML (schema.rdml)	Mappt Tabellen/Spalten auf CIM-Entitäten ohne Neumodellierung
Eine REST- oder ereignisgesteuerte JSON-API	JSON Schema (schema.json)	Validiert JSON-Payloads direkt
Eine relationale Datenbank, die CIM entsprechen soll	SQL DDL (schema.sql)	Portable SQL 2008 DDL
Eine RAML-beschriebene API	RAML-Typen (schema.raml)	Native für RAML-Toolchains

Ein paar praktische Vorbehalte:

• Behandeln Sie die Formate nicht als unabhängige Modelle. Sie sind Serialisierungen desselben zugrunde liegenden CIM. Wenn Sie eine Diskrepanz beispielsweise zwischen schema.json (JSON Schema) und schema.json (SHACL) finden, ist dies ein Fehler oder ein Versionsunterschied, keine Designentscheidung – bitte melden Sie dies.
• Achten Sie auf Dateinamenkollisionen. Mehrere Formate teilen sich den Stamm schema mit unterschiedlichen Erweiterungen (schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml). Halten Sie beim Herunterladen der vollständigen Distribution die Formatverzeichnisse getrennt, damit Sie nicht eine Serialisierung durch eine andere überschreiben.
• Passen Sie das Format an die Validierungsphase an. Verwenden Sie die konzeptionellen Formate für die Prüfung während der Designzeit und die kanonischen Formate für die Laufzeitvalidierung. Eine Validierung gegen das konzeptionelle Modell ist nicht sinnvoll, da ihr die Constraints fehlen.
• Bevorzugen Sie generierte gegenüber manuell bearbeiteten Formaten. Wenn Sie CIM erweitern, erweitern Sie die Quelle und generieren Sie die anderen Serialisierungen neu, anstatt jedes Format von Hand zu bearbeiten, da sonst die Formate asynchron werden.

Herunterladen der vollständigen CIM-Distribution

CIM wird als vollständige Definition in jedem verfügbaren Format verteilt, sodass Sie das gesamte Modell in der benötigten Serialisierung herunterladen können, anstatt es Stück für Stück zusammenzusetzen. Die veröffentlichten Download-Optionen sind:

• AML (vocabulary) — das für Menschen lesbare konzeptionelle Modell.
• AML (dialect) — die für Menschen lesbaren kanonischen Formen.
• JSON-LD (vocabulary & schema) — das maschinenlesbare semantische Modell.
• R2RML — das Relational-to-RDF-Mapping.
• RAML Types — die kanonischen Formen als RAML-Datentypen.
• SQL DDL — die kanonischen Formen als portables SQL.

Jeder Download enthält die vollständige CIM-Definition in diesem Format, was bedeutet, dass Sie CIM schrittweise übernehmen können: Beginnen Sie mit dem Format, das Ihre aktuelle Toolchain unterstützt, und fügen Sie weitere hinzu, wenn Ihre Interoperabilitätsanforderungen wachsen.

Mitwirken über Formate hinweg

Da CIM ein offenes Projekt ist, sind Beiträge willkommen – und die Multiformat-Struktur prägt die Funktionsweise der Beiträge. Mitwirkende lassen sich typischerweise in zwei Gruppen einteilen:

• Modell-Mitwirkende schlagen neue Entitäten, Beziehungen oder Einschränkungen vor. Diese Änderungen werden einmal erstellt und dann auf die anderen Serialisierungen übertragen.
• Format-Mitwirkende verbessern die Wiedergabetreue oder das Tooling einer bestimmten Serialisierung – zum Beispiel durch die Verfeinerung der R2RML-Mappings oder der SQL-DDL-Portabilität.

Wenn Sie einen Beitrag leisten, besteht die praktische Regel darin, zu verstehen, welche Ebene Sie ändern (konzeptionell vs. kanonisch) und welche Formate als Ergebnis neu generiert werden müssen. Die GitHub-Repositories und das Mitwirkenden-Webformular des Projekts sind die Einstiegspunkte für die Beteiligung.

Häufig gestellte Fragen

Was ist der Unterschied zwischen concepts.json und schema.json in CIM?

concepts.json ist das konzeptionelle Modell – die Entitäten und Beziehungen in CIM, ausgedrückt als JSON-LD mit RDF-Schema-Semantik. schema.json ist das kanonische Schema – die Datenformen und zusätzlichen Einschränkungen, ausgedrückt als JSON-LD mit SHACL-Semantik. Kurz gesagt: concepts beschreibt, was existiert; schema beschreibt, wie eine gültige Instanz aussehen muss.

Warum veröffentlicht CIM das gleiche Modell in so vielen Formaten?

Weil unterschiedliche Konsumenten unterschiedliche Technologien verwenden. Ein Triple-Store benötigt RDF; eine JSON-API benötigt JSON Schema; ein DBA benötigt SQL DDL; ein Business-Analyst benötigt etwas für Menschen Lesbares. Die Veröffentlichung von CIM in mehreren Standardformaten ermöglicht es jeder dieser Zielgruppen, das Modell mit Tools zu übernehmen, die sie bereits besitzen, anstatt jedem einen einzigen Stack aufzuzwingen.

Wofür wird R2RML in CIM verwendet?

R2RML ist der W3C-Standard für das Mapping eines relationalen Datenbankschemas auf einen RDF-Graphen. In CIM ist es die Brücke, die vorhandene SQL-Datenbanken als CIM-konforme Linked Data verfügbar macht, sodass Sie operative relationale Systeme mit der semantischen Ebene verbinden können, ohne sie manuell neu zu modellieren.

Ist AML dasselbe wie die JSON-LD-Formate?

Nein. AML ist der für Menschen lesbare Ausdruck von CIM – das Vokabular (concepts.yaml) und der Dialekt (schema.yaml, schema.raml). JSON-LD ist der maschinenlesbare, RDF-basierte Ausdruck. Sie beschreiben dasselbe Modell, richten sich jedoch an unterschiedliche Zielgruppen und Toolchains.

Mit welchem CIM-Format soll ich beginnen?

Das hängt von Ihrem Konsumenten ab. Wenn Sie das Modell überprüfen, beginnen Sie mit dem AML-Vokabular. Wenn Sie eine JSON-API erstellen, beginnen Sie mit JSON Schema. Wenn Sie eine relationale Datenbank anbinden, beginnen Sie mit R2RML oder SQL DDL. Wenn Sie mit einem Knowledge Graph arbeiten, beginnen Sie mit JSON-LD und SHACL.

Kann ich ein CIM-Format bearbeiten, ohne die anderen zu aktualisieren?

Sie können es, aber Sie sollten es nicht. Die Formate sind Serialisierungen eines einzigen zugrunde liegenden Modells, sodass die manuelle Bearbeitung eines einzelnen Formats dazu führt, dass die Familie asynchron wird. Erweitern Sie stattdessen das Quellmodell und generieren Sie die anderen Serialisierungen neu.

Weiterführende Literatur

• World Wide Web Consortium (W3C) — das Standardisierungsgremium hinter RDF, RDF Schema, SHACL und R2RML, den Spezifikationen, auf denen CIM aufbaut.
• Shapes Constraint Language (SHACL) — Hintergrundinformationen zur Constraint-Sprache, die für die kanonischen Datenformen von CIM verwendet wird.
• Linux Foundation — die Stiftung, unter deren Dach das CIM-Projekt operiert.