The Conceptual Dimension

Documentation baseline: 2026-10-13, connection prod, read-only. The conceptual dimension is about to undergo a broader review. These pages first document the existing records, without treating them as a newly approved design. See the snapshot and review register.

What this dimension describes#

The conceptual dimension supplies schematic structures against which a lexical frame's meaning can be analyzed: regions, ordered positions, containment, relations, occurrences, transformations and composed actions. A schema is represented as a frame with local FEs and explicit relations, not merely as a descriptive label.

The intended benefit is to make selected claims addressable: which positions a change connects, which participants are shared across component actions, or which relation holds between two roles. Prose remains necessary. An FE list or graph alone does not encode every entailment, temporal order or lexical distinction, and an available mechanism does not prove that all records using it are populated or validated.

For this baseline, schemas are inventoried by Structural namespace membership (frame.idNamespace = 16), not by their names. Production contains 45 such frames: 44 schema-prefixed names and Boulder. Some related lexical frames, notably Attributes and Bounded_region, are outside Structural and must not be silently counted as members.

The schema-prefixed inheritance graph has two roots:

  • REGION (3872): a concept represented as a region in conceptual space; one local FE, Region.
  • LINK (3881): an association between Relatum1 and Relatum2, without an inherent force commitment. Its explicit structure assertion uses associatedWith.

The previous prose treated every link as a force and every static configuration as equilibrium. That is not an accurate account of the current stored base definitions. EVENT now has only Event, with no required exerter, and CHANGE is force-neutral. Force transfer is explicit in FORCE_APPLICATION rather than presupposed at the occurrence floor.

The layer's region vocabulary is intended to describe organization and relations, rather than a universal metric distance between meanings. How this commitment should interact with quantity, force and the redesigned schema inventory remains a theoretical review question. The database graph alone cannot settle it.

The two-root inheritance account covers the 44 schema-prefixed records. Boulder instead inherits from lexical Event (168), so “every Structural frame reaches REGION or LINK” is not a true statement about the full production selection.

Different relations do different jobs#

Mechanism What the record says What not to infer
Inheritance A parent → child specialization; FE mappings are separate rows. Every child role has been mapped, or every restriction is operationally inherited.
Composition (rel_sub_frame, type 308) A composite → component link, with local-to-component FE mappings. The component is an inheritance parent, or the ordinary rel_subframe type 2 is interchangeable.
Structure (rel_structure) A mediator relates two local FEs, with bindings to its roles. Temporal execution order, or two new assertions from the two mediator-role bindings.
Frame constraint A particular local FE is constrained by a frame. A grounding of the whole host frame.
Grounding (rel_grounded_in) An explicit grounding relation when stored. Its presence from shared names, compatible meanings or inheritance alone.

The schema inventory contains the actual hierarchy and composition links. The snapshot has no explicit Grounded_in row touching the selected schemas or their FEs. Its 168 local FEs all have null reusable Element links. Those observations delimit what is implemented here; they do not forbid future grounding or Element-based analysis.

Profiling: foregrounding is not identity#

A profile foregrounds part of a semantic base. It does not by itself change a frame's namespace, create an additional LU home frame or equate all readings of a word.

Keep three levels distinct:

  1. Schema structure: the roles and relations available in a schema.
  2. Frame-to-schema analysis: explicit role correspondences supporting a particular grounding or composition.
  3. Lexical profile: what one LU foregrounds. Current repository documentation specifies reusable Element targets and frame-relative realizations; see Profiling.

A proposed analysis can combine more than one structure, such as motion and containment. That is a modeling proposal until the actual edges and mappings are recorded. An example using entrar is not evidence that a production frame has two groundings. Likewise, a shared Element is not another direct lexical evocation.

Multimodal annotations can also evoke frames, but this Structural inventory audit does not establish a profiling implementation for every kind of evoking element.

Relation to the other dimensions#

Dimension Main question
Ontological What semantic category or modeling function does the frame represent?
Conceptual What schematic structure supports the analysis, and which roles or relations are relevant?
Domain What area of experience does it concern?

These questions are related but not interchangeable. In particular, an Agentive namespace does not require a schema named AGENTIVE; none is in this Structural snapshot. An Experiential namespace can remain valid without a Structural EXPERIENTIAL member. The State namespace includes general and resultant situations beyond the maintenance-oriented interpretation in the current STATIVE schema definition.

Schema analysis must preserve the distinctions established by the frame's definition and lexical evidence. It cannot automatically replace namespace review, merge frames or move LUs.

Reading order#

  1. Schemas: all current members, inheritance, composition and known contradictions.
  2. Grounding a Frame: distinguish interpretation, stored mappings and missing evidence.
  3. Lexical Units and Profiling: denotation, reusable Elements and lexical prominence.
  4. Microframes: explicit local structure assertions and mediator roles.
  5. Principles and Diagnostics: a cautious review procedure, not the former automatic cascade.