Classifying LUs

Each LU (a lemma + sense pairing) carries an ontological type: a coarse, semantic classification of the concept's stable identity. It is not a part-of-speech and is orthogonal to the LU's UD POS tag. It tracks the DUL thing identity — what kind of thing the concept is — independent of syntactic realization or constructional construal.

The mechanism is the same namespace device frames and FEs use, scoped to lu. Every LU carries an idNamespace link to one of nine LU-scope namespace values (nsp_lu_event, nsp_lu_entity, nsp_lu_entity<event>, and so on) — the same table, the same one-value-per-object economy described for frame-scope and FE-scope namespaces. LUs do not carry a literal suffix string; nothing in the schema stores .event or .entity<event> as text. The dotted notation used throughout this document is a documentation convention, read off whichever namespace value the LU is assigned to, chosen for readability over spelling out nsp_lu_entity<event> on every line:

destruição.event      cansaço.state
beleza.attribute      cadeira.entity

Entities individuated through a relational concept carry a parameter naming that concept (see §"Entities through a relation"), which likewise notates a distinct namespace value (nsp_lu_entity<event>, nsp_lu_entity<relation>, ...), not a stored parameter string. A value on an attribute's own scale carries a parameter of its own too, hosted on .attribute rather than .entity (see §"Values on a scale"):

comprador.entity<event>       pai.entity<relation>
bonito.attribute<value>       cansado.state<value>

The inventory#

The ontological-type vocabulary is deliberately narrower than the frame-scope namespace vocabulary. It does not mirror frame namespace names, even though both are namespace values under the hood.

Entities through a relation: the .entity<…> parameter#

The motivation#

A recurring class of words doesn't name a free-standing thing, and doesn't name a relation either — it names an entity, but only as it participates in some relation. Comprador ("buyer") doesn't make sense apart from the idea of buying; remove the relation, and the word's meaning evaporates along with it. Words like this are still, ontologically, entities — a buyer is a person, and a person is a thing with independent existence — but that entity is individuated by the relation it stands in.

FNBr records this with a parameter on the base .entity type, naming the relation that does the individuating:

The parameter is a genuine refinement, not a new base type — a comprador.entity<event> is still, for every coarse purpose, an .entity. The relation named by the parameter is the lens the entity is being seen through, not a second identity layered on top of the first.

The line that decides whether the parameter applies is constitutivity. Ask: does the relation actually have to be invoked to make sense of the word, or does the word stand on its own? Comprador cannot be understood without invoking "buying" — the parameter applies. Documento ("document") is understood perfectly well without invoking any particular event, even though documents do, like everything else, end up participating in plenty of events (being signed, filed, sent). That looser fact — mere participation — is not enough to trigger the parameter; if it were, nearly every entity noun in the lexicon would end up parameterized, and the whole point of keeping this distinction sharp would be lost.

Because the parameter tracks a sense, not a lemma, one word can carry different parameters — or none — across its different senses, and each distinct sense is recorded as its own lexical unit, exactly as usual. Dependente ("dependent"), for instance, denotes a relatum of a dependency relation in one sense ("meu dependente", a noun) and a resultant condition in another ("ele é dependente", the resultant-condition adjectival reading) — two senses, two lexical units, two different parameters (see §"Sense-split cases" below).

A value on a scale is not an instance of this device, whether the scale belongs to an attribute or to a state. For bonito, quente, inteligente (values on an attribute's own scale) and cansado, quebrado, sentado (values on a state's own scale) no entity is presupposed, so the parameter that names one lives on .attribute or .state, never on .entity. See §"Values on a scale" below.

The three-way diagnostic#

For any candidate lemma, ask what the lemma names:

1. The relational concept itself — the tie, event, quality, or condition, needing its relata to make sense → a bare relational type (.relation, .event, .attribute, or .state): paternidade, beleza, cansaço, destruição.
2. A thing with standalone existence, intelligible without invoking any particular relation → bare .entity: documento, cadeira, água, pessoa.
3. A thing, but only as the filler of a relational slot — remove the relation and the sense evaporates → .entity<…>, the parameter being the relational type that individuates it: comprador, pai.

