Function for iterating over scope readings

[goodmami]

#211 describes a module for scope operations. The current implementation for v1.0.0 satisfies the goals complete except for a function to iterate over scope readings. I'm creating this issue for that last function, in case it needs to be delayed to a later release.

[arademaker]

Not sure if I understood what '...a function to iterate over scope readings..' means. The code for generating scoped MRSs from a given MRS is already in the library or not ? Sorry, I didn't get.

[goodmami]

A non-scope-resolved structure is ambiguous over one or more scope-resolved structures. To iterate over scope readings is to expand the ambiguous structure to those resolved structures and iterate over them (e.g., in a for-loop, or the function could just return a list of scope-resolved MRSs).

As the text of this issue states, a function to do this is not yet present in the library. You can see the documentation for the delphin.scope module to see what is currently available.

[arademaker]

Yes, the first part was already completely clear to me. The second part is not so much. Actually, the comment in #241 is not clear at all.

it looks like the actual code for producing all possible scoped trees is not trivial. One naive approach is to collect all holes and handles. Produce all possible permutations of them, filtering the ones that violate any HCONS constraint. But we need to check all predications on each LABEL/scope and also consider that no variable can be 'used' before its introduction by a quantifier.

[goodmami]

Yes, the first part was already completely clear to me. The second part is not so much.

Maybe some pseudocode would help?

>>> m = simplemrs.load(...)         # an MRS with underspecified quantifier scope
>>> for _m in scope.resolve(m):     # iterate over scope readings (this issue)
>>>     print(simplemrs.dumps(_m))  # prints the scope-resolved MRS

Actually, the comment in #241 is not clear at all.

Well, #241 is really about representing the underspecified scopal tree fragments than resolving the structures, so maybe it's less relevant for you.

it looks like the actual code for producing all possible scoped trees is not trivial. One naive approach is [...]

It's been a while since I've attempted to write the function, but I recall that naively enumerating all and checking for constraint violations is intractable (for similar reasons this issue describes the function as "iterating" over readings instead of returning a list; it would take too much time and memory to construct the full list for longer sentences). It's better to get the partial orderings from qeqs, etc., first and then only enumerate the feasible ones.

[arademaker]

I am trying to make sense from the LKB code, but not trivial! Hope that eventually @john-a-carroll can help me to read it. It seems that some extra checks for implicit existentials may pre-date some new expected conditions of MRSs

[arademaker]

https://www.coli.uni-saarland.de/projects/chorus/utool/ can be integrated with LKB via server-mode. That could be a good starting point for PyDelphin too, don't you think?

[goodmami]

Possibly, yes, but I'm concerned about two things:

• Does it run with a modern version of Java? (I haven't tested)
• Koller's & Thater's work with MRS used a different interpretation of handle constraints (qeqs are dominance constraints, IIRC) which might not be how we generally do things. But if the LKB is able to accommodate then surely it must be possible.