Description
Artefact.combine!/2 raises Artefact.Error.Invalid with duplicate relationship ids
when two artefacts are combined and their relationships do not overlap by content.
Relationship ids are assigned sequentially ("r0", "r1", …) in build_graph/2
per Artefact.new!/1 call. deduplicate_rels/2 merges by content key
{from_id, type, to_id} — correctly deduplicating shared edges — but does not
reassign the id field of surviving relationships. When two artefacts each carry
relationships with the same ids but different content, both survive deduplication,
and the combined graph contains multiple relationships with the same id. The
validator catches this and raises.
Reproduced by progressive combination across the diffo-dev/ieee1164 knowledge
compiler pipeline, where each section artefact introduces new relationships with no
content overlap against prior sections:
# Each section produces r0, r1, r2 … independently.
# Combining standard + signals + values + … eventually clashes.
Diffo.Ieee1164.stream_integrated() |> Enum.to_list()
# ** (Artefact.Error.Invalid) invalid artefact: duplicate relationship ids: ["r1", "r2", "r0", "r4", "r3"]
What we need
combine! to produce a valid artefact when the two inputs have disjoint
relationships. Relationship ids in the result must be unique. How the team
achieves that is theirs to decide.
Why it matters
Any pipeline that progressively combines artefacts — where each step introduces
new relationships — will hit this error. It blocks combine! from being used
as a fold operation across a stream of artefacts, which is the natural shape
of a knowledge compiler pipeline.
A possible direction
Re-indexing relationship ids after deduplicate_rels/2 would resolve the clash.
This is offered as an observation about where the gap sits, not as a prescription
— the team may see a better approach, or a reason why ids should be preserved
across combination.
Workaround in use
Local patch to deps/artefact in diffo-dev/ieee1164. Not committed; lost on
mix deps.get.
Description
Artefact.combine!/2 raises Artefact.Error.Invalid with duplicate relationship ids
when two artefacts are combined and their relationships do not overlap by content.
Relationship ids are assigned sequentially ("r0", "r1", …) in build_graph/2
per Artefact.new!/1 call. deduplicate_rels/2 merges by content key
{from_id, type, to_id} — correctly deduplicating shared edges — but does not
reassign the id field of surviving relationships. When two artefacts each carry
relationships with the same ids but different content, both survive deduplication,
and the combined graph contains multiple relationships with the same id. The
validator catches this and raises.
Reproduced by progressive combination across the diffo-dev/ieee1164 knowledge
compiler pipeline, where each section artefact introduces new relationships with no
content overlap against prior sections:
What we need
combine! to produce a valid artefact when the two inputs have disjoint
relationships. Relationship ids in the result must be unique. How the team
achieves that is theirs to decide.
Why it matters
Any pipeline that progressively combines artefacts — where each step introduces
new relationships — will hit this error. It blocks combine! from being used
as a fold operation across a stream of artefacts, which is the natural shape
of a knowledge compiler pipeline.
A possible direction
Re-indexing relationship ids after deduplicate_rels/2 would resolve the clash.
This is offered as an observation about where the gap sits, not as a prescription
— the team may see a better approach, or a reason why ids should be preserved
across combination.
Workaround in use
Local patch to deps/artefact in diffo-dev/ieee1164. Not committed; lost on
mix deps.get.