Formati CIM

Il Cloud Information Model (CIM) è stato progettato fin dall’inizio come un modello di concetti di business basato su standard e indipendente dall’applicazione: clienti, ordini, prodotti, conti e le relazioni tra loro. Ma un modello concettuale è utile solo se i sistemi che ne hanno bisogno possono effettivamente consumarlo. Questo è il motivo per cui CIM non viene pubblicato come un singolo artefatto proprietario, ma come una famiglia di serializzazioni, ciascuna destinata a una diversa classe di strumenti, runtime e pubblico.

Questa pagina spiega cos’è ogni formato CIM, a cosa serve e come scegliere tra di essi. Se sei un architetto di dati aziendali, un ingegnere di integrazione o ETL, un fornitore di applicazioni o piattaforme o un collaboratore open source, il formato che sceglierai per primo dipende da dove ti trovi nella pipeline.

Punti chiave

• CIM è distribuito in due famiglie: formati per il web semantico (JSON-LD, RDF Schema, SHACL, R2RML) e formati leggibili dall’uomo/relazionali (vocabolario AML, dialetto AML, tipi RAML, JSON Schema, SQL DDL).
• Il modello concettuale (concepts.*) descrive entità e relazioni; lo schema canonico (schema.*) descrive le forme e i vincoli dei dati. Sono artefatti separati con scopi distinti.
• JSON-LD è la forma canonica leggibile dalla macchina; AML è la forma leggibile dall’uomo dello stesso contenuto; SQL DDL e JSON Schema sono i formati che la maggior parte dei team di applicazione e ETL consuma direttamente.
• R2RML è il ponte: mappa uno schema relazionale su un grafo RDF, che è il modo in cui si collegano i database SQL esistenti al livello semantico.
• La scelta di un formato è una questione di consumatore, non di preferenza: scegli quello che la tua toolchain di destinazione ingerisce nativamente e usa gli altri come controlli incrociati.

Perché CIM viene distribuito in più formati

La maggior parte dei modelli di dati viene pubblicata in un unico formato: in genere un diagramma ER, un foglio di calcolo o un file di metadati specifico del fornitore. Questo funziona finché non è necessario condividere il modello tra organizzazioni che utilizzano stack diversi.

Una piattaforma di vendita al dettaglio potrebbe utilizzare PostgreSQL e dbt; un partner potrebbe utilizzare un database a grafo e un triple store; un fornitore SaaS potrebbe esporre API JSON e convalidare i payload con JSON Schema. Se il modello condiviso esiste solo in uno di questi dialetti, tutti gli altri devono tradurlo — e le traduzioni tendono a divergere.

La strategia multiformato di CIM è una risposta deliberata a questo problema. Il modello viene redatto una volta e poi tradotto in formati che si mappano chiaramente su standard riconosciuti, in modo che ogni consumatore adotti CIM utilizzando gli strumenti di cui già dispone.

Questa è la stessa filosofia alla base di organismi di standardizzazione come il World Wide Web Consortium (W3C), che pubblica specifiche come RDF, SHACL e R2RML che CIM riutilizza anziché reinventare. Si allinea inoltre con la più ampia missione di interoperabilità della Linux Foundation, nell’ambito della quale opera il progetto CIM.

Correlato: Fivetran — La pipeline ELT completamente gestita che continua a funzionare.

Il vantaggio pratico è duplice: le aziende con tecnologie diverse possono adottare CIM senza dover ricorrere a un “rip-and-replace”, e i contributori possono estendere il modello nel formato che meglio si adatta alla loro esperienza, sapendo che le altre serializzazioni possono essere rigenerate.

Il modello concettuale vs lo schema canonico

Prima di confrontare i formati di file, è utile separare due livelli che CIM mantiene distinti — e che i nuovi arrivati spesso confondono.

• Il modello concettuale risponde a cosa esiste e come si relaziona. Definisce le entità (Cliente, Ordine, Prodotto), i loro attributi e le relazioni tra loro. È intenzionalmente vicino al vocabolario di business e deliberatamente leggero sui dettagli fisici.
• Lo schema canonico risponde a come appare un’istanza valida. Aggiunge forme di dati e vincoli — cardinalità, tipi, campi obbligatori, intervalli di valori — rispetto ai quali un sistema può eseguire la convalida.

