Ontological Types for LUs

Definition

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 type is written as a suffix on the LU:

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"):

comprador.entity«event»     pai.entity«relation»
bonito.entity«attribute»    cansado.entity«state»

The inventory (intentionally small and coarse)

The ontological-type vocabulary is deliberately narrower than the namespace vocabulary. It does not mirror namespace names.

Entities through a relation: the .entity«…» parameter

The motivation

A recurring class of lemmas does not name a relational concept, nor a free-standing thing, but an entity construed through its participation in a relational concept. Every instance a relational type (.event, .relation, .attribute, .state) has an argument slot, and the lemma names the entity filling that slot rather than the relational concept itself.

Ontologically, a role- or quality-bearer is still an entity — an entity individuated by a relation it stands in. It is not a new top-level identity. So the model uses one second-order type that names the construal and points at what it is the incumbent of:

This mirrors the Event/Situation logic of the namespace layer. There, one Event identity is viewed under many Situations without splitting the concept. Here the dual move applies: one entity identity, profiled through a relational concept. The relation is the lens, not a new identity. The base type remains .entity, so coarseness is preserved: comprador.entity«event» is still an .entity for every purpose of the check.

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, bonito, cansado.

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) → .entity«attribute»; "o sistema está operacional" (up and running, a resultant condition) → .entity«state». Two senses, two LUs.
• 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") → .entity«state» or .entity«attribute» per resultant-condition vs. intrinsic-disposition reading.

Design rationale: why .entity is the base, and why only .entity is parameterized

Two choices in the .entity«…» scheme 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.

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 only .entity carries a parameter

Every ontological type has presupposed structure: events presuppose their argument roles, attributes presuppose a scale and dimension, states presuppose a source event and a holder, relations presuppose arity and converse structure. It would be natural to expect parameters on all five. They are not added, and the reason is a division of labour between layers, not a claim that entities are special.

For four of the five types, the presupposed structure is already carried one layer down, by Layer 2's per-namespace participant signatures:

• .event — argument-structure flavour (agent + theme + counterparty vs. bare patient) is exactly what the eventive namespace signatures encode.
• .attribute — the value/scale structure surfaces either in Layer 2 or, for the value-bearer reading, as .entity«attribute» (quente as a value of temperatura); no separate device is needed.
• .state — the source event (via the residual diagnostic) and the holder (via .entity«state») are both already captured.
• .relation — arity and converse structure belong to @relational's reference frame, not to Layer 1.

.entity was the unique case where the presupposition points upward into another type's territory — an entity individuated by an event, a relation, an attribute, or a state — and where Layer 1 had no other slot to record it. Layer 2 cannot fill this gap, because Layer 2 is organized within a namespace, whereas "individuated through a relational concept" is a fact that reaches across namespaces (the role noun lives in @entity and in the namespace of the relation that licenses it).

So the parameter exists to record exactly the cross-type presupposition that Layer 2 cannot carry. That, rather than economy ("one parameter beats four primitives"), is the deeper justification: the economy argument explains why not to mint four primitives; the layer-division argument explains why the device is needed at all, and why it is needed for .entity alone.

Adverbs and other scalar/relational concepts

"Adverb" is a part-of-speech wastebasket, not a semantic class: the traditional category collects manner, place, time, frequency, degree, focus, epistemic, and connective words that have almost nothing ontological in common. Layer 1 is expected to cut across it rather than align with it. This is the healthy outcome — if the five types carved adverbs cleanly, the types would be tracking syntax, not meaning.

The guiding principle is the same as everywhere in this layer: classify by what the concept means, never by how the word combines in a clause. A word that evokes a frame is meaningful and therefore has a thing-identity to classify; "function word" is a claim about syntactic behaviour and has no bearing on the ontological type. Every case below is decided by asking what kind of thing the lemma names, and the answer, in almost every case, is a type the model already has.

Scales and values: the scalar adverbs are .entity«attribute»

Several adverb classes name a value on a scale. Degree (muito, pouco), quantity (muito, bastante), frequency (sempre, raramente, às vezes), and epistemic likelihood/certainty (talvez, possivelmente, certamente) are all scalar: one can be more or less intense, frequent, or certain.

A scale is an attribute — a dimension along which values range — exactly as temperatura is the attribute along which quente and frio are values. The scalar adverbs are therefore the direct extension of the quente analysis from concrete attributes to the more abstract scales of degree, quantity, frequency, and certainty:

• the scale/dimension itself is a bare .attribute — grau, intensidade, quantidade, frequência, certeza;
• the value on that scale, lexicalized, is an incumbent of the attribute: .entity«attribute» — muito, raramente, talvez.

This is the same value-vs-dimension split already drawn for quente (value, .entity«attribute») vs. temperatura (dimension, .attribute) in the Design rationale. No new machinery is required; the scalar adverbs simply populate the value side for scales that happen to be lexicalized adverbially.

