Classifying Frames

Namespaces#

Every frame in FNBr belongs to exactly one namespace. Where a semantic type or a filler restriction says something about a frame element's possible fillers, the namespace says something about the frame itself: what fundamental kind of thing is this frame's Description about? An occurrence, an entity, an attribute, a relation between things, or something more structural?

This is a coarse, single-valued classification, and it's deliberately kept that way. A namespace answers what kind of thing is this, not which particular view does this frame take of it — that finer question belongs to the conceptual dimension's own machinery (grounding schemas and profiles), not to the namespace. Keeping the two separate matters: a namespace has to be able to say "this is definitely wrong" when a frame is put in the wrong category, and it can only do that reliably if it isn't also trying to capture every nuance of construal at the same time.

The namespace inventory#

By design, the namespace values form one flat list — there's no additional layer of grouping stored above them. @eventive is a family label, not a namespace value. Agentive, Change, Experiential, Phenomenon, Process, Stative, and Undergoing are each their own namespace, independently — a frame is stored with exactly one of these seven, never with @eventive itself. No frame anywhere carries @eventive as a stored value. The other nine namespaces below are each the only member of their own family, which is why they don't need a family name distinct from their own.

Fifteen namespaces, seven of them grouped under one family label, eight of them families of one — that arithmetic is what makes "the namespace inventory" a well-defined, closed list rather than an open-ended one. It was sixteen briefly: a since-retired @condition namespace — promoted from Attributes' own CONDITION profile — was folded back into @stative after the split proved not to be a namespace-shaped fact; see Stative's merge note for why.

Frames about an occurrence — the eventive family

Each of these seven is documented on its own page (starting with Agentive), with its own scope, subtypes, characteristic participant signature, and diagnostic tests — the detail that belongs at the level of one namespace, not repeated seven times on this page. What belongs here is only the shared fact that motivates keeping them distinct rather than collapsing them back into @eventive: each of the seven now anchors its own DUL Situation class (see Situations, below) — a fact the conceptual dimension's profile layer cannot carry on its own, and the concrete, permanent reason the split is not a pending collapse.

Frames about a participant rather than an occurrence — the ontological family

Structural and scaffolding namespaces

Frames belonging to another dimension entirely

Why these last several are kept as separate categories rather than merged into one. They share only a negative fact — none of them is a view over an event — and a shared negative isn't itself a real category. @structural frames provide abstract scaffolding other frames lean on; @microframe is the relation inventory that scaffolding is wired together with; @class exists purely to represent DUL's own classes inside the frame inventory; @domain belongs to an entirely different dimension of the resource, and unlike the others, it does have lexical units attached to it. Collapsing distinct facts into one shared bucket just because none of them is eventive would throw away exactly the distinctions that make each one useful on its own.

Situations#

Recall from Introduction that DUL separates an Event — something that occurs, with one stable identity — from a Situation, a particular contextualized view over that event. DUL itself already recognizes several named kinds of Situation, and it turns out that FNBr's seven eventive namespaces line up with exactly this idea: each one names a characteristic kind of view, not a different kind of event. This is also the concrete, structural reason the seven stay independent namespace values rather than collapsing into @eventive: a namespace value can carry its own link to a DUL class (the same mechanism a frame, an FE, or an LU uses), so keeping each of the seven as its own row is what makes it possible for each to anchor its own Situation class in the first place. Collapse them into one @eventive value and there is only one row left to hang seven different classes on.

The now-retired @condition namespace never needed a Situation-class mint of its own — it grounded in Attributes, the same static schema @attribute grounds in, differing only by one ordinary relation rather than by aspect. That lighter weight is exactly why folding it into @stative was a coarsening rather than a category error: @stative's minted StativeSituation class now covers the resultant reading too, accepted as a legitimate (if coarser) Situation-view in its own right — see Stative's merge note for the reasoning.

Two frames can describe the very same real-world happening — João quebrou o vaso ("João broke the vase") and o vaso quebrou ("the vase broke") — while taking two different views of it: one foregrounding the breaker, one foregrounding the result. Under DUL's own logic, that's one Event, read under two different Situations. It's exactly this insight that lets each of the seven eventive namespaces connect outward to its own named DUL Situation class, rather than staying an FNBr-only label with no wider meaning:

Two of these deserve a short additional note, because it's easy to reach for the wrong comparison. Agentive and Phenomenon frames are not classified by which participants the underlying event actually had — DUL already has classes for that (an event with an agent versus one without), but those classify the event itself. What the eventive namespaces classify instead is what the frame's own description chooses to profile — which is exactly why o vaso quebrou and João quebrou o vaso can be, and are, treated as the same underlying event read two different ways, rather than as two events that happen to look similar.

Stative is narrower than it might first appear, but along one axis only. A frame only belongs here if a force is genuinely on record, in some tense — either being held in place against change right now (a posture sustained, a state actively maintained), or having produced a condition it no longer holds ("the door is broken", ← quebrar, force spent but on record). A frame that states a plain, unforced property with no force ever, in either tense ("the door is red") belongs instead in @attribute. A frame stating a bare relation belongs in @relational. Neither of those two is @stative, and mixing either in would blur the one real boundary this namespace has to hold — some force on record, at some point, vs. none at all. See Stative for how this boundary was arrived at — the namespace's documented scope was first pulled back to a force-maintained-only core (excluding scenarios, plain properties, resultant conditions, and bare relations that had accumulated in it), then deliberately widened back out to include the resultant-condition reading once a separate @condition namespace for that reading proved not to earn its keep as its own category.

Not every namespace pair that looks like a perspective alternation actually is one. @experiential and @process are each minted on a structural fact — constitutive sentience, and a genuinely graduated middle, respectively — rather than on a foregrounding choice, so a frame with that structural fact grounds there regardless of which participant its bindings happen to trace. A frame with a constitutively sentient participant is always @experiential, never optionally @change or @agentive; a frame with a graduated ground is always @process, never optionally @phenomenon.

Perspective pairs#

Some namespace pairs, by contrast, genuinely are two Situations profiling the same underlying Event. AGENTIVE, UNDERGOING, and CHANGE are each their own schema object in the conceptual dimension — independent siblings minted directly over EVENT, rather than profiles over one shared grounding the way they used to be — and Phenomenon's own grounding, OCCURRENCE, has been retired outright, folded into bare EVENT itself. None of that changes the ontological story here: three separate conceptual-layer grounding targets can still be, and still are, three DUL Situations over one Event, exactly the way three profiles over one shared target used to be — the Situation-class question is about what kind of view a frame takes, not about how the conceptual dimension happens to implement recording that view underneath. A frame in one of these pairs is distinguished from its partner by which schema it grounds in and what its own description foregrounds — judged by a human, and the model must therefore never auto-flag a frame merely because it could also fit the partner namespace:

The alternation is real and expected; recording it here at the level of the namespaces means the evaluation tooling treats partner-namespace membership as legitimate, not as an error to flag.

Scenarios#

It's worth flagging one thing explicitly, because the two are easy to confuse: Scenario is not a namespace value. It's a separate frame type, marking a frame that scaffolds together a more complex scene — one that might decompose into ordered sub-phases, or that might support two or more alternative construals of the same participants, or both at once. A frame carrying the Scenario type still has its own namespace, chosen the ordinary way, based on what the scenario itself is about — an obligation scenario, for instance, sits comfortably in @stative, while a commerce scenario sits in @agentive. Scenario and namespace are genuinely independent facts about a frame, the same way Domain is independent of namespace too: a single frame can be a scenario, sit in a particular namespace, and belong to a particular domain, all at once and all without any tension between the three.

Modality is cross-cutting, not a namespace#

There is no @modal namespace, by deliberate decision. Modality (possibility, probability, necessity, obligation, permission, capability) is a feature that cuts across namespaces, not a namespace of its own. Inspection of the candidate frames shows they do not form one class — they distribute by modal flavor (epistemic / deontic / dynamic):

Two consequences:

1. Deontic modality decomposes by perspective into @agentive (imposing) and @stative (the obligation holding), bound together by a Scenario frame (Obligation_scenario) — using the same distinctions the event model already uses. A @modal namespace would compete with these and force an arbitrary choice; the perspective decomposition is cleaner and is recorded as a perspective set over the scenario.

   Obligation_scenario itself sits in @stative, which is worth revisiting: a scaffold binding an @agentive and a @stative perspective arguably takes neither view itself, and a non-perspectivized scaffold may want a different namespace than the perspective it scaffolds.

2. The only residue without a pre-existing home is Senser-less epistemic predication of a proposition (Group 1: Possibilidade, Probabilidade). This is a narrow class and is housed in @attribute, distinguished from ordinary entity-attributes by the bearer's semantic type:

   @attribute sub-kind	Bearer (semantic type)	Examples
   Entity-attribute	Entity	inteligência, cor, tamanho, Capacidade_volume
   Modal-attribute	State_of_affairs	Possibilidade, Probabilidade

   The semantic-type layer carries this distinction; no new namespace is needed. Revisit only if the modal-attribute class grows large enough to justify the overhead — current evidence (two frames) says it will not.