Analyse ontologique

Reflexion en cours.

But de l’analyse ontologique, avant de figer le DSL : pas modéliser toute la boîte, mais isoler les distinctions qui changent le comportement. Pour chaque feature, j’examine entités (User, Project, Organisation), rôles (Owner, Member, Reviewer, qui ne sont pas des classes permanentes : un même user a des rôles selon le contexte), relations (User memberOf Organisation, Project belongsTo Organisation), états, événements, valeurs/identités, cardinalités.

Le point qui crève les yeux après coup, sur le bug : activeOrganisation est un contexte de session ou de requête, pas une propriété ontologique permanente de l’utilisateur.

User belongsTo Org A and Org B
Session selects Org A
visible projects = projects belonging to selected Org A

Confondre « l’org de l’utilisateur » et « l’org active de la session », c’est exactement ce qui laisse passer la liste vide.

Les objets contextuels méritent leur propre catégorie : Session.activeOrganisation, Request.actor, CurrentTenant. Et les relations dérivées comme accessibleTo(user, project, session) ne sont pas stockées : elles se calculent depuis membership + org active + permission + état du projet. Pour chaque chose, il faut savoir ce qui définit l’identité, ce qui change, ce qui dépend du contexte, ce qui est dérivé, ce qui n’est qu’une représentation UI.

À creuser : comment forge repère automatiquement qu’un attribut est « contextuel » et pas « permanent » ? Indice dans le schéma, dans les types, ailleurs ? Liés : couche-semantique, competency-questions, compiler-intention-en-preuve