The two readings of talvez illustrate the value-vs-dimension line directly. When the sense profiles a point on the likelihood scale (Chance, Certeza), it is a value — .entity«attribute». When the sense profiles the epistemic stance as such (Postura_epistêmica — a speaker's attitude toward a proposition), it names the attribute-concept itself and is bare .attribute. As always, distinct senses are distinct LUs; the type follows the sense, not the lemma.

Manner adverbs are .attribute

Manner adverbs (belamente, rapidamente, particularmente [Maneira]) are the adverbial realization of an attribute predicated of an event rather than an entity. belamente stands to beleza as bonito does — the same quality, borne by an eventuality instead of a thing. They receive the bare .attribute type, the same as the noun beleza: the fact that the bearer is an event rather than an entity is a Layer 2 concern (which frame element the manner modifies), not an ontological-type distinction. Manner adverbs therefore need no new machinery: they are .attribute concepts realized adverbially.

Deictic and connective adverbs are .relation

Two adverb classes name ties, not values, and are therefore .relation.

• Place and deictic-time adverbs — aqui, ali, lá (place); hoje, agora, ontem (deictic time) — are spatial and temporal image-schemas: a figure located relative to a ground, deictically anchored. They join the spatial/temporal relations the inventory already lists (adjacência, anterioridade) and live in @image_schema. Type: .relation.
• Conjunctive adverbs — contudo, portanto, entretanto — name a tie between propositions or events (contrast, consequence, inference), not between entities. The .relation type explicitly admits ties whose relata are events or propositions, so these are .relation with propositional relata, routed to @relational.

Note the split within "time" adverbs: the deictic reading (hoje, agora — temporal location) is a .relation, while an extent/proximity reading (recentemente — a value on a temporal-distance scale) is scalar and patterns with the value adverbs as .entity«attribute». Distinct senses, distinct LUs.

Affirmation and negation are .relation

sim and não — and the wider polarity vocabulary (nunca, jamais, tampouco, sequer; sem) — are polarity ties, not values and not events. Affirmation asserts, and negation denies, that a proposition holds; each is a tie between a polarity and a proposition (or, with an addressee in play, between a speaker's assertion and a factual situation). This fits the .relation definition directly, with propositional relata, parallel to the conjunctive adverbs above.

Type: .relation.

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

1. Polarity relation vs. the act of affirming/denying. The relation of negation/affirmation (não as propositional polarity) is .relation. The act of affirming or denying — a speaker using language to affirm a message to an addressee (afirmar, negar, confirmar) — is an .event in an @agentive frame. These are different ontological types and therefore different frames, even though ordinary usage runs them together. A lemma like negação may legitimately yield two LUs: negação.event (the act of negating) and negação.relation (the semantic negation relation) — the same one-lemma / two-identities pattern as cansaço/cansado. This is exactly the kind of type-heterogeneity that a mixed frame surfaces: the type is what tells you whether to split the frame, move a stray LU, or recognize a legitimate cross-frame polysemy.

2. Negative quantifiers are unsettled. nada, nenhum are negative quantity words — values on a quantity scale carrying negative polarity. Whether they are best treated as .entity«attribute» (a value on the quantity scale) combined with negative polarity, or as something the model does not yet name, is left open here, the adverbial analogue of the multi-relation cardinality question (genro) flagged for the parameter. Defer rather than force.

Summary

The whole class resolves with no new ontological type: scalar adverbs are values (.entity«attribute») of attribute-scales (.attribute), manner adverbs are attributes, 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 suffix-vs-namespace asymmetry

The asymmetry is the most important property of this layer. The namespace is the fine-grained view (the Situation/Description); the ontological type is the coarse identity class (the Event). Hence:

• destruição.event may be evoked by a @agentive frame (destruction as cause), a @transition frame (destruction as change of state), and a @stative frame (destruction as resulting condition) — all without contradiction and without splitting the concept. The suffix stays .event throughout.
• Genuine type ambiguity does split the LU: silent.state (entered a state, ficar em silêncio) vs. silent.attribute (a personality trait, é silencioso) are two LUs for one lemma, disambiguated by the annotator against a real sentence.

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«…»: cansado is .entity«state», bonito is .entity«attribute», pai is .entity«relation».

Under the present scheme .state names cansaço (the condition-concept itself), while cansado — the entity in that condition — is .entity«state».

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 for every row below.

Spatial/temporal relations in @image_schema also take .relation, but @image_schema's full admit-set is out of scope here — its reference structure is deferred. (@relational, by contrast, is now described via the existing Relation frame; see Non-eventive Namespaces.) This row pair extends Layer 1 coverage to relational concepts.

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. @eventive, 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.

Within-class evaluation is the job of Layer 2.