Profiling

Introduction and Motivation

Frame membership already establishes a relation between a Lexical Unit (LU) and the Frame Elements (FEs) of the frame it evokes. But this relation is weak and undifferentiated: every LU in a frame is related, in the same flat way, to the frame's entire FE inventory. Frame membership alone tells us that the LUs
are all "related to" the FEs — but it does not tell us that a specific LU can foreground a specific FE, even though this difference is a reason to have distinct LUs.

Profiling supplies the missing differentiation. In the Fillmore/Langacker sense, an LU evokes a frame (its base) and profiles some aspect or component of that frame — the element it makes focal. Recording this explicitly turns a flat "related to all FEs" into a structured "foregrounds these FEs against the backgrounded rest."

The FrameNet paper (Fillmore & Baker, 2010) discusses profiling as a principle, but the public FrameNet database does not implement an LU→FE profile relation. What the database does record is a distinct relation, incorporation (e.g. the verb box.v incorporates the Placing.Goal FE), stored as a field on the LU table. Incorporation and profiling must not be conflated:

Entity LUs and external evocation

The comprador case is the paradigm case for external profiling: it is one instance of a systematic pattern in which an entity LU, housed in a classificatory frame, profiles an FE that is a participant of an event frame elsewhere in the network. Some representative cases:

In each row the classificatory frame states what kind of entity the LU denotes (a person by transient activity, by criminal status, by health condition), while the profiled FE — and hence the entity's actual content — lives in the event frame(s) the entity participates in.

This pattern carries consequences that motivate implementing external profiling as a first-class relation.

Theoretical consequence. A frame comes to be evoked not only directly, by its own LUs, but also indirectly, by "external" LUs housed in other (classificatory) frames. The entity noun paciente evokes the health-event frames it participates in, even though those frames are not its lexical home. Frame evocation is thus distributed across the network rather than confined to a frame's own LU list — an extension of the standard Frame-Semantic notion that a sign evokes the frame that interprets it.

Practical consequences.

• Network densification. Cross-frame profile edges connect classificatory frames to event frames, enriching the TQR connectivity available for spread activation.
• Avoidance of LU duplication. The entity need not be re-listed as an LU inside every event frame it participates in; one anchored profile pointer replaces many redundant memberships.
• More frames inferred by the sentence parser. An "external" LU in a sentence can license inference of the event frames it profiles into, so a single entity noun raises the number of frames the parser can recover from the sentence.
• Explicit FE semantics. The profile makes the semantic content of an FE explicit — Buyer is not merely a role label but is tied to the entity LUs that realize it — rather than leaving the FE's meaning implicit in annotation practice.

Implementation

External profiling is implemented as a Frame-to-Frame relation, closely modeled on the existing Using relation (rel_using). Like the other frame relations (rel_using, rel_perspective_on, rel_inheritance, …) it is stored as a row in entityrelation, and — exactly as those relations do — it carries a set of associated FE-to-FE relations as child rows. The LUs that occasion the relation are recorded separately, as a many-to-many association in a dedicated lu_profiling table.

The profiling relation

• Relation type. A new relation type, rel_profiling.
• Endpoints. The relation connects the classificatory frame (the lexical home of the entity LU) to the event frame whose FEs the LU profiles — the two frames' idEntity values, just as rel_using connects two frames. Direction runs from the classificatory frame to the profiled event frame.
• Anchoring at the LU. Although the endpoints are frames, the relation is occasioned by LUs in the classificatory frame (e.g. comprador, cliente). Which LUs do the profiling is recorded in the lu_profiling table (below), not on the entityrelation row itself.

LU anchoring — the lu_profiling table

The profiling relation is occasioned by LUs housed in the classificatory frame, and several LUs may share the very same profiling relation: when they profile the same event frame in the same way, the relation's definition and its FE-to-FE mappings are identical for all of them, so there is no reason to duplicate the frame relation per LU. The anchoring is therefore a many-to-many association, stored in a dedicated join table rather than on the relation row:

lu_profiling
  idLuProfiling     PK
  idEntityRelation  FK → entityrelation.idEntityRelation   (ON DELETE CASCADE)
  idLU              FK → lu.idLU                           (ON DELETE CASCADE)
  UNIQUE (idEntityRelation, idLU)

