Integer literals from VALUES/expressions compare as xsd:long while stored integers are xsd:integer — same number is two distinct terms

[bplatz]

Summary

A plain integer literal in a query (VALUES ?n { 5 }) lowers to a binding with datatype xsd:long, while the same integer stored in a ledger materializes from the index as xsd:integer. Since term equality includes the datatype, the same number arriving from the two sources is treated as two distinct RDF terms.

Repro

On any ledger containing ex:a ex:n 5:

PREFIX ex: <http://example.org/ns/>
SELECT DISTINCT ?n { { ex:a ex:n ?n } UNION { VALUES ?n { 5 } } }

returns two rows:

[{"n": {"type":"literal","value":"5","datatype":".../XMLSchema#integer"}},
 {"n": {"type":"literal","value":"5","datatype":".../XMLSchema#long"}}]

Per SPARQL, the bare literal 5 is "5"^^xsd:integer, so this should dedup to one row. The same mismatch makes joins/MINUS/GROUP BY on integer values miss across the two sources.

Notes

• Independent of binding representation (encoded vs decoded) — it reproduces decoded-vs-decoded, e.g. against novelty-only data. Discovered while building fluree-db-api/tests/it_mixed_representation.rs (see the NOTE comment there excluding the integer case).
• Value-space comparison paths (FILTER =, numeric operators) are unaffected; this is about term identity surfaces: DISTINCT, GROUP BY keys, COUNT(DISTINCT), join unification, MINUS.
• Needs a canonicalization decision rather than a point fix: either lower bare integer literals to xsd:integer end-to-end, or canonicalize the int64 datatype family at the term-identity surfaces.

[aaj3f]

See also #1343 (that issue closed as a duplicate of this one)

[aaj3f]

Status on current main: the triple-pattern constant path now tags bare integers xsd:integer (fluree-db-sparql/src/lower/term.rs, added in ce5d0a8db), but the VALUES path still lowers bare Integer to xsd:long, and the query side keeps the datatype id in term/group keys (object_binding.rs, group_aggregate.rs), so the DISTINCT-returns-two-rows repro still reproduces. datatypes_equivalent / is_integer_family exist in fluree-db-query/src/context.rs but currently have no callers — no canonicalization is wired in yet. Keeping this open as the tracker (supersedes #1343).

[aaj3f]

Verified mechanism from the W3C burn-down audit (PR #1437, docs/audit/burn-down/expression-semantics.md + ROADMAP §1.1-7): ordinary pattern objects carry no datatype constraint at all (lower/term.rs:164-166, deliberate), and dt_compatible is asymmetric and not consulted on that path — so the join itself survives today, and the impact is the output datatype tag and term identity (DISTINCT/GROUP BY/sameTerm). The correct fix is at lowering (bare integers in VALUES/expressions → xsd:integer, roadmap PR-X1), not extending dt_compatible. Scan-path datatype constraints are a separate, perf-sensitive item (D5b) tracked with its own bench gate.