Formatos CIM

El Modelo de Información en la Nube (CIM) fue diseñado desde el principio como un modelo de conceptos de negocio basado en estándares e independiente de las aplicaciones: clientes, pedidos, productos, cuentas y las relaciones entre ellos. Pero un modelo conceptual solo es útil si los sistemas que lo necesitan realmente pueden consumirlo. Es por eso que CIM no se publica como un único artefacto propietario, sino como una familia de serializaciones, cada una de las cuales se dirige a una clase diferente de herramientas, tiempo de ejecución y audiencia.

Esta página explica qué es cada formato de CIM, para qué sirve y cómo elegir entre ellos. Si usted es un arquitecto de datos empresariales, un ingeniero de integración o ETL, un proveedor de aplicaciones o plataformas, o un colaborador de código abierto, el formato que elija primero dependerá de en qué parte del pipeline se encuentre.

Conclusiones clave

• CIM se distribuye en dos familias: formatos de web semántica (JSON-LD, RDF Schema, SHACL, R2RML) y formatos relacionales/legibles por humanos (vocabulario AML, dialecto AML, tipos RAML, JSON Schema, SQL DDL).
• El modelo conceptual (concepts.*) describe entidades y relaciones; el esquema canónico (schema.*) describe las formas y restricciones de los datos. Son artefactos separados con propósitos distintos.
• JSON-LD es la forma canónica legible por máquina; AML es la forma legible por humanos del mismo contenido; SQL DDL y JSON Schema son las formas que la mayoría de los equipos de aplicaciones y ETL consumen directamente.
• R2RML es el puente: mapea un esquema relacional a un grafo RDF, que es la forma de conectar las bases de datos SQL existentes a la capa semántica.
• Elegir un formato es una cuestión de consumidor, no de preferencia: elija el que su cadena de herramientas de destino ingiera de forma nativa y utilice los demás como verificaciones cruzadas.

Por qué CIM se distribuye en múltiples formatos

La mayoría de los modelos de datos se publican en una sola forma: generalmente un diagrama ER, una hoja de cálculo o un archivo de metadatos específico del proveedor. Esto funciona hasta que se necesita compartir el modelo entre organizaciones que utilizan diferentes pilas tecnológicas.

Una plataforma de retail podría ejecutar PostgreSQL y dbt; un socio podría ejecutar una base de datos de grafos y un triple store; un proveedor de SaaS podría exponer APIs JSON y validar payloads con JSON Schema. Si el modelo compartido solo existe en uno de esos dialectos, todos los demás tienen que traducirlo, y las traducciones divergen.

La estrategia multiformato de CIM es una respuesta deliberada a ese problema. El modelo se redacta una vez y luego se traduce a formatos que se mapean limpiamente con estándares reconocidos, para que cada consumidor adopte CIM utilizando las herramientas que ya posee.

Esta es la misma filosofía detrás de organismos de estándares como el World Wide Web Consortium (W3C), que publica especificaciones como RDF, SHACL y R2RML que CIM reutiliza en lugar de reinventar. También se alinea con la misión de interoperabilidad más amplia de la Linux Foundation, bajo la cual opera el proyecto CIM.

Relacionado: Fivetran — El proceso ELT totalmente gestionado que sigue funcionando.

El beneficio práctico es doble: las empresas con diversas tecnologías pueden adoptar CIM sin necesidad de un proceso de “rip-and-replace”, y los colaboradores pueden ampliar el modelo en cualquier formato que coincida con su experiencia, sabiendo que las otras serializaciones pueden regenerarse.

El modelo conceptual vs. el esquema canónico

Antes de comparar formatos de archivos, es útil separar dos capas que CIM mantiene distintas y que los recién llegados frecuentemente confunden.

• El modelo conceptual responde a qué existe y cómo se relaciona. Define entidades (Cliente, Pedido, Producto), sus atributos y las relaciones entre ellos. Es intencionalmente cercano al vocabulario de negocio y deliberadamente ligero en detalles físicos.
• El esquema canónico responde a cómo se ve una instancia válida. Agrega formas y restricciones de datos —cardinalidad, tipos, campos obligatorios, rangos de valores— contra los cuales un sistema puede validar.

