Formatos CIM

O Cloud Information Model (CIM) foi projetado desde o início como um modelo de conceitos de negócios baseado em padrões e independente de aplicativos — clientes, pedidos, produtos, contas e os relacionamentos entre eles. Mas um modelo conceitual só é útil se os sistemas que dele necessitam puderem realmente consumi-lo. É por isso que o CIM é publicado não como um único artefato proprietário, mas como uma família de serializações, cada uma visando uma classe diferente de ferramentas, tempo de execução e público.

Esta página explica o que é cada formato CIM, para que serve e como escolher entre eles. Se você é um arquiteto de dados corporativos, um engenheiro de integração ou ETL, um fornecedor de aplicativos ou plataformas ou um contribuidor de código aberto, o formato que você busca primeiro depende de onde você está no pipeline.

Principais conclusões

• O CIM é distribuído em duas famílias: formatos de web semântica (JSON-LD, RDF Schema, SHACL, R2RML) e formatos relacionais/legíveis por humanos (vocabulário AML, dialeto AML, tipos RAML, JSON Schema, SQL DDL).
• O modelo conceitual (concepts.*) descreve entidades e relacionamentos; o esquema canônico (schema.*) descreve formas e restrições de dados. São artefatos separados com finalidades distintas.
• JSON-LD é a forma canônica legível por máquina; AML é a forma legível por humanos do mesmo conteúdo; SQL DDL e JSON Schema são as formas que a maioria das equipes de aplicativos e ETL consomem diretamente.
• R2RML é a ponte: mapeia um esquema relacional para um grafo RDF, que é como você conecta bancos de dados SQL existentes à camada semântica.
• A escolha de um formato é uma questão de consumidor, não de preferência — escolha aquele que seu conjunto de ferramentas de destino ingere nativamente e use os outros como verificações cruzadas.

Por que o CIM é fornecido em vários formatos

A maioria dos modelos de dados é publicada em exatamente um formato — geralmente um diagrama ER, uma planilha ou um arquivo de metadados específico do fornecedor. Isso funciona até que você precise compartilhar o modelo entre organizações que usam stacks diferentes.

Uma plataforma de varejo pode rodar PostgreSQL e dbt; um parceiro pode executar um banco de dados de grafos e um triple store; um fornecedor de SaaS pode expor APIs JSON e validar payloads com JSON Schema. Se o modelo compartilhado existir apenas em um desses dialetos, todos os outros terão que traduzi-lo — e as traduções divergem.

A estratégia multiformato do CIM é uma resposta deliberada a esse problema. O modelo é criado uma vez e depois traduzido em formatos que mapeiam claramente para padrões reconhecidos, para que cada consumidor adote o CIM usando as ferramentas que já possui.

Esta é a mesma filosofia por trás de órgãos de padronização como o World Wide Web Consortium (W3C), que publica especificações como RDF, SHACL e R2RML que o CIM reutiliza em vez de reinventar. Também se alinha com a missão mais ampla de interoperabilidade da Linux Foundation, sob a qual o projeto CIM opera.

Related: Fivetran — O pipeline ELT totalmente gerenciado que continua funcionando.

O benefício prático é duplo: empresas com tecnologias variadas podem adotar o CIM sem a necessidade de substituição total (“rip-and-replace”), e os colaboradores podem estender o modelo em qualquer formato que corresponda à sua experiência, sabendo que as outras serializações podem ser regeneradas.

O modelo conceitual versus o esquema canônico

Antes de comparar formatos de arquivo, é útil separar duas camadas que o CIM mantém distintas — e que os recém-chegados frequentemente confundem.

• O modelo conceitual responde o que existe e como se relaciona. Define entidades (Cliente, Pedido, Produto), seus atributos e os relacionamentos entre eles. É intencionalmente próximo do vocabulário de negócios e deliberadamente leve em detalhes físicos.
• O esquema canônico responde como é uma instância válida. Ele adiciona formas e restrições de dados — cardinalidade, tipos, campos obrigatórios, intervalos de valores — que um sistema pode validar.

