Stative Namespace

Core Definition#

Stative frames profile a condition tied to a force — a position, a captivity, a persistence, a supported posture, or a resultant condition — whether that force is actively holding the condition now or already produced it and has since stopped acting. Both readings are STATIVE-family content in the conceptual dimension's own schema catalog: the actively-held reading grounds in STATIVE itself (an EVENT-family schema, minted by holding the transition step null and constraining Income same_as Outcome); the resultant reading grounds in Attributes plus an ordinary relation row linking Value to the Outcome of a producing EVENT (the same schema @attribute grounds in, one relation richer). Mode: dynamic in the actively-held case (a force genuinely acts); static in effect either way — nothing is being displaced right now, whether because the force holds it in balance or because the force is simply over.

Formal templates:

MAINTAIN(force, condition)              — Income same_as Outcome (force still acting)
RESULT(condition ← Outcome of EVENT)    — force once acted, is over now

The single test that matters is was a force ever involved, in any tense — not is a force acting right now. Permanecer — this namespace's own defining maintained-condition example — routinely asserts an ongoing hold with no maintainer anywhere in the cast; cansado asserts no ongoing hold at all, only a producing event (cansar) on record. Both clear the bar. Only a plain, brute property with no force ever, in either tense — alto, azul, provável — fails it and belongs in @attribute.

