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 FE display names in the resource were read against DUL's Concept subclasses, and all of them sorted into one of six buckets:

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

Why PropositionType is kept apart from EventType. An ordinary embedded event — the Event that occurred — really did happen, or is talked about as if it did. State_of_affairs, by contrast — "an event, a state, or a property that the Agent wants others to believe have occurred or hold" — names something someone is asserting, which might turn out to be false. Classifying an event that occurs and classifying a claim someone is trying to get believed are different acts: the second can be false, the first cannot.

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), every FE 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). An FE never carries the DUL link directly — it inherits its concept-kind 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#

Not every FE denotes a Concept at all. Three further patterns showed up in the full survey and are excluded from this axis on purpose, not by oversight:

A small residual pocket — Norm, Rule, Precept, Standard, Criteria (under 30 rows total) — is folded into ClassifierConcept rather than minted a seventh kind: the volume doesn't clear the bar for a new bucket on its own, and it can be revisited if it grows.

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/>+intentional +volitional]
        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, carried over from prior analysis:

• 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). This is a migration away from an older, now-legacy device: filler restrictions used to be recorded as links to SemanticType entries (sty_sentient_1, sty_state_of_affairs_1, sty_place_1, and so on); those have been carried over one-for-one into @class frames (frm_class:sentient, frm_class:stateofaffairs, frm_class:place...), and new filler restrictions are recorded against the @class frame directly, not the old SemanticType row. This device answers "what class does the filler belong to?" — the same question a filler restriction has always asked.

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. This is a live, populated mechanism (over 3,700 rel_constraint_frame rows on FEs), not a proposal.

A class restriction and a frame constraint can sit on the same FE at once, and they're never in tension, because they answer different questions: 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.

This axis also absorbs the FEs that fall outside the six concept-kinds above. FEs whose own semantics is a Quality/Region rather than a Concept — Descriptor, Attribute, Value, Color, Shape — are described by their filler restriction instead of a concept-kind, because the FE itself denotes a property value rather than classifying a concept: frm_class:quality and frm_class:region are themselves among the @class frames FEs are typed against. FEs that denote an InformationObject — Name, Term, Text, Sign, Document, Label, Title — are handled the same way, against frm_class:informationobject.

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.