Semantic constraints are used to check the validity of fuse operators under construction and are analogous to syntactic constraints . All though the mechanism for constraints is the same for both syntax and semantics the types of constraint to be tested are obviously different :-

• Category check : A constraint to check the compatibilty of the categories of the proposed fuse.
• P-Sense check : A constraint to check the compatibilty of the p-senses of the proposed fuse.
• Duplicate fusion check : A constraint to check if a duplicate fusion can be made. Duplicates are possible for conditions when snips can be made to undo the competing link (in the case of external,internal, and internal2 roles) or anytime in the case of property links.
• Check syntax constraint : A constraint to check that the proposed fuse would be consistent with the current u-model.
• Check selection restrictions : A constraint to check selection restrictions on fuses. N.B. This has been removed from version nl9702.
• Check adjacency constraint : a constraint to check adjacency for compound nouns connected with the property relation.
• Check pragmatics constraint . This constraint checks that the u-model is consistent with pragmatics. The operation of this constraint is very different from the rest as upon failing it triggers a syntactic snip. N.B. This is experimental code and not part of the automatically loaded NL-Soar code.

It is likely that these constraints will be expanded in the future. However these existing constraints are sufficient for a wide range of semantic sentences.

This page written by Mark H. Smith, April 1997.

Updated by Julie Van Dyke (vandyke@cs.cmu.edu), August, 1997