canonical_senf_pln

[danielbirhanu]

This PR introduces Identity-Aware Semantic Parsing to improve semantic alignment and eliminate brittle symbol mismatches.

Changes

• Added prototype-aware SENF to distinguish different meanings of the same word (e.g., chess_game vs. football_game).
• Implemented an Identity Graph and TransWeave alignment to score semantic identity using positive and negative evidence.
• Integrated identity-aware similarity into PLN via SimilarityLink atoms for more robust, confidence-based reasoning.

Testing

• All existing tests pass (23/23).
• Added tests for TransWeave alignment and similarity penalties.
• Minor cleanup of temporary files and formatting.

[BekLG]

@danielbirhanu, I reviewed this in depth and also ran the 25-case stress benchmark locally. Here are the main implementation issues I found in the SENF path:

1. The SENF layer is too permissive about what it enriches.

• parsers/canonical_senf_pln_parser.py sends all base-parser statements into SENF processing.
• core/senf.py then extracts entities from very broad atom shapes, including atoms that are not clearly relevant.
• This appears to let noisy base output propagate into identity edges, TransWeave alignments, and bridge atoms instead of being filtered out first.

2. Predicate-family bridging is still incomplete.

• core/pln_bridge.py currently emits SimilarityLink / ContextLink, but that does not solve cases where the generated statements and the final query use different predicate heads.
• In practice, there are cases where SENF has semantically relevant atoms available, but the final query still asks for an unsupported predicate family.

3. Query execution can drift away from the strongest supported symbolic form.

• canonical_senf_pln delegates query parsing to the canonical parser and enriches afterward.
• Because query replanning happens against the available statements/context, the executed query can end up stricter or differently abstracted than the atoms SENF actually produced, which leaves the query looking aligned but still unprovable.

4. TransWeave is currently too broad to act as a reliable semantic filter.

• core/transweave.py builds weaves from a wide cross-product of extracted entities and uses a very lightweight matching rule.
• Combined with permissive entity extraction, this makes the alignment step vulnerable to noisy or accidental matches.

5. The identity/exemplar scoring is still too shallow for the amount of graph expansion it introduces.

• core/exemplar_registry.py and core/identity_graph.py rely on a very small hardcoded exemplar set plus lightweight kind/exemplar checks.
• That may be fine for a prototype, but in the current form it does not seem strong enough to justify broad identity expansion over all extracted entities.

Suggested direction:

• narrow the atoms/entities that are allowed into SENF enrichment
• add explicit predicate bridging, not only entity similarity bridging
• constrain TransWeave to query-relevant or kind-compatible structures
• keep the final executed query close to predicates that were actually generated and supported

Overall, this looks promising as an experimental direction, but these SENF-side issues should be tightened before it can be relied on as a stronger reasoning path.