iSummary: Workload-based Selective Summaries for Knowledge Graph Exploration

The authors have provided a substantially improved manuscript, and the quality has clearly increased as a result of the revisions. Most previously raised issues have been satisfactorily addressed, and the paper is now clearer and more cohesive. However, I am still missing a concrete, practical application scenario that demonstrates how the proposed summarization method would be used in a real-world setting. Such an application-oriented example would strengthen the motivation, clarify practical relevance, and help readers understand the intended use of the proposed approach. I therefore recommend a minor revision to incorporate this element.

I would like to thank the authors for providing a detailed response and a clearly improved version of the paper. However, I still have some concerns, thus, cannot accept the paper for publication in its current status.

Major comments

Regarding the algorithm, the authors clarified my previous comment partially. They explain endpoint-based variable resolution and position it as a step toward hybridization. They also say the approach is complementary to KG-structure methods and explicitly discuss what happens with inadequate logs. However, the “revert to structure-driven variant” idea is still more future work or suggestion than an alternative algorithm with evaluated performance.

I guess there is a problem with definition 1. It is posed with node weights and maximization of sum of node weights. As far as I see, the approximation proof section constructs a working graph where edges have frequency weights and defines the objective as sum of edge weights (“coverage weight”). This is a potential theory-to-method mismatch unless the authors very clearly reconcile. Are you approximating the node-weight objective from Definition 1, or an edge-weight / coverage objective? If both, where is the equivalence established?

The authors, moreover, explain why Random can beat PPR/GLIMPSE under query-log coverage. Random is restricted to the query-induced in the subgraph.
This explanation is reasonable, but it also poses a concern. The authors seems to be comparing methods operating on different information sources. They do discuss “comparability of query-log and KG-based methods” later, which helps. However, I would invite the authors to include an additional KG-based baseline that is also constrained to the same induced subgraph, to isolate algorithmic merit from information advantage.

iSummary is built using the query logs, and the main score that the authors report is “coverage” which measures how well the summary matches those same kinds of queries. However, the evaluation is a bit self-aligned. The authors do a fair thing by testing on different queries than the ones used to build the summary (train/test split), which helps. But if iSummary gets high coverage, does that mean the summary is truly useful for people to explore and understand the KG? Or does it mainly mean it is good at reproducing the patterns that appear in the query logs, without proving it improves real user exploration? From my point of view, the method is being judged mostly on how well it matches query-log fragments, not on whether humans actually find the summaries better. This should be stated in the paper clearly.

The authors also add a small qualitative evaluation from a demo with 10 participant feedback percentages. A part of the fact that the number is small, the authors fail to provide any statistical significance about the experiment. They only report some simple percentages of agreement “80% said …”. The demo evidence is weak. I would also suggest authors to tone down claims like “consistently outperforms” and “useful to end-users” when the user study is tiny and non-comparative, or explicitly label the demo feedback as preliminary.

Even though the authors report low divergence between log-based and endpoint-based variable instantiation, the endpoint strategy (e.g., taking the first/limited results) can still be non-deterministic or biased because it depends on the SPARQL endpoint’s default result ordering. I suggest clarifying the ordering assumptions and considering a more robust resolution method (e.g., deterministic ordering or top-k aggregation) to avoid arbitrary choices affecting the produced summary.

I suggest adding an ablation study to better isolate the contribution of each design choice in the proposed method, such as the impact of log size, tie-breaking strategy, shortest-path restriction, and node/edge weighting scheme. This would improve the transparency of the approach and help readers better understand which components are most critical to its performance.

Minor comments:
(λ, κ)-Selective Summary problem, -> in the abstract there should be no notations or undefined symbols.
Steiner tree problem -> add citation
Hybrid use of the knowledge graph: While the computation primarily relies on the query log, iSummary optionally accesses the underlying knowledge graph through its SPARQL endpoint only to instantiate unresolved variables in the generated summary. In this step, a single first result is retrieved per variable to ensure completeness. -> why can be this a contribution? What are you contributing at here? This is listed as a contribution, but in the methods section the authors also say that they “always pick the first endpoint result thus leaving a more complex selection for future work, which makes it feel more like an implementation option than a research contribution.
conduct extensive experiments -> also this is not a contribution. It is part of the evaluation of your contribution, but it cannot be considered as a contribution itself.

