CIM-formater

(CIM) blev fra starten designet som en standardbaseret, applikations-agnostisk model for forretningskoncepter — kunder, ordrer, produkter, konti og relationerne mellem dem. Men en konceptuel model er kun nyttig, hvis de systemer, der har brug for den, faktisk kan forbruge den. Det er grunden til, at CIM ikke udgives som en enkelt proprietær artefakt, men som en familie af serialiseringer, der hver er rettet mod en anden klasse af værktøjer, runtime og målgrupper.

Denne side forklarer, hvad hvert CIM-format er, hvad det bruges til, og hvordan man vælger imellem dem. Hvis du er enterprise-dataarkitekt, integrations- eller ETL-ingeniør, applikations- eller platformleverandør eller open source-bidragyder, afhænger det format, du rækker ud efter først, af, hvor i pipelinen du befinder dig.

Key Takeaways

• CIM distribueres i to familier: semantic-web-formater (JSON-LD, RDF Schema, SHACL, R2RML) og menneskelæselige/relationelle formater (AML vocabulary, AML dialect, RAML types, JSON Schema, SQL DDL).
• Den konceptuelle model (concepts.*) beskriver entiteter og relationer; det kanoniske skema (schema.*) beskriver dataformer og begrænsninger. De er separate artefakter med separate formål.
• JSON-LD er den kanoniske maskinlæsbare form; AML er den menneskelæselige form af det samme indhold; SQL DDL og JSON Schema er de former, som de fleste applikations- og ETL-teams forbruger direkte.
• R2RML er broen: den mapper et relationelt skema til en RDF-graf, hvilket er måden, man forbinder eksisterende SQL-databaser til det semantiske lag på.
• Valg af format er et spørgsmål om forbruger, ikke præference — vælg det, som din målværktøjskæde indlæser nativt, og brug de andre som krydstjek.

Hvorfor CIM leveres i flere formater

De fleste datamodeller udgives i nøjagtig én form — normalt et ER-diagram, et regneark eller en leverandørspecifik metadatafil. Det fungerer, indtil man skal dele modellen på tværs af organisationer, der bruger forskellige stacks.

En detailplatform kører måske PostgreSQL og dbt; en partner kører måske en grafdatabase og en triple store; en SaaS-leverandør eksponerer måske JSON-API’er og validerer payloads med JSON Schema. Hvis den fælles model kun eksisterer i én af disse dialekter, skal alle andre oversætte den — og oversættelser driver fra hinanden.

CIM’s multiformat-strategi er et bevidst svar på dette problem. Modellen forfattes én gang og bliver derefter oversat til formater, der mapper rent over på anerkendte standarder, så hver forbruger kan adoptere CIM ved hjælp af værktøjer, de allerede har.

Dette er den samme filosofi, som ligger bag standardiseringsorganer såsom World Wide Web Consortium (W3C), der udgiver specifikationer som RDF, SHACL og R2RML, som CIM genbruger frem for at genopfinde. Det stemmer også overens med den bredere interoperabilitetsmission for Linux Foundation, som CIM-projektet opererer under.

Relateret: Fivetran — Den fuldt administrerede ELT-pipeline, der bare bliver ved med at køre.

Den praktiske fordel er todelt: Virksomheder med forskellige teknologier kan adoptere CIM uden en “rip-and-replace”, og bidragydere kan udvide modellen i det format, der matcher deres ekspertise, i vished om, at de andre serialiseringer kan regenereres.

Den konceptuelle model vs. det kanoniske skema

Før man sammenligner filformater, hjælper det at adskille to lag, som CIM holder adskilt — og som nytilkomne ofte forveksler.

• Den konceptuelle model svarer på, hvad der eksisterer, og hvordan det relaterer. Den definerer entiteter (Customer, Order, Product), deres attributter og relationerne mellem dem. Den er bevidst tæt på forretningssproget og bevidst let på fysiske detaljer.
• Det kanoniske skema svarer på, hvordan en gyldig instans ser ud. Det tilføjer dataformer og begrænsninger — kardinalitet, typer, påkrævede felter, værdiintervaller — som et system kan validere imod.

