Skip to content

Latest commit

 

History

History
93 lines (78 loc) · 5.74 KB

File metadata and controls

93 lines (78 loc) · 5.74 KB

Paper-to-code mapping

How the proof of concept implements "Event Knowledge Graph for a Knowledge-Based Design Process Model for Additive Manufacturing" (Chen, Haruna, Chen, Li, Noman, Li, Eliker; Machines 2025, 13, 112), and where it deliberately simplifies.

Sections, algorithms and figures -> code

Paper element Implementation
Sec. 3.1 Design process model (5 steps + solution, Fig. 3) events + construction in data/intake_system.yaml; served by /process/steps
Sec. 3.2 Event-based knowledge representation; functional triples r: h -> t (Fig. 4) app/domain/models.py (Event, Entity, Triple); triples generated in app/graph/ekg_builder.py
Sec. 3.3 Relationship-aware knowledge representation (Fig. 5) + Algorithm 1 app/graph/reasoning.py (compute_stability, run_reasoning)
Sec. 3.4 Construction of the EKG (Fig. 6) + Algorithm 2 app/graph/ekg_builder.py (event triggering -> path calculation -> triple generation)
Neo4j storage (Sec. 3.4) app/graph/neo4j_client.py (sync_graph, read_graph)
Sec. 4 Case study (intake system, 5 components/functions) data/intake_system.yaml
Fig. 11 Chronological construction per-event cumulative Snapshots; /ekg/snapshots + UI replay
Fig. 12 Stable/unstable subgraphs for decisions node stability + classification from run_reasoning
Table 1 Realization of AM capabilities scoring.realization_matrix + realization_matrix seed
Table 2 Average + std (Eq. 1-2) scoring.average, scoring.sample_std, scoring.evaluate
Table 3 Comparison with prior methods comparison seed; /comparison

Algorithm 2 (EKG construction)

EKGBuilder.build() iterates the construction recipe in causality order. For each event:

  1. Event triggering - a new event node emerges (and a TRIGGERS edge from the previous event).
  2. Path calculation - existing nodes are matched (MERGE semantics: _ensure_entity only creates missing nodes). reasoning.calculate_paths exposes the path enumeration from a triggered event.
  3. Triple generation - declared sources expand into (h, r, t) triples; the first time an entity appears it is PRODUCESd by the firing event.

After each event a cumulative snapshot is recorded so the UI can replay the build (Fig. 11).

Algorithm 1 (relationship-aware causality)

The paper learns an attention-style embedding that weights neighbouring nodes and propagates causal information from triggered events. The PoC implements a deterministic, explainable approximation:

  • Influence starts at the causal roots (events + components) with value 1.0.
  • It propagates along the relationship-aware edges (TRIGGERS, HAS_FUNCTION, REALIZED_BY, CONSTRAINED_BY, CAUSES) via max-product relaxation.
  • REALIZED_BY edges are modulated by AM-capability quality (score / scale), so a weak capability yields a less stable downstream subgraph.
  • A node's stability is the strongest causal support it receives, in [0, 1]; nodes are classified stable/unstable against a threshold (default 0.5) - the paper's stable/unstable subgraphs used for design decisions.
  • Achievability ("Can it be achieved?", Table 1) is inferred per REALIZED_BY edge as confidence = capability score / scale, a link-prediction analog.

Reproducing Tables 1-2

  • Table 1 is encoded as the realization_matrix (function -> capabilities) and rendered/served verbatim. "Achievable" = the function realizes >= 1 capability (all rows meet requirements, per the paper).
  • Table 2 averages/std are computed by Eq. 1-2 from raw VDI data points in evaluation_metrics. The paper publishes only the aggregates, so the raw arrays are synthesized to reproduce each published mean and sample-std to within ~0.02 (verified in tests/test_scoring.py).

Assumptions and simplifications

  1. VDI scale 0-4 vs reported 4.53. The paper states a VDI 0-4 scale but reports a Topology Optimization average of 4.53/4.54 (text and Table 2), which exceeds 4. To faithfully reproduce the published aggregates we treat the scale as 0-5 (scoring.SCALE_MAX = 5).
  2. Synthesized raw scores. Per-metric data points are not given in the paper; we generated integer arrays that match the published mean/std (see above).
  3. Table 1 partial rows. The source PDF's column alignment for rows with fewer marks is ambiguous. "Shape of the main body" clearly realizes all five capabilities; the other rows use a best-effort, engineering-sensible assignment in the seed.
  4. Deterministic reasoning, not a trained GAT. Algorithm 1's attention embedding is approximated by weighted information-flow (above). This is reproducible and needs no training data or ML dependencies.
  5. Causal roots for stability. Influence is seeded at events and components (the design inputs). PRODUCES edges (event-creates-node bookkeeping) are excluded from stability propagation so quality/depth actually differentiate nodes.
  6. Capabilities without a Table 2 metric. increase_surface_area has no Table 2 entry; its REALIZED_BY edges use a neutral default score (3.0).
  7. Component->function and capability->process-parameter mappings are illustrative, engineering-sensible interpretations consistent with Sec. 4.3.
  8. Feedback edge choice. The paper's reverse causality (t -> h) is illustrated with a process parameter feeding back to reassess a capability (part_orientation -> thin_walls, "revalidates"), matching the paper's "modify process variables" validation loop and avoiding a degenerate duplicate of a forward requirement link.

None of these change the method; they make an under-specified, conceptual paper runnable and its published results reproducible.