SYNTACTIC ANALYSIS

This section presents syntactic grammars, i.e. grammars that process sequences of tokens (as opposed to the morphological grammars that process sequences of letters in tokens). In NooJ, syntactic grammars are organized sets of graphs, and are called local grammars. Chapter 13 presents local grammars that are used to recognize and annotate multi-word units and semi-frozen expressions, build complex embedded annotations, as well as delete annotations to disambiguate words. Chapter 14 shows how to formalize frozen expressions (i.e. discontinuous ALUs). Chapter 15 describes NooJ’s syntactic parser’s behavior in special cases, such as when applying ambiguous grammars. Chapter 16 presents more powerful syntactic tools, such as a Context-Free parser that can compute sentences’ structure, and NooJ’s Enhanced Grammars that can perform semantic analyses (i.e. to produce abstract representations of texts), transformations on texts (to generate paraphrases) and translations.

Chapter 13. Syntactic Grammars

In Chap. 11, we saw that certain parts of the dictionary can be processed with morphological grammars (see grammars tsar and Roman numerals). These grammars were applied by NooJ’s morphological engine to simple word forms (sequences of letters between delimiters); hence, they could not process multi-word units or frozen expressions.

The syntactic grammars we see now are also used to represent ALUs (Atomic Linguistic Units), but these ALUs can be multi-word units or frozen expressions.

13.1. Local Grammars

Numeric Determiners

We want to identify numeric determiners written out in text form. (e.g. two thousand three hundred fify two). Start by creating a new syntactic grammar ( File > New Grammar, choose the two languages en / en, then click “Create a syntactic grammar”), and name it Dnum (do not delete the default grammar _Dnum).

In the main graph of the new grammar, include links to three embedded graphs: “Dnum 2-99”, “Dnum 100-999” and “Dnum 1000-999999”, as seen in the following graph:

Figure 1 Numeric determiners from 1 to 99

To enter a reference to a graph in a node, write the graph’s name prefixed with the colon special character “:”. The node’s background color should change to yellow to indicate that it is an auxiliary node.

At this point, the three graphs do not exist yet in the Dnum grammar. We are going to create the first one Dnum2-99 by alt-clicking its reference. NooJ knows that the graph Dnum2-99 does not exist, and asks if you want to create the graph:

“Yes”. NooJ should now display an empty graph. Edit it and construct a graph similar to the following one:

Figure 2. Numeric determiners from 1 to 99

Go back up to the Parent node (press the “U” key, or display the grammar’s structure and click the Main graph) and then alt-click the node for Dnum100-999 to create it.

To navigate between different graphs in one grammar, use:
-- the “U” key (UP) to display the current graph’s Parent
-- the “D” key (DOWN) to display the current graph’s first Child
-- the “N” key (NEXT) to display the current graph’s next Sibling
-- the “P” key (PREVIOUS) to display the current graph’s previous sibling
You can also display the grammar’s structure Grammar > Show Structure, and navigate to any graph by clicking its name.

Enter the graph Dnum100-999, then edit it to get a graph similar to the following:

Figure 3. Numeric determiners from 100 to 999

Notice the yellow line “Dnum2-99” inside the graph “Dnum100-999” : it refers to the graph of the same name. If “Dnum2-99” is not displayed in yellow, remember to prefix its name with the colon character “:”; In this case we’ve entered the label “:Dnum2-99”.

To verify whether or not the embedded graph really exists, Alt-Click (press the Alt key, and click simultaneously) on its reference: the embedded graph should appear. Continue the formalization of numeric determinants by constructing the graph “Dnum1000-999999” which will represent the numbers 1,000 to 999,999:

Figure 4. Numeric determiners from 1,000 to 999,999

Exercise: enhance the linguistic description to represent numeric determiners such as thirteen hundred, hundreds of, thousands of, two millions thirty thousand and fourty-three, eight billion, etc.

Do not forget to save your grammar. At this point, we have created a grammar that can be applied to texts in order to build a concordance of numeric determiners. For instance, load the text “_en Portrait Of A Lady” ( File > Open > Text), then apply the previous grammar to the text (Text > Locate), then:

Figure 5. Locate numeric determiners in a text

With the same options checked (all matches; only one example per match), you should get a concordance with 33 entries:

Figure 6. Numeric determiners in the text THE PORTRAIT OF A LADY

We are going to enhance this grammar so that instead of merely recognizing numeric determiners, NooJ will tag them in texts, just as if they had been entered in a dictionary.

Now, we want to annotate the matching sequences with the category “DET” (already used to tag other determiners such as “the”). In order to do that, we go back to the main graph (press the “U” key, or click the Main graph in the grammar’s structure’s window), then edit the initial node and enter the new label “<E>/<DET”, add a new node before the terminal node, and enter its label “<E>/>”. You should get a graph similar to the following:

Figure 7. Annotation the numeric determiners

All the sequences that are recognized by this grammar will now be analyzed as “DET”. Each annotation starts where the “<” character is located (in this case, at the beginning of the expression), and ends where the “>” character is located (in this case: at the end of the sequence). We want to add more information than just the category: edit the graph to add the “+Num” property (numeric expression), the “one” label to add the “+s” (singular) property, then connect all other plural determiners to a new node labeled “<E>/+p” (plural). Connect the nodes so that you get a graph similar to the following:

Figure 8. Syntactic grammar to annotate numeric determiners

Now, if this grammar is applied to the text (either manually via the Locate window, or automatically via Text > Linguistic Analysis), NooJ will process numeric determiners exactly as if they had been listed explicitly in a dictionary:

one,DET+Num+s

two,DET+Num+p

...

one hundred and twenty-two,DET+Num+p

...

seven thousand three hundred and two,DET+Num+p

and all numeric determiners in the text will be annotated accordingly:

Figure 9.Annotating numeric determiners

Note that NooJ displays lexical annotations in black, and syntactic annotations in green. You can apply syntactic grammars, and insert all their annotations into the TAS, either manually, or automatically:

(1) manually: apply the syntactic grammar via the TEXT > Locate command. Edit the resulting concordance, i.e. filter out sequences that were incorrectly recognized ( CONCORDANCE > Filter out selected lines), then insert the newly created annotations in the TAS ( CONCORDANCE > Annotate Text).

(2) automatically: select the syntactic grammar in Info > Preferences > Syntactic Analysis, then use the “+” and “-” buttons to assign it a priority over other ones. From now on, every time the command TEXT > Linguistic Analysis is being launched, NooJ’s engine will apply it, as well as other syntactic grammars, and after all selected lexical resources.

Dates

The description of certain linguistic phenomena typically requires the construction of dozens of elementary graphs such as the ones we just built. At the same time, most of these local grammars can be re-used in different contexts, for the description of many different linguistic phenomena.

A typical NooJ local grammar consists of a dozen graphs, and can be seen as a libraries of graphs; this allows different users to cooperatively build and share re-usable libraries of graphs.

For instance, consider the following graph Tuesday that recognizes names of days ( Monday ... Sunday):

Figure 10. Name of the days

This graph can be used in the grammar that recognizes more complex dates, e.g.:

last Monday; on Tuesday, June 5th; on Wednesday 31st

Figure 11.Graph Mondayn,June 5th

The graph Monday, June 5th can be reused, together with other graphs that recognize other expressions of date, as for instance the following graph at 7:10 am:

Figure 12. Graph at 7:10 am

These graphs, together with another dozen are then composed into a general grammar that recognizes and annotates complex date expressions:

Figure 13. Grammar Date

If this grammar is applied to a text either manually, via TEXT > Locate and then CONCORDANCE > Annotate Text, or automatically, by selecting it in Info > Preferences > Syntactic Analysis, all dates in the text will be annotated as if they had been recognized by a dictionary lookup:

Figure 14. Annotating complements of date

Frozen and semi-frozen expressions are naturally described by local grammars, and should be applied automatically, by default, everytime a text or a corpus is being analyzed with the command TEXT > Linguistic Analysis. In order to do that, select the grammars in Info > Preferences > Syntactic Analysis.

As soon as date expressions has been annotated, it is possible to access these annotations in NooJ regular expression queries, such as the following:

<PRO> <V+PP> <ADV+Date>

This would recognize phrases such as “it happened on Monday, June 5th”, “he left a few years ago”, etc.

NooJ syntactic grammars have access to all the text’s lexical and syntactic annotations; they can add their own annotations, that will in turn be re-used in other grammars to describe more and more complex phrases, up to the sentence level.

13.2. Taking Contexts Into Account

Being able to specify exactly where annotations start and end allows also linguists to describe parts of the left and right contexts of the patterns they are looking for.

For instance, consider the following grammar:

Figure 15.Annotating Noun Phrases' head

This grammar recognizes sequences such as “Large red tables which” and “The American Import Export Organization that”, and then annotate the head of these incomplete noun phrases, respectively “tables” and “Organization”.

13.3. Disambiguation=Filtering Out Annotations

We have seen how to add annotations to a text annotation structure. We also need methods to remove annotations from a Text Annotation Structure. NooJ provides three methods: automatic, semi-automatic and manual;

Automatic disambiguation

For instance, consider the following ambiguous text:

Figure 16. An ambiguous text

In fact, in this text, the first occurrence of the word “this” should correspond to a pronoun, and the second occurrence to a determiner; “makes” should be here annotated as a verb, and “table” as a noun.

Now consider the following grammar:

Figure 17. Disambiguation Grammar

This grammar recognizes the sequence “this makes”. In that case, it produces the annotation “<PRO>” at the position of the word “this”, and the annotation “<V>” at the position of the word “makes”. Note that each of these annotations has a 0-character length; in consequence, NooJ uses them to filter out all the annotations of the Text Annotation Structure that are not compatible with them. In consequence, the two annotations “this,DET” and “this,ADV” are deleted, as well as the annotation “make,N+p”.

In the same way, the grammar recognizes “this table”, and produces the two filters “<DET>” and “<N>”. In consequence, the annotations “this,PRO” and “this,ADV” are deleted, as well as the three annotations that correspond to the verb “to table”. Applying this grammar to this text produces the following result:

Figure 18. Disambiguated Text

Although this local grammar is very specific, it covers 2.5% of the text. Our goal is to develop a set of 30+ local grammars such as this one: target frequent ambiguous words to be as efficient as possible, while at the same time as specific as possible, so as to avoid producing incorrect results.

Semi-automatic disambiguation

The double constraint of efficiency and correctness is often very hard to follow, and in a number of cases, it is much too tempting to design very efficient rules which are correct in all but a few cases … For instance, it seems that all occurrences of the word all followed by a proper name correspond to the pronoun:

Figure 19. The context that <N+PR> is a good candidate for a disambiguation rule

This rule would have been very helpful to get rid of the incorrect concordance entries for the above-mentioned query <DET> <N>. Indeed, in the text The portrait of a lady, this rule can effectively be used to remove 150 ambiguities. However, it is not very difficult to build an example in which that is followed by a proper name, but is still a determiner:

Are you speaking of that John Doe?

Therefore, we need to be able to quickly enter simple disambiguation rules and check them before effectively applying them. In NooJ’s new v2.2 version, it is possible to type in a query in the form of an expression associated with an output:

Figure 20. A simple disambiguation query

The regular expression that/<PRO> <N+PR> matches all the sequences of that followed by a proper name; then the output <PRO> is used to disambiguate the word form that.

We can edit the resulting concordance in order to filter out incorrect matches, i.e. sequences that were recognized but should not be used. We first select the unwanted concordance entries, then use the command Filter out selected lines of the CONCORDANCE menu to remove them from the concordance, and then Annotate Text (add/remove annotations) to perform the disambiguation for all remaining concordance entries.

This process is very quick: users should not hesitate to enter disambiguation commands that are very efficient but have poor accuracy, such as:

are/<V>

for/<PREP>

its/<DET>

etc.

The possibility of examining the resulting concordances and then filtering out incorrect analyses allows us to experiment more freely. Finally, note that we can save concordances at any moment: this allows us to validate large concordances at our own pace.

Editing the TAS

Sometimes, it is much faster to just delete unwanted annotations without having to write local grammars or even queries. In NooJ’s new 2.2 version, we can just open the TAS (click Show Text Annotation Structure at the top of the text window), click an unwanted annotation, and then delete it either with the menu command Edit > Cut, or by pressing any of the following keys: Ctrl-x, Delete or Backspace. NooJ manages an unlimited number of undo’s: Edit > Undo or press Ctrl-Z.

Figure 21.Editing the TAS

Examining the text’s ambiguities

A new tool has been added to NooJ: the possibility of listing ambiguities according to their frequencies, to select one ambiguity and then to apply one solution to the text automatically. The most frequent ambiguous words will be the ones we intend to study in order to disambiguate the text efficiently.

Double-click Ambiguities in the text’s result window, then click the header “Freq” to sort all ambiguities according to their frequency.

Figure 22. List of frequent Ambiguities

Here we notice that the word form for is ambiguous and occurs 1,919 times in the text. We select the second disambiguation solution (at the top of the window): <for,PREP>. Then, we click one of the colored buttons to build the corresponding concordance. Finally, we filter out the rare cases in which for is actually a conjunction (I did not find any occurrence in the text Portrait of a lady) and then click Annotate text (add/remove annotations) to disambiguate the word form.

Conversely, we can double-click Unambiguous Words in the text’s result window in order to display the list of all unambiguous words. Usually, the word forms the, a and of appear most frequently. We can then use frequent unambiguous words as anchors, to remove word ambiguities that occur immediately before or after them. For instance, the word table is theoretically ambiguous (it could be a verb), but in the sequences the table and a table it has to be a noun. Focusing on frequent unambiguous words can help us design new types of disambiguation rules.

13.4 Multiple Annotations

Up to now, sequences recognized by a local grammar (e.g. “twenty-three thousand seven hundred fourty-one”) were annotated as a whole (e.g. DET). We now show how to produce more complex grammars, to annotate only parts of the recognized sequences, or to produce more than one annotation for a given sequence.

Consider the following Duration grammar:

Figure 23. Grammar Duration

This grammar recognizes sequences such as “From Monday to Thursday”. When recognized, sequences get annotated the following way:

Figure 24. Complex annotations are inserted in the TAS

(Green annotations come from the above grammar; black annotations come from NooJ’s lexical parser).

There is no limit to the number of embedded annotations that can be inserted at the same time for a given sequence. Indeed, annotations can (and should) be inserted locally, from inside embedded graphs. For instance, the following grammar:

Figure 25. Embedded Grammar and Annotations

produces DURATION annotations; at the same time, the graphs DATE produce DATE annotations; they refer to other embedded graphs TIME which produce TIME annotations, etc.

A given grammar can add annotations, and remove others, at the same time. For instance, the following grammar can be used to disambiguate “this” and “that”, and annotate the noun phrase at the same time.

Figure 26. Adding and Removing Annotations at the same time

Chapter 14. Frozen Expressions

Affixes, simple words and multi-word Units are processed by NooJ’s lexical parser, as we saw in the previous part. Frozen expressions, on the other hand, are discontinuous multi word units that cannot be recognized by NooJ’s lexical parser. NooJ provides two methods to formalize frozen expressions:

-- NooJ’s local grammars can represent and recognize all the possible contexts of a given expression.

-- NooJ allows linguists to link a dictionary that describes the possible constitutents of the frozen expression, with a grammar that describes its syntactic behavior[1]. Basically, linguists typically use the first, easiest, method to represent limited series of frozen expressions or semi-frozen expressions (such as named entitites), whereas they use the second, more powerful tool to represent large numbers of expressions, typically lists of hundreds of idioms, proverbs, etc. that are best represented by dictionaries.

[1]: Linking a dictionary with a grammar is natural in linguistics: Maurice Gross has indeed described frozen expressions in “lexicon-grammar tables”, which are dictionaries in which lexical entries are associated with some syntactic properties. Lexicon-grammar tables can easily be imported into NooJ, and any NooJ dictionary can be displayed as a lexicon-grammar table: the commands “Display As Table” and “Display As List” perform the conversion. Here, we are taking a further step: NooJ uses the grammar to validate the dictionary’s entries.

14.1 Local Grammars Of Frozen Expressions

NooJ’s syntactic local grammars are used to represent, automatically recognize and annotate expressions, such as the ones we saw in 13.1. Local grammars. Complex determiners, such as the ones represented by the grammar in Figure 63.144 ) can indeed be considered as full ALUs.

The situation is a little more complex when we deal with discontinuous ALUs. For instance, the phrasal verb to give up occurs in the two following sentences:

John gave up his rights. John gave his rights up .

Therefore we need to represent both ALUs with an annotation. Consider the following grammar:

Figure 27. A discontinuous expression

This grammar recognizes the sequence “gave up”, and then produces the single annotation <PV> (Phrasal Verb). The grammar recognizes also the sequence “gave his right up”, and then produces two annotations that contain the keyword XREF. This keyword tells NooJ to aggregate these annotations. The result is a discontinuous annotation, as seen in the following figure:

Figure 28. A Discontinuous Annotation

In other words, the expression “gave ... up” has been annotated as a <PV>. The previous local grammar can be enhanced as one might decide to annotate the expression in a richer way: instead of annotating the whole expression as a <PV>, one might rather annotate the first component of the expression as <V+PV> and the second component as <PART+PV>:

Figure 29. A Richer Grammar

In that case, the resulting text annotation structure will be the following:

Figure 30. A Richer Annotation

The richer annotation allows NooJ to still be able to find “gave” as a verb, and “up” as a particle, eventhough the whole can also be processed as a single entity.

One might even decide to lemmatize the annotation, and to describe it by reusing parts of the lexical information associated with “gave” so that the corresponding ALU will be <give up,PV+tr+Pret>. In order to do that, we need to add to the previous grammar a variable, say $V, that will hold the lexical information that is produced by the node <give>.

In a “real” linguistic application, we would want to replace the node <WF>* (which matches any sequence of tokens) with a more adequate description, such as a description of noun phrases. There are two possibilities here:

-- We could insert a simplified description of NPs in an embedded graph. To do that, just replace the node <WF> with a :NP node. Note that the :NP graph itself can also has its own embedded graphs.

-- There might already be a general syntactic grammar that annotates all noun phrases as <NP>. In that case, make sure that the NP grammar has been selected in Info > Preferences > Syntactic Analysis, then simply replace the node <WF>* with a node <NP>.

14.2 Linking Dictionnries And Grammars

Local grammars are easy to implement when one wants to describe a small family of expressions, but they would be inadequate if one wants to describe several hundred expressions.

