CIM-formater

(CIM) ble designet fra begynnelsen som en standardbasert, applikasjons-agnostisk modell for forretningskonsepter – kunder, bestillinger, produkter, kontoer og relasjonene mellom dem. Men en konseptuell modell er bare nyttig hvis systemene som trenger den faktisk kan konsumere den. Det er grunnen til at CIM ikke publiseres som en enkelt proprietær artefakt, men som en familie av serialiseringer, der hver retter seg mot en annen klasse av verktøy, kjøretid og publikum.

Denne siden forklarer hva hvert CIM-format er, hva det brukes til, og hvordan du velger mellom dem. Hvis du er en enterprise-dataarkitekt, en integrasjons- eller ETL-ingeniør, en applikasjons- eller plattformleverandør eller en åpen kildekode-bidragsyter, avhenger formatet du først søker etter hvor i pipelinen du befinner deg.

Viktige takeaways

• CIM distribueres i to familier: semantiske nettformater (JSON-LD, RDF Schema, SHACL, R2RML) og menneskelesbare/relasjonelle formater (AML-vokabular, AML-dialekt, RAML-typer, JSON Schema, SQL DDL).
• Den konseptuelle modellen (concepts.*) beskriver enheter og relasjoner; det kanoniske skjemaet (schema.*) beskriver dataformer og begrensninger. De er separate artefakter med separate formål.
• JSON-LD er den kanoniske maskinlesbare formen; AML er den menneskelesbare formen av det samme innholdet; SQL DDL og JSON Schema er formatene de fleste applikasjons- og ETL-team konsumerer direkte.
• R2RML er broen: den mapper et relasjonsskjema til en RDF-graf, som er måten du kobler eksisterende SQL-databaser til det semantiske laget på.
• Å velge et format er et spørsmål om forbruker, ikke preferanse – velg det formatet målverktøykjeden din støtter nativt, og bruk de andre som krysssjekker.

Hvorfor CIM leveres i flere formater

De fleste datamodeller publiseres i nøyaktig én form – vanligvis et ER-diagram, et regneark eller en leverandørspesifikk metadatafil. Det fungerer helt til du trenger å dele modellen på tvers av organisasjoner som bruker forskjellige teknologistabler.

En detaljhandelsplattform kan kjøre PostgreSQL og dbt; en partner kan kjøre en grafdatabase og en triple store; en SaaS-leverandør kan eksponere JSON-API-er og validere nyttelaster med JSON Schema. Hvis den delte modellen bare eksisterer i én av disse dialektene, må alle andre oversette den – og oversettelser avviker over tid.

CIMs flerformatstrategi er et bevisst svar på dette problemet. Modellen forfattes én gang og blir deretter oversatt til formater som mapper rent mot anerkjente standarder, slik at hver forbruker kan ta i bruk CIM med verktøyene de allerede har.

Dette er den samme filosofien bak standardiseringsorganer som World Wide Web Consortium (W3C), som publiserer spesifikasjoner som RDF, SHACL og R2RML, som CIM gjenbruker i stedet for å gjenoppfinne. Det er også i tråd med det bredere interoperabilitetsoppdraget til Linux Foundation, som CIM-prosjektet opererer under.

Relatert: Boomi AtomSphere — Enterprise iPaaS for hybrid sky-til-på-prem-integrasjon.

Den praktiske fordelen er todelt: bedrifter med varierende teknologier kan ta i bruk CIM uten en fullstendig utskifting («rip-and-replace»), og bidragsytere kan utvide modellen i det formatet som passer deres ekspertise, vel vitende om at de andre serialiseringene kan regenereres.

Den konseptuelle modellen vs. det kanoniske skjemaet

Før man sammenligner filformater, hjelper det å skille mellom to lag som CIM holder adskilt – og som nykommere ofte blander sammen.

• Den konseptuelle modellen svarer på hva som eksisterer og hvordan det henger sammen. Den definerer enheter (Customer, Order, Product), deres attributter og relasjonene mellom dem. Den er bevisst tett opp til forretningsvokabularet og med vilje lett på fysiske detaljer.
• Det kanoniske skjemaet svarer på hvordan en gyldig forekomst ser ut. Det legger til dataformer og begrensninger – kardinalitet, typer, obligatoriske felt, verdiområder – som et system kan validere mot.

I CIM-distribusjonen mapper disse til to filnavnstammer: concepts.* for det konseptuelle laget og schema.* for det kanoniske laget. Ved å holde dem adskilt kan en forretningsanalytiker lese den konseptuelle modellen uten å måtte vasse gjennom syntaks for begrensninger, mens en ingeniør kan validere nyttelaster mot skjemaet uten å trenge den fullstendige konseptuelle fortellingen.

Vårt valg: Workato — Automatiseringsledet iPaaS som bedriftsteam faktisk kan bygge på.

De semantiske nettformatene

Disse formatene uttrykker CIM som en RDF-basert graf. De er det riktige valget når forbrukerne dine inkluderer triple stores, kunnskapsgrafer, ontologiverktøy eller ethvert system som resonnerer over koblede data.

JSON-LD — concepts.json og schema.json

JSON-LD er JSON med en linked-data-kontekst, noe som gjør det til den pragmatiske broen mellom vanlige web-API-er og det semantiske nettet. CIM publiserer to JSON-LD-artefakter:

• concepts.json — den konseptuelle beskrivelsen av enheter og relasjoner, uttrykt som RDF Schema.
• schema.json — de kanoniske dataformene og tilleggsbegrensningene, uttrykt i SHACL.

Fordi det er gyldig JSON, kan concepts.json og schema.json lastes med vanlige JSON-verktøy, men fordi de bærer en @context, kan de også utvides til fulle RDF-tripler. Denne doble naturen er grunnen til at JSON-LD ofte er det beste standardvalget for team som ønsker semantisk troskap uten å måtte ta i bruk en spesialisert RDF-stabel fra dag én.

RDF Schema — schema.json

RDF Schema (RDFS) gir vokabularet for å beskrive klasser og egenskaper – konstruksjonene rdfs:Class, rdfs:subClassOf og rdfs:domain/rdfs:range som lar en maskin forstå at en Order er en forretningsdokument og at dens kunde-egenskap peker på en Customer. CIM bruker RDFS for å gi den konseptuelle modellen formell semantikk, slik at underklassehierarkier og egenskapsdomener er maskintolkbare i stedet for bare dokumenterte.

SHACL — schema.json

Shapes Constraint Language (SHACL) er en W3C-standard for å validere RDF-grafer mot et sett med betingelser kalt shapes. Der RDFS sier hva en klasse er, sier SHACL hva en gyldig forekomst må tilfredsstille — nødvendige egenskaper, tillatte verdityper, kardinalitetsgrenser. CIMs kanoniske data-shapes er uttrykt i SHACL, noe som betyr at enhver SHACL-prosessor kan validere CIM-konforme data uten tilpasset kode.

R2RML — schema.rdml

R2RML er W3C-standarden for å kartlegge et relasjonsdatabaseskjema til en RDF-graf. Dette er formatet som betyr mest for integrasjons- og ETL-ingeniører, fordi det er mekanismen som gjør at en eksisterende SQL-database — med sine tabeller, kolonner og fremmednøkler — eksponeres som CIM-konforme koblede data.

Relatert: Matillion — Push-down ELT bygget for skydatavarehus.

I stedet for å remodellere den operasjonelle databasen for hånd, skriver du (eller genererer) en R2RML-mapping som erklærer hvordan hver tabell og kolonne tilsvarer CIM-enheter og egenskaper. Resultatet er en virtuell RDF-graf over dine eksisterende relasjonsdata.

De menneskelesbare og relasjonelle formatene

Ikke alle forbrukere ønsker RDF. Applikasjonsutviklere, datamodellere og DBA-er ønsker ofte noe de kan lese i en tekstredigerer eller laste rett inn i en database. CIM betjener dem med AML-, RAML-, JSON Schema- og SQL DDL-serialiseringer.

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

AML, AnyLogic Modeling Language-linjen som brukes her som en modelleringsdialekt, er det menneskelesbare uttrykket for CIM. CIM publiserer tre AML-artefakter:

Hvor vi skulle begynne: Fivetran — Den fullt administrerte ELT-rørledningen som bare fortsetter å kjøre.

• concepts.yaml — AML vokabular, en menneskelesbar versjon av den konseptuelle modellen.
• schema.yaml — AML dialekt, en menneskelesbar versjon av de kanoniske data-shapes.
• schema.raml — RAML-datatypene som gjengir de kanoniske shapes.