Na distribuição CIM, eles são mapeados para dois prefixos de nome de arquivo: concepts.* para a camada conceitual e schema.* para a camada canônica. Mantê-los separados significa que um analista de negócios pode ler o modelo conceitual sem ter que lidar com a sintaxe de restrições, enquanto um engenheiro pode validar payloads em relação ao esquema sem precisar de toda a narrativa conceitual.

Nossa escolha: Workato — iPaaS baseado em automação que as equipes de negócios podem realmente desenvolver.

Os formatos da Web Semântica

Esses formatos expressam o CIM como um grafo baseado em RDF. Eles são a escolha certa quando seus consumidores incluem triple stores, grafos de conhecimento, ferramentas de ontologia ou qualquer sistema que raciocine sobre dados vinculados (linked data).

JSON-LD — concepts.json e schema.json

JSON-LD é JSON com um contexto de dados vinculados, o que o torna a ponte pragmática entre APIs web comuns e a web semântica. O CIM publica dois artefatos JSON-LD:

• concepts.json — a descrição conceitual de entidades e relacionamentos, expressa como RDF Schema.
• schema.json — as formas de dados canônicas e restrições adicionais, expressas em SHACL.

Por ser um JSON válido, concepts.json e schema.json podem ser carregados por ferramentas JSON comuns, mas como carregam um @context, eles também se expandem em triplos RDF completos. Essa natureza dual é a razão pela qual o JSON-LD costuma ser o melhor padrão para equipes que desejam fidelidade semântica sem adotar uma stack RDF especializada desde o primeiro dia.

RDF Schema — schema.json

O RDF Schema (RDFS) fornece o vocabulário para descrever classes e propriedades — as construções rdfs:Class, rdfs:subClassOf e rdfs:domain/rdfs:range que permitem que uma máquina entenda que um Pedido é um documento de negócio e que sua propriedade de cliente aponta para um Cliente. O CIM usa RDFS para dar semântica formal ao modelo conceitual, de modo que as hierarquias de subclasses e os domínios de propriedades sejam interpretáveis por máquina, em vez de meramente documentados.

SHACL — schema.json

A Shapes Constraint Language (SHACL) é um padrão W3C para validar grafos RDF em relação a um conjunto de condições chamadas shapes. Enquanto o RDFS diz o que uma classe é, o SHACL diz o que uma instância válida deve satisfazer — propriedades obrigatórias, tipos de valores permitidos, limites de cardinalidade. Os shapes de dados canônicos do CIM são expressos em SHACL, o que significa que qualquer processador SHACL pode validar dados conformes ao CIM sem código personalizado.

R2RML — schema.rdml

R2RML é o padrão W3C para mapear um esquema de banco de dados relacional para um grafo RDF. Este é o formato mais importante para engenheiros de integração e ETL, porque é o mecanismo pelo qual um banco de dados SQL existente — com suas tabelas, colunas e chaves estrangeiras — é exposto como linked data conforme ao CIM.

Related: Matillion — ELT push-down desenvolvido para data warehouses em nuvem.

Em vez de remodelar seu banco de dados operacional manualmente, você escreve (ou gera) um mapeamento R2RML que declara como cada tabela e coluna corresponde a entidades e propriedades CIM. O resultado é um grafo RDF virtual sobre seus dados relacionais existentes.

Os Formatos Legíveis por Humanos e Relacionais

Nem todo consumidor deseja RDF. Desenvolvedores de aplicações, modeladores de dados e DBAs geralmente desejam algo que possam ler em um editor de texto ou carregar diretamente em um banco de dados. O CIM os atende com as serializações AML, RAML, JSON Schema e SQL DDL.

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

AML, a linhagem AnyLogic Modeling Language usada aqui como um dialeto de modelagem, é a expressão legível por humanos do CIM. O CIM publica três artefatos AML:

Se você estiver comprando: Boomi AtomSphere — Enterprise iPaaS para integração híbrida de nuvem local.

