Travaux et programmes antérieurs

Depuis les années 70, plusieurs « programmes étymologiques » ont vu le jour. Ces programmes se répartissent essentiellement en deux catégories(1) : (1) ceux basés sur des méthodes statistiques et/ou comparatives dont le but consiste à reconstruire les proto-formes d’une langue mère à partir d’un corpus de mots provenant de plusieurs langues sœurs, et (2) ceux utilisant des règles qui sont appliquées à des formes provenant d’une langue mère attestée afin de calculer leur évolution postérieure (forme/s moderne/s et stades intermédiaires). Vu que ces deux techniques sont directement liées à la direction du calcul sur l’axe temporel, on parle aussi de upstream calculation (type 1) ou downstream calculation (type 2) (2).

Les programmes du deuxième type – qui sont ceux qui nous intéressent à cet endroit – sont assez peu nombreux(3). Les voici dans l’ordre chronologique(4) :


Année

Auteur

Langue(s) concernée(s)

1971

Raoul N. Smith

(aucune indication)

1976

Sarah K. Burton-Hunter

latin classique => latin vulgaire => ancien français

1977

Charles L. Eastlack

latin vulgaire => espagnol médiéval

1980

Albert Maniet

proto-indo-européen => latin

1979/80

Mart Remmel

balto-finnois

1981

Bátori

ouralien

1982

Donald A. Becker

allemand

1996

Lee Hartmann

latin => espagnol


Nous pourrions aussi mentionner le projet intitulé The Reconstruction Engine dirigé par John Lowe et Martine Mazaudon qui combine les deux méthodes(5). Si malgré sa date récente nous ne nous intéressons guère à ce programme, c’est que son objectif principal réside dans la reconstruction de proto-formes. Nous ne parlerons pas non plus du programme FONOL, développé par Frank Brandon(6) à partir de 1983 qui est clairement orienté vers la grammaire générative malgré certains points communs qu’il peut présenter avec notre projet notamment en ce qui concerne le formalisme des règles.

Par la suite, nous allons traiter plus en détails les deux programmes qui touchent au domaine de l’espagnol, c’est-à-dire IBEROCHANGE de Charles Eastlack et PHONO de Lee Hartmann.

IBEROCHANGE

IBEROCHANGE de Charles Eastlack fait partie des programmes pionniers dans le domaine de la linguistique historique. Il dérive des mots de l’espagnol médiéval de l’époque du Cantar de Mio Cid (~1200 apr.J.-C.) à partir de formes provenant du latin vulgaire (~100 av.J.-C.). Pour le calcul, le programme se sert d’une base de 42 règles qui ont été directement intégrées au programme(7). Quoique l’accent soit surtout mis sur les changements « phonologiquement conditionnés » (phonologically conditionned changes), Eastlack a aussi essayé de formuler des règles qui tiennent compte de certaines conditions lexicales ou morphologiques(8).

Comme beaucoup de symboles phonétiques ne sont pas disponibles sur l’ordinateur, Eastlack a mis sur pied un système de notation où certains sons sont représentés par un seul caractère (par exemple P, T, K, B, D, G pour les consonnes occlusives) et d’autres par deux (C; et Z; par exemple représentent les affriquées palatales sourde et sonore). Les semi-voyelles yod et wau, ainsi que les variantes ouvertes de e et o sont exprimées par des chiffres (1, 2 et 3, 9). La longueur des voyelles ainsi que l’accent sont notés par : et . L’utilisateur doit également indiquer les frontières de mots (#) et de syllabe (en plaçant un espace entre les symboles)(9). Les mots fuerça, çiego et oy sont donc notés #F2’ER C;A#, #C;1’E GO# et #’01#.

Une fois que l’utilisateur a dûment introduit le mot à calculer, IBEROCHANGE applique les règles, les unes après les autres. Chaque fois qu’une règle transforme le mot, la nouvelle forme ainsi que le numéro de la règle responsable du changement sont affichés à l’écran, ce qui donne pour FECI et ALTERUM les évolutions suivantes :


		#FE: KI#
Rule7(a)	#F’E: KI#	
Rule7(h)	#F’E KI#	
Rule17	        #F’E CI#	
Rule22	        #F’E JI#	
Rule27(a)	#F’E Z;I#	
Rule40	        #F’I Z;I#		
Rule41(a)	#F’I Z;E#		
Rule42	        #F’I Z;#


                #AL TE RUM#
Rule 2(x)	#A2 TE RUM#
Rule 3	        #A2 TE RU#
Rule 7(a)	#’A2 TE RU#
Rule 7(f)	#’A2 TRU#
Rule 7(g)	#’A2 TRO#
Rule 30(ax)	#’O2 TRO#
Rule 39	        #’O TRO#
	

Comme on peut voir, le programme profite du fait que le latin a un accent mécanique pour ajouter automatiquement l’accent au mot (règle 7).

Eastlack insiste sur l’utilité de son programme dans le domaine scientifique en signalant, par exemple, que, déjà pendant son développement, il a pu faire de nouvelles découvertes notamment par rapport à l’ordre des règles(10). Si ces exploits ainsi que le programme en général méritent sans aucun doute notre plus grande admiration, il n’en reste pas moins vrai qu’IBEROCHANGE n’a pas toujours su choisir la solution idéale aux problèmes posés : ainsi, par exemple, la non-dissociation du programme, d’une part, et des règles linguistiques, d’autre part, a comme conséquence évidente qu’il est difficile et laborieux (voire impossible) d’utiliser le même programme pour plusieurs langues. Aussi, IBEROCHANGE traite-t-il les sons comme des unités phonématiques sans représentation interne, c’est-à-dire sans recourir à une analyse en traits distinctifs des phonèmes. Ce sont là des points que Hartmann essaiera d’améliorer beaucoup plus tard avec PHONO.

PHONO(11)

Lee Hartmann définit son programme lui-même comme « a DOS-based software tool for developping and testing models of regular historical sound change »(12). Afin d'illustrer son fonctionnement, l'auteur a pris soin de l'accompagner de deux « modèles » : IGPAY, un exemple très simple et plutôt ludique qui convertit des mots anglais en « Pig Latin »(13) et SPAN1, un ensemble de quelques 130 règles décrivant l'évolution du latin vers l'espagnol, qui montre les vraies capacités de cet outil.

Le calcul des étymologies repose donc sur un « modèle »  qui comprend trois éléments :


  1. Alphabet : Des 256 caractères théoriquement disponibles sur l'ordinateur, 70 peuvent être modifiés par l'utilisateur. Les caractères sont définis par une liste de traits distinctifs qui peuvent avoir des valeurs positives (+ et #) ou négatives ( et =)(14). Le nombre des traits est limité à 23. Voici, à titre d'exemple, la définition du modèle SPAN1 :

    
    SPAN1    aábßcçddeéÉføgGhiíjkl£mµnñnoóOpqrs$StTuúvwüxy¥zZ3:
    cons     ==++++++===+++++==+++++++++===++#+++++==+--+=#+++=
    syllabic ##------###----=##---------###--------##-==-=----=
    obstr    ==######===####===##==========##=#####==#--#=####=
    high     ==--#=-====--++-####=#--=#+===-+-=#---##-+++##=-#=
    low      ##-------=#-----------------=#-------------------=
    back     ##------===--##-==-#-----=##++-#------##-++#==--==
    round    ==------===-----==-=-------###-#------##-##-==---=
    coronal  --==####---=====--#=##==##=---=-+#####--=----####=
    anterior --##-#+#---##===----+-##+==---#-+#==##--#----=#===
    distrib  ++##+++++++=#+++++++++#=+++++++++#+=+-++=++++++=+=
    cont     ++=#===#+++++=##++=========+++==####=#++####+++##=
    delrel   ++-###-#+++##-#+++#-++++++++++--++++-++++++++++++=
    strident ---=##==---#------#--------------###==--#----=###=
    voice    ++##==##+++==##=++#=++++++++++==+=====++#++=+####=
    nasal    --------------------==#####----------------------=
    long     -------------------------------------------------#
    stress   =#------=##-----=#---------=##--------=#---------=
    
  2. Makeup : Le makeup (que l'on pourrait traduire par « arrangement ») contient les règles phonétiques. Chacune de celles-ci reçoit un nom univoque qui apparaît au début et à la fin de sa définition proprement dite, définition qui se compose de lignes « IF » (if-lines), marquées par une majuscule, et de lignes « THEN » (then-lines), marquées par un chiffre. Ces lignes peuvent, à leur tour, être de différents types : il existe quatre types de lignes « IF » (branching, COUNT, constant, variable) et cinq types de lignes « THEN » (constant, variable, DELETE, INSERT, SWAP), donc sept types différents en tout (puisque les types constant et variable apparaissent dans les deux catégories). Voici à nouveau, à titre d’exemple, la règle responsable de la diphtongaison de /o/ et /e/ ouverts (qui, en espagnol, aboutissent respectivement à // et //) :

    
    DIPHTHONG
    A :  B and C
    B :  +low(*)
    C :  back(*) = round(*)
    1 :  -low(*) +high(*) -syllabic(*) 
    2 :  INSERT e (*+1) 
    3 :  stress(*+1) = stress(*)
    4 :  -stress(*)             
    END DIPHTHONG
    
    Toute règle du type A ® B / C ¾ D (notation généralement admises par les linguistes) doit donc d'abord être traduite dans ce format spécial qui seul peut être compris par PHONO.
    Il est important de signaler que PHONO distingue entre des règles séquentielles (transient rules), qui ne peuvent être appliquées qu’une seule fois au cours du calcul, et des règles persistantes (persistent rules)(15), qui sont appliquées autant de fois que le mot remplit les conditions phonétiques nécessaires. Ces deux types de règles peuvent être définis dans l’order (voir ci-dessous).


  3. Order : Après la définition des règles, celles-ci doivent être mises dans un certain ordre. Cette tâche peut être accomplie de manière interactive et les informations qui en résultent sont sauvegardées dans un fichier séparé. L'utilisateur peut donc, à tout moment, changer l'ordre des règles indépendamment du makeup. Dans l’order les règles sont, outre cela, marquées comme transient ou persistent.


Une fois que toutes ces données sont disponibles, le calcul peut s'effectuer de différentes manières :


  1. Interactif : L'utilisateur peut entrer des mots à l'aide du clavier. Ces mots sont ensuite calculés et le résultat est affiché à l'écran.

  2. Singleton : Dans ce mode, les mots à calculer proviennent d'un fichier créé au préalable. PHONO lit les mots les uns après les autres et les calcule individuellement. Les évolutions sont sauvegardées dans le fichier SINGLE.OUT où elles peuvent être lues après le calcul.

  3. Pair : Comme dans le cas de singleton, les mots proviennent d'un fichier qui, cette fois-ci, contient aussi, pour chaque mot, le résultat attendu du calcul. PHONO compare donc le mot calculé à l'évolution correcte et les trie en fonction de cette comparaison (les « bonnes » et les « mauvaises » évolutions étant sauvegardées dans deux fichiers différents, respectivement GOOD.OUT et BAD.OUT).


Dans les modes singleton et pair, PHONO offre en outre la possibilité de créer un fichier où l’on trouve pour chaque règle les mots affectés par celle-ci pendant le calcul (Hartmann appelle cette fonction rule trace).

Dans les trois cas, une seule ligne de descendance (descendancy line) est calculée. Si on travaille dans le mode interactif, les évolutions sont présentées à peu près de la même façon que dans IBEROCHANGE (sauf que les règles, ici, ne sont pas numérotées, mais pourvues d’un nom comme nous l’avons signalé plus haut) :


ETYMON -->                  auricula
O-CEE_KAY:              =>  aurikula
O-LATIN_DIPHTHONGS:     =>  awrikula
O-STRESS_2:             =>  awríkula
  SYNCOPE_EXECUTION:    =>  awríkla
  VELAR_SPIRANT:        =>  awríxla
  HIGH_LOWERING:        =>  awréxla
  VELAR_YOD_EARLY:      =>  awréyla
  RESONANT_PALATAL:     =>  awréy£a
  GLIDE_ABSORPTION:     =>  awré£a
  LATERAL_AFFRICATION:  =>  awréja
  J_Y_MERGER:           =>  awré3a
  A_COLORING:           =>  owré3a
P-BACK_MONOPHTHONG:     =>  oré3a
  UNVOICE:              =>  oré$a
  PALATAL_VELARIZATION: =>  oréxa

Les règles précédées de « O » sont ce que Hartmann appelle « old orthographic rules » qui transcrivent l’input graphique dans une forme phonétique (outre la transformation de c en k et de u en w, cela inclut le placement d’un accent tonique). Il est important de signaler, à cet endroit, que ces transformations n’ont rien à voir avec le programme lui-même, mais uniquement avec le modèle (SPAN1 dans ce cas). C’est-à-dire que même si l’insertion de l’accent tonique ressemble, à première vue, à celui d’IBEROCHANGE, il existe une différence fondamentale entre eux : IBEROCHANGE place l’accent en appliquant une règle qui est intimement liée au programme, tandis que PHONO ne fait qu’exécuter des règles provenant d’un modèle (donc de l’extérieur, en quelque sorte). La même remarque est valable pour les deux points utilisés pour marquer la longueur des sons (« : ») : dans le cas d’IBEROCHANGE, le signe « : » est défini comme « longueur » à l’intérieur même du programme, tandis que dans le cas de PHONO, le signe « : » apparaît dans l’alphabet (voir plus haut) qui peut être librement défini par l’utilisateur. PHONO présente donc une dissociation absolue entre le programme et les règles, ce qui a pour conséquence qu’il peut, en principe, être utilisé pour n’importe quelle langue(16). L’évolution ci-dessus présente aussi une règle précédée par « P » : il s’agit d’une règle persistante qui, ici, n’est appliquée qu’une seule fois.

PHONO présente aussi des innovations dans le domaine phonologique : les « sons » ne sont plus considérés comme des « unités de surface » dont on ne connaît pas la structure interne, mais comme des unités phonologiques, représentées par les caractères de l’alphabet, dont chacune reçoit une définition sous forme d’une liste de traits distinctifs. Le mot à calculer est traduit dans une représentation interne (qui correspond à une suite de segments qui contiennent un certain nombre de traits), ce qui fait que les règles phonétiques ne se présentent plus comme une transformation de phonèmes (ou de caractères), mais comme une modification de traits distinctifs. Il est évident que, une fois que ce procédé a été choisi, il se pose le problème de la « retraduction » des sons, c’est-à-dire que le programme doit être capable de reconvertir les ensembles de traits distinctifs (contenus dans les segments) en caractères. Dans cette retraduction on peut distinguer deux cas possibles : (1) l’ensemble de traits correspond parfaitement à un caractère, et (2) l’ensemble de traits ne correspond que partiellement (il est possible qu’il y ait trop ou trop peu de traits). Tandis que le premier cas est trivial, le deuxième peut poser des problèmes. Supposons, par exemple, que nous ayons définis trois traits distinctifs, x, y et z, et deux phonèmes, A et B, qui se présentent de manière suivante :


     A := [ x, y ]   et   B := [ z, y ]


Si notre mot contient un segment constitué par [ x, z ], il est impossible de dire si le phonème est du type A ou B. La situation serait différente, cependant, si les traits n’avaient pas tous la même « valeur » à l’intérieur du système, c’est-à-dire s’il existait une hiérarchie entre eux. Dans ce cas, si, par exemple, x a plus de « valeur » que y et z, on pourrait considérer que [ x, z ] est une variante du phonème A. Si nous regardons encore une fois l’alphabet du modèle SPAN1, nous constatons que Hartmann a effectivement introduit une hiérarchie qui comprend deux plans :


valeur positive

valeur négative

plan supérieur

#

=

plan inférieur

+


Lors de la retraduction d’un segment, le programme compare d’abord les traits du plan supérieur, après quoi il compare les traits du plan inférieur et détermine, de cette façon, la meilleure correspondance. Si après ce processus, il reste des traits superflus, ils sont notés à droite de l’évolution, par exemple :


       ádtranS     +long/-ante-dist
           ^^

Ici, le signe ^ est utilisé pour désigner les segments ayant des traits superflus. S’il y en a plusieurs, les traits superflus sont séparés par /.

Il est incontestable que grâce à tous ces éléments mentionnés (dissociation entre programme et règles, distinction entre règles séquentielles et persistantes, représentation interne des phonèmes à l’aide d’une système de traits distinctifs, hiérarchisation des traits en deux plans) PHONO constitue un outil très puissant qui offre à peu près toutes les capacités dont un philologue peut avoir besoin. Néanmoins, il nous semble que le programme pourrait encore être amélioré dans certains points : ainsi, la limitation du calcul à une seule ligne évolutive nous paraît une entrave importante. De même, nous considérons que le système de traits distinctifs binaires pourrait être changé en un système de traits distinctifs multiples, ce qui permettrait peut-être aussi d’améliorer la hiérarchisation entre eux. Outre cela, PHONO est incapable de tenir compte de certains facteurs grammaticaux ou morphologiques qui peuvent avoir une influence sur le calcul. Finalement, il faudrait simplifier la notation des règles qui, assez insolite pour le linguiste ordinaire, peut poser des problèmes. Ce sont là les principales améliorations que nous nous proposerions d’apporter au programme ETYMO.


1 Voir Charles Eastlack, op. cit., 1977 ou John Lowe et Martine Mazaudon, op. cit., 1994.

2 Expressions empruntées à Hewson, op. cit., 1989.

3 Outre cela, il n’existe que très peu de bibliographie à ce sujet.

4 Hewson, op. cit., 1989, p. 577.

5 « The reconstruction engine is bi-directional : given words in modern languages, it can propose cognate sets (with reconstructions); given reconstructions, it can project the modern formes which would result from regular changes. », John Lowe et Martine Mazaudon, op. cit., 1994.

6 Voir Frank Brandon, op. cit., 1984.

7 « Each sound change rule is written as a separate program module », Eastlack, op. cit., 1977, p. 82.

8 Pour plus de détails, voir son article.

9 Ceci à la différence du programme de Sarah Burton-Hunter qui effectue la syllabation du mot de façon automatique. Eastlack justifie sa manière de procéder en signalant des irrégularités dans la syllabation de certains mots.

10 « In the writing of the Iberochange program it was discovered, for example, that the loss of high and high-mid vowels in posttonic syllables of words with three or more syllables [..] must have occurred long before the loss of high and high-mid vowels in pretonic syllables of words with four or more syllables ». Eastlack, op. cit., 1977, p. 84.

11 D'après nos informations lors de la rédaction de ce chapitre, la version la plus récente du programme était 3.3 (PHONO33.ZIP) qui avait été mise à disposition des utilisateurs sur internet en octobre 1996. Tous nos commentaires se réfèrent donc à cette version qui a été incluse sur le CD-ROM qui accompagne ce travail.

12 Tiré du fichier READ.ME livré avec le programme.

13 Pour plus de détails, voir le programme sur le CD-ROM.

14 Nous verrons pourquoi PHONO recourt à deux caractères différents pour chacune de ces valeurs.

15 Hartmann indique comme source de ces termes Wallace Chafe, International Journal of American Linguistics, no. 34, 1968, p. 131. Voir le fichier READ.ME qui accompagne le programme.

16 La seule condition est que la langue soit « représentable » par les éléments mis à disposition, ce qui veut dire essentiellement qu’il doit être possible de représenter les unités lexicales comme des segments phonétiques qui peuvent être définis comme des « ensembles de traits distinctifs binaires ».


Retour à la page principale << Chapitre précédent Chapitre suivant >>