I CIM-distributionen mapper disse til to filnavnestammer: concepts.* for det konceptuelle lag og schema.* for det kanoniske lag. At holde dem adskilt betyder, at en forretningsanalytiker kan læse den konceptuelle model uden at skulle vade gennem begrænsningssyntaks, mens en ingeniør kan validere payloads mod skemaet uden at have brug for den fulde konceptuelle fortælling.

Hvis du handler: Boomi AtomSphere — Enterprise iPaaS til hybrid cloud-to-on-prem integration.

De semantiske web-formater

Disse formater udtrykker CIM som en RDF-baseret graf. De er det rigtige valg, når dine forbrugere inkluderer triple stores, vidensgrafer, ontologiværktøjer eller ethvert system, der ræsonnerer over linkede data.

JSON-LD — concepts.json og schema.json

JSON-LD er JSON med en linked-data-kontekst, hvilket gør det til den pragmatiske bro mellem almindelige web-API’er og det semantiske web. CIM udgiver to JSON-LD-artefakter:

• concepts.json — den konceptuelle beskrivelse af entiteter og relationer, udtrykt som RDF Schema.
• schema.json — de kanoniske dataformer og yderligere begrænsninger, udtrykt i SHACL.

Fordi det er gyldig JSON, kan concepts.json og schema.json indlæses af almindelige JSON-værktøjer, men fordi de bærer en @context, kan de også udvides til fulde RDF-tripler. Denne dobbelte natur er grunden til, at JSON-LD ofte er det bedste standardvalg for teams, der ønsker semantisk troskab uden at skulle adoptere en specialiseret RDF-stack fra dag ét.

RDF Schema — schema.json

RDF Schema (RDFS) leverer ordforrådet til at beskrive klasser og egenskaber — rdfs:Class, rdfs:subClassOf og rdfs:domain/rdfs:range-konstruktionerne, der lader en maskine forstå, at en Order er et forretningsdokument, og at dens customer-egenskab peger på en Customer. CIM bruger RDFS til at give den konceptuelle model formel semantik, så underklassehierarkier og egenskabsdomæner er maskinelt fortolkelige frem for blot at være dokumenterede.

SHACL — schema.json

Shapes Constraint Language (SHACL) er en W3C-standard til validering af RDF-grafer mod et sæt betingelser kaldet shapes. Hvor RDFS siger, hvad en klasse er, siger SHACL, hvad en gyldig instans skal opfylde — påkrævede egenskaber, tilladte værdityper, kardinalitetsgrænser. CIM’s kanoniske data-shapes er udtrykt i SHACL, hvilket betyder, at enhver SHACL-processor kan validere CIM-konforme data uden brugerdefineret kode.

R2RML — schema.rdml

R2RML er W3C-standarden til at kortlægge et relationelt databaseskema til en RDF-graf. Dette er det format, der betyder mest for integrations- og ETL-ingeniører, fordi det er den mekanisme, hvorved en eksisterende SQL-database — med dens tabeller, kolonner og fremmednøgler — eksponeres som CIM-konforme linkede data.

Relateret: Matillion — Push-down ELT bygget til cloud-datavarehuse.

I stedet for at ommodellere din operationelle database manuelt, skriver (eller genererer) du en R2RML-mapping, der erklærer, hvordan hver tabel og kolonne svarer til CIM-enheder og egenskaber. Resultatet er en virtuel RDF-graf over dine eksisterende relationelle data.

De menneskeligt læsbare og relationelle formater

Ikke alle forbrugere ønsker RDF. Applikationsudviklere, datamodeller og DBA’er ønsker ofte noget, de kan læse i en teksteditor eller indlæse direkte i en database. CIM betjener dem med AML-, RAML-, JSON Schema- og SQL DDL-serialiseringerne.

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

AML, AnyLogic Modeling Language-slægten, der bruges her som en modelleringsdialekt, er det menneskeligt læsbare udtryk for CIM. CIM udgiver tre AML-artefakter:

Læsernes favorit: Airbyte — Open source ELT med en administreret cloud-mulighed.

• concepts.yaml — AML ordforrådet, en menneskeligt læsbar version af den konceptuelle model.
• schema.yaml — AML dialekten, en menneskeligt læsbar version af de kanoniske data-shapes.
• schema.raml — RAML-datatypernes gengivelse af de kanoniske shapes.

