TomarSemanticParsing

Discussion: Discussion: ‘Semantic Parsing’ and how to talk to the rest of the world about what we do

Moderator: EmilyBender; Scribe: StephanOepen

Observations

• Growing interest in all things ‘Semantic’ in NLP
• ... including ‘Semantic Parsing’: mapping surface strings to (often task-specific) semantic representations
• This seems like a real opportunity for DELPH-IN work to have an impact, but I don't see a lot of awareness of DELPH-IN tools

Questions

• What is the most productive way to engage?
• How best to frame what we do for this community?
• Focus on one ‘view’ of grammar output, or attempt to make many accessible?

Discussion Notes

Emily is frustrated with the (poorly defined) term ‘semantic parsing’ ... what else would be the goal of parsing?

Abstract Meaning Representation (AMR) aims to do for semantic parsing what the PTB did for syntactic parsing.

Opportunity for DELPH-IN to make a contribution to a current development in the larger world.

Which kinds of target representations should we offer to others?

Woodley: Sometimes syntactic structure is what people need for tasks like, e.g. chunking, coreference

Bec: Demonstrate utility of DELPH-IN semantics not by argueing about what one should do in parsing, but rathrer via contributions to larger tasks, e.g. negation scope, relation extraction.

Francis: Work more on packaging, make more easily available pairs of strings and target representations.

Ann: Tends to give students DMRs; keep them away from having to run the parser themselves. Rather than approach the parsing community, approach the user communities. Stanford Dependencies have been successful in that respect.

Glenn:

Emily: Hold tutorial on getting and using MRSs from the ERG.

Francis: Integrate with NLTK.

Oe: Our representations are non-standard.

Jao

Antske: Lots of initial complexity for non-experts to appreciate.

Ann: Need near-perfect coverage.

Dan: Can you see that it's a fiction? The additional ten percent we would give people would be a ‘lie’.

Ann: Often need only some percentage of dependencies for some applications. But can't use ERG for coreference resolution.

Francis: Is there a real difference? Even when we parse, we can't be sure the dependencies are correct.

Antonio: Be proud of us being different: we have something that others are lacking. However, big issues: documentation and robustness.

Oe: Enju lacks 5% coverage of WSJ Treebank; for many tasks, one can fall back to features from another parser.

Woodley: JigSaw plus robust meaning composition: resurrect?

Tim: Devil's advocate: ‘semantic’ parsing, most people don't care about the semantics, they care about the application. Purer semantics won't get these people excited. In that community, also skepticism towards (scalability and sustainability of) AMR.

Bec: We could cover the robustness thing, but need to package like Stanford did.

Various: ACE is approaching a development status that makes that possible: download and run.

Emily:

Tj: Course at UW, good success using ACE and ERG ‘off the shelf’. My team actually found ACE easier to get going than Stanford coreference resolver.