Master Dissertation He Lafe HR I

Cycle de Formation Doctorale
dans la Discipline Gnie lectrique

et informatique
Rpublique Tunisienne
Ministre de lEnseignement Suprieur
NTSID
Universit de Sfax
cole Nationale dIngnieurs de Sfax
Mmoire de MASTERE
N dordre:
MEMOIRE
prsent
lcole Nationale dIngnieurs de Sfax

en vue de lobtention du
MASTERE
Dans la discipline Gnie lectrique et Informatique
Nouvelles Technologies des Systmes Informatiques Ddis
par
Hla FEHRI
(Matrise en Informatique Appliqu la Gestion)
UN PROTOTYPE DE PROJECTION DU HPSG

VERS LMF
soutenu le 23 Juin 2007, devant le jury compos de :
M.
Mohamed JMAIEL
M.
Bilel GARGOURI
M.
Kais HADDAR
Prsident
Membre
Encadreur
Ddicaces
Jai le grand plaisir de ddier ce travail :

A
Mon cher pre pour sa patience, ses sacrifices et ses conseils prcieux quil ma toujours
donn.
A
Ma trs chre mre pour son norme tendresse et qui ma infiniment encourag et qui na
jamais cess de me soutenir.
Que dieu leur prserve la bonne sant et une longue vie pleine de joie et de bonheur.
A
Mon frre et mes surs pour leur amour et leur encouragement.
A
Tous les cousins, les amis et ceux qui mont aid raliser ce travail.
Hla
REMERCIEMENTS
ai lhonneur dexprimer mes vifs remerciements mon

encadreur Mer KAIS HADDAR
qui m a tmoign sa
confiance et qui ma encadr avec beaucoup de rigueur,
damabilit et de disponibilit dans la ralisation de ce travail, quil retrouve ici

lexpression de mon profond respect et de mon dvouement.
Mes remerciements sont adresss de mme pour les membres du jury pour le grand
honneur quils me rendent de juger ce travail.
Pour la mme occasion, je tiens aussi remercier mes professeurs et mes collgues.
Je noublie pas dexprimer mes sentiments de gratitude tous ceux qui ont
contribu de prs ou de loin au bon droulement de ce travail.
Table des matires

Introduction gnrale............................................................................................................... 1
Chapitre 1 : Etat de lart ......................................................................................................... 4
1. Lexiques HPSG existants pour la langue arabe ............................................................ 5
2. Normalisation ................................................................................................................... 6
2.1. Pourquoi normaliser ? ............................................................................................... 6
2.2. Normes au sein de lISO-TC37.................................................................................. 7
2.3. Travaux bass sur la normalisation ......................................................................... 9
3. Traduction dun formalisme vers un autre.................................................................. 13
3.1. Projection de FB-LTAG vers HPSG ....................................................................... 13
3.2. Projection de HPSG vers TAG................................................................................. 18
Conclusion........................................................................................................................... 21
Chapitre 2: Lexique HPSG pour lArabe ............................................................................. 22
1. Aperu sur HPSG........................................................................................................... 23
2. Lexique HPSG arabe ..................................................................................................... 25
2.1. Traits ajouts ............................................................................................................ 25
2.2. Les noms ................................................................................................................... 26
2.3. Les particules............................................................................................................ 31
2.4. Les verbes.................................................................................................................. 34
Conclusion........................................................................................................................... 37
Chapitre 3: Lexical Markup Framework (LMF) ................................................................. 38
1. Prsentation gnrale du LMF...................................................................................... 39
1.1. Partie noyau.............................................................................................................. 39
1.2. Extensions................................................................................................................. 42
1.3. Catgories de donnes .............................................................................................. 43
2. Processus LMF ............................................................................................................... 45
3. Extension morphologique .............................................................................................. 46
4. Extension syntaxique...................................................................................................... 47
5. Extension smantique .................................................................................................... 49
Conclusion........................................................................................................................... 52
Chapitre 4 : Dmarche propose .......................................................................................... 54
1. Identification dun systme de rgles de projection.................................................... 55
1.1. Rgles identifies pour les traits morphologiques................................................... 56

1.2. Rgles identifies pour les traits syntaxiques .......................................................... 60
1.3. Rgles identifies pour les traits smantiques ......................................................... 61
1.4. Exemple illustratif .................................................................................................... 62
2. Processus de projection.................................................................................................. 65
2.1. Extraction dun fragment xml de la SAV du mot correspondant ......................... 66
2.2. Identification de la position de la projection........................................................... 67
2.3. Projection proprement dite....................................................................................... 73
Conclusion........................................................................................................................... 75
Chapitre 5 : La ralisation informatique ............................................................................. 77
1. Architecture gnrale du prototype ralis.................................................................. 78
2. Conception du prototype ............................................................................................... 79
2.1. Diagramme des cas dutilisation.............................................................................. 79
2.2. Diagramme de squence du cas Projection vers LMF ....................................... 81
2.3. Diagramme de classes .............................................................................................. 82
3. Implmentation............................................................................................................... 83
3.1. Reprsentation interne des lexiques HPSG............................................................. 83
3.2. Module de projection................................................................................................ 85
4. Interfaces ralises ......................................................................................................... 94
5. Evaluation ....................................................................................................................... 99
Conclusion......................................................................................................................... 101
Conclusion gnrale ............................................................................................................. 102
Bibliographie......................................................................................................................... 104
Annexe A: Le DTD de la norme LMF................................................................................ 109
Table de figures
Figure 1.1. Echantillon du Morphalou ... 11
Figure 1.2. Ajout dun nouveau lexique .
12
Figure 1.3. Tableau de la conjugaison du verbe " "..
13
Figure 1.4. Arbre lmentaire canonique et arbres et arbres lmentaires non 14

canoniques ..
Figure 1.5. Conversion des arbres lmentaires canoniques vers des entres en HPSG ..
15
Figure 1.6. Rgle de substitution 15

Figure 1.7. Rgle dadjonction 16
Figure 1.8. Application des rgles grammaticales larbre de drivation LTAG pour 16
lexemple what you think he loves ...
Figure 1.9. Exemple dapplication de la procdure divide_tree_into_subtrees
17
Figure 1.10. Schmas de domination .
18
Figure 1.11. Exemple dun arbre auxiliaire 19

Figure 1.12. Arbre de drivation de what Kim gives to Sandy ..
20
Figure 2.1. SAV du nom livre .
24
Figure 2.2. Squelette gnral dun mot arabe 26

Figure 2.3. Le nom et ses catgories ..
27
Figure 2.4. Modle dune SAV dun nom ...
28
Figure 2.5. SAV du nom ...
29
29
30
Figure 2.8. SAV du nom ... 31

Figure 2.9. Types de particules ..
32
Figure 2.10. Modle dune SAV dune prposition
33
Figure 2.11. Modle dune SAV dun outil
33
Figure 2.12. SAV de la particule
34
Figure 2.13. SAV de la particule
34
Figure 2.14. Type des verbes .
35
Figure 2.15. Modle dune SAV dun verbe ...
36
Figure 2.16. SAV du verbe 36
Un prototype de projection du HPSG vers LMF
Hla Fehri
Figure 3.1. Modle noyau ... 40

Figure 3.2. Sous-classes de Form ..
41
Figure 3.3. Dpendance des extensions .
43
Figure 3.4. Reprsentation simplifie de la catgorie de donnes /gender/ ..
44
Figure 3.5. Processus LMF
45
Figure 3.6. Modle morphologique
46
Figure 3.7. Diagramme dobjets reprsentant la partie flexionnelle de sans 47

paradigme flexionnel ...
Figure 3.8. Diagramme dobjets reprsentant la partie flexionnelle de avec 47
paradigme flexionnel ...
Figure 3.9. Modle syntaxique ...
48
Figure 3.10. Diagramme dobjets reprsentant le comportement syntaxique du verbe 49

.
Figure 3.11. Modle smantique
50
Figure 3.12. Diagramme dobjets reprsentant le rapport entre la syntaxe et la 52

smantique du verbe ...
Figure 4.1. Exemple dapplication de la rgle R5m
58
59
Figure 4.3. SAV du verbe .. 62

Figure 4.4. Diagramme dobjets du verbe 63
Figure 4.5. Fragment en format LMF relatif lentre lexicale . 64
Figure 4.6. Etapes de la dmarche propose .
65
Figure 4.7. Extraction dun fragment xml dune entre lexicale ...
66
Figure 4.8. Organigramme rcapitulatif
68
Figure 4.9. Extraction du fichier reprsentant les schmes des formes drives ... 70
Figure 4.10. Exemple des verbes dune mme entre lexicale ...
71
Figure 4.11. Formes flchies de projetes dans LMF ..
72
Figure 4.12. Fichier LMF obtenu aprs lajout de ..
73
Figure 4.13. Projection des traits de la SAV dun mot ... 74

Figure 5.1. Architecture du prototype ralis
78
Figure 5.2. Diagramme des cas dutilisation du prototype ralis .................................... 80

Figure 5.3. Diagramme de squences du cas Projection vers LMF ..
81
Figure 5.4. Diagramme de classes du prototype ralis
82
II
Hla Fehri
Figure 5.5. Organisation du fichier Verbes.xml . 84

Figure 5.6. Extraction du fragment dune entre lexicale .. 86
Figure 5.7. Position de la projection dun verbe forme canonique ou forme flchie 87
dune forme canonique ..
Figure 5.8. Position de la projection dun verbe forme drive ou forme flchie dune 88
forme drive .
Figure 5.9. Schme de la forme drive .
89
Figure 5.10. Extraction de la valeur dun trait ..
90
Figure 5.11. Choix de l mthode de projection .
91
Figure 5.12. Projection dun verbe.
92
Figure 5.13. Rgle de projection
93
Figure 5.14. Forme dune entre lexicale ..
94
Figure 5.15. Interface daccueil .
95
Figure 5.16. Ouverture du fichier Verbes.xml 96

Figure 5.17. Projection du Verbes.xml ... 97
Figure 5.18. Ajout dun verbe
98
Figure 5.19. Affichage des entres contenues dans Verbes.xml . 98

Figure 5.20. Tableau rcapitulatif des rsultats obtenus aprs la projection ...
III
99
Introduction gnrale
Un langage donn ne peut pas exister sans lexique riche. Pour cela, l'analyse descriptive de ce
lexique, discern comme matire structure ou structurable, devient un facteur prioritaire et
basique pour toutes les applications qui ont pour objet le langage naturel. En effet, le lexique
n'est pas une matire inerte mais dynamique, qui change sans cesse. En plus, il est le premier
"rcipient" de la grammaire d'une langue vu que les mots peuvent tre subdiviss et flchis.
La communaut du traitement automatique des langues (TAL) a propos un ensemble de
lexiques. Selon leur usage, nous pouvons distinguer diffrents types [14], [35]. Parmi
lesquels, nous pouvons citer : les lexiques morphologiques qui servent entre autre
ltiquetage (puis la dsambigusation), la lemmatisation et la correction. Nous trouvons
aussi les lexiques grammaires qui se basent sur la sous catgorisation syntaxique (i.e.,
constituants, dpendances) et les thsaurus qui sont utiliss pour la rsolution automatique
danaphores nominales, pour la recherche dinformations et lextraction des termes et des
concepts.
Du fait de la diversit des lexiques, lchange des donnes nest pas une tche trs facile,
surtout entre des lexiques de familles diffrentes. La fusion des dictionnaires reste une
opration trs complexe. Un autre problme rside lors de la construction du lexique luimme. En effet, pour construire une entre du dictionnaire, le lexicographe doit rechercher les
diffrents
usages
de
lentre
donne.
Il
ne
peut
pas
se
contenter
de
son
intuition linguistique. De plus, la construction doutil pour le lexique pose des problmes
informatiques forts du fait de la masse des informations construire. En outre, la modification
de la structure du dictionnaire, afin de mieux prendre en compte certains phnomnes qui ont
t mal valus ou sous-estims, peut se traduire par un changement des interfaces dont
dispose le lexicographe et par une modification des ventuels outils de vrifications
automatiques de cohrence.
Plusieurs chercheurs dans le domaine de linformatique linguistique ont propos des
lexiques grammaires HPSG dans le cadre de diffrentes applications telles que lanalyse
syntaxique dune langue naturelle et la construction dun dictionnaire lectronique [3], [6],
[8], [31]. Lvaluation et la rcupration des rsultats fournis par ces applications ne sont pas
des tches faciles car celles-ci nutilisent pas gnralement des ressources lexicales
normalises telles que le lexique. En outre, les ressources utilises peuvent contenir des
catgories de donnes diffrentes. De ce fait, des langages pivots sont ncessaires afin de
faciliter la cration de telles ressources utilisant des mcanismes de fusion ou
dinteroprabilit. Il sagira donc ventuellement de choisir une norme de reprsentation et
Hla Fehri
description pour le traitement automatique du langage naturel [20] vu lexistence de plusieurs

lexiques grammaires HPSG non valus et assez dvelopps.
Cest dans ce cadre que sinscrit le prsent travail. En effet, lobjectif principal est de
proposer une dmarche permettant de projeter un lexique grammaire HPSG vers un langage
pivot normalis et compatible avec le standard LMF (Lexical Markup Framework) qui est
valid par le comit ISO TC 37/SC4. Cela va nous permettre de vrifier le degr de
couverture des lexiques syntaxiques HPSG dj labors et de pouvoir fusionner les rsultats
obtenus. En effet, le mme processus peut tre appliqu sur des lexiques provenant de
formalismes dunification diffrents. La dmarche, que nous prconisons dans notre travail,
tient compte des spcificits du formalisme HPSG adapt la langue arabe et de la possibilit
dappliquer LMF sur ce formalisme. Cest pourquoi, pour la russite de la projection des
lexiques syntaxiques HPSG vers LMF, une tude dtaille sur les deux concepts est effectue
afin de dgager, dune part, les adaptations qui peuvent tre apportes HPSG et dautre part,
les ajouts relatifs la norme 12620 des catgories de donnes. Cette tude nous permet de
dgager un systme de rgles dfini dune faon formelle. Ce systme est utilis dans le
processus de projection.
Le prsent mmoire est compos de cinq chapitres.
Dans le premier chapitre, nous prsentons quelques travaux existants sur la normalisation
et sur la projection dun formalisme vers un autre qui ont t effectus afin de faciliter
lchange des rsultats, des lexiques et des ressources raliss par diffrentes communauts de
recherche utilisant des formalismes diffrents.
Le deuxime chapitre est consacr une tude sur le formalisme HPSG. Nous prsentons
au dbut un aperu gnral sur ce formalisme. Ensuite, nous dcrivons larabisation de ce
dernier ainsi que les modifications qui ont t faites afin de pouvoir projeter HPSG vers LMF.
Enfin, nous achevons le chapitre en donnant quelques exemples des structures
attributs/valeurs mettant en relief les changements effectus.
Le troisime chapitre sintresse la plate-forme LMF destine la projection. En effet,
nous commenons tout dabord par prsenter la norme LMF. Ensuite, nous dcrivons sa
structure. Puis, nous donnons une ide sur les catgories de donnes qui peuvent tre utilises
dans cette norme. Enfin nous terminons par le dtail des extensions dont nous avons besoin
dans notre travail et qui sont illustres par quelques exemples obissant la langue arabe.
Dans le quatrime chapitre, nous proposons une dmarche permettant de projeter un
lexique HPSG vers LMF. Cette dmarche est base sur une tude effectue sur les diffrentes
SAVs du formalisme HPSG et sur un systme de rgles dgag partir des modles prsents
Hla Fehri
dans LMF. Nous prsentons aussi dans ce chapitre lalgorithme de base de la projection
proprement dite qui inclut plusieurs cas discuter. Enfin, nous donnons un exemple illustrant
les diffrentes tapes de la dmarche propose.
Le cinquime chapitre est consacr la ralisation informatique tout en suivant la
dmarche dcrite dans la partie prcdente. Nous prsentons dans un premier temps
larchitecture gnrale du prototype ralis. Nous passons par la suite la conception et
limplmentation de ce dernier. Nous choisissons pour ce faire le langage UML pour la
conception et la modlisation objet du prototype et le langage JAVA pour limplmentation
qui va permettre de valider les ides proposes.
Ce travail sera cltur par une conclusion et des perspectives qui sont actuellement en
cours et dautres qui peuvent tre raliss ultrieurement.
Chapitre 1
Chapitre 3 :
Etat de lart
Hla Fehri
Le prsent chapitre est ddi la prsentation de quelques travaux en faveur de lchange des
rsultats, des lexiques et des ressources linguistiques faites par diffrentes communauts de
recherche adoptant des formalismes linguistiques diffrents. Ces travaux sont intresss par
la proposition des normes concernant la reprsentation des lexiques ou bien par le traitement
de la traduction dun formalisme linguistique vers un autre.
Nous dbutons ce chapitre en donnant un aperu sur les lexiques HPSG arabes existants.
Ensuite, nous dtaillons le concept de la normalisation en prsentant quelques normes
existantes et des travaux qui en dcoulent. Enfin, nous donnons une ide sur quelques travaux
qui sintressent la traduction dun formalisme vers un autre.
1. Lexiques HPSG existants pour la langue arabe

Nous pouvons remarquer lexistence de plusieurs lexiques HPSG traitant des travaux
spcifiques la langue arabe. Nous remarquons aussi que ces lexiques sont de petites tailles
car chacun deux se concentre sur une tche particulire. Par exemple, nous pouvons citer les
travaux de [1], [4] et de [13].
Le travail de [4] consiste dvelopper un conjugueur arabe automatique. Le lexique utilis
pour ce faire est cr sous forme dun fichier xml qui contient trois cents verbes sous forme
canonique ou drive. Les adaptations effectues sur les SAVs sintressent essentiellement
aux aspects relatifs la conjugaison (i.e., le temps, la voix, la personne, le schme). Ce travail
se limite lutilisation des traits phonologiques, lexicaux et syntaxiques.
Le travail de [13] consiste effectuer une analyse syntaxique de la langue arabe dont le
lexique est rduit. Il est compos uniquement des mots de phrases choisies pour lanalyse.
Aucune adaptation na t faite pour le formalisme HPSG afin de raliser ce travail. De plus,
les traits utiliss se limitent ceux phonologiques, lexicaux et syntaxiques.
Sans oublier enfin de citer le travail de [29] qui consiste tudier la coordination ; cest
pourquoi le lexique cr afin de tester ce travail contient aussi des entres lexicales
reprsentant les conjonctions de coordination (i.e., ) . Les adaptations pour HPSG
sont effectues la lumire de cet objectif.
Bien que tous ces lexiques soient complmentaires, diffrents et que leur fusion puisse
engendrer un lexique riche contenant toutes les catgories lexicales de la langue arabe,
lopration de fusion reste assez complexe. En effet, les lexiques HPSG peuvent contenir des
catgories de donnes diffrentes surtout que ce formalisme possde plusieurs versions et est
utilis pour des langues diffrentes. Par consquent, nous pouvons marquer lexistence dun
Hla Fehri
certain nombre de traits dans un lexique mais non dans un autre. De plus, ces lexiques
peuvent exister sous diffrents formats (i.e., xml, binaire) ce qui fait de leur rcupration une
tche plus dlicate.
En consquence et afin de raliser la rutilisation de telles ressources ainsi que leur fusion
et davoir des catgories de donnes standardises, le besoin de la normalisation devient de
plus en plus ncessaire.
2. Normalisation
La normalisation est une activit collective visant trouver des solutions pour des situations
rptitives par le biais de normes. Toute norme est conue comme un ensemble de
spcifications techniques qui doivent tre respectes afin de garantir le plus haut niveau de
qualit des activits et des produits. Elle est labore en collaboration et avec le consensus de
tous les intresss et elle est approuve par un organisme (i.e., ISO, OMG) qualifi sur le plan
national, rgional ou international.
2.1. Pourquoi normaliser ?

La normalisation effective des donnes manipules en ingnierie linguistique est cruciale. De
nombreux acteurs doivent pouvoir disposer de ressources linguistiques directement
exploitables ainsi que doutils de traitement rutilisables. Ces acteurs peuvent sintresser la
correction orthographique et grammaticale ainsi qu la traduction automatique .
De nombreuses initiatives ont port sur la normalisation au cours des annes passes
parmi lesquelles, nous pouvons citer celle de EAGLES (Expert Advisory Group on Language
Engineering Standards) [9], [10], [11] et [12], groupe europen qui a entam ses activits en
1993, dans le cadre dun programme de la commission europenne concernant lingnierie
linguistique. Lobjectif du groupe EAGLES est dencourager et de promouvoir llaboration
de recommandations et de directives relatives aux ressources linguistiques, aux outils
informatiques pour le traitement des donnes et pour leur valuation. Linitiative EAGLES
contribue acclrer lapprovisionnement de normes en soulignant les besoins de
normalisation dans le domaine de lindustrie de la langue. Mais ce groupe ne vise pas
produire des normes internationales mais prsenter les besoins et les exigences
dapplications oprationnelles et acclrer le processus de normalisation dans cette matire.
Hla Fehri
Dans ce contexte, le sous-comit TC 34/SC 4 de lISO a labor un cadre de

normalisation pour les diffrents formats et produits utiliss en ingnierie linguistique, qui
puisse rpondre diffrents dfis :
-
la multiplicit des niveaux de reprsentation : Le traitement de ce dfit ncessite dune