Sondringen mellem ordforråd og dialekt er værd at internalisere: ordforrådet definerer begreberne (modellens navneord og verber), mens dialekten definerer, hvordan disse begreber kombineres til gyldige strukturer. Hvis du gennemgår CIM for første gang, er concepts.yaml normalt det mest tilgængelige indgangspunkt.

JSON Schema — schema.json

JSON Schema er de facto-standarden til validering af JSON-dokumenter, understøttet indbygget eller via biblioteker i stort set alle moderne sprog. CIM’s JSON Schema-artefakt udtrykker de kanoniske data-shapes som JSON Schema, hvilket gør det direkte brugbart i API-gateways, message brokers og CI-pipelines, der allerede validerer JSON-payloads. Hvis din integrationsflade er REST eller begivenhedsdrevet JSON, er det ofte det format, du ønsker.

SQL DDL — schema.sql

SQL DDL er sættet af CREATE TABLE, CREATE VIEW og constraint-statements, der materialiserer de kanoniske shapes i en relationel database. CIM retter sig mod SQL 2008-syntaksen, hvilket holder DDL-koden bærbar på tværs af de store relationelle motorer. Dette er det format, som DBA’er og ETL-ingeniører rækker ud efter, når de ønsker at oprette et fysisk skema, der er konformt med CIM — for eksempel en staging- eller integrationsdatabase, der afspejler den kanoniske model.

Valg af format: En praktisk vejledning

Der findes ikke ét enkelt “korrekt” format. Det rigtige valg afgøres af, hvem eller hvad der forbruger modellen næste gang. Brug nedenstående tabel som beslutningshjælp.

Hvis din forbruger er…	Start med…	Fordi…
En forretningsanalytiker eller datamodeller, der gennemgår modellen	AML-ordforråd (concepts.yaml)	Menneskeligt læsbart, business-vokabular-først
En triple store, vidensgraf eller ontologiværktøj	JSON-LD (concepts.json, schema.json)	Native RDF med en JSON on-ramp
En SHACL-validator eller semantisk datakvalitetspipeline	SHACL (schema.json)	Standard constraint-validering over RDF
En eksisterende relationel database, du vil eksponere som linkede data	R2RML (schema.rdml)	Mapper tabeller/kolonner til CIM-enheder uden ommodellering
En REST- eller begivenhedsdrevet JSON API	JSON Schema (schema.json)	Validerer JSON-payloads direkte
En relationel database, du ønsker skal være konform med CIM	SQL DDL (schema.sql)	Bærbar SQL 2008 DDL
En RAML-beskrevet API	RAML-typer (schema.raml)	Native til RAML-værktøjskæder

Et par praktiske forbehold:

• Behandl ikke formaterne som uafhængige modeller. De er serialiseringer af den samme underliggende CIM. Hvis du finder en uoverensstemmelse mellem f.eks. schema.json (JSON Schema) og schema.json (SHACL), er det en fejl eller en versionsforskel, ikke et designvalg — rapporter det.
• Vær opmærksom på filnavnekollisioner. Flere formater deler stammen schema med forskellige udvidelser (schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml). Når du downloader den fulde distribution, skal du holde formatmapperne adskilt, så du ikke overskriver én serialisering med en anden.
• Match formatet til valideringsstadiet. Brug de konceptuelle formater til design-time review og de kanoniske formater til runtime-validering. Validering mod den konceptuelle model er ikke meningsfuld — den mangler constraints.
• Foretræk genererede frem for håndredigerede. Hvis du udvider CIM, skal du udvide kilden og regenerere de andre serialiseringer i stedet for at redigere hvert format manuelt, ellers vil familien glide ud af sync.

Download af den fulde CIM-distribution

CIM distribueres som en komplet definition i hvert tilgængeligt format, så du kan hente hele modellen i den serialisering, du har brug for, i stedet for at samle den stykke for stykke. De offentliggjorte downloadmuligheder er:

• AML (vocabulary) — den menneskeligt læsbare konceptuelle model.
• AML (dialect) — de menneskeligt læsbare kanoniske former.
• JSON-LD (vocabulary & schema) — den maskinlæsbare semantiske model.
• R2RML — den relationelle-til-RDF-kortlægning.
• RAML Types — de kanoniske former som RAML-datatyper.
• SQL DDL — de kanoniske former som portabel SQL.

Hver download indeholder den fulde CIM-definition i det pågældende format, hvilket betyder, at du kan adoptere CIM trinvist: start med det format, din nuværende værktøjskæde understøtter, og tilføj andre, efterhånden som dine interoperabilitetsbehov vokser.

Bidrag på tværs af formater

Fordi CIM er et åbent projekt, er bidrag velkomne — og multiformatstrukturen præger, hvordan bidrag fungerer. Bidragydere falder typisk i to grupper:

• Modelbidragydere foreslår nye entiteter, relationer eller begrænsninger. Disse ændringer forfattes én gang og propageres derefter til de andre serialiseringer.
• Formatbidragydere forbedrer troskaben eller værktøjerne til en specifik serialisering —for eksempel ved at raffinere R2RML-kortlægningerne eller SQL DDL-portabiliteten.

Hvis du bidrager, er den praktiske regel at forstå, hvilket lag du ændrer (konceptuelt vs. kanonisk), og hvilke formater der som følge heraf skal regenereres. Projektets GitHub-repositories og bidragyderwebformular er indgangspunkterne for at blive involveret.

Ofte stillede spørgsmål

Hvad er forskellen mellem concepts.json og schema.json i CIM?

concepts.json er den konceptuelle model — entiteterne og relationerne i CIM, udtrykt som JSON-LD med RDF Schema-semantik. schema.json er det kanoniske skema — dataformerne og yderligere begrænsninger, udtrykt som JSON-LD med SHACL-semantik. Kort fortalt beskriver concepts, hvad der eksisterer; schema beskriver, hvordan en gyldig instans skal se ud.

Hvorfor udgiver CIM den samme model i så mange formater?

Fordi forskellige forbrugere bruger forskellige teknologier. En triple store har brug for RDF; et JSON API har brug for JSON Schema; en DBA har brug for SQL DDL; en forretningsanalytiker har brug for noget menneskeligt læsbart. Ved at udgive CIM i flere standardformater kan hver af disse målgrupper adoptere modellen med de værktøjer, de allerede har, i stedet for at tvinge en enkelt teknologistak ned over alle.

Hvad bruges R2RML til i CIM?

R2RML er W3C-standarden for kortlægning af et relationelt databaseskema til en RDF-graf. I CIM er det broen, der eksponerer eksisterende SQL-databaser som CIM-konforme linked data, så du kan forbinde operationelle relationelle systemer til det semantiske lag uden at skulle re-modellere dem manuelt.

Er AML det samme som JSON-LD-formaterne?

Nej. AML er det menneskeligt læsbare udtryk for CIM — ordforrådet (concepts.yaml) og dialekten (schema.yaml, schema.raml). JSON-LD er det maskinlæsbare, RDF-baserede udtryk. De beskriver den samme model, men henvender sig til forskellige målgrupper og værktøjskæder.

Hvilket CIM-format skal jeg starte med?

Det afhænger af din forbruger. Hvis du gennemgår modellen, så start med AML-ordforrådet. Hvis du bygger et JSON API, skal du starte med JSON Schema. Hvis du forbinder en relationel database, skal du starte med R2RML eller SQL DDL. Hvis du arbejder med en vidensgraf, så start med JSON-LD og SHACL.

Kan jeg redigere ét CIM-format uden at opdatere de andre?

Du kan, men du bør ikke. Formaterne er serialiseringer af én underliggende model, så hvis du redigerer et enkelt format manuelt, vil familien glide ud af synkronisering. Udvid kildemodellen og regenerer de andre serialiseringer i stedet.

Yderligere læsning

• World Wide Web Consortium (W3C) — standardiseringsorganet bag RDF, RDF Schema, SHACL og R2RML, som er de specifikationer, CIM bygger på.
• Shapes Constraint Language (SHACL) — baggrund om det begrænsningssprog, der bruges til CIM’s kanoniske dataformer.
• Linux Foundation — den fond, som CIM-projektet opererer under.