Estándares abiertos

¿Qué es Apache Ossie?

Jochen Christ

Co-Founder & CTO, Entropy Data · 2026-08-22

Apache Ossie es una especificación abierta y neutral respecto al proveedor para intercambiar metadatos semánticos entre plataformas de analítica, BI e IA. Describe qué significan tus datos en dos capas: los modelos semánticos, que se apoyan sobre las tablas y definen campos, joins y métricas, y las ontologías, que describen el propio negocio en términos de conceptos, relaciones y reglas. Define «Customer» o «Gross Merchandise Value» una sola vez y cada herramienta que lea el archivo, incluidos tus agentes de IA, entenderá lo mismo.

El problema que resuelve Ossie

Cada herramienta de datos tiene su propio lugar para guardar el significado. El warehouse tiene una capa semántica, la herramienta de BI tiene un modelo de datos, dbt tiene sus métricas, el CRM tiene sus propias definiciones de campos y el asistente de IA tiene un prompt con instrucciones. Ninguna lee a las demás. El resultado es que un concepto como «usuarios activos mensuales» o «ingresos netos» se define tres o cuatro veces, cada vez de forma ligeramente distinta, y nadie sabe decir qué cifra es la correcta.

Con los agentes de IA, esta fragmentación deja de ser una molestia y se convierte en un problema de corrección. Un agente que escribe SQL necesita saber que total_spent son los ingresos acumulados del cliente, que un pedido tiene muchas líneas y que el GMV se mide antes de los reembolsos. Si ese conocimiento vive en un formato propietario dentro de una herramienta, el agente no puede usarlo en ningún otro sitio.

La respuesta de Ossie es un único formato de archivo abierto para metadatos semánticos que cualquier herramienta puede leer y escribir. En palabras del propio proyecto:

Apache Ossie, industry wide specification effort to standardize how we exchange semantic metadata across analytics, AI and BI platforms, providing a vendor neutral, single source of truth for semantic data.

El resto de este artículo sigue los tres niveles del diagrama siguiente: el nivel conceptual, donde vive la ontología; el nivel lógico de productos de datos, Data Contracts y modelos semánticos; y las tablas y columnas físicas debajo. Ossie especifica los dos primeros.

De Open Semantic Interchange a Apache Ossie

El proyecto nació en 2025 como Open Semantic Interchange (OSI), lanzado por Snowflake con 17 socios fundadores. El repositorio público se abrió en noviembre de 2025. En julio de 2026 el proyecto fue aceptado en la Apache Incubator y pasó a llamarse Apache Ossie, sobre todo porque «OSI» ya pertenece a varios otros proyectos y estándares (el modelo de referencia ISO/OSI, entre otros). Para entonces, la coalición había crecido hasta más de 50 organizaciones, con contribuciones de código de Snowflake, Dremio, Salesforce, Databricks, dbt Labs, RelationalAI, GoodData y Entropy Data.

Entropy Data se unió al proyecto en junio de 2026 y contribuye al grupo de trabajo de ontología, que está construyendo la segunda capa de la especificación descrita más abajo.

Las especificaciones de Ossie

Apache Ossie es una familia de especificaciones. La versión actual es el borrador 0.2.0, que todavía no está cerrado: se esperan cambios menores antes de la publicación, así que toma los ejemplos de este artículo como una instantánea. Lo que existe hoy:

• Especificación de metadatos principal (core-spec). La parte original y más madura: modelos semánticos con datasets, campos, relaciones, métricas, contexto de IA y extensiones de proveedor. Se publica como especificación legible, como spec.yaml legible por máquina y como el schema osi-schema.json que se usa para la validación.
• Especificación de ontología (ontology). Conceptos, relaciones, reglas y los mapeos que conectan los conceptos con los campos de un modelo semántico, con su propio schema ontology.json. Es la capa que está construyendo el grupo de trabajo de ontología y a la que contribuye Entropy Data; el resto de este artículo la trata en detalle.
• Lenguaje de expresiones (propuesta). Un subconjunto portable de SQL para las expresiones de campos y métricas, de modo que una métrica no tenga que escribirse una vez por dialecto. Define las construcciones admitidas, la precedencia de operadores, las funciones de agregación obligatorias y cómo se resuelven los nombres. Sigue siendo una propuesta, elaborada por el grupo de trabajo Metric Language.

Modelos semánticos

El modelo semántico es la parte que la mayoría conoce por las herramientas de BI. Toma tablas físicas y les da estructura de negocio para la analítica dimensional: qué tablas son hechos y cuáles dimensiones, cómo se unen y qué métricas se definen sobre ellas. En términos de productos de datos, suele ser lo que un producto de datos orientado al consumidor expone a las herramientas de BI y a los agentes. Sus componentes:

• Datasets: tablas lógicas de hechos y dimensiones, cada una apuntando a un source físico y declarando sus claves primarias y únicas.
• Campos: las columnas de un dataset. Cada campo tiene una expresión, opcionalmente en varios dialectos (ANSI SQL, Snowflake, Databricks, BigQuery, Tableau, MDX, GoodData MAQL), un tipo de dato y un rol: dimensiones, dimensiones temporales o atributos simples.
• Relaciones: rutas de join entre datasets, declaradas como from / to con las columnas que se unen.
• Métricas: medidas agregadas como los ingresos totales o el número de clientes, de nuevo como expresiones multidialecto.
• Contexto de IA en el modelo, en un dataset, en un campo o en una métrica, y extensiones personalizadas para la configuración específica de cada proveedor.

Una versión recortada del ejemplo de e-commerce de la especificación:

version: 0.2.0.dev0
semantic_model:
  - name: ecommerce_analytics
    description: E-commerce sales and customer analytics
    ai_context:
      instructions: >-
        Use this model for analyzing sales trends,
        customer behavior, and product performance
    datasets:
      - name: orders
        source: sales.public.orders
        primary_key: [order_id]
        fields:
          - name: order_id
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: order_id
          - name: order_date
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: order_date
            datatype: Date
            dimension:
              is_time: true
          - name: amount
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: amount
      - name: customers
        source: sales.public.customers
        primary_key: [id]
    relationships:
      - name: orders_to_customers
        from: orders
        to: customers
        from_columns: [customer_id]
        to_columns: [id]
    metrics:
      - name: total_revenue
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: SUM(orders.amount)
        description: Total revenue from all orders
        ai_context:
          synonyms: ["total sales", "revenue"]

Esto basta para que una herramienta de BI construya un esquema en estrella, para que dbt genere una métrica y para que un agente de IA escriba una consulta de ingresos correcta. Lo que no dice es qué es un pedido, ni que el mismo cliente aparece también en el dataset del CRM con otra clave. Ese es el trabajo de la ontología.

Ontología

Una ontología, en el sentido de Ossie, es un modelo conceptual de los datos de la empresa. La especificación lo expresa así:

Ontologies are conceptual models of enterprise data that describe the enterprise in terms of concepts, relationships, and business rules.

La diferencia con un modelo semántico es el nivel de abstracción. Un modelo semántico está atado a los datasets: un campo es una expresión sobre columnas, una relación es un join. Una ontología habla del negocio sin referirse al almacenamiento. Un Customer es un concepto tanto si vive en Salesforce como en el warehouse o en ambos; un Customer realiza un Order es cierto con independencia de qué tabla contenga la clave foránea. Esa independencia es exactamente lo que hace portable a una ontología y lo que la hace útil para un agente de IA que tiene que razonar sobre varios sistemas.

Conceptos

Todo lo que hay en una ontología es un concepto, y un concepto es actualmente de uno de estos tipos:

• Un EntityType representa cosas del mundo real que no se pueden escribir directamente y deben referenciarse mediante otra información: una persona por su número de la seguridad social, un pedido por su ID de pedido. Otros lenguajes de modelado los llaman entidades o tipos de objeto.
• Un ValueType es un tipo de dato con semántica adicional: un número de la seguridad social es una cadena de exactamente nueve dígitos, un código de moneda es un código ISO 4217 de tres letras. Otros lenguajes los llaman dominios o tipos de dato.

Cada concepto extiende (extends) uno o más conceptos. Los tipos de valor acaban extendiendo uno de los tipos integrados; los tipos de entidad extienden otros tipos de entidad y, de forma implícita, el tipo integrado Any. Esto da a la ontología una jerarquía de subtipos: un Employee es una Person, una Billing Address es una Postal Address.

name: EnterpriseOntology
ontology:
  - concept: SocialSecurityNr
    type: ValueType
    extends: [Integer]
    requires: [ "0 < SocialSecurityNr", "SocialSecurityNr <= 999999999" ]
  - concept: Person
    type: EntityType
    identify_by: [ nr ]
    relationships:
      - name: nr
        roles:
          - concept: SocialSecurityNr
        multiplicity: OneToOne
        verbalizes: [ "{Person} is identified by {SocialSecurityNr}" ]
      - name: earns
        roles:
          - concept: Salary
        multiplicity: ManyToOne
        verbalizes: [ "{Person} earns {Salary}" ]
  - concept: Employee
    type: EntityType
    extends: [Person]
    derived_by: [ "EXISTS ( Person.earns )" ]

Relaciones, roles y verbalización

Las relaciones conectan conceptos. Cada relación se declara bajo el concepto que desempeña su primer rol y se identifica con el nombre de ese concepto más el suyo propio, así que las relaciones anteriores son Person.nr y Person.earns. Los demás participantes se listan como roles. Piensa en una relación como una tabla estrecha: sus enlaces son las filas, sus roles son las columnas y cada rol está tipado por un concepto.

Ossie admite relaciones n-arias, así que no se limitan a las binarias. Una relación unaria no tiene roles adicionales (Person files married filing joint), una ternaria tiene dos (Person purchased Vehicle on Date). Cuando el mismo concepto desempeña dos roles, como en Store ships to Store in NrDays, un nombre de rol como destination los distingue.

Los patrones verbalizes son un detalle pequeño con grandes consecuencias. Cada relación debe declarar cómo se lee un enlace en lenguaje natural, con marcadores para los roles: "{Customer} places {Order}". Esto es lo que permite a una herramienta, o a un LLM, convertir un grafo en frases y las frases de vuelta en navegación por el grafo. Las multiplicidades (ManyToOne, OneToOne) indican que el último rol queda determinado por los demás: cada persona percibe como mucho un salario.

Identificadores, derivaciones y reglas

• identify_by lista las relaciones que forman el identificador preferido de un concepto. Una persona se identifica por nr; una licencia puede identificarse por el par cuenta y número de asiento.
• derived_by convierte un concepto o una relación en una vista. El Employee de arriba es toda persona que percibe un salario. Una relación recursiva ancestor_of puede derivarse de parent_of con dos reglas, un caso base y un caso recursivo, igual que una consulta SQL deriva filas.
• requires añade restricciones que deben cumplirse sobre una población: un número de la seguridad social es positivo y tiene como máximo nueve dígitos, un importe de venta es mayor que cero, un artículo con ventas en una tienda debe ofrecerse en esa tienda.

En conjunto, esto hace que una ontología Ossie sea más que un glosario. Es un modelo computable: una herramienta puede comprobar las reglas, expandir las derivaciones y responder a «¿qué Persons son Employees?» sin que nadie haya escrito esa consulta.

Una ontología en la práctica: el ejemplo retail

Así es una ontología Ossie para un dominio real. Este extracto procede de la organización retail de demostración que acompaña a Entropy Data: la entidad Customer, el tipo de valor compartido Customer ID que la identifica, la relación con Order y la métrica Gross Merchandise Value que se mide sobre ella.

