How does the semantic algebra deal with two holes with the same label?

Another semantic algebra question :slight_smile:

In section 4 of the semantic algebra paper it states the following:

The full inventory of labels for the ERG is: SUBJ, SPR, SPEC, COMP1, COMP2, COMP3, and MOD.

It then specifies that there is an operator for each type of hole (e.g. op_subj) and that the holes of the result of performing the operation is the union of the holes between the semantic functor and the semantic argument, minus the hole with the label matching the operator’s name, because this is what the operator was plugging.

So, for example, for I bake cookies, op_comp1 will plug the COMP1 hole of bake and then the holes list of the result of this composition will just be the SUBJ hole from bake, which op_subj can plug with I.

When implementing, of course, my holes were just labeled as ARG0, ARG1, etc because that’s what the predicates in the ERG have. However, I ran into an issue with this because sometimes both the semantic functor and the semantic argument would have a hole with the same label. I initially thought that this was a symptom of the ERG just having generic names, but @ebender pointed out to me that’s not really the problem.

For example, take the locked box:

  • lock has two holes: ARG1 (the locker), ARG2 (the thing that is locked)
  • box has one hole: ARG1 (box of what?)
  • First, we can use op_ARG2 to plug lock’s ARG2 with box
  • When doing this, the operator will check the holes list, find the hole labeled ARG2, and plug it with the variable in ARG0 of box
  • Then, the new set of holes for this larger SEMENT fragment should be the union of the remaining holes, that is the ARG1 from lock and the ARG1 from box
    … this is where I run into a problem.

If the holes are labeled things like ARG1, ARG2, etc. then there is no way to distinguish them. But even if they have names that specify the role of the arguments, e.g. COMP1, the same thing will happen here because they would both have a COMP1 hole. Perhaps they could be named something like ARG1_lock and ARG1_box, however this then means that op_ARG1 has to know which ARG1 from which predicate it is plugging, which doesn’t feel right.

What I ended up doing was just assuming that the holes from the semantic argument were “already handled” and only passed up the holes from the functor, but this is clearly not what’s intended in the paper, and it ended up causing me problems in certain niche cases. For example, the ERG treats the prefix un- as a predicate in some cases, so if I wanted to say the un-opened box of cookies, if I plugged the ARG1 hole of un- first with opened (which in my case I had to do, because at that step I didn’t yet know what it is exactly that was unopened) then the holes of opened are lost because it’s serving as the semantic argument and I did not pass those onward, so it became impossible to compose the semantics for something like this.

How is this sort of situation meant to be handled in the algebra?

The algebra is an attempt to formalize the syntax-semantics interface, so the operations in the algabra are intended to correspond to the syntax. That’s why the operators are things like op_subj. I don’t see how one can get the appropriate generalizations by talking about op_arg1 in an HPSG-style grammar. The algebra has to have access to the syntactic operations in the ERG (or other grammar), which is indeed a nuisance to implement.

Turning to your question - I much prefer to use the term “slot” rather than “hole” because it avoids confusion with the notion of putting fragments together when scoping an MRS. So I’ll use “slot” rather than “hole” here. The inventory of slot labels discussed in the paper is SUBJ, COMP1 etc, as you describe. The algebra paper was oversimplifying in a number of respects but, because of the standard assumptions about saturation in the syntax, I don’t think there will actually be many cases where the functor and the argument still have unfilled slots with the same slot label. The main exception that I can think of off the top of my head is where there are optional complements, so one needs a separate operation in the algebra to “discharge” those (as described in the later paper).