Each row anchors one LU to one profiling relation. Because the same frame pair can be profiled by many LUs, one entityrelation (profiling) row typically has several lu_profiling children; conversely, a single LU may anchor several distinct profiling relations (to different event frames). Deleting the profiling relation cascades to its lu_profiling rows.

This is why the anchor is a join table and not the ternary entityrelation.idEntity3 slot used by other ternary relations: idEntity3 would force exactly one LU per relation row and thus duplicate the frame relation (and its FE-to-FE children) once per LU.

Associated FE-to-FE relations

The profiled FEs are recorded as child FE-to-FE relations tied to the parent profiling relation, in the same way other frame relations carry their FE mappings: each child relation is stored in entityrelation with its idRelation pointing back to the parent profiling relation's idEntityRelation, so that deleting the frame relation cascades to its FE relations.

Each associated FE relation links an FE that the entity LU makes focal to the corresponding participant FE of the event frame — e.g. comprador's profiling of Commerce_buy associates it with the Buyer FE.

Consistency with ontological type (Layer 1)

For an .entity«event» LU, external profiling and the Layer-1 parameter are the same fact at two grains: the parameter records coarsely that the entity is individuated by an event; the profiling relation records finely which event frame and which FE. This yields a free consistency check — if an .entity«event» LU's profiling relation does not name the FE (and event frame) implied by its parameter, something is wrong.

User interface

Profiling relations are created and their FE-to-FE mappings edited on the frame's F-F Relation tab, like any other frame relation. LU anchoring lives on a dedicated Profiles tab of the frame editor. That tab presents a form to anchor an LU to one of the frame's profiling relations — a selector listing the frame's existing rel_profiling relations (by profiled event frame) and a picker restricted to LUs housed in the frame — followed by the list of anchors already made (LU › Profiles › event frame), each removable. The form/list layout mirrors the LU TQR-reference page.

Under the hood the tab reuses the endpoints POST /relation/profiling/lu and DELETE /relation/profiling/lu/{idLuProfiling} and the App\Repositories\LuProfiling repository.

Situations Requiring Caution

Multi-profiling vs. polysemy. A single profile whose members form a configuration (an LU profiling several FEs as one construal) is genuine multi-profiling. An LU that profiles one FE or another depending on use is two distinct LUs (polysemy) and must be split under the splitting commitment. Diagnostic: one construal foregrounding several FEs (multi-profile) vs. two construals each foregrounding one (two LUs).

Terminology / type–namespace drift. Profiling is a construal-level foregrounding relation, distinct from ontological type and from namespace. Attributive verbs are profiled-attribute cases, not a new namespace; a stative verb remains .event + @stative. Keep the profile from silently absorbing type or namespace information.

Incorporation is not profiling. An incorporated FE is fixed; a profiled FE is foregrounded and realizable. They may co-occur on one LU targeting different FEs (box.v incorporates Goal, profiles Theme/Recipient). Keep the two relations and their diagnostics separate.

Deferred to later steps

The following are intentionally out of scope for this first step and are parked here so the roadmap is not lost:

• Internal profiling. The case in which an LU and the FEs it profiles live in the same frame (comprar → Buyer, Goods within Commerce_buy). The mechanism above is external-only.
• Rank / ordering of profiled FEs. The ranked-list model — where the ordering is the subject/object assignment, the top-ranked FE is the trajector/default subject, and symmetric relations are flagged as unordered poles.
• The default linking prior. Using the top-ranked profiled FE to predict the most prominent argument, feeding the semantic-valence field and the frame parser.
• Perspective subsumption. Defining perspective pairs as two LUs in one frame whose ranked profiles are permutations differing in the top-ranked FE (comprar [Buyer, Goods] vs. vender [Seller, Goods]), and the derivation of paraphrase / converse signals from shared vs. complementary profile sets.
• Profiling across the full ontological-type range. Interaction with .event, .attribute and .relation LUs (participant vs. whole-eventuality profiling, attribute/value profiling, relation-pole profiling).