Réseau sémantique
3.3.2 Edition et compilation des Règles d’Acquisition de Connaissance
Les Règles d’Acquisition de Connaissance sont au cœur d’OntoPop. Au niveau de la méthodologie, elles représentent le socle de la passerelle entre le résultat des extractions linguistiques d’un côté et la représentation sémantique de la connaissance de l’autre. Au niveau de la solution logicielle proposée par OntoPop, elles composent l’ingrédient indispensable au bon fonctionnement du processus de peuplement d’ontologie et d’annotation documentaire.
Parmi la suite logicielle fournie par OntoPop, l’utilisateur dispose d’un Editeur de Règles qui lui permet de saisir l’ensemble des Règles d’Acquisition de Connaissance d’une application cible donnée. L’interface utilisateur est très simple : elle propose un formulaire composé des champs nécessaires à la création d’une nouvelle règle comme spécifié par le langage OPAL. Une description plus technique de cet éditeur est fournie à la section 6.1. Mais ce langage OPAL est avant tout destiné à des utilisateurs humains. Par conséquent, les RAC doivent être traduites dans un langage informatique pour être comprises et manipulées par les agents logiciels. Ce langage informatique doit lui-même être assez puissant et flexible pour traduire l’expressivité et la complexité de chacune des Règles d’Acquisition de Connaissance. Il doit également servir les objectifs de ces règles d’acquisition, à savoir :
1) le passage d’un format de représentation à un autre, que ce dernier représente un réseau sémantique de connaissance au format XTM ou OWL ou un ensemble d’annotations sémantiques au format RDF,
2) et la gestion du contexte particulièrement importante comme nous l’avons vu.
Au chapitre précédent, nous avons déjà précisé qu’un arbre conceptuel peut être représenté comme un document XML. Il nous a donc semblé tout à fait naturel de nous appuyer sur l’ensemble des langages et formats issus de la technologie XML. Parmi cette offre, se dégage tout naturellement le langage XSLT33 qui opère des actions de transformations sur les éléments sélectionnés d’un arbre. Les feuilles de transformations XSLT reposent sur l’exploitation des chemins XPath34 afin de sélectionner les nœuds de l’arbre XML à transformer. Le langage XPath définit en effet des chemins à travers l’arbre XML : il permet de naviguer dans un arbre XML, de sélectionner n’importe quel nœud de cet arbre et d’effectuer des opérations sur ces nœuds. Or pour appréhender la complexité des Indices Contextuels des RAC, il est particulièrement intéressant de disposer d’un tel langage de parcours des arbres.
Rappelons brièvement que le déclenchement d’une règle d’acquisition repose sur la présence dans l’arbre de concept du nœud indicateur contenant l’information à récupérer pour instancier un élément de l’ontologie ou pour annoter le document en question. L’utilisation de ce nœud indicateur est dépendante de l’ensemble des contraintes exprimées sur le contexte de ce nœud dans l’arbre de concept. Ce contexte peut être ascendant comme descendant. Les contraintes peuvent être
33 Site web de XSLT: http://www.w3.org/TR/xslt 34 Site web de XPath: http://www.w3.org/TR/xpath
formulées sur l’existence ou non d’un nœud ou d’une valeur particulière. D’autres sortes de contraintes peuvent porter sur des enchaînements d’opérations diverses, des calculs à partir de chaînes de caractères ou de valeurs numériques, etc.
Ces langages, et tout particulièrement XPath, possèdent a priori toute l’expressivité et la flexibilité nécessaires à la transcription des Règles d’Acquisition de Connaissance dans un langage compréhensible et manipulable par les machines. A eux deux, XSLT et XPath remplissent les objectifs des RAC : XPath va être utilisé pour sélectionner les nœuds indicateurs dans l’arbre de concept et vérifier les contraintes liées au contexte de ce nœud et XSLT va réaliser la transformation de ces arbres de concepts en nouvelles instances de la connaissance ou en nouvelles annotations sémantiques. Par ailleurs, nombre d’implémentations techniques et logicielles ont d’ors et déjà été développées et sont disponibles en libre accès. OntoPop peut directement les intégrer et les exploiter dans ses divers modules. L’utilisation de ces langages implique néanmoins que l’arbre de concept généré par l’outil d’extraction d’information soit transformé au format XML, si cela n’est déjà pas la sortie en standard de l’outil.
Par exemple, la Règle d’Acquisition de Connaissance concernant l’attribut « Date de naissance » (cf. Figure 40) sera définie par la règle Xpath suivante : « Naissance/DATE[ancestor::DATE-NAISSANCE/Personne] ». Cette règle XPath signifie : trouver un nœud « DATE » dont le père est le nœud « Naissance » et qui possède un ancêtre « DATE-NAISSANCE », ayant lui-même un nœud fils nommé « Personne ».
Figure 42. Transcription d’une Règle d’Acquisition de Connaissance en template XSLT pour le peuplement d’ontologie. NomRègle: PersonnaliteR1 TypeConcept: Classe ConceptURI: http://www.mondeca.com/onto#Personnalité NoeudIndicateur: NomPropre IndicesContextuels:
{Existe: [EspaceRechercheArbre: père] [NoeudIndice: Personne] } Valeur: text() Position: faux Confiance: élevé finRègle
Exemple de Règle d’Acquisition Exemple de « template » XSLT
<xsl:template match="Personne/NomPropre" mode="t100081"> <topic id="{generate-id()}"> <instanceOf> <subjectIndicatorRef xlink:href="http://www.mondeca.fr/onto#Personnalité"/> </instanceOf> <baseName> <baseNameString>
<xsl:value-of select="text()"/>
</baseNameString>
</baseName>
<xsl:element name="mondecaMetadata">
<xsl:element name="mondecaPosition">
<xsl:attribute name="start"><xsl:value-of select="@start"/></xsl:attribute>
<xsl:attribute name="length"><xsl:value-of select="@length"/></xsl:attribute>
</xsl:element>
<mondecaTrust>
<topicRef xlink:href="high"/>
</mondecaTrust>
</xsl:element>
<xsl:apply-templates mode="di100811" select="nomPub"/>
<xsl:apply-templates mode="di100812" select="date[not(child::*)]"/>
<xsl:apply-templates mode="di100813" select="numEltPub"/>
<xsl:apply-templates mode="di100813" select="self::numFas"/>
</topic> </xsl:template> Les « apply-templates » sont
déduits à partir des règles d’acquisition définies pour les attributs de cette classe, i.e. dont le domaine est l’URI de la classe définie dans cette règle
Par conséquent, lorsque l’utilisateur humain saisit une nouvelle règle d’acquisition dans l’Editeur des Règles, celle-ci est immédiatement compilée avec les règles déjà existantes pour générer une feuille de transformation au format XSLT. En réalité, la compilation des règles d’acquisition ne génère pas une seule feuille de transformation XSLT, mais deux : la première destinée au peuplement de l’ontologie du domaine et la seconde pour l’annotation documentaire.
Chaque élément d’OPAL est utilisé pour construire un « template » XSLT. Dans la Figure 42, le template généré par le compilateur de l’Editeur de Règle correspond à la création d’une instance de classe, i.e. un « topic » dans le langage XTM. Rappelons que dans OntoPop ce langage est celui utilisé pour la modélisation de la base de connaissance, et par conséquent pour le processus de peuplement d’ontologie. La partie la plus complexe dans la génération des templates à partir des RAC écrites en OPAL concerne la création du chemin XPath à partir du nœud indicateur et de ses indices contextuels.
Chaque règle d’acquisition, quelle que soit sa complexité, doit pouvoir être traduite dans le langage XPath. Et cette complexité détermine forcément le niveau de difficulté de la transcription à opérer. Nous avons donc analysé les différentes constructions utilisées pour l’écriture des conditions contextuelles des RAC et nous avons dégagé la graduation suivante :
- sans contexte : aucune condition contextuelle n’a été précisée dans la RAC, par conséquent cette règle sera déclenchée quelle que soit la position du nœud déclencheur dans l’arbre conceptuel ou autrement dit, quels que soient ses ancêtres.
- avec un contexte ascendant : la RAC contient une seule condition contextuelle qui porte sur l’existence d’un nœud ancêtre (parent, grand-parent ou autre aïeul)
- avec un contexte descendant : la RAC contient une seule condition contextuelle qui porte l’existence d’un nœud descendant (fils, petit-fils, etc.)
- avec un contexte ascendant et un contexte descendant : la RAC contient deux conditions contextuelles dont une sur l’existence d’un nœud ascendant et l’autre sur l’existence d’un nœud descendant, à quelque niveau que ce soit de la hiérarchie
- avec juxtapositions de contextes ascendants : la RAC contient plusieurs conditions contextuelles, toutes liées à l’existence de plusieurs ascendants
- avec juxtapositions de contextes descendants : la RAC contient plusieurs conditions contextuelles, toutes liées à l’existence de plusieurs nœuds descendants
- avec imbrications de contextes : la RAC contient une ou plusieurs conditions contextuelles, qui elles-mêmes peuvent contenir une ou plusieurs conditions
- avec utilisation de fonctions : la condition contextuelle ne porte plus seulement sur l’existence ou non d’un nœud dans l’arbre mais sur des conditions nécessitant l’utilisation de fonctions comme le calcul de sa position dans un sous-arbre ou d’une partie de sa valeur textuelle par exemple.
Nous avons analysé ces niveaux de construction des RAC afin de pouvoir dégager pour chaque cas un algorithme nous permettant de générer le chemin XPath associé. Le tableau ci-dessous présente chaque opération de transcription, illustrée par un exemple précis à l’aide du schéma représentant les éléments suivants :
Constructions Opérations de transcription
sans contexte En Xpath, l’axe « ancestor ::* » et son raccourci « // » sont utilisés pour indiquer qu’un nœud peut avoir n’importe quel ancêtre.
Avec un contexte ascendant
L’axe « parent :: » et son raccourci « / » sont utilisés pour indiquer le nœud père du nœud concerné. Nous insérerons donc ce raccourci ou celui représentant les ancêtres, i.e. « // », entre le nœud indice et le nœud déclencheur de la RAC.
avec un contexte descendant
Les axes « child:: » et « descendant:: » sont utilisés pour respectivement indiquer un nœud fils ou un nœud descendant du nœud concerné. La fonction « child :: » peut être omise, il s’agit d’un raccourci XPath. Ces fonctions concernant le nœud indice de la RAC seront insérées entre crochets « [] » après le nœud déclencheur.
Avec un contexte ascendant et descendant
Il s’agit dans ce cas de combiner les deux opérations de transcriptions précédentes : ajout des raccourcis « / » ou « // » avant le nœud déclencheur de la RAC pour indiquer le nœud indice ascendant et insertion d’une des fonctions descendantes entre « [] » pour indique le nœud indice descendant.
/Arbre_xml /nœud_A /nœud_AA /nœud_B NomRègle : contexte_descendant … NœudIndicateur : nœud_A IndicesContextuels : {existe : [EspaceRechercheArbre=fils ; NœudIndice=nœud_AA] }… nœud_A[child::nœud_AA] /Arbre_xml /nœud_A /nœud_AA /nœud_B
Nom Règle : contexte_ascendant … NœudIndicateur : nœud_AA IndicesContextuels : {existe : [EspaceRechercheArbre=père ; NœudIndice=nœud_A] } … nœud_A/nœud_AA Arbre de concept généré
pour un document fictif
Règle d’acquisition de connaissance définie sur le domaine concerné
Chemin XPath créé à partir de la règle d’acquisition définie ci-dessus
/Arbre_xml /nœud_A /nœud_AA /nœud_B NomRègle : sans_contexte … NœudIndicateur : nœud_AA IndicesContextuels : {} … //nœud_AA
avec juxtapositions de contextes ascendants
La juxtaposition de ces indices contextuels se caractérise par la réinterprétation de la hiérarchie des ascendants grâce à l’utilisation des axes : « ancestor :: » et « parent :: », traduit par leurs raccourcis « // » et « / ».
Dans l’exemple ci-dessous, le nœud déclencheur « nœud_A11 » possède un père dénommé «nœud_A1 » et un grand-père « nœud_A » lui-même étant le père du « nœud_A1 » par transitivité. Enfin, l’ancêtre de ces nœuds est le nœud dénommé « Arbre_xml ». Comme sa place dans la hiérarchie des ascendants n’est pas connue, le raccourci « // » entre ce nœud et le nœud grand-père indique qu’il peut optionnellement y avoir d’autres nœuds ascendants entre eux.
avec juxtapositions de contextes descendants
La juxtaposition d’indices contextuels descendants se caractérise par la coordination des axes « child :: » et « descendant :: » avec l’opérateur « and » dans la partie située entre « [] » après l’indice déclencheur. Précisons ici que la non-existence d’un nœud se définit par l’utilisation de la fonction « not(axe ::nom_noeud) ».
/Arbre_xml /nœud_A /nœud_A1 /nœud_A2 /nœud_B /nœud_B1 /nœud_B2 NomRègle : juxtaposition_descendants … NœudIndicateur : nœud_A IndicesContextuels : {existe : [EspaceRechercheArbre=fils ; NœudIndice= nœud_A1] } {existe : [EspaceRechercheArbre=fils ; NœudIndice=nœud_A2] } {nonExiste : [EspaceRechercheArbre=descendant ; NœudIndice=nœud_B] }…
nœud_A[nœud_A1 and nœud_A2 and not(descendant:: nœud_B)] /Arbre_xml /nœud_A /nœud_A1 /nœud_A11 /nœud_B /nœud_B1 /nœud_B2 NomRègle : juxtaposition_ascendants … NœudIndicateur : nœud_A11 IndicesContextuels : {existe : [EspaceRechercheArbre=ancêtre ; NœudIndice= Arbre_xml] } {existe : [EspaceRechercheArbre=grand-père ; NœudIndice=nœud_A] } {existe : [EspaceRechercheArbre=père ; NœudIndice=nœud_A1] } … ancestor::Arbre_xml//nœud_A1/nœud_A2/nœud_A11 /Arbre_xml /nœud_A /nœud_AA /nœud_B NomRègle : contexte_asc_&_des … NœudIndicateur : nœud_A IndicesContextuels : {existe : [EspaceRechercheArbre=père ; NœudIndice=Arbre_xml] } {existe : [EspaceRechercheArbre=fils ; NœudIndice=nœud_AA] }…
avec imbrications de contextes
La complexité repose ici sur la reconstitution de ces imbrications, selon si elles sont liées aux ascendants ou aux descendants.
Par exemple ci-dessous, le nœud indicateur « nœud_A1 » possède un nœud fils « nœud_A11 », lui-même ayant au moins un nœud fils, quel qu’il soit, symbolisé par le caractère « * ». Il faut donc reconstruire la hiérarchie descendante dans la condition entre « [] ».
avec l’utilisation de fonctions
Les RAC utilisent aussi contraintes liées au nombre de nœuds, à leur position dans le sous-arbre, à leur nom, leurs valeurs textuelles, etc. Les chemins XPath doivent donc être en mesure d’implémenter ces conditions particulières à l’aide des fonctions prédéfinies dans ce langage. Dans l’exemple ci-dessous deux fonctions Xpath sont utilisées : la première « contains(text(), ‘’xml’’) » pour tester si la valeur textuelle du nœud contient une certaine chaîne de caractères et la seconde « count(child ::*)=2 » pour savoir si il possède exactement deux nœuds fils.
Tableau 4. Opérations de transcription des RAC en chemins XPath
Jusqu’à présent, l’algorithme de transcription des RAC fournit une solution générique permettant générer automatiquement les chemins XPath à partir des RAC. Il est capable de gérer toutes les formes de constructions des conditions contextuelles rencontrées, quel que soit leur niveau de
/Arbre_xml (blah blah… xml…) /nœud_A /nœud_A1 /nœud_A2 /nœud_B /nœud_B1 /nœud_B2 NomRègle : fonctions_dans_contextes … NœudIndicateur : nœud_A1 IndicesContextuels : {existe : [EspaceRechercheArbre=grand-père ; NœudIndice= Arbre_xml] {contient : [EspaceRechercheArbre=texte ; valeur=’’xml’’] } {nombre : [EspaceRechercheArbre=fils ; valeur=’’2’’] } }… //Arbre_xml[contains(text(),’’xml’’) and count(child::*)=2]//nœud_A1 /Arbre_xml /nœud_A /nœud_A1 /nœud_A11 /noeud_XYZ /nœud_A2 /nœud_B /nœud_B1 /nœud_B2 NomRègle : imbrication_contextes … NœudIndicateur : nœud_A1 IndicesContextuels : {existe : [EspaceRechercheArbre=grand-père ; NœudIndice= Arbre_xml] } {existe : [EspaceRechercheArbre=père ; NœudIndice=nœud_A] } {existe : [EspaceRechercheArbre=fils ; NœudIndice=nœud_A11] {existe : [EspaceRechercheArbre=fils ; NœudIndice=*] } }…
complexité, grâce notamment à la richesse du langage XPath. Néanmoins, les RAC sont appelées à évoluer en fonction des besoins de chacune des applications pour lesquelles elles sont créées. Il se peut donc que l’algorithme actuel ne puisse résoudre les nouvelles constructions, même si nous avons tenté de les anticiper.
Une fois l’ensemble des RAC saisies dans l’Editeur des Règles et compilées en feuilles de transformation XSLT, le processus d’annotation sémantique et de peuplement d’ontologie peut être lancé sur un corpus documentaire. Nous allons voir dans la suite quelles sont les tâches et les spécificités de ce processus dans le cadre de la démarche adoptée par OntoPop.
3.4 Conclusion
Les Règles d’Acquisition de Connaissance forment le cœur de la démarche OntoPop. Elles permettent de passer d’une représentation du texte sous la forme d’un arbre conceptuel à une représentation formelle du contenu sous la forme d’annotations sémantiques et/ou d’instances de la base de connaissance selon les besoins. Elles fournissent une solution flexible, facilement adaptable et sachant combler le fossé qui sépare le plus souvent ces deux niveaux de représentation du contenu.
Dans ce chapitre, nous avons défini les composants nécessaires à la formalisation d’une Règle d’Acquisition de Connaissance et décrit le langage OPAL qui permet de les implémenter dans un système logiciel. Enfin, nous avons présenté la manière dont ces règles, destinées à des utilisateurs humains, sont compilées en feuilles XSLT. A présent, nous allons présenter le reste de la démarche OntoPop dans laquelle s’inscrivent ces RAC. Nous allons notamment nous intéresser au cycle de vie des ressources terminologiques et ontologiques au cours du processus d’annotation sémantique et de peuplement d’ontologie.