• concepts.yaml — o vocabulário AML, uma versão legível por humanos do modelo conceitual.
• schema.yaml — o dialeto AML, uma versão legível por humanos dos shapes de dados canônicos.
• schema.raml — a renderização dos tipos de dados RAML dos shapes canônicos.

A distinção entre vocabulário e dialeto vale a pena ser internalizada: o vocabulário define os termos (os substantivos e verbos do modelo), enquanto o dialeto define como esses termos são combinados em estruturas válidas. Se você estiver revisando o CIM pela primeira vez, concepts.yaml geralmente é o ponto de entrada mais acessível.

JSON Schema — schema.json

JSON Schema é o padrão de fato para validar documentos JSON, suportado nativamente ou via bibliotecas em praticamente todas as linguagens modernas. O artefato JSON Schema do CIM expressa os shapes de dados canônicos como JSON Schema, o que o torna diretamente utilizável em API gateways, message brokers e pipelines de CI que já validam payloads JSON. Se a sua superfície de integração for REST ou JSON orientado a eventos, este é frequentemente o formato desejado.

SQL DDL — schema.sql

SQL DDL é o conjunto de instruções CREATE TABLE, CREATE VIEW e constraints que materializam os shapes canônicos em um banco de dados relacional. O CIM visa a sintaxe SQL 2008, o que mantém o DDL portátil entre os principais motores relacionais. Este é o formato que DBAs e engenheiros de ETL buscam quando desejam implementar um esquema físico que esteja em conformidade com o CIM — por exemplo, um banco de dados de staging ou integração que espelhe o modelo canônico.

Escolhendo um Formato: Um Guia Prático

Não existe um único formato “correto”. A escolha certa é determinada por quem ou o que consumirá o modelo a seguir. Use a tabela abaixo como auxílio à decisão.

Se o seu consumidor é…	Comece com…	Porque…
Um analista de negócios ou modelador de dados revisando o modelo	Vocabulário AML (concepts.yaml)	Legível por humanos, priorizando o vocabulário de negócios
Um triple store, knowledge graph ou ferramenta de ontologia	JSON-LD (concepts.json, schema.json)	RDF nativo com rampa de acesso JSON
Um validador SHACL ou pipeline semântico de qualidade de dados	SHACL (schema.json)	Validação de restrições padrão sobre RDF
Um banco de dados relacional existente que você deseja expor como linked data	R2RML (schema.rdml)	Mapeia tabelas/colunas para entidades CIM sem remodelagem
Uma API REST ou JSON orientada a eventos	JSON Schema (schema.json)	Valida diretamente payloads JSON
Um banco de dados relacional que você deseja conformar ao CIM	SQL DDL (schema.sql)	DDL SQL 2008 portátil
Uma API descrita em RAML	Tipos RAML (schema.raml)	Nativo para toolchains RAML

Algumas ressalvas práticas:

• Não trate os formatos como modelos independentes. Eles são serializações do mesmo CIM subjacente. Se você encontrar uma discrepância entre, por exemplo, schema.json (JSON Schema) e schema.json (SHACL), isso é um bug ou um descompasso de versão, não uma escolha de design — reporte-o.
• Cuidado com as colisões de nomes de arquivos. Vários formatos compartilham o radical schema com extensões diferentes (schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml). Ao baixar a distribuição completa, mantenha os diretórios de formato separados para não sobrescrever uma serialização com outra.
• Combine o formato ao estágio de validação. Use os formatos conceituais para revisão em tempo de design e os formatos canônicos para validação em tempo de execução. Validar em relação ao modelo conceitual não é significativo — faltam as restrições.
• Prefira o gerado ao editado manualmente. Se você estender o CIM, estenda a fonte e regenere as outras serializações em vez de editar cada formato manualmente, caso contrário, a família ficará dessincronizada.

Baixando a Distribuição Completa do CIM

O CIM é distribuído como uma definição completa em cada formato disponível, para que você possa baixar o modelo inteiro na serialização de que precisa, em vez de montá-lo peça por peça. As opções de download publicadas são:

• AML (vocabulário) — o modelo conceitual legível por humanos.
• AML (dialeto) — as formas canônicas legíveis por humanos.
• JSON-LD (vocabulário e esquema) — o modelo semântico legível por máquina.
• R2RML — o mapeamento relacional para RDF.
• Tipos RAML — as formas canônicas como tipos de dados RAML.
• SQL DDL — as formas canônicas como SQL portátil.

Cada download contém a definição completa do CIM nesse formato, o que significa que você pode adotar o CIM de forma incremental: comece com o formato que seu conjunto de ferramentas atual suporta e adicione outros à medida que suas necessidades de interoperabilidade cresçam.

Contribuindo em Vários Formatos

Como o CIM é um projeto aberto, as contribuições são bem-vindas — e a estrutura multiformato molda o modo como as contribuições funcionam. Os colaboradores normalmente se enquadram em dois grupos:

• Contribuidores do modelo propõem novas entidades, relacionamentos ou restrições. Essas alterações são criadas uma vez e depois propagadas para as outras serializações.
• Contribuidores de formato melhoram a fidelidade ou as ferramentas de uma serialização específica — por exemplo, refinando os mapeamentos R2RML ou a portabilidade do SQL DDL.

Se você estiver contribuindo, a regra prática é entender qual camada você está alterando (conceitual vs. canônica) e quais formatos devem ser regenerados como resultado. Os repositórios GitHub do projeto e o formulário web do contribuidor são os pontos de entrada para se envolver.

Perguntas Frequentes

Qual é a diferença entre concepts.json e schema.json no CIM?

concepts.json é o modelo conceitual — as entidades e relacionamentos no CIM, expressos como JSON-LD com semântica de RDF Schema. schema.json é o esquema canônico — as formas de dados e restrições adicionais, expressas como JSON-LD com semântica SHACL. Em suma, concepts descreve o que existe; schema descreve como deve ser uma instância válida.

Por que o CIM publica o mesmo modelo em tantos formatos?

Porque diferentes consumidores usam tecnologias diferentes. Um triple store precisa de RDF; uma API JSON precisa de JSON Schema; um DBA precisa de SQL DDL; um analista de negócios precisa de algo legível por humanos. Publicar o CIM em múltiplos formatos padrão permite que cada um desses públicos adote o modelo com as ferramentas que já possuem, em vez de forçar uma única pilha tecnológica a todos.

Para que o R2RML é usado no CIM?

O R2RML é o padrão do W3C para mapear um esquema de banco de dados relacional para um grafo RDF. No CIM, ele é a ponte que expõe bancos de dados SQL existentes como dados vinculados (linked data) conformes ao CIM, para que você possa conectar sistemas relacionais operacionais à camada semântica sem ter que remodelá-los manualmente.

O AML é o mesmo que os formatos JSON-LD?

Não. O AML é a expressão legível por humanos do CIM — o vocabulário (concepts.yaml) e o dialeto (schema.yaml, schema.raml). O JSON-LD é a expressão legível por máquina, baseada em RDF. Eles descrevem o mesmo modelo, mas visam públicos e cadeias de ferramentas diferentes.

Com qual formato CIM devo começar?

Depende do seu perfil de consumo. Se você estiver revisando o modelo, comece com o vocabulário AML. Se estiver construindo uma API JSON, comece com o JSON Schema. Se estiver conectando um banco de dados relacional, comece com R2RML ou SQL DDL. Se estiver trabalhando com um grafo de conhecimento, comece com JSON-LD e SHACL.

Posso editar um formato CIM sem atualizar os outros?

Você pode, mas não deve. Os formatos são serializações de um único modelo subjacente, portanto, editar um único formato manualmente faz com que a família de arquivos perca a sincronia. Em vez disso, estenda o modelo de origem e regenere as outras serializações.

Leitura Adicional

• World Wide Web Consortium (W3C) — o órgão de padronização por trás do RDF, RDF Schema, SHACL e R2RML, as especificações nas quais o CIM se baseia.
• Shapes Constraint Language (SHACL) — informações básicas sobre a linguagem de restrição usada para as formas de dados canônicas do CIM.
• Linux Foundation — a fundação sob a qual o projeto CIM opera.