Funcionalidad
Semantics: conecta el negocio con tus productos de datos
Jochen Christ
Co-Founder & CTO, Entropy Data ·
Un esquema te dice cómo se almacenan los datos. Una capa semántica te dice qué significan. En esta página verás qué es una capa semántica, cómo la modela la funcionalidad Semantics de Entropy Data y cómo la ontología resultante se conecta con los productos de datos y los Data Contracts.
El problema
La mayoría de las plataformas de datos te dicen bien qué tabla, qué columna y qué tipo. Mucho peor te dicen qué significa todo eso. Y las preguntas que frenan a los equipos suelen ser justo las del segundo tipo:
- Tres equipos tienen una columna
customer_id. ¿Se refieren a los mismos clientes? ¿Incluyen las compras sin registro? - Finanzas y Producto informan del Gross Merchandise Value y las cifras no cuadran. ¿Qué fórmula es la buena?
- Una analista recién incorporada necesita datos de seguimiento de envíos. Buscar «shipment» en una docena de esquemas devuelve cuarenta columnas. ¿Cuáles son las canónicas?
Son problemas de semántica, no de esquema, y se agravan a medida que crecen el número de productos de datos, de equipos y de herramientas de IA.
Qué es una capa semántica
Una capa semántica es una definición de tu dominio con nombre propio y gobernada, independiente de cualquier tabla o sistema concreto. Se construye con dos elementos principales:
- Conceptos: las cosas de tu negocio, es decir, entidades, propiedades y métricas.
- Relaciones: cómo se conectan esos conceptos entre sí y con los campos de un Data Contract.
Conceptos
Cada concepto tiene un ID estable, un nombre legible, una descripción y un IRI para poder referenciarlo desde herramientas externas. Por ejemplo, el concepto Editorial Object de EBU Core Plus tiene este IRI:
http://www.ebu.ch/metadata/ontologies/ebucoreplus#EditorialObject
Los conceptos viven en namespaces (el predeterminado es main) y son de cuatro tipos:
- Entity (
EntityType): los sustantivos de tu dominio. Cliente, Pedido, Artículo, Envío. - Property (
ValueType): un atributo con un tipo primitivo. Marcado conshared: truese convierte en una propiedad compartida reutilizable que se asocia a una o varias entidades: Email del cliente, SKU, ID de pedido. Se define una vez y se referencia desde varios sitios. - Metric (
MetricType): una magnitud medible con su unidad, una dirección de «mejor cuando» y una fórmula opcional. Gross Merchandise Value, tasa de conversión, tiempo de preparación del pedido. - Group (
GroupType): un contenedor para organizar los conceptos por dominio o área temática. Ventas, Logística, Catálogo, Controlling.
Los conceptos llevan los metadatos de los que dependen la gobernanza y las herramientas de IA: tipo de dato, clasificación (por ejemplo PII, sensible, restringido), marcas de obligatorio y único, ejemplos, enumeraciones, expresiones regulares, nombres y descripciones en varios idiomas y etiquetas.
Conceptos en YAML
La ontología completa se puede editar como YAML, algo muy práctico para cambios masivos, revisiones de código y mantener la ontología en Git. Cada concepto tiene además su propio editor YAML individual. El formato sigue la especificación de ontología de Apache Ossie. Este es un extracto de la ontología de retail de la demo:
version: 0.2.0.dev0
name: main
ontology:
- concept: Order
id: order
type: EntityType
group: Sales
description: A confirmed purchase placed by a customer in the online shop.
custom_properties:
owl:equivalentClass: http://schema.org/Order
relationships:
- name: order_id
type: hasProperty
roles:
- concept: Order ID
- name: customer_id
type: hasProperty
roles:
- concept: Customer ID
- name: order_status
type: hasProperty
roles:
- concept: order_status
- name: currency
type: hasProperty
roles:
- concept: currency
- concept: order_status
id: order.order-status
type: ValueType
extends:
- String
description: Lifecycle state of the order.
enum: [pending, confirmed, shipped, delivered, cancelled, returned]
- concept: currency
id: order.currency
type: ValueType
extends:
- String
description: ISO 4217 currency code of the order total.
pattern: ^[A-Z]{3}$
examples: [EUR, USD]
Merece la pena fijarse en tres detalles. Una entidad referencia sus propiedades mediante relaciones hasProperty: Order ID y Customer ID son propiedades compartidas, definidas una sola vez con shared: true y reutilizadas en varias entidades, mientras que order_status y currency son propiedades del pedido, cada una como componente ValueType propio. Una propiedad expresa su tipo de dato extendiendo un tipo de valor integrado como String, Decimal o DateTime. Y la entrada owl:equivalentClass en custom_properties alinea el concepto con una ontología externa (schema.org en este caso), de modo que el modelo interno sigue siendo interoperable con estándares como GoodRelations o FIBO.
Métricas con fórmula
Una métrica registra su unidad, la dirección en la que mejora y cómo se calcula. Así, Finanzas, Producto y las herramientas de IA parten de una única definición.
ontology:
- concept: Gross Merchandise Value
id: gmv
type: MetricType
group: Controlling
description: Total value of all placed orders before refunds, returns, and discounts.
unit: EUR
better_when: higher
formula: "SUM(order.total_amount)"
- concept: Average Order Value
id: average_order_value
type: MetricType
group: Sales
unit: EUR
better_when: higher
formula: "SUM(order.total_amount) / COUNT(DISTINCT order.id)"Relaciones
Los conceptos se conectan entre sí mediante relaciones dirigidas y tipadas. Los tipos habituales son hasProperty, relatedTo, measures y derived_from; el subtipado se expresa con extends. Una relación se declara en el concepto que desempeña su primer rol, así que ese concepto queda implícito: roles solo lista los demás participantes, y verbalizes recoge patrones en lenguaje natural que los agentes de IA pueden aprovechar.
ontology:
- concept: Customer
relationships:
- id: customer_places_order
name: places
type: relatedTo
roles:
- concept: Order
multiplicity: OneToMany
verbalizes:
- "{Customer} places {Order}"
- concept: Average Order Value
relationships:
- id: aov_derived_from_gmv
name: derived_from
type: derived_from
roles:
- concept: Gross Merchandise Value
verbalizes:
- "{Average Order Value} derived from {Gross Merchandise Value}"La página de cada concepto muestra las aristas entrantes y salientes, así que puedes recorrer la ontología en ambos sentidos. La vista de diagrama que abre esta página representa ese mismo namespace como un grafo interactivo, con desplazamiento, zoom y acceso directo desde cualquier nodo a su página de concepto.
Traducciones en varios idiomas
Cada concepto, propiedad y relación puede llevar traducciones de su nombre y su descripción en tantos idiomas como quieras. Las traducciones se guardan como entradas de custom_properties etiquetadas por idioma, como name@de o description@fr, se exponen a través del endpoint SPARQL y se muestran en la interfaz según el idioma preferido del usuario. Una sola ontología puede servir, desde la misma fuente, a analistas en inglés, product managers en francés y auditores en alemán.
ontology:
- concept: Customer
id: customer
type: EntityType
group: Customers
description: A natural person who places orders in the online shop.
custom_properties:
name@de: Kunde
name@fr: Client
description@de: Eine natürliche Person, die Bestellungen im Online-Shop aufgibt.
description@fr: Une personne physique qui passe des commandes dans la boutique en ligne.Las ontologías sectoriales que incluye Entropy Data vienen ya traducidas. EBU Core Plus, por ejemplo, trae etiquetas y descripciones en inglés, alemán y francés para cada clase y propiedad.
Enlazar productos de datos y Data Contracts
Una capa semántica solo sirve de algo si los datos que la implementan apuntan de vuelta a ella. Entropy Data usa el mecanismo authoritativeDefinitions del Open Data Contract Standard para conectar los conceptos con los datos que los implementan en tres niveles:
- En un producto de datos (ODPS), representando el producto de datos en su conjunto.
- En un Data Contract o en uno de sus objetos de esquema.
- En un campo concreto dentro del esquema de un contrato.
Ese mismo enlace se puede escribir directamente en el YAML de ODCS. Extraído de un contrato de envíos de la demo:
properties:
- name: shipment_id
businessName: Shipment ID
logicalType: string
primaryKey: true
authoritativeDefinitions:
- type: "semantics"
url: "https://demo.entropy-data.com/my-organization/semantics/main/shipment_id"
- name: order_id
authoritativeDefinitions:
- type: "semantics"
url: "https://demo.entropy-data.com/my-organization/semantics/main/order_id"
El marcador type: "semantics" le indica a Entropy Data que la URL resuelve a un concepto semántico, y el enlace se muestra como una referencia navegable en la página del contrato. En la página del concepto, Entropy Data lista todos los productos de datos y Data Contracts que lo referencian, así que preguntas como «¿qué conjuntos de datos contienen direcciones de email de clientes?» se responden de inmediato.
Para qué sirve Semantics
Descubrimiento por significado
Los consumidores buscan Envío y encuentran todos los productos de datos que implementan ese concepto, sin importar cómo se llamen las columnas subyacentes.
Definiciones coherentes entre equipos
Una única definición de Email del cliente referenciada desde varios Data Contracts. Si cambias su clasificación a sensible, la actualización llega a todas las referencias.
Una única fuente de verdad para las métricas
El GMV, la tasa de conversión y los márgenes de contribución tienen definiciones canónicas con fórmula, lo que elimina la ambigüedad que se acumula en las hojas de cálculo.
Contexto para los agentes de IA
Los LLM no saben qué entiende tu negocio por Cliente activo o Margen de contribución 2. Cuando los agentes acceden a los datos a través de nuestro servidor MCP, Semantics les aporta ese contexto: hacen el join por las claves correctas y usan las definiciones de métrica correctas.
Empieza con una ontología sectorial
No hace falta que modeles tu dominio desde cero. Entropy Data incluye ontologías listas para importar de varios sectores. Abre Studio, entra en Semantics y usa Add → Import Industry Standard:
- GoodRelations (comercio electrónico)
- FIBO (finanzas)
- EBU Core Plus (medios)
- CGMES (energía)
- IDMP (farmacéutica)
- EPCIS (cadena de suministro)
- IATA ONE Record (carga aérea)
- TM Forum SID (telecomunicaciones)
También puedes subir tus propios archivos RDF/OWL (Turtle, OWL, RDF/XML, N-Triples, N3, JSON-LD) o consultar la ontología mediante programación desde el endpoint SPARQL en /api/semantics/sparql.
Estándares abiertos: Apache Ossie
Entropy Data apuesta por los estándares abiertos para la capa semántica y se ha unido al proyecto Apache Ossie, antes conocido como la iniciativa Open Semantic Interchange (OSI). Apache Ossie es un proyecto open source e independiente de fabricantes que estandariza cómo se intercambian los modelos semánticos entre plataformas de BI, agentes de IA y herramientas de analítica, de forma que una misma definición de entidad o de métrica se mantenga coherente en todo tu ecosistema. Daremos soporte nativo al futuro estándar Ossie Ontology dentro de Semantics, junto al que ya ofrecemos para el Open Data Contract Standard y el Open Data Product Standard de Bitol en el lado de los Data Contracts y los productos de datos.
Cómo encaja Semantics en el resto de Entropy Data
- Marketplace usa los conceptos semánticos para el descubrimiento.
- Studio es donde los expertos de negocio y los Data Product Owners curan los conceptos y los enlazan con los contratos.
- Governance reutiliza las clasificaciones semánticas (PII, sensible, etcétera) en políticas transversales.
- El servidor MCP usa Semantics para anclar las llamadas de herramientas de los LLM a tu vocabulario de negocio.
Primeros pasos
Semantics está disponible detrás de un feature flag:
- Entropy Data Cloud: escríbenos y lo activamos para tu organización.
- Self-hosted: pon
APPLICATION_SEMANTICS_ENABLED=truey reinicia la aplicación.
Para probar Semantics sin instalar nada, abre la demo y entra en Studio → Semantics. La demo trae los principales estándares sectoriales: ve a Studio → Semantics → Add → Import Ontology para explorarlos o para subir tu propia ontología.
Sobre el autor
Jochen Christ
LinkedIn de Jochen ChristCo-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.