Grounding a Frame in a Schema
What grounding actually records#
A lexical frame is grounded in the schema whose structure its meaning rests on. Grounding isn't a label — it's an edge to a specific schema, carrying a set of bindings from the frame's own frame elements to that schema's elements. Once those bindings exist, two things follow automatically, without anyone having to state them separately: the frame's profile — which of the schema's elements it actually brings forward — is simply read off which of its core frame elements are bound; and whatever the schema already knows how to do with its own structure, the frame inherits for free.
A binding is always to the most specific schema that actually fits. A frame whose roles are a category and its subtypes cannot be bound in OBJECT, which exposes only one element — the binding attempt fails immediately, and that failure itself is what tells a modeler CLASS is the right target instead. Trying to actually bind a frame tests the choice of schema far more rigorously than picking a schema in the abstract ever could.
Reading a profile off the bindings#
The profile is never stored separately from the bindings — it's computed by looking at which of the schema's elements the frame's core frame elements reach. A peripheral frame element can still bind — a Manner or a Time binding to EVENT.Event, say — but a peripheral binding never enters the profile; it reaches the schema's background instead, exactly the way a backgrounded participant in an ordinary sentence is present without being foregrounded.
Two consequences fall out of this directly:
- An empty profile and an unanalyzed frame look the same, on purpose. If a frame's core frame elements haven't been bound to anything yet, the profile computed from them is empty — which is exactly the state a frame in that condition should show. Nothing is lost by not storing the profile separately.
- A frame element's name is never good evidence for what it binds to. Two frames can each have a frame element called Ground, and mean two entirely different things by it — one the dimension a transformation traverses, one simply "the thing being examined." Binding is always a judgment call made frame by frame, never a name-matching exercise.
Grounding more than once#
A single word very often packs more than one construal into itself, and the grounding mechanism is built to let that show. Entrar ("to enter") is read as a traversal and as a boundary being crossed, and no one schema captures both at once — so the frame grounds twice, once in a schema from the event family for the traversal, once in CONTAINER for the boundary it crosses. Each grounding carries its own bindings and contributes its own profile; together, the two record what one word does at once.
This is the ordinary case for a lexicalized word, not a special exception. A second grounding earns its place by reaching something the first grounding can't: CONTAINER gives entrar an Interior for its goal to bind to, where the traversal schema on its own offers only a bare, structureless position. A second grounding that repeats what the first one already covers isn't adding anything, and shouldn't be added.
Coverage is judged across all of a frame's groundings together, not edge by edge. Entrar's frame element for the boundary it crosses has no home in the traversal schema at all, and its frame element for where the motion started has none in CONTAINER — each one is covered by exactly one of the two edges, and that's sufficient. What matters is that every core frame element is reached by some grounding, not that every grounding reaches every frame element.
Choosing a target#
Deciding where a new frame should ground is exactly the question the diagnostic cascade answers: a short, ordered sequence of tests — constitutive sentience, displacement, force, role count, and (for anything relational) the converse predicate — that sorts a frame into EXPERIENTIAL, the event family, STATIVE, an attribution, or one of the relational schemas. See Principles, the Minting Rule, and Diagnostics for the full cascade, why the gates have to run in that order, and the table that picks among the relational schemas once gate ⑤ settles a frame is relational.