Values, not links: do entity attributes belong in the model

[antejavor]

Part of #344

Question

Half the corpus's question types ask for a value, not a link. Does the model gain attributes — and if so, where do they live in hygm's types and in the graph?

Graduated from the map's Not yet specified — "whether GLiNER2.5's span attributes are needed as a second mechanism alongside relations" — because #350 supplied the evidence it was waiting for. Over one session per question type, with a typed relation vocabulary running both constrained and permissive:

question	expected answer	edges found
personal best in the charity 5K	25:50	none, either arm
items of clothing to pick up or return	3	none, either arm
Admon's Sunday rotation	8am-4pm day shift	none, either arm
degree graduated with	Business Administration	studied(User -> Organization:'Business Administration')
MoMA / exhibit dates	a date difference	attended(User -> Event:'MoMA tour'), no dates
video-editing preference	Premiere Pro advanced settings	prefers(User -> Topic:'advanced settings')

The three misses are not extraction failures. A personal-best time, a count and a shift window are properties of something, and a vocabulary of entity-to-entity edges has nowhere to put them. Even the two hits are weaker than they look: the MoMA question needs the dates of two visits, and valid_at (session-stamped per #347) gives the date the conversation happened, not the date of the event discussed.

#347 kept relations as the primitive and set reified assertions aside, on the reasoning that time-anchored edges carry the knowledge-update class. That holds for updates; it says nothing about values.

Open:

1. Measure the share. The starter relation vocabulary #347 measured the corpus (42% time/change, 98/100 first-person); do the same for value-shaped answers, so this is decided on a distribution rather than on six questions.
2. What GLiNER2 actually offers. What JointSchema actually enforces #345 investigated JointSchema's relations only. Does the installed gliner2==2.0.0 support attributes/fields on an entity type in the joint path, what shape does the output take, and are attribute values type-constrained the way endpoints are? (Upstream markets "span attributes" for 2.5 — confirm against the source and the checkpoint we run, not the blog.)
3. Where they live in the graph. Node properties are cheap and queryable but carry no provenance and no time. A value node carries both and multiplies node count. This is the same tension The starter relation vocabulary #347 resolved for superseded facts (retain, timestamp) and the answer should probably match.
4. hygm.types impact. Does NodeType gain an attribute declaration, and what do the other two strategies do with it? OWL maps cleanly — owl:DatatypeProperty with an rdfs:range of a literal type is exactly this, so OwlImportStrategy gains a natural mapping rather than a workaround. ManualStrategy's YAML gains a key. That symmetry is an argument the model is missing something rather than being asked to grow a special case.
5. Does this displace reified assertions? The map's other fog item is a node per statement carrying subject/predicate/object/time/source. Attributes on entities and reified statements are competing answers to overlapping questions; decide whether one subsumes the other or they sit side by side.

Interacts with #353 (attributes change what derivation must emit) and the plan's §1 types.py.

Evidence: prototype/gliner2-constrained-edges, section A of the prototype README.

[antejavor]

#362 resolved. This ticket's open question 2 is answered, a third option has appeared, and one sweep is now this session's work.

Full note: unstructured2graph/docs/research/gliner2-attributes.md (branch research/gliner2-attributes).

Open question 2 is closed: what the library offers

Nothing on the joint path. No attribute slot on EntitySpec, none on JointSchema, compile_schema hard-codes "json_structures": [], and a structure forced into the compiled schema is silently dropped. Also: JointSchema.from_dict ignores unknown top-level keys without complaint, so a hygm YAML carrying attributes: would load, validate, and do nothing — worth knowing before anyone designs that key.

The mechanism is the legacy API, in three forms: entity_attributes (closed label sets, {"label","confidence"}, no offsets), structure().field() (real value spans with offsets, but document-scoped and attached to nothing), and classification (doc-level). All three compose with entities and relations in one extract() call — but that is the legacy runtime #345 retired, where relations lose their typing. The trade: values in one pass, or typed relations, not both. Keeping JointSchema means a second inference call per window (+90% wall clock) with no entity ids, which brings back the span-matching apparatus #345 established we could delete.

Nothing is enforced during decoding (no search, so no feasible analogue — #350's infeasibility question has no counterpart). validators= is a provable post-hoc filter. Two failure modes to design around: a single-label group can never abstain (softmax argmax — three unrelated entities all came back Mars), and choices= hallucinates, returning a value absent from the text at conf 0.99.

A third option, which changes what this ticket is choosing between

Value-shaped entity types — Duration, Quantity, TimeWindow, Money, Date — with relations into them express every value fact on the joint path: one pass, entity ids and #345's constraint enforcement intact, feasible=True.

REL owns_count     Person:'user'  -> Quantity:'3 pairs'        conf=0.985
REL paid           Person:'user'  -> Money:'$129.99'           conf=0.964
REL personal_best  Person:'user'  -> Duration:'26:34'          conf=0.971

So #350's "no expressible answer" was a property of its vocabulary, not of the library, and the honest framing of this ticket's question 1 is now: does the model need attributes, or does the vocabulary need value-shaped types? The second costs no change to hygm.types at all and moves the whole problem into #353/#359/#360.

Measured caveats, not to be skipped: 2 of 4 values bound wrong — personal_best took 26:34, the previous PB, and 25:50 was never extracted as a Duration; works_shift took 'Sunday shift' while '8am-4pm' sat two tokens away at conf 0.998. The structure path got 5/5 on the same text. Sample of one, and the note says plainly it is not a quality result. And in the same legacy pass, the relation mechanism answered personal_best = 26:34 while the structure mechanism answered 25:50 — same model, same text, two mechanisms, two answers. Whatever this ticket picks, that disagreement is the thing it is picking between.

Folded in: sweep occurrence_policy before deciding

Record mode (structure(mode="natural", anchor=...)) is the only per-entity value construct, and its anchors match joint entity ids exactly by (start, end) — so it is the one path that could give per-entity values and keep typed relations. But in #362's probe it bound a value 460 chars away to the wrong anchor (gave a runner's personal best to Admon the physio, twice, leaving shift null), and occurrence_policy — "all" | "first" | "error_on_ambiguous" | "latent_all" — was never swept. error_on_ambiguous may surface ambiguity rather than guess, which would change the verdict on record mode entirely.

That sweep is this ticket's work. Deciding record mode's fitness without it is deciding on a default nobody chose.

Also relevant here

• Calibration: structure-field confidences cluster 0.99+, attribute confidences spread 0.44-0.99. Different heads, not calibrated against each other — one threshold across both would be unsound.
• Cost is linear, not quadratic (attribute labels become extra entity queries, 5 -> 8), unlike the endpoint expansion Wire a constrained ontology and read the edges #350 measured. This is not a performance decision.
• No version bump exists or is needed — 2.0.0 is latest on PyPI, "2.5" is the checkpoint generation we already run, and the transformers floor is untouched.

[antejavor]

Resolution

The ticket asked whether values belong in the model. They do, but not as attributes. Values are entity types, and #362 had already shown that the library can carry them that way. What this ticket had to establish was how much of the corpus that serves, what the graph must do differently, and whether it actually works on real sessions.

Evidence: sections E–F of the prototype README on prototype/gliner2-constrained-edges (49c0ba5). value_share.py classifies the answers; value_types.py runs the extraction.

1. The share, measured over all 100 committed goldens

Classified by hand, with every answer printed next to its class in value_share.log. Regex can't do this, since four, 3.5 weeks and 8 am - 4 pm (Day Shift) all defeat it.

what the answer takes	n	% of 92 answerable
stated literal — a value the text contains (25:50, $800, Friday)	18	20%
date arithmetic — a difference between two dates	18	20%
sum of stated values ($185 total)	8	9%
count of edges (how many museums… → 4)	12	13%
named entity — already a node today	21	23%
narrative prose	15	16%

61% want a value, which is more than #347's own headline figures (42% time/change). But "values, not links" is too coarse a framing:

• Only 48% need a value slot. The 12 count-of-edges answers never appear in the text as a number. They are the size of a set of edges, so they need relations plus Entity identity across chunks #346's identity being right, and nothing new.
• Of the 18 date questions, 8 are "how long ago…", which valid_at (the session date, The starter relation vocabulary #347) already serves. 10 are "between X and Y", which need the date of the discussed event, and valid_at isn't that. At 11% of answerable questions, this is the largest single bucket nothing in the model serves yet.
• The preference type is 6/6 prose. No value and no node serves it: it's an LLM-judged summary, so it belongs to map Map: Context-graph emergence pipeline — reconciliation, retrieval, eval #297.
• The two largest types are about 73% value: multi-session through sums and counts, temporal-reasoning through date arithmetic.

Decisions

1. Values are carried by value-shaped entity types: Duration, Quantity, Money, Date, TimeWindow, with relations into them, all on the joint path. Entity ids, What JointSchema actually enforces #345's decode-time constraint enforcement, feasible, and Extraction-time constraints vs post-hoc validation #348's two compilations all keep working unchanged. Rejected alternatives:

   • The legacy structure().field() path. It's the only real value span, but it's the runtime What JointSchema actually enforces #345 retired, so it costs typed relations outright, or a +90% second call per window with no entity ids.
   • A hybrid with record mode. Same +90%, and it rests on What gliner2 2.0.0 actually offers for entity attributes #362's unswept occurrence_policy, which already bound a value 460 characters away to the wrong anchor.
   • Reified assertions. See decision 5.

   Choosing this path retires What gliner2 2.0.0 actually offers for entity attributes #362's occurrence_policy unknown rather than resolving it: the question only exists on the record-mode path.

2. Value types get span-scoped identity. _entity_id is (chunk_hash, type, text) and a session is one chunk, so under today's rule every 3 in a session would be a single node, and "3 pairs of socks" and "3 movie festivals" would share it. If both carried the same relation type, the MERGE would silently drop one of the two facts. A value has no identity of its own: it's only meaningful attached to something, and two 3s are not the same thing the way two Frida Kahlos are. Measured: 35% of distinct value keys cover more than one span. Date:'sunday' appears ×8 in one shift table, each a different agent's day. Rejected: folding the value onto the edge. The extracted relation is personal_best(User -> Duration), so the value already is the tail and there is no third node to hang it off.

3. Date is just a value type, and resolution gets its own ticket: Resolving relative dates against valid_at #364. In the evidence sessions, dates are 17 relative to 6 absolute (last summer, today, last Thursday, a few weeks; all 6 absolute mentions are May 6). So a Date node mostly holds an expression that can't be used for arithmetic until it's resolved against valid_at. Resolution is a separate problem: it's deterministic for some forms, impossible for a few weeks/recently, and it decides what a partially-resolved date means at read time.

4. hygm.types gains nothing new (item 4). Entity identity across chunks #346's mergeable: bool on NodeType widens to identity: global | chunk | span, which is the same concept with a third value. Because decision 1 makes values into types, NodeType needs no attribute construct and RelationType is untouched. The derivation contract for LlmRecommendationStrategy #353 emits the enum instead of the boolean. OWL has no counterpart for the scope, since it's an operational hint rather than ontology, so OwlImportStrategy just defaults it. Rejected: keeping the boolean and adding an is_value flag (two fields encoding one concept, where mergeable=true, is_value=true is meaningless but representable), and moving the scope out of hygm (contradicts Entity identity across chunks #346's placement and splits The derivation contract for LlmRecommendationStrategy #353's output into two artifacts).

5. Reified assertions are subsumed, so the map's fog item closes (item 5). Before this ticket, a value had nowhere to live, which made a statement node its obvious home: that was reification's strongest remaining case. Now a value fact is an ordinary edge. It inherits valid_at (The starter relation vocabulary #347) and MENTIONED_IN (Entity identity across chunks #346), so subject, predicate, object, time and source all exist already, distributed across the edge rather than reified into a node. Knowledge-update questions (initial vs current value) are already served by retaining both edges with their timestamps. Nothing in the 100 questions needs a statement about a statement. Reopen only if one is measured.

Validation: does it actually work on real sessions

value_types.py adds the five types plus eight relations into them (personal_best, lasted, spent_time, paid, costs, owns_count, happened_on, works_shift) to #350's vocabulary, and runs it over the same 10 sessions with #350's vocabulary as the baseline. The baseline must reproduce #350's 1004 raw edges with zero value relations leaking into it (asserted). That guard is what caught #365, below. Full output: value_types.log.

question	result
personal best 25:50	✅ personal_best(User:'user' -> Duration:'25:50'). The baseline has no way to express it. #362's wrong 26:34 binding didn't recur.
clothing count 3	❌ in both arms, as predicted: it's a count of edges, not a stated value
Admon 8 am - 4 pm	⚠️ extracted but never bound. All four shift windows came out as TimeWindow (8 am - 4 pm ×5), but none was attached to Admon, who was typed User. The source is a table, and the only works_shift edges were Agent -> 'Friday'.
MoMA visit dates	❌ no event date extracted for either visit

Two costs, recorded as caveats. Decision 1 stands because every alternative shares these failures, and the legacy path also costs typed relations:

• Adding types taxes the existing relations. On the original eleven: raw edges 1004 → 954, and distinct claims 299 → 276 (98 lost, 75 gained). owns −75, practices −89, studied +83. The lost claims include real ones (purchased('i' -> "chef's knife"), practices('user' -> 'meal prep')). Declaring more types reshuffles the beam for every type.
• Precision is poor with a hand-written vocabulary: by my read, roughly half of the 167 value edges are junk. None of the 3 Money mentions was an amount ('premium features', 'subscription fees', 'TLC'). Day names got typed as Event (happened_on(Event:'Friday' -> Date:'Sunday')). Quantity picked up 'them' and 'a lot', and Date picked up '18'.

Consequences

• The derivation contract for LlmRecommendationStrategy #353 must emit identity instead of mergeable. It inherits both measured costs: vocabulary size is not free (−8% distinct claims on the existing relations), and value-type descriptions drive the junk typing.
• How wide should a relation's declared range be #359 / Near-synonymous relation labels all fire on the same pair #360: lasted, spent_time and personal_best all point into Duration, which is Near-synonymous relation labels all fire on the same pair #360's label-overlap problem arriving on a new axis.
• Chunking and the durability of constraints #352: binding a value across a layout (the Admon table) is a structure problem, not a vocabulary one.
• Entity identity across chunks #346: the 13% of count-of-edges questions rest entirely on its identity being right.
• Resolving relative dates against valid_at #364 filed: resolving relative dates against valid_at.
• Map Map: Context-graph emergence pipeline — reconciliation, retrieval, eval #297: the preference type (6/6 prose) is served by none of this.

Found along the way: #365 and a correction to #350

gliner2 2.0.0 caches compiled schemas under repr(schema), which is a memory address, so a process that compiles more than one JointSchema can silently be served a stale compilation. Filed as #365, which is a hard constraint on GLiNER2Backend and on #348's retry path. Because #350's prototype built its schemas fresh per session, 3 of its 10 permissive runs were contaminated. Corrected on #350: constrained-only claims 85 → 119, which strengthens #348's claim rather than weakening it. #358's numbers are unaffected.

[antejavor]

Amendment from #352. Decision 5 said reified assertions are subsumed: "nothing in the 100 needs a statement about a statement." That still holds. But #352 measured the first case the binary model can't express: an n-ary fact. Admon's rotation is (Admon, Sunday, 8 am – 4 pm), spread across a table's column header, row label and cell. Even when extraction binds it (a verb template produces works_shift(Admon -> TimeWindow)), a binary edge has nowhere to put the day. That's the case an event node or a reified statement exists for. So decision 5 stands for statements about statements, and n-ary facts are now raised under the map's "Not yet specified" (#344), with evidence in tables.py / tables.log.

[antejavor]

Correction from #364. "Of 18 date questions 10 are 'between X and Y' and need the discussed event's date, which valid_at is not — the largest unserved bucket (11%)" is wrong. I classified by question shape without checking the data. LongMemEval phrases each evidence event as "today"/"just" in its session, so the gold answer equals the difference of the two sessions' dates in 8/8 two-session cases, and 17 of all 18 date questions are served by valid_at alone. The one miss (#82) is a "yesterday", off by one day. The 61%/48% value shares and every other decision here stand. Date stays a span-scoped value type, unresolved in v1.