version: 0.2.0.dev0
name: main
description: Core business semantics for the demo retail organization.
ontology:
  - concept: Customer ID
    id: customer_id
    type: ValueType
    shared: true
    group: Customers
    description: |-
      The internal ID of any customer in the online shop.
      Guest customers have a customer ID as well.
    extends:
      - String
    classification: Confidential
    examples:
      - "c1-10123123"
    custom_properties:
      name@de: Kunden-ID
      name@fr: ID du client

  - concept: Customer
    id: customer
    type: EntityType
    group: Customers
    description: A natural person who places orders in the online shop.
    iri: http://www.entropy-data.com/ns/main/Customer
    custom_properties:
      owl:equivalentClass: http://schema.org/Person
      name@de: Kunde
      name@fr: Client
    relationships:
      - name: places
        description: A customer places one or more orders.
        roles:
          - concept: Order
        multiplicity: OneToMany
        verbalizes:
          - "{Customer} places {Order}"
      - name: customer_id
        type: hasProperty
        roles:
          - concept: Customer ID
      - name: customer_email
        type: hasProperty
        roles:
          - concept: Customer Email

  - concept: Gross Merchandise Value
    id: gmv
    type: MetricType
    group: Controlling
    description: |-
      Total value of all placed orders before refunds, returns, and discounts.
      The headline ecommerce KPI, commonly abbreviated as GMV.
    unit: EUR
    better_when: higher
    formula: "SUM(order.total_amount)"
    relationships:
      - name: measures
        type: measures
        roles:
          - concept: total_amount
        verbalizes:
          - "{Gross Merchandise Value} measures {total_amount}"