The bright line between (2) and (3) is constitutivity: the parameter fires only when the relational concept is constitutive of the sense. comprador cannot be understood without "buying"; documento is perfectly understood without any event. The fact that documents participate in events (signing, filing, sending) does not make them .entity<event> — everything participates in events. If the parameter fired merely on participation, it would fire for cadeira, água, pessoa, and the coarseness would be lost.

Sense-split cases#

The parameter does not rescue the annotator from sense disambiguation; where a lemma has distinct senses, it still yields distinct LUs, as required generally.

• operacional: "setor operacional" (pertaining to operations, an intrinsic disposition) → .attribute<value>, a value on the scale of operational-ness, no entity presupposed; "o sistema está operacional" (up and running, a resultant condition) → .state<value>, a value on the scale of operational-readiness, related to a producing event, no entity presupposed either. Two senses, two LUs, two different <value> parameters — one hosted on .attribute, one on .state, distinguished by whether a producing event is on record.
• dependente: as a noun ("meu dependente", a person on one's insurance) → .entity<relation>, a relatum of a dependency relation, converse the one-depended-upon; as an adjective ("ele é dependente") → .state<value> (resultant reading, a value on a dependency-scale with a producing force on record) or .attribute<value> (intrinsic-disposition reading, the same scale with no force ever, no entity presupposed either way).

Values on a scale: the .attribute<value> and .state<value> parameters#

The motivation#

An attribute — and, on the same footing, a state — has two facets, not one: the same split conceptual-spaces theory (Gärdenfors) draws between a dimension and a region within it. Temperatura names the dimension itself: an axis, if the attribute is gradable (as temperature is), or a class, if the attribute is categorial instead — which one is a fact about the attribute's own topological type, decided at the schema layer (ATTRIBUTE's own grounding, VALUE/AXIS/CLASS per Conceptual Dimension §2), not something Layer 1 needs to settle. Quente names a region within that dimension — a value the dimension can take, not the dimension, and not any particular thing that happens to have it. Cansaço and cansado repeat the exact same split, one row down: cansaço is the condition-dimension, cansado is a value on it — the only structural difference from temperatura/quente is that a producing event is on record (Attributes.Value plus a relation to that event, rather than Attributes.Value alone), which is exactly the distinction that already separates bare .attribute from bare .state.

No entity is presupposed by any of these four readings. A temperature scale exists, and a point on it is nameable, whether or not any particular object is currently at that temperature — quente is well-formed even said of nothing in particular ("está quente hoje", of the weather in general, names no entity at all). The same holds for cansado: the condition is nameable independent of who, if anyone, is in it. What links a value to the entity that bears it is the job of the Attributes schema itself — its Entity, Value, and Attribute elements, and the relation rows between them (§11.1 of Conceptual Dimension) — not a fact the LU's own ontological type needs to carry. This is why the parameter lives on .attribute or .state, never on .entity: bonito denotes a value on exactly the same footing as quente, and cansado denotes a value on exactly the same footing as either — none of the three presupposes the thing that happens to have it.

The parameter is a genuine refinement, not a new base type — exactly the same discipline .entity<…> follows: bonito.attribute<value> is still, for every coarse purpose, an .attribute; cansado.state<value> is still, for every coarse purpose, a .state.

The diagnostic: dimension, or a point on it?#

Ask what the lemma names: the scale itself, or a position on the scale? Altura / alto, temperatura / quente, beleza / bonito, cansaço / cansado are each a dimension/value pair, decided the same way every time (this is the same "Value or dimension?" diagnostic already used for the schema-layer profile choice — see conceptual_dimension.md §8). Where the scale itself is named → bare .attribute or bare .state (the existing residual diagnostic, §"Why coarse" below, decides which of those two — whether a producing event is on record). Where a region on it is named → .attribute<value> or .state<value>, by the same test. No entity-hood question enters into either diagnostic at all — that question belongs to whatever the value is predicated of in a given sentence, which is exactly what the Attributes schema's own Entity element records, separately.

