Connaissances du domaine applicatif

4.3.2.1 Introduction

Ainsi qu'il a été présenté au chapitre précédent, les connaissances du domaine jouent un rôle central dans les traitements réalisés dans le cadre d'une tâche parti-culière. Celles-ci peuvent être divisées en deux catégories.

Les connaissances du domaine d'étude représentent les concepts qui peuvent être manipulés dans le cadre d'une synthèse et sont instanciés au sein des dossiers clin-iques et données histologclin-iques. En tant que telles, elle servent de base à la dénition des connaissances des archétypes utilisateur et à la formulation de requête.

Les connaissances expérimentales permettent la dénition de contraintes sur les sous-tâches élémentaires. Ces contraintes sont de deux types : contraintes sur le type de traitement à réaliser pour une sous-tâche particulière ou contraintes sur les paramètres du traitement. Ces connaissances expérimentales peuvent aussi être envisagées à plusieurs niveaux : de manière générique, au niveau du domaine

appli-Fig. 4.2: Décomposition fonctionnelle d'un modèle de tâche - Chaque chier XML de modèle de tâche est décomposé en trois parties principales correspondant aux trois catégories de problèmes à résoudre. Chacune contient une hiérarchie de catégories jusqu'au niveau sous-tâche élémentaire. Chacune de ces sous-tâches élémentaires est alors décrite, et en particulier les éléments de

spécial-isation, c'est-à-dire les entrées et sorties.

catif ; de manière personnalisée, en tant que comportements idiosynchratiques d'un groupe d'usagers ou d'un utilisateur particulier ; ou de manière spécique, dans le cadre d'une étude particulière. Il s'agit donc d'un ensemble de contraintes à prendre en compte lors de l'instanciation d'une tâche.

La représentation formelle de ces connaissances est donc de première importance et va être détaillée ici.

4.3.2.2 Connaissances du domaine d'étude

4.3.2.2.1 Taxonomie

En ce qui concerne le domaine d'étude, la représentation de connaissances doit re-couvrir tout à la fois les connaissances cliniques sur les patients et les problématiques biologiques, en particulier des informations anatomiques. Au niveau dossier médical, les systèmes de gestion informatisés sont de plus en plus nombreux, et des systèmes

tels que celui de [Patel et al., 2006], qui placent cette problématique dans le contexte des banques de tissus, contexte qui est celui des données associées aux TMA, sont de bonnes sources d'inspiration pour une représentation de connaissances.

Au niveau biologique, alors qu'il existe une ontologie de l'anatomie humaine pour des organes sains [Rosse and Mejino, 2003], les ontologies de tissus pathologiques ne sont pas très satisfaisantes et des ontologies du côlon et du sein pathologiques ont été construites par le Dr. Joëlle Simony-Lafontaine, dans le cadre de sa thèse [Simony-Lafontaine, 2007]. La taxonomie correspondante pour le côlon est présenté Fig. 4.3.

Fig. 4.3: Taxonomie de l'ontologie du côlon - Construite par le Dr. Joëlle Simony-Lafontaine, cette taxonomie reète les diverses pathologies du côlon, de l'échelle de l'organe à l'échelle cellulaire.

La mise en relation des connaissances qui viennent d'être décrites et la base de données existante au sein du projet TMA-Explorer a permis la dénition d'une taxonomie du domaine d'étude.

Cette taxonomie a été envisagée dans un objectif purement applicatif : elle se limite à organiser logiquement, au sein d'une hiérarchie de profondeur raisonnable, des entités présentes dans la base de données qui ont été jugées comme essentielles pour le prototype. Cette taxonomie, reétée matériellement par une arborescence de répertoires au sein du système de chiers du serveur, est présentée Fig. 4.4.

Les diérents concepts présents au sein de cette taxonomie doivent alors être représentés de manière satisfaisante dans le cadre du prototype, ainsi que présenté dans le prochain paragraphe.

Fig. 4.4: Taxonomie du domaine d'étude - Les n÷uds sont représentés physiquement par des répertoires, et les feuilles des chiers XML au format spécique. Cette taxonomie couvre les champs

essentiels de la base de données.

4.3.2.2.2 Représentation de concepts

Les concepts correspondant à des catégories de la taxonomie du domaine d'étude ne requièrent pas une représentation plus étendue qu'un nom et une description, puisqu'ils jouent un simple rôle d'organisation. Par contre, les concepts feuille sont beaucoup plus complexes, car ce sont ceux qui sont manipulés par le processus de synthèse. En particulier, ils peuvent avoir des natures très diérentes, impliquant un traitement diérent dans le cadre du processus de synthèse. De plus, ils corre-spondent à des éléments en base de données, ce qui implique la dénition d'une correspondance avec un champ particulier dans la base.

