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:

Two cases: external and internal profiling

Profiling comes in two cases, distinguished by where the profiled FEs live relative to the LU:

• External profiling. The profiled FEs live in a different frame from the one the LU is housed in. This is the comprador pattern — an entity LU in a classificatory frame profiling an FE of an event frame elsewhere in the network (detailed just below).
• Internal profiling. The profiled FEs live in the same frame the LU evokes — e.g. comprar foregrounding Buyer and Goods within Commerce_buy, the very frame it is a member of.

Both cases are recorded identically: a lu_profiling row points an LU directly at a profiled FE. The external/internal label is not stored — it is derived by comparing the profiled FE's frame with the LU's own frame. The Implementation section describes this single mechanism.

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. Each external profile is a cross-frame edge from a classificatory frame to an event frame, enriching the TQR connectivity available for spread activation. The edge is now derived from the lu_profiling row (LU in frame A → FE in frame B implies an A→B edge) rather than materialized as a separate frame-to-frame relation; any graph consumer reads it off lu_profiling.
• Avoidance of LU duplication. The entity need not be re-listed as an LU inside every event frame it participates in; one profile pointer to the event frame's FE 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

Both cases of profiling are recorded in a single lu_profiling table, the same way: one row points an LU directly at a profiled Frame Element. Nothing distinguishes external from internal in storage; the label is derived by asking whether the profiled FE belongs to the LU's own frame (internal) or to another frame (external).

The lu_profiling table

lu_profiling
  idLuProfiling   PK
  idLU            FK → lu.idLU                        (ON DELETE CASCADE)
  idFrameElement  FK → frameelement.idFrameElement    NOT NULL, ON DELETE CASCADE
  rank            INT                                 NULLABLE

A row names the LU (idLU), the profiled FE (idFrameElement), and an optional rank for ordering the LU's profile. There is no relation to entityrelation: the earlier idEntityRelation anchor column and the whole rel_profiling Frame-to-Frame apparatus have been removed.

Mode is derived, not stored. Compare the profiled FE's frame (frameelement.idFrame) with the LU's frame (lu.idFrame): equal ⇒ internal, different ⇒ external. The repository computes this per row for display; no column carries it.

Uniqueness. A single rule covers every row: UNIQUE (idLU, idFrameElement) — an LU profiles a given FE at most once. Because idFrameElement is NOT NULL, the MySQL "NULLs compare as distinct" caveat does not bite, so one plain composite unique constraint suffices.

External and internal are one mechanism

An external profile and an internal profile are the same kind of row — a direct (idLU, idFrameElement) pointer with a rank. The only difference is where the FE lives:

• Internal — the FE is one of the LU's own frame's FEs (e.g. comprar → Buyer, Goods within Commerce_buy).
• External — the FE belongs to a different frame (e.g. comprador in People_by_transitory_activity → Buyer of Commerce_buy). The cross-frame edge is implied by the row (LU's frame → FE's frame); it is read off lu_profiling rather than stored as a separate frame-to-frame relation.

This replaces the earlier external design, which modelled external profiling as a rel_profiling Frame-to-Frame relation (carrying FE-to-FE child relations) that the lu_profiling row merely anchored. That avoided repeating an FE mapping shared by several LUs, but it made external and internal profiling two parallel mechanisms for no real gain — the data volume never justified the complexity. A direct FE pointer, already proven by internal profiling, does the job for both.

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 profile row records finely which FE (and, through the FE's frame, which event frame). This yields a free consistency check — if an .entity«event» LU's profile does not name the FE (and event frame) implied by its parameter, something is wrong.

Profile rows and rank

A profile — internal or external — is a set of direct FE rows, one per foregrounded FE.

Direct FE rows

Each profiled FE is one lu_profiling row naming the LU and the FE: idLU + idFrameElement (+ rank). A multi-FE profile is therefore several rows, one per foregrounded FE, all sharing the same idLU. The rows stand on their own and are removed individually (or with the LU/FE they reference). This is exactly the shape used for the same-frame case — comprar profiling Buyer and Goods within Commerce_buy — and, identically, for the cross-frame case.

Rank — ordering the profiled FEs

The rank column orders an LU's profile. The ordering is the subject/object assignment: the top-ranked FE is the trajector — the default subject — and lower ranks descend through the remaining foregrounded arguments. For comprar in Commerce_buy this is two rows, Buyer at rank 1 and Goods at rank 2. Where two poles are genuinely symmetric (no inherent subject/object asymmetry), they are recorded as unordered rather than forced into a rank order.

This section documents only what rank stores and means. Exploiting it — deriving a default linking prior for the parser, or defining perspective pairs from permuted ranked profiles — is deferred (see below).

Consistency with ontological type (Layer 1)

For an .event, .attribute or .relation LU, an internal profile makes explicit which of its own frame's FEs the LU foregrounds and in what order — a finer-grained statement of the same participant structure the LU's type implies. As with external profiling, a mismatch between the ranked profile and what the LU's type leads one to expect is a signal that something needs review.

User interface

All profiling — internal and external — is entered on the frame editor's Profiles tab; the F-F Relation tab is no longer involved. The tab presents one form and a list:

• Form. Pick an LU housed in the frame; pick a Frame (defaulting to the current frame — leave it for an internal profile, or search for another frame for an external one); pick a Frame Element of the selected frame (the FE picker reloads when the frame changes, via GET /components/fesByFrame); and optionally give a rank.
• List. The profiles already recorded for the frame's LUs (LU › Profiles › FE), each tagged internal or external (external rows also show the FE's home frame), with the rank, each removable.

Under the hood the tab uses the endpoints POST /relation/profiling/lu and DELETE /relation/profiling/lu/{idLuProfiling} and the App\Repositories\LuProfiling repository, whose allProfilesByFrame() derives each row's internal/external mode by comparing the profiled FE's frame with the LU's frame.

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). For internal profiling this is concrete: the several ranked lu_profiling rows of a single LU are one multi-profile only if they form one construal — if the FEs belong to alternative construals, the rows belong to two separate LUs, not one.

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

Profiling (above) now records both the same-frame and cross-frame cases as direct FE rows with a rank. What remains out of scope — parked here so the roadmap is not lost — is the exploitation of those ranked profiles:

• 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 internal 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. Fuller interaction with .event, .attribute and .relation LUs (participant vs. whole-eventuality profiling, attribute/value profiling, relation-pole profiling) beyond the direct FE-ranking recorded above.