Commit 592c70c3 authored by Bruno Guillaume's avatar Bruno Guillaume

update doc

parent c955b7ed
......@@ -9,23 +9,23 @@ menu = "main"
+++
# Command syntax
Each rule contains a sequence of commands introduced by the keyword `commands`, separated by semicolon symbol ; and surrounded by braces.
Each rule contains a sequence of commands introduced by the keyword `commands`, separated by semicolon symbol `;` and surrounded by braces.
## Node deletion
This following command removes the A nodes and all its incident edges.
The following command removes the A nodes and all its incident edges.
~~~grew
del_node A
~~~
## Node creation
To create a new node, the command is `add_node`.
The command below create a new node and give it the identifier `A` until the end the rule application.
The command below creates a new node and give it the identifier `A` until the end the rule application.
~~~grew
add_node A
~~~
Moreover, if the node must be placed at a specific position in the linear order of the nodes, the two syntax are available: the new node `B` (resp. `C`) is placed on the immediate left (resp. right) of the node `N`.
Moreover, if the node must be placed at a specific position in the linear order of the nodes, two syntax are available: the new node `B` (resp. `C`) is placed on the immediate left (resp. right) of the node `N`.
~~~grew
add_node B :< N
add_node C :> N
......@@ -51,28 +51,28 @@ add_edge N -[suj]-> M
~~~
### Add a new edge with a label taken in the pattern
The command `add_edge e: N -> M` add a new edge in the current graph from the node matched with indentifier `N` to the node matched with indentifier `M` with the same label as the edge that was match in the pattern with the edge indentifier `e`.
The command `add_edge e: N -> M` add a new edge in the current graph from the node matched with identifier `N` to the node matched with identifier `M` with the same label as the edge that was match in the pattern with the edge identifier `e`.
#### Example:
`add_edge_pattern.grs`:
~~~grew
module deterministic M {
package M {
rule r {
match { A[phon=A]; B[phon=B]; e: B -> A }
pattern { A[phon=A]; B[phon=B]; e: B -> A }
commands { del_edge e; add_edge e: A -> B }
}
}
sequences { main { M }}
strat main { Onf(M) }
~~~
`input.gr`:
~~~grew
graph {
A [phon="A"];
B [phon="B"];
B -[x]-> A;
B -[y]-> A;
B -[z]-> A;
A [phon="A"];
B [phon="B"];
B -[x]-> A;
B -[y]-> A;
B -[z]-> A;
}
~~~
......@@ -100,5 +100,39 @@ The action of the 3 commands above are respectively:
* modifying all out-edges which are starting in `B` with a `suj` or `obj` label: they are redirected to start in `C`.
* modifying all in-edges which are ending in `B` with a label different from `suj` and `obj`: they are redirected to end in `D`.
# Effective commands
There are situations where commands may not be properly defined.
Consider the rule `r` below and and a graph with two nodes `A` and `B` linked by two edges `X` and `Y` both going from `A` to `B`.
The rule `R` can be applied to the graph but the command `add_edge` can not be applied (the edge labelled `Y` already exists).
```grew
rule r {
pattern { N -[X]-> M }
commands { add_edge N -[Y]-> M }
}
```
The fact that a rule is effective or not depends on the graph on which the rule is applied.
In fact, to deal with this case, **Grew** has two running modes with different behaviors.
1. In the default mode, ineffective commands are simply ignored and the rewriting goes on with the next commands or rules.
1. In the safe mode (set by the `-safe_commands` argument), an ineffective command stop the rewriting with and produces an exection error.
## List of ineffective Commands
Command which may be ineffective are:
* `add_edge` when the edge is already present in the graph
* `del_edge` when the edge does not exists in the graph
* `del_node` when the node does not exists in the graph (this can happen when there are two commands `del_node A` in the same rule)
* `def_feat` when the feat does not exists in the node
Note that it is always possible to define a Graph Rewriting System with only effective commands following the procedure:
* a rule with an potential ineffective `add_edge` commands can be replaced by two rules, one with a `without` clause ensuring the absence of the edge and one without the `add_edge` command.
* a rule with an potential ineffective `del_edge` commands can be replaced by two rules, one with the given edge in the pattern and one without the `del_edge` command.
* an ineffective `del_node` command can be safely removed
* a rule with an potential ineffective `del_feat` commands can be replaced by two rules, one with the feat in the pattern and one without the `del_feat` command.
......@@ -15,7 +15,7 @@ For the previous syntax, view [old_grs](../old_grs) page.
## 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.
These files are expected to used the `.grs` or the `.dom` file extension.
Five kinds of declarations can be used:
......@@ -99,19 +99,27 @@ Strategy descriptions are defined by the following syntax:
| 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:
Other constructor are provided for some strategies
~~~grew
Onf (S) ≜ Pick (Iter (S)) % Onf stands for 'One normal form'
Empty ≜ Seq() % The Empty strategy always returns the input graph
Try (S) ≜ If (S, S, Empty) % Equivalent to S if S is productive else it returns the input graph
~~~
Other constructor are provided for some strategies
### Computing one normal form
To compute only one normal form with a strategy `S`, one can used the strategy: `Pick (Iter (S))`:
the strategy `Iter (S)` computes the full set of normal forms and the `Pick` operator choses one of them.
But this may be not efficient if the number of normal forms is high.
For this case, another implementation of the rewriting is available with the operator `Onf` (the name stands for 'One normal form').
With this operator, only one normal form is built, and so :
~~~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
Onf (S) = Pick (Iter (S))
~~~
:warning: But `Onf` can be safely used only if the strategy is terminating. More info about this on the [rewriting page](../rewriting).
## Packages
......@@ -170,7 +178,7 @@ has the same meaning as
## A complete example
We consider the same GRS defined through the multi-file mechanism and with a single files.
We consider the same GRS defined through the multi-file mechanism and with a single file.
### Multi-file declaration
Consider a folder with the five files:
......
......@@ -15,14 +15,14 @@ Categories = ["Development","GoLang"]
## News
**2017/12/14:** New release of version **0.46**. Main changes are:
* GTK interface is proposed as a separate package and so Grew without GUI is much more easy to install
* GTK interface is proposed as a separate package and so Grew without GUI is much more easy to [install](../install)
* Command line arguments were revisited (see [Run Grew page](../run))
## A first taste of Grew
The easiest way to try and test **Grew** is to use one of the two online interfaces.
1. [Online graph matching](http://match.grew.fr) lets the user search for a given pattern in a corpus of syntactic structures (a tutorial is available to help learning pattern syntax).
2. [Online parsing](http://parse.grew.fr) returns for a input French sentence, a set of linguistic representations (syntax and semantics) which are built using Graph Rewriting.
1. Online graph matching: [Grew-match](http://match.grew.fr) lets the user search for a given pattern in a corpus of syntactic structures (a tutorial is available to help learning pattern syntax).
2. Online parsing: [Grew-parse](http://parse.grew.fr) returns for a input French sentence, a set of linguistic representations (syntax and semantics) which are built using Graph Rewriting.
## Some of the main features of Grew
......@@ -30,5 +30,5 @@ The easiest way to try and test **Grew** is to use one of the two online interfa
* The left-hand side of a rule is described by a graph called a **pattern**; injective graph morphisms are used in the pattern matching algorithm.
* **Negative pattern** can be used for a finer control on the left-hand side of rules.
* The right-hand side of rules is described by a sequence of **atomic commands** that describe how the graph should be modified during the rule application.
* Subset of rules are grouped in **modules**; the full rewriting process being a sequence of module applications.
* Subset of rules can be organized in **packages** and **strategies** define the way rules and packages are applied in graph transformation.
* **Grew** has support both for **confluent** and **non-confluent** modules; when a non-confluent modules is used, all normal forms are returned and then ambiguity is handled in a natural way.
......@@ -26,7 +26,7 @@ A GTK interface is available (again on Linux and Mac OS&nbsp;X, untested on Wind
* Test
* Try the command `grew version`
* In case of trouble, make sure that your PATH contains `~/.opam/4.06.0/bin` and try again
* In trouble persists, please [fill an issue](https://gitlab.inria.fr/grew/grew_doc/issues)
* If trouble persists, please [fill an issue](https://gitlab.inria.fr/grew/grew_doc/issues)
* Updating when **Grew** is already installed:
* `apt-get update && apt-get upgrade`
......
+++
Tags = ["Development","golang"]
Description = ""
date = "2018-02-08T15:07:28+01:00"
title = "ogm doc"
menu = "main"
Categories = ["Development","GoLang"]
+++
# Grew-match: Online Graph Matching
**Grew-match** is a one page online web application for searching graph pattern in a TreeBanks.
In the current version, the TreeBanks available are:
* The 102 TreeBanks of the version 2.1 of [Universal Dependencies](http://universaldependencies.org)
* Some other versions of French Universal Dependencies
* The French Sequoia corpus (with and without deep syntactic annotations)
## Basic usage
1. Select the corpus on which you want to search (Click on `Show corpora list` if needed)
1. Enter the search pattern in the text area (you may use some snippets on the right of the text area)
1. Click on `Search`
The number of items is displayed and the first 10 items can be explored.
If you want to see more the next 10 items, click on `Get more results`.
To limit server usage, only the first 1000 items are computed.
It the searched pattern is found more then 1000 times, the amount of corpora used to find the first 1000 items is reported.
For instance, if you search for a `nsubj` relation, the output message is `More than 1000 results found in 6.01% of the corpus`.
This means that the first 1000 items were found in 6.01% of the 16,622 sentences of the UD_English corpus.
## Learning syntax
A [tutorial](http://match.grew.fr/?tutorial=yes) with a progressive sequence of patterns is available.
You may also explore snippets given on the right of the text area to learn with other examples.
## About CoNLL field names
The fields 2, 3, 4 and 5 of CoNLL structure are named differently in UD and in Sequoia
| CoNLL field | 2 | 3 | 4 | 5 |
|-----------------|:------:|:-------:|:------:|:------:|
| Name in UD | `form` | `lemma` | `upos` | `xpos` |
| Name in Sequoia | `phon` | `lemma` | `cat` | `pos` |
For instance, if you want to search for the word _maison_, you write:
* in UD: `pattern { N [form="maison"] }`
* in Sequoia: `pattern { N [phon="maison"] }`
## Access to CoNNL-U specificities
Additional information available in the CoNNL-U format can be accesses through special features:
* Enhanced dependencies are written with the prefix `E:`
* Features of column 10 (MISC) are shown with the prefix `_MISC_`
* Empty nodes have a feature `_UD_empty=Yes`
* Multiword tokens are described on the first element with features `_UD_mw_fusion` and `_UD_mw_span`
## Contact
For any remark or request, you can either contact [us](mailto:Bruno.Guillaume@loria.fr?subjectGrew-match) or open an issue on the [GitLab project](http://gitlab.inria.fr/grew/grew_web/issues) (you will have to register).
......@@ -9,4 +9,4 @@ title = "pattern"
# Pattern syntax
One way to learn the syntax of patterns in grew is to follow the tutorial part of the [Online Graph Matching](http://match.grew.fr) tool.
\ No newline at end of file
One way to learn the syntax of patterns in grew is to follow the tutorial part of the [Grew-match](http://match.grew.fr) tool.
\ No newline at end of file
+++
Categories = ["Development","GoLang"]
Tags = ["Development","golang"]
Description = ""
date = "2018-02-17T18:07:38+01:00"
title = "rewriting"
menu = "main"
+++
# Graph rewriting
## Terminology
* Normal form
* Confluent
* Terminating
## Terminating and confluent system
When a GRS is **terminating** and **confluent**, we have the equivalence of the 4 strategies:
~~~grew
Onf (S) ≃ Iter(S) ≃ Pick (Iter (S)) ≃ Iter (Pick (S))
~~~
They all compute one graph which is the unique normal form.
In this case, the strategy `Onf` should be used because it is the more efficient one.
## Terminating system
When a GRS is **terminating**, we have the equivalence of the two strategies:
~~~grew
Onf (S) ≃ Pick (Iter (S))
~~~
See below for an example of non-terminating system where the equivalence does not hold.
## Example of non-terminating rewriting system
The following code described a non-terminating rewriting system:
```grew
package S {
rule B2A { pattern { e: N -[B]-> M } commands { del_edge e; add_edge N -[A]-> M } }
rule B2C { pattern { e: N -[B]-> M } commands { del_edge e; add_edge N -[C]-> M } }
rule C2B { pattern { e: N -[C]-> M } commands { del_edge e; add_edge N -[B]-> M } }
rule C2D { pattern { e: N -[C]-> M } commands { del_edge e; add_edge N -[D]-> M } }
}
```
Each rule replaces an edge label by another.
For instance, the rule `B2A` removes and edge with an `B` label and adds one with an `A` label.
Let `G_A`, `G_B`, `G_C` and `G_D` the 4 graphs with 2 nodes and 1 edge labelled `A`, `B`, `C` and `D` respectively.
The schema below shows how the 4 rules act on these 4 graphs:
![input.gr](/examples/non-term/xyz.svg)
### Applying `S` to `G_B`
* The strategy `Iter (S)` applied to `G_B` produces the 2 graphs `G_A` and `G_D`.
* The strategy `Pick (Iter (S))` applied to `G_B` may produce (unpredictably):
* the graph `G_A`
* the graph `G_D`
* The strategy `Iter (Pick (S))` applied to `G_B` may produce (unpredictably):
* the graph `G_A`
* the graph `G_D`
* the empty set
* The strategy `Onf (S)` applied to `G_B` may lead to (unpredictably):
* the output of the graph `G_A`
* the output of the graph `G_D`
* a non-terminating execution
Note that all unpredictable behavior will be identical from one execution to another with the same input data.
But, if the order of rules in the pacakge `S` is changed, the behavior may be different.
......@@ -30,8 +30,6 @@ The full command for this mode:
Required arguments for this mode are:
where:
* `<grs_file>` is the main file which describes Graph Rewriting System
* `<input_file>`: describes the input data (CoNLL file of gr file)
* `<output_file>`: is the name of the output file (CoNLL file)
......@@ -39,6 +37,7 @@ where:
Optional argument is:
* `-strat <name>`: the strategy used in transformation (default value: `main`)
* `-safe_commands`: make rewriting process fail in case of [ineffective command](../commands/#effective-commands)
---
......@@ -57,24 +56,23 @@ Optional arguments:
---
# Grep mode
This mode corresponds to the command line version of the [Online graph matching](http://match.grew.fr) tool.
This mode corresponds to the command line version of the [Grew-match](http://match.grew.fr) tool.
The command is:
`grew grep -pattern <pattern_file> -node_id <id> -i <corpus_file>`
`grew grep -pattern <pattern_file> -i <corpus_file>`
where:
* `<pattern_file>` is a file which describes a pattern
* `<id>` is the name of a node identifier declared in the pattern
* `<corpus_file>` is the corpus in which the search is done
The output is a list of lines, one for each occurrence of the pattern in the corpus.
The output is given in JSON format.
## Example
With the following files:
* The surface sequoia version 7.0: `sequoia.surf.conll` ([Download](https://gitlab.inria.fr/sequoia/deep-sequoia/raw/master/tags/sequoia-7.0/sequoia.surf.conll)),
* The surface sequoia version 8.0: `sequoia.surf.conll` ([Download](https://gitlab.inria.fr/sequoia/deep-sequoia/raw/master/tags/sequoia-8.0/sequoia.surf.conll)),
* A pattern file with the code below: `subcat.pat` ([Download](https://gitlab.inria.fr/grew/grew_doc/raw/master/static/examples/grep/subcat.pat))
```
......@@ -87,17 +85,41 @@ pattern {
The command:
`grew grep -pattern subcat.pat -node_id V -i sequoia.surf.conll`
produces the following output:
```
annodis.er_00040 41
annodis.er_00240 12
annodis.er_00441 14
emea-fr-test_00438 19
emea-fr-test_00478 31
Europar.550_00496 14
`grew grep -pattern subcat.pat -i sequoia.surf.conll`
produces the following JSON output:
```json
[
{
"sent_id": "Europar.550_00496",
"matching": { "V": "16", "DE": "19", "A": "14" }
},
{
"sent_id": "emea-fr-test_00478",
"matching": { "V": "33", "DE": "32", "A": "35" }
},
{
"sent_id": "emea-fr-test_00438",
"matching": { "V": "20", "DE": "21", "A": "22" }
},
{
"sent_id": "annodis.er_00441",
"matching": { "V": "16", "DE": "20", "A": "18" }
},
{
"sent_id": "annodis.er_00240",
"matching": { "V": "12", "DE": "13", "A": "11" }
},
{
"sent_id": "annodis.er_00040",
"matching": { "V": "42", "DE": "50", "A": "47" }
}
]
```
This means that the pattern described in the file `subcat.pat` was found 6 times in the corpus, each line gives the sentence identifier and the position of node matched by the node `V` of the pattern.
This means that the pattern described in the file `subcat.pat` was found 6 times in the corpus, each item gives the sentence identifier and the position of nodes matched by the pattern.
Note that two other options exist (`-html` and `-dep_dir <directory>`).
The first one produces a new `html` field in each JSON item with the sentence where words impacted by the pattern are in a special HTML span with class `highlight`.
The second one produces a new file in the folder `directory` with the representation of the sentence with highlighted part (as in [Grew-match](http://match.grew.fr) tool) and a new field in each JSON item with the filename; the output is in `dep` format (usable with [Dep2pict](http://dep2pict.loria.fr)).
......@@ -9,8 +9,8 @@
<hr/>
<li class="section">Try Grew online</li>
<li><a href="http://match.grew.fr">Online graph matching</a></li>
<li><a href="http://parse.grew.fr">Online parsing</a></li>
<li><a href="http://match.grew.fr">Grew-match (Online Matching)</a></li>
<li><a href="http://parse.grew.fr">Grew-parse (Online parsing)</a></li>
<hr/>
<li class="section">Use Grew</li>
......
......@@ -16,7 +16,7 @@ Prism.languages.grew = {
}
],
'operator': {
pattern: /<<|<|>|>>|-\[|\]->|==>|=\[|\]=>/,
pattern: /<<|<|>|>>|:<|:>|->|-\[|\]->|==>|=\[|\]=>/,
greedy:true
},
};
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment