Journal Chat80

Posté par (page perso) .
31
24
juin
2010
Chat80 est bien connu dans le monde de l'intelligence artificielle et le traitement automatique du langage naturel (TALN).
Ce logiciel a été écrit en Prolog entre 1978 et 1982 par Francisco Pereira et David H. Warren. Prolog en était alors à ses balbutiements, et encore assez peu considéré sérieusement par la communauté scientifique d'alors.

Chat80 possédait à l'époque une petite base de données prolog de géographie. On y trouvait quelques informations sur les pays frontaliers les un aux autres, leur population, leur capital, leur surface ou encore les fleuves qui y coulent.
Chat80 est ce que l'on appel un NLIDB : Natural Language Interface to DataBase. On peut donc lui poser quelques questions en anglais et voir s'afficher la réponse.

Un simple exemple est tout de suite parlant :
Which country bordering the Mediterranean borders a country that is bordered by a country whose population exceeds the population of India ?
Et de nous répondre : Turkey (eh oui à l'époque l'URSS était un grand pays...)

(Petite parenthèse pour dire que je viens de découvrir que le fameux Wolfram Alpha qui était soit disant révolutionnaire, est quand même capable de répondre ce genre de question : http://www.wolframalpha.com/input/?i=What+are+the+capitals+o(...) )

Comment est-ce possible ?
La réponse est résumable en quelques mots, mais difficile à comprendre profondément.
Chat80 analyse la structure grammaticale de la question, dans la plus pure perspective de la grammaire générative inventée par Noam Chomsky.
Il en produit une arbre grammatical, qui va être analysé pour être transformé en requête logique, qui est exécutée. A l'époque vu les performances limités des machines, un "planner" similaires à ceux que l'on trouve dans les SGBD a été ajouté afin d'améliorer les temps de réponse.

Prenons une phrase plus simple pour l'exemple :
What are the capitals of the countries bordering the Baltic ?

Etiquetons la grammaticalement :
What/Whq are/Verb the/det capitals/noun of/prep the/det countries/noun bordering/Verb the/det Baltic/Noun ?

Ce qui nous donne après analyse une structure grammaticale de la phrase.


C'est à partir de cette arbre que l'on construit la requêtes logique :
Le what initial dans la phrase, qui est un pronom, initie ce qui sera la variable
Le verbe être indique que l'on cherche un existence, donc une liste
Le COD (rappelez vous vos vieux cours de grammaire ... ;-) ) indique que l'on cherche les capitales

La Prepositional Phrase (le COI si vous préférez*) est une phrase entière The countries bordering the Baltic.
Là encore on a une structure SVO (Sujet Verbe Complément). Elle s'analyse simplement : border(X,baltic) **
Or comme cette phrase se trouve dans une Prepositional Phrase, X est une variable liée

Chat80, en mode trace, nous donne :

answer([$VAR(0)]) :-
$VAR(0) = setof ( [$VAR(1)]: $VAR(2) , country($VAR(1)) )
&
borders($VAR(1), baltic)
&
$VAR(2) = setof ( $VAR(3) capital($VAR(1), $VAR(3)) )



Le set of est une sorte de select/where


On pourrait l'écrire :

Select $country,$capital where
country($country)
and
borders($country,Baltic)
and
capital($country,$capital)




Quelques progrès on été réalisés depuis (compréhension d'une conversation et de l'implicite), ainsi que quelques tentatives commerciales.
Cette approche a plusieurs problème : l'anglais doit être grammaticalement correcte, et reconnue par le logiciel. Des ambigüités peuvent apparaître.
Si l'on se connecte à un SGBD relationnel, il faut pouvoir faire la liaison entre l'anglais pur et propre et des champs du genre Client_no ou Client_adresse.
Malgré cela, ce genre d'approche recèle une puissance inexploitée : imaginez le gain de temps que l'on peut faire sur des requêtes complexes, des algorithmes, etc...

Un mot sur le libre.
J'ai écrit à Pereira (impossible de trouver le mail de Warren) pour lui demander si 30 ans après cela ne le dérangeait pas de laisser son logiciel dans une licence libre (celle qu'il veut, c'est du détail).
Toujours pas de réponse au bout de 10 jours.

Il y a quelques ressources de ce genre dans le monde libre, mais ces approches sont surtout statistiques (ie. la machine apprend à reconnaitre des formes grammaticales), ce qui est très bien pour de l'analyse de texte, mais pas très adapté à des requêtes précises. Bref, rien de très exploitable en prolog dans le monde libre, à moins que je l'ai loupé...
A part ça, pas mal de choses en python (nltk, etc...).
Je vais me faire taper, mais même si je trouve python très bien, cela reste un langage impératif/objet classique. Je pense que c'est absolument pas adpté pour ce genre de problème.
Pour se donner une idée de ce qui me fait avancer cela : une implémentation un peu similaire à chat80, "Pytalk" qui fait à peine plus et pas mal de choses en moins a été faite en python.
Plus de 38 000 lignes de code.
Un parser à n'en plus finir (12 074 lignes de codes !!).

Chat80, c'est 5335 de prolog dont 1901 ligne pour les données brutes.

Cela montre l'efficacité impressionnante de ce langage pour ce genre de problème (on est bien d'accord que pour plein d'autres choses, c'est pas adapté).
Voilà, le troll est lancé, et si vous avez des liens..



* Les canons de la grammaire générative ne font pas d'analyse de la fonction grammaticale à la française, où l'on cherche les Sujet, COD, COI, Complément circonstanciel, propositions relatives, subordonnées, etc...
Ce que je trouve particulièrement dommage car cela simplifie énormément l'analyse en obtenant des arbre très profond.
La grammaire générative est basé sur l'idée de pouvoir utiliser une machine à état fini pour le parsing (comme les parsers de langage de programmation) et (c'est lié) de grammaire hors contexte.
je trouve ça un peu dommage, car ce genre d'analyse de fonction grammaticale apporte une très grande aide dans l'analyse de la logique de la phrase

** Intro ultra rapide à prolog pour ceux qui ne connaissent pas : Prolog est une sorte de SGBD orienté logique et ultra puissant. On y stocke des fait :

border(france,italy).
border(france,belgium).

Et on peut l'interroger :

border(france,X).
X = italy
X = belgium

On reconnait ici une forme verbe(sujet , complément)
  • # Coquille

    Posté par (page perso) . Évalué à 7.

    A la fin : "Ce que je trouve particulièrement dommage car cela simplifie énormément l'analyse en obtenant des arbre très profond."
    Lire : "des arbres peu profond".

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Coquille

      Posté par (page perso) . Évalué à 10.

      Les DLFPiens sont par nature des aigris, si tu corriges tes propres fautes d'orthographe sur un très bon journal comme celui-ci, il nous reste quoi pour gueuler ?!

      Et sinon, merci pour le journal, que j'ai pris plaisir à lire et qui m'a rappelé cette bonne vieille époque de l'école :p
    • [^] # Re: Coquille

      Posté par . Évalué à 8.

      > l’anglais doit être grammaticalement correcte
      Fail.
      • [^] # Re: Coquille

        Posté par . Évalué à 3.

        Je dirais même plus :
        l’anglais doit être grammaticalement correcte, et reconnue (la virgule devant le "et" est également en trop...)
        • [^] # Re: Coquille

          Posté par . Évalué à 2.

          ... et aussi :

          s/plusieurs problème/plusieurs problèmes/

          s/si 30 ans après cela ne le dérangeait pas/si 30 ans après, cela ne le dérangerait pas/

          s/reconnaitre/reconnaître/

          s/c'est absolument pas adpté/ce n'est absolument pas adapté/
    • [^] # Re: Coquille

      Posté par (page perso) . Évalué à 6.

      Lire "des arbres peu profonds".

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # RDF - technos du web sémantiques

    Posté par . Évalué à 7.

    Si tu veux partir sur ce genre de trucs, tu peux te pencher sur RDF par exemple.

    Les requêtes s'expriment dans des langages comme SPARQL, et sûrement plein d'autres
    PREFIX abc: <nul://sparql/exampleOntology#> .
    SELECT ?capital ?country
    WHERE {
    ?x abc:cityname ?capital ;
    abc:isCapitalOf ?y.
    ?y abc:countryname ?country ;
    abc:isInContinent abc:Africa.
    }


    pour la partie traitement des requêtes ...

    Ça donne l'avantage qu'il existe déja des ressources existantes et abondantes pour la bases de données, comme les trucs qui font de l'extraction de wikipedia (à partir des infobox notamment) ...

    http://en.wikipedia.org/wiki/Resource_Description_Framework
  • # Utilité

    Posté par . Évalué à 8.

    Ce que j'adore c'est que le genre de cas d'usage étudiés est typique de l'IA en général, à savoir : on ne résoud pas ce qui pourraît être utile, mais ce qui paraît possible à résoudre.

    En l'occurence, il est extrêmement rare de se poser ce genre de questions exactes mais tordues (façon trivial pursuit un peu sadique) : « Which country bordering the Mediterranean borders a country that is bordered by a country whose population exceeds the population of India ? »

    En général, les questions que se posent les gens, même dans des domaines plus ou moins scientifiques, sont plutôt du genre simples et pas exactes, donc pas solubles du tout par ce genre d'approche.

    (c'est aussi ce qui rend le RDF généralement inutile, cf. exemple dans un message plus haut)
    • [^] # Re: Utilité

      Posté par (page perso) . Évalué à 3.

      Récemment, j'ai codé une application en rail ou j'ai écrit des requêtes SQL bien plus complexe que cela.
      Je sais pas où tu travailles, mais j'y vois de nombreuses applications dans les projets que j'ai vu durant mon parcours professionnel : Dans de nombreux cas, il arrive que l'on ait des filtrage de données qui corresponde à des requête 2, 3, 4 fois imbriquées, avec des divisions relationnelles et autres joyeuseté.

      Je pense que ce n'est pas du tout à rejeter d'un revers de la main, il faut juste être un peu créatif et imaginer des applications.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Utilité

        Posté par . Évalué à 3.

        Récemment, j'ai codé une application en rail ou j'ai écrit des requêtes SQL bien plus complexe que cela.

        Cela ne change pas grand'chose. Ecrire des requêtes SQL (ou les clauses ORM correspondant à ces requêtes) n'est en général pas l'activité dominante d'un programmeur dans une application Web.
        Du reste, une requête SQL ne serait pas plus facilement écrite en Prolog.

        il faut juste être un peu créatif et imaginer des applications.

        C'est bien ce que je disais : il s'agit d'imaginer des questions que les gens ne se posent pas. C'est la grande faiblesse de ces visions purement logiciennes du langage naturel.

        Quand même, tu l'as dit toi-même : le logiciel a été écrit au début des années 80, et les techniques utilisées n'ont rien de très délicat à maîtriser. Si cela devait avoir des exploitations intéressantes, je pense que cela aurait déjà été fait.
    • [^] # Re: Utilité

      Posté par . Évalué à 5.

      D'un aute côté on parle d'une approche d'il y a 30 ans, c'est pas neuf.

      J'ai un peu l'impression qu'on a pas mal abandonné l'idée de faire des requêtes en langage naturel, par exemple. Ici le truc c'est que tu fais ta requête avec une grammaire super contrainte dans un langage qui ressemble a de l'anglais, mais qui au final est à peu prêt identique au SQL et au requêtes qu'on peut faire sur des bases rdf.

      Pour le requetage, même chose, quand la question est imprécise, on utilise plus des approches genre logiques floues, ou alors des approches de "guidage" de l'utilisateur avec des trucs tout faits pour construire l'utilisateur, ou des arbres de décisions ou des choses comme ça.


      Globalement l'IA a fait le chemin suivant, à mon avis : ils ont commencé par des approches "universelles" qui feraient toutes la chaîne de traitement, des interactions avec les humains jusqu'aux raisonnement, typiquement une approche comme celle du journal. Ensuite ils se sont rendus compte qu'il y avait du travail à tous les niveaux pour arriver à faire un truc pareil, et l'IA a éclaté en plein de sous disciplines qui visent à résoudre des sous problèmes du problème global (typiquement le traitement du langage pour l'analyse de requête), qui ont vécues leur vie plus ou moins indépendemment.

      Traitement du langage, représentation des connaissances, requêtes dans les connaissances avec la logique floue, moteurs d'inférences dans la continuité de Prolog, et pleins d'autres. C'est contrairement à ce que tu sembles dire une réponse plutôt pragmatique, et au moins nécessaire, dans l'objectif initial de l'IA tout au moins.

      Ces approches ont plus ou moins d'utilité en pratique suivant l'avancement des domaines, la difficulté des problèmes, ... mais l'enjeu, c'est à mon avis de réintégrer ensemble toutes ces techniques une fois qu'elles seront suffisament matures.

      Mais à mon avis si on cherche dans l'IA une méthode automagique qui marcherait immédiatement on se trompe : l'IA a la démarche d'essayer de résoudre une classe très large de problèmes, quand une approche ingénierie "classique" a plutôt pour but de résoudre efficacement un problème assez défini, ce qui est dans un premier temps largement plus simple et pragmatique ...
    • [^] # Re: Utilité

      Posté par . Évalué à 4.

      Tiens c'est marrant, je viens de tomber là dessus de manière complètement indépendante, et c'est pile dans le topic, donc je poste ici.

      En gros ça ressemble à la version moderne et 'achement plus balaise, à première vue ... j'ai pas encore regardé en détail, donc je peux pas en dire plus ...

      http://bienbienbien.net/2010/06/21/watson-lordinateur-le-plu(...)
    • [^] # Re: Utilité

      Posté par . Évalué à 5.

      Pas vraimment d'accord . Je viens juste de mettre en place un outil écrit en Prolog (la tronche de mes collègues :-) ) pour faire des vérifications dans le domaine des circuits intégrés.

      Typiqement, les "questions" sont du genre :

      Donne moi la liste des signaux, connectés à ce genre de "pin" (broche), qui ont les caractéristiques suivantes, etc


      C'est évidemment réalisable dans un langage autre que Prolog mais je pense que c'est impossible de battre un language logique comme Prolog pour la concision et la puissance des "requêtes"

      C'est sur que ca demande un peu d'effort intellectuel pour change de paradigme, mais une fois que l'on a franchi le pas, difficile de revenir en arrière.

      Concernant le RDF, je ne pense pas que ce soit si inutile que ca - C'est plus la question "on en fait quoi et comment" qui compte
      (en fait une description RDF c'est un équivalent d'un "fait" ("fact") en Prolog
      • [^] # Re: Utilité

        Posté par (page perso) . Évalué à 10.

        Exactement. Ya 2 ans, je devais débuger un logiciel dans le domaine ferrovière, en lui faisant travailler sur des morceaux de circuit, que je devais assembler tout seul.
        Problème, assembler les bouts à la main pour en faire des circuits, était titanesque.

        J'en parle à mon chef de projet qui me dit "ouais fait le en java, ça fait 500 lignes de code, c'est faisable, etc... on en a besoin".

        Je lui dit qu'en prolog ça ira beaucoup plus vite.
        Il me répond que c'est débile, j'irai beaucoup plus vite avec mes 500 lignes de java.
        je lui répond que prolog ça sera bcp plus court et rapide.
        Il refuse.

        Tête de cochon, je continue, je pose la question, parce que prolog c'est loin et j'ai du mal à formaliser mon problème : http://linuxfr.org/forums/31/24437.html

        Résultat, une demi heure de préparation des données.
        Et...
        2 lignes de code....

        Ca lui a un peu fermé sa gueule...

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: Utilité

          Posté par (page perso) . Évalué à 4.

          Eh, je me souviens de cette question prolog apparue sur le forum (il n'y en a pas tant que ça dans ce langage). Ravi d'avoir pu etre utile :-)

          Sinon, tout à fait d'accord quant à l'efficacité de ce type de langage pour des problemes de ce genre. Pour avoir un peu bossé dans le domaine de l'embarqué et de la verification de circuit, ça peut etre vraiment utile.
      • [^] # Re: Utilité

        Posté par . Évalué à 3.

        Pour la petite histoire, Stallman a écris un article de recherche intitulé
        Forward Reasoning and Dependency-Directed Backtracking in a System for Computer-Aided Circuit Analysis.
        Donc rien d'étonnant dans ce que tu dis :)

        Sinon, tu peux probablement exprimer ton problème dans un langage de programmation par contrainte, et le résoudre sans doute plus rapidement qu'en prolog "de base" ...
    • [^] # Re: Utilité

      Posté par (page perso) . Évalué à 2.

      Ton post m'a fait pas mal réfléchir depuis que je l'ai lu.

      Ca fait quelques années que je te lis, Antoine, et j'apprécie tes commentaires pertinents et tes compétences théoriques.

      Malgré tout, il y a un point sur lequel on ne sera jamais d'accord, c'est que tu as toujours tendance à dire "mais pourquoi tu veux inventer la machine à vapeur ? La charette à cheval, c'est très bien !"

      Que ton horizon indépassable soit Python ou Java, grand bien te fasse. Que tu penses que c'est ce qu'on utilisera encore dans 50 ans, c'est ton droit.

      Mais n'oublie pas que les trucs soit disant "inutiles" apporte souvent beaucoup de choses par ricochet.
      Je ne suis pas sûr que google translate tel quel existerait si des recherches comme chat80 n'avait pas été initiée.
      Bien sûr google translate produit plein de contresens et fait hurler (des fois de rire) ma copine traductrice/interprète.

      Mais ce genre d'approche a permis de défricher un terrain et d'arriver à des machineries semi symbolique, semi statistiques.

      De même, j'ai quelques idées sur les applications potentielles de ce genre de choses, j'en ai parlé.
      Ca n'a pas encore été fait, ou ca n'a pas marché parce qu'il était sans doute trop tôt.
      Lis http://www.dreamsongs.com/Files/AcceptanceModels.pdf pour t'en convaincre : Une idée génial, si elle arrive trop tôt, est une mauvaise idée.

      Je pense qu'on arrive à un stade ou le volume d'information, la complexité du logiciel, ainsi que du hardware qui devient multicoeur, nécessite que l'on recours à des outils issus de la recherche "inutile" en IA afin de faire fasse à la complexité.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # langage de programmation

    Posté par (page perso) . Évalué à 3.

    Ben dis donc, si tout le monde se met à transformer ses commentaires en journal ... ;-P

    Si je ne confonds pas, dans ton commentaire tu parlais d'un nouveau langage de programmation, c'est bien pour ce langage que tu bidouilles Chat80?
    Ton commentaire était assez elliptique, peux-tu développer? si je me réfère au commentaire que tu viens de mettre ci-dessous, il s'agit de faire des requêtes en langage naturel (en gros)?


    Question annexe: que deviendront Lisaac et LisaacOS alors?...

    PS: le commentaire dont il a tiré son journal http://linuxfr.org/comments/1137557,1.html
    et l'excellent journal (qui-fait-beaucoup-de-bien) à l'origine de son commentaire http://linuxfr.org/~marahi/29852.html (Lamentations ou les remords d'un geek)

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: langage de programmation

      Posté par (page perso) . Évalué à 4.

      Oui en effet, après 5 ans de réflexions et pas mal de journaux sur linuxfr ;-) j'ai une vision assez claire, maintenant, de ce que je veux faire.
      C'est une approche inédite, ou en tout cas je ne l'ai jamais vu nulle part.
      Et le mot d'ordre sera surtout : intuitivité. ie. le langage s'adapte à l'humain pas le contraire.
      Je vous en parlerai quand j'aurai au moins un début d'interpréteur qui fonctionne un minimum, ça peu prendre longtemps vu que je suis tout seul...

      Concernant Lisaac, c'est maintenant que je découple mon objectif de langage de prog haut niveau et l'évolution de Lisaac : La dernière spec qui commence à être implémentée (via la 4ème réécriture du compilateur basé sur un paradigme radicalement différent) pousse un tel langage quasiment au maximum de ce qu'il est possible de faire sans le rendre incohérent. Comme je veux aller plus loin, je dois faire mon langage de mon côté.
      Il est probable que j'utilise Lisaac comme un langage cible pour un hypothétique compilateur.

      Pour IsaacOS, je souhaiterai qu'on le libère afin que des motivés s'en occupent. Mais ça on verra à la prochaine réunion.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # Google aussi...

    Posté par . Évalué à 2.

    (Petite parenthèse pour dire que je viens de découvrir que le fameux Wolfram Alpha qui était soit disant révolutionnaire, est quand même capable de répondre ce genre de question : http://www.wolframalpha.com/input/?i=What+are+the+capitals+o(...) )

    SI tu tapes la même phrase dans Google [1], tu obtiens la page Wikipedia de la Turquie en première position. Tu crois qu'ils utilisent Chat80 ?

    [1] http://www.google.com/search?hl=en&source=hp&q=Which(...)
    • [^] # Re: Google aussi...

      Posté par . Évalué à 2.

      Je pense que c'est plutôt parce que cette question est un exemple récurent de questions posées à Chat80. Et que beaucoup de pages web associent cette question à cette réponse.

      Knowing the syntax of Java does not make someone a software engineer.

      • [^] # Re: Google aussi...

        Posté par (page perso) . Évalué à 2.

        La preuve ;-)

        J'ai un peu détourné la requête :
        http://www.google.com/search?hl=en&q=Which+country+borde(...)


        qui pose donc la question :
        Which country bordering the atlantic borders a country that is bordered by a country that is bordered by a country that is bordered by a country that is bordered by a country that is bordered by a country that is bordered by a country that is bordered by a country that is bordered by a country that is bordered by a country whose population exceeds the population of canada ?

        Là il s'emmelle les pinceaux, en sortant france et costa rica.
        Or, le costa rica ne peu pas être la bonne réponse :
        http://en.wikipedia.org/wiki/File:Costa_Rica_%28orthographic(...)

        Maintenant, essaye avec vietnam, japon, ou autres choses.

        Dommage.. Mais je suis sûr qu'ils auraient les ressources pour le faire chez google..

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # Ouaip

    Posté par (page perso) . Évalué à 3.

    >> Cela montre l'efficacité impressionnante de ce langage pour ce genre de problème (on est bien d'accord que pour plein d'autres choses, c'est pas adapté).

    Cela étant, c'est une chose TRÈS courante que de devoir faire ce genre de requêtes. Et plutôt que de les coder à la main, il peut être bien rentable de lier son programme à un interprète ou compilateur prolog qui se chargera de faire tout ce travail à la demande.

    Je pense au gestionnaires de paquets des distributions/os libres, des logiciels qui tagguent les images, etc…
  • # Mixer Python et Prolog....

    Posté par (page perso) . Évalué à 2.

    http://code.google.com/p/pyswip/

    http://openbookproject.net//py4fun/prolog/prolog3.html

    http://sourceforge.net/projects/pyprolog/

    Bon, faut voir où ils en sont, si c'est pas abandonné & Co...

    Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

  • # Analyse syntaxique électrostatique

    Posté par . Évalué à 1.

    Peut être que tu peux jeter un coup d'oeil au projet Leopar (et son confrère Leotok) pour la construction de la structure grammaticale de la phrase.

    Ce n'est pas du python, c'est OCaml qui est utilisé.

    J'ai beaucoup aimé le principe de polarisation (Analyse syntaxique électrostatique - http://www.loria.fr/~guillaum/publications/tal03.pdf).

    Ce n'est bien évidemment que la première étape. La transformation de cet arbre en requête logique me paraît un peu plus complexe.

    Le site du projet
    http://leopar.loria.fr/

    La forge du projet
    https://gforge.inria.fr/projects/leopar/
    • [^] # Re: Analyse syntaxique électrostatique

      Posté par (page perso) . Évalué à 2.

      Je suis moins chaud pour utiliser du caml que du prolog.
      Pour moi Python est hors de question, bien que cet avis est à relativiser avec le train intéressant lien de Laurent Pointal plus sur PySwp, on pourrait donc coupler nltk et prolog.

      Mais Caml vient après prolog dans ma liste de langage "acceptable" pour ce genre de travail.

      Ce qui m'étonne c'est que personne ne reprenne une analyse ou on cherche à retrouver les fonctions grammaticales comme on nous l'apprend à l'école : COD, COI, proposition relative, etc...

      Pour avoir fait quelques arbres à la main en utilisant cette méthode, je trouve que ça rend l'analyse logique de la phrase simplissime.

      Je garde précieusement ce bookmark que tu m'offres :-)

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.