part de dfinir des mthodes permettant de combiner ces niveaux entre eux (annotation
syntaxique de corpus dj annot au niveau morpho-syntaxique) et dautre part de
garantir la cohrence de dfinition de descripteurs pouvant apparatre dans diffrents
types de reprsentation (ex. partie du discours dans une annotation morpho-syntaxique
et dans une structure lexicale) ;
la varit des approches : Ces approches diffrent dans le nombre et la nature des
descripteurs utiliss ou encore dans lorganisation mme des donnes correspondantes
(ex. annotation syntaxique hirarchique ou base de relations de dpendances) ;
le multilinguisme : Il exige de tenir compte de linapplicabilit de certains concepts

dune langue une autre (ex. varits des types de morphologies, dcoupage en mots,
varit des mcanismes de regroupement de syntagmes dans la phrase), tout en
garantissant une certaine universalit des cadres normatifs proposs. Citons
simplement deux exemples de difficult : lEurope comporte maintenant plus de 20
langues trs diffrentes les unes des autres. Quel rapport existe-t-il entre le maltais qui
est une langue smitique (arabe pour faire simple) et lestonien qui est une langue
finno-ougrienne ? Lautre exemple est le chinois qui autorise plusieurs translitrations
du mme mot comme "non-spaced pinyin" par opposition "spaced pinyin and tone".
Ces diffrents aspects poussent dfendre la normalisation qui nimpose pas de format
particulier de reprsentation, mais mne au contraire la dfinition des plate-formes de
spcification de tels formats.
2.2. Normes au sein de lISO-TC37

LISO a adopt une direction (SC4) forme de plusieurs chercheurs de diffrents pays qui
consiste dfinir une famille de normes destines au TAL de lISO-TC37 parmi lesquelles,
nous pouvons citer les suivantes :
-
ISO-12620 pour les catgories de donnes :

Dans cette norme, il s'agit de spcifier deux formats : le format des catgories de
donnes telles qu'elles sont gres dans le registre des catgories de donnes (DCR) et
7
Hla Fehri
le format de la slection des catgories de donnes (DCS) pour un usage particulier

afin de dcorer un modle structurel. Ces deux formats sont spcifis dans la norme
ISO-12620 propose par [33].
-
ISO-24614 pour la segmentation des mots

Il s'agit de spcifier comment sparer les mots dans une phrase d'une langue donne et
d'en produire une reprsentation. La spcification est intimement lie la dfinition de
ce qu'est un mot dans la langue en question. La norme en est au stade prparatoire (et
les chefs de projet sont Eric de la Clergerie, Maosong Sun (dlgation chinoise), KeySun Choi (dlgation corenne) et Hitoshi Isahara (dlgation japonaise)).
ISO-24611 pour lannotation morpho-syntaxique

L'objectif est de spcifier comment annoter une phrase avec des marqueurs morphosyntaxiques comme une partie du discours (e.g. /noun/) ou un trait de genre (e.g.
/feminine/). L'annotation est soit humaine (manuelle, autrement dit) afin par exemple
de constituer un corpus destin l'apprentissage ou bien automatique parce qu'elle est
le rsultat d'un logiciel d'annotation (le "part of speech tagging" de l'anglais). La
norme en est au stade comit et le chef de projet est Eric de la Clergerie (France).
ISO-24615 pour lannotation syntaxique

Il s'agit de spcifier comment reprsenter le rsultat d'une analyse syntaxique sur une
phrase. Les annotations consistent par exemple dterminer le sujet ou les
rattachements entre groupes syntaxiques. L'annotation est soit humaine soit
automatique. La norme en est au stade prparatoire et le chef de projet est Thierry
Declerck (dlgation allemande).
ISO-24613 pour le dictionnaire

La norme LMF de spcification de dictionnaire destin au TAL se prsente sous forme
d'une partie noyau et d'un ensemble de cinq extensions. La partie noyau spcifie les
notions de lexique, de mot, de forme et de sens. Les extensions traitent de la
morphologie, du paradigme de flexion, de la syntaxe, de la smantique et des notations
multilingues. La norme en est au stade prparatoire et les chefs de projet sont Monte
George (dlgation amricaine) et Gil Francopoulo (France).
Daprs [18], [19], ces normes sont de bas et de haut niveau :

des normes de bas niveau pour les constantes. Les normes existantes sont ISO/IEC10646 pour le codage des caractres, ISO-639 pour les codes de langue, ISO-3166
pour les codes des pays, ISO-15924 pour les codes des scripts. La nouvelle norme
traite des constantes spcifiques au TAL qui sont dclares dans un registre de
8
Hla Fehri
catgories de donnes. Ce sont soit des noms d'attribut comme /grammatical gender/
soit des valeurs comme /feminine/. Chaque constante possde un identifiant unique,
des noms d'affichage plurilingues et des dfinitions plurilingues. Ce registre est
soumis un ensemble de rgles dcrites dans la rvision de l'ISO-12620. Le logiciel
qui gre la base de donnes a t dvelopp par l'quipe Syntax du Loria. Le DCR est
actuellement hberg par l'INIST-CNRS.
des normes de haut niveau qui se fondent sur les normes de bas niveau et qui
spcifient les structures. Il s'agit de spcifier les meilleures pratiques du domaine et de
couvrir la majorit des situations relles. Ces structures (quelque fois appeles mtamodles) sont constitues des lments importants et des liens d'association qui les
relient. Mais la liste des attributs de chaque lment n'est pas dcrite. Le document
normatif spcifie que tel lment est destin tel usage et non tel autre. Chaque
lment doit tre dcor par des couples attributs-valeur prendre obligatoirement
dans le registre de catgorie de donnes. Ces normes sont TMF [36], [37], LMF et
MAF. La premire (i.e. TMF pour Terminological Markup Framework ISO-16642)
traite des terminologies dentreprise quelles soient monolingues ou multilingues. La
seconde (i.e. LMF pour Lexical Markup Framework ISO-24613) couvre les
dictionnaires dans une large mesure, que ce soient les lexiques destins au traitement
automatique du langage ou bien les bases de donnes ditoriales servant de support de
traduction aux grandes administrations. La troisime norme (i.e. MAF pour Morphosyntactic Annotation Framework ISO-24611) traite de lannotation des corpus que
celle-ci soit effectue par un tre humain ou bien par un programme. Dans la mesure
o ces trois normes de haut niveau changent les mmes constantes et quelles sont
dfinies en XML, linteroprabilit entre elles est trs forte.
Les normes de haut niveau sont proches des utilisateurs puisquelles enregistrent les pratiques
des experts, alors que les normes de bas niveau sont plus du domaine de la "tuyauterie". Mais
les unes ne vont pas sans les autres.
2.3. Travaux bass sur la normalisation

Parmi les travaux bass sur les ressources lexicales du TAL lISO (TC37/SC4), nous
pouvons citer MorPhaLou [38], Lexus [26] et ArabicLDB [27] que nous allons prsenter ciaprs.
Hla Fehri
2.3.1. Morphalou
Les enjeux derrire le dveloppement dune telle ressource [30] et [40] sont de deux
ordres : garantir une large couverture et validit linguistique rendant crdible le projet vis-vis des communauts intresses et proposer une structure cohrente et bien documente afin
dassurer la prennit des donnes correspondantes. Le projet sorganise autour de deux sites
complmentaires : lATILF qui apporte les donnes et la comptence linguistique, et le
LORIA qui apporte son exprience en matire de manipulation de documents semi-structurs
et de normalisation des ressources linguistiques.
Lobjectif initial la cration dun lexique morphologique normalis, cest--dire document
et sintgrant aux travaux de normalisation en cours au niveau national (RNIL) et
international (ISO/TC 34/SC 4) a t ralis courant 2004. Morphalou sert, entre autre, dans
un projet de dictionnaire franais-estonien (INALCO, Paris), dans le dveloppement dun
analyseur syntaxique (Loria, Nancy) et dans la description des proprits flexionnelles des
entres dun dictionnaire de franais qubcois (projet Franqus, Sherbrooke, Canada).
Morphalou traite la variation morphologique, orthographique et flexionnelle au niveau du
lemme ainsi que la variation (accidentelle) pour une forme flchie. Il traite aussi la
fminisation bien que la porte dune telle information dpasse le cadre strict dun lexique
morphologique flexionnel. Pour l'instant, Morphalou ne contient aucune forme compose,
qu'elle soit graphiquement marque ou non (pomme de terre, parce que, fait-tout). Par
ailleurs, le lexique ne comprend ni noms propres (Paris, Matignon), ni abrviations (ONU,
C.R.S.). La figure 1.1 reprsente un chantillon du Morphalou.
<lexicalEntry
lemma="lexique"
grammaticalCategory="commonNoun"
grammaticalGender="masculine" >
<inflectionGroup>
<inflection
orthography="lexique"
grammaticalNumber="singular" />
<inflection
orthography="lexiques"
grammaticalNumber="plural" />
</inflectionGroup>
</lexicalEntry>
<lexicalEntry
lemma="morphologique"
grammaticalCategory="adjective" >
<inflectionGroup>
<inflection
orthography="morphologique"
grammaticalGender="masculine"
10
Hla Fehri
<inflection
orthography="morphologique"
grammaticalGender="feminine"
<inflection
orthography="morphologiques"
grammaticalGender="masculine"
<inflection
orthography="morphologiques"
grammaticalGender="feminine"
</inflectionGroup>
</lexicalEntry>
Figure 1.1. Echantillon du Morphalou
Lchantillon illustr dans la figure 1.1 dcrit le squelette structurel du lexique Morphalou
qui comprend comme lments /LexicalEntry/, /InlectionGroup/ et /Inflection/. Le premier
reprsente un lemme catgorie grammaticale unique. Ce choix implique la cration de deux
entres pour des formes identiques catgorie distincte. Le deuxime regroupe toutes les
informations flexionnelles relatives un et un seul paradigme flexionnel. Le troisime
correspond une forme d'occurrence du lemme. Il existe au moins une forme flchie par
entre. Cela implique en particulier de considrer la forme d'occurrence des invariables
(adverbe, interjection, etc.) comme une forme flexionnelle. Les catgories de donnes
reprsentes dans la figure 1.1 relatives une entre lexicale sont /lemma/,
/grammaticalCategory/ et /grammaticalGender/ et celles qui sont associes une forme
flchie sont /orthography/, /grammaticalGender/ et /grammaticalNumber/.
2.3.2. LEXUS
Dans ce paragraphe, nous allons prsenter un systme qui se base sur la future norme LMF
baptise LEXUS [26].
LEXUS est un outil de cration de bases de donnes lexicales. Il est utilis surtout par les
psycholinguistes de Nimgue Hollande. En effet, il aide les linguistes travailler avec un
corpus dune langue donne. LEXUS qui est bas sur la plate-forme LMF est compatible avec
plusieurs autres logiciels ; il peut servir comme administrateur de logiciel de lexiques et
permet de convertir et dunifier des lexiques.
Parmi les fonctions fournies par LEXUS, nous pouvons citer celles permettant la cration
dun nouveau lexique ou dune nouvelle catgorie de donnes, permettant lajout dune
11
Hla Fehri
nouvelle entre lexicale et la synchronisation avec un lexique se trouvant sur le serveur. La

figure 1.2 illustre, titre dexemple, la fonction dajout dun lexique.
Figure 1.2. Ajout dun nouveau lexique
Comme lillustre la figure 1.2, lutilisateur de ce systme doit tout dabord, choisir le menu
Lexical Resource et activer la commande New afin dajouter un nouveau lexique.
Ensuite, il doit entrer le nom du lexique accompagn dune description courte. Enfin, il
enregistre les nouvelles informations saisies en cliquant sur le bouton Save.
En conclusion, bien que le systme LEXUS permette la cration des bases de donnes
lexicales standardises, il nintgre pas un vrificateur de contraintes lexicales de la langue
traite.
2.3.3. ArabicLDB
Le systme ArabicLDB [27] comporte essentiellement une base de donnes lexicale qui a t
effectue dans le cadre dun projet de coopration entre le laboratoire MIRACL, lunit de
recherche LSCA et le laboratoire Loria / INRIA. Cette base est conforme la future norme
LMF dans sa version actuelle (rvision de Mars 2006). Quant sa ralisation, elle est
effectue en XML avec un gestionnaire conu en JAVA. En outre, ArabicLDB est dote dun
conjugueur des verbes sur un processus de calcul des formes flchies. En effet, elle comporte
tous les paradigmes de flexion verbales (259) formes qui couvrent plus de 16000 entres
lexicales verbales. La figure 1.3 illustre la conjugaison du verbe " "suivant ArabicLDB.
12
Hla Fehri
Figure 1.3. Tableau de conjugaison du verbe ""
En conclusion, bien quArabicLDB soit conforme la future norme ISO 24613, son travail
sest limit au niveau morphologique. Ainsi, il manque les autres niveaux : syntaxique, et
smantique. En outre, il na trait que les verbes conjugables : il reste traiter les verbes semi
conjugables et non conjugables.
3. Traduction dun formalisme vers un autre

La traduction dun formalisme vers un autre nest pas une tche facile car chaque formalisme
possde ses propres spcificits. Pour ce faire, il existe peu de travaux qui sintressent ce
problme. Dans ce qui suit, nous allons dcrire deux projets [25] et [41] qui traitent ce point.
3.1. Projection de FB-LTAG vers HPSG

Dans [41], lauteur a propos un algorithme permettant la conversion de la grammaire FBLTAG Feature-Based Lexicalized Tree Adjoining Grammar, qui est une extension du
13
Hla Fehri
formalisme LTAG, vers la grammaire HPSG. Vu que LTAG est bas sur un ensemble fini
darbres lmentaires et sur deux oprations : ladjonction et la substitution, lalgorithme de
conversion utilis est bas sur deux grandes parties : la conversion des arbres lmentaires
vers des entres lexicales en HPSG et la ralisation de la substitution et de ladjonction par
des rgles grammaticales pr-dtermines.
Ainsi, la premire partie de cet algorithme consiste dfinir les arbres lmentaires
canoniques et trouver pour chacun lentre lexicale correspondante en HPSG sachant quun
arbre lmentaire canonique doit satisfaire les deux conditions suivantes :
Condition 1 : Un arbre a seulement une ancre.
Condition 2 : Chaque structure du branchement dans un arbre contient des nuds du tronc.
Notons que les arbres lmentaires non canoniques doivent tre tout dabord transforms
en arbres lmentaires canoniques avant dtre convertis en des entres lexicales en HPSG en
utilisant lalgorithme correspondant. La figure 1.4 donne une ide sur les arbres lmentaires
canoniques et ceux qui ne sont pas canoniques.
Figure 1.4. Arbre lmentaire canonique et arbres lmentaires non canoniques
Le premier arbre 1) de la figure 1.4 est un arbre lmentaire canonique. Les deux autres ne
le sont pas ; en effet, le deuxime 2) ne vrifie pas la condition 1 puisquil admet plus dun
nud ancr (look et for) par contre, le troisime 3) ne satisfait pas la condition 2 vu quil
admet un sous-arbre ne possdant aucun nud ancr. Dans ce qui suit, on va dtailler la
conversion des arbres lmentaires canoniques vers des entres HPSG.
3.1.1. Conversion des arbres lmentaires canoniques
La conversion des arbres lmentaires canoniques se fait directement en utilisant la procdure
convert_tree_into_lexical_entry illustre dans la figure 1.5 et dtaille dans [41].
14
Hla Fehri
procedure convert_tree_into_lexical_entry(T)
begin
arg:= []
for i := 1 to depth(T) 1
ni-1:= trunk(T, i -1)
li := leaf(T, i)
di := direct (T, i)
ti := type (T, i)
bi := (ni-1, li, di, ti)
arg := [bi] arg
end for
L := (n depth(T) - 1, arg)
return L;
end
depth: returns the depth of the anchor.
trunk: returns the symbol of the trunk node.
leaf: returns the side of the leaf node at depth i.
direct: returns the side of the trunk node for the node at depth i.
type: returns the type of the leaf node at depth i.
Figure 1.5. Conversion des arbres lmentaires canoniques vers des entres en HPSG
Dans cette procdure, Arg reprsente un tas de branchements bi dcrit par le quadruplet <ni-1,
li, di, ti> le long du tronc. Le paramtre ni-1 reprsente le noeud mre ni du noeud tronc. Les
paramtres li, di et ti reprsentent respectivement le noeud feuille une profondeur i, sa
direction relative au tronc ni et son type (sil est un nud pied ou un noeud de substitution).
Une fois la conversion des arbres lmentaires canoniques faite, on passe lapplication des
rgles dadjonction et de substitution illustres respectivement dans les figures 1.6 et 1.7 pour
obtenir lquivalent de LTAG en HPSG.
Figure 1.6. Rgle de substitution

On peut noter que dans la rgle de substitution, la valeur du trait Arg du nud, auquel va
tre appliqu la substitution, doit tre vide alors que la valeur de Sym doit tre identique
15
Hla Fehri
celle du nud feuille du nud tronc. Cette rgle permet lunification des valeurs du trait Arg
du nud tronc avec les valeurs du trait Arg du nud mre afin de poursuivre la construction
de larbre.
Figure 1.7. Rgle dadjonction
Dans la rgle dadjonction, la valeur du trait Sym du nud pied doit tre identique celle
du nud feuille du nud tronc. La concatnation des valeurs des traits Arg du nud pied et
des lments de la queue du tronc constitue la valeur de Arg du nud mre. Dans les deux
rgles, la valeur de Foot? dtermine quelle est la prochaine rgle appliquer : celle de
substitution (Foot ? = -) ou dadjonction (Foot ? = +). La figure 1.8 reprsente un exemple
dapplication de ces rgles.
Figure 1.8. Application des rgles grammaticales larbre de drivation LTAG pour
lexemple what you think he loves
16
Hla Fehri
Dans la figure 1.8, les lignes paisses indiquent larbre avoisin 1 et les lignes pointilles
indiquent larbre contigu 1.
3.1.2. Conversion des arbres lmentaires non canoniques
Pour les arbres lmentaires non canoniques, la conversion se fait de la mme faon mais
aprs les avoir convertis en arbres lmentaires canoniques. Dans le cas o larbre est multiancr (MT), il doit tre divis en un ensemble de sous arbres (ST) dont chacun doit avoir un
seul nud ancr en utilisant la procdure divide_tree_into_subtrees dtaille dans larticle
[41]. La figure 1.9 est propose comme exemple dapplication de cette procdure.
Figure 1.9. Exemple dapplication de la procdure divide_tree_into_subtrees
La procdure divide_tree_into_subtrees commence par slectionner un seul nud

ancr et le seul sous-arbre qui le comporte. Ensuite, elle parcourt le sous-arbre slectionn du
nud racine jusqu lancre A. Puis, elle coupe le nud cut-off nodes ayant les mmes
parents que ce dernier sil nest pas un nud feuille. Enfin, elle stocke l'adresse de l'arbre
lmentaire dont le noeud coup va avoir un identificateur. Cette procdure est tendue par un
algorithme appel expand_tree_into_anchored_tree. Il permet de convertir les sous-arbres
non ancrs, dj extraits de la procdure divide_tree_into_subtrees, vers des arbres multiancrs en remplaant le nud substituer qui existe sur le branchement le plus profond par
chaque arbre du candidat pour la substitution. Ces arbres sont slectionns parmi les arbres
canoniques
qui
existent
dj
et
ceux
qui
sont
obtenus
par
lalgorithme
divide_tree_into_subtrees. Bien quil existe plusieurs nuds substituer ou nuds pied, un

seul va tre substitu.
En conclusion, lalgorithme propos permet le partage des ressources LTAG avec la
communaut HPSG et lclaircissement des diffrences qui existent entre les analyses
linguistiques des deux formalismes.
17
Hla Fehri
Remarquons que le formalisme HPSG peut tre considr comme tant un formalisme
intermdiaire pour la conversion des arbres lmentaires canoniques vers LMF.
3.2. Projection de HPSG vers TAG
Dans [25], lauteur a propos un algorithme permettant la projection de HPSG vers TAG et
obissant certaines contraintes du TAG. Cet algorithme explore le rapport entre les deux
concepts employs dans ces deux thories. Lalgorithme propos a commenc, tout dabord,
par prendre un type lexical et crer un nud avec ce type. Le nud cr reprsente un
schma HPSG. Ensuite, il a ajout un nud n qui le domine. Puis, il est pass la slection et
la rduction des informations spcifies par le type lexical correspondant en utilisant le
schma de dominance appropri (voir figure 1.10). Le rsultat obtenu est alors un autre nud
m qui domine n. Enfin, lalgorithme refait cette dernire tape jusqu ce quaucune rduction
supplmentaire ne soit possible.
Figure 1.10. Schmas de domination
Notons que les schmas de dominance prsents dans la figure 1.10 sont trs importants
pour lapplication de cet algorithme. En effet, tous ces schmas satisferont le principe de
slection et de rduction. Rappelons que la slection veut dire la slection du nud fille
18
Hla Fehri
(Selector Daughter : SD) et la slection du trait correspondant (Selector Feature : SF) se

trouvant dans ce nud. Chaque schma de dominance doit rduire au moins un SF. En effet,
si on prend, par exemple, le cas de Head-Subj-Schema, on peut dire que HEAD-DTR
reprsente le SD et que SUBJ reprsente le SF. Par consquent, et daprs le principe de
slection et de rduction, la valeur de SUBJ (F), qui est gale lindice 2, slectionne le non
SD COMP-DTR dont la valeur ne doit pas tre contenue dans F du nud mre. On dit alors
que F est rduit par le schma en question.
Lexcution de lalgorithme dcrit ci-dessus a pour rsultat la production des arbres ayant
une trajectoire de lancre lexical jusqu la racine. Pour chaque arbre produit, il faut savoir sil
sagit dun arbre auxiliaire ou bien dun arbre initial. Un arbre est dit auxiliaire si le nud
pied et le nud racine ont en commun les mmes valeurs des SFs non vides sinon on parle
dun arbre initial. La figure 1.11 est lexemple dun arbre auxiliaire reprsentant un verbe
lev (exemple marque de linfinitif to).
Figure 1.11. Exemple dun arbre auxiliaire
Larbre T1 illustr dans la figure 1.11 est un arbre auxiliaire vu que les valeurs de SUBJ et de
SLASH du nud pied (marqu par *) qui sont non vides sont les mmes que celles du nud
racine. Ces traits peuvent tre rduits plus loin en les combinant avec un autre arbre.
Exemple 1 :
Soit la phrase en Anglais what Kim gives to Sandy. Le type lexical pris dans cette phrase
est celui du verbe gives qui sous catgorise un sujet et deux complments. De cette entre
lexicale, on peut obtenir larbre initial T2 illustr dans la figure 1.12.
19
Hla Fehri
Figure 1.12. Arbre de drivation de what Kim gives to Sandy
Larbre prsent dans la figure 1.12 est obtenu en utilisant respectivement les schmas de
domination suivants : le schma Lexical Slash-Termination-Rule, le schma Head-Comps,
Head-Subj et le schma Head-Filler. La substitution des nuds de la frontire constitue la
phrase what Kim gives to Sandy.
Ainsi, lalgorithme propos dcrit comment les spcifications de HPSG peuvent tre
compiles dans TAG dune manire fidle aux deux structures. Notons que lalgorithme a t
implment avec Lisp et a t utilis pour compiler un fragment considrable en HPSG
allemand. Il faut noter que les rsultats de la compilation ne sont pas toujours conformes avec
les suppositions conventionnelles adoptes dans TAG. Il faut noter aussi quil y a plusieurs
techniques attendues pour amliorer lanalyse grammaticale rsultant du TAG. Par exemple,
20
Hla Fehri
cest possible de dclarer les non SFs qui peuvent tre levs en rduisant de cette faon le
nombre darbres inutiles produits pendant la compilation phase multiple. La possibilit de
compiler HPSG dans une extension du TAG reste explorer.
Les algorithmes tudis prcdemment qui convertissent une grammaire vers une autre
permettent lchange, la comparaison et le partage des ressources lexicales.
Conclusion
Dans ce chapitre, nous avons prsent quelques travaux en faveur de la fusion et de lchange
des ressources lexicales pour le traitement automatique du langage naturel. De ce fait, nous
avons commenc tout dabord par prsenter quelques lexiques HPSG spcifiques la langue
arabe et le rapport qui existe entre eux afin de mettre en vidence le besoin de la
normalisation. Ensuite, nous avons mis en valeur le concept de normalisation puisque la
proposition des normes facilite la cration de telles ressources. Enfin, nous avons prsent
quelques travaux qui partagent le mme objectif mais par la traduction dun formalisme vers
un autre.
La ralisation des ces travaux ncessite quelquun qui matrise les deux grammaires
concernes par la projection et permet de comparer et dvaluer des recherches bases sur des
formalismes diffrents. Dans le mme but, sinscrit notre travail qui permet la projection des
lexiques grammaires sources vers un langage pivot cible, le LMF.
21
Chapitre 2
Lexique HPSG pour

lArabe
22
Hla Fehri
Le prsent chapitre est ddi ltude de la grammaire syntagmatique guide par les ttes,
mieux connue sous le nom HPSG puisque cest le formalisme concern par la projection dans
notre travail. Cette tude nous permet didentifier, dune part, les phnomnes linguistiques
qui sont traits par le HPSG et dautre part, les adaptations qui peuvent tre faites ce
formalisme pour atteindre notre objectif.
Dans ce chapitre, nous allons donner, dans un premier temps, une vue gnrale sur le
formalisme HPSG. Ensuite, nous dcrirons larabisation de ce formalisme en donnant une
ide sur les diffrents traits que nous avons ajouts afin de projeter HPSG vers LMF. Enfin,
nous achevons par quelques exemples des structures attribut/valeur (SAVs) en nous basant sur
les changement faits pour cette grammaire.
1. Aperu sur HPSG

Le formalisme des grammaires syntagmatiques guides par les ttes (en Anglais Head-driven
Phrase Structure Grammar, HPSG) a t conu depuis le dbut des annes 80 par Pollard et
Sag [31]. La thorie HPSG appartient la famille des thories bases sur les contraintes et
revendique lhritage de plusieurs cadres thoriques tels que GPSG (Generalised Phrase
Structure Grammar), CG (Categorial Grammar) et LFG (Lexical Fonctional Grammar) [3].
Nous distinguons trois volutions plus ou moins fondamentales au niveau de la structure et
des principes utiliss dans le formalisme HPSG. La premire version (appele HPSG I)
correspond la prsentation qui en a t faite dans louvrage [32]. La seconde version (HPSG
II) est dcrite dans [31] et constitue une volution sous de nombreux aspects : lorganisation
des structures de traits (regroupement des traits syntaxiques et smantiques, apparition de
nouveaux traits), la description de nouveaux principes et lvolution des principes de base
(principe des traits non locaux). Quant la troisime version (HPSG III), elle correspond
des volutions plus rcentes portant essentiellement sur une modification de la description de
la sous-catgorisation ainsi que sur labandon des catgories vides dans la description de
certaines constructions.
HPSG repose sur le cadre formel de la logique attribut/valeur. Les proprits formelles
sont ainsi dcrites dans un cadre homogne utile la fois dun point de vue strictement
thorique mais aussi dimplantation. Cette caractristique fait de HPSG la thorie la plus
utilise aujourdhui pour le traitement automatique de la langue naturelle. Parmi les traits de
la structure attribut/valeur (SAV), nous trouvons :
-
le trait phon : il indique la suite des mots du constituant.
23
Hla Fehri
le trait synsem : il regroupe lensemble des traits syntaxiques et smantiques

dcrivant le constituant.
le trait loc : il regroupe les informations essentielles un constituant.
le trait tte : les traits de tte permettent de donner les caractristiques concernant la
partie de discours elle-mme : son type, sa forme, ventuellement les constituants
slectionnes en dehors du cadre de la valence, etc.
le trait index : il a pour valeur les traits daccord. Ce trait est utilis pour indexer un
constituant et donc pour s'y rfrer.
le trait nonloc : il dcrit les relations quentretient le constituant avec dautres objets
nappartenant pas ncessairement la mme sous-structure syntaxique.
La figure 2.1 reprsente la SAV dun nom utilisant la majorit des traits dcrits
prcdemment.
Figure 2.1. SAV du nom livre
Lexemple de la figure 2.1 montre que Livre est un nom rfrenc. Ces informations sont
exprimes respectivement par les traits MAJ et NFORM. Le trait SPR qui est un trait
syntaxique indique que Livre peut tre prcd par un dterminant. Les traits daccord en
HPSG sont classs parmi les traits smantiques. Quant au trait INDEX, il montre que Livre
est un nom masculin singulier.
HPSG possde un certain nombre de schmas de combinaison qui sont exprims dans le
mme formalisme que les descriptions des mots. Ces schmas dcrivent la combinaison dune
tte et dun argument (head-complement-phrase, head-subject-phrase, ), dune tte et dun
modifieur (head-modifier-phrase), dune tte et dun lment extrait (head-filler-phrase) ou
de deux conjoints (coordinate-phrase). La combinaison de deux mots est en fait la
combinaison de leurs descriptions avec un schma de construction. La rpartition de
24
Hla Fehri
linformation linguistique entre descriptions de mots et schmas est formellement libre. Dans
ce qui suit, nous allons dtailler les diffrentes catgories lexicales caractrisant un lexique
HPSG Arabe.
2. Lexique HPSG arabe

Il existe plusieurs adaptations faites pour les SAVs en HPSG, mais ces adaptations ne sont pas
satisfaisantes pour la ralisation de la projection. Pour ce faire, nous avons vu quil est utile
dadapter ce formalisme la langue arabe en ajoutant quelques traits et valeurs qui vont
favoriser notre travail. Nous donnons dans la section suivante une description des traits
ajouts ainsi quune description des structures attribut/valeur pour chaque catgorie lexicale
non dcrite dans les travaux antrieurs.
2.1. Traits ajouts

Vu la richesse linguistique de la langue arabe et vu sa complexit en terme syntaxique, sa
reprsentation dans le formalisme HPSG standard conu spcialement pour les langues latines
ncessite la modification du contenu de quelques traits et lajout dautres traits inluctables
afin davoir un lexique HPSG arabe complet permettant la projection vers LMF. Parmi les
traits nouveaux ventuellement reformuls que nous avons vus essentiels, nous pouvons citer :
TRILITERE : ce trait est utilis pour les verbes et peut prendre comme valeurs (+) ou
() indiquant respectivement sil sagit dun verbe trilitre ( )ou quadrilitre
(). Ce trait est ncessaire pour minimiser laccs aux diffrents schmes qui
sont utiles pour savoir quelle forme canonique ou drive appartient lentre lexicale
concerne.
-
MOJARAD : ce trait est utilis pour les verbes et peut prendre comme valeurs (+) ou
() indiquant respectivement sil sagit dun verbe trilitre ( ) ou augment
(). Il est utile pour le mme but que TRILITERE.
TASGUIR : ce trait est utilis pour les noms et peut prendre comme valeurs (+) ou ()
pour indiquer respectivement sil sagit dun nom diminutif ( )ou non diminutif
() . Ce trait permet de distinguer sil sagit dune forme canonique ou bien
dune forme flchie.
25
Hla Fehri
NASAB : ce trait a le mme rle que le trait TASGUIR. Il peut prendre les valeurs (+)
ou () pour indiquer respectivement sil sagit dun nom relatif ( )ou non relatif
() .
NAT : ce trait est utilis afin de donner la nature dun nom. Parmi les valeurs qui
peuvent tre prises par ce trait, nous pouvons citer : .
Chaque valeur prise par ce trait reprsente une entre lexicale et exactement une forme
drive ou flchie.
RADICAL : Ce trait est ajout pour les noms afin de savoir quelle forme drive
appartient une forme flchie.
Nous avons aussi modifi la valeur du trait NFORM pour les noms. En effet, ce trait va
avoir comme valeurs : ( flexionnel driv) ( flexionnel inerte) et
( non flexionnel). Le trait NFORM nous permet de savoir si une forme canonique peut
avoir des formes flchies (ou mme drives) ou non.
En sinspirant de [5], la langue arabe dfinit un mot comme tant un genre qui catgorise
trois ensembles de base (particule, verbe et nom). La figure 2.2 illustre cette rpartition qui
sera dtaille dans les paragraphes qui suivent.
Figure 2.2. Squelette gnral dun mot arabe
A partir de la figure 2.2, nous identifions quun mot arabe peut tre un nom (), une
particule ( )ou un verbe ( ; )mais il existe dautres rpartitions pour ce mot par
exemple en considrant ladjectif comme une quatrime catgorie de base. Dans ce qui suit,
nous allons dtailler ces diffrentes catgories de mots.
2.2. Les noms

Il existe des traits qui sont propres la catgorie relative au nom. Il s'agit des traits de tte
NFORM, NAT, NASAB et TASGUIR ainsi que des traits appropris au sous-type nombre du
26
Hla Fehri
type contenu savoir INDEX et RESTR. Un des aspects fondamentaux de HPSG rside dans
la reprsentation au niveau lexical de certaines relations syntaxiques. Il s'agit en particulier
des relations de valence qui sont videmment reprsentes par le trait VALENCE. Ce trait est
compos dans la plupart des cas de notre exemple d'un seul lment SPR indiquant que ce
nom attend un spcificateur tout en identifiant son type. Le principe de valence permettra
d'tablir un lien entre la valeur du trait SPEC et le constituant effectivement ralis (i.e., le
dterminant utilis dans l'nonc). Les traits prsents seront dcrits par les matrices
attribut/valeur de la figure 2.4.
Figure 2.3. Le nom et ses catgories

27
Hla Fehri
Ce qui distingue la langue arabe est le fait que la catgorie nom se dcompose son tour en
plusieurs sous-ensembles savoir les noms flchis comme les noms figs (les noms propres
"" , noms de lieu "" ,) et ceux non figs (les adjectifs "" , nomagent "" ,) et les noms flchis (les pronoms dmonstratifs "" , les pronoms
"",...) Ces sous-ensembles sont dtaills dans la figure 2.3.
Tous les noms partagent le mme contenu de la SAV reprsente dans la figure 2.4 et ne
sont que les valeurs des traits qui changent avec lajout du trait MOD dans TETE pour les
adjectifs.
Figure 2.4. Modle dune SAV dun nom
Rappelons que dans la SAV dun nom, tous les traits morphologiques sont regroups dans
le trait TETE. Le seul trait syntaxique est SPR. Bien que les traits daccord en HPSG soient
classs parmi les traits smantiques en LMF, ils sont classs en LMF dans la partie
morphologique car ils concernent lentre lexicale elle-mme.
Puisque la catgorie nom est subdivise en plusieurs sous-catgories, nous devons prciser
leurs SAVs appropries.
-
Nom flchi fig () : comme lindique la figure 2.3, un nom flchi

fig peut tre un nom concret ( ) ou bien un nom abstrait () . La figure
2.5 et 2.6 sont deux exemples respectivement dun mot concret et dun mot abstrait.
28
Hla Fehri
Figure 2.5. SAV du nom ""
La figure 2.5 montre que le nom " "est un nom fig non dfini, non et non .
Ces informations sont donnes respectivement par les traits NFORM, DEFN, TASGUIR et
NASAB. Les traits NAT, RACINE et SPR montrent que ce nom reprsente un ""
ayant comme racine " "et qui peut tre prcd par un verbe " "ou un pronom
dmonstratif "" . Notons que le nom " "est un nom masculin " "singulier"".
Dans la figure 2.6, nous remarquons que les traits qui ont chang de valeur sont les traits
NAT, MASDAR, DEFN et GENR puisque " "est un nom propre ""
dfini" "et fminin"".Ce nom peut tre prcd par un verbe comme "
" ou par un pronom dmonstratif " " comme "" . Cette
29
Hla Fehri
information syntaxique est exprime par le trait SPR qui appartient VALENCE. Un nom
propre peut tre employ comme tant un adjectif et dans ce cas il faut apporter des
modifications dans la SAV approprie.
-
Nom flchi driv : un nom flchi est dit driv sil est obtenu partir dun verbe. La
figure 2.7 est un exemple dune SAV qui reprsente un adjectif.
Le trait NAT de la SAV de la figure 2.7 montre que le nom " "est un adjectif "" .
Gnralement ladjectif reprsente lui-mme une catgorie indpendante comme le nom et le
verbe au contraire de la langue arabe.
Nous remarquons que dans la SAV des adjectifs, existe la plupart des traits dcrivant les
noms. Il y a cependant deux diffrences essentielles. Tout dabord, la valence est une liste
vide. En dautres termes, il sagit dun signe satur, ne construisant aucun complment. Par
ailleurs, nous remarquons parmi les traits de tte, le trait MOD qui a pour valeur le constituant
modifi par ladjectif. Le trait MOD jouera essentiellement le mme rle que SPEC pour les
spcificateurs.
-
Nom non flchi ( ) : le nom non flchi est celui qui garde le mme
tat. Ce nom peut tre un pronom, un pronom dmonstratif, un nom interrogatif etc.
La figure 2.8 illustre un exemple dune SAV dun pronom.
30
Hla Fehri
La SAV de la figure 2.8 est un autre exemple reprsentant une catgorie diffrente
appartenant au nom. Cest la catgorie des noms non flchis. Le trait NAT indique le sousensemble dans lequel figure lentre lexicale et dans notre cas, il sagit dun pronom "".
Nous remarquons que la SAV du pronom " "contient la plupart des traits existants dans les
deux SAVs prcdentes vu que ces trois entres lexicales appartiennent la mme catgorie
principale nom.
2.3. Les particules

Les particules sont des mots qui servent situer les vnements et les objets par rapport au
temps et l'espace, et permettent un enchanement cohrent du texte. Les particules
reprsentent une autre catgorie pour un mot arabe et peuvent tre des lettres de construction
( ) comme ou des lettres de signification ( ) .Ces dernires sont
divises leur tour en deux sous-catgories : la premire regroupe les particules qui nont
aucun effet sur le mot alors que la deuxime englobe les particules qui ont des effets sur le
nom (... ) ou le verbe (... ) ou les deux (
... ). Les diffrentes sous-catgories des particules sont dtailles dans la figure 2.9.
31
Hla Fehri
Figure 2.9. Types de particules
Pour les particules, nous avons propos deux modles de SAVs diffrents, lun est utilis
pour les prpositions et lautre pour les outils. Ces deux modles de SAVs sont illustrs
respectivement dans les figures 2.10 et 2.11.
32
Hla Fehri
Figure 2.10. Modle dune SAV dune prposition
Les traits morphologiques dune prposition sont regroups dans le trait TETE. Notons que
les traits daccord sont relatifs au complment admis par cette prposition.
Figure 2.11. Modle dune SAV dun outil
Remarquons quil existe une grande diffrence entre la SAV dune prposition et celle
dun outil. Cette diffrence rside dans les traits TETE, VALENCE et CONT. En effet, dans
la SAV dune prposition, nous remarquons lexistence du trait PFORM comme trait
morphologique. Par contre, dans la SAV dun outil, le trait SPEC prend sa place. De plus, le
trait VALENCE et les traits daccord existent pour une prposition mais non pour un outil.
De mme, pour le trait INDEX. Dans ce qui suit, nous donnons quelques exemples de SAVs
qui correspondent des catgories diffrentes de particules.
33
Hla Fehri
Figure 2.12. SAV de la particule ""

La figure 2.12 montre que lentre lexicale " "est une particule faisant partie des lettres
de signification et spcifiant (prcdant) un verbe accusatif ( )qui doit tre conjugu
linaccompli (). Ces informations sont exprimes respectivement par les traits MAJ,
NAT, SPEC et RESTIND.
Figure 2.13. SAV de la particule ""
La figure 2.13 reprsente un exemple dune SAV dune prposition. Dans cette SAV, nous
remarquons lutilisation du trait VALENCE. En effet, la particule " "admet un complment
qui doit tre un syntagme nominal datif "". Le trait INDEX exprime les caractristiques
de ce complment.
2.4. Les verbes

Le verbe est une entit exprimant un sens dpendant du temps. Cest un lment fondamental
auquel se rattachent directement ou indirectement les divers mots qui constituent la phrase.
34
Hla Fehri
La plupart des mots en arabe, drivent d'un verbe de trois lettres. Chaque verbe est donc la
racine d'une famille de mots. Comme en Franais, le mot en arabe se dduit de la racine en
rajoutant des suffixes ou des prfixes.
Figure 2.14. Types des verbes
Rappelons que les traits qui doivent tre contenus dans la SAV dun verbe sont
TRILITERE, MOJARAD, ASPECT, NAT, MAJ, VFORM, RADICAL, SCHEME, VOIX,
SUJ, COMPS, S_ARG, QUANTS et NUCLEUS. Le modle de la SAV utilise pour les
verbes est illustr dans la figure 2.15.
35
Hla Fehri
Figure 2.15. Modle dune SAV dun verbe
Les traits morphologiques sont toujours classs dans le trait TETE, ceux syntaxiques dans le
trait VALENCE et ceux smantiques dans le trait CONT. Dans ce qui suit, nous allons donner
un exemple dune SAV du verbe "".
Figure 2.16. SAV du verbe ""
Lexemple de la figure 2.16 montre que le verbe" "est conjugu laccompli en voix
active et ayant comme racine "" . Ce verbe sous catgorise un sujet 1 et un complment
dobjet direct 2. Ces valeurs se retrouvent dans le trait S-ARG dcrivant la structure
argumentale par ordre doblicit croissant. Ce dernier trait est en fait la concatnation des
36
Hla Fehri
traits de valence. Par ailleurs, nous remarquons que le sujet porte une spcification sur son
index : la catgorie nominale devra tre masculine et nominative.
Conclusion
Dans ce chapitre nous avons donn un aperu sur le formalisme HPSG qui a t choisi pour
tre projet vers la norme LMF. Nous avons propos par la suite un lexique syntaxique en
HPSG selon la spcificit de la langue arabe. En effet, nous avons adapt le formalisme
HPSG par lajout et la modification de quelques traits en tenant compte de la partie
flexionnelle qui est trs importante dans la plate-forme LMF. Le lexique propos comporte de
diffrentes catgories lexicales classifies selon [5]. Chaque catgorie comporte sa propre
SAV et sous catgorise un sous ensemble dont chacun est illustr par un exemple. Noublions
pas que nous avons propos deux modles de SAVs pour les particules de la langue arabe. La
classification des catgories lexicales admise dans notre travail est originale que ce soit par la
source adopte ou par les traits ajouts.
37
Chapitre 3
Lexical Markup
Framework (LMF)
38
Hla Fehri
Aprs avoir effectu une tude sur le formalisme HPSG arabis et dgag la SAV approprie
pour chaque catgorie lexicale, nous consacrons ce chapitre la prsentation de la plate-forme
LMF qui est concerne par la projection. Cela va nous permettre de comprendre les
spcificits de LMF et de dgager ultrieurement les points communs qui sont traits par les
deux concepts afin de pouvoir laborer une dmarche assurant la projection des lexiques
HPSG vers la future norme ISO 24613.
Dans le prsent chapitre, nous commenons tout dabord, par donner une prsentation
gnrale sur LMF. Ensuite, nous dcrivons son processus. Enfin, nous achevons par le dtail
des diffrentes extensions dont nous avons besoin dans notre travail travers des exemples.
1. Prsentation gnrale du LMF

