Feature/langpro parse results#78
Conversation
| ccgTrees: TreeWithType[]; | ||
| } | ||
|
|
||
| function flattenResult(parse: CCGParse): FlattenedParseResult { |
There was a problem hiding this comment.
"flattening" is probably not the most appropriate term here. Suggestions are welcome!
There was a problem hiding this comment.
Lift? Collapse? Unfold?
There was a problem hiding this comment.
Unfold it is!
|
I agree with having a common tree output format for both CCG Tree and the other three terms. |
jgonggrijp
left a comment
jgonggrijp
left a comment
There was a problem hiding this comment.
This looks good to me. The only thing I'd ask you to change, is to move the types from the parse results component folder to a central place, possibly just @/types.
| </div> | ||
| } @empty { | ||
| <div class="mt-3"> | ||
| <i class="text-muted" i18n>No parse results to display yet.</i> |
There was a problem hiding this comment.
As a help to the user, perhaps write something like "press the parse and prove button to see the parse results".
| } | ||
|
|
||
| function buildBinaryNode(node: BinaryNode): TreeNodeDisplay { | ||
| const left = buildDisplayTree(node.children[0]); |
There was a problem hiding this comment.
For very large parses, recursion could lead to a stack overflow. Not something to worry about right now, but useful to know.
There was a problem hiding this comment.
Don't worry about it. Kubernetes will solve all of our problems.
(Just kidding; good point! Let's hope we never have to worry about it.)
| ccgTrees: TreeWithType[]; | ||
| } | ||
|
|
||
| function flattenResult(parse: CCGParse): FlattenedParseResult { |
There was a problem hiding this comment.
Lift? Collapse? Unfold?
There was a problem hiding this comment.
The types in this module belong in a central place, because the ParseService and also the TableauSVG component will have to refer to at least some of these types.
3 participants
This PR displays syntactic parse results in the "CCG/LLF" tab of the Annotator interface.
The backend server now sends serialized results for all four parse trees to the frontend, but only the CCG Tree is currently visualised. The other three (CCG Term, Corrected CCG Term and LLF) are transformed into an NLTK in a different way (using
parse_terminstead ofparse_ccg_tree, as indicated by @kovvalsky). This yields malformed visualisations in the frontend, which relies on the CCG Tree format.We can of course handle these two types of trees differently in the frontend, but in my opinion it makes more sense to try to arrive at a common tree output format for both CCG Tree and the other three. This is something to discuss during our next meeting.
As a bonus, this PR enables scrolling in the ParseTreeTable, so complicated sentence parses (such as SICK 1) can be shown in full without overflowing the page.