• Keine Ergebnisse gefunden

7.4 The Implemented Grammar

7.4.1 The Rules

Overall, the implemented rules are a fairly straightforward formalisation in the notation used in the

LKBof the constraints we have shown in the previous section. We will not go through all the rules in detail here, and only point out where the implementation departs from the analyses from the previous section.12

There are two major points of deviation. First, for technical reasons, theERGdoes not make use of de-faults (although theLKBsupports their use), and so we cannot use the generalised head-feature principle from the previous section, which there simplified the presentation of the constructions. For this reason, it was not possible to use in the implementation the featureHEAD-DTR(on which the monotonic head-feature principle will work and from which it would take the value ofHEADfor the construction, even when the fragment-phrase is an NP and the resulting fragment-construction should be of sentential type);

rather, we had to introduce special featuresFRAGH-DTR(for fragment-head-daughter) andFRAGNH

-12The rules are printed in the appendix, with extensive comments. Also, adiff-file with which a copy of theERGcan be extended with the fragment rules is available on request from the author.

DTR(fragment-non-head-daughter), from which the head of the fragment-construction is available. To give an example, in a fragment like “probably Sandy”, the NP is the fragment-head-daughter and the ADV the non-head daughter.

The other deviation from the analysis of the previous section is that rather than analysing adverbs as sisters of unknown, as described above in (285), here we have them outscope that relation. As explained in Section 6.4.2, this means that the ULFs coming out of the grammar do not describe all possible readings. However, this analysis is technically simpler, because it does not require changes to be made to the analysis of adverbs in the grammar, and also, as described in that section, the readings that are lost are relatively marginal.

The organisation of the rules into dimensions is as shown above in Figure 7.5; however, we here have a common supertype frg above the types msg-type, frg-type and frg-arg-type, which collects all con-straints that are common to all different fragment-constructions. The specification of this type is shown in the following.

frg := non_headed_phrase & rule &

[

SYNSEM synsem_min &

[ LOCAL [ CAT s_cat_fin_unspec &

[ HEAD verb & [ AUX -, INV -, MOD < > ], VAL [ SUBJ <>,

SPR <>, COMPS <>, SPEC <>]

], CONJ cnil,

KEYS.MESSAGE <! #msg !> ], NON-LOCAL non-local_none

],

C-CONT [ TOP #ctop, INDEX #event, E-INDEX #event,

LISZT [ LIST < message & #msg & [ HANDEL #ctop ], unknown_rel & [ EVENT #event ]

> ],

H-CONS [ LIST < geq, ... > ] ],

FRAGH-DTR sign & [SYNSEM.NON-LOCAL.SLASH 0-dlist], FRAGNH-DTR sign

].

To give a feel for the rules as they are implemented, and also to give an idea of how theERGin general works, let us dissect this rule in the following. We begin with the first line:

frg := non_headed_phrase & rule &

This says that the type frg inherits constraints from non headed phrase and from rule. The former type specifies that the phrase built with this rule (or, equivalently, the sign satisfying these constraints) does not have a head-daughter. We have to do this to block the head-feature principle from applying, for the reasons given above. The other parent-type, rule, introduces a list-valued feature for arguments.

The next few lines give the specification of the syntactic face of fragment-signs:

[

SYNSEM synsem_min &

[ LOCAL [ CAT s_cat_fin_unspec &

[ HEAD verb & [ AUX -, INV -, MOD < > ], VAL [ SUBJ <>,

SPR <>, COMPS <>, SPEC <>]

], CONJ cnil,

KEYS.MESSAGE <! #msg !> ], NON-LOCAL non-local_none

],

In order, these specifications say that fragment signs belong to the category s cat fin unspec, i.e. behave syntactically like sentences with a finite verb. The additional specifications constrain this further, by postulating that the ‘verb’ is not an auxiliary (AUX-) and not inverted (INV-), can’t modify anything (MODis an empty list,hi), and has all its valency requirements satisfied (note that this is not redundant, since s cat fin unspec does not specify all of this). The specification of CONJas cnilblocks these signs from entering into coordination, whereas the value ofKEYS.MESSAGEmakes the message-type of the ‘sentence’ something that is selectable for other rules. Finally, the value ofNON-LOCALis specified to be empty, which prevents this sign from unifying with anything that wants to fill a gap.

This leaves the semantic contribution of the construction type ‘fragment’, which is as shown below:

C-CONT [ TOP #ctop, INDEX #event, E-INDEX #event,

LISZT [ LIST < message & #msg & [ HANDEL #ctop ], unknown_rel & [ EVENT #event ]

> ],

H-CONS [ LIST < geq, ... > ] ],

This specifies that the top-handle of the construction will be the handle of the message-relation of the fragment (be that prpstn, decl or imp), and that the main event is contributed by the unknown-relation.

Moreover, this specification says that at least one scope-constraint is contributed by this construction.

Finally, it is this type where the featuresFRAGH-DTRandFRAGNH-DTRare introduced. We can also already on the mother-type of all fragment-constructions specify that the fragment-phrases are not

al-lowed to contain gaps; this rules out ill-formed fragments like “the father of”, which otherwise would be allowed (as an NP containing a gap where the complement of the preposition is).

FRAGH-DTR sign & [SYNSEM.NON-LOCAL.SLASH 0-dlist], FRAGNH-DTR sign

].

The types for the three dimensions now are direct daughters of this general type:

frg_md :< frg.

frg_arg :< frg.

frg_mood :< frg.

The type frg md (for fragment-modification) has two daughters, one for fragments that are modified by an adverb and one for those that aren’t. Modification works basically as described above in (286) in the previous section, with some feature names being different. frg arg is a more diverse hierarchy, with sub-types for altogether six different arguments categories (NPs, lexical and functional PPs, VP[inf ], VP[bse] and S[comp]; we do not provide analyses for the other types mentioned above); again the con-tribution of the subtypes is as shown in the previous section, in Section 7.3.2. The type frg mood then finally has only two daughters, one for interrogative and one for declarative fragments. As the reader will have noticed, this leaves out imperative fragments; moreover, we make the restrictive assumption here that only wh-phrases are interrogative fragments. Both restrictions are made for the same reason: since obviously no information about verb-inversion for example is available, the only remaining information source for distinguishing for example “Peter.” from “Peter?” or “Peter!” would be interpunction (or, in the case of a speech recognition grammar, intonation). The parsing system we use, however, does not (at the time of writing) exploit this information, and so to avoid multiplying parses (by giving three ana-lyses for e.g. “Peter”) we have decided for this restrictive approach. This, however, is not a conceptual necessity and could be changed if needed.

All in all, this results in 18 different construction types as the nodes of this hierarchy, which through multiple inheritance can be specified very parsimoniously, as the example for non-modified interrogative NP-fragments shows:

np_nm_i_fragment := np_fragment & frag_int & fragment_nm.