Glue and the docu online

[Damir Cavar]

Hi there,

I just read at

https://www.nltk.org/howto/gluesemantics_malt.html

that

"""

Checking for equality of two DRSs is very useful when generating readings of a sentence. For example, the glue module generates two readings for the sentence John sees Mary:

>>> from nltk.sem.glue import DrtGlue
>>> readings = drtglue.parse_to_meaning('John sees Mary'.split())
>>> for drs in sorted([r.simplify().normalize() for r in readings], key=str):
...     print(drs)
([z1,z2],[John(z1), Mary(z2), sees(z1,z2)])
([z1,z2],[Mary(z1), John(z2), sees(z2,z1)])

However, it is easy to tell that these two readings are logically the same, and therefore one of them is superfluous. We can use the theorem prover to determine this equivalence, and then delete one of them. A particular theorem prover may be specified, or the argument may be left off to use the default.

>>> readings[0].equiv(readings[1])
True

"""

I do not know what this is about. My understanding of the lexical semantic of "to see" is not that it is symmetric and the two readings do not make sense, just the first. But this misunderstanding might be due to my lack of understanding of Glue, resource logic, or linear logic in general.

Independent of that, a more general question:

Is anybody still actively working on Glue (not necessarily in the context of Malt and DGs)? If so, who is pushing this effort?

Thanks a lot!

DC

[Damir Cavar]

Got it, the reverse order of the arguments in the two different sees in the code... ah... Sorry for the confusion. :-)

Independent of that, I would still be interested in the glue part of NLTK, and even the question whether anybody was thinking about integrating a LFG parser in NLTK. Maybe there is one and I did not find it.

Thanks!

DC

—

Damir Cavar

http://damir.cavar.me/

On Feb 26, 2020, at 2:17 PM, Damir Cavar <damir...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "nltk-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nltk-dev+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/nltk-dev/bb3be04d-527d-4bf4-b1bc-e1a75d25c163%40googlegroups.com.

[Steven Bird]

I expect there are Python implementations of LFG... if so, I'm not sure what we would achieve by including it in NLTK. Perhaps it could use NLTK's implementation of feature structures, assuming that this was sufficiently expressive.

-Steven

To view this discussion on the web, visit https://groups.google.com/d/msgid/nltk-dev/69D91763-83AC-4A58-B76B-D1C86A883569%40gmail.com.

[Damir Cavar]

Hi Steven,

I don’t know of any Python implementation of an LFG parser, not even of any other kind of implementation besides XLE and XLFG. It does not really matter, whether somebody would write one in Python and integrate it in NLTK. The question is rather whether anybody DID work on that kind of project in the NLTK context. Making a parser that would be close to the formalism that is covered by XLE would be beyond a simple exercise or hobby kind of implementation. This would be serious effort. I would not even try to implement it in Python, maybe in Cython. I did work on such a project in C++. Quite complex. :-)

The other question is, whether anybody works on Glue right now. Is it where it was when the book came out or is this still under active development.

I don’t want to even argue for somebody working on that as part of NLTK or adding this to the NLTK infrastructure. One could just integrate XLE in NLTK, but XLE is not free.

A completely new architecture with weighted or probabilistic unification, a probabilistic c-structure backend, that kind of stuff would make sense, and implementing compatibility with XLE might only make sense for reasons of sustainability of quite some important and impressive grammars that consumed a couple of expert person years to develop.

Thanks!

CU

DC

—

Damir Cavar

http://damir.cavar.me/

On Mar 7, 2020, at 6:51 PM, Steven Bird <steve...@gmail.com> wrote: