meta
De quoi ce nœud est-il une instance ? Cet axe, suivi en chaîne, fait émerger les trois niveaux.
Documentation · Le modèle
Generic System ne définit pas un type, un attribut et une relation comme trois mécanismes distincts. Il définit une primitive — le Generic — et laisse la structure et les données émerger de la même signature.
La signature
Un Generic n'est pas un objet sans structure. Ces quatre dimensions déterminent sa place et son rôle dans le graphe.
De quoi ce nœud est-il une instance ? Cet axe, suivi en chaîne, fait émerger les trois niveaux.
Quels nœuds plus généraux spécialise-t-il ? Cet axe porte l'héritage et les substitutions.
Quels nœuds participent à sa structure, et dans quel ordre ? Cet axe construit attributs et relations.
La quatrième dimension est la value : le nom d'un type, une clé métier, la valeur d'un holder ou toute autre donnée sérialisable. meta + supers + value + components donnent ensemble l'identité sémantique du nœud.
Les niveaux
Le niveau d'un nœud se lit sur la longueur de sa chaîne de meta, pas sur une étiquette qu'on lui colle.
META → STRUCTURAL → CONCRETE
La racine et les métas : le formalisme lui-même.
Les types, attributs et relations : la structure du système.
Les instances, holders et links : les faits.
Ce vocabulaire sert à lire le graphe. Il ne suppose ni trois moteurs, ni trois formats de stockage.
Une primitive, pas trois
Plutôt que de séparer « structure » et « données » dans deux mondes, Generic System fait du type un cas particulier de la même opération d'instanciation. Créer un type, c'est instancier la racine ; créer une donnée, c'est instancier un type.
// Un type est une instance de la racine.
Generic vehicle = engine.setInstance("Vehicle");
// Un attribut dépendant est un Generic structurel attaché au type.
Generic power = vehicle.setAttribute("Power");
power.enablePropertyConstraint();
// Une donnée concrète est une instance du type.
Generic myVehicle = vehicle.setInstance("myVehicle");
// Le holder relie la donnée à l'attribut et porte la valeur.
myVehicle.setHolder(power, 233);
System.out.println(myVehicle.getValue(power)); // 233
La relation fonctionne de la même manière, avec plusieurs composants ordonnés :
Generic color = engine.setInstance("Color");
Generic red = color.setInstance("red");
// Composants ordonnés : [Vehicle, Color]
Generic vehicleColor = vehicle.setRelation("VehicleColor", color);
// Le link est une instance de la relation : [myVehicle, red]
myVehicle.setLink(vehicleColor, null, red);
Ces appels sont ceux de l'API actuelle. Le didacticiel les déroule étape par étape avec les rendus d'origine.
L'arité
Les composants sont ordonnés : une position de base, une position cible, une position ternaire. Binaire, ternaire ou n-aire, le formalisme reste identique — c'est la composition ordonnée qui donne son sens à la relation.
Deux façons de construire
On peut construire le graphe à l'exécution avec les primitives ci-dessus, ou le déclarer une fois en Java avec des annotations @SystemGeneric. Les deux aboutissent au même graphe vivant. Voir les modèles Java →
Un malentendu fréquent
Un ORM projette un schéma figé sur une base relationnelle : le schéma vit à côté des données, et le modifier exige une migration. Ici, le schéma est des nœuds du graphe, sous le même contrat transactionnel que les faits.
Changer la structure, c'est muter le graphe comme on muterait n'importe quelle donnée : transactionnellement, avec les mêmes contraintes et la même sémantique de concurrence. C'est ce que la page Vision appelle une structure restructurable.
Continuer
Comment choisir entre attribut et relation, quelles contraintes poser, et comment le moteur valide tout cela : la page suivante.