Au niveau de la nature des éléments impliqués, les diérences d'échelle (du patient à la cellule), de type (nombres, textes, images) ont déjà été évoquées. Dans le cadre du processus de synthèse, c'est surtout le type qui est problématique.

En eet, la caractérisation d'un pourcentage de cellules marquées, soit une valeur numérique entre 0 et 100, ne peut pas être réalisée de la même façon que la descrip-tion d'un type de lésion, qui correspond à une liste prédénie de valeurs textuelles.

Tab. 4.1: Diverses natures de concepts du domaine d'étude - Ce tableau répertorie les diverses natures de concepts telles qu'envisagées au sein du prototype. En plus d'un exemple, il fournit des

contraintes sur les opérateurs et valeurs possibles pour chaque type de concept.

Nature du

concept ^{Exemple Opérateurs}possibles ^{Valeurs possibles}

N÷ud État-Civil = ; != liste prédénie de valeurs textuelles cor-respondant aux concepts de niveau plus n

Quantitatif Pourcentage de

cel-lules marquées ^{> ; < ; => ;}<= ; = ; != ^{valeurs numériques comprises entre un}minimum et un maximum Qualitatif Type de lésion = ; != liste prédénie de valeurs textuelles

Booléen Décédé = ; != vrai ou faux

Date Date de naissance > ; < ; => ;

<= ; = ; != ^{dates comprises entre un minimum et}un maximum Texte libre Commentaire contient() n'importe quel fragment de texte

Image Image d'un spot = ; != nom du chier image

Dans le premier cas, on peut dénir des caractéristiques de type valeur minimum, valeur maximum, ou taille de classe ; dans le second, seule la liste des valeurs possi-bles, éventuellement ordonnée, a un sens.

De plus, les opérations possibles sont diérentes. Ainsi, si l'on considère une sous-tâche élémentaire de sélection selon un critère donné, si le critère est le pourcentage de cellules marquées, des contraintes telles que inférieur à 50 ou supérieur ou égal à 20 ont un sens. Par contre, elles sont sans objet pour le type de lésion.

Ces considérations impliquent tout d'abord d'évaluer une liste des diverses na-tures de concepts, et des contraintes qu'elles posent sur des éléments tels que les opérateurs et valeurs possibles. Dans le cadre de la synthèse, cette évaluation a permis la construction du Tab. 4.1.

Dans le cadre du prototype, aucune vraie date n'est présente, toutes les dates étant dénies en tant qu'années, qui peuvent être considérées comme des éléments quantitatifs. Les éléments booléens peuvent être considérés comme des éléments qualitatifs à deux valeurs, vrai et faux. En ce qui concerne le texte libre, la mise en place d'un opérateur de type contient() induit le recours à des méthodes de Recherche d'Information en tant que telles, qui sont très complexes à mettre en ÷uvre et ne sont pas l'objet de ma thèse. Ces types de concepts n'ont donc pas été pris en compte de manière spécique au sein du prototype.

Il s'agit alors de proposer, pour chaque type de concept, une représentation par-ticulière. Ainsi qu'il a été déni dans le cadre de développement, celle-ci doit être réalisée au format XML et induit la description des éléments nécessaires et susants pour leur traitement.

Ainsi, pour tous les éléments il faut dénir une valeur par défaut, à utiliser quand seul le concept est mentionné sans choix d'une valeur spécique. Pour les concepts qui ne sont pas des n÷uds, il s'agit aussi d'indiquer une correspondance avec un champ de base de données.

Ensuite, les éléments quantitatifs doivent indiquer des valeurs minimum et maxi-mum possibles, ainsi que des tailles de classes possibles, sur la base desquelles seront construits des groupes. Les éléments qualitatifs, quant à eux, doivent spécier la liste de leurs valeurs possibles.

Un exemple de chier XML, pour un élément qualitatif, la notion d'organe, est présenté en AnnexeB.

4.3.2.3 Connaissances expérimentales

4.3.2.3.1 Introduction

Comme indiqué précédemment, les connaissances expérimentales peuvent être envisagées sous deux formes : contraintes sur les paramètres de certaines sous-tâches élémentaires ou contraintes sur le type de traitement à réaliser. Celles-ci ont été dénies comme connaissances expérimentales par analogie avec les méthodes mises en place dans le contexte applicatif de construction de TMA réels, et pourraient être envisagées comme des éléments de dénition de protocole expérimental.

