A new Graph-based Retrieval-Augmented Generation (RAG) approach for querying and instantiating large-scale industrial semantic artifacts

I thank the authors for their careful and thorough revision of the manuscript. The revised version addresses the previously raised concerns regarding token-limit behavior during retrieval and subgraph expansion, providing clearer explanations of the design choices and trade-offs. Additionally, the repository has been improved with the inclusion of further materials that enhance the transparency and reproducibility of the experimental evaluation.

This new version of the paper introduces several improvements that constitute an important step towards a more consolidated approach for graph RAG for industrial datasets.

In particular, the scope of the paper has been clarified, which has repercussions in different sections of the manuscript. For instance, the separation of OPC-UA from SAREF gives a better perspective of the generalizability of this approach. Contributions and research questions have also been revisited in order to remove previously identified vagueness problems and to emphasize on the generalizability aspects.
There has also been a substantial effort in providing a clearer formalization that gives the paper more substance beyond a simple implementation or engineering work.
The validation has also been improved, removing irrelevant comparisons and introducing additional baselines. The evaluation has also been extended substantially, which now constitutes a much more credible evidence of applicability.

One important detail is that at certain point towards the end of the paper the authors mention that they introduce their approach as "Graph-RAG", when GraphRAG is a family of RAG techniques that no only already exists but has many different variants and implementations. Therefore the authors should change the narrative and also include a more convincing position regarding its differentiation with previous approaches. This is already done in the related ork section, but only very superficially. This should be clarified and also referenced in the introduction to avoid any misunderstandings.

Minor details

- (p2l6) Reference [1] is too limited. At this point the authors refer to application domains for semantic artifacts. Therefore they should references several papers in which this is happening, or also reference surveys where these applications are attested.

- (p2l9) This data or "these data". Maybe use plural in this case? I think both are possible

- (p2l23) This problem is true, but it is also worth noting that these models operate at often different levels. WoT includes semantic means of specifying how "Things" interact with each other, while others like SAREF stays fore at the "descriptive modeling" end. This makes the heterogeneity problem even harder.

- (p2l33) "RDF/TTL files and knowledge graphs": this sounds a bit misleading, TTL files are usually *also* KGs. Perhaps better to rephrase and say that KGs (including its different file formats like TTL, etc) cannot be segmented like other textual contexts.

- (p4l46) reference to the OPC foundation?

- (p5l26) "The" SAREF ontology

- (p5l45) U is not defined, L is not defined. Make sure all elements in the formalization are defined.

- (p6l10) What is the function Sim() ?

- (p9l24) Section 3 seems at times to show like GraphRAG is a new thing, when it's not. The authors may need to be very clear at this point explaining the novelty of the approach with respect to Graph RAG approaches sin general , and not only to conventional RAG. There are many alternatives in the literature and the position of this paper in Section 3 is really not very clear

- (p10l30) This part explains the subgraph extraction mechanism, which it seems has not been included in the formalization. However this come back in Seciton4.2. Perhaps a clear link can be made between these parts.

- (p12l28) What kind of simplifications for OWL axioms? Not clear

- (p15l8) Not clear what exactly is the ExpansionRules function here, it should be better explained within the context of the formalization.

- (p16l18) the experiments in Section 7

-(p24l40) At this point the authors mention that they introduce Graph-RAG. This is very misleading as GraphRAG is a family of approaches that already exists. The authors should provide another name or way to referring to this specific approach. Later on in the related work the authors try to position this work with respect to other GraphRAGs, but it should be made clearer.

This manuscript was submitted as 'full paper' and should be reviewed along the usual dimensions for research contributions which include (1) originality, (2) significance of the results, and (3) quality of writing. Please also assess the data file provided by the authors under “Long-term stable URL for resources”. In particular, assess (A) whether the data file is well organized and in particular contains a README file which makes it easy for you to assess the data, (B) whether the provided resources appear to be complete for replication of experiments, and if not, why, (C) whether the chosen repository, if it is not GitHub, Figshare or Zenodo, is appropriate for long-term repository discoverability, and (4) whether the provided data artifacts are complete. Please refer to the reviewer instructions and the FAQ for further information.

This is an interesting, well written paper providing novel insights into the combination of LLMs and Semantic Web Technologies. The proposed approach is original and fairly well evaluated.

All relevant material is provided in a GitHub repository. This repo is well organized and well documented. To ensure reproducibility of the paper results, I suggest to freeze a version of the repo with, e.g., a zenodo DOI.

A few more detailed comments that should be addressed prior to publication:

general: the running title is missing

p2, l21: "RDF, TTL, or OWL" should be rephrased, after all TTL is an OWL-serialisation
p2, l24 ff: I suggest to also mention Graph-RAG here
p3, l1: validation and verification are two different things, should be phrased more precisely
p3, l29: what is specific about industrial semantic artifacts - or what makes the approach suited to those only?
p4,l45ff: the descriptionof OPC UA lacks references
p5,l44ff: U and L are not defined
p6, l5: s is used to denote both subject and SPARQL query.
p6, l20: is it correct, that the new graph has to contain the old one? So no updates or changes allowed?
p6,l8: might be good to mention somewhere, that as result to a NLQ, you expect something structured (like a set of queries, not a natural language answer).
p6,l42: SPARQL has been used before, bit late to introduce the acronym
p8,Fig 3: The figure sort of suggests that the embeddings for the text chunks happens at query time (and thus again for each query). I assume that is not that case...
p10, Fig 5: how is the subgraph provided to the LLM? as graph or in some form of embedding?
p11, l10: what happens if there is more than one possible URI?
p12,l50ff: something is wrong with this sentence
p14,l32: where is the inclusion of parent classes reflected in the algorithm?
p20, l4: shouldn't that be 4/5 (see line 14)
p20,l30: why is 3/5 deemed correct?
p20,l38/39: the numbers of the per-execution ratio seem not to match (47/60 does not equal 0.7, neither does 42/60 equal 0.72)
p24,l33ff: I didn't understand the remark about the size reduction. This needs more elaboration.
p24,l40: This is the first time, the approach is called Graph-RAG, before it was called Our RAG. should be named consistently - and Graph-RAG may be too close to GraphRAG not to cause confusion.
p25,l10: linebreak