Nella distribuzione CIM, questi corrispondono a due radici di nomi di file: concepts.* per il livello concettuale e schema.* per il livello canonico. Mantenerli separati significa che un analista aziendale può leggere il modello concettuale senza dover navigare nella sintassi dei vincoli, mentre un ingegnere può convalidare i payload rispetto allo schema senza necessità dell’intera narrazione concettuale.

La nostra scelta: Workato — IPaaS basato sull'automazione su cui i team aziendali possono effettivamente basarsi.

I formati del Web Semantico

Questi formati esprimono CIM come un grafo basato su RDF. Sono la scelta giusta quando i consumatori includono triple store, knowledge graph, strumenti di ontologia o qualsiasi sistema che ragioni su dati collegati (linked data).

JSON-LD — concepts.json e schema.json

JSON-LD è JSON con un contesto di linked data, il che lo rende il ponte pragmatico tra le normali API web e il web semantico. CIM pubblica due artefatti JSON-LD:

• concepts.json — la descrizione concettuale di entità e relazioni, espressa come RDF Schema.
• schema.json — le forme di dati canoniche e i vincoli aggiuntivi, espressi in SHACL.

Essendo un JSON valido, concepts.json e schema.json possono essere caricati da normali strumenti JSON, ma poiché contengono un @context, si espandono anche in triple RDF complete. Questa duplice natura è il motivo per cui JSON-LD è spesso la scelta predefinita migliore per i team che desiderano fedeltà semantica senza dover adottare uno stack RDF specializzato fin dal primo giorno.

RDF Schema — schema.json

RDF Schema (RDFS) fornisce il vocabolario per descrivere classi e proprietà — i costrutti rdfs:Class, rdfs:subClassOf e rdfs:domain/rdfs:range che consentono a una macchina di comprendere che un Ordine è un documento commerciale e che la sua proprietà cliente punta a un Cliente. CIM utilizza RDFS per dare al modello concettuale una semantica formale, in modo che le gerarchie di sottoclassi e i domini delle proprietà siano interpretabili dalla macchina anziché essere meramente documentati.

SHACL — schema.json

Il Shapes Constraint Language (SHACL) è uno standard W3C per la convalida di grafi RDF rispetto a un insieme di condizioni chiamate “shapes” (forme). Laddove RDFS definisce cosa una classe è, SHACL definisce cosa un’istanza valida deve soddisfare: proprietà richieste, tipi di valori consentiti, limiti di cardinalità. Le forme di dati canoniche di CIM sono espresse in SHACL, il che significa che qualsiasi processore SHACL può convalidare dati conformi a CIM senza codice personalizzato.

R2RML — schema.rdml

R2RML è lo standard W3C per mappare uno schema di database relazionale su un grafo RDF. Questo è il formato più importante per gli ingegneri di integrazione ed ETL, poiché è il meccanismo mediante il quale un database SQL esistente — con le sue tabelle, colonne e chiavi esterne — viene esposto come linked data conformi a CIM.

Correlato: Matillion — ELT push-down creato per data warehouse su cloud.

Invece di rimodellare manualmente il database operativo, si scrive (o si genera) una mappatura R2RML che dichiara come ogni tabella e colonna corrisponda a entità e proprietà CIM. Il risultato è un grafo RDF virtuale sui dati relazionali esistenti.

I formati leggibili e relazionali

Non tutti i consumatori desiderano l’RDF. Gli sviluppatori di applicazioni, i modellatori di dati e i DBA spesso desiderano qualcosa che possano leggere in un editor di testo o caricare direttamente in un database. CIM li supporta con le serializzazioni AML, RAML, JSON Schema e SQL DDL.

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

AML, il lignaggio AnyLogic Modeling Language utilizzato qui come dialetto di modellazione, è l’espressione leggibile dall’uomo di CIM. CIM pubblica tre artefatti AML:

Se stai facendo acquisti: Boomi AtomSphere — Enterprise iPaaS per l'integrazione ibrida da cloud a on-premise.