The value/dimension question is independent of force-status, and neither forks the type or the namespace. Sentado (force still active) and cansado (force already spent) are both .state<value>, exactly as postura and cansaço are both bare .state — force-status distinguishes a reading, not a type or a namespace: every .state/.state<value> LU lands in @stative, whether the force is holding now or already spent (the former @condition namespace, which used to carry the resultant reading separately, has been retired — see Stative's merge note). .state<value> does not fork into two further types any more than .state itself does; see the admit-set table below for how the routing works.

Design rationale: why .entity, .attribute, and .state are the bases, and why only they are parameterized#

Two choices — one in the .entity<…> scheme, one shared by the .attribute<…> and .state<…> schemes — are not ontological truths but design decisions serving Layer 1's job. They are recorded here so a future maintainer knows they were chosen deliberately, and what would motivate revisiting them. The .attribute/.state side has no live alternative-factoring debate the way .entity does (below) — there's no serious "value-base" competitor to consider, since a value simply is a region of its dimension and there's no second entity anywhere in the picture to make base a choice between two things. What §"Why .entity, .attribute, and .state carry a parameter" below settles for .attribute/.state is only that they need one, not which of two factorings to prefer.

Entity-base vs. relation-base

A role- or quality-bearer encodes one fact: there is a relational concept, and this lemma names one of its argument positions. That fact can be factored two ways.

• Entity-base (adopted): the entity is the base type; the parameter records which relational concept individuates it. "A thing, seen through a relation." comprador.entity<event>.
• Relation-base (the alternative): the relational concept is the base; the parameter records which argument slot is lexicalized. "A relation, projected on a slot." comprador = event<buy>.agent.

These carry identical information — there is a buying relation and this lemma names its agent — factored differently. Relation-base is arguably the more elegant ontology, and is closer both to this project's cognitive-linguistics starting point (all things are entities or relations) and to qualia structure, where a role-bearer is a value bound to a qualia role of the relational concept.

Entity-base is nonetheless adopted, for an operational reason rather than a metaphysical one: the class-compatibility check must be coarse over the stable, namespace-relevant identity. A role noun's namespace behaviour is governed by its being an entity (it lands in @entity frames, takes entity-like FEs), not by its being an agent-of-buying. Entity-base therefore keeps the coarse thing in the base position and the fine thing in the parameter — the same Event/Situation discipline the whole model runs on. Relation-base would reverse this, putting the volatile, construal-heavy part in the base slot and forcing the check to see through the parameter on every call.

The choice is thus tied to Layer 1's purpose. If project priorities shifted — e.g. toward generating frames from the relational concept rather than validating an entity's namespace — relation-base could win. One concrete advantage it would bring: converse pairs fall out as sibling projections of a single base (pai = relation<paternity>.arg1, filho = .arg2) instead of two independently-parameterized entities that happen to share a parameter value. If converse handling becomes important downstream, that is the point at which to reconsider the factoring.

Why .entity, .attribute, and .state carry a parameter, and the other two don't

Every ontological type has presupposed structure: events presuppose their argument roles, attributes presuppose a scale and dimension, states presuppose a source event and a scale of their own, relations presuppose arity and converse structure. It would be natural to expect parameters on all five. Three get one, and the reason is a division of labour between layers, not a claim that entities, attributes, or states are special — and the reasons split into two genuinely different kinds.

For two of the five types, the presupposed structure is already carried one layer down, by Layer 2's per-namespace participant signatures, with nothing left over for Layer 1 to record:

• .event — argument-structure flavour (agent + theme + counterparty vs. bare patient) is exactly what the eventive namespace signatures encode.
• .relation — arity and converse structure belong to @relational's reference frame, not to Layer 1.

The other three need a parameter, but for two different reasons — one reaches across namespaces, the other two stay within one:

.entity's reason: the presupposition points upward, out of .entity's own territory entirely. An entity individuated by an event or a relation is a fact that reaches across namespaces — the role noun lives in @entity and in the namespace of the relation that licenses it — and Layer 2 is organized within one namespace, so it structurally cannot carry a fact that spans two. .entity is where that cross-type presupposition has to land, because nowhere else has a slot for it.

.attribute's and .state's shared reason: the presupposition stays inside one namespace family, but Layer 2 still can't see it. Unlike .event's within-type variation (which does correlate with different namespaces — @agentive vs. @change vs. @phenomenon, and so on), the dimension/value split does not correlate with any namespace difference at all: beleza and bonito both evoke @attribute frames; cansaço and cansado both evoke @stative frames (as do postura and sentado) — the same namespace, either way, within each pair, and now (since @condition's retirement) the same namespace across both force-readings of .state too, not just within one of them. So this is a fact Layer 2's per-namespace signature is structurally the wrong tool for — it doesn't distinguish frames by namespace, it distinguishes two readings within one namespace — and Layer 1's parameter is what's left to carry it, on both types that have this shape. This is also why the fix isn't "the presupposition surfaces in Layer 2, same as event's" (the previous version of this document claimed exactly that for .attribute, routing the value reading through .entity<attr.value>, and made the same move for .state via .entity<state>): Layer 2 genuinely has nothing that distinguishes beleza from bonito, or cansaço from cansado, so the claim was wrong in both cases, not just inelegant.

.state's force-status question (maintained now vs. produced and spent) is a separate fact from this one, and no longer a namespace-routing fact at all. It used to pick between @stative and a separate @condition namespace; since that split's retirement it decides which conceptual schema a frame's meaning is read against (STATIVE vs. Attributes plus a relation to the producing event), not which namespace the frame sits in — every .state/.state<value> LU is @stative either way. That leaves the present argument untouched: within either force-status, the dimension and the value on it (cansaço/cansado, or postura/sentado) still land in the same namespace as each other, and Layer 2 still can't tell them apart. The parameter is needed regardless of which schema a given .state frame happens to ground in.

So the parameter exists, on .entity, .attribute, and .state, to record whatever Layer 2 cannot carry — for .entity, a fact that crosses namespaces; for .attribute and .state, a fact that Layer 2 is blind to within one namespace. That, rather than economy, is the deeper justification in all three cases; the economy argument only explains why not to mint further primitives once the layer-division argument has already established the device is needed at all.

Adverbs and other scalar/relational concepts#

"Adverb" is a part-of-speech wastebasket, not a semantic class — it collects manner, place, time, frequency, degree, epistemic, and connective words with almost nothing ontological in common. The ontological type is expected to cut across it, not align with it: every case below is decided by asking what kind of thing the lemma names, never how the word combines in a clause, and each one resolves to a type the model already has.

Scales and values: scalar adverbs are .attribute<value>#

Degree (muito, pouco), quantity (bastante), frequency (sempre, raramente), and epistemic likelihood (talvez, certamente) all name a value on a scale — the same value/dimension split already drawn for quente vs. temperatura. The scale itself is a bare .attribute (grau, frequência, certeza); a lexicalized value on it is .attribute<value> (muito, raramente, talvez).

talvez shows the line directly: profiling a point on the likelihood scale (Chance, Certeza) is a value, .attribute<value>; profiling the epistemic stance itself (Postura_epistêmica) names the attribute-concept, and is bare .attribute. Distinct senses, distinct LUs, same rule as always.

Manner adverbs are .attribute<value>#

Manner adverbs (belamente, rapidamente) name a value, not a bare dimension — belamente stands to beleza exactly as bonito does, a value on the same scale, predicated of an event rather than an entity. Nothing about what the value is predicated of enters into the ontological type (§"Values on a scale" above: that question belongs to the Attributes schema's own Entity/Value structure, not to Layer 1), so manner adverbs take .attribute<value>, the same type bonito takes — not bare .attribute, which would wrongly claim belamente names the beauty-scale itself rather than a point on it. That the bearer is an event rather than an entity is a namespace-level fact (which frame element the manner modifies), not an ontological-type distinction — exactly the same separation of concerns already established for every other <value> case.

Deictic, connective, and polarity adverbs are .relation#

Three adverb classes name ties, not values:

• Place and deictic-time (aqui, hoje, agora) are spatial/temporal image-schemas — a figure located relative to a ground — joining the other spatial/temporal relations (adjacência, anterioridade) in @relational. (Their image-schematic character is carried by what their frames ground in — FIGURE_GROUND, DEICTIC.) An extent/proximity reading of a time word (recentemente) is scalar instead, and patterns with the value adverbs as .attribute<value>.
• Conjunctive adverbs (contudo, portanto, entretanto) tie together propositions or events — contrast, consequence, inference — .relation with propositional relata, routed to @relational.
• Affirmation and negation (sim, não, and the wider polarity vocabulary — nunca, jamais, sem, nada, nenhum) are polarity ties: a tie between a polarity and a proposition, not a value and not an event. .relation, same propositional-relata pattern as the conjunctive adverbs.

Two cautions, both illustrating that the type is a diagnostic, not a rubber stamp:

1. The polarity relation isn't the act. não as propositional polarity is .relation; the act of using language to affirm or deny (afirmar, negar) is an .event in an @agentive frame — different types, different frames, even though ordinary usage runs them together. A lemma like negação can legitimately split into negação.event (the act) and negação.relation (the polarity) — the same one-lemma/two-identities pattern as cansaço/cansado.
2. Zero is polarity, not a low value — the diagnostic that settles negative quantifiers. nada, nenhum look at first like values on the quantity scale, parallel to pouco, bastante. But a low value still presupposes existence — pouco asserts some quantity, just a small one — while nada/nenhum deny existence outright (¬∃x). That is exactly the line that already separates raramente (.attribute<value>, a low but positive frequency, still asserting the event occurred) from nunca (.relation, zero frequency, a negative existential over time points): a zero reading on any scale negates the scale's own existential presupposition rather than measuring a small amount of it, so it is a polarity tie, not a point on the scale. nada, nenhum pattern with nunca/jamais, not with pouco — .relation, folded into the affirmation/negation bullet above. No new type is needed.

Summary#

The whole class resolves with no new ontological type: scalar and manner adverbs are both values (.attribute<value>) — of attribute-scales either way, differing only in what the value is predicated of, an event rather than an entity, which the type itself does not track — and deictic, connective, and polarity adverbs are relations. The apparent novelty of "adverbs" dissolves once the concepts, rather than the part-of-speech, are classified.

Why coarse, and the frame-namespace vs. LU-type asymmetry#

The asymmetry is the most important property of this layer. The frame's own namespace is the fine-grained view (the Situation/Description); the LU's ontological type — itself a namespace value, just scoped to lu rather than frame — is the coarse identity class (the Event). Hence:

• destruição.event may be evoked by a @agentive frame (destruction as cause), a @change frame (destruction as change of state), and a @stative frame (destruction as resulting condition) — all without contradiction and without splitting the concept. The type stays .event throughout.
• .attribute<value> and .state<value> do exactly the same thing, across @attribute/@state and @entity. Americano names a value on the origem scale — full stop, regardless of what it's predicated of: a person (um americano), a thing (um carro americano), or an event (o ataque americano, "the American attack"). The type never forks to track that; what changes is only which frame — hence which namespace — the LU evokes in a given sense. frm_people_by_origin (@entity, brasileiro, americano, francês…) is one such frame: a class of entities construed through their origem-value, exactly the way an @entity frame construes anything. This is not an exception or a metonymic patch — it is the identical Event/Situation asymmetry destruição already illustrates, and it is not rare: the live data has dozens of @entity frames built exactly this way over .state<value> alone (frm_people_by_religion, frm_people_by_vocation, frm_people_by_health_condition, frm_wealthiness, frm_expertise, frm_addiction, frm_plants, and around twenty-five more). See the admit-set table below for how this is recorded.
• Genuine type ambiguity does split the LU: silent.state (entered a state, ficar em silêncio) vs. silent.attribute (a personality trait, é silencioso) illustrate the principle — two LUs for one lemma, disambiguated by the annotator against a real sentence, though only the .attribute sense is currently lexicalized (the manter/guardar silêncio reading is a coverage gap, not yet a stored LU).

Diagnostics for the relational-concept vs. incumbent boundary#

The participle-derived candidates choice are handled by the three-way diagnostic above, because the adjectival incumbent and the nominalized concept receive different classifications:

• The nominalized relational concept is the bare relational type: cansaço is .state, beleza is .attribute, paternidade is .relation.
• The entity-construed form is .entity<…>, and only pai (.entity<relation>) is still an example of it here. Neither cansado nor bonito is entity-construed any longer — both are values on their respective scales (.state<value>, .attribute<value>), presupposing no entity at all (see §"Values on a scale").

Under the present scheme .state names cansaço (the condition-concept itself), while cansado — the value on that dimension, not an entity in it — is .state<value>.

For the .relation vs. .entity<relation> distinction (the relational-role nouns — pai, sócio, vizinho): the tie is .relation (paternidade); the relatum named as such is .entity<relation> (pai as the person standing in that tie). The arity/converse evidence (pai-de ↔ filho-de, posse ↔ pertence-a) confirms that a relation exists; it is the value of the parameter on the relatum LU, and the identity of the tie LU. A free-standing referent that merely happens to have a relational role available (pai used to pick out an individual who walked in, with no relation in play) is plain .entity.

What this layer validates (and what it cannot)#

The type licenses a class-compatibility check: does the frame's namespace admit this ontological class at all? The check runs on the base type; .entity<…> counts as .entity, .attribute<…> counts as .attribute, and .state<…> counts as .state, for every row below.

Note that @stative is a clean base-collapse, the same simplification @attribute got: .state/.state<value> lands there by the ordinary base-type rule regardless of force-status, with no separate .entity<…> exception needed and no fork across two namespaces the way it briefly did while @condition existed as its own row.

**@entity admitting .attribute<value>/.state<value> is the same construal mechanism that lets .event evoke @agentive or @change or @stative — a namespace is a view the frame takes, and @entity is one ordinary, expected view for a value-typed LU to be construed under, on exactly the same footing as @attribute itself. It is not the exception; it is not rare. frm_people_by_origin (brasileiro, americano, francês…, all .attribute<value>) and roughly thirty further @entity frames built the same way over .state<value> (frm_people_by_religion, frm_people_by_vocation, frm_people_by_health_condition, frm_wealthiness, frm_expertise, and more) are the live, populated, already-annotated evidence for this.

The @relational row now reads .entity<relation> rather than bare .entity for the relational-role nouns: a role noun appears in @relational frames and in @entity frames, and the parameter is what makes that spread legible to the check.

• Catches cross-class category errors: an .attribute LU in an eventive frame, an .entity LU in a stative frame, a .relation LU in an agentive frame. Automatable, high-precision.
• Cannot catch within-class errors: it is silent on @agentive vs. @change vs. @phenomenon, because all admit .event. The empirical case proves this — aquecer.v [Causar_mudança_de_temperatura] and aquecer.v [Mudança_de_temperatura] are both .event; the class check correctly passes both and says nothing about which is right.
• Cannot catch wrong-sense errors: only the annotator choosing between silent.state and silent.attribute, or between the noun and adjective senses of dependente, against a sentence can.
• Does not assign the parameter automatically: whether a lemma is plain .entity or .entity<…>, and which relational type the parameter takes, is the annotator's judgement (the three-way diagnostic), not something the class check derives.