Review Comment:
The paper presents a structured comparison of incremental view maintenance techniques for SPARQL conjunctive queries, implemented in the Incremunica engine and evaluated using an extended TypeScript version of the Train Benchmark. The results show that performance depends on query shape, update type, and data characteristics. Comparing all approaches in a single engine is a sound design, and the public code, the TypeScript benchmark with shape queries, and the proposed optimizations are valuable contributions. However, the motivation and formalization need to be clearer, and several aspects of the evaluation limit how far the conclusions can be generalized.
First, the introduction states the basic idea of incremental view maintenance, but it should explain more clearly when maintaining stored results is more efficient than recomputing them after each update, and why this makes a comparison of incremental join techniques important. This trade-off is only briefly mentioned in Section 4.1 and should be introduced earlier.
The introduction also motivates the work through streaming applications, but the evaluation uses small batches of updates without windows, arrival rates, or throughput measurements. The streaming-related claims throughout the paper, such as the claim in Section 8 that the Rete-based approach suits high-throughput streaming workloads, are therefore unsupported and should be either evaluated or moderated.
The authors should clarify what they mean by "low-latency query answering" and distinguish query response time from the time needed to process an update. Moreover, none of the evaluated approaches is full recomputation, since the single-order delta query is already incremental. A recomputation baseline, as used in the authors’ earlier Incremunica paper [21], would show how much each approach gains over recomputing from scratch.
The running example in Section 2 presents only the static graph and query, while the update that motivates incremental view maintenance (adding :switch2 :connectsTo :segment2) appears only in Section 4. Showing already in Section 2 how this update changes the query result, and why recomputing the result is costly, would help readers understand the motivation and the challenges before the detailed discussion.
The preliminaries need clearer explanations of their notation and more precise definitions of RDF graphs and SPARQL queries. For example, the statement that "entities are interconnected through subject–predicate–object triples" is too broad, since a triple's object can be a literal.
In Section 3, the notation should be used consistently. For example, the notation vars(·) denotes all occurring variables for triple patterns and bags of mappings, but only the projection variables for queries (Section 3.3), and Equation 9 uses vars(µ), although only dom(µ) is defined for mappings. In addition, since Equation 3 reuses the variables of Equation 2, the authors could state that it only illustrates the notation for bags of mappings. The running example in Section 3.2 could also be presented more clearly, for example by complementing the formulas with a table and short step-by-step explanations, instead of long paragraphs. It could also include a mapping that occurs more than once to illustrate multiplicity. More generally, the presentation of all running examples in the paper would benefit from a similar improvement. The authors should also justify the selectivity definition in Equation 14, particularly the use of the sum of input cardinalities as the denominator, and explain how to interpret this measure for joins. Finally, in Section 3.4, Equations 19–22 give different results for identical expressions, and the intended meaning should be stated explicitly.
Section 4 presents the existing approaches clearly, with pseudocode and worked examples. However, the proposed optimizations, the Memory Bind Join and the Rete indexing strategies, are described only in text, without pseudocode. Since they are contributions of the paper, they should be specified as precisely as the existing algorithms. In addition, Section 4.3 states that the rules for combining added and deleted mappings were given in the preliminaries, but Section 3.4 does not define them. Since these rules determine how changes propagate, they should be stated explicitly in Section 3.4, together with a formal definition of the materialized view and how the graph evolves as changes are applied. Finally, Table 1 should state whether costs are per update or per result.
The single-order delta query evaluates a new query for each changed triple, whereas the original counting algorithm processes changes in batches (as in Equation 23). The authors should discuss whether its poor performance reflects this implementation choice rather than the approach itself.
The paper proposes optimizations for both the bind join and Rete approaches, but provides a dedicated evaluation only for the Rete joins. The authors should either justify this choice or add a similar controlled evaluation of the Memory Bind Join, for example varying the number of duplicate and deleted mappings.
Regarding the implementation (Section 5), the code and benchmark results are publicly available, which supports reproducibility. However, for queries with FILTER EXISTS and FILTER NOT EXISTS, the authors should state which join algorithm evaluates the inner pattern, and discuss how evaluating filters only at the end affects the results for the Train Benchmark queries.
The paper does not give an overview of the evaluated queries and scenarios, and Appendix A lists only the largest version of each added shape query, while results are reported for several operation sizes. The authors should add an overview, for example, as a table, giving for each query its shape, operation sizes, and type of updates, and explain how the smaller versions are derived.
Regarding the evaluation, the paper uses a fixed join order (Section 5.3). Since some approaches, especially the higher-order delta queries, are highly sensitive to join order, the results may reflect the chosen order rather than the algorithms themselves. The authors should explain how the order was chosen and discuss its impact on the comparison.
The paper analyzes and measures only execution time. Since the approaches also differ in what they store, their memory requirements should also be analyzed in Section 4, and ideally measured in the experiments. The results tables should also distinguish runs that exceeded the time limit from those that ran out of memory, since one case is too slow and the other needs too much memory. In addition, the authors should define what the reported execution times measure (update processing, result retrieval, or both).
The paper cites cyclic queries as one reason to exclude the Dynamic Yannakakis algorithm, but none of the evaluated queries appears to be cyclic. The authors should include cyclic queries in the evaluation or discuss this limitation.
The scalability of the approaches is evaluated only on small datasets (at most about 64,000 triples), and many configurations already exceed the time limit at the larger sizes, leaving few comparable results. The authors should justify the chosen dataset sizes and time limits, and discuss how far the conclusions extend to realistic, larger datasets.
Section 8 attributes the performance of the Match Hash Join to the characteristics of realistic data (few duplicates, Cartesian joins, and shared bindings), but these characteristics are not measured. The authors should report them for the Train Benchmark queries to support this explanation.
Regarding related work, the authors should clarify what this article adds beyond their earlier Incremunica paper [21], which already presents the engine with multiple incremental operators, and how their comparison differs from the original Train Benchmark study [22]. The related work section is also brief and mostly lists systems. It could be extended with a short discussion of how each group of approaches relates to the evaluated techniques. Finally, the authors should discuss the recent work by Staquet et al. [A], which adapts the counting algorithm to SPARQL, and clarify how it relates to the single-order delta query implemented in Incremunica.
Minor: The presentation needs careful proofreading. For example, Section 2 refers to Section 5 for the Train Benchmark (it is described in Section 6), the numbering in the running example is broken, Section 6.2 lists the scenario characteristics twice, and Section 8 contains two nearly identical paragraphs. Also, several typos need correction.
[A] Staquet, Dore, Bart Buelens, and Jan Van den Bussche. "Incremental View Maintenance for SPARQL Queries: Adapting the Counting Algorithm." ACM Transactions on the Web (2026).
|
