CIM-format

(CIM) designades från början som en standardbaserad, applikationsagnostisk modell av affärskoncept – kunder, order, produkter, konton och relationerna mellan dem. Men en konceptuell modell är bara användbar om de system som behöver den faktiskt kan konsumera den. Det är därför CIM inte publiceras som en enda proprietär artefakt utan som en familj av serialiseringar, där varje serialisering riktar sig mot en annan klass av verktyg, körtid och publik.

Den här sidan förklarar vad varje CIM-format är, vad det är till för och hur man väljer mellan dem. Om du är en företagsdataarkitekt, en integrations- eller ETL-ingenjör, en applikations- eller plattformsleverantör eller en bidragsgivare med öppen källkod, beror formatet du väljer först på var i pipelinen du befinner dig.

Viktiga slutsatser

• CIM distribueras i två familjer: semantiska webbformat (JSON-LD, RDF Schema, SHACL, R2RML) och mänskligt läsbara/relationella format (AML-vokabulär, AML-dialekt, RAML-typer, JSON Schema, SQL DDL).
• Den konceptuella modellen (concepts.*) beskriver entiteter och relationer; det kanoniska schemat (schema.*) beskriver dataformer och begränsningar. De är separata artefakter med separata syften.
• JSON-LD är den kanoniska maskinläsbara formen; AML är den mänskligt läsbara formen av samma innehåll; SQL DDL och JSON Schema är de format som de flesta applikations- och ETL-team konsumerar direkt.
• R2RML är bryggan: den mappar ett relationsschema till en RDF-graf, vilket är så du kopplar befintliga SQL-databaser till det semantiska lagret.
• Att välja ett format är en fråga om konsument, inte preferens — välj det som din målverktygskedja hanterar nativt, och använd de andra som kontrollkontroller.

Varför CIM levereras i flera format

De flesta datamodeller publiceras i exakt en form – vanligtvis ett ER-diagram, ett kalkylblad eller en leverantörsspecifik metadatafil. Det fungerar tills du behöver dela modellen mellan organisationer som använder olika stackar.

En detaljhandelsplattform kan köra PostgreSQL och dbt; en partner kan köra en grafdatabas och en triple store; en SaaS-leverantör kan exponera JSON-API:er och validera nyttolaster med JSON Schema. Om den delade modellen bara finns i en av dessa dialekter måste alla andra översätta den – och översättningar tenderar att glida isär.

CIM:s multiformatstrategi är ett medvetet svar på det problemet. Modellen skapas en gång och översätts sedan till format som mappar rent mot erkända standarder, så att varje konsument kan använda CIM med verktyg som de redan har.

Detta är samma filosofi som bakom standardiseringsorgan som World Wide Web Consortium (W3C), som publicerar specifikationer som RDF, SHACL och R2RML som CIM återanvänder snarare än återuppfinner. Det ligger också i linje med det bredare interoperabilitetsuppdraget för Linux Foundation, under vilket CIM-projektet verkar.

Relaterat: Fivetran — Den fullt hanterade ELT-pipelinen som bara fortsätter att köras.

Den praktiska fördelen är tvåfaldig: företag med olika teknologier kan anta CIM utan att behöva byta ut hela sin miljö (“rip-and-replace”), och bidragsgivare kan utöka modellen i det format som matchar deras expertis, med vetskapen om att de andra serialiseringarna kan regenereras.

Den konceptuella modellen vs det kanoniska schemat

Innan man jämför filformat hjälper det att separera två lager som CIM håller åtskilda – och som nykomlingar ofta blandar ihop.

• Den konceptuella modellen svarar på vad som finns och hur det relaterar. Den definierar entiteter (Customer, Order, Product), deras attribut och relationerna mellan dem. Den är avsiktligt nära affärsvokabulären och medvetet knapphändig med fysiska detaljer.
• Det kanoniska schemat svarar på hur en giltig instans ser ut. Det lägger till dataformer och begränsningar – kardinalitet, typer, obligatoriska fält, värdeintervall – som ett system kan validera mot.