Merge note. This namespace previously excluded the resultant reading into a separate @condition namespace (promoted from Attributes' own CONDITION profile). That split has been retired: @condition is gone, and its scope has been folded back in here. Three considerations drove the merge, discussed and settled together:

1. The LU-ontology layer never forked in the first place. LUs types both readings as bare .state — postura (force-maintained) and cansaço (resultant) are the same ontological type, distinguished nowhere in Layer 1. Keeping the namespace split meant the class-compatibility check a namespace exists to run (does this namespace admit this type?) was identical for @stative and @condition — both admitted .state/.state<value>, differing only by a force-status footnote no type distinguishes. A check that can't discriminate the cases it's supposed to sort isn't earning its keep.
2. Naming and literature both already treat this as one category. Nearly every candidate frame for the old @condition reading is itself named Estar_* — estar being the prototypical Portuguese stative copula — and the wider FrameNet literature on the causative/inchoative alternation calls the result branch "stative" without further splitting it by whether the producing force happens to still be acting.
3. @condition was already the lighter-weight promotion of the two possible merges. Its own justification for existing separately from @attribute was one ordinary relation row (Value → a producing EVENT's Outcome), not a distinct DUL Situation class the way the seven eventive namespaces earn one — @condition explicitly minted no Situation class of its own. Folding it into @stative rather than into @attribute keeps .state's own unforked shape mirrored cleanly at the namespace layer too: @stative becomes the single home for every .state/.state<value> LU, exactly as @attribute is the single home for every .attribute/.attribute<value> LU, with no base type ever needing to split its home across two namespaces.

Consequence for the DUL Situation-class mechanism, decided explicitly rather than left implicit: @stative's minted StativeSituation class (see Situations, below) now covers both readings. A resultant condition — read as the settled state a Transition left behind — is accepted as a legitimate Situation-view in its own right, just a coarser one than the old @condition page drew; it is not treated as a lesser, unclassed case the way @attribute frames are. This was a deliberate choice, not a default: the alternative (keying the DUL-class link to the actual conceptual-schema grounding — STATIVE vs. Attributes — rather than to the bare namespace value) was considered and set aside in favor of the simpler, uniform rule.

Scope#

Includes — an actively-held condition:

• Maintaining verbs, no maintainer required in the cast: permanecer, manter, sustentar, prevalecer, repousar — the condition would lapse if this force stopped, and none of these lexicalizes a directed endpoint
• Posture held against gravity — the SUPPORT/RESISTANCE image schema, STATIVE with a spatial Ground: sentado, deitado, ajoelhado, de pé, curvado, encolhido — the Agent's own body continually supports itself
• Persistence of a process or activity, no boundary crossed: continuar, prosseguir, persistir — contrast with começar/terminar, which cross a boundary and are @change
• Maintained captivity or control — an external force actively holds an entity in a condition it would otherwise leave: preso, detido, sob custódia (captivity); controlar, administrar, fiscalizar (control)
• A vital state read as actively maintained rather than merely holding: vivo, morto, imortal — the state persists only as long as the underlying biological process does

Includes — a resultant condition, force now spent:

• Physical/bodily conditions: cansado (tired, ← cansar), quebrado (broken, ← quebrar), machucado (hurt, ← machucar)
• Social/legal status: casado (married, ← casar), aposentado (retired, ← aposentar)
• Functional status: operacional on the "up and running" reading (← the machine having been fixed/started), estragado (spoiled, ← a spoiling process)
• Identity/naming facts: an entity being named (← a naming act on record), tendo origem em (← an originating event)
• Process-relative states: a process's initial, completed, stopped, or uncompleted state — each defined directly in terms of the process event it's a slice of
• Depletion/use results: a resource diminished by repeated or extended use (usado, grau de processamento)

Excludes — see other namespaces:

• A displacement — the initial position differs from the final one → Change (Framework §8 gate ②: "a Protagonist is near or approaching death" is dynamic, not stative — dying is a process, not a maintained or resultant condition)
• A sentient participant, constitutive, with designated content → Experiential (gate ① runs before the force test — saber, temer resist the progressive exactly like a stative predicate, but that's not why they're excluded; they're excluded because a Cognizer/Content pair is present at all)
• No force asserted, ever, in either tense — a plain or measured attribute with no producing event on record at all (João é alto; o livro custa 50 reais) → Attribute
• No force asserted, and the two participants are exchangeable regions — category membership (João é médico), possession/kinship (João tem dois filhos), bare locational predication (João está em casa) → Relational (gate ⑤, the converse test: a caixa contém a chave fires cleanly on all three of these, which a genuine STATIVE case never does — a maintained or resultant state is a configuration of two regions and would pass the converse test too if asked out of order, which is exactly why gate ③ is checked before ⑤)
• Volitional activity, no maintained or resultant condition → Agentive (João correu)
• A caused result, by an agent or a natural force, read as the causing event itself → Agentive (João quebrou o vaso — the event; contrast o vaso está quebrado, the resultant condition, which is Stative)
• A Patient actively undergoing an externally-instigated event, not a static condition merely holding → Undergoing (correr risco, lidar com uma condição contra a vontade). Reclassify here only frames that profile a state obtaining, not an event befalling a Patient
• A position occupied part-way through an ongoing transformation, not yet a settled outcome → Process (a progressive/in-progress reading; the resultant-condition reading needs an actual Outcome reached, not a transformation still underway)

Critical boundary — stative vs. change: Ficar + adjective/predicate marks entry into a state (Change), not the state itself:

• João ficou feliz → Change (he transitioned into that state)
• João está feliz → almost always Attribute, not Stative — nothing in the sentence asserts a force, active or spent, producing or holding this. It clears the bar into Stative only where a force is genuinely on record, either holding the state now (João permanece feliz apesar de tudo) or having produced it (João está exausto, ← exaurir).

In practice, plain adjectival predicates split three ways: most "X é Y" sentences with no causal story ever told are Attribute; those with a producing event on record but no maintainer — a large and easy-to-underestimate class, the old @condition territory — are Stative on the resultant reading; a genuinely ongoing hold (permanecer-class maintenance, a held posture) is Stative on the active reading. The Attribute/Stative line is real and narrow; the two Stative readings are not narrow relative to each other, and the diagnostic below (Test 1) is what tells resultant-Stative from Attribute, not from active-Stative.

Subtypes#

Actively-held condition:

Resultant condition, force now spent (absorbed from the retired @condition namespace):

What moved out, and where it went (unaffected by the @condition merge — these were never a Stative reading to begin with):

The ser / estar / ficar contrast is a fact about Portuguese copula choice, not a direct proxy for namespace — it distinguishes individual-level from stage-level predication in general. Under this namespace's scope, a fair amount of estar-predication that used to look like it needed a separate @condition bucket is simply @stative, same as ficar-resultatives with a producing event on record; only genuinely event-free ser/estar predication is @attribute, and locational/categorical/relational estar/ser stays @relational.

Characteristic signature#

STATIVE is CHANGE's own child, not EVENT's direct child — moved there in the same restructuring that gave CHANGE its own native cast (Conceptual Schemas §6.2), since Income/Outcome no longer exist on bare EVENT to hold equal. It inherits CHANGE's full cast unchanged — Agonist, Event (both themselves inherited from EVENT), plus CHANGE's own native Antagonist, Ground, Income, Outcome, Target — with Income and Outcome held equal, and Target not core (a maintained state has no directed endpoint). The resultant reading (former @condition) does not use this cast at all — it grounds in Attributes' own three-role structure (Entity, Attribute, Value) plus a relation row from Value to a producing EVENT's Outcome; see Condition below.

graph LR
    Agonist["Agonist<br/><i>AGENTIVE</i><br/>force, often unexpressed"]
    Antagonist["Antagonist<br/><i>FORMAL</i><br/>entity/region held"]
    Ground["Ground<br/><i>FORMAL</i><br/>dimension, often unbound"]
    Income["Income"]
    Outcome["Outcome"]

    Agonist -->|holds| Antagonist
    Antagonist --- Income
    Antagonist --- Outcome
    Income -.->|is_region_for| Ground
    Outcome -.->|is_region_for| Ground
    Income -.->|same_as| Outcome

    classDef core fill:#8B0000,stroke:#8B0000,color:#fff
    classDef opt fill:#fff,stroke:#8B0000,stroke-dasharray:4 3,color:#8B0000
    class Antagonist,Income,Outcome core
    class Agonist,Ground opt

The dashed Agonist node is the point of this diagram: unlike an ordinary EVENT, a STATIVE frame on the actively-held reading is licensed by the invariant (Income same_as Outcome), never by having an exerter element in the cast. Target is absent entirely — the defining contrast with every dynamic namespace above it.

Characteristic signature (resultant reading)#

Same three roles as Attributes (Entity, Attribute, Value), plus one relation row: Value → the Outcome of a producing EVENT.

This is the same anchor Attributes/@attribute uses (Quality) — the resultant reading and ATTRIBUTE are one relation apart, not two different schemas, which is exactly why an LU typed .state/.entity«state» is admitted here by the same clause-1 anchor match the admit-set already uses for .attribute (see LUs). The DUL anchor never distinguishes the two readings; only the relation to a producing EVENT does, and — since the merge — that relation decides a schema, not a namespace.

Diagnostic Tests#

Test 1 — Textual commitment to a force, in any tense (the primary test; replaces the old Cessation-only test)#

Does the frame's own gloss or cast name, or clearly presuppose, a force — either actively holding the condition now, or having produced it and now spent?

✓ "Despite some implication that a State would be interrupted, the Entity remains" → STATIVE, actively held (`frm_state_continue`'s own gloss)
✓ cansado ← cansar (the verb is the evidence; "ficou cansado" presupposes the tiring, now over) → STATIVE, resultant
✗ O quadro está na parede — nothing is holding it there and nothing produced its being there → NOT STATIVE → RELATIONAL
✗ alto — nothing produced this, ever, in either tense → NOT STATIVE → ATTRIBUTE

Corroborating, never required, for the actively-held reading: can you name what holds it — a Connector, a supporting Agent? Permanecer passes with nothing in the cast to name. Corroborating, never required, for the resultant reading: is the producing verb itself the evidence, even with no FE for it in the cast? Cansado passes on cansar alone.

Test 2 — Progressive incompatibility (necessary, not sufficient)#

True states are incompatible with the progressive (estar + gerund). This separates Stative from Agentive/Phenomenon, but not from Attribute or Relational — a plain property resists the progressive too.

✗ *João está sendo alto (João is being tall) → not Agentive/Phenomenon — but this alone doesn't prove Stative; see Test 4
✓ João está correndo (João is running) → NOT STATIVE (Agentive)

Exception — coerced volitional reading: estar sendo + behavioral adjective is grammatical but coerces a non-stative meaning — João está sendo educado = João is acting politely (intentional behavior, not a maintained or resultant condition).

Test 3 — Imperative incompatibility#

States cannot be commanded because they are not under volitional control. This applies to both readings — nobody can be ordered into a resultant condition any more than into a maintained one.

✗ *Permaneça alto! → STATIVE (actively held), not under the addressee's control in that reading
✗ *Fique cansado! (as a command to already be tired, not to tire oneself) → STATIVE (resultant), not commandable as a state
✓ Corra! (Run!) → NOT STATIVE (Agentive)

Test 4 — The exchange test (the sharp boundary against Relational)#

Can the two participants be exchanged, using a predicate that reverses the relation? A maintained or resultant state is not a configuration of two exchangeable regions — an entity and the force that holds or produced its condition cannot swap places the way two regions in a relation can.

✓ a chave está na caixa / a caixa contém a chave → exchangeable → RELATIONAL, not Stative
✗ João permanece calmo / *calmo permanece João → no converse reading → genuinely STATIVE (active)
✗ João está cansado / *cansado está João → no converse reading either → genuinely STATIVE (resultant)

Test 5 — Homogeneity#

Any subinterval of a maintained or resultant state is also that state; events are not homogeneous.

STATIVE (active): João permaneceu calmo das 14h às 17h
→ João permanecia calmo às 15h ✓ (any subinterval holds) → STATIVE

STATIVE (resultant): João esteve cansado das 14h às 17h
→ João estava cansado às 15h ✓ (any subinterval holds) → STATIVE

PHENOMENON: João correu das 14h às 15h
→ João correu às 14h30 (not necessarily — event has phases) → NOT STATIVE

Test 6 — Not a progressive/in-progress reading (resultant reading only, boundary against Process)#

Is the value the endpoint reached, or a position occupied part-way through an ongoing transformation?

✓ o processo está completo (Outcome reached) → STATIVE (resultant)
✗ o processo está em andamento (part-way, not yet an Outcome) → PROCESS, not Stative

Test 7 — Don't infer a force the frame's own gloss is silent on#

A frame that could, in principle, be redescribed with a biological or physical mechanism is not thereby Stative — the bar is what the frame's own content asserts, not what could be imagined.

✗ doente (frm_health_conditions doesn't textually commit to a cause for every member — named by body part, population, or proper name as often as by cause) → default ATTRIBUTE; only cause-named members (e.g. "viral pneumonia") clear the bar into STATIVE
✓ frm_being_rotted — "has undergone the natural process of rotting" is asserted, not inferred → STATIVE (resultant)

Open population work#

The @stative namespace in the database currently holds 66 frames, populated against the pre-merge, narrower scope (actively-held readings only). Re-running Test 1 above against every one of them — and against the ~183 frames currently in @attribute, to catch resultant-condition frames stranded there under the old three-way split — is open work, tracked against the live data directly rather than settled here. This document fixes the scope, not the population.