4.3.1 The Semantically Annotated Syntax Rules

The syntax-semantics interface.

Here we go providing the clean interface between syntax and semantics construction that we've just promised. Recall that so far, we've simply been using concatenation (indicated by the @-operator) to combine semantic representations while parsing a sentence, then -converting the result in a subsequent post-processing step.

In our examples before, concatenation using the @-operator was encoded directly in the DCG. For instance, the s-rule looked like this:

s(NP@VP)--> np(NP), vp(VP).

Each DCG rule is paralleled by a combine-rule.

In view of our grammar engineering principles, this is not a good practice. The crucial keywords here are modularity and reusability. We shouldn't code one particular mode of semantic construction in the syntactic rules. Instead, we will encapsulate the particular method in use into a generic predicate combine/2. Each DCG rule will include a call to this predicate (to call a predicate with a DCG rule, we have to put it in curly brackets. The predicate is then called whenever the respective rule is applied). The following examples show what our DCG rules now look like:

s1(S1)--> np2(NP2), vp2(VP2), {combine(s1:S1,[np2:NP2,vp2:VP2])}.

np1(NP1)--> det(Det), noun2(N2), {combine(np1:NP1,[det:Det,n2:N2])}.

np1(NP1)--> pn(PN), {combine(np1:NP1,[pn:PN])}.

The first argument of combine/2 is always the semantic representation passed on to the superordinate phrase. Now let's look at the way we specify the second argument. We use a little Prolog trick here: In order to uniformly have a binary combine/2, no matter how many daughters the syntax rule at hand licenses, we make the second argument of combine/2 a list. On this list, we put the semantic representations of the daughters, each one tagged with its syntactic category. So there's one item on this list if we are in a unary syntax rule, and two if we are in a binary one.

As a result of our encapsulation strategy, changing the mode of semantic construction is now solely a matter of changing the implementation of combine/2, whereas the DCG itself will always remain as shown above. Additionally, we will often need to provide some postprocessing capabilities. These may of course also have to be implemented differently for different semantic construction methods. But given our modular architecture, they can simply be plugged in and out behind the modules we're looking at right now (we will see below how all of this is done at the example of -reduction).

englishGrammar.pl: View Download

The complete set of annotated DCG rules we will use in this course can be found in englishGrammar.pl.