I CIM-distributionen mappas dessa till två filnamnsstammar: concepts.* för det konceptuella lagret och schema.* för det kanoniska lagret. Att hålla dem åtskilda innebär att en affärsanalytiker kan läsa den konceptuella modellen utan att behöva plöja igenom begränsningssyntax, medan en ingenjör kan validera nyttolaster mot schemat utan att behöva hela den konceptuella berättelsen.

Om du handlar: Boomi AtomSphere — Enterprise iPaaS för hybrid moln-till-på-prem-integration.

De semantiska webbformaten

Dessa format uttrycker CIM som en RDF-baserad graf. De är det rätta valet när dina konsumenter inkluderar triple stores, kunskapsgrafer, ontologiverktyg eller vilket system som helst som resonerar över länkade data.

JSON-LD — concepts.json och schema.json

JSON-LD är JSON med en länkad datakontext, vilket gör det till den pragmatiska bryggan mellan vanliga webb-API:er och den semantiska webben. CIM publicerar två JSON-LD-artefakter:

• concepts.json — den konceptuella beskrivningen av entiteter och relationer, uttryckt som RDF Schema.
• schema.json — de kanoniska dataformerna och ytterligare begränsningar, uttryckta i SHACL.

Eftersom det är giltig JSON kan concepts.json och schema.json laddas med vanliga JSON-verktyg, men eftersom de bär en @context expanderar de även till fullständiga RDF-tripplar. Denna dubbla natur är anledningen till att JSON-LD ofta är det bästa standardvalet för team som vill ha semantisk trohet utan att behöva anta en specialiserad RDF-stack från dag ett.

RDF Schema — schema.json

RDF Schema (RDFS) tillhandahåller vokabulären för att beskriva klasser och egenskaper – konstruktionerna rdfs:Class, rdfs:subClassOf och rdfs:domain/rdfs:range som låter en maskin förstå att en Order är ett affärsdokument och att dess kundegenskap pekar på en Customer. CIM använder RDFS för att ge den konceptuella modellen formell semantik, så att subklasshierarkier och egenskapsdomäner är maskintolkbara snarare än bara dokumenterade.

SHACL — schema.json

Shapes Constraint Language (SHACL) är en W3C-standard för att validera RDF-grafer mot en uppsättning villkor som kallas former (shapes). Där RDFS anger vad en klass är, anger SHACL vad en giltig instans måste uppfylla — obligatoriska egenskaper, tillåtna värdetyper och kardinalitetsgränser. CIM:s kanoniska dataformer uttrycks i SHACL, vilket innebär att vilken SHACL-processor som helst kan validera CIM-kompatibla data utan anpassad kod.

R2RML — schema.rdml

R2RML är W3C-standarden för att mappa ett relationsdatabasschema till en RDF-graf. Detta är det format som är viktigast för integrations- och ETL-ingenjörer, eftersom det är mekanismen genom vilken en befintlig SQL-databas – med dess tabeller, kolumner och främmande nycklar – exponeras som CIM-kompatibla länkade data.

Relaterat: Matillion — Push-down ELT byggd för molndatalager.

Istället för att ommodellera din operativa databas för hand, skriver (eller genererar) du en R2RML-mappning som deklarerar hur varje tabell och kolumn motsvarar CIM-enheter och egenskaper. Resultatet är en virtuell RDF-graf över dina befintliga relationsdata.

De mänskligt läsbara och relationella formaten

Inte alla konsumenter vill ha RDF. Applikationsutvecklare, datamodellerare och DBA:er vill ofta ha något de kan läsa i en textredigerare eller ladda direkt in i en databas. CIM tillhandahåller serialiseringar i AML, RAML, JSON Schema och SQL DDL.

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

AML, här använd som en modelleringsdialekt baserad på AnyLogic Modeling Language, är det mänskligt läsbara uttrycket för CIM. CIM publicerar tre AML-artefakter:

Vårt val: Workato — Automationsledd iPaaS som affärsteam faktiskt kan bygga på.

• concepts.yaml — AML-vokabulären, en mänskligt läsbar version av den konceptuella modellen.
• schema.yaml — AML-dialekten, en mänskligt läsbar version av de kanoniska dataformerna.
• schema.raml — en rendering av de kanoniska formerna som RAML-datatyper.

