clay-lab / logos Goto Github PK

Right now, the definition for the single reflexive 'Himself' is not parsed correctly. We should fix that.

Complex semantic representations involving quantifiers, lambda expressions, and so forth, require the use of variables. Compare the following sentences and their parses.

Alice sees Bob			see ( alice , bob )
Everyone sees Alice		all x . ( person ( x ) -> see ( x , alice ) )
Everyone sees Everyone  	all x . ( person ( x ) -> all z1 . ( person ( z1 ) -> see ( x , z1 ) ) )

The symbols x and z1 in the previous expressions are variables. It's difficult for the network to determine these symbols since they aren't deterministic based on the input, but rather on what sentences were previously generated by the grammar. To get around this, we could opt for nameless variables, like De Bruijn indices, or require that all variables be numbers and then resetting the counter (somehow?) so that they are deterministic.

Turn the semrep object produced for each sentence into an nltk Tree object that can be thrown into a TreeDecoder.

Right now, the semrep for a sentence doesn't have any spaces around the functional symbols. For example,

Alice sees Bob -> sees(alice,bob)

We want to include spaces before and after these symbols to make Seq2Seq translation easier, so the same sentence should look like

Alice sees Bob -> sees ( alice , bob )

The best way to do this is probably to override the __format__ method of ApplicationExpression (the type of semrep).

Commit 6fd57de formats Expression output to have spaces around each functional symbol. This is accomplished by swizzling the __str__ methods on several subclasses of Expression. This fix is brittle for two reasons.

1. It is not immediately clear how changing the __str__ methods on each of these Expression subclasses affects the others; adding a space to one may mean that we have extra spaces in the final output.
2. This doesn't automatically extend to more complex semreps. It may very well be the case that adding in different types of Expression to the semrep results in new formats which haven't yet been swizzled.

Therefore, it is imperative that we create a set of unit tests which verify (1) that no extraneous spaces have been added to the output and (2) confirm that every new type of expression is not broken in the future. We may also want to add some kind of check for an output file to independently verify that there are no adjacent functional symbols, though this may be an undefinable problem due to the confusion of, say, a variable x and a symbol beginning with x, like xylophone.