\documentclass[11pt]{article} \usepackage{graphicx} \usepackage{colacl06} \usepackage{times} \usepackage{latexsym} \setlength\titlebox{6.5cm} % Expanding the titlebox \usepackage{amsmath,amstext} \usepackage{url} \usepackage{color} \usepackage{fancybox} \usepackage{texnames} \usepackage{xspace} %% Resizing legends \setlength\abovecaptionskip{0.25ex} \setlength\belowcaptionskip{0.25ex} %% Commands \newcommand{\natlang}{\textit} \newcommand{\FIXME}[1]{\{\textbf{FIXME:} \textit{#1}\}} %% Keywords \newcommand{\HPSG}{\textsc{hpsg}\xspace} \newcommand{\Tag}{\textsc{tag}\xspace} \newcommand{\LFG}{\textsc{lfg}\xspace} \newcommand{\xmg}{\texttt{XMG}\xspace} \newcommand{\geni}{\texttt{GenI}\xspace} \newcommand{\gtester}{\texttt{gtester}\xspace} \newcommand{\LKB}{\texttt{LKB}\xspace} \newcommand{\xle}{\texttt{XLE}\xspace} \newcommand{\xtag}{\texttt{XTAG}\xspace} \newcommand{\dyalog}{\texttt{DyALog}\xspace} \newcommand{\llp}{\texttt{LLP2}\xspace} \title{SemTAG, the LORIA toolbox for TAG-based Parsing and Generation} \author{Eric Kow \\ INRIA / LORIA \\ Universit\'e Henri Poincar\'e \\ 615, rue du Jardin Botanique \\ F-54 600 Villers-L\`es-Nancy\\ {\tt kow@loria.fr} \And \hspace{1cm} Yannick Parmentier \\ \hspace{1cm} INRIA / LORIA \\ \hspace{1cm} Universit\'e Henri Poincar\'e \\ \hspace{1cm} 615, rue du Jardin Botanique \\ \hspace{1cm} F-54 600 Villers-L\`es-Nancy\\ \hspace{1cm} {\tt parmenti@loria.fr} \And \hspace{1cm} Claire Gardent \\ \hspace{1cm} CNRS / LORIA \\ \hspace{1cm} 615, rue du Jardin Botanique \\ \hspace{1cm} F-54 600 Villers-L\`es-Nancy\\ \hspace{1cm} {\tt gardent@loria.fr} } \date{} \begin{document} \maketitle \begin{abstract} In this paper, we introduce {\sc SemTAG}, a toolbox for TAG-based parsing and generation. This environment supports the development of wide-coverage grammars and differs from existing environments for \Tag\ such as \xtag, \cite{xtag01lexicalized} in that it includes a semantic dimension. {\sc SemTAG} is open-source and freely available. \end{abstract} \section{Introduction} \label{sec:introduction} % yannick In this paper we introduce a toolbox that allows for both parsing and generation with \Tag. This toolbox combines existing software and aims at facilitating grammar development, More precisely, this toolbox includes\footnote{All these tools are freely available, more information and links at \url{http://trac.loria.fr/~semtag}.}: \begin{itemize} \item \xmg : a grammar compiler which supports the generation of a \Tag from a factorised \Tag \cite{crabbe04a}, \item \llp and \dyalog : two chart parsers, one with a friendly user interface \cite{lopez00extended} and the other optimised for efficient parsing \cite{DyALog:CSLP05}\footnote{Note that \dyalog refers in fact to a logic programming language, and a tabular compiler for this language. The \dyalog system is well-adapted to the compilation of efficient tabular parsers.} % In the rest of this % paper, we well call "\dyalog parser" a parser compiled by the \dyalog % system for a given grammar.} \item \geni : a chart generator which has been tested on a middle size grammar for French \cite{gardentKow05} \end{itemize} %\begin{tabular}{lp{6.5cm}} % $\bullet$ & \xmg - a metagrammar compiler allowing to describe the \Tag in a % highly factorized way \cite{crabbe04a}, \\ % $\bullet$ & \geni - a chart generator which has been tested on realistic % grammars \cite{gardentKow05}, \\ % $\bullet$ & \llp - a parser based on an original bottom-up algorithm and % with a friendly user interface \cite{lopez00extended}, and\\ % $\bullet$ & \dyalog - an alternative parser based on a tabular algorithm % increasing parsing efficiency \cite{DyALog:CSLP05}. \\ %\end{tabular} %% Commented for the extended abstract submission: % % While developing / integrating these tools, one of our goals is to % maintain a unique and common resource (in our case, a unique % {\it metagrammar} with associated lexicons, cf {\it infra}) for both % parsing and generation. Having a unique resource presents several % advantages: maintenance costs are reduced and the bidirectionality thus % provided allows us to perform cross-testing\footnote{Indeed, we can % use the output of the generator to check if the coverage of the % grammar as given by the parser is correct and {\it vice versa}.}. As % we will see in \S \ref{sec:testing}, performing such tests facilitates % grammar development. % Our toolbox can be compared with the \LKB system, which constitutes the % reference grammar development environment for \HPSG, as it shares some % of its features: % \paragraph{Declarativity and expressivity} the reduced description of % the grammar, called the metagrammar, is represented using a % metagrammatical framework (namely \xmg) whose description language % is highly expressive and declarative \cite{gardent06xmg}. % \paragraph{Bidirectionality} as mentioned above, the toolbox can be used % both for parsing and generation with the same metagrammar. % \paragraph{Scale} the use of a metagrammar allows to produce % semi-automatically a wide coverage \Tag, this has been done for % French \cite{crabbe05representation}. % \paragraph{Efficiency} the DyALog system which pre-compiles the % grammar to produce the parser is one of the most efficient \Tag\ % parsers \cite{Lisbon04}. % \paragraph{Semantic representation} the grammar which is produced by % the \xmg system associates a flat semantic representation to the % trees such as in \cite{gardent03semantic}. % \paragraph{Availability} eventually, all the tools of our toolbox are % open source and freely available (more details in \S \ref{sec:tools}). % %% End commented for extended abstract submission % long version %The paper is structured as follows. We introduce the individual components %of the toolbox in \S \ref{sec:tools}, discuss the issues raised by %sharing resources for parsing and generation in \S \ref{sec:resources}, %and evaluate the correctness and performance of our components in %\S \ref{sec:evaluation}. %In this section, we will introduce each of the tools composing our %toolbox, highlighting their features in the context of grammar %development. \section{XMG, a grammar writing environment for Tree Based Grammars} \label{sec:xmg} % yannick \xmg provides a grammar writing environment for tree based grammars\footnote{Although in this paper we only mention \Tag, the \xmg framework is also used to develop so called Interaction Grammars i.e., grammars whose basic units are tree descriptions rather than trees \cite{parmentier05a}.} with three distinctive features. First, \xmg supports a highly factorised and fully declarative description of tree based grammars. Second, \xmg permits the integration in a \Tag of a semantic dimension. Third, \xmg is based on well understood and efficient logic programming techniques. Moreover, it offers a graphical interface for exploring the resulting grammar (see Figure~\ref{fig:xmg}). \begin{figure}%[htbp] \begin{center} \includegraphics[scale=0.4]{images/xmg.jpg} \caption{XMG's graphical interface} \label{fig:xmg} \end{center} \end{figure} \paragraph{Factorising information.} In the \xmg framework, a \Tag is defined by a set of classes organised in an inheritance hierarchy where classes define tree fragments (using a tree logic) and tree fragment combinations (by conjunction or disjunction). \xmg furthermore integrates a sophisticated treatment of names whereby variables scope can be local, global or user defined (i.e., local to part of the hierarchy). In practice, the resulting framework supports a very high degree of factorisation. For instance, a first core grammar ({\sc FraG}) for French comprising 4 200 trees was produced from roughly 300 \xmg classes. \paragraph{Integrating semantic information.} In \xmg , classes can be multi-dimensional. That is, they can be used to describe several levels of linguistic knowledge such as for instance, syntax, semantics or prosody. At present, \xmg supports classes including both a syntactic and a semantic dimension. As mentioned above, the syntactic dimension is based on a tree logic and can be used to describe (partial) tree fragments. The semantic dimension on the other hand, can be used to associate with each tree a flat semantic formula. Such a formula can furthermore include identifiers which corefer with identifiers occurring in the associated syntactic tree. In other words, \xmg also provides support for the interface between semantic formulae and tree decorations. Note that the inclusion of semantic information remains optional. That is, it is possible to use \xmg to define a purely syntactic \Tag. \xmg was used to develop a core grammar for French ({\sc FraG}) which was evaluated to have 75\% coverage\footnote{This means that for 75 \% of the sentences, a \Tag parser can build at least one derivation.} on the Test Suite for Natural Language Processing (TSNLP, \cite{lehmann96tsnlp}). The {\sc FraG} grammar was furthermore enriched with semantic information using another 50 classes describing the semantic dimension \cite{gardent06integration}. The resulting grammar ({\sc SemFraG}) describes both the syntax and the semantics of the French core constructions. \paragraph{Compiling an \xmg specification.} By building on efficient techniques from logic programming and in particular, on the Warren's Abstract Machine idea \cite{aitkaci91warren}, the \xmg compiler allows for very reasonable compilation times \cite{dlp04}. For instance, the compilation of a \Tag containing 6 000 trees takes about 15 minutes with a Pentium 4 processor 2.6 GHz and 1 GB of RAM. \section{Two TAG parsers} \label{sec:parsers} % yannick The toolbox includes two parsing systems: the \llp parser and the \dyalog system. Both of them can be used in conjunction with \xmg. First we will briefly introduce both of them, and then show that they can be used with a semantic grammar (e.g., {\sc SemFrag}) to perform not only syntactic parsing but also semantic construction. \paragraph{LLP2} The \llp parser is based on a bottom-up algorithm described in \cite{lopez99analyse}. It has relatively high parsing times but provides a user friendly graphical parsing environment with much statistical information (see Figure~\ref{fig:llp2a}). It is well suited for teaching or for small scale projects. \begin{figure}%[htbp] \begin{center} \includegraphics[scale=0.3]{images/llp2a.jpg} \caption{The LLP2 parser.} \label{fig:llp2a} \end{center} \end{figure} \paragraph{DyALog} The \dyalog system on the other hand, is a highly optimised parsing system based on tabulation and automata techniques \cite{DyALog:CSLP05}. It is implemented using the \dyalog programming language ({\it i.e.}, it is bootstrapped) and is also used to compile parsers for other types of grammars such as {\it Tree Insertion Grammars}. The \dyalog system is coupled with a semantic construction module whose aim is to associate with each parsed string a semantic representation\footnote{The corresponding system is called SemConst ({\it cf} section \ref{sec:availability}).}. %% The LORIA toolbox aims not at gathering parsers and generators %% for a given formalism but rather at providing an efficient system for %% parsing and generation using common resources. In this context, we %% want to be able to produce semantic representations that would be used %% as input for generation\footnote{And vice-versa, we would use the %% generated sentences for parsing and thus cross-check the tools (and %% the resources).}. To perform this, we can use the results of %% syntactic parsing with a semantic grammar using This module assumes a \Tag of the type described in \cite{gardent03semantic,gardent06integration} where initial trees are associated with semantic information and unification is used to combine semantic representations. In such a grammar, the semantic representation of a derived tree is the union of the semantic representations of the trees entering in the derivation of that derived tree modulo the unifications entailed by analysis. As detailed in \cite{gardent05large}, such grammars support two strategies for semantic construction. The first possible strategy is to use the full grammar and to perform semantic construction during derivation. In this case the parser must manipulate both syntactic trees and semantic representations. The advantage is that the approach is simple (the semantic representations can simply be an added feature on the anchor node of each tree). The drawback is that the presence of semantic information might reduce chart sharing. The second possibility involves extracting the semantic information contained in the grammar and storing it into a semantic lexicon. Parsing then proceeds with a purely syntactic grammar and semantic construction is done after parsing on the basis of the parser output and of the extracted semantic lexicon. This latter technique is more suitable for large scale semantic construction as it supports better sharing in the derivation forests. It is implemented in the LORIA toolbox where a module permits both extracting a semantic lexicon from a semantic \Tag and constructing a semantic representation based on this lexicon and on the derivation forests output by \dyalog (see Figure~\ref{fig:semconst}). \begin{figure}%[htbp] \begin{center} \includegraphics[scale=0.25]{images/semconst3.jpg} \caption{The SemConst system} \label{fig:semconst} \end{center} \end{figure} The integration of the \dyalog system into the toolbox is relatively new so that parsing evaluation is still under progress. So far, evaluation has been restricted to parsing the TSNLP with \dyalog with the following preliminary results. On sentences ranging from 1 to 18 words, with an average of 7 words per sentence, and with a grammar containing 5 069 trees, \dyalog average parsing time is of 0.38 sec with a P4 processor 2.6 GHz and 1 GB of RAM\footnote{These features only concern classic syntactic parsing as the semantic construction module has not been tested on real grammars yet.}. \section{A TAG-based surface realiser} \label{sec:geni} The surface realiser \geni takes a TAG and a flat semantic logical form as input, and produces all the sentences that are associated with that logical form by the grammar. It implements two bottom up algorithms, one which manipulates derived trees as items and one which is based on Earley for \Tag. Both of these algorithms integrate a number of optimisations such as delayed adjunction and polarity filtering \cite{kow05a,gardentKow05}. \geni is written in Haskell and includes a graphical debugger to inspect the state of the generator at any point in the surface realisation process (see Figure~\ref{fig:geni_debugger}). It also integrates a test harness for automated regression testing and benchmarking of the surface realiser and the grammar. The harness \gtester is written in Python. It runs the surface realiser on a test suite, outputting a single document with a table of passes and failures and various performance charts (see Figures \ref{fig:testharness} and \ref{fig:testharness2}). \begin{figure}%[htbp] \begin{center} \includegraphics[scale=0.33]{images/geni-debugger-screenshot} \caption{The GenI debugger} \label{fig:geni_debugger} \end{center} \end{figure} \begin{figure}%[htbp] \begin{center} {\small \begin{tabular}{|r|l|l|l|} \hline \textbf{test} & \textbf{expected}& \textbf{simple}& \textbf{earley}\\ \hline t1 &il le accepter & pass & pass\\ \hline t32 &il nous accepter & pass & pass\\ \hline t83 &le ingénieur le lui apprendre & pass & \colorbox{red}{DIED}\\ \hline t114 &le ingénieur nous le présenter & pass & pass\\ \hline t145 &le ingénieur vous le apprendre & pass & pass\\ \hline t180 &vous venir & pass & pass\\ \hline \end{tabular} } \caption{Fragment of test harness output - The Earley algorithm timed out.} \label{fig:testharness} \end{center} \end{figure} \begin{figure}%[htbp] \begin{center} \includegraphics[scale=0.6]{images/gtester_graph} \caption{Automatically generated graph of performance data by the test harness.} \label{fig:testharness2} \end{center} \end{figure} %The use of \gtester is made %especially convenient when combined with a Makefile which automatically %recompiles a subset of the grammar needed for the tests being %run\footnote{One could also compile the entire grammar, but this is not %conducive to debugging as this entails frequent modifications to grammar %and much recompilation}, but only when the grammar or test suite have %changed. %Similar techniques are also used for testing the parser. % more on polarity filtering % ambiguity via number of results % \paragraph{Test suite and performance} The test suite is built with an emphasis on testing the surface realiser's performance in the face of increasing paraphrastic power i.e., ambiguity. The suite consists of semantic inputs that select for and combines verbs with different valencies. For example, given a hypothetical English grammar, a valency (2,1) semantics might be realised in as \natlang{Martin thinks Faye drinks} (\natlang{thinks} takes 2 arguments and \natlang{drinks} takes 1), whereas a valency (2,3,2) one would be \natlang{Dora says that Martin tells Bob that Faye likes music}. The suite also adds a varying number of intersective modifiers into the mix, giving us for instance, \natlang{The girl likes music}, \natlang{The pretty scary girl likes indie music}. The sentences in the suite range from 2 to 15 words (8 average). Realisation times for the core suite range from 0.7 to 2.84 seconds CPU time (average 1.6 seconds). We estimate the ambiguity for each test case in two ways. The first is to count the number of paraphrases. Given our current grammar, the test cases in our suite have up to 669 paraphrases (average 41). The second estimate for ambiguity is the number of combinations of lexical items covering the input semantics. This second measure is based on optimisation known as polarity filtering \cite{gardentKow05}. This optimisation detects and eliminates combinations of lexical items that cannot be used to build a result. It associates the syntactic resources (root nodes) and requirements (substitution nodes) of the lexical items to polarities, which are then used to build ``polarity automata''. The automata are minimised to eliminate lexical combinations where the polarities do not cancel out, that is those for which the number of root and substitution nodes for any given category do not equal each other. Once built, the polarity automata can also serve to estimate ambiguity. The number of paths in the automaton represent the number of possible combinations of lexical items. To determine how effective polarity filtering with respect to ambiguity, we compare the combinations before and after polarity filtering. Before filtering, we start with an initial polarity automaton in which all items are associated with a zero polarity. This gives us the lexical ambiguity before filtering. The polarity filter then builds upon this to form a final automaton where all polarities are taken into account. Counting the paths on this automaton gives us the ambiguity after filtering, and comparing this number with the lexical initial ambiguity provides an estimate on the usefulness of the polarity filter. In our suite, the initial automata for each case have 1 to 800 000 paths (76 000 average). The final automata have 1 to 6000 paths (192 average). This can represent quite a large reduction in search space, 4000 times in the case of the largest automaton. The effect of this search space reduction is most pronounced on the larger sentences or those with the most modifiers. Indeed, realisation times with and without filtering are comparable for most of the test suite, but for the most complicated sentence in the core suite, polarity filtering makes surface realisation 94\% faster, producing a result in 2.35 seconds instead of 37.38. \section{Benefits of an integrated toolset} \label{sec:benefits} As described above, the LORIA toolbox for TAG based semantic processing includes a lexicon, a grammar, a parser, a semantic construction module and a surface realiser. Integrating these into a single platform provides some accrued benefits which we now discuss in more details. \paragraph{Simplified resource management} \label{par:simplification} The first advantage of an integrated toolkit is that it facilitates the management of the linguistic resources used namely the grammar and the lexicon. Indeed it is common that each NLP tool (parser or generator) has its own representation format. Thus, managing the resources gets tiresome as one has to deal with several versions of a single resource. When one version is updated, the others have to be recomputed. Using an integrated toolset avoid such a drawback as the intermediate formats are hidden and the user can focus on linguistic description. \paragraph{Better support for grammar development} \label{par:mgdev} When developing parsers or surface realisers, it is useful to test them out by running them on large, realistic grammars. Such grammars can explore nooks and crannies in our implementations that would otherwise have been overlooked by a toy grammar. For example, it was only when we ran \geni on our French grammar that we realised our implementation did not account for auxiliary trees with substitution nodes (this has been rectified). In this respect, one could argue that \xmg could almost be seen as a parser/realiser debugging utility because it helps us to build and extend the large grammars that are crucial for testing. This perspective can also be inverted; parsers and surface realiser make for excellent grammar-debugging devices. For example, one possible regression test is to run the parser on a suite of known sentences to make sure that the modified grammar still parses them correctly. The exact reverse is useful as well; we could also run the surface realiser over a suite of known semantic inputs and make sure that sentences are generated for each one. This is useful for two reasons. First, reading surface realiser output (sentences) is arguably easier for human beings than reading parser output (semantic formulas). Second, the surface realiser can tell us if the grammar overgenerates because it would output nonsense sentences. Parsers, on the other hand, are much better adapted for testing for undergeneration because it is easier to write sentences than semantic formulas, which makes it easier to test phenomena which might not already be in the suite. \paragraph{Towards a reversible grammar} \label{par:reversible} %% intro de section Another advantage of using such a toolset relies on the fact that we can manage a common resource for both parsing and generation, and thus avoid inconsistency, redundancy and offer a better flexibility as advocated in \cite{neumann94uniform}. %% Fin intro de section % throwaway sentence? - depends on what Yannick writes % It is conceivable to use the LORIA toolbox to simulate the % interleaved % parsing/realisation architecture described by % \cite{neumann94uniform}. On top of these practical questions, having a unique reversible resource can lead us further. For instance, \cite{neumann94uniform} proposes an interleaved parsing/realisation architecture where the parser is used to choose among a set of paraphrases proposed by the generator; paraphrases which are ambiguous (that have multiple parses) are discarded in favour of those whose meaning is most explicit. Concretely, we could do this with a simple pipeline using \geni to produce the paraphrases, \dyalog to parse them, and a small shell script to pick the best result. This would only be a simulation, of course. \cite{neumann94uniform} goes as far as to interleave the processes, keeping the shared chart and using the parser to iteratively prune the search space as it is being explored by the generator. The version we propose would not have such niceties as a shared chart, but the point is that having all the tools at our disposable makes such experimentation possible in the first place. %Moving from conceivable to practical is likely just a matter of %implementation. Moreover, there are several other interesting applications of the combined toolbox. We could use the surface realiser to build artificial corpora. These can in turn be parsed to semi-automatically create rich treebanks containing syntactico-semantic analyses \`a la Redwoods \cite{oepen02lingo}. Eventually, another use for the toolbox might be in components of standard NLP applications such as machine translation, questioning answering, or interactive dialogue systems. \section{Availability} \label{sec:availability} %% say something about the availability of the system (including %% platform) The toolbox presented here is open-source and freely available under the terms of the GPL\footnote{Note that \xmg is released under the terms of the CeCILL license (\url{http://www.cecill.info/index.en.html}), which is compatible with the GPL.}. More information about the requirements and installation procedure is available at \url{http://trac.loria.fr/~semtag}. Note that this toolbox is made of two main components: the GenI\footnote{\url{http://trac.loria.fr/~geni}} system and the SemConst\footnote{\url{http://trac.loria.fr/~semconst}} system, which respectively performs generation and parsing from common linguistic resources. The first is written in Haskell (except the \xmg part written in Oz) and is multi-platform (Linux, Windows, Mac OS). The latter is written in Oz (except the \dyalog part which is bootstrapped and contains some Intel assembler code) and is available on Unix-like platforms only. \section{Conclusion} \label{sec:conclusion} %all The LORIA toolbox provides an integrated environment for TAG based semantic processing: either to construct the semantic representation of a given sentence (parsing) or to generate a sentence verbalising a given semantic content (generation). Importantly, both the generator and the parsers use the same grammar ({\sc SemFraG}) so that both tools can be used jointly to improve grammar precision. All the sentences outputted by the surface realiser should be parsed to have at least the semantic representation given by the test suite, and all parses of a sentence should be realised into at least the same sentence. Current and future work concentrates on developing an automated error mining environment for both parsing and generation; on extending the grammar coverage; on integrating further optimisations both in the parser (through parsing with factorised trees) and in the generator (through packing and accessibility filtering cf. \cite{carrollOepen05}; and on experimenting with different semantic construction strategies \cite{gardent05large}. %\section{Acknowledgements} %{\small \bibliographystyle{acl} \bibliography{garkowpar-tag-06} %} %\appendix %\section*{Appendix A. Features of eXtensible MetaGrammar.} % \begin{figure*} % {\bf Appendix A. Features of eXtensible MetaGrammar.} % \end{figure*} % \begin{figure*}%[htbp] % \begin{center} % \includegraphics[scale=0.6]{images/xmg.jpg} % \caption{XMG's output} % \label{fig:xmg} % \end{center} % \end{figure*} %\section*{Appendix B. Features of the GenI generator.} % \begin{figure*} % {\bf Appendix B. Features of the GenI generator.} % \end{figure*} % \begin{figure*}%[htbp] % \begin{center} % \includegraphics[scale=0.33]{images/geni-debugger-screenshot} % \caption{The GenI debugger} % \label{fig:geni_debugger} % \end{center} % \end{figure*} % \begin{figure*}%[htbp] % \begin{center} % {\small % \begin{tabular}{|r|l|l|l|} % \hline % \textbf{test} & \textbf{expected}& \textbf{simple}& \textbf{cky2}\\ % \hline % t1 &il le accepter & pass & pass\\ % \hline % t32 &il nous accepter & pass & pass\\ % \hline % t83 &le ingénieur le lui apprendre & pass & \colorbox{red}{DIED}\\ % \hline % t114 &le ingénieur nous le présenter & pass & pass\\ % \hline % t145 &le ingénieur vous le apprendre & pass & pass\\ % \hline % t180 &vous venir & pass & pass\\ % \hline % \end{tabular} % } % \caption{Fragment of test harness output - The Earley algorithm timed out.} % \label{fig:testharness} % \end{center} % \end{figure*} % \begin{figure*}%[htbp] % \begin{center} % \includegraphics[scale=0.9]{images/gtester_graph} % \caption{Automatically generated graph of performance data by the test % harness.} % \label{fig:testharness2} % \end{center} % \end{figure*} %\section*{Appendix C. Features of the LLP2 parser.} % \begin{figure*} % {\bf Appendix C. Features of the LLP2 parser.} % \end{figure*} % \begin{figure*}%[htbp] % \begin{center} % \includegraphics[scale=0.5]{images/llp2a.jpg} % \caption{The LLP2 parser.} % \label{fig:llp2a} % \end{center} % \end{figure*} %% removed for final version coz 6 pages limit. %% % \begin{figure*}%[htbp] % \begin{center} % \includegraphics[scale=0.6]{images/llp2b.jpg} % \caption{The LLP2 parser (displaying features).} % \label{fig:llp2b} % \end{center} % \end{figure*} % \begin{figure*}%[htbp] % {\small % \begin{verbatim} % Morpho loading time : 0ms % Resource loading time : 0ms % Lemmatizing time : 10645ms % Chart initializing time : 45ms % Parsing time : 67ms % Derivation Trees building time : 32ms % Nb of words :3 % Nb of segment :7 % Nb of elementary trees : 141 % Nb of items at the beginning: 242 % Nb of items at the end: 272 % Nb of parsed sentences : 2 % \end{verbatim} % } % \caption{Statistical information given by the LLP2 parser.} % \label{fig:stats} % \end{figure*} \end{document}