StanfordAlgebraAdditions

Revising the algebra

Here are some additional comments which may be useful for the algebra discussion:

Clarifications from presentation

Ambiguity of term `INDEX', `LTOP' etc

In DMRS, the index is a node in the DMRS graph, rather than a distinct instance variable. Since null semantics items have no nodes, they cannot have an index in that sense. However, the feature structure including the DMRS can have a feature INDEX, which could, for instance, link to a complement's index. What the DMRS treatment precludes, which is possible in MRS, is that the index is used as a sort of storage facility for properties such as tense, which can be accessed even if there are no syntactic arguments. This has consequences (predictions?) for the association of semantic properties with things like existential `it' - while it isn't completely ruled out, it would require an additional structure to be added.

Existing algebra is broken with intrinsic variable grammars

The algebra as originally defined says that the semantic head provides the slot and the hook (the index and ltop plus xarg or whatever). This worked for adjective-noun combination when we didn't use event variables on adjectives, because the hooks were equated. Once one does this with event variables on adjectives, the slot is on the adjective but the INDEX of the adjective-noun combination has to come from the noun, so we don't have a notion of semantic headedness any more. With scopal modification (adverbs like `probably'), the index comes from the modified verb and the ltop comes from the adverb, hence the hook isn't transmitted as a whole.

This could perhaps be fixed but points to a deeper issue: when we originally developed the algebra, we (at least me, and I think Alex) were influenced by previous approaches to want a notion of functor and argument, with the functor (aka semantic head) providing the slot and the hook. This is not tenable without some operation that does something drastic to the functor. Arguably this is analogous to some of the type-raising operations in conventional approaches. e.g., in lambda calculus, one can make an NP into a functor. But we always thought of this as a problem with those approaches, so this doesn't seem like a good path to go down.

Another issue is that the connection to the syntax is looser than I would like. The syntax and semantics cannot be completely isomorphic (again, this is a divergence from categorial grammars of various types) but we really would like the relationship to be regular with limited exceptions.

Modest proposal

Basics

1. We think of the algebra in terms of graphs (DAGs), since this is anyway what we're dealing with natively, and since it allows us to see the relationship of DMRS and other forms of MRS more clearly. Formalising in terms of graphs is possible but not done here, because it doesn't seem to me to improve clarity.

2. The TFS graphs have the following type of structure (abstractly):

   • [ SYN [ SYNROLE1 [1]

     • SYNROLE2 [2] ]

     • SEM < [ PRED

       • SEMROLE1 [1]

         SEMROLE [2] ] > ]

   where [1], [2] indicates reentrancy. In what follows, however, for the purposes of the algebra, I'm going to try writing the semantic graphs with additional syntactic annotations rather than keeping the graphs distinct. I expect this to go wrong, but it gives us the idea that syntax and semantics usually go together and we have to do something to disconnect them. (The hope is that what we do is less violent/unconstrained than with alternative approaches. )

3. As in the presentation, I will treat construction semantics as though it were lexical in what follows.

4. In terms of the semantics, we have the following components, much as in the original algebra:

   1. INDEX b. LTOP c. XARG d. EPs and closed links between them e. open links (= slots) The most basic principle is that nothing can happen to things in category d. other than via the other categories. This is guaranteed in the TFS implementation by never having paths into lists and by not proliferating features beyond LTOP, INDEX, XARG. BUT we may have to modify this (possibly depending on what we assume about the syntax-semantics interface).

5. Hook is retained in the dmrscomp grammar but has limited utility, since INDEX and LTOP no longer always go together. This would also apply to a revised algebra using MRS. In the dmrscomp grammar, open links always select for LTOP or INDEX, rather than accessing HOOK as a whole.

6. All composition is treated as binary. This potentially allows some wiggle room in the syntax-semantics interface in grammars where there are n-ary rules with n > 2. Specifically X -> X1 X2 X3 could be treated as X' -> X1 X2, X -> X' X3 or as X' -> X2 X3, X -> X1 X'

This is as in the old algebra. Whether we want to take this to the point where we (for algebra purposes) analyse examples like make him angry' as make (him angry)' despite the ERG binary branching, I am not sure.

1. INDEX always comes from the syntactic head (see comments at top of page about ambiguity in terminology in DMRS). LTOP normally comes from the syntactic head, but comes from the modifier in scopal modifier examples (`probably sleeps') in the dmrscomp grammar and I expect there are other cases where this will be necessary.
2. Syntax chooses the constituents, says which one is the syntactic head and chooses an open arc. The arc is typed for LTOP or INDEX, hence can choose its target.

Examples

for clarity, XARG omitted except when it's needed. Similarly /= and /neq

I like bagels

like <-ARG1.SUBJ- like -ARG2.COMP1->

both arguments select for INDEX. In DMRS, both links are /neq. In MRS, the NP LTOP is unconnected.

Bagels are liked by me

like + passive <-ARG1.COMP1- like -ARG2.SUBJ->

in terms of the old algebra (Copestake 2007 paper) the slots are transformed by the passive operation. In this notation, the syntactic labels on the open arcs are changed.

Bagels, I like

like <-ARG1.COMP1- like -ARG2.SLASH->

Again, the syntactic labels on the open arcs are changed.

Kim tried to go

go -ARG1.SUBJ.XARG ->

[1]<-ARG1.SUBJ.XARG- try -ARG2.COMP1/h-> <target> -XARG->[1]

I hope the intuition is clear, but the notation needs some thought

Kim seemed to go (raising)

go -ARG1.SUBJ.XARG ->

[1] <-SUBJ- seem -ARG1.COMP1/h-> <target> -SUBJ->[1]

When a node with a syntax only specification comes out of a target, the idea is that it may unify with an open link on the target. When it comes out of the main EP, a syntax only specification implies there is no semantic argument.

Kim made him angry

If we take the option of reconfiguring the syntax (see above), there is nothing unusual here. him angry' has the same semantics as he is angry' and `make' takes it as a scopal argument. If we don't do that, we may need to constrain this sort of pattern somehow.

<-ARG1.SUBJ- make -ARG2.COMP2-> <target> -XARG-> [1]

• -COMP1-> [1]

easy editor to try to impress

rather a guess here, since I haven't looked at its actual analysis in the ERG in any detail

to try to impress

[ 1 ] <-ARG1- try -ARG2/H-> impress -ARG1->[1]

• -ARG2-> <target1>

easy editor (INDEX is editor)

easy -MOD/=-> editor

• -ARG1/H-> <target2> -XARG->[2] -ARG2->[2]

This illustrates two things. Firstly, this is an example where we need to retain `open' links in an English DMRS - we'd already decided to do this for ICONS purposes but here we need it in the same way as some of the other grammars. Secondly, we have two open links being simultaneously instantiated. This wasn't allowed for in the original algebra. Assuming we want to allow this, we need to work out how to constrain it.