I am trying to treebank using the fftb. I have filtered out items with non-empty parses. However, for some parses, fftb says “0 remaining” even before annotation (other parses did show to have non-zero parses remaining before annotation). Follow is a screenshot of what I was shown for some parses:
Does anyone know what could be causing this? Any help would be appreciated!
I think this is different because there are 0 parses (“remaining” , but in fact this is the initial state). My guess is that there is a parse forest but it contains no valid trees. @sweaglesw could that lead to this behavior?
If so, then your move @yclin is to “reject”.
This situation seems surprising to me if it came from picking item id’s with tsdb select i-id from edge. ACE normally only records edges that are connected to a root edge, and the existence of a root edge implies the existence of at least one tree. Whether the tree is “valid” in the sense of surviving reconstruction should not be relevant at this stage of the game. It’s conceivable the unreachable edges got recorded (by passing more than one -O flag to ACE during the creation of the full forest profile), which could lead to a situation like this.
Are there any interesting messages from FFTB on the console?
Also, what do you find in the edge file for the item ID in question? You could try something like:
$ tsdb -home path/to/my/profile
# select e-label e-start e-end from edge where i-id = 20.
… or you could just poke around in the edge file by hand.
When I clicked on the item (in FFTB) that says to have “0 (parses) remaining”, the terminal showed the following message (I modified the input part in item id 20 -> input '{item 20 of the source language}' because I’m not sure whether I’m allowed to show the data publicly):
should GET /private/parse?profile=/&id=20
item id 20 -> input '{item 20 of the source language}'
profile parse id 20
-> loaded stored forest
found stored forest (0 edges connected to 0 roots).<br/>
UCSTAT: input 0 edges, output 0 edges
For the relevant part of the item in question, I was not sure how to check it out – when I tried the command:
$ tsdb -home path/to/my/profile
I got the error message saying
main(): no history file `.tsdb_history'.
so it showed nothing after I typed
# select e-label e-start e-end from edge where i-id = 20.
I also tried to look at the edge file directly but it was a bit confusing to me…is the relevant part of an item listed in the corresponding position in the edge file? That is, is the relevant part of item 20 (i.e., the item ID is 20) the 3rd line in the edge file (since the item ID starts with 0)?
The message about the history file is safe to ignore. You got nothing after the select command because the result was empty, not because of a failure. The message from FFTB on the console also seems to confirm that there was nothing in the edge relation for item id 20. But then it is surprising to me that item id 20 is included in the list of IDs to be processed. If you run “select i-id from edge” in tsdb, is 20 among the values returned? It seems like it shouldn’t be.
Do you mean running select i-id from edge after tsdb -home path/to/my/profile? It was showing nothing a I after running the two commands, as shown in the following screenshot.
However, when I ran
tsdb -home mrs -query 'select i-id from edge'
I did see 20 in the returned list of values.
An update on this issue in case other people also encounter this in the future:
I checked the results with LKB as well. After filtering out items with non-empty parses, some of the remaining items might still be shown to have “0 remaining” parses in the fftb – these items were also shown to have no parses in the LKB.
If anyone encounters this in the future, it may be worth checking the results in the LKB as well! 