En la distribución de CIM, estos se mapean a dos raíces de nombre de archivo: concepts.* para la capa conceptual y schema.* para la capa canónica. Mantenerlos separados significa que un analista de negocio puede leer el modelo conceptual sin tener que navegar por la sintaxis de restricciones, mientras que un ingeniero puede validar payloads contra el esquema sin necesitar la narrativa conceptual completa.

Nuestra elección: Workato — iPaaS basada en automatización que los equipos empresariales pueden aprovechar.

Los formatos de la web semántica

Estos formatos expresan CIM como un grafo basado en RDF. Son la elección correcta cuando sus consumidores incluyen triple stores, grafos de conocimiento, herramientas de ontología o cualquier sistema que razone sobre datos vinculados.

JSON-LD — concepts.json y schema.json

JSON-LD es JSON con un contexto de datos vinculados, lo que lo convierte en el puente pragmático entre las APIs web ordinarias y la web semántica. CIM publica dos artefactos JSON-LD:

• concepts.json: la descripción conceptual de entidades y relaciones, expresada como RDF Schema.
• schema.json: las formas de datos canónicas y restricciones adicionales, expresadas en SHACL.

Debido a que es JSON válido, concepts.json y schema.json pueden cargarse mediante herramientas JSON ordinarias, pero debido a que llevan un @context, también se expanden en triples RDF completos. Esa naturaleza dual es la razón por la que JSON-LD suele ser el mejor valor predeterminado para los equipos que desean fidelidad semántica sin adoptar una pila RDF especializada desde el primer día.

RDF Schema — schema.json

RDF Schema (RDFS) proporciona el vocabulario para describir clases y propiedades: las construcciones rdfs:Class, rdfs:subClassOf y rdfs:domain/rdfs:range que permiten a una máquina entender que un Pedido es un documento de negocio y que su propiedad de cliente apunta a un Cliente. CIM utiliza RDFS para darle al modelo conceptual una semántica formal, de modo que las jerarquías de subclases y los dominios de propiedades sean interpretables por máquina en lugar de simplemente estar documentados.

SHACL — schema.json

El Shapes Constraint Language (SHACL) es un estándar del W3C para validar grafos RDF frente a un conjunto de condiciones llamadas formas (shapes). Mientras que RDFS dice qué es una clase, SHACL dice qué debe satisfacer una instancia válida: propiedades requeridas, tipos de valores permitidos, límites de cardinalidad. Las formas de datos canónicas de CIM se expresan en SHACL, lo que significa que cualquier procesador SHACL puede validar datos conformes a CIM sin código personalizado.

R2RML — schema.rdml

R2RML es el estándar del W3C para mapear un esquema de base de datos relacional a un grafo RDF. Este es el formato que más importa a los ingenieros de integración y ETL, porque es el mecanismo mediante el cual una base de datos SQL existente —con sus tablas, columnas y claves foráneas— se expone como datos vinculados (linked data) conformes a CIM.

Relacionado: Matillion — ELT push-down creado para almacenes de datos en la nube.

En lugar de remodelar su base de datos operativa a mano, usted escribe (o genera) un mapeo R2RML que declara cómo cada tabla y columna corresponde a entidades y propiedades de CIM. El resultado es un grafo RDF virtual sobre sus datos relacionales existentes.

Los formatos legibles por humanos y relacionales

No todos los consumidores quieren RDF. Los desarrolladores de aplicaciones, modeladores de datos y DBAs a menudo quieren algo que puedan leer en un editor de texto o cargar directamente en una base de datos. CIM les proporciona las serializaciones AML, RAML, JSON Schema y SQL DDL.

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

AML, el linaje AnyLogic Modeling Language utilizado aquí como un dialecto de modelado, es la expresión legible por humanos de CIM. CIM publica tres artefactos AML:

Si estás de compras: Boomi AtomSphere — iPaaS empresarial para la integración híbrida de la nube a las instalaciones.