Skillnaden mellan vokabulär och dialekt är viktig att förstå: vokabulären definierar termerna (modellens substantiv och verb), medan dialekten definierar hur dessa termer kombineras till giltiga strukturer. Om du granskar CIM för första gången är concepts.yaml vanligtvis den mest lättillgängliga ingångspunkten.

JSON Schema — schema.json

JSON Schema är de facto-standarden för att validera JSON-dokument och stöds inbyggt eller via bibliotek i praktiskt taget alla moderna språk. CIM:s JSON Schema-artefakt uttrycker de kanoniska dataformerna som JSON Schema, vilket gör det direkt användbart i API-gateways, meddelandemäklare och CI-pipelines som redan validerar JSON-nyttolaster. Om din integrationsyta är REST eller händelsedriven JSON är detta ofta det format du vill ha.

SQL DDL — schema.sql

SQL DDL är uppsättningen CREATE TABLE, CREATE VIEW och begränsningssatser (constraints) som materialiserar de kanoniska formerna i en relationsdatabas. CIM riktar in sig på SQL 2008-syntax, vilket gör DDL portabelt över de stora relationsmotorerna. Detta är formatet som DBA:er och ETL-ingenjörer använder när de vill sätta upp ett fysiskt schema som överensstämmer med CIM — till exempel en staging- eller integrationsdatabas som speglar den kanoniska modellen.

Välja ett format: En praktisk guide

Det finns inget enskilt “korrekt” format. Rätt val avgörs av vem eller vad som konsumerar modellen härnäst. Använd tabellen nedan som beslutshjälp.

Om din konsument är…	Börja med…	Eftersom…
En affärsanalytiker eller datamodellerare som granskar modellen	AML-vokabulär (concepts.yaml)	Mänskligt läsbar, affärsvokabulär i fokus
En trippelbutik (triple store), kunskapsgraf eller ontologiverktyg	JSON-LD (concepts.json, schema.json)	Native RDF med en JSON-ingång
En SHACL-validator eller semantisk datakvalitetspipeline	SHACL (schema.json)	Standardiserad begränsningsvalidering över RDF
En befintlig relationsdatabas som du vill exponera som länkade data	R2RML (schema.rdml)	Mappar tabeller/kolumner till CIM-enheter utan ommodellering
Ett REST- eller händelsedrivet JSON-API	JSON Schema (schema.json)	Validerar JSON-nyttolaster direkt
En relationsdatabas som du vill anpassa till CIM	SQL DDL (schema.sql)	Portabel SQL 2008 DDL
Ett RAML-beskrivet API	RAML-typer (schema.raml)	Native för RAML-verktygskedjor

Några praktiska varningar:

• Behandla inte formaten som oberoende modeller. De är serialiseringar av samma underliggande CIM. Om du hittar en diskrepans mellan till exempel schema.json (JSON Schema) och schema.json (SHACL), är det en bugg eller en versionsskillnad, inte ett designval — rapportera det.
• Var uppmärksam på filnamnskollisioner. Flera format delar stammen schema med olika tillägg (schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml). När du laddar ner hela distributionen, håll formatkatalogerna åtskilda så att du inte skriver över en serialisering med en annan.
• Matcha formatet med valideringsstadiet. Använd de konceptuella formaten för granskning under designfasen och de kanoniska formaten för validering under körning (runtime). Att validera mot den konceptuella modellen är inte meningsfullt eftersom den saknar begränsningarna.
• Föredra genererat framför handredigerat. Om du utökar CIM, utöka källan och generera om de andra serialiseringarna istället för att redigera varje format för hand, annars kommer de att glida isär.

Ladda ner hela CIM-distributionen

CIM distribueras som en komplett definition i varje tillgängligt format, så att du kan hämta hela modellen i den serialisering du behöver istället för att sätta ihop den bit för bit. De publicerade nedladdningsalternativen är:

• AML (vokabulär) — den mänskligt läsbara konceptuella modellen.
• AML (dialekt) — de mänskligt läsbara kanoniska formerna.
• JSON-LD (vokabulär & schema) — den maskinläsbara semantiska modellen.
• R2RML — mappningen från relationell till RDF.
• RAML-typer — de kanoniska formerna som RAML-datatyper.
• SQL DDL — de kanoniska formerna som portabel SQL.

Varje nedladdning innehåller den fullständiga CIM-definitionen i det formatet, vilket innebär att du kan införa CIM stegvis: börja med det format som din nuvarande verktygskedja stöder och lägg till andra i takt med att dina interoperabilitetsbehov växer.

Bidra över format

Eftersom CIM är ett öppet projekt är bidrag välkomna – och strukturen med flera format formar hur bidragen fungerar. Bidragsgivare delas vanligtvis in i två grupper:

• Modellbidragsgivare föreslår nya entiteter, relationer eller begränsningar. Dessa ändringar skapas en gång och propageras sedan till de andra serialiseringarna.
• Formatbidragsgivare förbättrar precisionen eller verktygen för en specifik serialisering – till exempel genom att förfina R2RML-mappningarna eller portabiliteten i SQL DDL.

Om du bidrar är den praktiska regeln att förstå vilket lager du ändrar (konceptuellt vs. kanoniskt) och vilka format som måste regenereras som ett resultat. Projektets GitHub-arkiv och webbformulär för bidragsgivare är startpunkterna för att engagera sig.

Vanliga frågor

Vad är skillnaden mellan concepts.json och schema.json i CIM?

concepts.json är den konceptuella modellen — entiteterna och relationerna i CIM, uttryckta som JSON-LD med RDF Schema-semantik. schema.json är det kanoniska schemat — dataformerna och ytterligare begränsningar, uttryckta som JSON-LD med SHACL-semantik. Kort sagt beskriver concepts vad som finns; schema beskriver hur en giltig instans måste se ut.

Varför publicerar CIM samma modell i så många format?

Eftersom olika konsumenter använder olika tekniker. En triple store behöver RDF; ett JSON-API behöver JSON Schema; en DBA behöver SQL DDL; en affärsanalytiker behöver något mänskligt läsbart. Genom att publicera CIM i flera standardformat kan var och en av dessa målgrupper anta modellen med verktyg de redan har, istället för att tvinga på alla en enda teknikstack.

Vad används R2RML till i CIM?

R2RML är W3C-standarden för att mappa ett relationsdatabasschema till en RDF-graf. I CIM är det bryggan som exponerar befintliga SQL-databaser som CIM-konform länkad data, så att du kan koppla operativa relationssystem till det semantiska lagret utan att behöva ommodellera dem för hand.

Är AML samma sak som JSON-LD-formaten?

Nej. AML är det mänskligt läsbara uttrycket för CIM – vokabulären (concepts.yaml) och dialekten (schema.yaml, schema.raml). JSON-LD är det maskinläsbara, RDF-baserade uttrycket. De beskriver samma modell men riktar sig till olika målgrupper och verktygskedjor.

Vilket CIM-format ska jag börja med?

Det beror på din konsument. Om du granskar modellen, börja med AML-vokabulären. Om du bygger ett JSON-API, börja med JSON Schema. Om du ansluter en relationsdatabas, börja med R2RML eller SQL DDL. Om du arbetar med en kunskapsgraf, börja med JSON-LD och SHACL.

Kan jag redigera ett CIM-format utan att uppdatera de andra?

Du kan, men du bör inte. Formaten är serialiseringar av en och samma underliggande modell, så att redigera ett enskilt format för hand gör att de hamnar i otakt. Utöka källmodellen och regenerera de andra serialiseringarna istället.

Ytterligare läsning

• World Wide Web Consortium (W3C) — standardiseringsorganet bakom RDF, RDF Schema, SHACL och R2RML, de specifikationer som CIM bygger på.
• Shapes Constraint Language (SHACL) — bakgrund om det begränsningsspråk som används för CIM:s kanoniska dataformer.
• Linux Foundation — stiftelsen under vilken CIM-projektet verkar.