-
Notifications
You must be signed in to change notification settings - Fork 5
Core Grammar: Content and Partitioning
Contact: For questions, contact seantrott@icsi.berkeley.edu
- Overview
- Packaging System
- Basic Phenomena
-
Packages for Specific Phenomena
- Copulas
- Intransitive Constructions
- Transitive Constructions
- Ditransitive constructions
- Change
- Negation
- Mental Argument Structure
- Control Argument Structure
- Explicit Causation
- Catenatives
- Auxiliaries
- Modals
- Gerunds
- Adjunct VPs
- Serial VPs
- Particles
- Conditionals
- Temporality
- Metaphor
- Indirect Speech Acts
- Relative Clauses
- Uncovered Phenomena
This page describes the content and current state of the "core" ECG grammar. The core grammar is meant to cover a range of English syntax and embodied semantics, and should be generalizable across various domains to enable language understanding and interaction with autonomous systems.
One valuable tool of the ECG 2.0 Environment is the ability to "package" subsets of grammar - constructions and/or schemas - to build dependency structures, and import into other grammars as needed. This functions much like modules or packages in code. Furthermore, since a grammar's size affects the efficiency of the ECG Analyzer, it gives a grammar designer or system integrator more control over the content of the grammar. For example, in a domain involving motion and force application, metaphor and abstract concepts might not be relevant, but in a domain involving inference about economic policies and states (Narayanan, 1997), both packages might be needed.
Packages can be declared with the package keyword:
package core
Dependencies for a package can be declared with the import keyword:
import auxiliaries
All constructions and schemas listed under a package declaration are assigned to that package, and are only imported into the grammar if that package is "active". By default, the "global" package is active, but the user can also add the main packages in the prefs file:
PACKAGE_NAME ::==
core
universal-schemas
;
This means that any constructions or schemas in the "core" or "universal-schemas" package will be active, and that any packages explicitly imported by "core" or "universal-schemas" will also be imported in the grammar (and any packages imported by those, etc.): the packaging system has a "chaining" analogous to that found in code packaging dependencies.
See more documentation on the prefs file here.
In ECG, nominal constructions (Nouns, NPs, Kernels, etc.) have a meaning of RD, or ReferentDescriptor. The RD schema contains a number of roles, including:
givenness
ontological-category
number
gender
referent
bounding
extensions
scale
extras
RD Extras
The RD.extras role uses the RDExtras schema, which itself contains several roles:
event
quantity
specificWh
These roles are only filled if an utterances uses constructions that fill them, e.g. "his pushing the box", "2 boxes", or "which box".
Extensions
The extensions role has not been fully explored, but is intended to allow Nominals to evoke a frame-based meaning, such as you might find in FrameNet. This is useful for Nominals with particularly rich or relevant semantics, such as "hammer", which is an Instrument, or "house", which is a Container and an Artifact.
Kernels
The Kernel constructions enumerate a number of constructional patterns in which Nominals can be joined with other parts of speech, such as Adjectives and Prepositional Phrases.
Types
A major development in the ECG 2.0 Environment is the introduction of types and tokens. The "core" grammar comes with a wide range of NounTypes built in, including...
InstrumentNoun
SubstanceNoun
AbstractNoun
... and more.
Tokens can be added to the grammar with the Token Tool.
Verbs and VPs in ECG have a meaning of Process. Process is a very high-level schema with the following roles:
protagonist
actionary
p-features
ed
The p-features role is mapped onto the ProcessFeatures schema, which contains grammatical information such as:
tense
perfect
progressive
temporality
voice
negated
The ed role is mapped onto the EventDescriptor schema (see description on sentence constructions below).
Constructionally, Verbs appear in Argument Structure constructions. Most of this page is devoted to different types of Argument Structure constructions, including transitive constructions, intransitive constructions, and ditransitive constructions.
Types
As with Nouns, lexical Verbs have been partitioned into semantic/syntactic types. These have a more significant impact on the grammar and SemSpec than the NounTypes, because in our implementation of ECG, Verbs take on richer and more nuanced frame-based meaning than Nouns (which always have a meaning of RD).
The Process schema lattice is quite complex, and includes semantics ranging from MotionPath to CauseHarm and Perception.
Sentences in ECG have a meaning of EventDescriptor. An EventDescriptor contains the following roles:
eventProcess
profiledProcess
profiledParticipant
e-features
eventForm
The EventDescriptor.e-features role maps onto the EventFeatures schema, which contains the following roles:
subord
telicity
duration
time
tense
modality
negated
place
The standard Sentence-With-Subject construction contains an NP subject and a finite VP. The subject is mapped onto the profiledParticipant role. Once the VP's evoked EventDescriptor is unified with the Sentence's meaning pole, the role bindings propagate downward, to the specific eventProcess and profiledProcess evoked by the verb.
Properties/Adjectives
Discrete properties, such as red in the red box, are handled using the PropertyModifier schema, and instantiated in the PropertyAdjectiveType construction. The information from this schema is later inverted by the Core Specializer and added to the n-tuple. Similarly, statements like the box is red encode the property information as part of the “state” or predication.
Continuous or scalar properties use a ScalarModifier schema (subtype of PropertyModifier), and instantiated in the ScalarAdjectiveType construction. Here, the value is meant to be a @scalarValue, such as “.7”. This signals to the Core Specializer that the n-tuple value ought to be a number rather than a string. Structurally, these can be expressed using many of the same constructions as discrete modifiers, such as the big box or the box is big. There is also an additional role called scale, which maps onto the Scale schema.
Examples:
the red box
the big red box
Adjectives are joined with nouns using a Kernel-Adjective construction, and are used as predication in a sentence like the box is red in the CopularVPAdjective construction.
Adverbs
Adverbials also use the Modification schema, but the modifiedThing is a Process, as opposed to an RD. We have implemented basic AdverbialVP constructions, which combine an Adverb and a VP. The Core Specializer then incorporates the Adverbial information into the resulting n-tuple.
In ECG, prepositional phrases are defined and organized semantically. The high-level PP construction defines a PP as containing a preposition and an NP, but does not impose any particular semantics. More specific PPs inherit from this general PP, and form a lattice structure.
For example, we have defined a general SpatialPP, which is further divided into notions of a Locative-PP...
near the house
in the room
on the table
...and a Path-PP, which could include phrases like:
into the room
through the hallway
from the house
Spatial-PPs have a meaning of TrajectorLandmark, which is a high-level concept in cognitive linguistics. More specific PPs, like a Path-PP, uses the SPG schema (Source-Path-Goal).
Other PPs we have defined include an InstrumentPP, AccompanimentPP, and TemporalPP, all of which are defined as AdjunctPPs (see adjunct vp), but which have different semantics.
Prepositions
Often, the prepositions provide many of the semantic bindings. For example, both "from" and "through" evoke the SPG schema, but they bind the landmark role to the source and path roles, respectively.
There are many packages in the grammar. We find it helpful to use a "main" file, such as argstruct-packages to govern which packages are active.
In general, the copulas package allows the ECG Analyzer to parse sentences involving a copula and some predication of a subject, e.g.:
the box is in the room
the box is red
he is a doctor
As well as the NegatedCopula form...
{X} is NOT {Y}
...which marks the ProcessFeatures.negated role to be @yes.
This uses the Stasis schema, which includes a protagonist and some state. Depending on the predication, the state can be mapped onto a type of Modification, TrajectorLandmark, or more.
The intransitive package defines the general IntransitiveArgumentStructure construction, as well as more specific constructions, such as BareIntransitive...
he ran
...and ActiveMotionPath:
he ran into the room.
The active/passive transitive constructions are handled compositionally, both conceptually and constructionally (as described in Dodge, 2010).
A set of "neutral" transitive constructions defines the semantics and general argument bindings, such as a Transitive-Perception construction.
All of these are general constructions, meaning they aren't used for parsing, and thus don't affect the ECG Analyzer's efficiency.
Additionally, the "neutral" constructions can add optional or required valences, such as the recipient in the transitive object-transfer construction:
John gave the ball to Sally.
The active transitive constructions are partitioned into the active-transitives package. A general ActiveTransitive construction defines high-level bindings between arguments (e.g., the NP[Object] is "arg2").
Then, more specific constructions subclass both this construction, and the "neutral" semantic construction, which allows the two poles to compose elegantly, as in ActiveTransitivePerception.
Currently, the active-transitives package has a nice range of semantic coverage:
he saw the box
he weighed the box
he entered the room
he painted the house blue
he moved the box
he pushed the box into the room
he built the house
he picked up the box
he gave the box to the man
The passive transitive constructions are partitioned in the passive-transitives package. In addition to importing the "neutral" transitives package, they also import the auxiliaries package.
The general PassiveTransitive construction defines the high-level bindings between grammatical constituents and arguments. Then, specific constructions, like PassiveTransitivePerception, compose the "neutral" semantic construction with the high-level grammatical construction.
Includes:
the box was seen by the man
the box was painted (by the man)
the box was moved (by the man)
the box was pushed into the room (by the man)
the house was built (by the man)
the box was picked up (by the man)
the box was given to him (by the man)
We are also experimenting with high-level transitive constructions, which wouldn't require different argument structure constructions for each semantic domain. Instead, the high-level construction has a meaning of TransitiveAction, and verbs (such as build), have meanings (such as Creation) that inherit from TransitiveAction. This reduces the proliferation of argument structure constructions, and the schema inheritance allows the role bindings to propagate correctly (using the agent and patient dichotomy).
These are contained in the transitiveTest package.
The Ditransitive construction is defined in the ditransitive package.
This package is imported in the “mental” package (since one of the communication variants relies on the ditransitive construction). More generally, there is a “Central ditransitive” construction which deals with Object Transfer, such as:
He gave Mary the box.
There is also a “Cause_motion’ ditransitive construction (added from base), which restricts the verb’s meaning to be “cause_motion”, and binds the “theme” in object transfer to the “affected Entity”:
He tossed John the ball.
He threw Sally the bat.
Finally, there is a “Creation” ditransitive construction, which maps the NP1 onto the intended_recipient:
He built Mary the house.
For this last one, it’s possible we want to use a similar construction as the “cause_motion” ditransitive, but it’s not clear that an actual Object Transfer takes place.
The change module, found in the change package, is still in development, but uses a general Change schema. The Change schema resembles the Stasis schema (above), but it also includes finalValue and initialValue roles.
There are two sub-schemas of Change: StateChange, which suggests a qualitative change in some discrete property (e.g., the box became red), and ScaleChange, which suggests a quantitative or scalar change in a continuous property (e.g., the box grew bigger). Examples:
the box became red
the man grew (bigger)
the box changed into a block
There is also a representation for CauseChange (which inherits from CausalTransitiveAction), in which some agent induces a change within a patient. This maps Change onto the affectedProcess role. Examples:
the man changed the box to a block
the man changed the box (from blue) to red
the man made the box bigger
the man painted the house blue
Become: We have, for the time being, lumped become under the umbrella of Change. However, it is also usually categorized as a copula, so this requires further reconciliation.
Note: As mentioned above, this package is still in development. The role names (finalValue, initialValue) are not finalized, and neither are the type-constraints on the state role (PropertyModifier, ScalarModifier).
In general, negation is usually encoded in p-features, unless it’s clearly negating some other schema, e.g. Modification (“the not red box”). By relegating negation to be a binary value (yes or no) in p-features, we suggest that the real “meaning” of the negation is application-dependent and will emerge in the simulation/solver. In many cases, the grammar/language has no way of determining the scope of the negation, particularly in auxiliary negation:
He did not run to the store.
Without an idea of the phonetic stresses on the sentence, it is unclear which aspect is being negated. Thus, more context is required to determine the actual meaning. By widening the scope to p-features, we avoid over-specifying the meaning in the SemSpec, and allow the Problem Solver to determine the meaning.
The only source of potential confusion is that modals, as opposed to auxiliaries, place the negation constraint on EventFeatures instead of ProcessFeatures, since modals modify EventFeatures instead:
He cannot push the box.
We’ve also implemented a mental argument structure package, which uses the Communication and Thought schemas. Importantly, we added a “media” role to Communication. The argument structure varies from Intransitive to Ditransitive (and thus imports both of those packages), and the sentences we can analyze include:
John thought that the box was big.
John said that the box was big.
John told Mary that the box was big.
John told Mary a story.
These constructions are included in the control package.
Currently, this package only contains subject-control argument structure, and only one constructional pattern for this type. Object-control argument structure (he caused John to move) is included within the explicit-causation package, though these could be reordered. Subject-control uses the same protagonist for the event-process and the embedded process. These sentences include:
John tried to move.
John tried moving.
John wanted to push the box into the room.
John intended to give Mary the ball.
See section on explicit causation below.
Constructions for explicit causation are defined in the explicit-causation package, and requires the active-transitives and gerunds package. Many of these can also be considered object control, but currently, we have packaged them as explicit-causation.
These constructions were originally defined with the Agent/Event distinction in mind. We are still testing and improving them, since they are somewhat outdated, but they allow the analysis of sentences like:
he caused John to move
he prevented John from moving
he caused the crisis
the storm moved the block
his moving caused the crisis
the storm prevented John from moving
Note: Our treatment of Force-Dynamics is not complete, and likely requires more complex semantics (though the constructions are mostly implemented).
Our implementation of catenatives in ECG is still in its early stages, but we have tested the implementation in the domain of Perception, and found that it works successfully. (See above for control verbs and explicit causation).
The catenatives package defines several high-level CatenativeVP cxns, with varying constraints on the verbform (Base vs. PresentParticiple) then subclasses compositionally with the active/passive transitive alternation, to allow the following utterances:
he saw the man run into the room
he saw the man running into the room
he was seen running into the room by the man
The auxiliaries constructions are used heavily in conjunction with the passive-transitives package. Importantly, auxiliaries have a meaning of ProcessFeatures. Thus, when an auxiliary combines with a verb or VP (which has a meaning of Process), the Process.p-features role unifies with the auxiliary's meaning.
Currently, there are constructions for the "do" auxiliary, the "have" auxiliary, and the "be" auxiliary. These combine with verbs and VPs by subclassing the general AuxPlusVerb construction.
Examples:
the box was not moving
the box was not being pushed
the box was being pushed by the man
the box was not pushed by the man
did the man push the box?
the man did (not) push the box
the man had been pushing the box
Modals constructions are found in the modals package. The bulk of the modal work is in the ModalPlusVP construction. The two modals we have encoded thus far are “can” and “will” (and their conjugations).
Can:
The man can push the box.
Could the man push the box?
Will:
The man will push the box.
Will the man push the box?
Modals have a meaning of EventFeatures. Unlike auxiliaries, which modify a Process, modals modify an EventDescriptor, and thus unify with the EventDescriptor.e-features role.
The gerund constructions are found in the gerunds package. This package is mostly self-contained, but can be imported into other packages. Gerunds allow VPs with a PresentParticiple verbform to be used as NPs.
Examples:
his pushing the box (caused it to move)
building a house (is difficult)
In terms of the semantics, the EventDescriptor evoked by the VP is bound to the RD.extras.event role in the RD schema.
These constructions are found in the adjunct package. They attach an adjunct-phrase (usually a PP) to a VP, independent of any particular domain. They are in the adjunct package. So far, we have encoded the following types of adjunct PPs:
Temporal-PP (binds to duration/telicity in EventFeatures):
did X for 2 hours
did X in 2 hours
Accompaniment-PP (action is performed with Y):
did X with Y
Instrument-PP (using Y):
did X with Y
Locative-VP (binds to place role in EventFeatures):
did X in Y
These do introduce the general notion of attachment ambiguity, some of which can be handled in the grammar, and some of which must be handled downstream.
Another issue, for the instrument-PP, is constraining the instrument to be compatible with the action. This can be handled within the grammar, if “Instrument Nouns” are defined to be compatible with a certain set of actions. If necessary, this can be further resolved downstream, probably in the Specializer, since it’s domain-specific. Ideally, a system integrator could specify the appropriate relations between instruments and actions (and other types of relationships) in some sort of table, and the Specializer would then use this table for a compatibility check. (E.g., @hammer is a suitable @instrument for @building, etc.)
The Serial VP constructions allow the coordination of two VPs, and map them onto the SerialProcess schema, e.g.:
he did X and then did Y
he did X before doing Y
he did X after doing Y
These constructions have been built compositionally, so that the individual conjunctions ("then", "before", "after") impose selectional constraints and also the semantic mappings of (X, Y) onto some temporal order.
The core ECG grammar handles particles with the particles package. The development here has been somewhat limited, but particles are treated, as suggested in Huddleston and Pullum, as intransitive prepositions.
Particles are unique in that they can appear between a transitive verb and its NP complement (Huddleston & Pullum, 2002), such as:
she brought down the bed
We define a VerbPlusParticle construction, which positions a particle directly after a verb. The "value" of the particle is incorporated into the particle role in ProcessFeatures.
Multi-words: Particles are also related to the problem of multi-word expressions, such as verbs like carry out, take off, and pick up. Thus far, we have handled these verbs as specific phrasal constructions, but much more work is needed. (See here for an attempt to define multi-word expressions for the verb+particle phrase "pick up".)
The core grammar has built-in several conditional constructions, which are included in the conditionals package.
From a cognitive linguistics perspective, conditionals are significant because they involve mental spaces, particularly in the case of counterfactuals and predictions, e.g.:
if John had painted the house, it would have been blue
if John paints the house, it will be blue
Our implementation of conditional semantics is based on previous work involving ECG and mental spaces (Mok, Bryant, & Feldman 2004). A ConditionalStatement contains at least a condition or premise ("if X") and a conclusion ("then Y"). This implementation is as general and compositional as possible, so more specific constructions allow the addition of an alternative ("otherwise, Z"), and can impose more constraints on the discourse mood of the conclusion (a prediction, a command, a counterfactual).
Furthermore, as with our implementation of the serial VPs, the conditional conjunctions ("if", "while") are built compositionally, to map different bindings and use different fillers. For example, in the case of a command, "while" suggests that the addressee should execute the command as long as the condition is True (see temporality below).
The notion of temporality surfaces in various grammatical and semantic domains (Processes, States, etc.), and various references to temporality are delineated using the ontology:
(type temporality)
(type ongoing sub temporality)
(type bounded sub temporality)
(type atemporal sub temporality)
@ongoing suggests that a described action or state does not have a defined end-state, and could be happening continuously. This is the case for conjunctions like "while", Present-Participles like "running", or Temporal-Prepositions like "for".
@bounded suggests that the action or state does have a defined end-state. This is particularly useful for describing the temporality of copulas, because it also solves the more general problem of information structure, e.g. the difference between the following two sentences:
the big red box
the red box is big
@atemporal is the inverse of @bounded, from the perspective of information structure, and is encoded by the former of the above sentences. The latter is an example of @bounded temporality.
Another major phenomenon in language is metaphor. Numerous articles and books have been published about Conceptual Metaphor Theory (Lakoff and Johnson, 2003, Metaphors We Live By), and other work has attempted to model metaphorical understanding using simulation semantics (Narayanan, 1997).
We do not claim to have solved the general problem of metaphor analysis and inference with our implementation in ECG, but our implementation does allow for the detection and identification of metaphors, based on semantic type constraint violations.
We define a high-level MetaphorSchema, which just a metaphor name, a role for the source, and a role for the target. Theoretically, this could be used to enumerate role mappings between the source and target domains, but most of our implementation has focused on reconstruing a target (such as an RD/Noun) in terms of the source. For example, the InstitutionAsPerson metaphor maps an @institution onto the @person value, and the StatesAreLocations metaphor maps an @abstractState onto the @location value.
Metaphorical RDs
These high-level MetaphorSchemas can then be evoked by a MetaphoricalRD, which is used in the MetaphoricalNominal construction.
Much of the ECG grammar has strong semantic constraints to prevent incorrect parses; the metaphors allow abstract or unusual nouns to match with these semantic constraints, and identifies the metaphor in the process. Consider the sentence:
the economy stumbled into the recession
Using the aforementioned InstitutionAsPerson metaphor and the StatesAreLocations metaphor, the following metaphors would be identified...
the economy[Institution-As-Person] stumbled into the recession[States-Are-Locations]
...and the sentence would parse successfully, just as it would in the non-metaphorical case:
the man stumbled into the room
Modification
We have also implemented a version of metaphorical modification. In some ways, this works as the inverse of the MetaphoricalRD, and is still very much in development. Consider the following phrase:
the big idea
Using just the aforementioned MetaphoricalRD approach, we would reconstrue the sentence as:
the big idea[Ideas-Are-Physical-Entities]
However, the Modification approach allows us to reconstrue source-domain Adjectives in terms of the target, which would identify the more salient Importance is Size metaphor:
the big[Importance-Is-Size] idea
Events
There has also been some experimentation with metaphorical events, but we have not developed anything concrete yet. Usually, the verb or "Process" is from the source domain, so it works fine to simply reconstrue an NP[Object] or NP[Subject] metaphorically, but this issue does merit additional consideration.
ECG "core" also has a (limited) treatment of indirect speech acts - specifically, those of the form:
could/would X do Y?
The package "indirect" defines a construction that reconstrues Y/N questions of this modal form to imperative commands, and marks the self.m.speechAct role with a value of @indirect. Thus, two SemSpecs are generated -- an indirect command, and a yes/no question.
Relative clauses, such as that pushed the box in the man that pushed the box, do have a treatment in the "core" grammar. A simple construction can be found in the relative-clause package, which also includes several constructions for the phenomenon of apposition.
The embedded VP is bound to the RD.extras.description role:
the man that pushed the box ran into the room.
There are also grammatical and semantic phenomena that aren't covered in the current "core" grammar. Some of these are constructional peculiarities - e.g. a particular form of nominal apposition - but others are richer domains of grammar. Below is a list of the main phenomena not covered by the core grammar:
A pleonastic or "dummy" pronoun is one used for syntax without explicit meaning. This frequently occurs with the pronoun "it", such as:
It is obvious that the company is dysfunctional.
"It" has no obvious antecedent. This is also used in the "weather" case, though there is some disagreement about whether the use there is truly pleonastic:
It is raining today.
Dummy pronouns can also be used in conjunction with other phenomena discussed above, such as raising:
`It seems that John loves coffee."
Related is the "there-construction", discussed extensively in Case study 3 in "Women, Fire, and Dangerous Things" (Lakoff).
Passives usually take the past participle voicing, and are handled quite extensively in the "core" grammar. However, the core grammar does not handle concealed passives, which usually involve the verb "need":
the house needs painting
There is some treatment of discourse in the grammar with the DiscourseElement schema, used by the Utterance construction, as well as ontological pointers by pronouns (@antecedent). Theoretically, construction grammar could be used for discourse as well. Work has been done on this, but not in ECG. Pragmatically, it seems that every construction in ECG ought to be somehow linked to a broader set of discourse knowledge, since all utterances (fragments or not) are part of a discourse. A serious treatment would perhaps involve the development of a Discourse Analyzer, which could link information in disparate SemSpecs.