• concepts.yaml — il vocabolario AML, una versione leggibile dall’uomo del modello concettuale.
• schema.yaml — il dialetto AML, una versione leggibile dall’uomo delle forme di dati canoniche.
• schema.raml — il rendering dei tipi di dati RAML delle forme canoniche.

Vale la pena interiorizzare la distinzione tra vocabolario e dialetto: il vocabolario definisce i termini (i nomi e i verbi del modello), mentre il dialetto definisce come questi termini vengono combinati in strutture valide. Se stai esaminando CIM per la prima volta, concepts.yaml è solitamente il punto di ingresso più accessibile.

JSON Schema — schema.json

JSON Schema è lo standard de facto per la convalida di documenti JSON, supportato nativamente o tramite librerie in praticamente ogni linguaggio moderno. L’artefatto JSON Schema di CIM esprime le forme di dati canoniche come JSON Schema, il che lo rende direttamente utilizzabile in API gateway, message broker e pipeline CI che già convalidano i payload JSON. Se la tua superficie di integrazione è REST o JSON event-driven, questo è spesso il formato desiderato.

SQL DDL — schema.sql

SQL DDL è l’insieme di istruzioni CREATE TABLE, CREATE VIEW e di vincolo che materializzano le forme canoniche in un database relazionale. CIM punta alla sintassi SQL 2008, che mantiene il DDL portabile tra i principali motori relazionali. Questo è il formato a cui si rivolgono i DBA e gli ingegneri ETL quando desiderano implementare uno schema fisico conforme a CIM — ad esempio, un database di staging o di integrazione che rispecchi il modello canonico.

Scegliere un formato: una guida pratica

Non esiste un unico formato “corretto”. La scelta giusta è determinata da chi o cosa consumerà il modello successivamente. Utilizza la tabella seguente come aiuto decisionale.

Se il tuo consumatore è…	Inizia con…	Perché…
Un analista aziendale o un modellatore di dati che esamina il modello	Vocabolario AML (concepts.yaml)	Leggibile dall’uomo, prioritario il vocabolario aziendale
Un triple store, knowledge graph o strumento ontologico	JSON-LD (concepts.json, schema.json)	RDF nativo con un accesso facilitato via JSON
Un validatore SHACL o una pipeline semantica di qualità dei dati	SHACL (schema.json)	Convalida dei vincoli standard su RDF
Un database relazionale esistente che desideri esporre come linked data	R2RML (schema.rdml)	Mappa tabelle/colonne su entità CIM senza rimodellare
Un’API JSON REST o event-driven	JSON Schema (schema.json)	Convalida direttamente i payload JSON
Un database relazionale che desideri rendere conforme a CIM	SQL DDL (schema.sql)	DDL SQL 2008 portabile
Un’API descritta in RAML	Tipi RAML (schema.raml)	Nativo per le toolchain RAML

Alcune avvertenze pratiche:

• Non trattare i formati come modelli indipendenti. Sono serializzazioni dello stesso CIM sottostante. Se trovi una discrepanza tra, ad esempio, schema.json (JSON Schema) e schema.json (SHACL), si tratta di un bug o di un disallineamento di versione, non di una scelta di progettazione: segnalalo.
• Attenzione alle collisioni dei nomi dei file. Diversi formati condividono la radice schema con diverse estensioni (schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml). Quando scarichi la distribuzione completa, mantieni separate le directory dei formati per non sovrascrivere una serializzazione con un’altra.
• Abbina il formato alla fase di convalida. Utilizza i formati concettuali per la revisione in fase di progettazione e i formati canonici per la convalida in fase di runtime. La convalida rispetto al modello concettuale non è significativa, poiché mancano i vincoli.
• Preferisci la generazione alla modifica manuale. Se estendi CIM, estendi la sorgente e rigenera le altre serializzazioni invece di modificare ogni formato a mano, altrimenti la famiglia di file andrà fuori sincrono.

Download della distribuzione CIM completa

CIM è distribuito come definizione completa in ogni formato disponibile, così puoi scaricare l’intero modello nella serializzazione di cui hai bisogno invece di assemblarlo pezzo per pezzo. Le opzioni di download pubblicate sono:

• AML (vocabulary) — il modello concettuale leggibile dall’uomo.
• AML (dialect) — le forme canoniche leggibili dall’uomo.
• JSON-LD (vocabulary & schema) — il modello semantico leggibile dalla macchina.
• R2RML — la mappatura relazionale-RDF.
• RAML Types — le forme canoniche come tipi di dati RAML.
• SQL DDL — le forme canoniche come SQL portabile.

Ogni download contiene la definizione CIM completa in quel formato, il che significa che puoi adottare CIM in modo incrementale: inizia con il formato supportato dalla tua attuale toolchain e aggiungine altri man mano che crescono le tue esigenze di interoperabilità.

Contribuire attraverso i formati

Poiché CIM è un progetto aperto, i contributi sono benvenuti — e la struttura multiformato determina il modo in cui funzionano i contributi. I contributori rientrano tipicamente in due gruppi:

• I contributori del modello propongono nuove entità, relazioni o vincoli. Queste modifiche vengono create una volta e quindi propagate alle altre serializzazioni.
• I contributori del formato migliorano la fedeltà o gli strumenti di una serializzazione specifica — ad esempio, perfezionando le mappature R2RML o la portabilità del SQL DDL.

Se stai contribuendo, la regola pratica è capire quale livello stai modificando (concettuale vs canonico) e quali formati devono essere rigenerati di conseguenza. I repository GitHub del progetto e il modulo web per i contributori sono i punti di ingresso per essere coinvolti.

Domande frequenti

Qual è la differenza tra concepts.json e schema.json in CIM?

concepts.json è il modello concettuale — le entità e le relazioni in CIM, espresse come JSON-LD con semantica RDF Schema. schema.json è lo schema canonico — le forme dei dati e i vincoli aggiuntivi, espressi come JSON-LD con semantica SHACL. In breve, concepts descrive ciò che esiste; schema descrive come deve apparire un’istanza valida.

Perché CIM pubblica lo stesso modello in così tanti formati?

Perché consumatori diversi utilizzano tecnologie diverse. Un triple store necessita di RDF; un’API JSON necessita di JSON Schema; un DBA necessita di SQL DDL; un analista aziendale ha bisogno di qualcosa di leggibile dall’uomo. La pubblicazione di CIM in più formati standard consente a ciascuno di questi segmenti di pubblico di adottare il modello con gli strumenti di cui già dispone, anziché imporre a tutti un unico stack.

A cosa serve R2RML in CIM?

R2RML è lo standard W3C per mappare uno schema di database relazionale su un grafo RDF. In CIM è il ponte che espone i database SQL esistenti come linked data conformi a CIM, in modo da poter connettere i sistemi relazionali operativi al livello semantico senza rimodellarli manualmente.

AML è uguale ai formati JSON-LD?

No. AML è l’espressione leggibile dall’uomo di CIM — il vocabolario (concepts.yaml) e il dialetto (schema.yaml, schema.raml). JSON-LD è l’espressione leggibile dalla macchina, basata su RDF. Descrivono lo stesso modello ma si rivolgono a pubblici e toolchain diversi.

Con quale formato CIM dovrei iniziare?

Dipende dal tuo consumatore. Se stai rivedendo il modello, inizia con il vocabolario AML. Se stai creando un’API JSON, inizia con JSON Schema. Se stai connettendo un database relazionale, inizia con R2RML o SQL DDL. Se stai lavorando con un knowledge graph, inizia con JSON-LD e SHACL.

Posso modificare un formato CIM senza aggiornare gli altri?

Puoi, ma non dovresti. I formati sono serializzazioni di un unico modello sottostante, quindi la modifica manuale di un singolo formato causa il disallineamento della famiglia di formati. Estendi il modello di origine e rigenera invece le altre serializzazioni.

Ulteriori letture

• World Wide Web Consortium (W3C) — l’organismo di standardizzazione dietro RDF, RDF Schema, SHACL e R2RML, le specifiche su cui si basa CIM.
• Shapes Constraint Language (SHACL) — informazioni generali sul linguaggio dei vincoli utilizzato per le forme di dati canoniche di CIM.
• Linux Foundation — la fondazione sotto la quale opera il progetto CIM.