Meuh fait le poussin qui regarde le serpent sa maman. Tout va bien ! Mais après cet article vous penserez pareil !
Partageons les nouveautés du sujet ontologique
En résumé, la moulinette Comitards vers Folkopedia fonctionne avec une croissance folle de +20x (en gros), et ça met quasi 2h… Plus de 90% des tables sont converties ou ignorées à propos et l’explorateur de fortune que j’ai fait montre bien le contenu de l’ontologie.
Le hic ? Beaucoup de « todo », de « on verra plus tard », de mise de côté, etc. Et si on veut avancer il faut légiférer, se décider, acter !
On a également Folkopedia qui est trop conscient de son ontologie, et je pense qu’il faut scinder. D’un côté Folkopedia qui gère son business et d’un autre un service ontologique qui gère son contenu structuré, ses caches, sa recherche, etc.
L’oeuf ?
Par où est-ce qu’on commence ? Un exemple de Personne et tenter de le faire rentrer dans l’ontologie en passant par la couche orientée objet ? Ou par des tuples de l’ontologie que l’on veut faire rentrer dans une classe Java ?
Comment rester générique en manipulant du spécifique selon les couches où on se trouve ? Là je me suis perdu, car actuellement le projet de moulinette et d’exploration de contrôle mélange tout sous forme de définitions incomplètes.
- Qu’est-ce qu’un Prédicat ?
- Est-ce que le Prédicat est un modèle de ses possibilités à définir ?
- Est-ce que le Prédicat est une Entité qui possède à son tour des « propriétés » Prédicat ?
- Quel est le lien entre Tuple, Sujet, Prédicat, Entité et Modèle ?
- Comment donner du sens à une classe Java avec une structure variante et basée sur un tronc commun ?
- Quelle partie du projet doit gérer quelle partie de l’ontologie et à quelle niveau d’abstraction ?
- Qu’est-ce qu’une poule ?
Pourquoi ces questions alors que la moulinette fonctionne ? Tout simplement car la moulinette map un contenu vers un autre en essayant d’injecter le nécessaire de fonctionnement (Prédicat), et ce au niveau directement ontologique via des mapper.
Actuellement le Prédicat est un lien entre un enum et un uuid avec une structure encodée de son uuid, nom et description générés. À l’usage on s’en sert pour afficher le nom lisible au lieu d’un uuid. Mais nous ne connaissons pas le type de donnée (datatype) de ce Prédicat, ni ses paramètres (longueur min et max, pattern, …).
Un Prédicat doit, à terme, permettre le contrôle de la valeur reçue, donner les indications de génération d’un champs de formulaire et expliquer son rôle dans la vie de la donnée valeur. Il est à la fois un indicateur de donnée, son descriptif et son contrôle, tout en se distinguant des autres et en étant réutilisable ailleurs.
Une poule ?
Un Prédicat est une Entité avec un datatype en plus, pour résumer. On aura donc le Prédicat qui hérite de l’Entity pour se compléter.
D’un autre côté, l’Entité est une racine de toute chose pour notre structure ontologique. Elle détermine le type, le nom et une description de son rôle/but. Et donc type, nom et description sont les Prédicats de cette Entité (sujet).
Là, normalement, vous voyez l’oignon qu’on va se manger : une boucle déclarative.
En terme ontologique, et en pensant atomique (tout en une fois) on peut représenter cette état Entité <-> Prédicat intrinsèquement liés, mais pas en Java. On pourra l’écrire, mais je vous met au défi d’instancier, vous aurez une infinité de new récursifs. Soit on triche comme dans la moulinette actuelle avec le type que l’on compose en parallèle de l’entité, soit on trouve une meilleur solution…
Un coq ?
Pas d’omelette sans poule et pas de poussin sans coq. Il ne s’agit pas d’un problème à 2 corps mais à 3 ! -<xp
- On a une base ontologique qui voit des Tuples ou groupe de Tuples,
- On a un usage métier abstrait représentant une personne par ses champs et valeur(s),
- Et on a une mécanique au milieu faisant le pont entre une représentation abstraite vers une donnée persistable.
C’est de cette mécanique qu’il s’agit au final. On veut lire un JSON d’entrée représentant une personne (nom, prénom(s), date de naissance, …), venant d’une classe métier permettant de la manipuler sémantiquement, puis le mapper à une série de descriptions (Prédicats) tout en validant le contenu (contrôle du Prédicat) donnant une série de Tuples prêt à être sauvés.
Évidemment si le Sujet existe déjà il faut penser mise à jour et contrôle de ce qui a changé etc. mais ce n’est pas un soucis. Tout ce qui nous importe est la division des responsabilités sans croisement.
Conclusion
Ainsi on aura 2 systèmes et une librairie :
- Un service ontologique tiers proposant une API traitant des Entités abstraites, validant les données par les Prédicats indiqués,
- Un service Folkopedia connaissant son métier et ses besoins, décrivant des classes et fonctions permettant de traiter ses données et interactions,
- Et au milieu une librairie ontologique mais côté Folkopédia, facilitant la communication vers le tiers ontologique, faisant la conversion entre les 2 univers classes métier spécifiques vers Tuples et inversement.
Ainsi les responsabilités sont claires et il n’y a plus de boucle déclarative car la traduction du besoin est décrite autrement. On peut avoir une classe métier Entité avec des valeurs finies et un service qui peuple ses valeurs par sa lecture des Tuples. Le Prédicat peut hériter de l’Entité, il n’y a pas d’usage de la représentation d’un Prédicat au niveau de l’entité, juste les valeurs directes. Ainsi la classe Prédicat est sa représentation technique finale et non une abstraction étant à la fois type et instance.
De l’autre côté on aura l’entity java Tuple et son repository permettant de requêter la table ontologique et une classe Subject représentant la collection de Tuples. Tout se jouera au niveau d’un service, peut-être d’annotations custom, d’un builder qui sait et d’introspection.