;;; ;;; This file is part of the English Level 2 Language model. It should be ;;; kept in the same directory as the accompanying files `english.grm' and ;;; `l2global.set'. Do not read any further; if you feel you have to, do not, ;;; under no circumstances, whatsoever, change any of the following. ;;; encoding := utf-8. include "global". ;; ;; suppress results of regular morphology rules if irregular form exists ;; irregular-forms-only. lex-entries-can-fail. ;; ;; names of attributes not to pass from daughter to mother in parsing ;; deleted-daughters := ARGS HD-DTR NH-DTR LCONJ-DTR RCONJ-DTR DTR1 DTR2 DTRA DTRB DTR. ;; ;; names of attributes to filter for packing parser ;; packing-restrictor := RELS HCONS RNAME. ;; ;; path into the MRS semantics ;; mrs-path := "SYNSEM.LOCAL.CONT". ;; ;; 'characterization': path to CFROM/CTO ;; mrs-cfrom-path := "SYNSEM.LOCAL.CONT.RELS.LIST.CFROM". mrs-cto-path := "SYNSEM.LOCAL.CONT.RELS.LIST.CTO". ;; ;; path to LABEL for relation-to-word mapping, absolute and within a relation ;; label-path := "SYNSEM.LKEYS.--KEYREL.WLINK". label-path-tail := "WLINK". ;; ;; name of type containing quick check structure ;; qc-structure := $qc_paths_set. ;;; ;;; based on selectional dependencies between lexical entries, reduce chart ;;; right after lexical look-up: `chart-dependencies' is a list of pairs of ;;; paths into lexical entries. the type of the node at the end of the first ;;; path in one lexical entry makes that entry depend on the existence of some ;;; other lexical entry that has that same type as the value of the node at the ;;; end of the second path. ;;; ;;; _fix_me_ ;;; not entirely sure, but it must (in principle) be possible to saturate a ;;; dependency from lexical and grammar rules. say, a lexical entry selected ;;; for something nominalized, and that relation was introduced by a lexical ;;; rule, in turn. unless this is the case already, compute static list of all ;;; relations introduced by rules (which, presumably, requires another setting ;;; to declare how to find constructional semantic contributions; C-CONT) and ;;; consider all such dependencies on lexical entries always saturated. ;;; (11-oct-02; oe) unidirectional-chart-dependencies. chart-dependencies := "SYNSEM.LKEYS.--+COMPKEY" "SYNSEM.LOCAL.CAT.HEAD.KEYS.KEY" "SYNSEM.LKEYS.--+OCOMPKEY" "SYNSEM.LOCAL.CAT.HEAD.KEYS.KEY" "SYNSEM.LKEYS.--COMPHD" "SYNSEM.LOCAL.CAT.HEAD" "SYNSEM.LOCAL.--+SUBJIND" "SYNSEM.--SIND" . ;;; ;;; some rules should be constrained to only apply over the entire string, i.e. ;;; to edges that span the full input; this should improve parsing efficiency ;;; only, rather than be considered part of the linguistic analyses. ;;; spanning-only-rules := $runon_s $frag_nocop_s $frag_pp_sl $frag_vp_sl $frag_l_mod_adv $frag_l_mod_vp $frag_r_mod_np $frag_r_mod_i_pp $frag_r_mod_i_pp $frag_r_mod_s_pp $frag_r_mod_ap. ;;; ;;; generic lexical entries for unknown words: basically, for each unknown ;;; token in the input all generic entries are postulated. optionally, there ;;; are two devices to filter out generic entries: suffix-based and by virtue ;;; of POS tag information. generic entries that require a certain suffix ;;; (`generic-le-suffixes') only fire if the input form has the suffix. if ;;; the input word has one more more POS tags associated to it, these are ;;; looked up in the `posmapping' table: this table is a list of pairs (tag, ;;; gle) where `gle' is the name of one of the generic items in `generic-les'. ;;; a non-empty `posmapping' table will filter all generic entries that are not ;;; explicitly licensed by a POS tag. ;;; generic-lexentry-status-values := generic-lex-entry. ;;; ;;; some generic lexical entries require inflectional marking. this mechanism ;;; is a filter on which generic entries proposed by other means can survive: ;;; generic entries listed here will only be postulated if the required suffix ;;; can be matched against the input token. ;;; ;;; when using only generic entries licensed by a POS tag, the suffix filter ;;; really does not make a lot of sense anymore. (6-jun-03; oe) ;;; generic-le-suffixes := $generic_trans_verb_pres3sg "S" $generic_trans_verb_past "ED" $generic_trans_verb_psp "ED" $generic_trans_verb_prp "ING" $generic_pl_noun "S" ;; ;; when running without a POS tagger, effectively disable a few generics ;; $generic_adj_compar "_block_" $generic_adj_superl "_block_" . posmapping := UpperAndLowerCase $genericname UpperAndLowerCaseInitial $genericname JJ $generic_adj JJR $generic_adj_compar JJS $generic_adj_superl NN $generic_mass_count_noun NNS $generic_pl_noun NNPS $generic_pl_noun NNP $genericname FW $generic_mass_noun RB $generic_adverb VB $generic_trans_verb_bse VBD $generic_trans_verb_past VBG $generic_trans_verb_prp VBN $generic_trans_verb_psp VBP $generic_trans_verb_presn3sg VBZ $generic_trans_verb_pres3sg #| JJ $generic_adj JA $generic_adj JB $generic_adj JBR $generic_adj_compar JBT $generic_adj_superl JJT $generic_adj_superl NN $generic_mass_noun NN1 $generic_sg_noun NN2 $generic_pl_noun NP1 $genericname NP2 $genericname NNSB $generic_title_noun NNSB1 $generic_title_noun NNSB2 $generic_title_noun RR $generic_adverb VV0 $generic_trans_verb_bse VV0 $generic_trans_verb_presn3sg VVD $generic_trans_verb_past VVD $generic_trans_verb_psp VVN $generic_trans_verb_psp VVN $generic_trans_verb_past VVG $generic_trans_verb_prp VVZ $generic_trans_verb_pres3sg |# . ;;; ;;; the setting `pos-completion' enables an additional mechanism to do with ;;; processing of generic lexical entrie: whenever we receive POS information ;;; as part of the input, we check to see whether the built-in lexical entries ;;; suffice to satisfy the POS annotations: each lexical entry retrieved for an ;;; input token ;;; ;;; ;;; ;;; is mapped to an application-specific POS tag, using the `type-to-pos' map, ;;; and checking the type of each lexical entry for subsumption against the ;;; left-hand side of each `type-to-pos' rule. some or all POS annotations ;;; from the input may be `satisfied' under this mapping by built-in lexical ;;; entries, e.g. for the example above, there may be lexical entries whose ;;; type maps to `pos_1' and `pos_3'; unless all POS annotations are satisfied ;;; after all built-in lexical entries have been processed, the remaining POS ;;; categories are processed by the regular `posmapping' look-up. note that, ;;; as a side effect, an empty `type-to-pos' map will always result in having ;;; all generic lexical entries activated (modulo the filter describe above), ;;; even for input tokens that were found in the native lexicon. ;;; #| pos-completion. type-to-pos := basic_noun_word NN basic_noun_word NNS basic_noun_word NNP basic_pronoun_word NN basic_pronoun_word NNS basic_pronoun_word NNP . |# ;;; ;;; as of august 2003, PET includes ECL and the generic (R)MRS code; hence, we ;;; need to include the MRS settings from the grammar. ;;; postload-lisp-files := "lkb/mrsglobals.lsp". ;;; ;;; and as of august 2006, the MRS variable property mapping (VPM) can now be ;;; activated as a configuration parameter. (26-aug-06; oe) ;;; vpm := "semi". ;; 'preprocessor': FSPP rule file preprocessor := "preprocessor.fsr". ; insert surface form of ersatzes at end of this path ersatz-carg-path := "SYNSEM.LKEYS.KEYREL.CARG".