LMF [24] est une initiative au sein de l'ISO en faveur de la normalisation de la reprsentation
des ressources lexicales. A partir des expriences acquises au cours des dix dernires annes
(Genelex [21], EAGLES, ISLE, Multext, TEI [39]), l'ide est de proposer un modle de
donnes modulaire, indpendant vis--vis d'une thorie lexicographique particulire et
permettant de s'abstraire de la reprsentation concrte (SGML/XML, DTD propritaire ou
TEI [34], base de donnes relationnelle, etc.). Le cadre de modlisation opre en effet au
niveau conceptuel : il vise inventorier les composantes essentielles d'un modle
lexicographique gnrique, dcrire les contraintes rgissant leur agencement ainsi qu'
inventorier les descripteurs qui leur sont associs. La future norme LMF de spcification de
dictionnaires destine au TAL se prsente sous la forme d'une partie noyau et d'un ensemble
de cinq extensions que nous allons dtailler dans ce qui suit.
1.1. Partie noyau

La partie noyau de LMF, modlise laide dun diagramme de classes UML par les auteurs,
spcifie les notions de lexique, de mot, de forme et de sens. En effet, elle dcrit dune part les
informations concernant le lexique et dautre part la hirarchie de base des informations qui
peuvent tre incluses dans une entre lexicale. Le modle noyau est illustr dans la figure 3.1.
39
Hla Fehri
Figure 3.1. Modle noyau
La figure 3.1 montre que le modle noyau contient neuf classes en relation. Ces classes sont
dcrites ci-dessous.
-
La classe Database : est un singleton qui reprsente la ressource entire. La base de

donnes est un rcipient pour un ou plus lexiques.
La classe Lexicon : est le rcipient pour toutes les entres lexicales d'une langue
source dans la base de donnes. Un lexique doit contenir au moins une entre lexicale
et n'autorise pas de sous-classes.
La classe Lexicon Information : contient des renseignements administratifs et

d'autres attributs dordre gnral tels que le numro de version, lauteur etc. Il y a un
rapport d'agrgation entre la classe Lexicon et la classe LexiconInformation puisque
cette dernire dcrit les renseignements administratifs totaux de chaque lexique.
LexiconInformation n'autorise pas de sous-classes.
40
Hla Fehri
La classe Lexical Entry : reprsente un mot, une expression compose, ou une

apposition dans une langue donne. LexicalEntry est un rcipient pour diriger les
classes Form et Sense. Par consquent, elle dirige le rapport entre les formes et leurs
sens apparents. Une entre lexicale peut avoir une ou plusieurs formes diffrentes, et
peut avoir zro ou plusieurs sens diffrents. La classe LexicalEntry n'autorise pas de
sous-classes.
La classe Entry Relation : est une classe de rfrence qui peut lier deux plusieurs
entres lexicales en LMF appartenant au mme lexique. Elle peut contenir des attributs
qui dcrivent la relation entre ces entres lexicales.
La classe Form : reprsente une variante lexicale de la forme crite ou parle de

l'entre lexicale. Elle contient une ficelle unicode qui reprsente la forme du mot et les
catgories de donnes qui dcrivent les attributs de la forme du mot. La classe Form
elle-mme peut contenir plus d'une variante orthographique (par exemple lemma,
prononciation, syllabification) et autorise des sous-classes. Ces sous-classes sont
illustres dans la figure 3.2.
Figure 3.2. Sous-classes de Form
Comme lindique la figure 3.2, Le modle noyau de LMF inclut deux sous-classes de
Form: LemmatisedForm et InflectedForm. La premire peut contenir seulement des
formes des mots qui sont du type lemme (
) alors que la deuxime peut contenir
seulement des formes des mots qui sont du type flchi (... ) .
-
La Classe Representation Frame : sil y a plus dune orthographe pour la forme du

mot (Note : par exemple, translittration, romanisation, prononciation), la classe Form
peut tre associe avec la classe RepresentationFrame. Cette dernire contient une
orthographe spcifique et une plusieurs catgories de donnes qui dcrivent les
attributs de cette orthographe.
41
Hla Fehri
La classe Sense : contient les attributs qui dcrivent le sens du mot. Cette classe peut
tre partage par plusieurs entres lexicales. Elle a une relation rflexive et elle est
compose par zro ou plusieurs relations smantiques.
La classe Sense Relation : est une classe de rfrence qui peut lier deux plusieurs
sens LMF pour une langue dans ou travers des lexiques. Elle peut aussi contenir des
attributs qui dcrivent le type de rapport smantique.
Le modle noyau LMF peut tre tendu pour satisfaire certaines exigences lies au
traitement de certains problmes linguistiques. En effet, les fondateurs de LMF ont fait
reposer le TALN sur cinq extensions : lextension morphologique, lextension syntaxique,
lextension smantique, lextension des modes de flexion et lextension des annotations
multilingues.
1.2. Extensions
Les extensions appliques au modle noyau de LMF traitent la morphologie, le paradigme de
flexion, la syntaxe, la smantique et des notations multilingues. Le mcanisme de l'extension
consiste :
-
crer des sous-classes bases sur les principes de UML,
additionner des nouvelles classes,
attribuer des contraintes sur les cardinalits, les types et les diffrents points d'ancre
pour les associations et
slectionner des catgories de donnes.
Toutes les extensions doivent dpendre du package noyau de LMF. En effet, une extension ne
peut pas tre utilise pour reprsenter les donnes lexicales indpendamment du package
noyau. Selon le genre de donnes linguistiques, une extension peut dpendre dune autre
extension. Du point de vue UML, une extension est un package UML. Le diagramme
reprsent dans la figure 3.3 dcrit les dpendances entre les diffrentes extensions.
42
Hla Fehri
Figure 3.3. Dpendance des extensions
Daprs la figure 3.3, nous distinguons trois cas de relation de dpendances pour les
extensions. Dans le premier cas, lextension dpend uniquement du package noyau ; tel est le
cas de lextension morphologique (NLP Morphology extension). Dans le deuxime cas,
lextension dpend dune autre extension existante qui importe elle-mme le package noyau
comme lextension du paradigme flexionnel (NLP Inflectional paradigm extension). Dans le
troisime cas, lextension dpend dune ou plusieurs extensions existantes et le package noyau
lui-mme telle lextension smantique (NLP Semantic extension).
En LMF, il faut distinguer entre la structure et la dcoration. En effet, la structure traite des
niveaux de description. Ainsi, le package LMF de la morphologie traite des descriptions
morphologiques. Le package LMF de la syntaxe traite des descriptions syntaxiques.
Cependant, la dcoration permet lassociation entre les packages LMF travers des traits vu
que tous les niveaux de description sont dpendants.
1.3. Catgories de donnes

