Un point important et délicat dans le cas d'un système qui réutilise des données mais qui offre aussi des fonctionnalités de constitution et donc de modification de ses données, concerne les aspects de cohérence de ces données dans le système.
Considérons le cas suivant :
Un utilisateur crée une nouvelle analyse (en créant une nouvelle anagnose) et construit une première interprétation (en créant un ensemble de CS, cf. plus tard). Un deuxième lecteur, trouve cette interprétation pertinente pour sa propre analyse et utilise ces CS en tant qu'interprétants pour ses propres CS. Plus tard, le premier utilisateur, ayant décidé de présenter une interprétation plus restreinte, reprend son anagnose pour diminuer sa taille, effacer quelques textes, et modifier certaines CS. Que se passe-t-il avec l'analyse du deuxième lecteur qui a utilisé ces CS en tant qu'interprétants ? Doit-il reconstruire cette anagnose et les mêmes CS dans son propre espace de travail ? Mais les deux analyses n'appartiennent peut-être pas dans le même domaine et que cet utilisateur veut juste réutiliser quelques résultats d'une analyse faite par un expert reconnu dans un autre domaine. Demander à un utilisateur de recréer ou de s'ajuster à une analyse qu'il utilise et qui appartient à un autre utilisateur, chaque fois que ce dernier décide de modifier son analyse, est sûrement une contrainte trop forte qui rend vite le système pratiquement inutilisable.
Pourtant, la modification d'une CS du système de la part d'un utilisateur demande l'intervention de tous les utilisateurs qui en ont fait l'usage dans leurs propres analyses. La nécessité de cette intervention vient du fait que seules les modifications automatiques peuvent être gérées automatiquement ; une intervention humaine dans la production du sens ne devrait pas être gérée de manière automatique.
La solution que nous proposons est inspirée de la réalité dans le monde scientifique et littéraire où la notion de réutilisation est fortement utilisée. Un auteur modifie en privé un document jusqu'à arriver à une version qui le satisfait. Cette version est publiée et peut ensuite être réutilisée et critiquée. Si l'auteur désire effectuer une modification de cette version publiée, il est obligé de faire une deuxième publication d'un autre document. Étant donné que les erreurs sont presque toujours aussi productives que les corrigés, cette approche est en plus très utile.
Dans le cas de notre système, une anagnose, tout comme un texte, constitue un document créé par un agent humain (un lecteur plutôt qu'un auteur) qui, à un certain moment, peut être satisfait du résultat et vouloir publier l'anagnose et les structures sémiques associées. Plus tard il pourra, s'il le souhaite, modifier l'anagnose en l'utilisant comme source de relations sémantiques au sein d'une nouvelle anagnose.
La notion de publication est assez facilement mise en place dans le modèle de classes. Il suffit de caractériser l'anagnose comme un objet PUBLIE ou LOCAL (cf. DB_EntPos) et permettre la réutilisation seulement des CS qui sont situées dans des anagnoses qui ont déjà été publiées. Bien sûr, une anagnose peut passer de l'état LOCAL à l'état PUBLIE mais pas le contraire. Et, bien entendu, le créateur de l'anagnose peut réutiliser les CS qui y sont situées (et les modifier), même si son état est LOCAL.