• concepts.yaml — el vocabulario AML, una versión legible por humanos del modelo conceptual.
• schema.yaml — el dialecto AML, una versión legible por humanos de las formas de datos canónicas.
• schema.raml — la representación de los tipos de datos RAML de las formas canónicas.

Vale la pena internalizar la distinción entre vocabulario y dialecto: el vocabulario define los términos (los sustantivos y verbos del modelo), mientras que el dialecto define cómo esos términos se combinan en estructuras válidas. Si está revisando CIM por primera vez, concepts.yaml suele ser el punto de entrada más accesible.

JSON Schema — schema.json

JSON Schema es el estándar de facto para validar documentos JSON, compatible de forma nativa o mediante bibliotecas en prácticamente todos los lenguajes modernos. El artefacto JSON Schema de CIM expresa las formas de datos canónicas como JSON Schema, lo que lo hace directamente utilizable en puertas de enlace de API, agentes de mensajes (message brokers) y canalizaciones de CI que ya validan cargas útiles JSON. Si su superficie de integración es REST o JSON basado en eventos, este suele ser el formato que desea.

SQL DDL — schema.sql

SQL DDL es el conjunto de sentencias CREATE TABLE, CREATE VIEW y de restricciones que materializan las formas canónicas en una base de datos relacional. CIM apunta a la sintaxis SQL 2008, lo que mantiene el DDL portátil entre los principales motores relacionales. Este es el formato que utilizan los DBAs y los ingenieros de ETL cuando quieren implementar un esquema físico que sea conforme a CIM; por ejemplo, una base de datos de preparación (staging) o de integración que refleje el modelo canónico.

Elegir un formato: una guía práctica

No existe un único formato “correcto”. La elección adecuada está determinada por quién o qué consumirá el modelo a continuación. Utilice la siguiente tabla como ayuda para la decisión.

Si su consumidor es…	Comience con…	Porque…
Un analista de negocio o modelador de datos revisando el modelo	Vocabulario AML (concepts.yaml)	Legible por humanos, prioriza el vocabulario de negocio
Un almacén de triples (triple store), grafo de conocimiento o herramienta de ontología	JSON-LD (concepts.json, schema.json)	RDF nativo con una rampa de acceso JSON
Un validador SHACL o una canalización semántica de calidad de datos	SHACL (schema.json)	Validación de restricciones estándar sobre RDF
Una base de datos relacional existente que desea exponer como datos vinculados	R2RML (schema.rdml)	Mapea tablas/columnas a entidades CIM sin remodelar
Una API JSON REST o basada en eventos	JSON Schema (schema.json)	Valida directamente las cargas útiles JSON
Una base de datos relacional que desea hacer conforme a CIM	SQL DDL (schema.sql)	DDL SQL 2008 portátil
Una API descrita en RAML	Tipos RAML (schema.raml)	Nativo de las cadenas de herramientas RAML

Algunas advertencias prácticas:

• No trate los formatos como modelos independientes. Son serializaciones del mismo CIM subyacente. Si encuentra una discrepancia entre, por ejemplo, schema.json (JSON Schema) y schema.json (SHACL), se trata de un error o un desfase de versión, no de una elección de diseño; infórmelo.
• Cuidado con las colisiones de nombres de archivos. Varios formatos comparten la raíz schema con diferentes extensiones (schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml). Al descargar la distribución completa, mantenga los directorios de formato separados para no sobrescribir una serialización con otra.
• Haga coincidir el formato con la etapa de validación. Utilice los formatos conceptuales para la revisión en tiempo de diseño y los formatos canónicos para la validación en tiempo de ejecución. Validar frente al modelo conceptual no tiene sentido, ya que carece de restricciones.
• Prefiera lo generado sobre lo editado a mano. Si extiende CIM, extienda la fuente y regenere las otras serializaciones en lugar de editar cada formato a mano, o de lo contrario la familia de formatos perderá la sincronización.

Descarga de la distribución completa de CIM

CIM se distribuye como una definición completa en cada formato disponible, para que pueda descargar el modelo entero en la serialización que necesite en lugar de ensamblarlo pieza por pieza. Las opciones de descarga publicadas son:

• AML (vocabulary) — el modelo conceptual legible por humanos.
• AML (dialect) — las formas canónicas legibles por humanos.
• JSON-LD (vocabulary & schema) — el modelo semántico legible por máquina.
• R2RML — el mapeo relacional a RDF.
• RAML Types — las formas canónicas como tipos de datos RAML.
• SQL DDL — las formas canónicas como SQL portátil.

Cada descarga contiene la definición completa de CIM en ese formato, lo que significa que puede adoptar CIM de forma incremental: comience con el formato que admita su cadena de herramientas actual y agregue otros a medida que crezcan sus necesidades de interoperabilidad.

Contribuciones en diversos formatos

Debido a que CIM es un proyecto abierto, las contribuciones son bienvenidas, y la estructura multiformato define cómo funcionan dichas contribuciones. Los contribuyentes suelen dividirse en dos grupos:

• Los contribuyentes del modelo proponen nuevas entidades, relaciones o restricciones. Estos cambios se redactan una vez y luego se propagan a las otras serializaciones.
• Los contribuyentes de formato mejoran la fidelidad o las herramientas de una serialización específica; por ejemplo, refinando los mapeos R2RML o la portabilidad de SQL DDL.

Si va a contribuir, la regla práctica es comprender qué capa está cambiando (conceptual frente a canónica) y qué formatos deben regenerarse como resultado. Los repositorios de GitHub del proyecto y el formulario web para contribuyentes son los puntos de entrada para involucrarse.

Preguntas frecuentes

¿Cuál es la diferencia entre concepts.json y schema.json en CIM?

concepts.json es el modelo conceptual: las entidades y relaciones en CIM, expresadas como JSON-LD con semántica de RDF Schema. schema.json es el esquema canónico: las formas de los datos y las restricciones adicionales, expresadas como JSON-LD con semántica SHACL. En resumen, concepts describe lo que existe; schema describe cómo debe verse una instancia válida.

¿Por qué CIM publica el mismo modelo en tantos formatos?

Porque diferentes consumidores utilizan diferentes tecnologías. Un triple store necesita RDF; una API JSON necesita JSON Schema; un DBA necesita SQL DDL; un analista de negocios necesita algo legible por humanos. Publicar CIM en múltiples formatos estándar permite que cada una de esas audiencias adopte el modelo con las herramientas que ya tienen, en lugar de imponer una sola pila tecnológica a todos.

¿Para qué se utiliza R2RML en CIM?

R2RML es el estándar del W3C para mapear un esquema de base de datos relacional a un grafo RDF. En CIM, es el puente que expone las bases de datos SQL existentes como datos vinculados conformes con CIM, para que pueda conectar sistemas relacionales operativos a la capa semántica sin tener que remodelarlos manualmente.

¿Es AML lo mismo que los formatos JSON-LD?

No. AML es la expresión legible por humanos de CIM: el vocabulario (concepts.yaml) y el dialecto (schema.yaml, schema.raml). JSON-LD es la expresión basada en RDF legible por máquina. Describen el mismo modelo pero se dirigen a diferentes audiencias y cadenas de herramientas.

¿Con qué formato de CIM debería empezar?

Depende de su perfil de consumidor. Si está revisando el modelo, comience con el vocabulario AML. Si está construyendo una API JSON, comience con JSON Schema. Si está conectando una base de datos relacional, comience con R2RML o SQL DDL. Si está trabajando con un grafo de conocimiento, comience con JSON-LD y SHACL.

¿Puedo editar un formato de CIM sin actualizar los demás?

Puede hacerlo, pero no debe. Los formatos son serializaciones de un único modelo subyacente, por lo que editar un solo formato a mano provoca que la familia de archivos se desincronice. En su lugar, extienda el modelo fuente y regenere las otras serializaciones.

Lectura adicional

• World Wide Web Consortium (W3C) — el organismo de estándares detrás de RDF, RDF Schema, SHACL y R2RML, las especificaciones en las que se basa CIM.
• Shapes Constraint Language (SHACL) — información general sobre el lenguaje de restricciones utilizado para las formas de datos canónicas de CIM.
• Linux Foundation — la fundación bajo la cual opera el proyecto CIM.