Les catgories de donnes sont des descripteurs lmentaires permettant de dcorer un modle
structurel (i.e., /root/, /grammaticalGender/). Leur normalisation suit des principes dfinis
par la norme ISO 12620. Elles sont organises dans un registre de catgories de donnes
(DCR) accessible en ligne (http://syntax.inist.fr/).
43
Hla Fehri
Daprs la description de lISO 1179, il existe deux genres de catgorie de donnes (CD) :
complexes comme /grammatical gender/ et simple comme /masculine/. Une CD complexe
utilise un ensemble de CD simples comme des valeurs possibles. Tous les attributs de LMF
sont des catgories de donnes complexes. Chaque valeur dun attribut correspond une
catgorie de donnes simple ou une chane de caractres (string) Unicode. La figure 3.4
donne un exemple de reprsentation dune catgorie de donnes complexe selon la norme
LMF [33].
Figure 3.4. Reprsentation simplifie de la catgorie de donne /gender/
LMF utilise la notion de DCS (Data Category Selection) qui dcrit l'ensemble des
catgories de donnes qui peuvent tre utilises dans un lexique LMF donn. Il dcrit aussi les
contraintes sur la manire avec laquelle les catgories de donnes sont dresses dans les
classes spcifies.
Le DCR [33] est un ensemble de spcifications des catgories de donnes qui sont dfinies
par lISO 12620. Les crateurs de tout lexique LMF se basent sur le DCR lors de la cration
de leur propre DCS.
Les crateurs du lexique peuvent dfinir un ensemble de nouvelles catgories de donnes
pour couvrir des concepts qui en ont besoin et qui ne sont pas disponibles dans le DCR. Ces
catgories de donnes supplmentaires seront enregistres et diriges conformment avec
lISO 12620.
44
Hla Fehri
2. Processus LMF
Le processus LMF consiste dterminer les tapes essentielles pour la construction dun
lexique conforme LMF. En effet, un lexique conforme LMF est dfini par la combinaison
du package noyau LMF, de zro plusieurs extensions et dun ensemble de catgories de
donnes. De ce fait, le crateur du lexique peut dune part slectionner, part le package
noyau, les extensions qui sont appropries son travail. Dautre part, il peut dfinir de
nouvelles catgories de donnes qui doivent tre enregistres dans le DCR. Ainsi, il arrive
construire son propre DCS. La combinaison de tous ces lments est illustre dans le
diagramme dactivits UML reprsent dans la figure 3.5.
Figure 3.5. Processus LMF
Rappelons que les extensions doivent tre slectionnes selon le besoin du crateur du
lexique. Celles qui sont pertinentes pour notre travail, sont les extensions morphologique,
syntaxique et smantique que nous allons dtailler dans les sections suivantes.
45
Hla Fehri
3. Extension morphologique
Le but de cette extension est de fournir des mcanismes qui supportent le dveloppement des
lexiques NLP (Natural Language Processing) dcrivant la morphologie des entres lexicales.
Le diagramme de classes relatif cette extension est illustr dans la figure 3.6.
(Par convention, les classes de lextension courante sont prsentes avec un fond orange.)
Figure 3.6. Modle morphologique
Dans la figure 3.6, les classes de lextension morphologique sont Stem, ListOfComponents et
InflectionalParadigm. Stem reprsente la partie principale de la forme du mot. Ainsi, cette
classe tient une partie de LemmatisedForm qui peut avoir zro, un ou plusieurs Stem.
writtenForm, spokenForm et transliteration sont des exemples dattributs qui peuvent dcorer
la classe Stem. La classe ListOfComponents permet de ranger et dagrger les composants
autonomes ou non-autonomes entre lesquels une expression compose est comprise.
InflectionalParadigm est une classe qui spcifie comment associer un certain type
LemmatisedForm au sein de ses formes flchies. Id et example sont des exemples dattributs
qui peuvent dcorer la classe InflectionalParadigm.
Exemple 3.1 (Le mot Arabe " )":
Les diagrammes dobjets reprsents dans les figures 3.7 et 3.8 reprsentent deux manires
diffrentes de dcrire la partie flexionnelle du mot arabe "".
46
Hla Fehri
Figure 3.7. Diagramme dobjets reprsentant la partie flexionnelle de " "sans

paradigme flexionnel
Dans la figure 3.7, les deux formes flchies " "au singulier et " "au pluriel sont
reprsentes sans passer par un paradigme flexionnel. Dans ce cas, chaque forme flchie doit
tre dcrite dans un objet de type InflectedForm.
Figure 3.8. Diagramme dobjets reprsentant la partie flexionnelle de " "avec

paradigme flexionnel
Dans la figure 3.8, les deux formes flchies de " "doivent tre gnres automatiquement
par lintermdiaire du paradigme flexionnel portant le nom "as ". Ce paradigme doit tre
identifi dans un objet de type InflectionalParadigm et peut tre partag par dautres entres
lexicales dont la partie flexionnelle sobtiendra de la mme faon que "( "exemple :
")".
4. Extension syntaxique
Le but de lextension syntaxique est de dcrire les proprits du mot pour tre combin avec
les autres mots dans une phrase. Le modle syntaxique dcrit des proprits syntaxiques
spcifiques des mots et n'exprime pas la grammaire gnrale d'une langue.
47
Hla Fehri
Figure 3.9. Modle syntaxique
Dans la figure 3.9, les classes de lextension syntaxique sont SyntacticBehavior, Construction,
ConstructionSet, Self et SyntacticArgument. SyntacticBehavior est une classe qui reprsente
un des comportements possibles d'un ou plusieurs sens. La prsence d'un comportement
syntaxique pour un mot veut dire que ce mot peut avoir ce comportement dans la langue
donne. La description dtaille du comportement syntaxique est dfinie dans Construction.
Id et Label sont des exemples dattributs qui peuvent dcorer la classe SyntacticBehavior.
Ainsi, Construction est la classe qui dcrit une construction syntaxique. Cest une classe
qui est partage par tous les mots qui ont le mme comportement syntaxique dans la mme
langue. Une construction peut hriter des relations et des attributs d'une autre construction
plus gnrique par un lien rflchi. Donc il est possible d'intgrer une ontologie hirarchique
de constructions. id, label et comment sont des exemples dattributs qui peuvent dcorer la
classe Construction.
La classe Self dcrit le noeud central de Construction. Lorsqu'il est connect
Construction, il est partag par tous les mots qui ont le mme comportement syntaxique. Self
fait rfrence l'entre lexicale courante. Les attributs partOfSpeech, mood, voice et auxiliary
peuvent dcorer la classe Self.
48
Hla Fehri
La classe SyntacticArgument dcrit un actant syntaxique. SyntacticArgument peut tre lie

rcursivement Construction pour dcrire des discussions trs complexes. SyntacticArgument
autorise le rapport avec un actant smantique au moyen de SemanticArgument. Les attributs
function, syntacticConstitutent, introducer, label et restrivtion peuvent dcorer la classe
SyntacticArgument.
La classe ConstructionSet dcrit un ensemble de constructions syntaxiques et peut tre la
relation qui subit ces constructions. ConstructionSet peut hriter des relations et des attributs
d'une autre ConstructionSet plus gnrique par un lien rflchi. Donc, il est possible d'intgrer
une ontologie hirarchique de ConstructionSet. Les attributs Id, label, example et comment
peuvent dcorer la classe ConstructionSet.
Exemple 3.2 (le mot Arabe " )":
Le verbe " "sous-catgorise un sujet qui doit tre un syntagme nominal (SN) et un
complment dobjet qui doit tre aussi un syntagme nominal. Ce comportement syntaxique est
dcrit dans la figure 3.10 sachant quun verbe peut admettre plus dun comportement
syntaxique.
Figure 3.10. Diagramme dobjets reprsentant le comportement syntaxique du verbe ""
La figure 3.10 montre que chaque comportement syntaxique doit tre reprsent dans un objet
de type Construction. Ce dernier comporte tant dobjets de type SyntacticArgument que le
nombre de constituants du verbe "".
5. Extension smantique
Le but de lextension smantique est de dcrire un sens et ses relations avec dautres sens qui
appartiennent la mme langue. En raison des complexits de la syntaxe et de la smantique
dans la plupart des langues, la partie smantique comprend aussi le rapport avec la syntaxe.
Lextension smantique est dcrite par le diagramme de classes reprsent dans la figure 3.11.
49
Hla Fehri
Figure 3.11. Modle smantique

Dans la figure 3.11, les classes de lextension smantique sont : SenseExample,
SemanticDefinition,
Proposition,
SynsetRelation,
PredicativeRepresentation,
SemanicPrdicate, Semantic Argument et PredicateRelation.

La classe SenseExample dcrit des usages de la signification particulire de la classe Sense.
Un sens peut avoir de zro beaucoup d'exemples. La langue utilise est celle de l'entre
lexicale mais le texte pourrait tre plus ou moins exprim dans un chemin explicite. Les
attributs text, source et language peuvent dcorer la classe SenseExample.
La classe SemanticDefinition permet une description narrative de Sense ou de Synset. La
dfinition smantique n'est pas fournie pour un usage par les programmes. Elle est fournie
pour adoucir l'entretien par les tres humains et peut tre affiche au dernier utilisateur. Un
sens ou un synset peuvent avoir de zro beaucoup de dfinitions smantiques. La description
narrative peut tre exprime dans une autre langue que celle de l'entre lexicale. Les attributs
text, source, language et view peuvent dcorer Semantic Definition.
50
Hla Fehri
La classe Proposition assure le raffinement de SemanticDefinition. Facultativement, une

dfinition peut tre dfinie par plusieurs propositions. Les attributs label, text et type peuvent
dcorer Proposition.
La classe SemanticPredicate permet de dcrire une signification abstraite avec l'association
des SemanticArgument. Un attribut smantique peut tre utilis pour reprsenter la
signification commune entre des sens diffrents qui ne sont pas ncessairement des
synonymes. Ces sens peuvent tre lis des entres lexicales dont les parties du discours sont
diffrentes. Comme exemple dattributs dcorant la classe SemanticPredicate, nous pouvons
citer label et definition.
La classe PredicativeRepresentation dcrit le lien entre Sense et SemanticPredicate.
Comme attributs pouvant dcorer Predicative Representation, nous pouvons citer les deux
attributs type et comment.
La classe SemanticArgument est consacre au lien entre SemanticActant et SyntacticActant
qui est exprim au moyen de SyntacticArgument. SemanticRole et restriction sont des
exemples dattributs qui peuvent dcorer SemanticArgument.
La classe PredicateRelation permet de dcrire la relation entre deux ou plusieurs
SemanticPredicate. Comme attributs dcorant la classe PredicateRelation, nous pouvons citer
les deux attributs label et type.
La classe Synset permet de lier des synonymes. Elle dcrit une signification commune et
partage dans la mme langue. Synset peut lier plusieurs sens des entres lexicales diffrentes
avec la mme part of speech. Les attributs Label et source peuvent dcorer Synset.
La classe SynsetRelation permet de lier deux ou plusieurs Synset. Les attributs label et type
peuvent dcorer SynsetRelation.
Exemple 3.3 (le mot Arabe " )":
Dans lexemple dcrit ci-dessous, nous allons prsenter le diagramme dobjets illustrant le
rapport entre la partie syntaxique et celle smantique du verbe "". De ce fait, chaque
lment sous-catgoris par ce verbe est reprsent par une tiquette. Lassociation de ces
tiquettes donne une signification abstraite de " ".
51
Hla Fehri
Figure 3.12. Diagramme dobjets reprsentant le rapport entre la syntaxe et la smantique du

verbe ""
Dans la figure 3.12, le sujet est tiquet par X et le complment dobjet par Y. Si nous
supposons que X reprsente " "et Y " "alors lassociation de ces constituants avec
le verbe " "donne la signification de " " exprime dans lobjet
SemanticPredicate.
Conclusion
Dans ce chapitre, nous avons tudi les diffrents points qui caractrisent la plate-forme LMF.
En effet, nous avons commenc par prsenter la structure de la norme LMF. Ensuite, nous
avons expliqu le processus utilis par cette norme. Enfin, nous avons tudi essentiellement
les extensions dont nous avons besoin dans notre travail travers des exemples. Ainsi, cette
tude nous a permis de constater que la sous-catgorisation ainsi que dautres mcanismes qui
sont traits par le HPSG sont traits aussi par LMF. La diffrence rside essentiellement dans
la manire de reprsentation des entres lexicales. En effet, une forme canonique (ou drive)
avec toutes ses formes flchies constitue une seule entre lexicale en LMF. Cependant, en
HPSG, chaque forme, que ce soit drive, canonique ou flchie constitue une entre lexicale
52
Hla Fehri
part. Nous pouvons remarquer encore lexistence de plusieurs traits en HPSG et spcifiques
la langue arabe qui nont pas leur quivalent en LMF donc il faut les ajouter au DCS.
53
Chapitre 4
Chapitre 3 :
Dmarche propose
54
Hla Fehri
Ce chapitre est ddi la prsentation de la dmarche suivie pour la projection dun lexique
syntaxique HPSG vers une reprsentation LMF. Cette dmarche est labore en se basant sur
le mta modle de LMF et sur les extensions appliques ce modle, dune part, et sur la
notion dintgration des connaissances de HPSG, dautre part. La mthode que nous
proposons ncessite le passage par deux phases essentielles : lidentification dun systme de
rgles de projection et le processus de projection lui-mme.
Dans le prsent chapitre, nous commenons, tout dabord, par prsenter le systme de
rgles tabli. Les rgles sont introduites dune faon formelle. Ensuite, nous dtaillons
lalgorithme et les phases du processus de projection. Enfin, nous clturons le chapitre par
une conclusion.
1. Identification dun systme de rgles de projection

Ltude effectue sur les SAVs des diffrentes catgories lexicales arabes nous a permis de
dgager la nature et linformation que peut avoir chaque trait figurant dans une SAV. En effet,
lors de la projection, nous avons constat que chaque trait doit tre transform en un attribut
dune classe LMF. La dtection de la nature du trait (morphologique, syntaxique ou
smantique) nous aide identifier vers quel sous-modle LMF le trait doit tre projet vu que
le modle LMF englobe trois sous-modles : morphologique, syntaxique et smantique. Ainsi,
nous pouvons limiter le nombre de classes concernes par la projection. Quant linformation
que peut porter le trait, elle nous aide par la suite identifier la classe cible de la projection.
Prenons le cas du trait RADICAL ; ce trait garde la mme valeur pour la forme canonique (ou
drive) et toutes ses formes flchies. Nous pouvons dire donc que cest un trait qui concerne
la classe LexicalEntry. Par contre, si nous prenons le cas du trait SCHEME, nous remarquons
que ce trait change dune forme flchie une autre et dans ce cas, il concerne la classe
InflectedForm.
En effet, ltude effectue sur les traits des SAVs [28] nous renseigne sur la manire selon
laquelle la projection va tre faite en donnant une ide sur la correspondance des traits HPSG
en LMF. Cette tude est donc une phase prparatoire lidentification du systme de rgles de
projection. Ainsi, nous avons pu laborer un systme contenant 14 rgles de projection. Ce
systme a t publi dans [15], [16] et [17]. Notons quune rgle de projection est identifie
selon la nature des traits HPSG projeter dune part, et la correspondance en LMF dautre
part. Le nom du trait peut tre modifi sil nexiste pas son quivalent en LMF. Noublions
pas que la correspondance en LMF dpend, entre autres, de la forme de lentre lexicale
55
Hla Fehri
projeter. Dans le paragraphe suivant, nous commenons par prsenter les rgles identifies
pour les traits morphologiques.
1.1. Rgles identifies pour les traits morphologiques

Les rgles identifies pour les traits morphologiques sont divises en deux types : celles qui
peuvent tre appliques aux diffrentes catgories lexicales (nom et verbe, particule, nom non
flchi et verbe non flchi) et celles qui sont appliques des catgories mais non dautres
(nom ou verbe).
- Rgles pour les verbes :
Dans la langue arabe, la forme infinitive nexiste pas. Par dfaut, le verbe est conjugu la
troisime personne du singulier (, il) laccompli. Dans ce cas, il peut tre la fois une
forme canonique et flchie ou drive et flchie. Par consquent, lors de la projection, il faut
tenir compte de ce point et appliquer une rgle qui considre le verbe comme tant une forme
canonique ou drive dans la classe LemmatisedForm et comme tant une forme flchie dans
la classe InflectedForm. La rgle qui est note R1m est dfinie formellement en logique des
prdicats comme suit :
R1m : (Trait
HPSG
= PHON) (Valeur (SCHEME) FDC) in LemmatisedForm :
att = lemma et val = Valeur (PHON) in InflectedForm : att = orthography

val= Valeur (PHON)
Dans la rgle R1m, FDC dsigne lensemble de tous les schmes reprsentant les formes
canoniques et les formes drives relatives un verbe. FDC = {
}.Notons que la fonction Valeur
permet de retourner la valeur dun trait HPSG.
Exemple 1 :
Nous pouvons prendre le cas du verbe . Ce verbe a pour schme qui appartient
FDC. Par consquent, aprs avoir appliqu la rgle R1m, un nouvel attribut est ajout dans la
classe LemmatisedForm dont le nom est gal lemma et la valeur est gale et un
autre est ajout dans la classe InflectedForm dont le nom est gal orthography et sa valeur
est gale .
Si la valeur donne par le trait PHON reprsente une forme flchie, la projection doit tre
faite vers la partie du modle LMF destine la flexion et exactement vers la classe
56
Hla Fehri
InflectedForm et dans ce cas, nous appliquons la rgle R2m qui est dfinie formellement
comme suit :
R2m : (Trait
HPSG
= PHON) (Valeur (SCHEME) FDC) in InflectedForm :
att = orthography val = Valeur (PHON)

Exemple 2 :
Soit la forme flchie du verbe . Si le trait concern par la projection est le trait
PHON, alors nous devons tester la valeur du trait schme de cette forme. Etant donn que le
schme de est gal et nappartient pas FDC, nous utilisons alors
la rgle R2m. Ainsi, deux nouveaux attributs seront ajouts dans la classe InflectedForm ; le
premier est gal att et sa valeur est gale orthography. Quant au deuxime, son nom est
gal val et sa valeur est gale .
- Rgles pour les noms :
Pour les noms, nous pouvons distinguer une forme flchie dune forme canonique ou drive
partir des traits reprsentant le nombre (), le genre ( )et la diminution ().
En effet, pour quune forme dun nom soit drive ou canonique, il faut que ce nom soit
singulier, masculin et non diminutif () .
Exemple 3 :
Le nom ( enfant) est masculin, singulier et non diminutif, il reprsente alors une forme
canonique ou drive. Par contre, le nom
( deux enfants), reprsente une forme flchie
vue que le nombre est diffrent du singulier.
Nous introduisons maintenant la rgle R3m qui est applique aux formes canoniques ou
drives dun nom.
R3m : (Trait HPSG = PHON) (Valeur (NOMB) = ( )Valeur (GENR)= )
(Valeur (TASGUIR) = -) in LemmatisedForm : att = lemma val = Valeur (PHON)
in InflectedForm : att = orthography val= Valeur (PHON)

Ainsi, lapplication de cette rgle permet dajouter deux nouveaux attributs : le premier est
ajout dans la classe LemmatisedForm et ayant comme nom lemma et comme valeur celle du
trait HPSG PHON et le deuxime est ajout dans la classe InflectedForm en portant le nom
orthography et en conservant la valeur du trait HPSG.
Pour les formes flchies, nous proposons la rgle R4m dfinie comme suit :
57
R4m :
(Trait
HPSG
PHON)
Hla Fehri
(Valeur
(NOMBRE)
(Valeur (GENR) ( ) Valeur (TASGUIR) -)
in InflectedForm :
att = orthography val= Valeur (PHON)

La rgle R4m ajoute un seul attribut dans la classe InflectedForm. Cet attribut va avoir comme
nom orthography et comme valeur celle du trait HPSG. Passons maintenant identifier un
autre type de rgles.
- Rgles pour les noms et verbes :
Les traits qui prennent toujours les mmes valeurs pour la forme canonique (ou drive) et
toutes ses formes flchies, doivent tre projets vers la classe LexicalEntry. Parmi ces traits,
nous pouvons citer les traits MAJ, RADICAL, VFORM et NFORM. Ces traits doivent tre
projets une et une seule fois lors de la premire rencontre dans le lexique concern. Les
rgles R5m, R6m sont les rgles quil faut appliquer dans ce cas. Dans ce qui suit, nous
introduisons la rgle R5m.
R5m :
Trait
HPSG
attributLMF
attributLMF
traitHPSG
Variable (Valeur (TraitHPSG)) in LexicalEntry : att = attributLMF

val = Valeur (Trait HPSG)
Notons que la fonction Variable est une fonction qui permet de retourner si un trait garde la
mme valeur pour la forme canonique (ou drive) et toutes ses formes flchies ou non. La
figure 4.1 reprsente un exemple pour lapplication de la rgle R5m.
58
Hla Fehri
Remarquons que dans la figure 4.1, la valeur du trait MAJ reste inchangeable pour le verbe
et pour toutes ses formes flchies. Dans ce cas, nous devons appliquer la rgle R5m vu
que le trait MAJ a son quivalent en LMF qui est gal lattribut PartOfSpeech.
Quant la rgle R6m, elle est applique dans le cas o un trait nadmet pas un quivalent en
LMF. Cette rgle est dfinie formellement comme suit :
R6m : Trait
HPSG
attributLMF : attributLMF Variable (Valeur (Trait HPSG))
in LexicalEntry : att = Trait HPSG val = Valeur (Trait HPSG)

Les traits VFORM, NFORM et TRILITERE sont des traits qui nont pas dquivalents en LMF
et dans ce cas, nous devons appliquer la rgle R6m.
Les traits qui portent des valeurs spcifiques lentre lexicale en cours et qui peuvent
changer de valeur dune forme flchie une autre doivent tre projets vers la classe
InflectedForm selon la forme indique dans les rgles R7m et R8m. La figure 4.2 reprsente un
exemple qui illustre ce point.
Dans la figure 4.2, le trait SCHEME change de valeur chaque fois que nous passons dune
forme flchie une autre. Et puisque le trait SCHEME na pas dquivalent en LMF, nous
appliquons la rgle R7m.
R7m :
TraitHPSG
Variable (Valeur (TraitHPSG))
attributLMF
attributLMF
traitHPSG
in InflectedForm : att = nom(TraitHPSG)
val = Valeur (Trait HPSG)

Les traits TASGUIR et NASAB sont aussi des traits qui nont pas dquivalents en LMF et
dans ce cas, nous devons appliquer la rgle R7m.
59
Hla Fehri
Quant la rgle R8m, elle est applique dans le cas o un trait admet un quivalent en
LMF. Cette rgle est dfinie formellement comme suit :
R8m : Trait HPSG attributLMF : attributLMF traitHPSG : Variable (Valeur (TraitHPSG))
in InflectedForm : att = nom(attributLMF) val = Valeur (Trait HPSG)

Le trait ASPECT peut tre un exemple pour lapplication de la rgle R8m. En effet, ce trait
change de valeur dune forme une autre et il admet un quivalent en LMF qui est gal
GrammaticalMood. Passons maintenant identifier un autre type de rgles.
- Rgles pour les particules, noms non flchis et verbes non flchis :
Pour les particules ou les noms et les verbes non flchis (i.e., ), il nexiste pas de
formes flchies et par consquent, la classe InfectedForm ne figure pas lors de la projection.
Pour ce faire, nous appliquons les rgles R9m et R10m.
R9m :
Trait
HPSG
MAJ
Trait
HPSG
PHON
in
LexicalEntry :
att = GrammaticalCategory val = Valeur (MAJ)

Notons que la rgle R9m est applique uniquement pour les traits MAJ et PHON vue que ces
traits existent dans nimporte quel type de particules. La dfinition formelle de la rgle R10m
est la suivante :
R10m : Trait HPSG in LemmatisedForm : att = Trait HPSG val = Valeur (Trait HPSG)
La rgle R10m est applique pour tous les autres traits autres que MAJ et PHON qui peuvent
exister dans des catgories de particules mais non dautres. Dans le paragraphe suivant, nous
donnons des rgles concernant les traits syntaxiques.
1.2. Rgles identifies pour les traits syntaxiques

Les rgles identifies pour les traits syntaxiques sont considres comme tant des
paradigmes. En effet, plusieurs entres lexicales peuvent avoir le mme comportement
syntaxique et dans ce cas, elles partagent la mme rgle de projection par lintermdiaire de
son identifiant. Si la valeur du trait HPSG projeter peut avoir plus dune valeur la fois
(complexe), nous appliquons dans ce cas la rgle R1syn. Cette rgle est dfinie formellement
comme suit :
60
Hla Fehri
R1syn: complexe Valeur(Trait HPSG) in SyntacticArgument:

att = function val = fonction(trait HPSG)
att = SyntacticConstituent val = Valeur (Trait HPSG)
Parmi les traits auxquels nous appliquons la rgle R1syn, nous citons SPR, TOPIC, ATT et
COMPS. Notons que la rgle R1syn doit tre applique autant de fois quil y a de valeurs pour
le trait en question. Si le trait ne peut avoir quune seule valeur la fois, nous appliquons alors
ou bien la rgle R2syn ou bien R3syn.
R2syn : atomique (valeur (traitHPSG)) attributLMF : attributLMF traitHPSG in : Self
att = nom (attributLMF) val = valeur (traitHPSG)
La rgle R2syn est applique pour les traits HPSG qui ont un quivalent en LMF. Parmi ces
traits, nous pouvons citer le trait VOIX qui lors de la projection devient Grammatical Voice.
R3syn : atomique (valeur (traitHPSG)) attributLMF : attributLMF traitHPSG in : Self
att = nom (traitHPSG) val = valeur (traitHPSG)
Au contraire de la rgle R2syn, la rgle R3syn est applique pour les traits qui nont pas
dquivalent en LMF. Passons maintenant prsenter les rgles concernant les traits
smantiques.
1.3. Rgles identifies pour les traits smantiques

Les traits smantiques sont reprsents dans le trait CONT qui renferme une liste de
quantificateurs. La partie smantique qui nous intresse est reprsente par le trait NUCLEUS
qui a gnralement pour valeur une SAV compose par les traits et sil
sagit dun verbe sinon, il est vide. Jusqu maintenant, nous avons identifi quune seule
rgle de projection appliquer pour les traits smantiques illustre par R1sem.
R1sem : si Nucleus <> in SemanticArgument : att =
val = valeur ()
La mme rgle R1sem est applique pour le trait . Lattribut sera mis dans la classe
SemanticArgument.
Notons bien que la projection dune entre lexicale doit tre faite dans lemplacement
convenable du fichier LMF. En effet, ce fichier contient dj dautres entres lexicales qui ont
t projetes. Si nous prenons le cas de et , nous pouvons remarquer quen HPSG,
61
Hla Fehri
ces deux entres lexicales sont indpendantes lune de lautre par contre lors de la projection,
les deux reprsentent une seule entre lexicale dont est une forme canonique et sa
forme flchie.
1.4. Exemple illustratif

Soit la SAV du verbe ( sortir) illustre dans la figure 4.3. A partir de cette SAV, nous
allons expliquer lapplication de certaines rgles de projection.
Figure 4.3. SAV du verbe
La figure 4.3 indique que le verbe est un verbe totalement tens , conjugu
laccompli et en voix active . Ces informations sont donnes
respectivement par les traits VFORM, ASPECT et VOIX. Ce verbe sous-catgorise un sujet
masculin et un complment qui peut tre un syntagme nominal (SN) ou un
syntagme prpositionnel (SP). La SAV du verbe est stocke dans un lexique crit en
XML. Rappelons que cest la nature du trait et linformation porte par lui, qui nous aide
choisir la rgle de projection correspondante. Dans cet exemple, les traits morphologiques
sont MAJ, VFORM, RADICAL, SCHEME, ASPECT, TRILITERE et MOJARAD. Ainsi, la
projection du trait PHON se fait en utilisant la rgle R1m. En effet, Valeur (SCHEME) =
et FDC.
MAJ sera projet en utilisant la rgle R5m vu que ce trait a son quivalent en LMF et sa valeur
reste invariable quelque soit la forme de lentre . VFORM et RADICAL seront projets
en utilisant la rgle R6m vu que ces deux traits nadmettent pas dquivalent en LMF mais
62
Hla Fehri
leurs valeurs restent inchangeables quelque soit la forme de . SCHEME, TRILITERE et

MOJARAD seront projets en utilisant la rgle R8m vu que ces traits nadmettent pas
dquivalents en LMF et vu que leurs valeurs changent dune forme flchie de une
autre. Le trait ASPECT sera projet en utilisant la rgle R7m vu que ce trait admet un
quivalent en LMF et vu que sa valeur change dune forme flchie de une autre.
Les traits syntaxiques de cet exemple sont VOIX, SUJ, et COMPS. Ainsi, VOIX sera
projet en utilisant la rgle R2syn vu que ce trait admet son quivalent en LMF et vu que sa
valeur est simple.
Les traits SUJ et COMPS seront projets en utilisant la rgle R1syn car leurs valeurs sont
composes.
Lapplication des rgles de projection peut tre bien illustre dans la figure 4.4 qui
reprsente le diagramme dobjets du verbe . En effet, ce diagramme contient les
diffrents objets dans lesquels la projection a t effectue ainsi que les attributs reprsentant
les traits HPSG projets.
Figure 4.4. Diagramme dobjets de
63
Hla Fehri
Le diagramme dobjets dune entre lexicale peut nous donner une ide sur le fichier LMF
obtenu lors de la projection. Ce fichier est reprsent dans la figure 4.5 et respecte la DTD
donne dans [24] (Annexe A).
Figure 4.5. Fragment en format LMF relatif lentre lexicale
64
Hla Fehri
Le fichier reprsent dans la figure 4.5 dcrit une partie du fichier LMF relatif lentre
lexicale . De ce fragment, nous remarquons que chaque trait avec sa valeur est
reprsent par la balise <DC>.
Dans le reste de ce chapitre, nous utilisons Ec pour lentre lexicale en cours de projection,
Fp pour le fichier LMF contenant les entres lexicales projetes et Ep pour les entres lexicales
dj projetes.
2. Processus de projection
La phase de projection, qui a pour but dappliquer les rgles de projection correspondantes
pour chaque trait caractrisant une entre lexicale, ncessite le passage par trois tapes
essentielles. Ces trois tapes se rptent autant de fois quil y a dentres lexicales dans les
lexiques destins la projection. Ces tapes sont illustres dans la figure 4.6.
Figure 4.6. Etapes de la dmarche propose
Lentre pour notre processus est une base de lexiques qui peuvent reprsenter des verbes,
des noms, des particules ou une combinaison de ces catgories. La projection se fait en
commenant par le premier lexique ouvert. Les tapes de la dmarche, qui seront dtailles
65
Hla Fehri
dans les paragraphes suivants, consistent extraire pour chaque entre lexicale son fragment
en xml, identifier sa position de projection et le projeter en utilisant les rgles adquates.
2.1. Extraction dun fragment xml de la SAV du mot correspondant

La premire phase consiste extraire un fragment du fichier xml. Ce fragment reprsente la
SAV de lentre lexicale projeter partir du lexique correspondant. La phase de lextraction
dun fragment est essentielle car la projection va tre faite mot par mot et nous devons
chaque fois extraire les traits relatifs chaque entre. Notons que lextraction va tre
commence partir de la premire entre lexicale rencontre dans le lexique concern,
jusqu la dernire. La figure 4.7 illustre cette tape.
Figure 4.7. Extraction dun fragment xml dune entre lexicale

66
Hla Fehri
Lexemple pris dans la figure 4.7 est celui du verbe . La description des diffrents traits
caractrisant ce verbe a t ralise en se rfrant [23]. Lalgorithme permettant lextraction
dun fragment xml de lentre lexicale projeter est le suivant :
Algorithme : Extraction dun fragment xml
Entre : lexique L, fichier xml contenant les entres lexicales projeter
Ec, nom de lentre lexicale projeter
P, position de Ec dans L
Sortie : F, fichier xml dcrivant Ec ; une partie de L
Dbut
verif , variable locale boolenne
p1, variable locale indiquant la position dune entre lexicale dans L
lecture de L
pour chaque nud ni <bi, Ai, ti> L faire
verif 0
p1 p1 + 1
soit nj <bj, Aj, tj> L {nj est le nud fille de ni}
pour chaque nj de ni faire
tant que (verif = 0) faire
si ((aj = PHON) et (tj = Ec) et (p1 = p)) alors
verif 1
sinon
supprimer_noeud (ni)
fin si
fin tant que
fin pour
fin pour
enregistrer (F)
Fin
Notons que dans cet algorithme, un nud XML n est un triplet < b, A, t > o
b est le nom du nud (de la balise),
A est un ensemble de couples (a, v) o a est un attribut, v est la valeur de cet attribut et
t est le texte associ la balise
Un arbre XML T est dfini par un triplet < E, r,R > o
E est un ensemble de noeuds,
r E est la racine de larbre,
R est une relation non symtrique, non transitive et non rflexive.
2.2. Identification de la position de la projection

Lalgorithme de base de la projection utilise certains tests. Ces tests concernent la vrification
de la forme de lentre lexicale projeter dune part, et la position dans laquelle doit se faire
la projection dautre part. La figure 4.8 illustre la position de ces tests lors du processus de
projection.
67
Hla Fehri
Figure 4.8. Organigramme rcapitulatif
Comme lindique la figure 4.8, le processus consiste tout dabord vrifier si lentre lexicale
en cours de projection peut admettre des formes flchies ou non. Cette vrification est
essentielle car dans le cas o il peut exister des formes flchies, il faut savoir dans quelle
position la projection doit tre faite ; Noublions pas que dans LMF, une entre lexicale est
compose de la forme canonique ou drive et de toutes ses formes flchies alors que notre
point de dpart est un lexique contenant diffrentes entres lexicales qui peuvent tre des
formes canoniques, drives ou flchies reprsentes selon le formalisme HPSG et organises
dune manire arbitraire selon le choix du concepteur du lexique. Par consquent, le fichier
LMF rsultat va contenir un nombre dentres lexicales qui doit tre infrieure ou gal au
68
Hla Fehri
nombre dentres lexicales existantes dans le lexique HPSG. Notons que les traits qui nous
permettent de savoir si une entre lexicale admet des formes flchies ou non sont NFORM et
VFORM respectivement pour les noms et les verbes. Pour les particules, il nexiste pas des
formes flchies.
Ensuite, le processus passe la vrification de la position de la projection. En effet, si
lentre lexicale en cours de projection peut admettre des formes flchies, il faut parcourir
dans ce cas le fichier LMF contenant les entres lexicales projetes afin de savoir si une
entre lexicale de la mme classe a t projete. Cette recherche est base:
sur les valeurs des traits RADICAL, TRILITERE et MOJARAD dans le cas dun
verbe reprsentant une forme canonique ou une forme flchie dune forme canonique
sur les valeurs des traits RADICAL et SCHEME pour le reste des verbes et
sur les valeurs des traits NAT et RADICAL pour les noms.
Les diffrents cas discuts pour la recherche de la position de la projection sont dtaills dans
les points suivants.
- Cas des verbes canoniques
Dans le cas dun verbe ayant une forme canonique, la valeur des traits TRILITERE et
MOJARAD impliquent que le verbe est " " ou "" . Il suffit alors de trouver,
dans Fp, une entre lexicale Ep ayant la mme valeur des traits TRILITERE, MOJARAD et le
mme radical pour dire que Ep est de la mme classe que Ec ; prenons le cas des verbes ""
et " "qui appartiennent deux entres en HPSG : ces deux formes ayant comme valeurs
" " pour les traits TRILITERE et MOJARAD et " " pour le trait RADICAL ; donc
ces deux formes appartiennent une seule entre lexicale en LMF.
- Cas des verbes drivs
Dans le cas dun verbe ayant une forme drive, o la valeur de TRILITERE et MOJARAD
est diffrente de " " ou "" , il faut voir la valeur du trait SCHEME. En effet,
il peut exister deux formes drives ayant un trait RADICAL de mme valeur ainsi que des
traits TRILITERE et MOJARAD de mme valeur mais chacun reprsente, lors de la
projection, une entre lexicale indpendante de lautre. Les verbes " "et " "en sont
un exemple puisquils ont tous les deux pour valeurs " " et " " respectivement
pour les traits RADICAL, TRILITERE et MOJARAD mais chacune doit figurer dans une
entre lexicale indpendante de lautre.
69
Hla Fehri
Pour ce faire, nous avons stock tous les schmes reprsentant les formes drives avec
leurs formes flchies dans un fichier de telle faon que si deux entres lexicales appartiennent
la mme classe, il faut alors quelles aient la mme valeur du schme de la forme drive.
La figure 4.9 reprsente un extrait de ce fichier et la figure 4.10 donne quelques exemples
illustrant ce cas.
Figure 4.9. Extrait du fichier reprsentant les schmes des formes drives
Dans la figure 4.9, les exemples choisis reprsentent les schmes " "et "".
Remarquons que chacun de ces schmes est conjugu laccompli, linaccompli et
limpratif. Le fichier o est pris cet extrait nous aide savoir, dune part, quelle forme
drive les formes flchies appartiennent si un verbe ayant une forme drive est projete
avant sa (ou ses) forme(s) flchie(s) et, dautre part, quelles sont les formes flchies relatives
la forme drive si un (ou des) verbe(s) ayant une forme flchie est (sont) projet(s) avant sa
(leur) forme drive.
70
Hla Fehri
Figure 4.10. Exemple des verbes dune mme entre lexicale
Dans la figure 4.10, nous avons pris le cas des verbes " "et " "afin de montrer que
cest le schme de la forme drive de ces verbes qui va regrouper " "avec ses formes
flchies et de mme pour " "bien que ces deux verbes aient le mme radical.
- Cas des noms
Dans le cas dun nom, pour dire quil existe une Ep de la mme classe que Ec, il faut que Ep et
Ec aient la mme valeur des traits NAT te RADICAL. Nous pouvons prendre comme exemple
le cas des noms " "et " ;"ces deux noms ont les mmes valeurs " " et "
" respectivement pour les traits RADICAL et NAT. Nous pouvons dire alors que ces
deux noms appartiennent la mme entre lexicale. Par contre, si nous prenons le cas des
noms " "et "". Nous trouvons que le premier a pour valeur " " pour le trait
NAT alors que le deuxime a pour valeur "" .
Dans le cas de lexistence dune entre lexicale dj projete de la mme classe que
lentre lexicale en cours de projection, celle-ci doit tre faite dans la mme position que
lentre dj projete de telle faon que le nombre dentres lexicales en LMF reste le mme.
Reprenons lexemple 4 du verbe . Sil existe des formes flchies relatives lentre
lexicale qui ont dj t projetes, il faut les prendre en compte et dans ce cas, nous
devons connatre leur position de projection afin que soit projet dans la mme
position de faon que le nombre dentres lexicales projetes reste le mme.
La figure 4.11 peut illustrer ce point. Dans cette figure, nous supposons que les formes
flchies et ont dj t projetes et par consquent nous devons connatre leur
position de projection dans le fichier LMF.
71
Hla Fehri
1
2
3
4
5
6
7
8
10
11
12
Figure 4.11. Formes flchies de projetes dans LMF
Daprs lexemple donn dans la figure 4.11, les formes flchies de existent dans la
position 9. De ce fait, lentre lexicale doit tre projete dans la mme position. Nous
obtenons alors aprs avoir fait la projection, le fichier reprsent dans la figure 4.12.
72
Hla Fehri
Figure 4.12. Fichier LMF obtenu aprs lajout de
Ltape suivante est la projection dune autre entre lexicale qui vient juste aprs lentre
dans le lexique HPSG si elle existe.
2.3. Projection proprement dite

La phase Projection proprement dite consiste parcourir le fichier XML dj extrait dans la
phase prcdente afin dextraire les traits reprsentant lentre lexicale projeter. En se basant
73
Hla Fehri
sur ltude des diffrentes SAVs dj effectue dans ltape 1, nous pouvons connatre les
diffrents traits formant chaque catgorie lexicale et par consquent, nous pouvons appliquer
la rgle de projection correspondante. La figure 4.13 illustre cette tape.
Figure 4.13. Projection des traits de la SAV dun mot
Lexemple pris dans la figure 4.13 est celui du verbe "". A partir de cet exemple, nous
allons extraire chaque fois un trait et sa valeur et les projeter en utilisant la rgle de
projection adquate. Lalgorithme de lextraction dune valeur dun trait est le suivant :
Algorithme : Extraction de la valeur dun trait
Entre : nom_trait, nom du trait chercher
F, fragment en xml reprsentant lentre lexicale projeter
Sortie : val_trait, valeur de nom_trait
Dbut
verif 0
lecture de F
val_trait rechercher (E, nom_trait, val_trait, verif) //rechercher un trait dans F
Fin
74
Hla Fehri
La mthode rechercher() utilise par lalgorithme prcdent est une fonction rcursive
permettant de parcourir larborescence dun fichier xml, de rechercher un trait et de retourner
sa valeur. Lalgorithme de cette mthode est le suivant :
Algorithme : recherche dun trait et de sa valeur dans un fichier xml
Entre : E, liste des nuds dans un fichier xml
nom_trait, nom du trait chercher
val_trait, valeur du trait retourner
verif, trait trouv si verif = 1
Sortie : val_trait
Dbut
Pour chaque ni <bi, Ai, ti> E faire
Tant que (verif = 0) faire
Si (ai = nom_trait) alors
verif 1
val_trait vi
Fin si
Si (verif = 0) alors
pour chaque ni E faire
E nuds filles de ni
val_trait rechercher (E, nom_trait, val_trait, verif)
fin pour
fin pour
Fin
Dans cet algorithme, nous remarquons que la fonction rechercher() est une fonction rcursive
qui sarrte quand le trait cherch est trouv ; c'est--dire quand la variable locale verif a pour
valeur 1.
Conclusion
Dans ce chapitre, nous avons prsent et dtaill les tapes de la dmarche que nous avons
propose pour la projection de HPSG vers LMF. Ltude effectue sur les traits des SAVs
nous a permis dlaborer le systme des rgles de projection. Les rgles tablies sont
spcifies formellement laide de la logique des prdicats ce qui a facilit la tche de la
construction de lalgorithme de la projection.
La dmarche, que nous avons propose dans ce chapitre, est indpendante de lorganisation
du lexique HPSG projeter. En effet, lordre des entres lexicales dans ce dernier, na pas
dinfluence sur la projection. Nous pouvons trouver, par exemple, dans le lexique HPSG, une
forme canonique avant ses formes flchies ou linverse.
Lajout ou lenlvement dun (ou des) trait(s) HPSG ninflue pas sur le rsultat obtenu
lors de la projection vu que la premire tape qui consiste tudier les SAVs est capable de
75
Hla Fehri
rsoudre ce problme. De plus, notre systme de rgles de projection tabli traite tous les cas
possibles que nous pouvons rencontrer dans la langue arabe.
Si nous allons plus loin, et que nous pensons la projection dun autre lexique en HPSG
utilisant une autre langue, nous pouvons dire que notre dmarche reste toujours valable et que
la modification ne touche que les rgles de projection en ajoutant ou enlevant par exemple une
(des) rgle(s) lies des particularits de la langue concerne.
Le seul point qui peut avoir dinfluence sur notre dmarche et exactement sur ltape de
lidentification dun systme de rgles de projection est le fait de changer le modle LMF vue
que ce modle nest pas encore stable. Les changements concernent, dans ce cas, la
modification du nom de la classe laquelle la projection doit tre faite.
Ainsi, cette dmarche nous aide traiter la partie de la conception et celle de
limplmentation qui vont tre lobjet du chapitre suivant.
76
Chapitre 5
Chapitre 3 :
La ralisation
informatique
77
Hla Fehri
Aprs avoir dtaill la dmarche propose pour la projection du HPSG vers LMF dans le
chapitre prcdent, nous prsentons dans ce chapitre le prototype ralis afin de valider cette
dmarche. En effet, nous avons choisi le langage unifi UML pour la modlisation de ce
prototype et le langage de programmation objet JAVA pour limplmenter.
Dans ce chapitre, nous commenons par donner larchitecture gnrale du prototype. Par la
suite, nous passons la conception et la modlisation de ce dernier. Enfin, nous dcrivons la
ralisation tout en utilisant un exemple illustratif.
1. Architecture gnrale du prototype ralis

Le prototype ralis consiste projeter un ou plusieurs lexiques syntaxiques HPSG existants
vers LMF. Cela va nous permettre davoir une reprsentation standardise de ces lexiques et
par consquent favoriser leur fusionnement.
Notre prototype est compos de deux modules. Le premier consiste dans la phase de
projection. Ce module est ralis aprs avoir choisi et ouvert un ou plusieurs Lexiques HPSG.
Le deuxime consiste dans la gnration du ficher LMF rsultat de la projection. La figure 5.1
dcrit ces diffrents modules.
Figure 5.1. Architecture du prototype

78
Hla Fehri
Afin de lancer la projection, lutilisateur doit ouvrir au moins un lexique reprsent en

HPSG. Ensuite, le systme va parcourir chaque lexique ouvert entre par entre pour extraire
chaque fois le fragment xml relatif lentre correspondante. Pour chaque fragment xml
extrait, le systme effectue lextraction de chaque attribut et sa valeur et les projette en
utilisant la base des rgles de projection appropries. Nous prsentons dans ce qui suit, la
partie conception du prototype ainsi que sa modlisation avec le langage UML.
2. Conception du prototype
Avant dentamer la phase de limplmentation de notre prototype, il est ncessaire de le
concevoir afin de mieux comprendre son fonctionnement, matriser sa complexit et assurer
sa cohrence et sa maintenance. En effet, nous avons choisi dutiliser la mthodologie UML.
Ce choix est bas sur le fait quUML est un langage semi-formel normalis qui reprsente un
support de communication performant. UML comprend 9 diagrammes qui sont autant de
visions particulires du systme. Ils sont regroups suivant deux axes : un axe statique et un
axe dynamique. Dans ce qui suit, nous nous limitons au diagramme des cas dutilisation, au
diagramme de squences et au diagramme des classes de notre systme.
2.1. Diagramme des cas dutilisation

Afin de bien comprendre le comportement de notre systme et de pouvoir ainsi dfinir ses
limites, nous prsentons dans cette sous-section le diagramme des cas dutilisation. En effet,
ce dernier va nous permettre de prsenter, dune part, les fonctions fournies par le systme
partir des cas et dautre part, les diffrents acteurs ainsi que linteraction entre les deux.
Dans le diagramme des cas dutilisation relatif notre prototype, nous distinguons deux
acteurs : ladministrateur et lutilisateur. Ladministrateur peut mettre jour les lexiques
existants ainsi que les rpertoires de lexiques alors que lutilisateur peut consulter des
lexiques, lancer des projections, imprimer des rsultats de projection et mme utiliser ces
rsultats dans dautres applications. La figure 5.2 illustre linteraction de ces acteurs avec le
systme implmenter.
79
Hla Fehri
Figure 5.2. Diagramme des cas dutilisation du prototype ralis
Comme lindique la figure 5.2, le diagramme des cas dutilisation comporte trois cas
essentiels. Le premier Mise jour des lexiques existants consiste mettre jour les
lexiques existants. Cette opration est ralise par lajout des lexiques HPSG dans le
rpertoire convenable ou par la suppression des lexiques non rutiliss. Le deuxime cas
dutilisation ouverture dun ou plusieurs lexiques permet de lancer les lexiques destins
la projection. Louverture de ces lexiques inclut leur choix. Le troisime cas dutilisation
projection vers LMF ne peut tre ralis que lorsque le deuxime cas dutilisation est
dclench. Ce dernier cas inclut lutilisation dun systme de rgles de projection et la
gnration du fichier LMF rsultat de la projection. En outre, il peut tre tendu soit par la
visualisation ou par limpression du fichier obtenu. De ce diagramme de cas dutilisation,
80
Hla Fehri
nous pouvons tudier certains scnarios travers les diagrammes de squence. Nous nous
contentons dun seul scnario : Projection vers LMF.
2.2. Diagramme de squence du cas Projection vers LMF

Afin de bien prciser la ralisation du cas dutilisation reprsentant la projection vers LMF, et
de spcifier dune manire dtaille le dynamisme dun ensemble dobjets en mettant laccent
sur les relations temporelles, nous prsentons dans le figure 5.3 le diagramme de squence du
cas projection vers LMF.
Figure 5.3. Diagramme de squence du cas Projection vers LMF
Suite une demande douverture dun lexique HPSG par lutilisateur, le systme consulte le
lexique HPSG dsign afin de raliser cette demande et terminer par laffichage du lexique
concern. Aprs avoir ouvert un ou plusieurs lexiques HPSG, lutilisateur peut demander leur
projection vers LMF. Le systme lancera alors cette opration en utilisant les rgles de
81
Hla Fehri
projection ncessaires afin de crer le lexique LMF qui sera affich par la suite. Maintenant,
nous pouvons donner le diagramme de classes de notre systme.
2.3. Diagramme de classes

Rappelons que le diagramme de classes reprsente la structure statique en termes de classes et
de relations. La figure 5.4 dcrit le diagramme de classes pour notre systme. Nous
distinguons deux types de classes : des classes qui permettent dimplmenter linterface du
prototype et des classes qui permettent dimplmenter le processus de projection et la
structure interne dun lexique HPSG.
Figure 5.4. Diagramme de classes du prototype ralis

82
Hla Fehri
Le diagramme de classes de la figure 5.4 dcrit les classes avec leurs attributs et leurs
mthodes, ainsi que leurs visibilits et portes. Il dcrit aussi les diffrentes associations entre
les classes et les proprits et contraintes sur ces associations. Notons que la classe
Projection constitue la classe la plus importante de notre prototype. En effet, cette classe
contient toutes les mthodes permettant de raliser la projection des diffrentes catgories
lexicales en HPSG comme projeter_verbes(), projeter_noms() et projeter_particules(). Les
diffrentes caractristiques de ces diffrentes catgories lexicales font lobjet respectivement
des classes Lexique_verbes, Lexique_noms et Lexique_particules. La classe
Projection se rfre la classe Rgles de projection qui contient toutes les rgles de
projection dcrites dans la dmarche propose. Rappelons que ces rgles peuvent tre
morphologiques, syntaxiques ou smantiques. Le lexique HPSG projeter est compos dune
ou plusieurs SAVs. Une SAV est compose elle-mme des traits et des valeurs. La valeur
dun trait peut tre une valeur simple ou bien une valeur compose (liste ou SAV). Quant au
lexique LMF, rsultat de la projection, il est compos dun ensemble dlments. Chaque
lment peut tre compos dautres lments et/ou des catgories de donnes (DC). Chaque
catgorie de donnes est constitue dun attribut ayant une valeur.
3. Implmentation
Notre but consiste construire un outil dvelopp en JAVA sous lenvironnement Borland
JBuilder X permettant la projection dun lexique syntaxique en HPSG vers la plate-forme
LMF tout en suivant la dmarche propose dans le chapitre prcdent. Dans ce qui suit, nous
allons tout dabord, donner la reprsentation interne des lexiques syntaxiques HPSG. Ensuite,
nous allons dtailler limplmentation des mthodes pour chaque module de notre systme en
nous rfrant des pseudo-codes java.
3.1. Reprsentation interne des lexiques HPSG

Les lexiques utiliser par notre systme doivent avoir une reprsentation interne en XML
conforme au formalisme HPSG et respecter le standard de reprsentation des structures
attributs valeurs. Pour les lexiques qui ne sont pas conformes ce standard, nous appliquons
des heuristiques dajustement afin de les projeter ultrieurement. Lutilisateur doit choisir un
ou plusieurs lexiques. Le choix du lexique concern par la projection entranera louverture
83
Hla Fehri
de sa reprsentation XML. La figure 5.5 est un exemple qui dcrit lorganisation dun fichier
nomm Verbes.xml contenant uniquement des verbes.
Figure 5.5. Organisation du fichier Verbes.xml
84
Hla Fehri
Le fichier de la figure 5.5 dcrit les diffrents traits caractrisant un verbe selon le formalisme
HPSG et en se rfrant [23]. En effet, la balise <fs> indique quil sagit dune structure
attribut/valeur et la balise <f> indique quil sagit dun trait. La balise <f> est suivie toujours
de lattribut name qui est suivie son tour par le nom dun trait correspondant.
3.2. Module de projection

Le module de projection est compos de deux sous-modules. Un sous-module reprsente
lextraction du fragment XML de lentre correspondante et lautre lextraction et la
projection des traits et des valeurs dune entre lexicale. Dans ce qui suit, nous allons dtailler
ces deux sous-modules en nous basant sur un exemple illustratif.
3.2.1. Extraction dun fragment XML dune entre lexicale
Le sous-modle Extraction dun fragment XML dune entre lexicale permet lextraction
du fragment XML correspondant lentre qui va tre projete partir du fichier ouvert en
cours de projection. La mthode qui permet la ralisation de cette tche doit parcourir ce
fichier en vrifiant la syntaxe. Pour cela, nous avons utilis le constructeur de la classe
SAXBuilder, bas, comme son nom l'indique, sur l'API SAX [7]. Nous avons cr par la suite
une liste base sur les nuds reprsentant les SAVs de notre arborescence que nous avons
parcourue grce un iterator.
Lidentification du fragment projeter se base sur le trait PHON. A chaque fois que la
valeur de ce dernier nest pas quivalente celle de lentre en cours de projection, le nud
sera supprim. Cest pourquoi, nous avons besoin de deux boucles imbriques. La premire
boucle permet de parcourir tous les SAVs du lexique alors que la deuxime permet de
parcourir les traits de chaque SAV jusqu trouver le trait PHON. Pour ne pas modifier le
contenu du
fichier initial, nous construisons un autre fichier nomm fragment.xml
contenant uniquement lentre projeter.

La dfinition de la mthode extraire() correspondant la description ci-dessus est illustre
dans la figure 5.6. Cette mthode admet comme paramtres le nom de lentre lexicale qui va
tre projete (entree), le nom du fichier projeter (fichier) et lordre de entree dans fichier (n)
afin dviter tout conflit entre deux entres lexicales ayant la mme valeur du trait PHON.
85
Hla Fehri
static void extraire (String entree, String fichier, int n)

{ //n : indice de lentre dans fichier
int verif;int n1=0; Element c, courant;
List listfs, listf; Iterator i, j;
SAXBuilder sxb=new SAXBuilder();// cre une nouvelle instance de SAXBuilder
try
{// On cre un nouveau document JDOM avec en argument le fichier xml
document = sxb.build(new File(fichier)); // le parsing est termin
}
catch(Exception e ){}
// initialise llment racine avec la racine du document
racine = document.getRootElement() ;
// liste contenant tous les SAVs contenues du fichier HPSG projeter
listfs=racine.getChildren("fs");
i=listfs.iterator(); // cre un itrator sur la listfs
while (i.hasNext())
{verif = 0;n1++;
courant=(Element)i.next();
// cre une liste contenant tous les traits de la SAV courante
listf = courant.getChildren("f");
j = listf.iterator();
//Recherche du trait PHON correspondant lentre projeter
while (j.hasNext() && verif == 0)
{
c = (Element)j.next();
if (c.getAttributeValue("name").equals("PHON"))
if (c.getChild("string")!=null)
if (c.getChild("string").getTextTrim().equals(entree)&& n==n1)
verif=1; // trait PHON est trouv
else
// trait PHON est trouv mais sa valeur ne correspond pas lentre cherche et
//dans ce cas toute la SAV va tre supprime de telle faon quil ne restera dans fichier que la
//SAV de lentre projeter
{verif=1;
racine.removeChild(courant) ;
}
}
}
enregistre("fragment.xml"); //Enregistrement de la SAV de lentre cherche
}
Figure 5.6. Extraction du fragment XML dune entre lexicale
La mthode extraire (entree, fichier, n) prsente dans la figure 5.6 va tre applique pour
chaque lexique ouvert et pour chaque entre existant dans ce dernier. Lextraction du
fragment XML relatif une entre lexicale est faite afin dextraire les traits qui vont tre
projets : objet du sous-module suivant.
86
Hla Fehri
3.2.2. Identification de la position de la projection

Une fois que le fragment XML est extrait, nous devons identifier sa position de projection
afin de pouvoir appliquer la rgle de projection adquate dans la position correspondante.
Ainsi, la position de projection est donne par la mthode rechercher() sil sagit dune forme
drive ou dune forme flchie dune forme drive ou par la mthode rechercher_mojarad()
sil sagit dune forme canonique ou dune forme flchie dune forme canonique.
rechercher_mojarad() et rechercher() sont dfinies respectivement dans les figures 5.7 et 5.8.
static int rechercher_mojarad(String val_rad, String NBL)
{int b=0,i=0,j;String nbl="",r="";
LexicalEntry[] LE;
LE=Database.getLexicon(0).getLexicalEntry();// LE contient toutes les Ep
/*Pour chaque Ep on vrifie si la valeur de RADICAL et de NBL sont les mmes que EC ou
non*/
while((i<LE.length)&&(b==0))
{for(j=0;j<LE[i].getDCCount();j++)
{ if(LE[i].getDC(j).getAtt().equals("RADICAL"))
r=LE[i].getDC(j).getVal();
if(LE[i].getDC(j).getAtt().equals("NBL"))
nbl=LE[i].getDC(j).getVal();
}
if(r.equals(val_rad))
if(nbl.equals(NBL))
b=1;
i++;
}
if(b==1)// il existe Ep de la mme classe que Ec
return (i-1);// retourner lemplacement de Ep
else
return (-1);
}
Figure 5.7. Position de la projection dun verbe (forme canonique ou une forme flchie dune
forme canonique)
Comme lindique la mthode la figure 5.7, pour un verbe ayant une forme canonique ou une
forme flchie dune forme canonique, le fait de savoir sil y a dans le fichier XML une entre
lexicale dj projete Ep de la mme classe que celle en cours de projection Ec, se base sur le
fait que Ec et Ep ont la mme valeur du radical et le mme nombre de lettres (mmes valeurs
des traits TRILITERE et MOJARAD). Dans ce cas, la mthode rechercher_mojarad() retourne
la position de projection de Ec qui reprsente la position de Ep sinon elle va retourner -1. La
valeur -1 implique la cration dune nouvelle entre lexicale lors de la projection.
87
Hla Fehri
static int rechercher(String val_rad,String val_sch,String val_asp, String val_vo)

{int b=0,i=0,l,j,c;String asp="",sch="",f;
LexicalEntry[] LE;DC[] D;
LE=Database.getLexicon(0).getLexicalEntry();
while((i<LE.length)&&(b==0))
{j=0;c=0;
while((j<LE[i].getDCCount())&&(c==0))
{
if(LE[i].getDC(j).getAtt().equals("RADICAL"))
{c=1;
if(LE[i].getDC(j).getVal().equals(val_rad))
{
if(LE[i].getLemmatisedFormCount()!=0)
{ D=LE[i].getLemmatisedForm(0).getInflectedForm(0).getDC();
for(l=0;l<D.length;l++)
{ if(D[l].getAtt().equals("GrammaticalMood"))
asp=D[l].getVal();
else
if(D[l].getAtt().equals("SCHEME"))
sch=D[l].getVal();}
if((sch!="") &&(asp!=""))
{f=verif_forme(sch,asp,val_vo);
if ((f.equals(verif_forme(val_sch,val_asp,val_vo)))&&(f!=""))
{b=1;}}
}}}
else
j++;
}
i++;
}
if(b==1)
return (i-1);
else
return (-1);
}
Figure 5.8. Position de la projection dun verbe (forme drive ou une forme flchie dune
forme drive)
Dans le cas dun verbe ayant une forme drive ou une forme flchie dune forme drive, sil
existe dj une entre lexicale Ep de la mme classe que Ec (mme radical et mme schme de
la forme drive) dans le fichier LMF.xml, la mthode rechercher() de la figure 5.8 va
retourner la position dans laquelle Ec doit tre projete. Dans le cas inverse, cette mthode va
retourner -1.
La fonction rechercher() fait appel la fonction verif_forme() qui a pour rle de retourner la
valeur du schme de la forme drive de Ec et celui de la forme drive de chaque Ep ayant le
mme radical que Ec. La dfinition de verif_forme() est illustre dan la figure 5.9.
88
Hla Fehri
static String verif_forme(String val,String aspect,String val_vo)

{SCHEMES_VERBES SV=new SCHEMES_VERBES();String f="";int b=0;
Element courant, c, e; List l, listSV, l2; Iterator i, j, k;
if(val_vo.equals("\u0645\u0639\u0644\u0648\u0645"))
{SAXBuilder sxb1=new SAXBuilder();
try
{SV.document1 = sxb1.build(new File("Schemes.xml"));
}
catch(Exception e ){}}
else
{SAXBuilder sxb1=new SAXBuilder();
try
{SV.document1 = sxb1.build(new File("Schemes_p.xml"));
}
catch(Exception e ){}}
SV.racine1 = SV.document1.getRootElement() ;
listSV=SV.racine1.getChildren();
i=listSV.iterator();
while(i.hasNext()&&b==0)
{courant = (Element)i.next();
if (courant.getName().equals(val))
{f=val;b=1;}
else
if(courant.getChildren(aspect)!=null)
{
1=courant.getChildren(aspect);
j=l1.iterator();
while(j.hasNext())
{
c=(Element)j.next();
if(c.getChildren()!=null)
{
l2=c.getChildren();
k=l2.iterator();
while(k.hasNext()&&b==0)
{e=(Element)k.next();
if(e.getName().equals(val))
{f=courant.getName();b=1;}
} } }}}
return f;
}
Figure 5.9. Schme de la forme drive
La mthode verif_forme() dfinie dans la figure 5.9 fait un parcours du fichier Schemes.xml si
lente correspondante est la voix active et du fichier Schmes_p.xml sinon. Ces deux
fichiers contiennent tous les schmes de toutes les formes drives ainsi que leur conjugaison.
Le paramtre aspect est utilis afin de minimiser laccs au fichier correspondant. Cette
fonction reoit chaque fois la valeur du schme de Ec et de chaque Ep existante dans
LMF.xml et retourne la valeur du schme de leur forme drive. Lappel cette fonction par
89
Hla Fehri
la mthode rechercher() sarrte quand le rsultat fourni pour Ec et le mme que Ep. En effet,
dans ce cas, il sagit de deux entres qui ont la mme classe.
3.2.3. Projection proprement dite
Une fois que le fragment XML est extrait et la position de projection est identifie, nous
passons lextraction des valeurs des traits afin de les projeter. Pour les traits, nous pouvons
les connatre partir de la catgorie lexicale vu que nous sommes passs dans le chapitre
prcdent par une phase qui permet ltude des diffrentes SAVs des diffrentes catgories
lexicales. La mthode permettant lextraction des valeurs dun trait donn est dfinie dans la
figure 5.10.
static String []val(String att, String val)
{ int verif=0;
String[] res;
res=new String [100]; // res va contenir la valeur du trait cherch.
SAXBuilder sxb=new SAXBuilder();
try
{//Ouverture du frgment.xml
document = sxb.build(new File("fragment.xml"));
}
catch (Exception e1) {}
racine = document.getRootElement();
List L = racine.getChildren("fs");
//chercher un trait et retourner sa valeur
res=rechercher (L,att,val,verif,res);
return res;
}
Figure 5.10. Extraction de la valeur dun trait
La mthode val (att, val) va tre appele autant de fois quil y a des traits dans le fragment
extrait. Le paramtre att prend gnralement la valeur du name qui existe dans lorganisation
du fichier XML reprsentant le lexique. La syntaxe du trait est la suivante : f name = nom du
trait. Le deuxime paramtre reprsente le nom du trait.
Vu quil existe plusieurs lexiques qui peuvent reprsenter diffrentes catgories lexicales, et
vu que chaque catgorie lexicale peut avoir ses propres traits et ses propres rgles de
projection, le trait MAJ nous permet de savoir quelle mthode de projection appliquer. La
figure 5.11 illustre ce point.
90
Hla Fehri
static void projeter(String fichier)

{ int verif;String entre="";
Element courant, c ; List listf, l1 ;
Iterator i, j ;
Lexique L, LVF ;
L = new Lexique();
L.lireFichier(fichier); // lecture du fichier projeter
l1 = L.racine.getChildren("fs");// Crer une liste contenant toutes les SAVs projeter
i=l1.iterator() ;int n=0;
while(i.hasNext())
{ verif=0;n++;
courant=(Element)i.next();
listf = courant.getChildren("f");
j = listf.iterator();
// Recherche de la SAV projeter
while (j.hasNext()&& (verif==0))
{ c = (Element)j.next();
if (c.getAttributeValue("name").equals("PHON"))
if (c.getChild("string")!=null)
entre=c.getChild("string").getTextTrim();
verif=1;
}
L.extraire(entre,fichier,n) ;// extraction de la SAV projeter
//Le paramtre n est ajout afin dviter le conflit entre deux SAVs ayant le mme PHON
LVF=new Lexique();
LVF.lireFichier("fragment.xml");//Lecture du fichier contenant la SAV projeter
r = verbe.val("name","MAJ");// Extraction de la valeur du trait MAJ pour savoir quelle
//mthode de projection appeler (chaque catgorie lexicale a sa propre mthode de
//projection)
if(r[0].equals("verbe")) // r[0] vu que la valeur de MAJ est simple
projeter_verbes();
else
if(r[0].equals("nom"))
projeter_noms();
else
projeter_particules();
}
}
Figure 5.11. Choix de la mthode de projection
Le paramtre fichier de la mthode projeter reprsente le fragment XML de lentre

lexicale qui va tre projete. Le trait MAJ peut porter les valeurs verbe, nom ou
particule
et
lappel
des
mthodes
projeter_verbes(),
projeter_noms()
ou
projeter_particules() sera dtermin par cette valeur. La figure 5.12 est un exemple pour la
mthode projeter_verbes().
91
Hla Fehri
static void projeter_verbes()

{ vi=0;vle=0;
r1=verbe.val("name","RADICAL");
String val_rad=r1[0];
r1=verbe.val("name","SCHEME");
String val_sch=r1[0];
r1=verbe.val("name","ASPECT");
String val_asp=r1[0];
r1=verbe.val("name","NBL");
String val_nbl=r1[0];
r1=verbe.val("name","VOIX");
String val_vo=r1[0];
if(val_nbl.equals("||)" val_nbl.equals("))"
ind= rechercher_mojarad(val_rad,val_nbl);
else
ind= rechercher(val_rad,val_sch,val_asp,val_vo);
ind1=forme(val_sch,val_vo);
r1=verbe.val("name","PHON");
if(ind1==1)
RP.R1(ind);
else
RP.R2(ind);
RP.R4("GrammaticalMood",val_asp,ind);
RP.R4("SCHEME",val_sch,ind);
RP.R4("VOICE",val_vo,ind);
if(ind ==-1)
{ r1=verbe.val("name","MAJ");
RP.R3("partOfSpeech",r[0],ind);
RP.R3("RADICAL",val_rad,ind);
RP.R3("NBL",val_nbl,ind);
r1=verbe.val("name","VFORM");
RP.R3("VFORM",r[0],ind); }
r1=verbe.val("name","SUJ");
r2=verbe.val("name","COMPS");
int k;String val;String[] v_g;String v_v;String []v_nomb;
r=verbe.val("name","VOY");
v_v=r[0];
v_g=verbe.val("name","GENR");
v_nomb=verbe.val("name","NOMB");
for(k=0;k<r2.length;k++)
if(r2[k]!=null)
{ for(int j=0;j<v_g.length;j++)
if(v_g[j]!=null)
for(int l=0;l<v_nomb.length;l++)
if(v_nomb[l]!=null)
{val=verif_comp_synt("Subject","Object",r1[0],r2[k],v_g[j],v_v,v_nomb[l]);
if(val.equals(""))
RP.R8("Subject","Object",r1[0],r2[k],ind,v_g[j],v_v,v_nomb[l]);
else
RP.R5(val,ind);}
}
}
Figure 5.12. Projection dun verbe
92
Hla Fehri
Comme lindique la mthode de la figure 5.12, la projection dun verbe passe par lutilisation
des rgles de projection. Ces rgles sont appliques selon les traits qui peuvent exister dans
une catgorie lexicale. R1, R2, R3, R4, R5 et R8 sont les rgles appeler dans le cas dun
verbe. La figure 5.13 est un exemple pour une rgle de projection.
static void R1(int ind)
{ LexicalEntry LE;
r=LV.val("name","PHON");
DC DC1=crer_DC("Lemma",r[0]); // crer une catgorie de donnes
DC DC2=crer_DC("orthography",r[0]);
p.vi=1;
if(ind!=-1) // il existe Ep de la mme classe que Ec
{ LE=p.Lexicon.getLexicalEntry(ind);
set_LED(DC1,LE); //Attribuer une catgorie de donnes LemmatisedForm
// relative une entre lexicale (LE)
crer_IF(DC2,LE);// crer llment InflectedForm
}
else
if(p.vle==0)// cest le premier trait projeter pour Ec
{LE=crer_LE(); // crer une nouvelle entre lexicale
set_LED(DC1,LE);//crer LemmatisedForm
crer_IF(DC2,LE);//crer InflectedForm
p.vle=1; // indiquer quil y a un trait de Ec qui a t projet
}
else
{LE=p.Lexicon.getLexicalEntry(p.Lexicon.getLexicalEntryCount()-1);
set_LED(DC1,LE);
crer_IF(DC2,LE);
}
// enregistrement des modifications dans le fichier concern
try {
p.Database.marshal(p.filename," ","windows-1256");
}
catch (Exception exx) {
exx.printStackTrace();
}
}
Figure 5.13. Rgle de projection
Remarquons que la rgle R1 illustre dans la figure 5.13 ncessite un paramtre de type
entier. Ce paramtre reprsente la position de projection.
Comme cest dj indiqu dans le chapitre prcdent, la projection dune forme canonique
(ou drive) ncessite lappel de R1 par contre celle dune forme flchie ncessite lappel de
R2. Cest pourquoi, lors de la projection dune entre lexicale qui peut admettre des formes
flchies, comme dans le cas des verbes, nous devons connatre la forme de lentre Ec et cest
dj le rle de la fonction forme() appele par projeter_verbes() et dfinie dans la figure 5.14.
93
Hla Fehri
static int forme(String val_sch, String val_vo)

{SCHEMES_VERBES SV=new SCHEMES_VERBES() ;
int b=0;//forme flchie
if((val_sch.equals(" && )" val_vo.equals("(||))"val_sch.equals("&&)"
val_vo.equals(") ))"
b=1; // forme canonique
else
{ SAXBuilder sxb1=new SAXBuilder();
try
{SV.document1 = sxb1.build(new File("Schemes.xml"));
}
catch(Exception e ){}
SV.racine1 = SV.document1.getRootElement() ;
List listSV=SV.racine1.getChildren();//crer une liste contenant tous les schmes
// des formes drives
Iterator i=listSV.iterator();
while(i.hasNext()&&b==0)
{Element courant = (Element)i.next();
if (courant.getName().equals(val_sch))
b=1; //forme drive
}
}
return b;
}
Figure 5.14. Forme dune entre lexicale
La mthode forme() illustre dans la figure 5.14 permet de retourner 1 si Ec reprsente une
forme canonique ou mme drive et -1 sinon. Pour connatre les formes canoniques, il suffit
que Ec soit la voix active et ait pour valeur de schme " "ou "". Pour connatre
les formes drives, il faut faire un accs au fichier Schemes.xml qui contient tous les schmes
des formes drives ainsi que leurs conjugaison.
4. Interfaces ralises
Le prototype ralis contient une interface principale interactive, intuitive et conviviale
dveloppe dans lenvironnement JBuilderX. En effet, lexcution du programme provoquera
lapparition de cette interface qui est dcrite dans la figure 5.15.
Dans ce qui suit, nous allons dtailler le fonctionnement de notre systme via la description
des interfaces tablies.
94
Hla Fehri
Figure 5.15. Interface daccueil
Linterface principale, dcrite dans la figure 5.15, contient une barre de menus qui permet
laccs toutes les fonctionnalits de notre systme. Dans ce qui suit, nous allons dtailler le
rle de chaque menu.
Le menu Fichier permet louverture des fichiers XML que lutilisateur dsire projeter ou
mme consulter. Ainsi, lactivation de la commande Ouvrir de ce menu provoquera
lapparition dune boite de dialogue. Lutilisateur doit alors choisir le lexique dsir en
prcisant son chemin daccs.
Notons que le choix du lexique est suivi par laffichage de son contenu. La figure 5.16 en
est un exemple douverture du fichier Verbes.xml. Ce fichier a t conu lors de la
ralisation de ce travail. En outre, la description des verbes contenus dans ce fichier est
effectue en se rfrant [2].
95
Hla Fehri
Figure 5.16. Ouverture du fichier Verbes.xml
Nous pouvons remarquer partir de la figure 5.16 que le fichier ouvert dcrit tous les traits
qui peuvent exister dans une SAV respectant le formalisme HPSG.
Le menu Projection permet la projection de tous les fichiers XML ouverts quelle que
soient leurs structures cest--dire sils respectent le format standard de reprsentation des
SAVs [23] ou non. La figure 5.17 illustre lopration de la projection.
96
Hla Fehri
Figure 5.17. Projection du Verbes.xml
Le fichier affich dans la figure 5.17 correspond au fichier rsultat de la projection. Il reflte
lapplication des rgles relatives un verbe que nous avons dtailles dans le chapitre
prcdent. Ce fichier respecte aussi le DTD reprsent dans [24].
Le menu Ajout permet lajout des entres lexicales. La figure 5.18 reprsente un exemple
dajout du verbe .
97
Hla Fehri
Figure 5.18. Ajout dun verbe
Lajout dune entre lexicale implique celui de toutes les valeurs des traits qui identifient sa
catgorie. Cette opration est effectue juste pour pouvoir tester le prototype ralis.
Le menu Affichage permet laffichage des entres lexicales des fichiers construits. La
figure 5.19 est un exemple daffichage des verbes qui se trouvent dans le fichier
Verbes.xml.
Figure 5.19. Affichage des entres contenues dans Verbes.xml

98
Hla Fehri
Laffichage dun verbe implique celui de toutes les valeurs des traits caractrisant ce verbe.
Les boutons et de la figure 5.19 permettent dafficher respectivement le
verbe qui vient aprs le verbe dans le fichier Verbes.xml et le verbe qui vient juste
avant.
5. Evaluation
Dans le but dvaluer et de tester notre systme, nous avons projet dix lexiques HPSG qui
varient du point de vue structure et contenu. Ces critres de variation ont des influences sur
les rsultats obtenus. Le tableau reprsent dans la figure 5.20 illustre les diffrents rsultats
obtenus.
Nombre de lexiques HPSG
Structure du lexique
Contenu du lexique LMF
obtenu
obtenu
conforme LMF
aucune perte dinformations
conforme LMF
perte dinformations
non conforme LMF
perte dinformations
Figure 5.20. Tableau rcapitulatif des rsultats obtenus aprs la projection
Les rsultats obtenus dans le tableau de la figure 5.20 dpendent du contenu du lexique HPSG
projeter. Notons que le lexique obtenu suite la projection ne dpend pas de la structure du
lexique HPSG choisie (standard ou non).
Daprs le tableau de la figure 5.20, il y a trois types de lexiques qui donnent trois rsultats
diffrents. En effet, les lexiques HPSG qui contribuent avoir un lexique conforme LMF
sans aucune perte dinformations doivent, ou bien contenir les diffrents traits, que nous
avons ajouts dans le chapitre 2, afin de lier chaque forme canonique ou drive ses formes
flchies, ou bien se limiter contenir des formes canoniques et/ou drives sans aucune forme
flchie. Cest le cas des six premiers lexiques. Nous pouvons trouver dans ces lexiques HPSG
des entres lexicales de diffrentes catgories lexicales ou linverse.
Quant aux deux lexiques HPSG qui ont entran aprs leur projection des lexiques
conformes LMF mais avec perte dinformations, sont ceux qui possdent les mmes
caractristiques que le cas prcdent mais qui contiennent des traits non existants dans la base
de traits choisie. En effet, les catgories de donnes en HPSG ne sont pas standardises et
chaque utilisateur peut dfinir ses propres donnes afin de raliser son objectif. Par
99
Hla Fehri
consquent, le mme trait peut exister dans plusieurs lexiques HPSG sous diffrents formats
dcriture.
Les deux derniers lexiques HPSG dans le tableau de la figure 5.19, qui gnrent des
lexiques non conformes LMF avec perte dinformations, sont ceux qui contiennent des
formes flchies sans utiliser les traits que nous avons ajouts.
Ainsi, nous pouvons remarquer que pour obtenir un lexique conforme LMF sans aucune
perte dinformations, trois conditions ncessaires doivent tre satisfaites dans le lexique
HPSG source de la projection : La premire consiste ajouter les traits qui lient les formes
canoniques ou drives leurs formes flchies dans le cas o le lexique HPSG projeter
contient des formes flchies. La deuxime consiste ajouter tous les traits HPSG dans la base
des traits. La troisime consiste la voyellation de tous les schmes des verbes trilitres afin
dviter le conflit entre deux verbes qui scrivent de la mme faon (
et
) .
En outre, notre systme peut tre qualifi dextensible puisque dune part, nous avons opt
pour une conception simple assurant lautonomie des modules et dautre part, nous avons
implment un prototype de projection du HPSG vers LMF laide dun langage orient objet
favorisant lobtention des logiciels extensibles. Ainsi, nous pouvons tendre notre tche par
lajout des rgles de projection qui permettent de traiter des lexiques HPSG appartenant
dautres langues naturelles ou des lexiques pour les noms composs.
Par contre, la portabilit de ce prototype nest pas assure du fait quil est cens manipuler
la langue arabe et seuls les systmes dexploitation Windows qui supportent la langue arabe
peuvent rpondre nos exigences.
Notre prototype ralis permet dune part la rcupration et la fusion des lexiques HPSG
sans redondance des donnes. Dautre part, il permet le traitement de plusieurs variations,
entre autres, la variation orthographique. En effet, au niveau du lemme, pour deux formes
tymologiquement lies, prononciation identique et appartenant des paradigmes
flexionnels diffrents, notre systme contient deux entres lexicales distinctes, sans renvoi de
lune lautre ( et ) .
Notre systme permet encore la projection des entres lexicales catgorises en tant que
mots grammaticaux. En effet, nous trouvons dans la catgorie des noms les pronoms (i.e.,
personnels, dmonstratifs), les noms propres, les noms abstraits, etc. Dans la catgorie des
particules, nous trouvons les lettres de signification (i.e., conjonction, prposition) et les
lettres de construction. Pour les verbes, il y a les verbes flexionnels, les verbes structurs,.
Certes le prototype traite plusieurs niveaux linguistiques. Mais, il ne traite pas les formes
composes telles que le nom propre () .
100
Hla Fehri
Conclusion
Dans ce chapitre, nous avons commenc tout dabord par donner larchitecture gnrale du
prototype ralis afin de projeter un lexique syntaxique HPSG vers LMF. Ensuite, nous avons
prsent la conception de ce prototype base sur le langage UML. Puis, nous avons dtaill
limplmentation qui a t faite avec le langage de programmation orient objet JAVA sous
lenvironnement JbuilderX. Aprs, nous avons dcrit quelques interfaces ralises partir
dun exemple illustratif. Enfin, nous avons valu notre travail en nous basant sur la
projection de dix lexiques HPSG de diffrentes structures et de diffrents contenus ce qui
nous a permis de prouver la faisabilit de notre prototype et de discerner ses limites.
101
Conclusion gnrale
102
Hla Fehri
Dans le prsent travail, nous avons dvelopp un systme permettant la projection dun
lexique syntaxique HPSG vers la plate-forme LMF. Ainsi, ce systme nous permet de projeter
des entres lexicales de diffrentes catgories lexicales partir de nimporte quel lexique
HPSG. Cette projection va nous aider soit rcuprer des lexiques HPSG existants, soit les
fusionner et les intgrer avec dautres lexiques afin dobtenir des ressources plus riches et
plus larges.
Pour la ralisation du systme de projection, nous avons commenc, tout dabord, par
effectuer une tude sur ltat de lart de quelques travaux qui visent dune faon ou dautre
lchange des lexiques, des ressources et des rsultats fournis par des communauts
diffrentes.
Ensuite, nous avons prsent le formalisme HPSG arabis et ajout quelques traits qui sont
ncessaires la ralisation de la projection. Ces modifications se focalisent sur la partie
flexionnelle. Puis, nous avons tudi la plate-forme LMF afin de dgager les points communs
et les diffrences entre LMF et HPSG.
Ltude de HPSG dune part, et de la norme LMF dautre part nous a conduit proposer
une dmarche compose de deux tapes et qui utilise 14 rgles de projection susceptibles de
couvrir les diffrents traits qui caractrisent les entres lexicales relatives la langue arabe.
Lexprimentation de ce travail qui a t faite avec le langage orient objet JAVA et
conformment la mthodologie de conception UML, nous a permis dune part, de tester la
faisabilit du systme ralis et dautre part, de discerner les limites rencontres. Lvaluation
de notre prototype a t base sur la projection de dix lexiques HPSG qui diffrent du point de
vue structure et contenu ce qui nous a aids dgager les conditions ncessaires pour la
russite de la projection vers LMF.
Comme perspectives, nous voulons dfinir des critres permettant de vrifier formellement
la russite de la projection. Nous voulons aussi essayer dalimenter des applications conues
dans des grammaires dunification partir des bases de donnes lexicales en LMF. Ceci va
favoriser la rutilisation et lenrichissement des lexiques existants. Noublions pas enfin que
nous pouvons exploiter la projection des grammaires LTAG vers HPSG en profitant de la
phase qui permet la conversion des arbres lmentaires canoniques vers des entres lexicales
en HPSG. En effet, cette phase peut tre considre comme une phase intermdiaire pour le
passage vers LMF : de LTAG vers HPSG et de HPSG vers LMF.
103
Bibliographie
104
[1] Abdelkader A. (2006), Etude et analyse de la phrase nominale arabe en HPSG, mmoire
de mastre, SNIT, FSEGS, Sfax.
[2] Bescherelle (1999), Les verbes arabes, maison ddition France.

[3] Blache P. (1995), Une introduction HPSG, 2LC-CNRS.
[4] Chabchoub S. (2005), Etude et reprsentation des verbes arabes en HPSG en vue de
construire un conjugueur automatique, mmoire de mastre, SNIT, FSEGS, Sfax.
[5] Dahdh A. (1997), dictionnaire des rgles de la langue arabe dans des tableaux, maison
ddition Bayrout.
[6] Detmar M. (2002), Head-Driven Phrase Structure Grammar An Introduction as
Background for Grammar Implementation, OSU, LING795K, Spring 2002.
[7] CYNOBER N. Manipuler des donnes XML avec Java et JDOM.
[8] Doug A., LG521 Introduction to HPSG: Some Constructions.
[9] Eagles (1996), EAGLES Recommondations on subcategorisation, Eagles document
EAG-CLWG-SYNLEX.
[10] Eagles (1996), EAGLES Formalisms Working Group Final Report, version of
September 1996.
[11] Eagles (1993), EAGLES Lexicon architecture, EAGLES Document EAG-CLWGLEXARCH / B, version of Oct, 1993.
[12] Eagles (1996), Eagles Synopsis and Comparison of Morphosyntactic Phenomena
Encoded in Lexicons and Corpora. A common Proposal and Applications European
Languages, EAGLES Document EAG-CLWG-MORPHSYN / R, version of May, 1996.
[13] Elleuch S., (2004), Analyse syntaxique de la langue arabe sur le formalisme
dunification HPSG, mmoire de mastre, SNIT, FSEGS, Sfax.
[14] Equipe TAL (2004), Lexiques TAL, 27 dcembre 2004.
105
[15] Fehri H. et Haddar K. (2006), Elaboration dun systme de rgles en vue de projeter
HPSG en LMF, dans les actes de confrence des siximes journes scientifiques des jeunes
chercheurs en Gnie Electrique et en Informatique (GEI'2006), papier long, Hammamet,
Tunisie, 24-26 mars.
[16] Fehri H., Loukil N., Haddar K., Romary L. et Ben Hamadou A. (2006), Un systme de
projection du HPSG arabis vers la plate-forme LMF, dans les actes du colloque JETALA,
Institut dEtudes et de Recherches pour larabisation (IERA), Rabat du 05-07 juin.
[17] Fehri H. et Haddar K. (2007), Un prototype de projection HPSG en LMF, Actes de
confrence des septimes journes scientifiques des jeunes chercheurs en Gnie Electrique et
en Informatique (GEI'2007), Monastir, Tunisie, 26-28 mars.
[18] Francopoulo G. (2005), Bilan au sein de laction nationale de recherche et de
dveloppement SYNTAX, INRIA Loria.
[19] Francopoulo G. (2005), Lexical Markup Framework (LMF = ISO 24-613), INRIALoria.
[20] Francopoulo G. (2003), Proposition de norme des lexiques pour le traitement
automatique du langage, inria/loria-action syntaxe.
[21] Genelex (1994), Projet Eureka GENELEX, Rapport sur LE MULTILINGUISME,
version 2.0, France.
[22] Gomez C., Pinto M. (2001), La normalisation au service du traducteur, Meta, XLVI.
[23] ISO/TC37/SC 4 (2004), Language Resource Management Feature Sructures- Part 1 :
Feature Structure Representation.
[24] ISO/TC37/SC 4 N130 Rev.9 (2006) Language Resource Management Lexical
Markup Framework (LMF).
[25] Kasper R., Kiefer B., Netter K. ET K. Vijay-Shanker (1995), Compilation of HPSG to
TAG proceeding of the 33rd ACL, p 92-99.
[26] Kemps-Snijders M., Wittenburg P.(2005), LEXUS a flexible web based lexicon tool,
www.mpi.nl/lexus, lexus@mpi.nl.
106
[27] Khemakem A.(2006), ArabicLDB : une base lexicale normalise pour la langue arabe,
mmoire de mastre, SNIT, FSEGS, Sfax.
[28] Loukil N., (2006), Une proposition de reprsentation normalise des lexiques des
grammaires d'unification in Actes de TALN, Presse Universitaire de Louvain, 10 13 Avril
2006, Belgique.
[29] Maaloul H., (2005), la coordination dans la langue arabe : tude et analyse en HPSG,
mmoire de mastre, SNIT, FSEGS, Sfax.
[30] Pierrel J., Pole de recherche scientifique et technologique : Intelligence logicielle,
ATILF UMR 7118 CNRS Nancy 2 UHP, Nancy Cedex.
[31] Pollard C., Sag., I.A. (1994), Head-Driven Phrase Structure Grammar, publi par la
presse dans luniversit de Chicago, Edition Golgoldmittu, Chicago, LSLI.
[32] Pollard C. & I. Sag (1987), Information-Based Syntax and Semantics, Voume I:
Fundamentals. CSLI Lecture Notes N.13. Stanford., Center for the Study of Language and
Information.
[33] Romary L. Action nationale INRIA SYNTAX, dcembre 2003 dcembre 2003.
[34] Romary L. Mtadonnes et Normalisation des ressources linguistiques, Laboratoire
Loria-Inria, CNRS Direction de lInformation Scientifique.
[35] Romary L., (2004), Corpus et Normalisation, Laboratoire Loria - Inria.
[36] Romary L.., Un modle abstrait pour la reprsentation de terminologies multilingues
informatises : TMF Terminolological Markup Framework, Loria Campus Scientifique.
[37] Romary L.,
Van Campenhoudt M., Normalisation des changes de donnes en
terminologie : le cas des relations dites : conceptuelles.

[38] Romary L., Salmon S., Francopoulo G., Standards going concrete: from LMF to
Morphalou.
[39] Romary L., ISO and the TEI when standards speak to standards, Loria - Inria.
107
[40] Salmon S. (2004), Morphalou : Lexique morphologique ouvert du franais,

http://loreley.loria.fr/morphalou/doc/morphalou/desc.html.
[41] Yoshinaga N.et Miyao Y. (2002), Grammar conversion from LTAG to HPSG IN Proc.
of the sixth ESSLLI Student Session, p 309-324, University of Tokyo.
108
Annexe A: Le DTD
de la norme LMF
109
Projection des lexiques HPSG vers LMF
Hla Fehri
<?xml version='1.0' encoding="UTF-8"?>



<!ELEMENT Database (DC*, Lexicon+, SenseAxis*, TransferAxis*, ExampleAxis*)>
<!ATTLIST Database
dtdVersion CDATA #FIXED "1.0">
<!ELEMENT
Lexicon
(LexiconInformation,
LexicalEntry+,
InflectionalParadigm*,
MWEPattern*, Construction*, ConstructionSet*, SemanticPredicate*, Synset*)>

<!ELEMENT LexiconInformation (DC*)>
<!ELEMENT
LexicalEntry
(DC*,
LemmatisedForm+,
Sense*,
EntryRelation*,
SyntacticBehavior*)>
<!ATTLIST LexicalEntry
id ID #IMPLIED>
<!ELEMENT Sense (DC*, SenseRelation*, PredicativeRepresentation*, SenseExample*,
SemanticDefinition*)>
<!ATTLIST Sense
id ID #IMPLIED
inherit IDREFS #IMPLIED>
<!ELEMENT EntryRelation (DC*)>
<!ATTLIST EntryRelation
targets IDREFS #REQUIRED>
<!ELEMENT SenseRelation (DC*)>
<!ATTLIST SenseRelation

<!ELEMENT LemmatisedForm (DC*, ListOfComponents?, InflectedForm*, Stem*)>
<!ATTLIST LemmatisedForm
id ID #IMPLIED
paradigm IDREF #IMPLIED
pattern IDREF #IMPLIED>
110
Hla Fehri
<!ELEMENT ListOfComponents (DC*)>

<!ATTLIST ListOfComponents
<!ELEMENT InflectedForm (DC*)>
<!ELEMENT Stem (DC*)>

<!ELEMENT InflectionalParadigm (DC*, MorphologicalFeaturesCombo*)>
<!ATTLIST InflectionalParadigm
id ID #REQUIRED>
<!ELEMENT MorphologicalFeaturesCombo (DC*, Composer*, InflectedFormCalculator*,
MorphologicalFeature*)>
<!ELEMENT Composer (DC*, MorphologicalFeature*)>
<!ELEMENT InflectedFormCalculator (DC*, Operation*)>
<!ELEMENT Operation (DC*, OperationArgument*)>
<!ELEMENT OperationArgument (DC*)>
<!ELEMENT MorphologicalFeature EMPTY>
<!ATTLIST MorphologicalFeature
att CDATA #REQUIRED
val CDATA #REQUIRED>

<!ELEMENT MWEPattern (DC*, Combiner*)>
<!ELEMENT Combiner (DC*, CombinerArgument*)>
<!ELEMENT CombinerArgument (DC*, Combiner*)>

<!ELEMENT SyntacticBehavior (DC*)>
<!ATTLIST SyntacticBehavior
id ID #IMPLIED
senses IDREFS #IMPLIED
constructions IDREFS #IMPLIED
111
Hla Fehri
constructionsets IDREFS #IMPLIED>

<!ELEMENT Construction (DC*, Self?, SyntacticArgument*)>
<!ATTLIST Construction
id ID #IMPLIED
<!ELEMENT Self (DC*)>
<!ELEMENT SyntacticArgument (DC*)>
<!ATTLIST SyntacticArgument
target IDREF #IMPLIED
semargs IDREFS #IMPLIED>
<!ELEMENT ConstructionSet (DC*)>
<!ATTLIST ConstructionSet
id ID #IMPLIED
constructions IDREFS #IMPLIED

<!ELEMENT PredicativeRepresentation (DC*, SemanticPredicate*)>
<!ELEMENT SemanticPredicate (DC*, SemanticArgument*, PredicateRelation*)>
<!ATTLIST SemanticPredicate
id ID #REQUIRED>
<!ELEMENT SemanticArgument (DC*)>
<!ATTLIST SemanticArgument
id ID #REQUIRED>
<!ELEMENT PredicateRelation (DC*)>
<!ATTLIST PredicateRelation
targets IDREFS #IMPLIED>
<!ELEMENT SenseExample (DC*)>
<!ATTLIST SenseExample
id ID #IMPLIED>
112
Hla Fehri
<!ELEMENT SemanticDefinition (DC*, Proposition*)>

<!ELEMENT Proposition (DC*)>
<!ELEMENT Synset (DC*, SemanticDefinition*, SynsetRelation*)>
<!ATTLIST Synset
id ID #IMPLIED>
<!ELEMENT SynsetRelation (DC*)>
<!ATTLIST SynsetRelation
targets IDREFS #IMPLIED>

<!ELEMENT SenseAxis (DC*, SenseAxisRelation*)>
<!ATTLIST SenseAxis
id ID #IMPLIED
senses IDREFS #IMPLIED
synsets IDREFS #IMPLIED>
<!ELEMENT SenseAxisRelation (DC*)>
<!ATTLIST SenseAxisRelation
<!ELEMENT TransferAxis (DC*, TransferAxisRelation*,
SourceTest*, TargetTest*)>
<!ATTLIST TransferAxis
id ID #IMPLIED
synbehaviors IDREFS #IMPLIED>
<!ELEMENT TransferAxisRelation (DC*)>
<!ATTLIST TransferAxisRelation
<!ELEMENT SourceTest (DC*)>
<!ELEMENT TargetTest (DC*)>
<!ELEMENT ExampleAxis (DC*)>
<!ATTLIST ExampleAxis
113
Hla Fehri
examples IDREFS #IMPLIED>


<!ELEMENT DC EMPTY>


<!ATTLIST DC
att CDATA #REQUIRED
val CDATA #REQUIRED>
114
Hla Fehri
UN PROTOTYPE DE PROJECTION DU HPSG VERS LMF

Hla FEHRI
Rsum. Lvaluation des lexiques grammaires HPSG existants nest pas une tche facile car
elle ncessite une tude profonde de leurs couvertures linguistiques. Nanmoins, ces lexiques
nutilisent pas les mmes ressources linguistiques et ventuellement des catgories de
donnes diffrentes. Dans ce contexte, nous prsentons la dmarche et le prototype ralis
pour la projection du HPSG arabis vers un langage pivot normalis le LMF en se basant sur
un systme de rgles. Llaboration dun tel systme est base sur une tude effectue sur le
HPSG adapt pour la langue arabe. Cette tude nous a permis didentifier des structures
attributs valeurs pour chaque catgorie lexicale et leurs correspondances en LMF.
Mots cls. HPSG, LMF, projection, systme de rgles
Abstract. An evaluation of existent HPSG lexicon grammar is not an easy task because it
requires an underlying study of their linguistic coverage. Nevertheless, these lexicons dont
use the same linguistic resources and eventually different data categories. In this context, we
present a method and a prototype realized for the projection from Arabic HPSG to a
normalised pivot language, the LMF based on a system of rules. The elaboration of such a
system is based upon a study of the HPSG adapted to Arabic. This study permits us to identify
the attribute value structures for each lexical category and their correspondences in the LMF.
Key-words. HPSG, LMF, projection, system of rules.
HPSG :
. .
. LMF HPSG
.HPSG
.LMF
. LMF HPSG :
115

Master Dissertation He Lafe HR I

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Master Dissertation He Lafe HR I

Uploaded by

Copyright:

Available Formats

Cycle de Formation Doctorale

dans la Discipline Gnie lectrique

lcole Nationale dIngnieurs de Sfax

UN PROTOTYPE DE PROJECTION DU HPSG

Jai le grand plaisir de ddier ce travail :

ai lhonneur dexprimer mes vifs remerciements mon

confiance et qui ma encadr avec beaucoup de rigueur,

damabilit et de disponibilit dans la ralisation de ce travail, quil retrouve ici

Table des matires

1.1. Rgles identifies pour les traits morphologiques................................................... 56

Figure 1.3. Tableau de la conjugaison du verbe " "..

Figure 1.4. Arbre lmentaire canonique et arbres et arbres lmentaires non 14

Figure 1.6. Rgle de substitution 15

Figure 1.10. Schmas de domination .

Figure 1.11. Exemple dun arbre auxiliaire 19

Figure 2.1. SAV du nom livre .

Figure 2.2. Squelette gnral dun mot arabe 26

Figure 2.4. Modle dune SAV dun nom ...

Figure 2.5. SAV du nom ...

Figure 2.6. SAV du nom ...

Figure 2.7. SAV du nom ...

Figure 2.8. SAV du nom ... 31

Figure 2.10. Modle dune SAV dune prposition

Figure 2.11. Modle dune SAV dun outil

Figure 2.12. SAV de la particule

Figure 2.13. SAV de la particule

Figure 2.14. Type des verbes .

Figure 2.15. Modle dune SAV dun verbe ...

Figure 2.16. SAV du verbe 36

Un prototype de projection du HPSG vers LMF

Figure 3.1. Modle noyau ... 40

Figure 3.3. Dpendance des extensions .

Figure 3.4. Reprsentation simplifie de la catgorie de donnes /gender/ ..

Figure 3.5. Processus LMF

Figure 3.6. Modle morphologique

Figure 3.7. Diagramme dobjets reprsentant la partie flexionnelle de sans 47

Figure 3.10. Diagramme dobjets reprsentant le comportement syntaxique du verbe 49

Figure 3.12. Diagramme dobjets reprsentant le rapport entre la syntaxe et la 52

Figure 4.2. Exemple dapplication de la rgle R7m

Figure 4.3. SAV du verbe .. 62

Figure 4.8. Organigramme rcapitulatif

Figure 4.11. Formes flchies de projetes dans LMF ..

Figure 4.12. Fichier LMF obtenu aprs lajout de ..

Figure 4.13. Projection des traits de la SAV dun mot ... 74

Figure 5.2. Diagramme des cas dutilisation du prototype ralis .................................... 80

Figure 5.4. Diagramme de classes du prototype ralis

Un prototype de projection du HPSG vers LMF

Figure 5.5. Organisation du fichier Verbes.xml . 84

Figure 5.10. Extraction de la valeur dun trait ..

Figure 5.11. Choix de l mthode de projection .

Figure 5.12. Projection dun verbe.

Figure 5.13. Rgle de projection

Figure 5.14. Forme dune entre lexicale ..

Figure 5.15. Interface daccueil .

Figure 5.16. Ouverture du fichier Verbes.xml 96

Figure 5.19. Affichage des entres contenues dans Verbes.xml . 98

Un prototype de projection du HPSG vers LMF

description pour le traitement automatique du langage naturel [20] vu lexistence de plusieurs

Un prototype de projection du HPSG vers LMF

Un prototype de projection du HPSG vers LMF

1. Lexiques HPSG existants pour la langue arabe

Un prototype de projection du HPSG vers LMF

2.1. Pourquoi normaliser ?