Classiquement, et en particulier dans les publications de sciences expérimentales telles que la biologie, ces indications de protocole sont considérées en matière de matériel (les éléments utilisés, par exemple échantillons biologiques, réactifs, ap-pareils, etc.) et méthodes (les procédures expérimentales mises en place, en terme de plan d'expérience, par exemple liste et durées des bains pour une coloration). Ici matériel correspondrait aux contraintes sur les paramètres et méthodes aux contraintes sur les méthodes de résolution.

Ces deux types de connaissances expérimentales vont donc être explorées plus en détails ici.

4.3.2.3.2 Connaissances de type Matériel

Dans le processus réel de fabrication de TMA, le matériel inclut entre autres des considérations comme la taille de l'aiguille utilisée pour prélever des carottes ou la taille du bloc de parane receveur, qui conditionnent la taille de la matrice lignes/colonnes du bloc TMA à construire. Des indications sur l'épuisement du bloc

donneur, qui empêche son utilisation dans un nouveau bloc car aucune nouvelle carotte ne peut physiquement être prélevée, ou sur l'âge du matériel, permettant de prendre en compte une inuence du traitement subi par le bloc sur le marquage, relèvent aussi de ce type de problématique.

Par analogie, dans le cadre de la synthèse appliquée au domaine des TMA, sont considérés à ce niveau des éléments tels que la taille de la grille du document de synthèse, la langue ou le code couleur à utiliser au sein de la grille.

En ce qui concerne le fonctionnement du prototype, ces éléments interviennent en tant que paramètres de sous-tâches élémentaires particulières. Ainsi, la largeur et la longueur de la grille sont utilisées par une sous-tâche élémentaire qui dénit l'adéquation de la grille au nombre total d'individus sélectionnés.

Se pose alors le problème de la représentation de tels éléments. Bien qu'ils soient conceptuellement diérents des éléments inclus dans la taxonomie du domaine d'é-tude, ils n'en dièrent guère par nature et peuvent être représentés de la même façon, c'est-à-dire au sein d'une hiérarchie de répertoires contenant des chiers XML de description d'éléments feuille.

4.3.2.3.3 Connaissances de type Méthodes

En ce qui concerne les éléments de type méthode, le problème est plus complexe. En eet, ceux-ci sont dénis comme des contraintes sur le traitement à réaliser dans le cadre d'une sous-tâche élémentaire, ce qui implique de décrire plus précisément ce qui est entendu par là, avant de proposer un mode de représentation.

Au sein du prototype, chaque sous-tâche élémentaire est résolue au niveau logiciel par un composant. Mais cette armation ne présuppose pas l'unicité du composant associé à chaque sous-tâche, et la relation peut être envisagée comme une relation de un à plusieurs. Or le processus de synthèse a été conçu au sein du prototype comme résultant de l'exécution d'un composant pour chacune des sous-tâches élémentaires du modèle de tâche.

Se pose alors un problème de choix de composant à exécuter pour chacune des sous-tâches élémentaires, déjà illustré au chapitre précédent par la Fig. 3.15. Ce problème, en l'absence de connaissances complémentaires, est souvent résolu par un choix arbitraire ou au hasard. Or ce type de choix n'est pas adapté dans le contexte scientique de l'appréhension des données TMA, puisqu'il limite la reproductibilité. Proposer une résolution qui ne repose plus sur le hasard est l'objet des connaissances expérimentales de type protocole.

d'associa-tion entre une sous-tâche élémentaire et un composant spécique, choisi parmi ceux permettant de résoudre ce sous-problème particulier. Dans le cadre du prototype, le système envisagé est pour l'instant très simple, puisqu'il constitue en la dénition d'un composant par défaut pour chaque sous-tâche élémentaire.

Ainsi, par exemple, la sous-tâche de gestion de données manquantes est réalisée par défaut par exclusion des individus ayant des données manquantes. La exibilité est apportée par la possibilité d'écraser ce choix par défaut, au sein de la requête ou au niveau utilisateur. Ainsi, certaines études peuvent être réalisées spéciquement en recourant à des inférences pour déterminer des valeurs de données manquantes.

A l'avenir, des mécanismes plus complexes peuvent être envisagés. Par exemple, une pondération de l'utilisation de chaque composant, en fonction du type d'étude qui est traité, peut être mise en place.

Ainsi, on peut imaginer, au cours d'une séance d'utilisation, le ranement pro-gressif de l'étude d'un problème particulier. Dans un premier temps, la gestion des données manquantes par inférence permet d'inclure plus d'individus et ainsi d'avoir une vision plus globale du problème. Ensuite, l'exclusion des données manquantes permet de construire une vue sur des données ables, qui peut servir de base à une publication ou à d'autres analyses, par exemple statistiques.

Un tel comportement peut être mis en place par le biais d'un système à base de règles, en liant par exemple le composant de gestion de données manquantes à utiliser au nombre de reformulations de la requête. Un système à partir de cas peut lui aussi s'avérer pertinent.

4.4 Gestion des utilisateurs