In a nutshell, the issue is that chart realization algorithms in the tradition of Kay (1996) require the semantics to be linear in the sense that no semantic material can be dropped or duplicated, and my article goes through how this issue plays out for doing realization with CCG from Hybrid Logic Dependency Semantics (HLDS); in particular, the article gives an argument for why you'd want to use distinct (albeit logically equivalent) representations for eg "Kim and Sandy smile" and "Kim smiles and Sandy smiles" in order to allow the content and sentence planner to exert control over aggregation choices.
That said, there are shortcomings to the HLDS semantics that could be overcome with judicious use of lambdas. An interesting strategy might be to encode lambda terms as HLDS graphs in a way that preserves linearity, as this would retain compatibility with the realizer. For an approach along these lines, the concerns discussed by Moore (ACL-89) remain relevant: http://www.aclweb.org/anthology/P/P89/P89-1005.pdf
In principle, OpenCCG could also be reworked to use lambda semantics directly; indeed, the initial design even included an LF interface to keep open the possibility of plugging in different semantic representations. However, this would require fairly major surgery at this point and most likely require giving up on making the realizer work. As such, it would make sense to at least look into the alternative of using a different framework or developing one's own, depending on the intended usage. For example, Yoav Artzi's Cornell/UW Semantic Parsing Framework (http://yoavartzi.com/spf) and Mike Lewis's EasyCCG and EasySRL (see http://lil.cs.washington.edu/easysrl/demo.cgi) both use lambdas, and the C&C parser outputs CCG derivations (there's also now a Java version: https://www.cl.cam.ac.uk/~sc609/java-candc/report.pdf).
Hope that helps
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mike
Thanks for all this info, I am following up the different threads. I got into this from wanting to understand what could be done in syntax with slash modalities, while sticking with lambda calculus semantics. Mainly I'm interested in the parsing direction, who knows. -- Mats
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see -- I believe OpenCCG is the only framework that implements slash modalities, so you might try using Moore's (1989) lambdas-only-where-necessary approach with OpenCCG, otherwise rolling your own might be your best bet. Broad coverage approaches with CCG have not implemented slash modalities (to my knowledge) because they can get away with only using category combinations that have been observed in training, which has the effect of prohibiting most if not all of the category combinations that slash modalities rule out.
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there any methodology for using lambda calculus terms for the semantics (in place of the feature logic, or coded in it)?
Hi Mats
There is some discussion of related issues in my article on the realizer in Research on Language and Computation (prior to the work with a CCGbank-derived broad coverage grammar): http://www.springerlink.com/content/e1q6xr0u3rr54173/; http://www.ling.ohio-state.edu/~mwhite/papers/White-RoLC-2004-to-appear.pdf
In a nutshell, the issue is that chart realization algorithms in the tradition of Kay (1996) require the semantics to be linear in the sense that no semantic material can be dropped or duplicated, and my article goes through how this issue plays out for doing realization with CCG from Hybrid Logic Dependency Semantics (HLDS); in particular, the article gives an argument for why you'd want to use distinct (albeit logically equivalent) representations for eg "Kim and Sandy smile" and "Kim smiles and Sandy smiles" in order to allow the content and sentence planner to exert control over aggregation choices.
That said, there are shortcomings to the HLDS semantics that could be overcome with judicious use of lambdas. An interesting strategy might be to encode lambda terms as HLDS graphs in a way that preserves linearity, as this would retain compatibility with the realizer. For an approach along these lines, the concerns discussed by Moore (ACL-89) remain relevant: http://www.aclweb.org/anthology/P/P89/P89-1005.pdf
In principle, OpenCCG could also be reworked to use lambda semantics directly; indeed, the initial design even included an LF interface to keep open the possibility of plugging in different semantic representations. However, this would require fairly major surgery at this point and most likely require giving up on making the realizer work. As such, it would make sense to at least look into the alternative of using a different framework or developing one's own, depending on the intended usage. For example, Yoav Artzi's Cornell/UW Semantic Parsing Framework (http://yoavartzi.com/spf) and Mike Lewis's EasyCCG and EasySRL (see http://lil.cs.washington.edu/easysrl/demo.cgi) both use lambdas, and the C&C parser outputs CCG derivations (there's also now a Java version: https://www.cl.cam.ac.uk/~sc609/java-candc/report.pdf).
Hope that helps
Mike
Hi Mike
Thanks for all this info, I am following up the different threads. I got into this from wanting to understand what could be done in syntax with slash modalities, while sticking with lambda calculus semantics. Mainly I'm interested in the parsing direction, who knows. -- Mats
I see -- I believe OpenCCG is the only framework that implements slash modalities, so you might try using Moore's (1989) lambdas-only-where-necessary approach with OpenCCG, otherwise rolling your own might be your best bet. Broad coverage approaches with CCG have not implemented slash modalities (to my knowledge) because they can get away with only using category combinations that have been observed in training, which has the effect of prohibiting most if not all of the category combinations that slash modalities rule out.
Mike