Microframes Inside a Schema

Every relation is a force named by a microframe#

The Introduction puts it plainly: a force is never an object in its own right — it's known only by its effects, and all of its actual content lives in which specific relation names the tie between two regions. A microframe is exactly that name: a binary relation, represented as a frame with two arguments, that FNBr's schemas use to wire their own elements together. Microframes introduces the general mechanism — two arguments, conventionally called Domain and Range, grounded outward in DUL (DOLCE+DnS Ultralite), the same foundational ontology the schemas' own bearer/value machinery (OBJECT, VALUE, Attributes) is read against. Every microframe cited on this page carries that grounding — see DUL Grounding for how a relation resolves to a specific DUL object property or class. This document is about the narrower, practical question a modeler actually faces: which microframe wires which pair of elements inside a given schema, and how to tell when an existing one already covers a new case.

A schema is genuinely wired by these rows, not just described by them. Every microframe conceptually specializes link — the same primitive relation the whole layer is built from — so a schema acquires its own tie to link simply by carrying relation rows, without needing any separate edge to link itself.

Region-in-dimension: one generic relation, several specific readings#

Every child of DIMENSION relates its own member elements back to the dimension that organizes them, and that relation is always some specialization of one shared, generic idea: a region is organized within a dimension. Which specific microframe actually names the row depends on how the organizing happens:

CLASS uses the first, PART_WHOLE the second, AXIS and Attributes the third — each one the most specific reading that actually fits its own case, rather than the generic relation restated three times under three different names. PART_WHOLE additionally has a is member of option for collection membership specifically — João pertence ao clube ("João belongs to the club") is a different force from a roda é parte do carro ("the wheel is part of the car"), even though both are compositional in the broad sense.

Mediated relations: a chain, and a fork#

Two schemas each connect three roles through a middle term, and it's worth seeing both shapes side by side, because they look similar and aren't.

Attributes is a chain: the bearer relates to the dimension via the value it holds — entity to value, then value to attribute, two separate rows. FIGURE_GROUND is a fork: the figure relates to the ground via the profiled region it's situated within, but the mediator relates outward to the ground in one direction and inward to the figure in the other. Both patterns recur elsewhere in the inventory, and recognizing which shape a new candidate actually has is often the fastest way to see which existing schema it belongs with.

The event family's own force rows#

Bare EVENT is wired by a single row, deliberately as neutral as possible, naming the tie between the entity that exerts and the force itself:

Every schema built on top of EVENT either inherits this row unchanged or pins it to something more specific. AGENTIVE pins it to agentively causes — an agent causing the occurrence of an event. UNDERGOING adds a row of its own instead, is affected by event, between Antagonist and Event — the force registering on the affected entity. EXPERIENTIAL adds a single row, cause experience, straight between Agonist and Antagonist, carrying both the exerting and the receiving side at once. AGENTIVE also adds is affected by agent, between Agonist and Antagonist, but only where Antagonist happens to be bound — a weaker claim than UNDERGOING's, affectedness without the fuller event-mediated registration.

CHANGE — the family's own home for directed change, category, degree, or plain accidental — carries the rest of the cast:

TRANSITION and MOTION, CHANGE's own children, each pin the transition from to row down further, in different directions: TRANSITION adds an entirely new row instead, is classified by, between Antagonist and Outcome — reclassification, not just a new value; MOTION narrows transition from to itself to a more specific microframe, moves from to, wherever the transformation is a genuine displacement rather than a category or degree change. Nothing about the rest of the cast changes in either case; only which force is asserted on that row does.

Two further, very general microframes show up wherever two positions need to be asserted equal or distinct: STATIVE holds Income and Outcome equal, against a force that would otherwise change them; BLOCKAGE holds Outcome and Target apart, recording that the transformation stopped short of where it was aimed. Neither of these is specific to the event family — they're the layer's general-purpose way of asserting that two regions are, or aren't, the same one.

Not every row is grounded the same way#

Two rows can both look like a plain tie between elements and still differ in what they're actually claiming. Some microframes hold directly between two individuals and are grounded as a sub-property of a DUL object property (property-grounded — is_region_for, used throughout this page, is one). Others denote a situation type that defines roles and classifies the entities filling them, grounded instead as a specialization of a DUL class (description-grounded). Recording that difference matters because a description-grounded microframe's Domain and Range are Roles a Situation defines, not two independent endpoints — collapsing the distinction would overstate what the row actually asserts. See DUL Grounding for the full property/description split, which microframes are which, and how it lines up with each microframe's semantic category.

Choosing between an existing microframe and a new one#

The inventory is meant to grow the same way the schema inventory does: by adding a specific, individually nameable relation whenever one is genuinely needed, not by budgeting how many can exist. A new microframe earns its place when some row genuinely needs to be written that nothing already in the inventory can name.

A few practical checks catch the cases that don't actually need a new one:

• Same force, arguments swapped. Has part and is part of are one relation, not two — direction is carried by which argument sits in which slot on the row, not by having two mirror-image relations.
• Same force, narrower filler. If a candidate differs from an existing microframe only in what kind of thing fills its arguments, and the frame or schema citing the row can already type that filler on its own, a coercion on the element does the job — no new relation needed. Causes emotion and causes infection differ in what gets caused, which is exactly this case.
• Two existing relations, chained. A candidate that's really two microframes joined through a middle term isn't a new relation — it's a pattern over two existing rows, the same way Attributes' own chain is two rows rather than one.
• Already named, under an unfamiliar label. The vocabulary this layer draws its microframes from isn't FrameNet's own, so a search by name can miss a real match. Searching by what the candidate actually means — its gloss — rather than by what it happens to be called catches this.

Where none of these apply — the force is genuinely new, distinct from anything already named, and some row actually needs to assert it — minting a new microframe is exactly the right move, and it's a cheap one: a microframe carries no elements of its own beyond its two arguments, so adding one never touches the rest of the inventory.