Standards ouverts

Qu'est-ce qu'Apache Ossie ?

Jochen Christ

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

Apache Ossie est une spécification ouverte et indépendante des éditeurs pour échanger des métadonnées sémantiques entre plateformes d'analyse, de BI et d'IA. Elle décrit ce que vos données signifient, sur deux niveaux : les modèles sémantiques, qui reposent sur les tables et définissent les champs, les jointures et les métriques, et les ontologies, qui décrivent le métier lui-même en termes de concepts, de relations et de règles. Définissez « Client » ou « Gross Merchandise Value » une seule fois, et chaque outil qui lit le fichier, y compris vos agents IA, y met le même sens.

Le problème qu'Ossie résout

Chaque outil de données a son propre endroit pour stocker le sens. L'entrepôt a une couche sémantique, l'outil de BI a un modèle de données, dbt a ses métriques, le CRM a ses propres définitions de champs et l'assistant IA a un prompt avec des instructions. Aucun ne lit les autres. Résultat : un concept comme « utilisateurs actifs mensuels » ou « chiffre d'affaires net » est défini trois ou quatre fois, à chaque fois un peu différemment, et personne ne peut dire quel chiffre est le bon.

Avec les agents IA, cette fragmentation cesse d'être un désagrément et devient un problème d'exactitude. Un agent qui écrit du SQL doit savoir que total_spent est le chiffre d'affaires cumulé du client, qu'une commande comporte plusieurs lignes et que la GMV se mesure avant remboursements. Si cette connaissance vit dans un format propriétaire à l'intérieur d'un seul outil, l'agent ne peut l'utiliser nulle part ailleurs.

La réponse d'Ossie est un format de fichier unique et ouvert pour les métadonnées sémantiques, que n'importe quel outil peut lire et écrire. Le résumé du projet lui-même :

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.

La suite de cet article suit les trois niveaux du schéma ci-dessous : le niveau conceptuel, où vit l'ontologie ; le niveau logique des produits de données, des Data Contracts et des modèles sémantiques ; et, en dessous, les tables et colonnes physiques. Ossie spécifie les deux premiers.

De l'Open Semantic Interchange à Apache Ossie

Le projet a démarré en 2025 sous le nom d'Open Semantic Interchange (OSI), lancé par Snowflake avec 17 partenaires fondateurs. Le dépôt public a ouvert en novembre 2025. En juillet 2026, le projet a été accepté dans l'Apache Incubator et renommé Apache Ossie, principalement parce que « OSI » appartient déjà à plusieurs autres projets et normes (modèle de référence ISO/OSI…). Entre-temps, la coalition était passée à plus de 50 organisations, avec des contributions de code de Snowflake, Dremio, Salesforce, Databricks, dbt Labs, RelationalAI, GoodData et Entropy Data.

Entropy Data a rejoint le projet en juin 2026 et contribue au groupe de travail Ontologie, qui construit le second niveau de la spécification décrit ci-dessous.

Les spécifications Ossie

Apache Ossie est une famille de spécifications. La version actuelle est le brouillon 0.2.0, qui n'est pas encore finalisé : des changements mineurs sont attendus avant la publication, considérez donc les exemples de cet article comme un instantané. Ce qui existe aujourd'hui :

• Spécification des métadonnées de base (core-spec). La partie d'origine et la plus mature : des modèles sémantiques avec datasets, champs, relations, métriques, contexte IA et extensions propres aux éditeurs. Livrée sous forme de spécification lisible, d'un spec.yaml exploitable par les machines et du schéma osi-schema.json utilisé pour la validation.
• Spécification des ontologies (ontology). Concepts, relations, règles et les mappings qui relient les concepts aux champs d'un modèle sémantique, avec son propre schéma ontology.json. C'est le niveau que construit le groupe de travail Ontologie, celui auquel Entropy Data contribue ; la suite de cet article le traite en détail.
• Langage d'expressions (proposition). Un sous-ensemble portable de SQL pour les expressions de champs et de métriques, afin qu'une métrique n'ait pas à être écrite une fois par dialecte. Il définit les constructions prises en charge, la priorité des opérateurs, les fonctions d'agrégation obligatoires et la résolution des noms. Encore au stade de proposition, produite par le groupe de travail Metric Language.

Les modèles sémantiques

Le modèle sémantique est la partie que la plupart des gens connaissent par les outils de BI. Il prend des tables physiques et leur donne une structure métier pour l'analyse dimensionnelle : quelles tables sont des faits et des dimensions, comment elles se joignent et quelles métriques y sont définies. En termes de produits de données, c'est en général ce qu'un produit de données orienté consommateur expose aux outils de BI et aux agents. Les briques de base :

• Datasets : tables logiques de faits et de dimensions, chacune pointant vers une source physique et déclarant ses clés primaires et uniques.
• Champs : les colonnes d'un dataset. Chaque champ a une expression, éventuellement en plusieurs dialectes (ANSI SQL, Snowflake, Databricks, BigQuery, Tableau, MDX, GoodData MAQL), un type de données et un rôle : dimension, dimension temporelle ou simple attribut.
• Relations : chemins de jointure entre datasets, déclarés par from / to avec les colonnes de jointure.
• Métriques : mesures agrégées comme le chiffre d'affaires total ou le nombre de clients, là encore sous forme d'expressions multi-dialectes.
• Contexte IA sur le modèle, un dataset, un champ ou une métrique, et extensions personnalisées pour les réglages propres à un éditeur.

Une version abrégée de l'exemple e-commerce de la spécification :

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"]

C'est suffisant pour qu'un outil de BI construise un schéma en étoile, que dbt génère une métrique et qu'un agent IA écrive une requête de chiffre d'affaires correcte. Ce que cela ne dit pas, c'est ce qu'est une commande, ni que le même client apparaît aussi dans le dataset du CRM sous une autre clé. C'est le rôle de l'ontologie.

L'ontologie

Une ontologie, au sens d'Ossie, est un modèle conceptuel des données de l'entreprise. La spécification le formule ainsi :

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

La différence avec un modèle sémantique tient au niveau d'abstraction. Un modèle sémantique est lié à des datasets : un champ est une expression sur des colonnes, une relation est une jointure. Une ontologie parle du métier sans référence au stockage. Un Client est un concept, qu'il vive dans Salesforce, dans l'entrepôt ou dans les deux ; un Client passe une Commande est vrai quelle que soit la table qui porte la clé étrangère. Cette indépendance est précisément ce qui rend une ontologie portable et ce qui la rend utile à un agent IA qui doit raisonner sur plusieurs systèmes.

Les concepts

Tout, dans une ontologie, est un concept, et un concept est actuellement de l'un de ces types :

• Un EntityType représente des choses du monde réel qui ne peuvent pas être écrites directement et doivent être référencées par d'autres informations : une personne par son numéro de sécurité sociale, une commande par son identifiant. D'autres langages de modélisation les appellent entités ou types d'objets.
• Un ValueType est un type de données doté d'une sémantique supplémentaire : un numéro de sécurité sociale est une chaîne d'exactement neuf chiffres, un code devise est un code ISO 4217 à trois lettres. D'autres langages les appellent domaines ou types de données.

Chaque concept extends un ou plusieurs autres concepts. Les types de valeur finissent par étendre l'un des types intégrés ; les types d'entité étendent d'autres types d'entité et, implicitement, le type intégré Any. L'ontologie obtient ainsi une hiérarchie de sous-types : un Employé est une Personne, une Adresse de facturation est une Adresse postale.

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 )" ]

Relations, rôles et verbalisation

Les relations relient les concepts. Chaque relation est déclarée sous le concept qui joue son premier rôle et s'identifie par le nom de ce concept suivi du sien : les relations ci-dessus sont donc Person.nr et Person.earns. Les autres participants sont listés comme rôles. Imaginez une relation comme une table étroite : ses liens sont les lignes, ses rôles sont les colonnes, et chaque rôle est typé par un concept.

Ossie prend en charge les relations n-aires, qui ne se limitent donc pas au binaire. Une relation unaire n'a aucun rôle supplémentaire (Person files married filing joint), une relation ternaire en a deux (Person purchased Vehicle on Date). Quand le même concept joue deux rôles, comme dans Store ships to Store in NrDays, un nom de rôle tel que destination permet de les distinguer.

Les motifs verbalizes sont un petit détail aux grandes conséquences. Chaque relation doit déclarer comment un lien se lit en langage courant, avec des emplacements pour les rôles : "{Customer} places {Order}". C'est ce qui permet à un outil, ou à un LLM, de transformer un graphe en phrases et des phrases en navigation dans le graphe. Les multiplicités (ManyToOne, OneToOne) indiquent que le dernier rôle est déterminé par les autres : chaque personne perçoit au plus un salaire.

Identifiants, dérivations et règles

• identify_by liste les relations qui forment l'identifiant préféré d'un concept. Une personne est identifiée par nr ; une licence peut l'être par le couple compte et numéro de siège.
• derived_by transforme un concept ou une relation en vue. L'Employé ci-dessus est toute personne qui perçoit un salaire. Une relation récursive ancestor_of peut être dérivée de parent_of en deux règles, un cas de base et un cas récursif, comme une requête SQL dérive des lignes.
• requires ajoute des contraintes qui doivent tenir sur une population : un numéro de sécurité sociale est positif et compte au plus neuf chiffres, un montant de vente est supérieur à zéro, un article qui a des ventes dans un magasin doit y être proposé.

Ensemble, ces éléments font d'une ontologie Ossie bien plus qu'un glossaire. C'est un modèle calculable : un outil peut vérifier les règles, développer les dérivations et répondre à « quelles Personnes sont des Employés ? » sans qu'un humain ait écrit cette requête.

Une ontologie en pratique : l'exemple retail

Voici à quoi ressemble une ontologie Ossie pour un domaine réel. Cet extrait provient de l'organisation retail de démonstration livrée avec Entropy Data : une entité Customer, le type de valeur partagé Customer ID qui l'identifie, la relation vers Order et la métrique Gross Merchandise Value mesurée dessus.

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}"

Quelques points à noter. La structure est celle d'Ossie : un document avec un name, une liste de concepts sous ontology, chacun avec un type, une chaîne d'extends jusqu'à un type intégré, et des relations regroupées sous le concept de leur premier rôle avec roles, multiplicity et verbalizes. Par-dessus, Entropy Data ajoute quelques extensions aux endroits que le brouillon laisse ouverts : les groupes et les métriques sont des types de concept à part entière (GroupType, MetricType), les propriétés sont rattachées aux entités par des relations hasProperty, et custom_properties, une extension Entropy Data qui ne fait pas partie du brouillon Ossie, porte les traductions sous forme de clés étiquetées par langue (name@de) et l'alignement avec des ontologies externes (owl:equivalentClass: http://schema.org/Person). L'iri rend chaque concept adressable comme une ressource du web sémantique, de sorte que la même ontologie peut être importée depuis OWL ou RDF et exportée vers ces formats.

Modèle sémantique ou ontologie

Vous avez besoin des deux. Le modèle sémantique vous donne des chiffres corrects sur une plateforme donnée ; l'ontologie vous donne un vocabulaire partagé entre plateformes, et le raisonnement dont les agents IA ont besoin pour trouver le bon produit de données en premier lieu.

Apache Ossie dans Entropy Data

Semantics, dans Entropy Data, est un éditeur d'ontologie bâti sur le brouillon d'ontologie Ossie. Les concepts sont organisés en espaces de noms et en groupes, avec entités, propriétés partagées et métriques côte à côte, et chaque concept est relié aux produits de données et aux Data Contracts qui l'implémentent.

Chaque concept a une page de détail avec sa description en plusieurs langues, ses relations, ses propriétés avec types de données et classification, son IRI et son alignement externe, et les produits de données qui lui sont liés.

Parce que l'ontologie est stockée au format Ossie, elle est portable. Vous pouvez modifier un espace de noms entier ou un seul concept en YAML dans le navigateur, l'exporter pour le garder dans Git, l'importer dans une autre instance et l'écrire via le serveur MCP, où des outils tels que semantics_save_ontology acceptent un document Ossie pour un espace de noms. Les ontologies OWL et RDF existantes, par exemple des normes sectorielles comme EBUCore Plus, peuvent être importées et sont représentées comme des concepts Ossie avec leurs IRI d'origine. Et les agents d'Entropy Intelligence utilisent la même ontologie pour relier une question métier aux produits de données qui y répondent.

Comment ontologies, produits de données, Data Contracts et modèles sémantiques s'articulent

Retour au schéma en trois niveaux du début de l'article. Les quatre éléments qu'il contient jouent des rôles distincts, et il vaut la peine de les garder séparés :

• L'ontologie est le vocabulaire partagé. Elle dit ce qu'est un Client, qu'un client passe des commandes et que la Gross Merchandise Value est la somme des totaux de commandes avant remboursements. Elle est définie une fois, détenue par le métier, et ne dit rien sur l'endroit où les données sont stockées ni sur l'outil qui les lit.
• Un produit de données est l'unité de responsabilité et de livraison. Une équipe publie des données via un ou plusieurs Output Ports, en assume la responsabilité et déclare quels concepts de l'ontologie le produit concerne. Il est implémenté par des tables, des fichiers ou des topics physiques.
• Un Data Contract est la spécification d'un Output Port : le schéma avec ses champs et leurs types, les règles de qualité, les niveaux de service et les conditions d'utilisation. Chaque champ peut référencer le concept de l'ontologie qu'il implémente : c'est ainsi qu'une colonne comme customer_id obtient son sens, sa classification et sa place dans le graphe.
• Un modèle sémantique de BI est un modèle orienté consommateur, construit pour l'analyse : faits, dimensions, jointures et métriques sur un ou plusieurs produits de données, dans Power BI, Snowflake, dbt ou Tableau. Il fait correspondre ses métriques et ses dimensions à l'ontologie pour que « chiffre d'affaires » dans un tableau de bord signifie la même chose que Gross Merchandise Value partout ailleurs.

Les relations vont dans un seul sens. L'ontologie définit le sens ; les produits de données et les modèles sémantiques l'implémentent ; les Data Contracts sont la spécification écrite qui lie une implémentation aux concepts ; et les tables physiques sont là où vivent les données. Un modèle sémantique lit en général depuis les Output Ports de produits de données, de sorte que ses propres définitions peuvent être dérivées des contrats en amont, et dans Entropy Data un modèle sémantique est lui-même un produit de données qui peut être placé sous contrat. Ossie standardise les deux niveaux porteurs de sens, l'ontologie et le modèle sémantique, afin que les deux puissent s'échanger entre outils. ODPS et ODCS, de Bitol, standardisent le produit de données et ses contrats.

Ce modèle de relations est, bien sûr, lui-même une ontologie, et peut donc s'écrire en Ossie. L'extrait ci-dessous déclare le concept Data Contract avec ses deux relations ; le document complet contient les neuf concepts répartis en trois groupes, un par niveau.

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}"

