Trois fournisseurs, trois decks, trois mots pour la chose qui se tient entre l’agent et vos données. L’un vend une couche sémantique, l’autre une ontologie, le troisième un graphe de connaissances. Les mots ne sont pas interchangeables, et la différence entre eux n’est pas celle que dessinent les decks. C’est la différence entre une métrique, une déclaration et un enregistrement, et entre ce que vous configurez et ce que vous possédez.
Trois mots, trois questions
La distinction est établie, et les éditeurs de catalogues de données l’énoncent bien. Une couche sémantique répond à « comment calcule-t-on cette métrique » : elle projette la logique métier sur les données pour que le chiffre d’affaires soit calculé de la même façon dans chaque outil.[1] Une ontologie répond à « quelles sont les choses de notre métier et comment sont-elles reliées » : elle définit les entités et leurs relations dans un schéma formel, lisible par la machine.[1:1] Atlan tient en une ligne : une couche sémantique vous dit ce qu’est votre chiffre d’affaires, une ontologie vous dit ce qu’est un client.[1:2] Alation trace la même ligne depuis l’autre côté : la couche sémantique répond à « quel est le nombre », l’ontologie définit ce qui doit se passer ensuite quand un événement survient.[2]
Un graphe de connaissances est une troisième chose. L’ontologie définit le schéma ; le graphe stocke les instances, et c’est lui qui rend possibles la recherche entre entités, le lignage et le parcours des relations.[1:3] L’une est la déclaration. L’autre est l’enregistrement.
Nous sommes d’accord. Le désaccord commence à la question que les decks sautent : qui écrit l’ontologie, et qu’est-ce qu’elle oblige ?
Ce que l’agent attend de la couche sémantique
Un chiffre calculé de la même façon à chaque fois. Atlan appelle cela un accès gouverné et déterministe aux métriques, et prévient qu’un agent qui ne s’appuie que sur une couche sémantique produit des résultats précis mais superficiels.[1:4] La couche sémantique sait additionner la colonne. Elle ne sait pas de quoi la colonne est la colonne, si le client du CRM est le compte du grand livre, ni pourquoi les dix-sept exceptions existent. On ne peut pas observer ce dont on n’a pas le concept.[3] Un agent qui tient une formule et aucun modèle du métier a de l’arithmétique et pas d’orientation. Il calculera correctement la mauvaise chose.
Ce que l’agent attend de l’ontologie
Entités, relations, actions, règles, et les cas limites qui consomment l’essentiel du travail : énoncés explicitement, dans le vocabulaire de ceux qui font le travail, et contraignants pour la machine.[4] Pas inférés des données, qui n’enregistrent que ce qui a été mesuré. Pas devinés par un modèle, qui comblera la structure manquante par une invention fluide. Déclarés, versionnés, contestés et possédés.
Deux mots portent l’argument. Le premier est contraignant. Un vocabulaire que l’agent peut consulter est un dictionnaire. Un vocabulaire dont l’agent ne peut pas sortir est une contrainte, et seule une contrainte rend une action assez prévisible pour qu’une personne nommée la signe. Le second est possédé. L’ontologie est le seul artefact que le métier et les ingénieurs éditent tous les deux, et c’est là, et seulement là, qu’ils cessent d’être deux populations.[4:1] Une ontologie que les opérateurs ne peuvent pas éditer est une spécification à leur sujet, écrite par quelqu’un d’autre.
Le graphe de connaissances est l’endroit où la déclaration rencontre l’enregistrement. Un graphe sans ontologie est un tas d’arêtes. Un graphe sous une ontologie déclarée est un territoire : chaque nœud est l’instance de quelque chose que l’institution a nommé, chaque relation en est une qu’elle a énoncée, et chaque chiffre remonte à la ligne dont il vient.
Pourquoi l’ontologie doit être la vôtre
Ici nous quittons les éditeurs, sur la propriété, pas sur les définitions.
Les modèles convergent, et vite. Le calcul a une grille tarifaire. Le talent bouge. Ce qui ne voyage pas, c’est le modèle déclaré de vos propres opérations : vos entités, vos règles, les exceptions qui existent à cause d’un incident en 2011 et d’une lettre du régulateur en 2019, les mots que vos gens emploient à l’atelier.[5] Et cela se capitalise : chaque exception résolue rejoint l’actif, et chaque règle rendue explicite contraint chaque agent qui suit.[5:1]
Un fournisseur qui tient ce modèle comme configuration dans son produit tient votre dernier avantage défendable comme une ligne de son renouvellement. Quand le produit part, la configuration part, et avec elle la raison pour laquelle le processus existe. Les successeurs conservent un processus et en perdent la raison ; c’est ainsi qu’une institution devient cérémonielle sans s’en apercevoir.[6] Une ontologie écrite, dans votre vocabulaire, sous une forme que vous pouvez emporter, est le seul instrument qui survit aux gens qui la détiennent.
Alation propose une couche de plus au-dessus de l’ontologie, une couche de contexte d’entreprise, qui dit à l’agent comment traiter l’arbitrage et s’améliore à partir des interactions de l’agent lui-même.[2:1] Nous déclinons la prémisse. Une règle qu’un agent a apprise de son propre comportement est une règle que personne n’a déclarée et que personne n’a signée. L’arbitrage appartient à une personne nommée. La règle qui l’a tranché appartient à l’ontologie, écrite par ceux qui font le travail, et contraignante pour l’agent suivant.
Ce que Galahad refuse de faire
Nous n’inférons pas votre ontologie de vos données. Nous ne laissons pas un modèle deviner la structure que vos systèmes n’ont pas enregistrée. Nous ne tenons pas le modèle de votre entreprise comme notre configuration : un déploiement, une ontologie, une organisation, détenue comme une chose que vous possédez et pouvez inspecter, et non comme des poids dans un modèle loué.[7] Si elle ne peut pas partir avec vous, elle n’a jamais été à vous.
Les questions à poser au fournisseur
- Montrez-moi l’ontologie. Est-ce un document que je peux lire, versionner et exporter, ou un réglage dans votre produit ?
- Qui l’édite : mes opérateurs, vos consultants, ou un modèle ?
- Le vocabulaire est-il contraignant pour l’agent, ou indicatif ?
- Quand l’agent rencontre un cas que l’ontologie ne contient pas, que fait-il, et qui est prévenu ?
- Si je mets fin au contrat, qu’est-ce qui part avec moi ?
Monarch est construit sur une ontologie que vous possédez : vos entités, vos règles, les mots de vos opérateurs. Voyez-le sur vos données.
Atlan, Ontology vs semantic layer : les ontologies définissent les concepts et relations du domaine dans un schéma formel, lisible par la machine ; les couches sémantiques projettent la logique métier sur les données pour des métriques cohérentes ; un graphe de connaissances stocke les instances que l’ontologie définit ; les couches sémantiques donnent un accès gouverné et déterministe aux métriques et, seules, des résultats précis mais superficiels. Source ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
Alation, Semantic layer vs ontology vs enterprise context layer : la couche sémantique répond à « quel est le nombre », l’ontologie définit ce qui doit se passer ensuite quand un événement survient, et la couche de contexte d’entreprise livre aux agents autonomes le contexte de l’arbitrage et s’améliore à partir de leurs interactions. Source ↩︎ ↩︎
Galahad, l’entreprise : un déploiement, une ontologie, une organisation ; l’ontologie détenue comme une chose que vous possédez et pouvez inspecter, et non comme des poids dans un modèle loué. Le lire ↩︎