The Ontological Dimension

Motivation#

FrameNet Brasil's core job has never changed: annotate real sentences, and record which frame a lexical unit evokes and how its frame elements are realized. The ontological dimension doesn't touch that job. What it adds is a second, complementary question, asked about the resource itself rather than about a sentence: what kind of thing is this frame, this lexical unit, this frame element — really?

That question matters for two practical reasons. First, as the frame inventory grows, it becomes easy to build two frames that quietly disagree about what they're modeling — one treats "destruction" as an event that happens, another treats it as a state left behind — without anyone noticing, because nothing forces the two analyses to be compared. Second, when a researcher creates a new frame, they benefit from a reference structure to place it against: is this a frame about something occurring, about an entity, about an attribute, about a relation? Answering that question well, early, prevents a great deal of later confusion.

An early attempt to answer it tried to organize frames into a strict inheritance lattice, with maximally general "top frames" at the root. That effort ran into a real obstacle: the most general frames resist being related to each other by the ordinary frame-to-frame relations FrameNet already has (Inheritance, Using, and the rest) — there's no good, uncontroversial answer to "what does Entity inherit from?" The ontological dimension takes a different, lighter approach: instead of a strict hierarchy of frames, it classifies frames, lexical units, and frame elements against a small, independently-motivated set of categories, and — where useful — links them outward to an existing, well-tested ontology instead of trying to grow FNBr's own.

The whole apparatus is descriptive, not prescriptive. As with FrameNet generally, the goal is to make a researcher's analysis explicit and to make inconsistencies visible — never to forbid a particular way of construing a scene. Language resists complete, tidy coverage. Honest, useful progress on it is the actual goal.

The organizing principle: Event, Situation, and Description (DUL)#

The single idea that holds the model together is borrowed from DUL's Descriptions & Situations (D&S) pattern (see the DUL design-patterns document). D&S separates the intensional side of meaning (a theory under which things are viewed) from its extensional side (an actual, contextualized view of some entities):

• A Description defines the concepts, roles and relations of a theory. It is intensional — it says how something may be viewed.
• A Situation satisfies a Description and is a setting for actual entities and events. It is extensional — one concrete view, consistent with the Description, over a particular set of things.
• An Event is something that occurs, with one stable identity. In rock erosion in the Sinni valley, erosion is one event. DUL deliberately does not classify events by aspect; the aspectual view is carried by a Situation. ErosionAsAccomplishment and ErosionAsTransition are two Situations over the same Event, neither of which changes the Event's identity.

This maps directly onto FNBr's annotation architecture:

The chain that gives the namespace its role runs through these correlates:

1. An annotation set (Situation) relates an LU (Event) to a whole annotated scene — the target and its frame elements in a corpus sentence.
2. The LU evokes a frame (Description), and the annotation set therefore satisfies that frame.
3. The frame belongs to exactly one namespace.

So the namespace, riding on the frame, characterizes the perspective under which the whole situation is viewed — @phenomenon, @change, @agentive, and the rest. And because a Description can be satisfied by many Situations, the same frame applies to many annotation sets: one view-defining theory, many concrete occurrences read under it.

Two consequences follow:

1. The LU tracks Event identity; the namespace tracks the view. This is why destruição evoking a change-frame is still typed destruição.event and never destruição.change: change is the view a particular frame takes; event is the concept's identity. One LU (Event) therefore maps, through the frames it can evoke, to many compatible namespaces (see Ontological Types for LU).

2. A single event can legitimately be viewed under more than one namespace. O gelo derreteu may be read as @change (the resulting liquid state is profiled) or @phenomenon (the melting process is profiled). These are two Situations over one Event. The model must therefore expect such pairs and never treat them as errors. This is FrameNet's native notion of perspective applied at the level of the LU and its frame.

A middle ground#

There's an old philosophical disagreement about whether events exist independently of how we describe them, or whether no event can be talked about at all without the theoretical baggage of some particular description. Following DUL, FNBr doesn't take a side. It records Events, Situations, and Descriptions together, so that whatever analysis a researcher settles on gets encoded faithfully, whichever side of that debate they'd personally favor. That's what makes the model descriptive rather than prescriptive: it records the view that was chosen, without adjudicating which view is the metaphysically correct one.

Grounding frames, lexical units, and frame elements in DUL#

Beyond the Event/Situation/Description idea, the ontological dimension links the resource's own objects — frames, lexical units, and frame elements — outward to a real hierarchy of DUL classes. The reason this matters in practice: a class hierarchy supports reasoning in a way an unstructured label never can. If one class is recorded as a specialization of another, then whatever holds for the general class automatically holds for the more specific one too, without every frame having to restate it individually. Linking the lexicon to DUL this way means FNBr isn't just organizing its own material — it's connecting to a broader, shared vocabulary for describing what things are, one that other resources and tools already use.

Two different, easily-confused kinds of fact both use this same class-linking idea, and it's worth keeping them apart from the start:

• What kind of thing is this object itself? A lexical unit, a frame element, or a frame can each be linked to a DUL class describing its own nature — an entity, an event, an attribute, and so on.
• What kind of thing may fill a given role? A frame element can separately carry a restriction on its filler — "whoever fills the Cook role must be a member of the class Sentient." This is a claim about what's allowed to occupy the role, not about what the role itself is.

These are genuinely independent facts, and neither one can be derived from the other. Both are described in their own place — the first in Frames, Lexical Units, and Frame Elements; the second wherever a frame element's filler restrictions are discussed.

A class only earns a place in this hierarchy when it does real work. It isn't enough that a word exists for a candidate class, or that a class could in principle be drawn narrower than its neighbor. A class is worth minting when treating it separately — rather than treating it as its nearest already-established relative — actually changes some conclusion the resource draws. This keeps the hierarchy from growing as fine-grained as the lexicon itself, which would defeat the purpose of having a hierarchy at all: a class inventory that mirrors every lemma one-to-one supports no more reasoning than the lemma list already did on its own.

One class in particular is worth calling out because it's easy to reach for by accident: DUL's own Entity, the very root of its hierarchy, is defined so broadly ("anything a modeler might want to talk about, real, possible, or imaginary") that linking something to Entity itself says almost nothing. The whole point of grounding a frame, lexical unit, or frame element in DUL is to say something informative about it — so the root class is deliberately avoided as a target, in favor of whichever more specific branch actually applies.

Namespaces: a shared classification device#

The concrete mechanism the ontological dimension is built on is the namespace. A namespace is a named group of objects that share some basic semantics — in the plainest sense, the same idea a namespace is in a programming language. Objects sharing a namespace don't need to stand in any frame-to-frame relation to each other at all; the namespace records a shared kind, not a shared position in some inheritance tree.

Namespaces classify three different kinds of object in FNBr, and each carries its own small, closed vocabulary of possible values:

• Frames are classified by what the frame is fundamentally about — an occurrence, an entity, an attribute, a relation, and a handful of other structural categories. This is the subject of Frames.
• Frame elements are classified by what kind of concept the frame element itself is — is it a participant role, a scalar parameter, an embedded event, and so on. This is the subject of Frame Elements.
• Lexical units carry an ontological type, a coarse classification of the concept's own stable identity, independent of part of speech. This is the subject of Lexical Units.

Each namespace value can, in turn, be linked to a DUL class of its own. Because many frames, frame elements, or lexical units typically share the same namespace value, this gives a very economical way to connect a large number of objects to the DUL hierarchy at once: change what one namespace value is linked to, and every object carrying that value inherits the change, without touching each object individually.

The remaining documents in this set work through each of these three classification layers — what the possible values are, why they're drawn the way they are, and what a researcher gains from using them well — plus a fourth: microframes, the reified relations that let FNBr talk about ties between frames, entities, and events, and that are themselves grounded in DUL's own vocabulary of relations. See Microframes for that piece.

Perspective notions#

Perspective is not a single device in FNBr; it recurs at three levels of granularity, each taking a view over the objects one level below it. The same mechanism — choosing a construal without changing what is construed — operates on frames, on sets of frames, and on the lexical units that evoke a frame.

1. A namespace is a perspective over a frame. As set out above, the namespace records which view a frame takes over the underlying Event — @phenomenon, @change, @stative, @agentive, and so on. This is the coarsest perspective device: it classifies the frame as a whole.

2. The Perspective_on relation is a perspective over a set of frames. Original to FrameNet, this frame-to-frame relation groups sibling frames that offer alternative construals of one neutral, perspective-free scene (the classic Commercial_transaction profiled as Commercial_buy vs. Commercial_sell). The perspective is not a property of a single frame but of the contrast between the frames in the set.

3. A frame is a perspective over its LUs. At the finest grain, the frame itself imposes a construal on every lexical unit that evokes it. The lemma inherits the frame's view rather than carrying that view intrinsically.

This third level is why the same verbal lemma can be interpreted as an eventive, a stative, or an agentive verb: the lemma does not fix its own construal. Evoking an @phenomenon frame, it reads as an eventive verb; evoking an @stative frame, as a stative verb; evoking an @agentive frame, as an agentive verb. The lemma is one lexical form; the frame it evokes is what supplies the perspective — the LU-level echo of the Event/Situation distinction that organizes the whole model.