Commit b996afef authored by Bruno Guillaume's avatar Bruno Guillaume

build with Makefile when possible

parent e5e9b473
selfdoc:
@echo " * make run --> run locally the server"
@echo " * make run --> run locally the server"
@echo " * make talc2 --> install on the production server"
@echo " * make build --> build the website "
run:
hugo server -w &
open -a firefox -g http://localhost:1313/
talc2:
build:
@make -C static/parsing run
@make -C static/parsing img
@make -C static/deep_syntax run
@make -C static/deep_syntax img
hugo
talc2:
#tar cf - public | ssh $(stalc2)/www/grew_doc tar xf -
scp -r public/* $(stalc2)/www/grew_doc/
purge:
@make -C static/parsing purge
@make -C static/deep_syntax purge
......@@ -9,58 +9,40 @@ menu = "main"
# Deep syntax
The goal of the deep syntax is to give a linguistic description of the input sentence which is closer to a semantic representation.
The goal of the deep syntax is to give a linguistic description of sentences which is closer to a semantic representation.
More information about deep syntax can be found on the [Deep-sequoia project](http://deep-sequoia.inria.fr).
For the sentence:
- "*La souris a été mangée par le chat.*" ["*The mouse was eaten by the cat.*"].
the deep structure is: ![Deep dependency structure](/img/test.deep.svg)
the deep structure is: ![Deep dependency structure](/deep_syntax/test.deep.svg)
With __grew__, this representation can be computed from the surface syntax in two steps:
With **Grew**, this representation can be computed from the surface syntax in two steps:
1. A general representation (called __mixed__) encodes both surface and deep syntax in the same structure.
2. A projection from the __mixed__ to the __deep__ structure
1. A general representation (called **deep_and_surf**) encodes both surface and deep syntax in the same structure.
2. A projection from the **deep_and_surf** to the **deep** structure
## Building the mixed structure
The GRS used to build __mixed__ structure can be obtained from InriaGForge by:
The GRS used to build the mixed **deep_and_surf** structure can be obtained by:
```
svn co svn://scm.gforge.inria.fr/svn/semagramme/grew_resources/deep_syntax
git clone https://gitlab.inria.fr/grew/SSQtoDSQ.git
```
The input of the GRS which produced the __mixed__ structure is the __surface__ structure.
We recall here the surface structure (see [Dependency parsing](../parsing) page) for our example sentence and we suppose that the file `test.surf.conll` contains the conll description below:
The input of the GRS which produced the **deep_and_surf** structure is the **surf** structure.
We recall here the surface structure (see [Dependency parsing](../parsing) page) for our example sentence and we suppose that the file [`test.surf.melt`](/deep_syntax/test.surf.melt) contains the Conll description below:
```
1 La le D DET sentid=00000 2 det _ _
2 souris souris N NC det=y|s=c 5 suj _ _
3 a avoir V V m=ind 5 aux.tps _ _
4 été être V VPP m=pastp 5 aux.pass _ _
5 mangée manger V VPP diat=passif|m=pastp _ _ _ _
6 par par P P _ 5 p_obj.agt _ _
7 le le D DET _ 8 det _ _
8 chat chat N NC det=y|s=c 6 obj.p _ _
9 . . PONCT PONCT _ 5 ponct _ _
```
{{< input file="/static/deep_syntax/test.surf.conll" >}}
The mixed structure is then computed with the command:
```
grew -det -grs deep_syntax/grs/deep_synt_main.grs -i test.surf.conll -f test.mix.conll
```
which produces the file `test.mix.conll` which contains the code below corresponding the next figure
```
1 La le D DET sentid=00000 2 det _ _
2 souris souris N NC det=y|s=c 5 suj:obj _ _
3 a avoir V V dl=avoir|m=ind|void=y 5 S:aux.tps _ _
4 été être V VPP dl=être|m=part|t=past|void=y 5 S:aux.pass _ _
5 mangée manger V VPP diat=passif|dl=manger|dm=ind|m=part|t=past _ _ _ _
6 par par P P void=y 5 S:p_obj.agt:suj _ _
7 le le D DET _ 8 det _ _
8 chat chat N NC det=y|s=c 6|5 S:obj.p|D:p_obj.agt:suj _ _
9 . . PONCT PONCT _ 5 ponct _ _
```
![Mixed dependency structure](/img/test.mix.svg)
which produces the file [`test.deep_and_surf.melt`](/deep_syntax/test.deep_and_surf.melt) which contains the code below corresponding the next figure
{{< input file="/static/deep_syntax/test.deep_and_surf.conll" >}}
![Mixed dependency structure](/deep_syntax/test.deep_and_surf.svg)
## Building the deep structure
The deep structure is a projection form the mixed structure.
......@@ -73,24 +55,13 @@ wget https://gitlab.inria.fr/sequoia/deep-sequoia/raw/master/tools/sequoia_proj.
The deep structure is then computed with the command:
```
grew -det -grs sequoia_proj.grs -seq deep -i test.mix.conll -f test.deep.conll
grew -det -grs sequoia_proj.grs -strat deep -i test.deep_and_surf.conll -f test.deep.conll
```
The output is given below (code and picture):
{{< input file="/static/deep_syntax/test.deep.conll" >}}
```
1 La le D DET sentid=00000 2 det _ _
2 souris souris N NC det=y|s=c 5 obj _ _
3 a avoir V V dl=avoir|m=ind|void=y 0 void _ _
4 été être V VPP dl=être|m=part|t=past|void=y 0 void _ _
5 mangée manger V VPP diat=passif|dl=manger|dm=ind|m=part|t=past _ _ _ _
6 par par P P void=y 0 void _ _
7 le le D DET _ 8 det _ _
8 chat chat N NC det=y|s=c 5 suj _ _
9 . . PONCT PONCT _ 5 ponct _ _
```
![Deep dependency structure](/img/test.deep.svg)
![Deep dependency structure](/deep_syntax/test.deep.svg)
This diff is collapsed.
+++
date = "2017-05-29T18:30:19+02:00"
title = "new_grs"
menu = "main"
Categories = ["Development","GoLang"]
Tags = ["Development","golang"]
Description = ""
+++
# GRS syntax
:warning: This page describes the new GRS syntax which is still in project :warning:
## Global structure
A GRS is composed by a set of declarations that may be provided in several files.
These files are expected to used the `.grs` of the `.dom` file extension.
Five kinds of declarations can be used:
* **Feature domain** declarations (keyword `features`)
* **Label domain** declarations (keyword `labels`)
* **Rule** declaration (keyword `rule`)
* **Strategy** declaration (keyword `strategy`)
* **Package** declaration (keyword `package`)
The first two kinds (Feature domain and label domain) can only be used at the top level and they cannot be nested (see below the multi-file handling).
## Feature domains
In graphs and in rules, nodes contain feature structures.
To control these feature structures, a feature domain may be given first.
In the feature domain declaration, feature names are identifiers and are defined as:
* **closed** feature accepts only an explicit given set of possible values (like the cat feature value below);
* **open** feature name accepts any string value (like the lemma feature value below);
* **numerical** feature (like the position feature below).
In closed features definition, feature values can be any strings; double quotes are required for string that are not lexical identifier (like values for pers).
:question: Explain merging of two feature domain declarations.
~~~grew
features {
cat: n, np, v, adj;
mood: inf, ind, subj, pastp, presp;
lemma: STRING;
phon: STRING;
pers: "1","2","3";
position: NUMERIC;
}
~~~
**REM:** values of pers feature are numerals but the only way to restrict to the finite domain {1, 2, 3} is to declare it as a closed feature and possible values as strings.
## Label domains
An explicit set of valid labels for edges may be given after the `labels` keyword.
It is possible to give several label domain declarations; the union of the different sets is then considered (:question: what about duplicates?, see [#4](https://gitlab.inria.fr/grew/libcaml-grew/issues/4)).
By default, edges are drawn with a black solid line and above the figure in DEP representation.
To modify the color or the position of the edges, the user can add attributes to a label with suffixes:
* `@bottom` to put the label above
* `@red`, `@blue`, … to modify the color of the link and the label
* `@dot` or `@dash` to modify the style of the link
Several suffixes can be used simultaneously.
~~~grew
labels { OBJ, SUJ, DE_OBJ, ANT, ANT_REL@red, ANT_REP@blue@bottom@dash }
~~~
:warning: the color, style and position management will change soon (see [#5](https://gitlab.inria.fr/grew/libcaml-grew/issues/5))
## Rules
Rule declaration is introduced by the keyword `rule`. For the syntax, see [rule page](../rule).
## Strategies
Strategies are used specify the way rules are applied during transformation.
The syntax of strategies definition is:
~~~grew
strat strat_id {
<<< strategy_description >>>
}
~~~
Strategy descriptions are defined by the following syntax:
~~~grew
S ::= rule_id % Apply the gives rule
| package_id % Apply any rule defined in the package (not in sub-packages)
| strat_id % Called a strategy defined elsewhere
| Pick (S) % Select arbitrary one of the graph produced by the strategy S
| Alt (S_1, …, S_n) % Collect graphs produced by each sub-strategies (union)
| Seq (S_1, …, S_n) % Apply sequentially S_1, then S_2 on S_1 output …
| Iter (S) % Iterate the application of the strategy S until normal forms
| If (S, S_1, S_2) % If S is productive then it is equivalent to S_1 else it is equivalent to S_2
~~~
It is common to compute one normal form with respect to a strategy `S`.
For instance, when one knows that the strategy is confluent, it is a much more efficient way to compute the unique normal form.
Some syntactic sugar is provided for this:
~~~grew
Onf (S) ≜ Pick (Iter (S)) % Onf stands for 'One normal form'
~~~
Other constructor are provided for some strategies
~~~grew
Empty ≜ Seq() % The Empty strategy returns the input graph
Try (S) ≜ If (S, S, Empty) % Equivalent to S if S is productive else it returns the input graph
~~~
## Packages
Packages are used to organize the set of declarations and to define scopes of definitions.
Syntax of packages definition:
~~~grew
package package_id {
declarations_list
}
~~~
where `declarations_list` is a list of declarations of **rules**, **packages** and **strategies**.
The syntax for accessing to some element `e` defined in package `P` is `P.e`.
In case of nested packages, an identifier may look like `P1.P2.P3.e`.
When a reference is made to an element `P1.P2.e`, the system tries to find inside the current package a sub-package `P1` which contains a sub-package `P2` which contains an element `e`.
If no such element is found, the same thing is searched recursively, first in the mother package of the current one, up to the root package.
Note that it is not allowed to have a domain declaration inside a package.
## Multi-file management
When a GRS become large and contains an high number of rules, it is sensible to define it in through a set of files.
Two mechanisms are available for this purpose: external file import and external file inclusion.
### External file import
At any place in a list of declaration in a GRS file, one can use the syntax:
```grew
import "filename.grs"
```
This creates a new package with the same name as the file (without the `.grs` extension).
Hence, the meaning is the same as the following code:
```grew
package filename {
<<< content of the file "filename.grs" >>>
}
```
As a consequence, it is not allowed to import a file which contains domain declarations because it would be equivalent to a domain declaration inside a package and this is forbidden.
To use a external domain declaration, one should use the file inclusion.
### External file inclusion
With file inclusion, the content of the external file is interpreted as if it was placed directly in the file at the same place.
In other words the code:
```grew
include "filename.grs"
```
has the same meaning as
```grew
<<< content of the file "filename.grs" >>>
```
## A complete example
We consider the same GRS defined through the multi-file mechanism and with a single files.
### Multi-file declaration
Consider a folder with the five files:
* `d_1.dom` ([Download](https://gitlab.inria.fr/grew/grew_doc/raw/master/static/examples/strategies/d_1.dom))
```grew
labels { E_1, E_11, E_12 }
```
* [`d_1.dom`](../examples/strategies/d_1.dom)
{{< grew file="/static/examples/strategies/d_1.dom" >}}
* [`p_1.grs`](../examples/strategies/p_1.grs)
{{< grew file="/static/examples/strategies/p_1.grs" >}}
* [`d_2.dom`](../examples/strategies/d_2.dom)
{{< grew file="/static/examples/strategies/d_2.dom" >}}
* [`p_2.grs`](../examples/strategies/p_2.grs)
{{< grew file="/static/examples/strategies/p_2.grs" >}}
* [`multi.grs`](../examples/strategies/multi.grs)
{{< grew file="/static/examples/strategies/multi.grs" >}}
### Single file declaration
The five files above define a GRS, equivalent to the one below:
* [`single.grs`](../examples/strategies/single.grs)
{{< grew file="/static/examples/strategies/single.grs" >}}
### Apply the GRS to a graphs
Consider the graph defined in [`input.gr`](../examples/strategies/input.gr):
{{< grew file="/static/examples/strategies/input.gr" >}}
+++
date = "2017-05-23T15:32:25+02:00"
title = "grs"
menu = "main"
Categories = ["Development","GoLang"]
Tags = ["Development","golang"]
Description = ""
+++
# GRS syntax (DEPRECATED)
In Grew, rewriting rules are described in a GRS file (GRS stands for Graph Rewriting System).
A GRS file describes a set of modules, each module contains a set of [rules](../rule).
:warning: Files using this format are expected to used the `.grs` file extension.
A Grew Graph Rewriting System (GRS) is defined by:
* a optional domain definition
* a set of modules (each module is introduced by the keyword `module`)
* the definition of sequences of modules (keyword `sequences`)
## Domain definition
The domain is defined as a pair of a feature domain and an edge label domain.
### Feature domain
In graphs and in rules, nodes contain feature structures.
To control these feature structures, a feature domain may be given first.
In the feature domain declaration, feature names are identifiers and are defined as:
* **closed** feature accepts only an explicit given set of possible values (like the cat feature value below);
* **open** feature name accepts any string value (like the lemma feature value below);
* **numerical** feature (like the position feature below).
In closed feature definition, feature values can be any strings; double quotes are required for string that are not lexical identifier (like values for pers).
~~~grew
features {
cat: n, np, v, adj;
mood: inf, ind, subj, pastp, presp;
lemma: *;
phon: *;
pers: "1","2","3";
position: #;
}
~~~
**REM:** values of pers feature are numerals but the only way to restrict to the finite domain {1, 2, 3} is to declare it as a closed feature and possible values as strings.
### edge label domain
An explicit set of valid labels for edges may be given after the `labels` keyword.
By default, edges are drawn with a black solid line and above the figure in DEP representation.
To modify the color or the position of the edges, the user can add attributes to a label with suffixes:
`@bottom` to put the label above
`@red`, `@blue`, … to modify the color of the link and the label
`@dot` or `@dash` to modify the style of the link
Several suffixes can be used simultaneously.
~~~grew
labels { OBJ, SUJ, DE_OBJ, ANT, ANT_REL@red, ANT_REP@blue@bottom@dash }
~~~
## Modules
In Grew, rules are grouped in modules.
A module is defined by a name and a set of [rules](../rule).
Example of module:
~~~grew
module name {
rule r_1 {
...
}
rule r_2 {
...
}
}
~~~
A module can be declared as `deterministic`:
~~~grew
module deterministic mod_name { ... }
~~~
If a module is declared deterministic, then only one normal form is computed.
If a non-confluent module is declared deterministic, some normal forms may be lost!
## Sequences
In the sequences part of a GRS file, each sequence is described by a name and a list of modules.
The same module can be used in several sequences but it can also be used several times in the same sequence
(mainly useful when total ordering of module is not possible).
## examples of GRS
A minimal GRS file (without any module) looks like:
~~~grew
features {
cat: v, np;
phon: *;
lemma: *;
}
labels { suj, obj }
sequences { dummy {} }
~~~
A bigger grs file:
~~~grew
features { ... }
labels { OBJ, SUBJ, DE_OBJ, ANT }
module det {
rule det_1 {
...
}
rule det_2 {
...
}
}
...
module ana {
...
}
sequences {
full {det; normsyn; arg; ana}
dn {det; normsyn}
}
~~~
## Split a GRS description into several files
It is possible to describe a GRS through several text files.
### External domain
The two declarations of features domain and of labels domain can be putted in a separate file and include in the main GRS with the keyword `domain`
### External module definition
It is also possible to put a list of modules in a external file `modules_1_and_2.grs`:
~~~grew
module M1 { ... }
module M2 { ... }
~~~
and to include them in a GRS file with the syntax below:
~~~grew
include "modules_1_and_2.grs";
~~~
The recursive use of the include directive is available.
\ No newline at end of file
......@@ -11,11 +11,10 @@ Description = ""
**Grew-parse-FR** is natural language parser for French.
It is composed of a GRS (Graph Rewriting System) which can be used with the Grew software to produce dependency syntax structures from POS-tagged data.
With a POS-tagger (MElt is a recommended), it provides a full parser with sentences as input and dependency structures as output
With a POS-tagger (**MElt** is a recommended), it provides a full parser with sentences as input and dependency structures as output
The parsing GRS is described in an [IWPT 2015 publication](https://hal.inria.fr/hal-01188694).
# How to parse a sentence?
Prerequisite: the Grew software, the MElt software, the POStoSSQ rewriting system (see below for installation procedures).
We consider the sentence:
......@@ -23,8 +22,8 @@ We consider the sentence:
The parsing is done in two steps:
1. POS-tagging with melt: `echo "La souris a été mangée par le chat." | MElt -L -T > test.melt`
2. Building the dependency syntax structure: `grew -det -grs POStoSSQ/grs/surf_synt_main.grs -seq full -i test.melt -f test.conll`
1. POS-tagging with **MElt**: `echo "La souris a été mangée par le chat." | MElt -L -T > test.melt`
2. Building the dependency syntax structure: `grew -det -grs POStoSSQ/grs/surf_synt_main.grs -strat full -i test.melt -f test.conll`
# Prerequisite
......@@ -38,70 +37,45 @@ The parsing is done in two steps:
## POS-tagging
The parsing system **POStoSSQ** is waiting for a pos-tagged input.
One easy way to produce such a pos-tagged French sentence is to use [MElt](https://gforge.inria.fr/frs/?group_id=481).
It should be possible to use another tagger but this may require a few caterories matching to adapt the output of the tagger.
It should be possible to use another tagger but this may require a few categories matching to adapt the output of the tagger.
With MElt, the options used `-L` and `-T` ask MElt to tokenize the input sentence and to lemmatize the output.
For instance, the output of the following command:
With **MElt**, the options used `-L` and `-T` are used to tokenize the input sentence and to lemmatize the output.
For instance, the following command:
`echo "La souris a été mangée par le chat." | MElt -L -T`
`echo "La souris a été mangée par le chat." | MElt -L -T > test.melt`
is:
produces the file [`test.melt`](/parsing/test.melt):
```
La/DET/le souris/NC/souris a/V/avoir été/VPP/être mangée/VPP/manger par/P/par le/DET/le chat/NC/chat ./PONCT/.
```
{{< input file="/static/parsing/test.melt" >}}
## Parsing with the GRS
If we supposed that the file `test.melt` contains a POS-tagged sentence like the one given above:
With the file `test.melt` described above, the following command produces the Conll code of the parsed sentence:
```
La/DET/le souris/NC/souris a/V/avoir été/VPP/être mangée/VPP/manger par/P/par le/DET/le chat/NC/chat ./PONCT/.
```
`grew -det -grs POStoSSQ/grs/surf_synt_main.grs -strat full -i test.melt -f test.conll`
The command to produced a Conll version of the parsed sentence:
The output file is [`test.conll`](/parsing/test.conll):
`grew -det -grs POStoSSQ/grs/surf_synt_main.grs -seq full -i test.melt -f test.conll`
The produced file contains the Conll description:
```
1 La le D DET sentid=00000 2 det _ _
2 souris souris N NC det=y|s=c 5 suj _ _
3 a avoir V V m=ind 5 aux.tps _ _
4 été être V VPP m=pastp 5 aux.pass _ _
5 mangée manger V VPP diat=passif|m=pastp _ _ _ _
6 par par P P _ 5 p_obj.agt _ _
7 le le D DET _ 8 det _ _
8 chat chat N NC det=y|s=c 6 obj.p _ _
9 . . PONCT PONCT _ 5 ponct _ _
```
{{< input file="/static/parsing/test.conll" >}}
which encodes the syntactic structure:
![Dependency structure](/img/test.surf.svg)
![Dependency structure](/parsing/test.svg)
It is also possible to runs a GTK interface in which you can explore step by step rewriting of the input sentence:
`grew -grs POStoSSQ/grs/surf_synt_main.grs -seq full -gr test.melt`
`grew -grs POStoSSQ/grs/surf_synt_main.grs -strat full -gr test.melt`
## Parsing a set of sentence
No explicit linking with a sentence tokenizer is provided.
We will suppose here that the input file is already split in sentences (one by line).
Suppose that the file [`tdm80_ch01.txt`](/examples/tdm80_ch01.txt) contains the following data:
Suppose that the file [`tdm80_ch01.txt`](/parsing/tdm80_ch01.txt) contains the following data:
```
En l'année 1872, la maison portant le numéro 7 de Saville-row, Burlington Gardens - maison dans laquelle Sheridan mourut en 1814 - , était habitée par Phileas Fogg, esq., l'un des membres les plus singuliers et les plus remarqués du Reform-Club de Londres, bien qu'il semblât prendre à tâche de ne rien faire qui pût attirer l'attention.
À l'un des plus grands orateurs qui honorent l'Angleterre, succédait donc ce Phileas Fogg, personnage énigmatique, dont on ne savait rien, sinon que c'était un fort galant homme et l'un des plus beaux gentlemen de la haute société anglaise.
On disait qu'il ressemblait à Byron - par la tête, car il était irréprochable quant aux pieds - , mais un Byron à moustaches et à favoris, un Byron impassible, qui aurait vécu mille ans sans vieillir.
Anglais, à coup sûr, Phileas Fogg n'était peut-être pas Londonner.
On ne l'avait jamais vu ni à la Bourse, ni à la Banque, ni dans aucun des comptoirs de la Cité.
Ni les bassins ni les docks de Londres n'avaient jamais reçu un navire ayant pour armateur Phileas Fogg.
Ce gentleman ne figurait dans aucun comité d'administration.
```
{{< input file="/static/parsing/tdm80_ch01.txt" >}}
The parsing can be done with the same two steps process:
1. POS-tagging with melt: `cat tdm80_ch01.txt | MElt -L -T > tdm80_ch01.melt`
2. Building the dependency syntax structure: `grew -det -grs POStoSSQ/grs/surf_synt_main.grs -seq full -i tdm80_ch01.melt -f tdm80_ch01.conll`
2. Building the dependency syntax structure: `grew -det -grs POStoSSQ/grs/surf_synt_main.grs -strat full -i tdm80_ch01.melt -f tdm80_ch01.conll`
......@@ -8,10 +8,14 @@ menu = "main"
+++
# Last release: version 0.43 on May 23, 2017
The symbol ":warning:" indicates changes that may break backward compatibility.
# [last release] Version 0.44 on September 05, 2017
* :warning: new grs syntax (with package and strategies), see [grs](../grs).
# Vversion 0.43 on May 23, 2017
## Syntax changes
The syntax changes below make existing Grew code to be deprecated.
The old syntax is still accepted but for a limited amount of time, please update your existing GRS system soon.
......@@ -21,7 +25,7 @@ The old syntax is still accepted but for a limited amount of time, please update
## Command actions
* :warning: the shift command semantics: edges with source and target nodes in the pattern are not concerned by the shifts
* a new syntax is available for the command `add_edge` [#2](https://gitlab.inria.fr/grew/libcaml-grew/issues/2). See [command documentation](../commands#add-a-new-edge-with-a-label-taken-in-the-pattern).
* a new syntax is available for the command `add_edge` (issue [#2](https://gitlab.inria.fr/grew/libcaml-grew/issues/2)). See [command documentation](../commands#add-a-new-edge-with-a-label-taken-in-the-pattern).
## Removed old stuff
* :warning: old syntax for node addition is no longer supported:
......
......@@ -16,7 +16,7 @@
<li class="section">Use Grew</li>
<li><a href="/installation">Installation</a></li>
<li><a href="/run">Run Grew</a></li>
<li><a href="/whats">version 0.43: what's new</a></li>
<li><a href="/whats">version 0.44: what's new</a></li>
<hr/>
<li class="section">Available GRS</li>
......@@ -34,7 +34,6 @@
<hr/>
<li class="section">Developper corner</li>
<li><a href="/new_grs">New GRS syntax</a></li>
<li><a href="https://gitlab.inria.fr/grew/libcaml-grew">Gitlab for Grew library</a></li>
<li><a href="https://gitlab.inria.fr/grew/grew">Gitlab for Grew GUI</a></li>
</ul>
......
<pre><code>{{$file := .Get "file"}}
{{- $file | readFile | safeHTML -}}
</code></pre>
\ No newline at end of file
selfdoc:
@echo "make run"
@echo "make img"
run:
ln -s /Users/guillaum/gitlab/grew/POStoSSQ
ln -s /Users/guillaum/gitlab/grew/SSQtoDSQ
ln -s /Users/guillaum/gitlab/deep-sequoia/tools/sequoia.dom
ln -s /Users/guillaum/gitlab/deep-sequoia/tools/sequoia_proj.grs
echo "La souris a été mangée par le chat." | MElt -L -T > test.melt
grew -det -grs POStoSSQ/grs/surf_synt_main.grs -strat full -i test.melt -f test.surf.conll
grew -det -grs SSQtoDSQ/grs/main_dsq.grs -i test.surf.conll -f test.deep_and_surf.conll
grew -det -grs sequoia_proj.grs -strat deep -i test.deep_and_surf.conll -f test.deep.conll
rm -f POStoSSQ SSQtoDSQ sequoia.dom sequoia_proj.grs
img: figures
purge:
@make clean
rm -f test.* POStoSSQ SSQtoDSQ sequoia.dom sequoia_proj.grs
include ../Makefile
\ No newline at end of file
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Created with dep2pict 2.29 -->
<svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="844.57715" height="277.25586">
<rect x="0" y="0" width="844.57715" height="277.25586" style="fill:white;fill-opacity:1;" />
<g transform="translate(0,114.89844) scale(2,2)">
<text id="word__N_1" x="30.8884" y="-14.4062" font-style="normal" font-weight="normal" fill="black" font-size="12" font-family="Arial" text-anchor="middle" text-align="center">
<tspan x="30.8884" dy="12.8633">La</tspan>
</text>
<text id="subword__N_1" x="30.8884" y="-1.54297" fill="black" font-size="7" font-family="Arial" text-anchor="middle" text-align="center">
<tspan x="30.8884" dy="8.33691">le</tspan>
<tspan x="30.8884" dy="8.33691">D</tspan>
<tspan x="30.8884" dy="8.33691">DET</tspan>
<tspan x="30.8884" dy="8.33691">sentid=00000</tspan>
</text>
<text id="word__N_2" x="87.3989" y="-14.4062" font-style="normal" font-weight="normal" fill="black" font-size="12" font-family="Arial" text-anchor="middle" text-align="center">
<tspan x="87.3989" dy="12.8633">souris</tspan>
</text>
<text id="subword__N_2" x="87.3989" y="-1.54297" fill="black" font-size="7" font-family="Arial" text-anchor="middle" text-align="center">
<tspan x="87.3989" dy="8.33691">souris</tspan>
<tspan x="87.3989" dy="8.33691">N</tspan>
<tspan x="87.3989" dy="8.33691">NC</tspan>
<tspan x="87.3989" dy="8.33691">det=y</tspan>
<tspan x="87.3989" dy="8.33691">s=c</tspan>
</text>
<text id="word__N_3" x="135.171" y="-14.4062" font-style="normal" font-weight="normal" fill="red" font-size="12" font-family="Arial" text-anchor="middle" text-align="center">
<tspan x="135.171" dy="12.8633">a</tspan>
</text>
<text id="subword__N_3" x="135.171" y="-1.54297" fill="red" font-size="7" font-family="Arial" text-anchor="middle" text-align="center">
<tspan x="135.171" dy="8.33691">avoir</tspan>
<tspan x="135.171" dy="8.33691">V</tspan>
<tspan x="135.171" dy="8.33691">V</tspan>
<tspan x="135.171" dy="8.33691">dl=avoir</tspan>
<tspan x="135.171" dy="8.33691">m=ind</tspan>
<tspan x="135.171" dy="8.33691">void=y</tspan>
</text>
<text id="word__N_4" x="178.049" y="-14.4062" font-style="normal" font-weight="normal" fill="red" font-size="12" font-family="Arial" text-anchor="middle" text-align="center">
<tspan x="178.049" dy="12.8633">été</tspan>
</text>
<text id="subword__N_4" x="178.049" y="-1.54297" fill="red" font-size="7" font-family="Arial" text-anchor="middle" text-align="center">
<tspan x="178.049" dy="8.33691">être</tspan>
<tspan x="178.049" dy="8.33691">V</tspan>
<tspan x="178.049" dy="8.33691">VPP</tspan>
<tspan x="178.049" dy="8.33691">dl=être</tspan>
<tspan x="178.049" dy="8.33691">m=part</tspan>
<tspan x="178.049" dy="8.33691">t=past</tspan>
<tspan x="178.049" dy="8.33691">void=y</tspan>
</text>
<text id="word__N_5" x="229.796" y="-14.4062" font-style="normal" font-weight="normal" fill="black" font-size="12" font-family="Arial" text-anchor="middle" text-align="center">
<tspan x="229.796" dy="12.8633">mangée</tspan>
</text>
<text id="subword__N_5" x="229.796" y="-1.54297" fill="black" font-size="7" font-family="Arial" text-anchor="middle" text-align="center">
<tspan x="229.796" dy="8.33691">manger</tspan>
<tspan x="229.796" dy="8.33691">V</tspan>
<tspan x="229.796" dy="8.33691">VPP</tspan>
<tspan x="229.796" dy="8.33691">diat=passif</tspan>
<tspan x="229.796" dy="8.33691">dl=manger</tspan>
<tspan x="229.796" dy="8.33691">dm=ind</tspan>
<tspan x="229.796" dy="8.33691">m=part</tspan>
<tspan x="229.796" dy="8.33691">t=past</tspan>
</text>
<text id="word__N_6" x="281.005" y="-14.4062" font-style="normal" font-weight="normal" fill="red" font-size="12" font-family="Arial" text-anchor="middle" text-align="center">
<tspan x="281.005" dy="12.8633">par</tspan>
</text>