In that case, we need to link a dictionary to a syntactic grammar. This association between a dictionary and a grammar is very natural; indeed linguists at the LADL and in other labs have used lexicon-grammars to represent frozen expressions for a long time [[#_ftn1][]]. In order to formalize a series of frozen expressions in NooJ, we need to construct a dictionary and a grammar, and link them.

(1) The dictionary contains the characteristic component for each expression.

The characteristic component of a frozen expression is a simple word or a multi-word unit that occurs every time the frozen expression occurs.

In general, the characteristic component triggers the recognition for the whole expression. For instance, both the verb take and the noun “account” could be characteristic components of the expression to take into account. However, the verb be cannot be a characteristic component of the expression “to be late”, because this expression occurs even if the verb be does not occur, for instance in:

John made Mary late.

(which is analized as John caused Mary to be late). In that case, the characteristic component should be late.

For this reason, the characteristic component of the associations of a predicative noun and its support verb (and all the support verb’s variants) should always be the noun.

When choosing the characteristic component for a frozen expression, it is important to avoid words that occur in a lot of frozen expressions: if “take” is the characteristic component of thousands of expressions (e.g. take into account, take care of, take place, take a swim, etc.), there will be thousands of entries “take” in the dictionary; solving all these ambiguities will slow NooJ’s lookup procedure considerably. It is much better to choose really characteristic components, such as into account, care of, place, a swim.

(2) In the dictionary, each characteristic component must be associated with each of the other components of the expression, as well as some properties that will be checked by the associated grammar. For instance, we could have the following lexical entry:

take,V+FLX=TAKE+PP=“into account”

The FLX information ensures that the characteristic component will be recognized even when inflected. The PP information links the lexical entry to the word sequence “into account”. More information, such as N0Hum (to ensure that the subject of the frozen expression is a Human noun phrase), could be added to enhance the precision of the description.

(3) The associated grammar must describe the context in which the frozen expression occurs. It includes the characteristic component, as well as the other components of the expression. Matching the grammar validates the frozen expression, and its output is usually used to annotate the expression.

For instance, the following grammar can be associated with the dictionary above to recognize occurrences of the frozen expression “to take ... into account”.

Figure 31. A generic Syntactic Grammar

The compound variable $V$PP (in red) links the verb recognized by <V> with the value of its PP field value. In other words, when the grammar is activated by take (which has the field +PP=“into account”), the grammar behaves exactly as the following one:

Figure 32. Instalation of a generic syntactic grammar

The advantage of the generic grammar is that it needs to be written only once, even if the corresponding dictionary has thousands of lexical entries.

In order to link a dictionary and its corresponding grammar, just give them the same name, and store them in the Lexical Analysis folder. For instance, the French Lexical Analysis module contains a pair of files C1D.nod, C1D.nog that formalize over 1,600 frozen expressions like “perdre le nord” (= to lose it). This

Figure 33. Frozen expression Formalized in a pair Dictionary / Grammar

NooJ’s C1D pair of dictionary, grammar formalizes Maurice Gross’s C1D lexicon-grammar table.

Chapter 15. Rules Of Grammars' Application

NooJ’s syntactic parser follows a set of rules.

15.1. A Grammar Cannot Recognize An Empty Node

NooJ’s syntactic parser cannot apply grammars that recognize the empty string. For instance, consider the following grammar:

Figure 34. Graph recognizing the empty string

This graph recognizes and annotates a few determiners, including the empty determiner that can be found in the following text:

Birds have wings

Unfortunately, one cannot directly apply this grammar to a text: doing so would request NooJ to insert an infinite number of <DET> annotations at every position in the text!

If you try to apply to a text a grammar that recognizes the empty string, NooJ will recognize the problem, will warn you and then abort.

In Syntax as well as in Morphology, there are a number of cases in which it is important to describe sequences of grammatical words that are implicit; for instance, the sequence “who is” can arguably be seen as implicit in the noun phrase “John, late as usual”.

NooJ provides ways to formalize empty strings, i.e. to associate them with linguistic information: even though a grammar cannot recognize the empty string, it can contain an embedded graph that recognizes the empty string. In the previous example, we could include the DET0 graph in a more general NP (“noun phrase”) grammar, as long as the NP grammar itself does not recognize the empty string. We will also see how that implicit words or sequences can be formalized as “default values” for grammar variables (see below).

15.2. Ambiguity

When NooJ’s parser produces more than one analysis for a particular sequence, the sequence is said to be ambiguous. For example, consider the following grammar, which annotates “this” or “that” as pronouns if they are followed by a verb, and as determiners if they are followed by a noun.


Figure 35. An Ambiguous Grammar

But what happens if the following word is ambiguous (noun or verb), such as “rose” in:

... this rose yesterday (rose = to rise,V) ...

... this rose is beautiful (rose = N) ...

In that case, NooJ produces both results, i.e. two lines in the concordance:

Figure 36. An ambiguous annotation

Now, if the user chooses to insert the annotations into the Text Annotation Structure (CONCORDANCE > Annotate Text), we get both annotations:

Figure 37. An ambiguous annotation

In general, NooJ cannot detect such contradictory commands. It is your responsibility to verify that your grammar, regardless of the degree of complexity, does not associate different annotations for one given sequence (except of course if the sequence is genuinely ambiguous!).

15.3. Ambiguous Matches With Different Lenghts

A given grammar could potentially recognize more than one sequence at one position, and then associate each sequence with a different annotation. For instance, consider the following query, entered as a regular expression:

<be> <WF>* <N>

If entered in the Locate panel, this expression will locate in texts all the sequences constitued of a conjugated form of the verb to be, followed by any number of word forms (including 0), followed by a noun, e.g. “was admitted in a hospital”.

The symbol <WF> recognizes any word form, including nouns. So what happens if there are several nouns in a given text unit, such as in:

(T) ... there are few hours in life more agreeable than the hour dedicated to the ceremony known as afternoon tea . There are circumstances...

15.4. Shortest/Longest/All matches

In the Locate panel, the user can choose one of the three following options:

Figure 38. Grammars' application options

These options decide what sequences NooJ should take into account in case of ambiguities, i.e. what sequences will show up in the Concordance.

Index Shortest matches

This option tells NooJ to stop as soon as it gets a match. Therefore, the concordance for text (t) will show the shortest sequence:

... there are few hours in life more agreeable...

In that case, it is as if <WF> meant “any word form but a noun”.

Index Longest matches

This option tells NooJ to keep going as far as possible, and produce only the longest sequence possible. Therefore, the concordance for text (t) will show:

... there are few hours in life more agreeable than the hour dedicated to the ceremony known as afternoon tea . There are circumstances...

Note that it is important to keep text units small; if the text was opened as one single text unit, a query such as this one could produce a sequence of hundreds of pages!

Index All matches

This option tells NooJ to produce all possible matches. Therefore, the concordance for text (t) will display five entries:

... there are few hours in life more agreeable than the hour dedicated to the ceremony known as afternoon tea. There are circumstances...

... there are few hours in life more agreeable than the hour dedicated to the ceremony known as afternoon tea. There are circumstances...

... there are few hours in life more agreeable than the hour dedicated to the ceremony known as afternoon tea. There are circumstances...

... there are few hours in life more agreeable than the hour dedicated to the ceremony known as afternoon tea. There are circumstances...

... there are few hours in life more agreeable than the hour dedicated to the ceremony known as afternoon tea . There are circumstances...

15.5. Ambiguity And The Insersation Of Annotations

Consider the following grammar:

Figure 39. An ambiguous Grammar

This grammar recognizes sequences such as “the table” by following the direct path <DET> <N>, “the red table” (through <DET> <A> <N>), “the American imports exports companies” (through <DET> <A> <N> <N> <N>), etc. Recognized sequences are annotated as NP.

Now, more specifically: what happens exactly when the sequence “The American imports exports companies” is parsed? Note that “American” can be an Adjective or a Noun, “imports” and “exports” can be nouns or verbs, and “companies” is a noun. Therefore, the grammar above recognizes actually four sequences:

(a) The American

(b) The American imports

(c) The American imports exports

(d) The American imports exports companies

As for regular expressions queries, the Locate panel provides the three options:

Figure 40. Grammars' application options

These options decide what sequences NooJ should take into account, and therefore what annotation will be inserted in the TAS.

Index Shortest matches

In that case, NooJ’s parser stops as soon as it has found a match. In our example, when NooJ reads “The American”, it considers it a match thanks to the path <DET> <N>, and then simply ignores all the other matches. In other words, the resulting concordance will only contain the first sequence (a): “The American”. If the user decides to insert the concordance’s annotations in the Text Annotation Structure ( CONCORDANCE > Annotate Text), the resulting TAS will include only one NP annotation:

Figure 41. The shortest match

Note that even if the option “Index Shortest Matches” is selected, it is still possible that there are more than one “shortest sequence”, associated with different annotations. In that case, NooJ will annotate all solutions.

Index Longest matches

In that case, NooJ’s parser returns only the longest matches, and simply forgets the shorter ones. In our example, NooJ recognizes “The American import export company” thanks to the path <DET> <A> <N> <N> <N>, and ignores all the shorter matches. The resulting concordance will only contain the last sequence (d): “The American import export company”; the resulting annotated text will contain only the longest annotation:

figure 42. The longest match

Note that even if the option “Index Longest Matches” is selected, it is still possible that there are more than one “longest sequence”, associated with different annotations. In that case, NooJ will annotate all solutions.

Index All matches

In that case, NooJ’s parser returns all matches, in our example: four results. The resulting concordance will contain the four lines (a), (b), (c) and (d). If we ask NooJ to insert the new annotations in the text ( CONCORDANCE > Annotate Text), we get the following TAS:

Figure 43. An ambiguous NP

15.6. Overlapping Matches

More complex cases of ambiguity may occur. Consider for instance the following grammar, that can be entered as a simple regular expression query in the Locate panel:

<N> <N> <N>*

In our previous text, this grammar would recognize the six following sequences:

American imports

American imports exports

American imports exports companies

imports exports

imports exports companies

exports companies

If the option “Index All matches” is selected, NooJ will produce the six sequences above. If the option “Index Longest matches” is selected, NooJ will produce only the longest: “American imports exports companies”.

But if the option “Intex shortest matches” is selected, NooJ will produce only the two following results:

American imports

exports companies

The sequence “imports exports” is not even considered, because after NooJ has matched the sequence “American imports”, it simply goes to the right of the matching sequence and continues its parsing.


NooJ produces overlapping matches (and the resulting annotations) only when the option “Index All matches” is selected. With all other options, after NooJ’s parser has matched a given sequence (shortest or longest), it simply goes beyond the sequence before applying the grammar again.

15.7 Setting modes For GrammarsThat Are Automatically Applied

The user can select grammars in Info > Preferences > Syntactic Analysis. In that case, NooJ applies them automatically every time the command TEXT > Linguistic Analysis is launched, right after the selected lexical resources.

Each grammar can be applied in sequence; this allows one grammar to insert annotations in the TAS, which will be re-used in turn by other subsequent grammars. For instance, consider the following text:

... from Monday to Thursday ...

a Date grammar could be used to annotate the word forms “Monday” and “Tuesday” as DATE; then a Duration grammar could be used to annotate seqences such as “from <DATE> to <DATE>” as DURATION.

By default, each grammar is applied with the “Longest Match” option; thus, in case of ambiguity, only the longest possible sequences will be annotated. It is possible to override this mode, and tell NooJ to apply a certain grammar in a specific mode. In order to do that, we use a special file name convention. If the suffix of the grammar name is:

-A (e.g. filename: DET-A.nog): the grammar will be applied in “All Matches” mode. In other words, in case of ambiguities, the grammar will annotate all matching sequences;

-S (e.g. filename: NP-S.nog): the grammar will be applied in “Only Shortest Matches” mode. In other words, in case of ambiguities, the grammar will annotate only the shortest sequences; -L : (e.g. filename: Date-L.nog or Date.nog) the grammar will be applied in “Only Longest Matches” mode. In other words, in case of ambiguities, the grammar will annotate only the longest sequences.

15.8. Special Feature +UNAMB

The special feature +UNAMB -- already seen in Chapter 12. can be used also by NooJ’s syntactic parser. For instance, the following syntactic grammar:

Figure 44. A Syntactic Grammar For USA

recognizes both “United States” and “United States of America”. If the longest sequence is recognized, we do not want to parse it as ambiguous. Thus, we add the special feature +UNAMB to the annotation by the grammar.

15.9 Special Symbol <ONCE>

The special symbol <ONCE> is used whenever we want to stop NooJ from following a given path more than once. For instance, in English, date complements are quite moveable in a sentence:

Yesterday John saw a duck. ? John yesterday saw a duck. John saw a duck yesterday.

In consequence, a syntactic grammar that describes full sentences will have to make provisiong for date complements pretty much between every phrase of the sentences. However, it is not possible to have more than one date complement at the same time:

* Yesterday John saw a duck this morning.

In order to stop the parser from getting more than one date complement, we can use the <ONCE> special symbol:

Figure 45.One date complement, anywhere

It is possible to use more than one <ONCE> constraint at the same time, for instance if we want to have only one date complement, one location complement, etc. In that case, we need to name each constraint: <ONCE-DATE>, <ONCE-LOC>, etc.

The special symbol <ONCE> is particularly useful when parsing languages in which words or phrases can occur in any order. For instance, the following grammar could be used to parse some sentences in Latin:

Figure 46. Free noun phrase order

This grammar makes sure that in the resulting analysis, there will be at most one nominative noun phrase, one accusative noun phrase, one dative noun phrase and one verb.

Moreoever, this mechanism automatically removes certain ambiguities, such as between nominative and dative nouns: if we know that a certain noun is obligatorily in its nominative form, then all other (possibly ambiguous) nouns will automatically be described as being not nominative.

Chapter 16. Beyond Finite-State Machines

Most grammars we have seen are equivalent to finite-state devices. Although some of them contain several graphs that include references to embedded graphs, such as the Roman Numeral or the Date grammars, these grammars can be rewritten (or even compiled automatically) into a single, finite-state graph, just by replacing each reference to embedded graphs by the graphs themselves. We now consider more powerful tools that can be used to compute the structure of sentences, to compute paraphrases (i.e. to perform transformations on texts), or to perform machine translation.

16.1. Context-Free Grammars

Consider the following grammar:

Figure 47. Example of a recursive grammar

In this grammar, the main graph “Main” contains a reference to itself. This graph recognizes the following sequence:

a b

as well as the sequence:

a a b b

NooJ’s parser matches the first “a”, then it recognizes the sequence “a b” thanks to the call to Main in the upper path of the graph; then “b”: then, it reaches the terminal node, so the whole sequence is recognized. We can, in the same manner, identify an infinite number of sequences such as:

a a a b b b

a a a a b b b b

a a a a a b b b b b

...

More generally, this grammar recognizes any sequence composed of a given number of “a”, followed by the same number of “b”.

It is not possible to “flatten” this grammar into a single graph simply by replacing each reference of an embedded graph by the graph itself. This grammar is said to be a recursive grammar. Recursive grammars are also called “C ontext-Free Grammars”, Chomsky’s grammars, or Algebraic grammars.

When, in a grammar, a graph contains a reference to itself (as is the case of the graph Main), we say that it is directly recursive. Certain grammars are indirectly recursive when for example they contain a graph A which contains a reference to a graph B, which itself contains a reference to graph A.

There are three types of direct or indirect recursion: head recursion, tail recursion and middle recursion:

Grammars with head recursion

A head recursion means that the recursion is occurring at the left part of the grammar. In other words, the prefix of the grammar contains a direct or indirect recursive call. Consider the following recursive grammar:

Figure 48.A Grammar with Head Recursion

This grammar represents English noun phrases made up of a determiner, a noun, an optional modifier to the right, as well as noun phrases followed by an “’s” (indicator of the genitive case) and a noun, such as:

the neighbour

the neighbour’s friend

the neighbour’s friend’s table

This grammar is said to be head-recursive because the reference to the graph Main occurs to the left of the graph Main.

Head recursions may be automatically removed from a grammar. For example, the grammar RecNP above is equivalent to the following grammar NP2:

Figure 49. Equivalent Grammar,non head recurring

Note: a distributional constraint is not taken into account here: the noun phrase before the “‘s” must be human ( +Hum), while the entire noun phrase is not necessarily human. Therefore, writing a recursive call to Main is not correct, and should be replaced with a reference to a different graph that recognizes only human noun phrases. This distributional constraint weakens the argument that we need head-recursive grammars to formalize the English syntax.

Grammars with tail recursion

Consider the following grammar:

Figure 50.A Grammar with Tail Recursion

This grammar recognizes sequences like the following:

John thinks that Mary said that Peter knows that Lisa declared that Luc is fair

This grammar is indirectly tail-recursive, because the Main graph contains a reference to graph NP1, which itself contains a reference to the Main graph to its right.

There as well, the tail recursion can automatically be removed. For example, the previous grammar Sentence is equivalent to the following grammar Sentence2, which is a finite-state grammar:

Figure 51. An equivalent finite-state Grammar

Note: Here too, there are linguistic constraints that are not taken into account here: each verb needs to be compatible with its corresponding complement NP1. Verbs that accept an adjective as complement (such as in “to be fair”) should not be processed the same way as verbs that require a sentencial complement (such as “to say that S”). These constraints weaken the argument that we actually need tail-recursive grammars to formalize the English syntax.

Grammars with middle recursion

Contrary to the preceding cases, grammars with a more general recursivity (neither head nor tail), as in the following grammar, are strictly Context-Free, as an equivalent non-recursive grammar cannot be constructed:

This grammar takes into account relative clauses which may occur to the right of the subject, as for example:

(1) The cat John bought is white
(2) ? The cat that the neighbour the waiter saw bought is white

It is fairly easy to see that this grammar is a very inadequate description of the syntactic phenomenon that we observe in English. Sentence (2) is already hard to accept, and a further embedded clause would make it unacceptable:

(3) * The cat that the neighbour the waiter you saw is looking at bought is white

Moreover, the embedded relative clauses are not complete sentences, as the following impossible construction shows:

* The cat John bought a dog is white

The relative clause cannot contain a direct object. More precisely, the graph to the right of the relative pronoun should not be Main, but rather a different graph that represents incomplete sentences, the structure of which depends on the relative pronoun in question.

It is interesting to note that other languages rarely authorize this type of insertions for more than three levels, as we can see in the following French examples:

Le chat dont tu m’as parlé a faim

? le chat que le voisin dont tu m’as parlé a volé a faim

?* le chat que le voisin dont l’enfant ne travaille plus a volé a faim

* le chat que le voisin dont la femme avec qui Luc a travaillé est partie a volé a faim

It appears then, except maybe for some type of tail-recursivity, that natural languages are far less recursive than is generally held.

16.2. Enchanced Grammars

Enhanced Grammars are grammars that use internal variables to store parts (affixes) of the recognized sequences, and then use their content in the output, as constraints for the syntactic parser or in order to construct the result of the analysis. This functionality is similar to the way variables are used in programs like SED and PERL. Note that we have already used variables in NooJ’s morphological grammars.

In a grammar’s output, variable names must be prefixed with the character “$”, and must end either with a space, or with the special character “#” when one does not wish to add a space after a variable’s content. For instance, the output: “$Verb ($Name )” is a valid output that contains references to the two variables $Verb and $Noun, and might produce the text “sleep (John )” (with two spaces); similarly, “$Verb#($Name#)” is a valid output that would produce “sleep(John)” (without spaces), whereas “$Verb($Noun)” is an invalid output that will produce the error message “Variable “$Verb(” is undefined”.

Performing transformations

We give now examples of syntactic applications. For example, consider the following grammar:

Figure 52. Moving the adverb out of the Verb Group

This grammar could be used to extract the adverbial insertions from the Verb Group, and thus to tag compound tenses and verb constructs as single words. For instance, the sequence “have not yet eaten” could then be annotated as:

<have eaten,eat,V+PresentPerfect> <not yet,ADV>

To store an affix into a variable, create a node labeled “$(” followed by the variable’s name before the text to be recognized, and a node labeled “$)” after the text.

If we apply this grammar to the following text:

My mother has thoroughly mastered the art of condensation

The sequence “has thoroughly mastered” is recognized, and the variables $Aux, $Adv and $Vpp are associated to the respective values:

$Aux = “has” ; $Adv = “thoroughly” ; $Vpp = “mastered

The result produced by the grammar is then: has mastered thoroughly. If we apply the grammar to the text “The portrait of a lady”, we get the following concordance:

Figure 53. Moving the adverb out of the Verb Group

Set Variables’ Value

It is possible to set variables to specific values that are different from the text sequence that was matched by the grammar. In order to do that, enter the variable’s value after the variable’s closing parenthesis. See for instance the values “M” and “F” in the following grammar:

Figure 54. Setting a variable's value

When matching a sequence, the variable $Sex is set to either “M” or “F”, rather than “man” or “woman”. Applying this grammar to a text produces the following concordance:

Figure 55. Setting a variable's value

This feature allows users to set values to annotations’ properties, that are different from the input text. This can be used to produce abstract representations of the text, such as XML-type or PROLOG-type semantic representations. For instance, the sentence “One woman aged 25 had fever symptom” could be analyzed as:

Agent (Sex(F), Age(25), Symptom(fever))

or annotated as:

<AGENT+Sex=F+Age=25+Symptom=fever> ... </AGENT>

Remember to use the special character “#” at the end of the variable’s name. For instance, if $Sex holds the value “M” and $Age holds the value “25”, “+Sex=$Sex#+Age=$Age#” will produce “+Sex=M+Age=25”, whereas “+Sex=$Sex+Age=$Age” will produce the error message “Variable “$Sex+Age=$Age” is undefined”.

Even at the surface level, it is often useful to be able to render explicit an expression that was either modified or deleted in the original text. For instance, in the following grammar:

Figure 56. Computing Vsup

the value of variable $Vsup is either read explicitely from the text (e.g. to “become” in “the company known to become richer”), or is set to “is” if no verb is present (e.g. in “the company, richer”).

Morphological operations on variables

Variables’ content can be processed with NooJ’s morphological engine, if the dictionaries NooJ is currently using (i.e. selected in Info > Preferences > Lexical Analysis) are providing the corresponding information. For instance, if one of the currently selected lexical resources contains an entry such as:

eat,V+FLX=EAT+tr+...

where the paradigm +FLX=EAT allows NooJ to recognize the word form “eaten” as a valid inflected form for “eat”, then NooJ can lemmatize “eaten” into “eat”.

Lemmatization operator: in order to lemmatize the content of a variable, use the operator “_” (underline character) to the right of the variable’s name.

For instance, “$V_” takes the content of variable $V, e.g. “ate”, and then lemmatizes it into “eat”.

Similarly, if the conjugation paradigm for the verb“eat” associates the inflectional code “+PP” for its Past Participle form “eaten”, then the expression “$V_PP” will produce the word form “eaten” from any other word form of “eat”.

Remember to use the special character “#” at the end of the variable’s name when composing a grammar’s complex output. For instance, if $V holds the value “distributes”, “$V_” will produce “distribute”, whereas “$V#_” will produce “distribute_”.

Inflection: in order to inflect the content of a variable, use the operator “_” (underline character) followed by one or more inflectional codes that characterize the resulting inflected form.

Another example: the expression “$N_p” takes the content of variable $N, e.g. “woman”, then inflects it in the plural, e.g. “women”; the expression “$V_PR+3+s” takes the content of variable $V, e.g. “ate”, and then inflects it to Present, third person, singular, e.g. “eats”.

Derivational operations on variables

Variables’ content can be processed also with NooJ’s derivational morphological engine, if the dictionaries NooJ is currently using (i.e. selected in Info > Preferences > Lexical Analysis) are providing the corresponding information. For instance, if one of the currently selected lexical resources contains an entry such as:

distribute,V+DRV=TION+...

where the paradigm +DRV=TION links the lexical entry “distribute” to the derived form “distribution”, then one can nominalize “distribute” into “distribution” by using the expression “$V_N”.

Derivation: in order to derive the content of a variable, use the operator “_” (underline character) followed by a category and one or more inflectional codes, to the right of the variable’s name.

A derivation operator can be followed by an inflection operator. For instance, “$V_N+p” takes the content of variable $V, e.g. “distributed”, then nominalizes it (e.g. “distribution”), and computes the plural form of the result, e.g. “distributions”.

Extracting Variables’ Lexical Properties

NooJ can retrieve and extract values of a property that is associated with the variable’s content. For instance, if one of the currently selected lexical resources contains an entry such as:

pen,N+Class=Conc+...

then NooJ can extract the value “Conc” from the lexical entry’s property name “Class”.

Property: in order to extract the value of a variable’s property, use the name of the property to the right of the variable’s name.

For instance, if the variable $Noun holds the lexical entry for “pen”, then the output $Noun$Class will produce the text “Conc”.

Remember to use the special character “#” at the end of the compound variable’s name. For instance, $Noun$Class refers to the property “Class” of the variable “$Noun”, whereas $Noun#$Class will concatenate the content of the two different variables $Noun and $Class.

Of course, retrieving a lexical entry’s property value requires that the lexical property be expressed in terms of a attribute-value pair, such as in the previous example: +Class=Conc. But NooJ lexical properties can also be expressed as single features such as “+Present”, “+Hum” or “+s”, as in:

teacher,N+Hum+s

In order to extract simple features from a lexical entry, we need to use NooJ’s “properties.def” property definition file. For example, consider the following definitions stored in a “properties.def” definition file:

N_Class = Hum + Conc + Anim + Abst ;

N_Nb = s + p ;

These definitions state that “Class” is valid property for category “N” (Nouns); it can take one of the following values: Hum, Conc, Anim and Abst. “Nb” is a valid property for Nouns; it can take the two values “s” (singular) or “p” (plural).

If these two rules are written in the current “properties.def” file, then the previous lexical entry is exactly equivalent to the following one:

teacher,N+Class=Hum+Nb=s

Then, it is possible to access the features “Hum” and “s” by using variables’ property queries such as $N$Class or $N$Nb.

16.3. Lexical And Agreement Constaints

Just like morphological grammars, syntactic grammars can contain lexical and agreement constraints. Constraints allow grammar writers to separate the “constituent” part of a grammar from the “agreement” constraints, thus simplifying grammars considerably. For instance, when describing French noun phrases, one can write a simple grammar such as:

<DET> <N> <A>

and associate it with the two following agreement constraints:

<$DET$Nb=$N$Nb>, <$A$Nb=$N$Nb>

16.4. Applications

Transformational Analysis

Being able to use variables and to perform morphological operations on them allows us to perform the four basic transformation operations:

-- delete elements: for example, the substitution: $1 $2 $3 / $1 $3 allows us to erase the sequence stored in variable $2 in the left context of $1 and in the right context of $3.

This feature is useful when erasing certain grammatical words, such as in:

The table that John bought = The table John bought

-- insert elements: for example, the substitution: $1 $2 / $1 XXX $2 allows us to insert the text XXX between sequences $1 and $2.

This feature can be used to analyze certain types of support verb deletions; for instance, the sentence “the red table” can be automatically linked to “the table which is red”, where the verb “is” is made explicit.

-- dupplications: for example, the substitution : $1 $2 $3 $4/ $1 $2 $3 $2 $4 allows us to copy the sequence $2 to two different locations in the text.

This feature can be used to analyze certain types of coordinations; for instance, the sentence “The red tables and chairs” can be automatically linked to “The red tables and the red chairs”, where the modifyer “red” is duplicated.

-- permutations: for example, the substitution : $1 $2 $3 $4 $5 / $1 $4 $3 $2 $5 allows us to swap the respective positions of $2 and $4.

This feature can be used to perform sentences’ transformations. For instance, the sentence “John ate 3 apples” can be automatically linked to “3 apples were eaten by John”, where the subject “John” and the object “3 apples” are permuted, and the verb “ate” is replaced with “were eaten” thanks to the output “were $V_PP”.

The use of such transducers in sequence gives NooJ the power of a Turing machine, and makes it a unique tool to perform automatic transformational analyses of texts.

Semantic Analyses

NooJ grammars can be used to recognize certain sequences and produce a corresponding semantic analysis, expressed in any formalism, including XML or PROLOG-like predicate-argument constructions.

For instance, consider the following grammar:

Figure 57. A Prolog Semantic Analysis

This grammar recognizes sequences such as:

John sees Mary

and then, produces the corresponding PROLOG-like analysis:

PRED=see (John,Mary)

Of course, the formalism used to format the output is totally open. For instance, the previous grammar can be rewritten to produce an XML-like analysis:

Figure 58. An XML Semantic Analysis

In that case, the same sequence “John sees Mary” will be assocated with the output:

<PRED F=see ARG1=John ARG2=Mary>

Machine Translation using multilingual dictionaries and grammars

NooJ dictionaries are associated with one single input language (the one that has to be specified when creating a new dictionary via the command File > New Dictionary). All lexical entries of the dictionary must belong to this language.

However, lexical entries can be associated with properties which can hold values in other languages than the dictionary’s. For instance, consider the following English lexical entry:

pen,N+Conc+FR=”crayon”+IT=”penna”+SP=”pluma”

The properties’ names “FR”, “IT” and “SP” refer to language names. Therefore, if a grammar variable, say $Noun, holds the value “pen”, the output $Noun$FR will produce the text “crayon”.

Now consider the following dictionary entries:

Monday,N+FR=lundi

Tuesday,N+FR=mardi

Wednesday,N+FR=mercredi

Thursday,N+FR=jeudi

Friday,N+FR=vendredi

Saturday,N+FR=samedi

Sunday,N+FR=dimanche

and the following grammar:

Figure 59. A simple translation

The output “$Dname$FR $DNb” takes the name of the day, translates it into French, and then adds to it the date number. For instance, “Friday, the 13th” and “Friday 13th” will be translated into “lundi 13”.

Exporting results and the TRANS operator.

Topic attachments
I Attachment Action Size Date Who Comment
JPEGjpg pic_0.jpg manage 24.3 K 2009-08-13 - 21:03 UnknownUser  
JPEGjpg pic_1.jpg manage 6.5 K 2009-08-13 - 21:03 UnknownUser  
JPEGjpg pic_10.jpg manage 27.2 K 2009-08-13 - 21:04 UnknownUser  
JPEGjpg pic_11.jpg manage 34.2 K 2009-08-13 - 21:40 UnknownUser  
JPEGjpg pic_12.jpg manage 27.9 K 2009-08-13 - 21:40 UnknownUser  
JPEGjpg pic_13.jpg manage 27.3 K 2009-08-13 - 21:40 UnknownUser  
JPEGjpg pic_14.jpg manage 36.2 K 2009-08-13 - 21:40 UnknownUser  
JPEGjpg pic_15.jpg manage 33.7 K 2009-08-13 - 21:40 UnknownUser  
JPEGjpg pic_16.jpg manage 21.2 K 2009-08-13 - 21:40 UnknownUser  
JPEGjpg pic_17.jpg manage 37.7 K 2009-08-13 - 21:40 UnknownUser  
JPEGjpg pic_18.jpg manage 20.1 K 2009-08-13 - 21:40 UnknownUser  
JPEGjpg pic_19.jpg manage 32.2 K 2009-08-13 - 21:40 UnknownUser  
JPEGjpg pic_2.jpg manage 33.3 K 2009-08-13 - 21:03 UnknownUser  
JPEGjpg pic_20.jpg manage 53.8 K 2009-08-13 - 21:41 UnknownUser  
PNGpng pic_21.png manage 39.5 K 2009-08-13 - 21:41 UnknownUser  
JPEGjpg pic_22.jpg manage 5.0 K 2009-08-13 - 21:41 UnknownUser  
PNGpng pic_23.png manage 50.0 K 2009-08-13 - 21:41 UnknownUser  
JPEGjpg pic_24.jpg manage 21.4 K 2009-08-13 - 21:41 UnknownUser  
JPEGjpg pic_25.jpg manage 28.7 K 2009-08-13 - 21:41 UnknownUser  
JPEGjpg pic_26.jpg manage 19.7 K 2009-08-13 - 21:41 UnknownUser  
JPEGjpg pic_27.jpg manage 26.9 K 2009-08-13 - 21:41 UnknownUser  
JPEGjpg pic_28.jpg manage 23.8 K 2009-08-13 - 21:41 UnknownUser  
JPEGjpg pic_29.jpg manage 28.6 K 2009-08-13 - 21:41 UnknownUser  
JPEGjpg pic_3.jpg manage 23.5 K 2009-08-13 - 21:03 UnknownUser  
JPEGjpg pic_30.jpg manage 25.3 K 2009-08-13 - 21:41 UnknownUser  
JPEGjpg pic_31.jpg manage 20.8 K 2009-08-13 - 21:42 UnknownUser  
JPEGjpg pic_32.jpg manage 26.8 K 2009-08-13 - 21:43 UnknownUser  
JPEGjpg pic_33.jpg manage 19.4 K 2009-08-13 - 21:43 UnknownUser  
JPEGjpg pic_34.jpg manage 16.9 K 2009-08-13 - 21:43 UnknownUser  
JPEGjpg pic_35.jpg manage 16.4 K 2009-08-13 - 21:43 UnknownUser  
JPEGjpg pic_36.jpg manage 32.7 K 2009-08-13 - 21:43 UnknownUser  
JPEGjpg pic_37.jpg manage 33.3 K 2009-08-13 - 21:43 UnknownUser  
JPEGjpg pic_38.jpg manage 18.0 K 2009-08-13 - 21:43 UnknownUser  
JPEGjpg pic_39.jpg manage 39.9 K 2009-08-13 - 21:43 UnknownUser  
JPEGjpg pic_4.jpg manage 20.9 K 2009-08-13 - 21:03 UnknownUser  
JPEGjpg pic_40.jpg manage 44.2 K 2009-08-13 - 21:43 UnknownUser  
JPEGjpg pic_41.jpg manage 16.9 K 2009-08-13 - 21:43 UnknownUser  
JPEGjpg pic_42.jpg manage 20.3 K 2009-08-13 - 21:44 UnknownUser  
JPEGjpg pic_43.jpg manage 16.8 K 2009-08-13 - 21:44 UnknownUser  
JPEGjpg pic_44.jpg manage 41.6 K 2009-08-13 - 21:44 UnknownUser  
JPEGjpg pic_45.jpg manage 40.5 K 2009-08-13 - 21:44 UnknownUser  
JPEGjpg pic_46.jpg manage 39.4 K 2009-08-13 - 21:44 UnknownUser  
JPEGjpg pic_47.jpg manage 25.0 K 2009-08-13 - 21:44 UnknownUser  
JPEGjpg pic_48.jpg manage 16.7 K 2009-08-13 - 21:44 UnknownUser  
JPEGjpg pic_49.jpg manage 35.1 K 2009-08-13 - 21:44 UnknownUser  
JPEGjpg pic_5.jpg manage 23.4 K 2009-08-13 - 21:04 UnknownUser  
JPEGjpg pic_50.jpg manage 20.4 K 2009-08-13 - 21:44 UnknownUser  
JPEGjpg pic_51.jpg manage 25.4 K 2009-08-13 - 21:45 UnknownUser  
JPEGjpg pic_52.jpg manage 21.6 K 2009-08-13 - 21:46 UnknownUser  
JPEGjpg pic_53.jpg manage 13.7 K 2009-08-13 - 21:46 UnknownUser  
JPEGjpg pic_54.jpg manage 14.6 K 2009-08-13 - 21:47 UnknownUser  
JPEGjpg pic_55.jpg manage 14.8 K 2009-08-13 - 21:47 UnknownUser  
JPEGjpg pic_56.jpg manage 21.2 K 2009-08-13 - 21:47 UnknownUser  
JPEGjpg pic_57.jpg manage 14.8 K 2009-08-13 - 21:47 UnknownUser  
JPEGjpg pic_58.jpg manage 33.2 K 2009-08-13 - 21:47 UnknownUser  
JPEGjpg pic_59.jpg manage 16.3 K 2009-08-13 - 21:47 UnknownUser  
JPEGjpg pic_6.jpg manage 36.1 K 2009-08-13 - 21:04 UnknownUser  
JPEGjpg pic_60.jpg manage 41.3 K 2009-08-13 - 21:49 UnknownUser  
JPEGjpg pic_61.jpg manage 15.7 K 2009-08-13 - 21:48 UnknownUser  
JPEGjpg pic_62.jpg manage 18.7 K 2009-08-13 - 21:48 UnknownUser  
JPEGjpg pic_63.jpg manage 16.7 K 2009-08-13 - 21:48 UnknownUser  
JPEGjpg pic_64.jpg manage 21.7 K 2009-08-13 - 21:48 UnknownUser  
PNGpng pic_7.png manage 33.3 K 2009-08-13 - 21:04 UnknownUser  
JPEGjpg pic_8.jpg manage 35.4 K 2009-08-13 - 21:04 UnknownUser  
JPEGjpg pic_9.jpg manage 37.7 K 2009-08-13 - 21:04 UnknownUser  
Topic revision: r4 - 2009-08-14 - MaxSilberztein
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback