Context. stargraph's graph store is homogeneous (one Entity node + one Rel edge carrying a predicate string), so it physically cannot represent MemGraphRAG's three views (Semantic Ontology / Fact / Source-Evidence) or the Three-Layer Global Memory. Every downstream mechanism (schema filtering on Type nodes, hub suppression, IDF passage weighting, PPR over a heterogeneous vertex set) presupposes type and passage nodes. This schema is the foundational unlock.
Proposal. Add a heterogeneous tri-view schema via a RyuGraph migration.
- Type node table (id, schema_label,
frequency INT for the τ gate).
- Passage node table (id, text,
idf_weight DOUBLE).
INSTANCE_OF (Entity→Type) + EVIDENCE (Entity/Fact→Passage) rel tables. Keep Entity/Rel for the fact view.
- Bump
_SCHEMA_V to 2; add typed write helpers; extend the bulk_copy COPY-FROM ingest path.
Where.
src/stargraph/stores/ryugraph.py:65-70 (_DDL_ENTITY/_DDL_REL; add tables), _SCHEMA_V :62, bulk_copy :208-220.
src/stargraph/stores/graph.py:41-51 (NodeRef.kind already discriminates labels; docstring anticipates future kinds via migrations).
MigrationPlan in src/stargraph/stores/_common.py:43-59.
- NOTE:
add_triple accepts a props arg but currently IGNORES it (ryugraph.py:175-189) — wiring props is a prerequisite for type/passage edge attrs.
Acceptance criteria.
BLOCKER (blocked). migrate() is a stub in every store — _validate_migration_plan (_common.py:62-85) only ALLOWS nullable add_column and hard-rejects everything else; RyuGraphStore.migrate (ryugraph.py:157-165) never applies even add_column. Real add-table migration support must land first. Relates to #21, #41.
Source: arXiv:2606.00610v1 — "MemGraphRAG: Memory-based Multi-Agent System for Graph Retrieval-Augmented Generation". Distilled from arXiv-research/2606.00610v1/analysis.md; file refs verified against current main by the analysis pass.
Context. stargraph's graph store is homogeneous (one Entity node + one Rel edge carrying a predicate string), so it physically cannot represent MemGraphRAG's three views (Semantic Ontology / Fact / Source-Evidence) or the Three-Layer Global Memory. Every downstream mechanism (schema filtering on Type nodes, hub suppression, IDF passage weighting, PPR over a heterogeneous vertex set) presupposes type and passage nodes. This schema is the foundational unlock.
Proposal. Add a heterogeneous tri-view schema via a RyuGraph migration.
frequency INTfor the τ gate).idf_weight DOUBLE).INSTANCE_OF(Entity→Type) +EVIDENCE(Entity/Fact→Passage) rel tables. Keep Entity/Rel for the fact view._SCHEMA_Vto 2; add typed write helpers; extend thebulk_copyCOPY-FROM ingest path.Where.
src/stargraph/stores/ryugraph.py:65-70(_DDL_ENTITY/_DDL_REL; add tables),_SCHEMA_V:62,bulk_copy:208-220.src/stargraph/stores/graph.py:41-51(NodeRef.kindalready discriminates labels; docstring anticipates future kinds via migrations).MigrationPlaninsrc/stargraph/stores/_common.py:43-59.add_tripleaccepts apropsarg but currently IGNORES it (ryugraph.py:175-189) — wiring props is a prerequisite for type/passage edge attrs.Acceptance criteria.
_SCHEMA_V=2.propswired throughadd_triple.BLOCKER (
blocked).migrate()is a stub in every store —_validate_migration_plan(_common.py:62-85) only ALLOWS nullableadd_columnand hard-rejects everything else;RyuGraphStore.migrate(ryugraph.py:157-165) never applies even add_column. Real add-table migration support must land first. Relates to #21, #41.Source: arXiv:2606.00610v1 — "MemGraphRAG: Memory-based Multi-Agent System for Graph Retrieval-Augmented Generation". Distilled from
arXiv-research/2606.00610v1/analysis.md; file refs verified against currentmainby the analysis pass.