Chargé dans Entropy Data, le document devient un graphe navigable : les trois niveaux sont les groupes, les concepts sont les nœuds, et les arêtes portent les noms de relations issus des motifs verbalizes.

Des concepts aux produits de données : le lien par le Data Contract

Une ontologie dit ce qu'est un Client. Elle ne dit pas où vivent les données client, et elle ne le doit pas : le même concept est implémenté par plusieurs produits de données, dans des systèmes différents, avec des schémas différents. Quelque chose doit faire le lien entre la couche conceptuelle et les données physiques. Dans Entropy Data, ce quelque chose est le Data Contract, qui spécifie le niveau logique du schéma en trois niveaux ci-dessus.

Le mécanisme existe déjà dans l'Open Data Contract Standard : authoritativeDefinitions, une liste d'URL typées qui peut être rattachée à presque n'importe quel élément d'un contrat. Entropy Data reconnaît le type semantics et résout l'URL vers un concept, soit par son adresse Entropy Data (/semantics/{namespace}/{id}), soit par l'IRI du concept. Le lien peut être posé à trois niveaux :

1. Sur un champ du schéma d'un contrat : la colonne SKU implémente le type de valeur partagé Stock Keeping Unit.
2. Sur un objet du schéma ou sur le contrat : la table customers implémente l'entité Customer.
3. Sur un produit de données, dans sa description ODPS, à la racine ou sur un Input Port ou Output Port : le produit Customer Cohorts concerne Customer.

Dans le contrat articles de démonstration, deux champs qui pointent vers leurs concepts :

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

Et le même lien sur un produit de données, dans son fichier 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

Une fois le lien dans le contrat, Entropy Data l'exploite à plusieurs endroits. La page du contrat affiche chaque champ relié avec son concept, et la classification du concept voyage avec lui : un champ relié à Customer Email est marqué Restricted parce que le concept l'est, et la classification du contrat lui-même est dérivée des concepts qu'il relie, puis recalculée quand un concept change. La page du concept liste chaque produit de données et chaque contrat qui l'implémente, ce qui transforme « quels datasets contiennent des adresses e-mail de clients ? » en simple recherche. Dans l'éditeur de contrats, un sélecteur trouve le bon concept pour un champ, et une passe de suggestions par IA propose des liens pour toutes les propriétés d'un contrat en une fois.

Pour un agent IA, c'est le chemin qui mène d'une question à une requête. L'agent résout les termes métier de la question dans l'ontologie, suit les liens des contrats depuis les concepts jusqu'aux produits de données qui les implémentent, lit le schéma du contrat pour trouver les colonnes physiques, et seulement alors écrit le SQL. Les mappings d'ontologie d'Ossie décrivent la même connexion du côté de l'ontologie, champ par champ. Entropy Data la déclare du côté des données, dans le contrat, ce qui garde l'ontologie stable tandis qu'un nombre quelconque de produits de données peuvent indiquer quels concepts ils implémentent.

Pour commencer

• Lisez la spécification des métadonnées de base et la spécification des ontologies dans le dépôt apache/ossie, et validez votre premier fichier avec le schéma et les outils qui s'y trouvent.
• Suivez les actualités du projet sur ossie.apache.org ; le site d'origine opensemantic.com présente toujours l'idée d'un modèle sémantique indépendant des éditeurs.
• Essayez l'éditeur d'ontologie dans la démo Entropy Data : ouvrez Studio, puis Semantics, et basculez n'importe quel concept ou l'espace de noms entier en YAML.

À propos de l'auteur

Jochen Christ

LinkedIn de Jochen Christ

Co-Founder & CTO, Entropy Data

Jochen construit des outils pour faire travailler ensemble les données, les gens et l'IA. Il est l'auteur du site Data Mesh Architecture, mainteneur de la Data Contract CLI et membre du TSC du projet Bitol de la Linux Foundation, qui héberge l'Open Data Contract Standard.

Échanger avec Jochen →