Skillet mellom vokabular og dialekt er verdt å internalisere: vokabularet definerer begrepene (substantivene og verbene i modellen), mens dialekten definerer hvordan disse begrepene kombineres til gyldige strukturer. Hvis du vurderer CIM for første gang, er concepts.yaml vanligvis det mest tilgjengelige inngangspunktet.

JSON Schema — schema.json

JSON Schema er de facto-standarden for validering av JSON-dokumenter, støttet nativt eller via biblioteker i praktisk talt alle moderne språk. CIMs JSON Schema-artefakt uttrykker de kanoniske data-shapes som JSON Schema, noe som gjør det direkte brukbart i API-gatewayer, meldingsmeglere og CI-pipelines som allerede validerer JSON-nyttelaster. Hvis integrasjonsflaten din er REST eller hendelsesdrevet JSON, er dette ofte formatet du ønsker.

SQL DDL — schema.sql

SQL DDL er settet med CREATE TABLE, CREATE VIEW og constraint-setninger som materialiserer de kanoniske shapes i en relasjonsdatabase. CIM retter seg mot SQL 2008-syntaks, noe som holder DDL-en portabel på tvers av de viktigste relasjonsmotorene. Dette er formatet DBA-er og ETL-ingeniører tyr til når de ønsker å sette opp et fysisk skjema som samsvarer med CIM — for eksempel en staging- eller integrasjonsdatabase som speiler den kanoniske modellen.

Velge et format: En praktisk veiledning

Det finnes ikke ett enkelt “riktig” format. Det riktige valget avgjøres av hvem eller hva som skal bruke modellen videre. Bruk tabellen nedenfor som beslutningsstøtte.

Hvis forbrukeren din er…	Start med…	Fordi…
En forretningsanalytiker eller datamodeller som gjennomgår modellen	AML-vokabular (concepts.yaml)	Menneskelesbar, forretningsvokabular-først
En triple store, kunnskapsgraf eller ontologiverktøy	JSON-LD (concepts.json, schema.json)	Nativ RDF med en JSON-pårampe
En SHACL-validator eller semantisk datakvalitetspipeline	SHACL (schema.json)	Standard constraint-validering over RDF
En eksisterende relasjonsdatabase du ønsker å eksponere som koblede data	R2RML (schema.rdml)	Mapper tabeller/kolonner til CIM-enheter uten remodellering
Et REST- eller hendelsesdrevet JSON-API	JSON Schema (schema.json)	Validerer JSON-nyttelaster direkte
En relasjonsdatabase du ønsker skal samsvare med CIM	SQL DDL (schema.sql)	Portabel SQL 2008 DDL
Et RAML-beskrevet API	RAML-typer (schema.raml)	Nativt for RAML-verktøykjeder

Noen praktiske forbehold:

• Ikke behandle formatene som uavhengige modeller. De er serialiseringer av den samme underliggende CIM. Hvis du finner et avvik mellom for eksempel schema.json (JSON Schema) og schema.json (SHACL), er det en feil eller en versjonsskjevhet, ikke et designvalg — rapporter det.
• Vær oppmerksom på filnavnkollisjoner. Flere formater deler stammen schema med forskjellige utvidelser (schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml). Når du laster ned hele distribusjonen, hold formatmappene adskilt slik at du ikke overskriver én serialisering med en annen.
• Tilpass formatet til valideringsstadiet. Bruk de konseptuelle formatene for gjennomgang i designfasen og de kanoniske formatene for validering ved kjøring (runtime). Validering mot den konseptuelle modellen er ikke meningsfullt — den mangler constraints.
• Foretrekk generert fremfor håndredigert. Hvis du utvider CIM, utvid kilden og generer de andre serialiseringene på nytt i stedet for å redigere hvert format for hånd, ellers vil familien drive fra hverandre.

Nedlasting av hele CIM-distribusjonen

CIM distribueres som en komplett definisjon i hvert tilgjengelig format, slik at du kan laste ned hele modellen i den serialiseringen du trenger i stedet for å sette den sammen bit for bit. De publiserte nedlastingsalternativene er:

• AML (vokabular) — den menneskelesbare konseptuelle modellen.
• AML (dialekt) — de menneskelesbare kanoniske formene.
• JSON-LD (vokabular og skjema) — den maskinlesbare semantiske modellen.
• R2RML — relasjonell-til-RDF-kartleggingen.
• RAML-typer — de kanoniske formene som RAML-datatyper.
• SQL DDL — de kanoniske formene som portabel SQL.

Hver nedlasting inneholder den fullstendige CIM-definisjonen i det formatet, noe som betyr at du kan ta i bruk CIM trinnvis: start med formatet din nåværende verktøykjede støtter, og legg til andre etter hvert som interoperabilitetsbehovene dine vokser.

Bidra på tvers av formater

Fordi CIM er et åpent prosjekt, er bidrag velkomne – og flerformatstrukturen former hvordan bidrag fungerer. Bidragsytere faller vanligvis inn i to grupper:

• Modellbidragsytere foreslår nye enheter, relasjoner eller begrensninger. Disse endringene forfattes én gang og overføres deretter til de andre serialiseringene.
• Formatbidragsytere forbedrer nøyaktigheten eller verktøyet til en spesifikk serialisering – for eksempel ved å raffinere R2RML-kartleggingene eller SQL DDL-portabiliteten.

Hvis du bidrar, er den praktiske regelen å forstå hvilket lag du endrer (konseptuelt vs. kanonisk) og hvilke formater som må regenereres som et resultat. Prosjektets GitHub-depoter og bidragsyternes nettskjema er inngangspunktene for å bli involvert.

Vanlige spørsmål

Hva er forskjellen mellom concepts.json og schema.json i CIM?

concepts.json er den konseptuelle modellen — enhetene og relasjonene i CIM, uttrykt som JSON-LD med RDF Schema-semantikk. schema.json er det kanoniske skjemaet – dataformene og tilleggsbegrensningene, uttrykt som JSON-LD med SHACL-semantikk. Kort fortalt beskriver concepts det som eksisterer; schema beskriver hvordan en gyldig forekomst må se ut.

Hvorfor publiserer CIM den samme modellen i så mange formater?

Fordi ulike forbrukere bruker ulike teknologier. En triple store trenger RDF; et JSON-API trenger JSON Schema; en DBA trenger SQL DDL; en forretningsanalytiker trenger noe som er menneskelesbart. Å publisere CIM i flere standardformater lar hver av disse målgruppene ta i bruk modellen med verktøy de allerede har, i stedet for å tvinge en enkelt teknologistabel på alle.

Hva brukes R2RML til i CIM?

R2RML er W3C-standarden for å kartlegge et relasjonsdatabaseskjema til en RDF-graf. I CIM er det broen som eksponerer eksisterende SQL-databaser som CIM-konforme koblede data, slik at du kan koble operasjonelle relasjonssystemer til det semantiske laget uten å remodellere dem for hånd.

Er AML det samme som JSON-LD-formatene?

Nei. AML er det menneskelesbare uttrykket for CIM – vokabularet (concepts.yaml) og dialekten (schema.yaml, schema.raml). JSON-LD er det maskinlesbare, RDF-baserte uttrykket. De beskriver samme modell, men retter seg mot ulike målgrupper og verktøykjeder.

Hvilket CIM-format bør jeg begynne med?

Det avhenger av forbrukeren din. Hvis du går gjennom modellen, start med AML-vokabularet. Hvis du bygger et JSON-API, start med JSON Schema. Hvis du kobler til en relasjonsdatabase, start med R2RML eller SQL DDL. Hvis du jobber med en kunnskapsgraf, start med JSON-LD og SHACL.

Kan jeg redigere ett CIM-format uten å oppdatere de andre?

Du kan, men du bør ikke. Formatene er serialiseringer av én underliggende modell, så redigering av et enkelt format for hånd fører til at formatene kommer ut av synk. Utvid kildemodellen og regenerer de andre serialiseringene i stedet.

Videre lesing

• World Wide Web Consortium (W3C) — standardorganet bak RDF, RDF Schema, SHACL og R2RML, spesifikasjonene CIM bygger på.
• Shapes Constraint Language (SHACL) — bakgrunn om begrensningsspråket som brukes for CIMs kanoniske dataformer.
• Linux Foundation — stiftelsen som CIM-prosjektet opererer under.