Classifying Frame Elements

A Frame Element (FE) is FrameNet's most local unit of description — Cook in Apply_heat, Killer in Killing, Buyer in Commerce_buy. FrameNet deliberately names frame elements per frame, and this model has no interest in undoing that: Cook and Killer are not literally the same role, and collapsing frame-specific names into one shared inventory would throw away real distinctions FrameNet is careful to preserve.

At the same time, many frame elements plainly share a high-level semantics — the Cook, the Killer, and the Builder are all, at a coarser level, agentive instigators of their respective events. The model records that shared structure without touching the frame-specific names, through three genuinely independent facts a frame element can carry:

Each axis is developed in its own section below.

The FE's own concept-kind#

The concept-kind vocabulary distinguishes six kinds using DUL's Concept subclasses. Classify from each FE's definition and function, not its name alone; this vocabulary is not evidence that every FE has been reviewed or populated:

Two of these distinctions are easy to miss at first glance, and worth spelling out:

Why PropositionType differs from EventType. EventType concerns an embedded occurrence or situation; PropositionType concerns content that can be believed, asserted or evaluated for truth. Neither label establishes actual occurrence: an embedded event can be hypothetical, intended or negated. State_of_affairs and similar names require their frame-specific definitions to determine whether the FE is content or an embedded situation.

Why ClassifierConcept earns its own place. An FE like Type or Category doesn't hold a participant, a value, or an embedded event at all — its filler is itself a concept that classifies something else. This recurs across independent lexical domains — subtype classification, sensory categorization, cognitive framing — often enough, and distinctly enough from the other five kinds, that it earns its own bucket rather than stretching one of them to cover it.

The mechanism mirrors the one frames use. Just as every frame carries a frame-scope namespace value (see Frames), an FE classified on this axis carries an FE-scope namespace value — Role, Parameter, EventType, Task, PropositionType, or ClassifierConcept — and each of those six values, not the individual FE, carries the rel_hasontotype link to a DUL Concept subclass (frm_class:role, frm_class:parameter, and so on; frm_class:role itself inherits from frm_class:concept via rel_inheritance, confirming it really is a Concept subclass rather than just a same-named frame). For concept-kind, the FE obtains its DUL classification derivatively, through whichever of the six namespace values it's assigned to, the same one-link-per-value, many-objects-inherit-it economy the frame-scope namespace already uses for its own DUL grounding.

What falls outside the six kinds#

Some FE descriptions need additional care on this axis. Filler type does not by itself determine the kind of the FE concept. The following patterns require separate filler or scaffolding analysis rather than classification by name:

Norm, Rule, Precept, Standard and Criteria may be ClassifierConcept when they classify content in the frame. Their names or frequency do not alone determine the answer; defer unclear cases.

Qualia type#

FrameNet assigns frame-specific Frame Elements (FEs) by design — Cook in Apply_heat is not literally the same FE as Agent in Killing. This specificity is a strength and the current model does not seek to abolish it. But it is plainly true that many FEs share a high-level semantics: the Cook, the Killer, the Builder are all, at a higher level, agentive instigators.

The model exploits this shared high-level semantics using qualia types, adapted (roughly) from the Qualia Structure of the Generative Lexicon. Qualia types are not new FEs and do not replace frame-specific FEs. They are a small classifying vocabulary used to group FEs across frames and to describe the characteristic participant structure of each namespace.

The four qualia types:

The generic event structure, showing all four roles and their relation to the Event, is the backdrop against which each namespace profiles a subset:

graph BT
    subgraph AQ["AGENTIVE ROLE"]
        Agent[Agent<br/>+intentional +volitional]
        Cause[Cause<br/>+causation -intentional]
        Cognizer[Cognizer<br/>cognition; control varies]
        Source[Source<br/>-intentional -volitional]
    end

    subgraph TQ["TELIC ROLE"]
        Patient[Patient<br/>+affected +endpoint +change]
        Experiencer[Experiencer<br/>+perceiver +experiential]
        Goal[Goal<br/>+recipient +destination]
        Result[Result<br/>+recipient +endpoint]
    end

    subgraph CQ["CONSTITUTIVE ROLE"]
        Theme[Theme<br/>+participant -specific_role]
        Instrument[Instrument<br/>+means +used_by_agent]
        Path[Path<br/>+component]
        Part[Part<br/>+component]
        Material[Material<br/>+substance]
        Value[Value<br/>+component]
    end

    subgraph FQ["FORMAL ROLE"]
        Entity[Entity<br/>+participant]
        Activity[Activity]
        Relation[Relation]
        Condition[Condition]
        State[State]
        Attribute[Attribute]
        Category[Category]
    end

    Condition -->|predicates| Theme
    Theme -->|participates_in| Event
    Agent -->|intentionally_causes| Event
    Cause -->|causes| Event
    Source -->|origin_of| Event
    Cognizer -->|acts_on| Event

    Activity -->|is_a| Event
    State -->|is_a| Condition
    Attribute -->|is_a| Condition
    Category -->|is_a| Condition
    Relation -->|is_a| Condition

    Instrument -->|is_a| Theme
    Part -->|is_a| Theme
    Material -->|is_a| Theme
    Value -->|is_a| Theme
    Entity -->|participates_in| Event
    Path -->|is_a| Theme

    Event -->|affects| Patient
    Event -->|stimulus_for| Experiencer
    Event -->|directed_to| Goal
    Event -->|results| Result
    Event -->|affects_reflexively| Agent
    Event -->|mutual| Agent

    Patient -->|from| Condition
    Patient -->|to| Condition
    Experiencer -->|to| Condition

FrameNet names the roles by frame context; the labels above are the high-level classifying vocabulary. Two cautions apply:

• A frame-specific FE may not fit exactly one qualia type. Qualia types are a grouping criterion, not a partition. Where an FE spans roles (the notorious Theme; see below), it is entirely legitimate for the FE to carry more than one qualia type at once — see the note on cross-type FEs below.
• Qualia types answer "what role does this FE play in the event". They are distinct from filler restrictions (see below), which answer "what kind of thing fills this FE". The two axes are orthogonal and the model uses both.

Note on cross-type FEs#

Patient, Experiencer, and Theme are intrinsically multi-role, and the model treats this as expected, not as a defect. The device supports this directly, rather than forcing a single label: a qualia type is itself a SemanticType entry (sty_agentive_qualia, sty_telic_qualia, sty_constitutive_qualia, sty_formal_qualia — children of sty_qualia_type), and an FE is linked to one through the same rel_hassemtype relation used throughout the resource, which is many-valued by construction. A cross-type FE simply carries more than one such link; nothing about the mechanism prefers a single "profiled" type over the others.

• Patient combines TELIC (affected endpoint), CONSTITUTIVE (participant), and FORMAL (the entity that ends in a state).
• Experiencer combines TELIC (endpoint of a stimulus), AGENTIVE (when under control, e.g. olhar), and FORMAL (bearer of a mental state, e.g. saber).
• Theme is the most generic CONSTITUTIVE participant and is deliberately underspecified for affectedness. It is the default role for a participant with no sharper characterization.

Filler restriction#

A filler restriction is the most literal of the three axes: a constraint on whoever occupies the FE slot — but, as the two devices below show, not always the same kind of constraint. It is a claim about the FE's filler, not about the FE itself, and it is independent of the other two axes: it says nothing about whether Cook is a Role, a Parameter, or any of the other concept-kinds from the first axis, and nothing about which qualia type Cook carries in Apply_heat.

The axis runs on two genuinely different devices, not one.

The first is a class-membership expectation: a rel_hasontotype relation from the FE to an @class frame — a frame that exists purely to represent a DUL class inside FNBr's own frame inventory (see the @class namespace). Examples include frm_class:sentient, frm_class:stateofaffairs and frm_class:place. This device answers "what class does the filler belong to?"; it is independent of the FE's own concept-kind.

The second is a coercion reading, and it asks a different question entirely: not what class the filler belongs to, but whether the filler's own content is interpreted as evoking a frame. rel_constraint_frame and rel_constraint_framefamily record this. The relation doesn't run directly from the FE to the constraining frame; a generic constraint_entity row names what's constrained (the FE), what it's constrained by (a Frame, for rel_constraint_frame, or a frame family, for rel_constraint_framefamily), and a constraint group that lets several alternatives stand as a disjunction. In Attracting_tourists, for instance, the Attraction FE carries two such rows — one constrained by Natural_features, one by Buildings, both in the same constraint group — recording that whatever fills Attraction is read as evoking one or the other when the group is disjunctive. Constraint expressions can also be nested through CON nodes. Inspect the full expression, operators and endpoint types before determining its meaning or reporting an association absent; a direct-FE-only extraction is incomplete.

A class restriction and a frame constraint can sit on the same FE at once, and they answer different questions and must be checked for joint satisfiability: is the filler a member of DUL class X, versus does the filler's content itself evoke frame Y. Neither one is derivable from the other — a filler can belong to the right class without evoking the expected frame, or vice versa.

Quality, Region and InformationObject can be filler restrictions for FEs such as Attribute, Value, Name or Document. These restrictions do not settle the FE's own concept-kind; inspect the frame-specific definition separately.

Participant associations#

FNBr places agentive names in Entity frames, with a separate association to the relevant event or relational FE. Use an FE–Frame association only when all relevant LUs of the Entity frame suit the intended contribution; otherwise use LU–FE associations for the qualifying subset. A direct missing link is not proof of absence until nested constraints have been resolved.

CoreSet, Requires and Excludes#

These FrameNet devices are distinct from concept-kind, qualia and filler typing:

• CoreSet: any member can satisfy the semantic valence; members may co-occur.
• Requires: realization of one FE requires another in the relevant pattern.
• Excludes: alternatives cannot be direct dependents of the target on the same annotation layer; embedded layers can realize both.

Apply them per frame, not universally by namespace. Experiencer/Cognizer labels do not automatically create Excludes, and an Excludes group does not by itself require separate perspective frames. See FrameNet patterns for verified book references and participant-policy provenance.

Why this matters in practice#

Together, the three axes let a modeller describe a frame element far more precisely than a bare, frame-specific name alone can. Auditing a frame, or deciding how to name a new frame element, becomes three separate, focused questions instead of one vague one: what kind of concept is it, in its own right (its concept-kind), what part does this play in the event (qualia type), and what's allowed to fill it (filler restriction)? Keeping the three questions separate — rather than trying to answer all of them with one label — is what makes each answer sharp enough to actually be useful.