Algunas cosas que conviene observar. La estructura es la de Ossie: un documento con un name, una lista de conceptos bajo ontology, cada uno con un type, una cadena de extends hasta un tipo integrado y relaciones agrupadas bajo el concepto de su primer rol con roles, multiplicity y verbalizes. Sobre eso, Entropy Data añade algunas extensiones en los huecos que deja abiertos el borrador: los grupos y las métricas son tipos de concepto propios (GroupType, MetricType), las propiedades se asocian a las entidades mediante relaciones hasProperty, y custom_properties, una extensión de Entropy Data que no forma parte del borrador de Ossie, lleva las traducciones como claves con etiqueta de idioma (name@de) y la alineación con ontologías externas (owl:equivalentClass: http://schema.org/Person). El iri hace que cada concepto sea direccionable como recurso de la web semántica, de modo que la misma ontología puede importarse desde OWL o RDF y exportarse a esos formatos.

Modelo semántico frente a ontología

Necesitas ambos. El modelo semántico te da cifras correctas en una plataforma concreta; la ontología te da un vocabulario compartido entre plataformas y el razonamiento que los agentes de IA necesitan para encontrar, antes que nada, el producto de datos adecuado.

Apache Ossie en Entropy Data

Semantics en Entropy Data es un editor de ontologías construido sobre el borrador de ontología de Ossie. Los conceptos se organizan en namespaces y grupos, con entidades, propiedades compartidas y métricas lado a lado, y cada concepto enlaza con los productos de datos y los Data Contracts que lo implementan.

Cada concepto tiene una página de detalle con su descripción en varios idiomas, sus relaciones, sus propiedades con tipos de dato y clasificación, su IRI y su alineación externa, y los productos de datos relacionados con él.

Como la ontología se guarda en el formato Ossie, es portable. Puedes editar un namespace entero o un solo concepto como YAML en el navegador, exportarlo para guardarlo en Git, importarlo en otra instancia y escribirlo a través del servidor MCP, donde herramientas como semantics_save_ontology aceptan un documento Ossie para un namespace. Las ontologías OWL y RDF existentes, por ejemplo estándares del sector como EBUCore Plus, pueden importarse y se representan como conceptos Ossie con sus IRI originales. Y los agentes de Entropy Intelligence usan la misma ontología para resolver una pregunta de negocio hasta los productos de datos que la responden.

Cómo se relacionan ontologías, productos de datos, Data Contracts y modelos semánticos

Volvamos al diagrama de tres niveles del inicio del artículo. Las cuatro cosas que aparecen en él desempeñan papeles distintos, y conviene mantenerlas separadas:

• La ontología es el vocabulario compartido. Dice qué es un Customer, que un cliente realiza pedidos y que el Gross Merchandise Value es la suma de los importes de los pedidos antes de reembolsos. Se define una sola vez, pertenece al negocio y no dice nada sobre dónde se almacenan los datos ni qué herramienta los lee.
• Un producto de datos es la unidad de propiedad y entrega. Un equipo publica datos a través de uno o varios Output Ports, asume la responsabilidad sobre ellos y declara de qué conceptos de la ontología trata el producto. Se implementa con tablas, archivos o topics físicos.
• Un Data Contract es la especificación de un Output Port: el schema con sus campos y tipos, las reglas de calidad, los niveles de servicio y las condiciones de uso. Cada campo puede referenciar el concepto de la ontología que implementa, y así es como una columna como customer_id obtiene su significado, su clasificación y su lugar en el grafo.
• Un modelo semántico de BI es un modelo orientado al consumidor construido para el análisis: hechos, dimensiones, joins y métricas sobre uno o varios productos de datos, en Power BI, Snowflake, dbt o Tableau. Mapea sus métricas y dimensiones a la ontología para que «ingresos» en un dashboard signifique lo mismo que Gross Merchandise Value en todas partes.

Las relaciones van en una sola dirección. La ontología define el significado; los productos de datos y los modelos semánticos lo implementan; los Data Contracts son la especificación escrita que vincula una implementación con los conceptos; y las tablas físicas son donde viven los datos. Un modelo semántico suele leer de los Output Ports de los productos de datos, así que sus propias definiciones pueden derivarse de los Data Contracts que tiene aguas arriba, y en Entropy Data un modelo semántico es a su vez un producto de datos que puede ponerse bajo un Data Contract. Ossie estandariza las dos capas que llevan significado, la ontología y el modelo semántico, para que ambas puedan intercambiarse entre herramientas. ODPS y ODCS, de Bitol, estandarizan el producto de datos y sus Data Contracts.

Este modelo de relaciones es, por supuesto, una ontología en sí mismo, así que puede escribirse en Ossie. El extracto siguiente declara el concepto Data Contract con sus dos relaciones; el documento completo contiene los nueve conceptos en tres grupos, uno por nivel.

version: 0.2.0.dev0
name: ossie-meta
ontology:
  - concept: Data Contract
    type: EntityType
    group: logical-level
    description: The specification of an output port. Schema, quality rules, service levels, and terms of use. Specified by Bitol ODCS.
    relationships:
      - name: references
        description: Contract fields reference the concepts they implement via authoritativeDefinitions.
        roles:
          - concept: Concept
        multiplicity: OneToMany
        verbalizes:
          - "{Data Contract} references {Concept}"
      - name: describes
        description: The contract schema describes the physical columns.
        roles:
          - concept: Column
        multiplicity: OneToMany
        verbalizes:
          - "{Data Contract} describes {Column}"

Cargado en Entropy Data, el documento se convierte en un grafo navegable: los tres niveles son los grupos, los conceptos son los nodos y las aristas llevan los nombres de relación de los patrones verbalizes.

De los conceptos a los productos de datos: el enlace del Data Contract

Una ontología dice qué es un Customer. No dice dónde viven los datos de clientes, y no debería: el mismo concepto lo implementan varios productos de datos, en sistemas distintos y con schemas distintos. Algo tiene que establecer la conexión desde la capa conceptual hasta los datos físicos. En Entropy Data, ese algo es el Data Contract, que especifica el nivel lógico del diagrama de tres niveles de arriba.

El mecanismo ya existe en el Open Data Contract Standard: authoritativeDefinitions, una lista de URL tipadas que puede adjuntarse a casi cualquier elemento de un Data Contract. Entropy Data reconoce el tipo semantics y resuelve la URL a un concepto, ya sea por su dirección en Entropy Data (/semantics/{namespace}/{id}) o por el IRI del concepto. El enlace puede establecerse en tres niveles:

1. En un campo del schema del Data Contract: la columna SKU implementa el tipo de valor compartido Stock Keeping Unit.
2. En un objeto del schema o en el propio Data Contract: la tabla customers implementa la entidad Customer.
3. En un producto de datos, en su descripción ODPS, en la raíz o en un Input Port u Output Port: el producto Customer Cohorts trata de Customer.

Del Data Contract de artículos de la demo, dos campos que apuntan a sus conceptos:

schema:
  - name: articles
    properties:
      - name: SKU
        logicalType: string
        primaryKey: true
        authoritativeDefinitions:
          - type: semantics
            url: https://demo.entropy-data.com/my-organization/semantics/main/sku
      - name: BRAND_NAME
        logicalType: string
        description: The brand of the article
        authoritativeDefinitions:
          - type: semantics
            url: https://demo.entropy-data.com/my-organization/semantics/main/product.brand

Y el mismo enlace en un producto de datos, en su archivo ODPS:

apiVersion: v1.0.0
kind: DataProduct
id: customer-cohorts
authoritativeDefinitions:
  - type: semantics
    url: https://demo.entropy-data.com/my-organization/semantics/main/customer
inputPorts:
  - name: customers-latest-npii
    contractId: databricks_customers_latest_npii_v1
    authoritativeDefinitions:
      - type: semantics
        url: https://demo.entropy-data.com/my-organization/semantics/main/customer

Una vez que el enlace está en el Data Contract, Entropy Data lo usa en varios sitios. La página del Data Contract muestra cada campo enlazado con su concepto, y la clasificación del concepto viaja con él: un campo enlazado con Customer Email se marca como Restricted porque el concepto lo está, y la clasificación del propio Data Contract se deriva de los conceptos que enlaza y se recalcula cuando un concepto cambia. La página del concepto lista todos los productos de datos y Data Contracts que lo implementan, lo que convierte «¿qué datasets contienen direcciones de correo de clientes?» en una simple consulta. En el editor de Data Contracts, un selector encuentra el concepto adecuado para un campo, y una ejecución de sugerencias con IA propone enlaces para todas las propiedades de un Data Contract a la vez.

Para un agente de IA, este es el camino de la pregunta a la consulta. El agente resuelve los términos de negocio de la pregunta contra la ontología, sigue los enlaces de los Data Contracts desde los conceptos hasta los productos de datos que los implementan, lee el schema del Data Contract para encontrar las columnas físicas y solo entonces escribe SQL. Los mapeos de ontología de Ossie describen la misma conexión desde el lado de la ontología, campo a campo. Entropy Data la declara desde el lado de los datos, en el Data Contract, lo que mantiene estable la ontología mientras cualquier número de productos de datos puede indicar qué conceptos implementa.

Primeros pasos

• Lee la especificación de metadatos principal y la especificación de ontología en el repositorio apache/ossie, y valida tu primer archivo con el schema y las herramientas que encontrarás allí.
• Sigue las novedades del proyecto en ossie.apache.org; el sitio original opensemantic.com sigue presentando la idea de un modelo semántico independiente del proveedor.
• Prueba el editor de ontologías en la demo de Entropy Data: abre Studio, luego Semantics, y cambia cualquier concepto o el namespace entero a YAML.

Sobre el autor

Jochen Christ

LinkedIn de Jochen Christ

Co-Founder & CTO, Entropy Data

Jochen construye herramientas para que los datos, las personas y la IA trabajen juntos. Es autor del sitio Data Mesh Architecture, maintainer de la Data Contract CLI y miembro del TSC del proyecto Bitol de la Linux Foundation, hogar del Open Data Contract Standard.

Habla con Jochen →