Strengths: The workload-first framing is well motivated. The comparison of log-based and endpoint-based variable resolution, along the dimensions of freshness, completeness, determinism, and autonomy, is a substantive piece of design analysis. The limitations section acknowledges workload bias, log sparsity, and the structural-vs-workload asymmetry. In my opinion, the bias in logs is a real problem, given that certain queries in both DBpedia and WikiData query logs are from automated users (applications) which generate the same query patterns continuously, en mass, and "pollute" the logs. Section 4.8's discussion of the KG-vs-log incomparability is a necessary piece of methodological framing. The worked example in Section 4.7, contrasting Steiner, CHINS, and iSummary, anchors the behavior of the algorithm concretely.

RDF modeling: Section 2.1 introduces an RDF-to-graph abstraction in which edges are unlabeled and predicates (including rdf:type) are treated uniformly. The algorithm, however, operates on predicate-labeled paths such as ?x dbo:spouse ?y. The abstraction as stated does not match the structure the algorithm actually uses. The authors should either revise the abstraction to a labeled directed multigraph, or state explicitly that Section 2.1 is a bookkeeping simplification and that the algorithmic graph is a labeled multigraph derived from the queries.

Relatedly, treating rdf:type identically to domain predicates is defensible for frequency counting, but has semantic consequences. A (Person, rdf:type, Professor) edge and a (Person, advisor, Professor) edge encode different information, and summaries that conflate them may obscure the schema-vs-instance distinction that users of KG exploration interfaces typically rely on. The current sentence on this point in Section 2.1 is brief. The limitations section should address it more directly.

SPARQL handling: The paper states that FILTER, UNION, OPTIONAL, and aggregation clauses are dropped and only BGPs are retained. Two questions follow.

First, the treatment of SPARQL property paths is not specified. A pattern such as ?x foaf:knows+ ?y encodes structural information that flat BGP extraction would either lose or mischaracterize. The authors should clarify whether property paths are rewritten, ignored, or treated as single edges.

Second, the assumption that logs contain syntactically valid and semantically meaningful queries that return at least one answer misses a practical issue. Real endpoint logs contain substantial volumes of bot traffic, malformed queries, and federated query fragments. The authors note that preprocessing is offline and one-shot, which is reasonable, but the paper does not report what fraction of the raw DBpedia and WikiData logs "survived" preprocessing. This figure matters for practitioners applying the method to other endpoints.

Variable resolution (endpoint mode): Algorithm 3 issues queries of the form SELECT ?o WHERE {?o a Person} LIMIT 1. The paper acknowledges that endpoint result ordering is implementation-defined, but the practical implication is stronger than stated: on public endpoints, the first result of an unordered query can vary between runs, particularly under federation or caching. The reported empirical divergence below 10% between the log-based and endpoint-based variants is tied to the specific DBpedia and WikiData snapshots used in the evaluation, and the paper should say so.

Evaluation: Two concerns on the evaluation design.

First, the coverage metric is trained and tested on the same query log. This structurally favors any workload-derived method, including the Random baseline (which is itself workload-restricted), over KG-structure-driven methods such as PPR and GLIMPSE. Section 4.8 acknowledges this asymmetry, but the acknowledgement does not offset its effect on the headline comparison. A seed-held-out split, in which test seeds never appear in training queries, would test whether summaries generalize to unseen exploration targets rather than to unseen queries about already-seen targets. If a full seed-held-out evaluation is not feasible, the caveat should at minimum be flagged in Section 4.3, not only in 4.8.

Second, the GLIMPSE comparison does not report what query set was provided as input to GLIMPSE, which requires user queries as part of its interface. Without this information, the reader cannot determine whether GLIMPSE received the same workload information iSummary exploits, a filtered subset, or something weaker.

Questions for the authors.

1. Please reconcile the unlabeled-edge abstraction in Section 2.1 with the labeled-path algorithm that operates downstream.
2. How are SPARQL property paths handled, if at all?
3. What fraction of the raw DBpedia and WikiData logs survived preprocessing?
4. Can the evaluation include a seed-held-out split, in which test seeds do not appear in training queries?
5. What query set was provided to GLIMPSE as its user-query input?