Difference between revisions of "SCI Parser Programmer's Reference/Said Spec Trees"
| (5 intermediate revisions by the same user not shown) | |||
| Line 6: | Line 6: | ||
[[SCI Parser Programmer's Reference/User Parse Trees|2]] | | [[SCI Parser Programmer's Reference/User Parse Trees|2]] | | ||
[[SCI Parser Programmer's Reference/Said Specs|3]] | | [[SCI Parser Programmer's Reference/Said Specs|3]] | | ||
| − | [[SCI Parser Programmer's Reference/Syntax|4]] | | + | [[SCI Parser Programmer's Reference/Said Syntax|4]] | |
| − | [[SCI Parser Programmer's Reference/Spec Trees|5]] | | + | [[SCI Parser Programmer's Reference/Said Spec Trees|5]] | |
[[SCI Parser Programmer's Reference/Tree Matching|6]] | | [[SCI Parser Programmer's Reference/Tree Matching|6]] | | ||
[[SCI Parser Programmer's Reference/Examples|7]] | | [[SCI Parser Programmer's Reference/Examples|7]] | | ||
| Line 19: | Line 19: | ||
| | ||
| − | + | ==<br /> Said Spec Trees: == | |
| + | |||
| + | When a spec is processed, it is turned into a tree that can be compared with the user parse tree. Since the spec IS a structural specification, the mapping is straightforward. It is important to keep these mappings in mind though, because our goal is to imagine the structure of possible user input trees and create specs that match them closely enough for the similarity to be recognized by the matcher. | ||
| + | |||
| + | At the top level there are three possible "slots" to fill: verb, dobj and iobj. At lower levels the only slots to be filled are ROOT and MOD(ifier). Alternatives and optionals generate OR and OPT nodes with the appropriate children nodes under them. | ||
| + | |||
| + | ===<br /> Example === | ||
| + | |||
| + | 'start,(turn<on)[/car]' generates the following tree: | ||
| + | |||
| + | <blockquote> | ||
| + | <div class="CodeBlockHeader">Code:</div> | ||
| + | <syntaxhighlight lang="sci"> | ||
| + | (root s | ||
| + | (root verb | ||
| + | (or | ||
| + | (root verb . 'start') | ||
| + | (root | ||
| + | (root verb . 'turn') | ||
| + | (mod prep . 'on') | ||
| + | ) | ||
| + | ) | ||
| + | ) | ||
| + | (opt | ||
| + | (dobj np | ||
| + | (root noun . 'car') | ||
| + | ) | ||
| + | ) | ||
| + | ) | ||
| + | </syntaxhighlight> | ||
| + | </blockquote> | ||
| | ||
| Line 32: | Line 62: | ||
| | ||
| − | <span style="float: left">[[SCI Parser Programmer's Reference/Syntax|< Previous: Syntax]]</span> | + | <span style="float: left">[[SCI Parser Programmer's Reference/Said Syntax|< Previous: Said Syntax]]</span> |
<span style="float: right">[[SCI Parser Programmer's Reference/Tree Matching|Next: Tree Matching >]]</span> | <span style="float: right">[[SCI Parser Programmer's Reference/Tree Matching|Next: Tree Matching >]]</span> | ||
Latest revision as of 01:14, 22 December 2015
Said Spec Trees:
When a spec is processed, it is turned into a tree that can be compared with the user parse tree. Since the spec IS a structural specification, the mapping is straightforward. It is important to keep these mappings in mind though, because our goal is to imagine the structure of possible user input trees and create specs that match them closely enough for the similarity to be recognized by the matcher.
At the top level there are three possible "slots" to fill: verb, dobj and iobj. At lower levels the only slots to be filled are ROOT and MOD(ifier). Alternatives and optionals generate OR and OPT nodes with the appropriate children nodes under them.
Example
'start,(turn<on)[/car]' generates the following tree:
Code:(root s (root verb (or (root verb . 'start') (root (root verb . 'turn') (mod prep . 'on') ) ) ) (opt (dobj np (root noun . 'car') ) ) )
- Notes
< Previous: Said Syntax Next: Tree Matching >
