R: Debugging computational grammars

Wed Apr 19 11:44:32 UTC 2000

Date: Tue, 18 Apr 2000 08:42:50 +0100
From: Christian Boitet <Christian.Boitet at imag.fr>
Message-Id: <v03102804b520d0c4f8e2@[129.88.32.65]>

Dear colleague,				18/4/2000

Sorry I left this unanswered for so long.

I Ariane-G5 (presented at the last ATALA WS on tools, some more on my web
site & in the literature), we have developed quite powerful tools to debug
our grammars, which are actually made of modules consisting of
transformation rules.

1) Only a modular organisation of the rule systems allows to do that
efficiently. In ROBRA, for instance, we have 3 levels: transformational
system, grammar, rule.

2) Provide for a variety of traces, at each of these levels, of course in
terms of the external specialized language (SLLP) used by the
linguist-developer.

3) If you develop really large applications, a specification level such as
that of Vauquois' "static grammars" (ref. in Vauquois Analects 1989 & in
Zarin's articles) is most crucial to create and maintain your computational
grammars in an orderly way.

As an anecdote, I was personnally able to debug a particular point of an
English-Thai prototype without knowing anything about the computational
grammars developed, or even about Thai.

I was with Pr. Udom Warutamasikkhadit who told me something was wrong in a
translation.  I ran the sentence in question, tracing the output trees
after AS (structural analysis), before GS (structural + syntactic
generation), & after it. Looking at the static grammars "boards" for Thai,
he told me the input to generation was OK, the output not.  I then went to
the ROBRA module & 3-4 rules indicated in the board as implementing the
construct in question, and easily detected that one rule schema did not
correspond to the board. I corrected it, reran, it worked. All this in less
than 15 minutes, and the computational grammars in question represented
(for analysis, transfer & generation) several hundred pages in source form
(including of course comments).

4) One originality in ROBRA (our language for writing tree transformational
systems) is that tracing and stepping are modular and graded:

- one may trace or not each main step of the automaton: prefiltering,
labelling (= finding all possible rule occurrences), choice (conflict
resolution and production of the set of rule occurrences to apply in
parallel to the tree -- which may represent several paragraphs and contain
thausend of nodes), and transformation proper.
- there are 4 levels of global and dynamic) tracing, 1-4, and each trace
point also has a (local and static) tracing grade. Whether the trace is
produced depends on whether, at a given point, the sum exceeds 4. In this
way, one can step and see more or less details.
- in the same spirit, any active tree (contained in the stack) can be
visualize in 4 or 5 geometric forms, with only the lexical units, or with
the complete decoration of each node. -- in a future implementation, we
should add a graphical, mouse sensitive interface, allowing to examine
individual nodes by clicking them.

This domain is still full of interesting possibilities.

Yours very sincerely,

Ch.Boitet

>Date: Thu, 23 Sep 1999 10:23:59 +0200 (MET DST)
>From: Alberto Lavelli <lavelli at itc.it>
>Message-Id: <199909230824.KAA16161 at ecate.itc.it>
>
>
>Dear colleagues,
>
>I'm looking for references to the problem of developing and debugging
>computational grammars for natural languages. I'm particularly
>interested in tools and approaches used in debugging grammars
>(particularly in their use when dealing with relatively large
>hand-written grammars).  In the computational systems I'm aware of,
>usually there is only a limited (and standard) set of debugging tools:
>tracers, steppers, chart browsers.
>
>Furthermore, does anybody know any extensive study on the most
>suitable strategies/tools to cope with the writing/testing/debugging
>cycle (always with a particular emphasis on debugging)?
>
>I know that there have been hints to this problem in related areas
>(e.g., the EU projects TSNLP and DiET, some papers at the ACL-EACL97
>workshop on Computational Environments for Grammar Development and
>Linguistic Engineering) but it seems to me that this topic has so far
>received little attention. But perhaps I'm missing some relevant
>contributions and so I'm asking for your help.
>
>Apart from references to relevant stuff, I'm also interested in your
>general opinion on the issue.  Is this (alleged) lack of interest an
>indication of the fact that such issue is in your opinion not
>particularly relevant?
>
>
>I'll post a summary if I receive enough responses
>
>
>best
>	alberto
>
>
>ps: I have sent this message to several mailing lists. I apologize if
>you receive it more than once.

-------------------------------------------------------------------------
Christian Boitet
(Pr. Universite' Joseph Fourier)         Tel: +33.4-7651-4355/4817
GETA, CLIPS, IMAG-campus, BP53           Fax: +33.4-7651-4405
385, rue de la Bibliothe`que             Mel: Christian.Boitet at imag.fr
38041 Grenoble Cedex 9, France           Mobile:  +33-(0)6-6005-1969
http://www-clips.imag.fr/geta/christian.boitet
-------------------------------------------------------------------------
Projet C-STAR (http://www.c-star.org/) et projet européen
	Nespole (http://nespole.itc.it) de traduction de parole
Projet UNL de communication et recherche d'information multilingue sur le
	réseau http://www.unl.ias.unu.edu ou http://www.unl.org

___________________________________________________________________
Message diffusé par la liste Langage Naturel <LN at cines.fr>
Informations, abonnement : http://www.biomath.jussieu.fr/LN/LN-F/
English version          : http://www.biomath.jussieu.fr/LN/LN/
Archives                 : http://web-lli.univ-paris13.fr/ln/