Webtool 4.5
Frame
Lexicon
Construction
Ontology
Grapher
Dashboard
Documentation
FN 1.7
Portuguese
English
Portuguese
Spanish
French
Japanese
Home › Documentation › Framenet/Frame Classification
Login

Frame classification

Non-lexical (Book 6.2.2.1)

Such frames have no lexical units and are present purely to connect two (or more) frames semantically. One example is the Post getting frame, connected to Getting via a Precedes relation and connected to Possession via an Inheritance relation. This practice allows us to succinctly encode the fact that the state following “getting X” (the Getting frame) is “having X” (the Possession frame).

Non-perspectivized (Book 6.2.2.2)

This semantic type is used for frames that have a great diversity of lexical units, all of which share a kind of scene as a background. Such frames do not have a consistent set of FEs for the targets, a consistent time assigned to the events or participants, or (most especially) a consistent point-of-view between targets. An example of this type of frame is the Performers and roles frame, which contains such diverse LUs as co-star.v , feature.v , and as.prep. Like the Biframal LU types, this semantic type is intended as a time-saving measure. All such frames could be split up into smaller frames with a consistent perspective, but these frames would contain very few LUs. (Sec. 6.2.3.4 on Biframal LUs.)

Conceptual

Frames presenting a conceptual/image schematic situation (both lexical and non-lexical frames).

Scenario

A Scenario frame holds together a specific complex scene whose unfolding the language can construe from more than one perspective, or that decomposes into an ordered set of subframes sharing the same participants. Scenario frames provide a structural scaffold — the combination of roles, setting conditions, perspectives, and typical sub-event sequences that constitute a familiar situation type.

The commercial-transaction scene is the canonical case. Buying and selling are not unrelated frames; they are two perspectives on one scene in which a Buyer and a Seller exchange Money and Goods. The Commerce_scenario frame is the scaffold that holds the scene together, and Compra (buy) and Venda (sell) are its perspectives. Likewise the Employment scenario binds the Employer and Employee perspectives; the Giving scenario binds Donor-centred giving and Recipient-centred getting; the Motion scenario binds setting out, travelling, and arriving as subframes of one journey.

A scenario exists when a scene (a) can be entered from more than one participant's point of view (Perspective_on), or (b) breaks into ordered phases that carry the same participants across them (Subframe). A frame that merely names an area of experience — anatomy, motion-in-general, weaponry — is not a scenario; it belongs to the Domain taxonomy.

Key properties of Scenario frames:

  • Multi-perspective or subframe-structured: the defining trigger is that the scene supports two or more perspectives on the same participants, or unfolds as ordered subframes that share them
  • Multi-participant: two or more roles are typically required — a consequence of the multi-perspective structure, not the criterion itself
  • Phase-structured: scenarios unfold through recognizable phases or sub-events tied together by shared participants
  • Type-level: Scenario frames name a kind of situation, not a specific occurrence; they serve as organizing schemas that other frames inherit from or use as a setting
  • Non-reducible: the scenario cannot be collapsed into a single event, attribute, or relation without losing the multi-perspective scene
  • Orthogonal to Domain: a scenario is itself a frame, and is itself classified under a domain (see vs. Domain below); the two layers are independent, and a frame has a scenario only when it participates in such a scene

Hierarchical Scenarios

Scenarios may be related to one another, so that a scenario can be a subframe of a more abstract scenario, or an abstract scenario can gather several concrete ones as subframes. This lets a scene be reused across more than one situation, and lets general scenes be built whose specific cases are spelled out as children.

The abstract Transfer scene, for example, is specialized to the concrete Giving, Getting, and Commerce scenarios, which share its Donor/Recipient/Theme structure while adding their own perspectives. Transportation is a further case: centred on the multi-perspective act of operating a vehicle to move from a source to a goal, it is a genuine hierarchical scenario whose subframes (Operate_vehicle, Motion, and their kin) construe the same journey from different points. It is filed under its centre of gravity — Motion — while reaching by secondary links into Artifacts (the vehicle) and Economy (transport as a service).

Cross-cutting coverage topics, by contrast, are handled by the Domain taxonomy, not by a "super-scenario." Food spans several domains — eating is a physiological function, food as substance is matter, cooking is a physical transformation, food service is an economic transaction — but it is a thematic area, not a scene viewed from several perspectives, so it is modelled as a domain node whose facets sit in the subdomains where each construal naturally lives. A shared scene becomes a hierarchical scenario; a shared topic becomes a region of the domain tree.