Dx-Onto: A Core Ontology for a Semantic-Based Framework for Managing Digital Transformation Projects

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The article proposes Dx-Onto, a central ontology for knowledge management in digital transformation (Dx) projects.

The article provides a broad conceptual review.

Some comments on the article's text:

The work presents some limitations, such as empirical validation and comparison with existing works.

There is a lack of comparison with a baseline.

Lack of ontological formalization (metrics).

Author Response

Got it! Here is your single, combined response with polished grammar and an academic tone, keeping your exact structure intact:

Comment 1: The work presents some limitations, such as empirical validation and comparison with existing works.

Comment 2: There is a lack of comparison with a baseline.

Comment 3: Lack of ontological formalization (metrics).

Response: We have addressed the concerns of all three comments by developing a benchmarking experiment against the COOT ontology. All relevant data—including the baseline comparison, coverage metrics, and empirical validation against existing works—has now been fully addressed in the revised manuscript, specifically Section 8.

Reviewer 2 Report

Comments and Suggestions for Authors

This paper introduces "Dx-Onto," a core domain ontology implemented in OWL, designed to structure, integrate, and manage heterogeneous knowledge and multimedia artifacts generated during Digital Transformation (Dx) projects. The authors address a critical and practical problem: the fragmentation of project knowledge across various organizational silos and formats. To evaluate the technical feasibility and scalability of the ontology, they developed three query-driven scenarios and conducted performance experiments using synthetically generated datasets. 

I found some good points and atrengthes.
1. Well-Defined Scope and Motivation: The paper clearly articulates the practical challenges of data heterogeneity in Dx projects. Unifying multi-format files (PDFs, spreadsheets, images, and videos) under a semantic layer is a highly relevant and practical goal.
2. Comprehensive Ontology Design: The design of Dx-Onto is modular and covers multiple strategic dimensions (9 subclasses), project phases, and operational/technological ecosystems, providing a rich semantic hub.
3. Consideration of Future Trends: The inclusion of a hybrid LLM-Ontology concept is very timely and adds potential value to the practical application of the proposed ontology.
4. Open Science: The authors provided a GitHub repository for the ontology, which enhances the reproducibility of the work.

However there are some weaknesses and areas for Improvement:
1. Lack of Evaluation with Real-World Data:
The performance and scalability evaluation relies entirely on algorithmically generated synthetic datasets. While the authors state that real-world Dx project data is often protected by NDAs, relying solely on synthetic data limits the validation of the ontology's conceptual accuracy and utility. The authors should consider providing at least one small-scale qualitative case study or a user study/expert evaluation involving actual Dx project managers to verify whether the ontology effectively captures real operational realities.

2. Lack of Direct Comparison with Existing Ontologies:
Although the literature review mentions existing frameworks like COOT and DT&I-BPM-Onto, the paper lacks a detailed, explicit comparison showing exactly which concepts or relationships are missing in prior work but resolved by Dx-Onto. A comparative table or a dedicated subsection outlining the precise theoretical gaps would significantly strengthen the paper's claimed contributions.

3. Ambiguity in LLM Integration:
The abstract and introduction emphasize that Dx-Onto will serve as the core semantic layer for a proposed Hybrid LLM-Ontology framework. However, the technical details of how this integration works—such as how the ontology grounds the LLM to prevent hallucinations or how natural language is mapped to SPARQL queries via Dx-Onto—are not fully explained. Please clarify the exact scope of this paper regarding the LLM integration, or provide a brief architecture overview of this hybrid framework.

4. Clarification on Multimedia Extraction:
In Section 4.2.1 (Scenario 1), the paper illustrates metadata retrieval for multimedia files (e.g., classifying a file as "ImageType"). It would be helpful to briefly explain how these unstructured artifacts are ingested into the ontology. Is this mapping expected to be done manually by project administrators, or is there an automated pipeline (e.g., using computer vision or text extraction metadata)?

Even with the points you could have improved as above, overall, this is a solid and well-written manuscript with a clear contribution to knowledge management in the digital transformation domain. Addressing the evaluation gaps and providing clearer comparisons with prior work will greatly improve the impact of this study.

Further comments on the figures.

1. Quality and Legibility of Ontology Diagrams (Figures 2, 3, and 4):
While the conceptual diagrams are comprehensive, the text inside the nodes in Figure 3 (The nine strategic dimensions) and Figure 4 (The overall taxonomy of Dx-Onto) is extremely small and blurry, making them very difficult to read. Please replace these with high-resolution vector graphics (e.g., PDF or SVG format converted to high-DPI TIFF/PNG) or consider splitting Figure 4 into smaller, modular sub-figures so that readers can clearly examine the properties and class hierarchies.

2. Consistency in Naming Conventions:
Please ensure that the naming conventions (such as camelCase, PascalCase, or hyphens) used for classes and properties in the text exactly match those visualized in Figures 2, 3, and 4. For instance, verify that terms like "DxProject" or specific object properties are written identically in both the manuscript text and the diagrams to prevent reader confusion.

3. Improvement of Figure 5 (Performance Graphs):
Figure 5 illustrates the query execution times across different scales of dataset volumes. To make this figure more informative:
- Please ensure the error bars (reflecting the Standard Deviation shown in Tables 3, 4, and 5) are clearly visible or clarified in the caption.
- Consider using a logarithmic scale for the Y-axis if it helps to better present the scalability trend from low-volume to high-volume data.
- The font size of the axis labels and legends should be slightly increased for better readability.

4. Table Enhancements (Tables 3, 4, and 5):
The quantitative data in Tables 3, 4, and 5 is detailed and well-structured. However, instead of separating them into three distinct tables, the authors might consider merging them into a single, comprehensive table with hierarchical column headers (Low, Medium, High volume). This would allow readers to compare the performance metrics (Mean, SD, Median, p95) of Q1, Q2, and Q3 across different volumes more efficiently.

Author Response

Comment 1: Lack of Evaluation with Real-World Data: The performance and scalability evaluation relies entirely on algorithmically generated synthetic datasets. While the authors state that real-world Dx project data is often protected by NDAs, relying solely on synthetic data limits the validation of the ontology's conceptual accuracy and utility. The authors should consider providing at least one small-scale qualitative case study or a user study/expert evaluation involving actual Dx project managers to verify whether the ontology effectively captures real operational realities.

Response: We have added a real-world dataset to address this concern. Furthermore, we have benchmarked Dx-Onto against the COOT ontology to demonstrate better grounding performance.

Comment 2: Lack of Direct Comparison with Existing Ontologies: Although the literature review mentions existing frameworks like COOT and DT&I-BPM-Onto, the paper lacks a detailed, explicit comparison showing exactly which concepts or relationships are missing in prior work but resolved by Dx-Onto. A comparative table or a dedicated subsection outlining the precise theoretical gaps would significantly strengthen the paper's claimed contributions.

Response: We have improved the literature review to provide a better conceptual comparison between the ontologies. Additionally, the newly added experiments section compares the performance of Dx-Onto directly with existing studies.

Comment 3: Ambiguity in LLM Integration: The abstract and introduction emphasize that Dx-Onto will serve as the core semantic layer for a proposed Hybrid LLM-Ontology framework. However, the technical details of how this integration works—such as how the ontology grounds the LLM to prevent hallucinations or how natural language is mapped to SPARQL queries via Dx-Onto—are not fully explained. Please clarify the exact scope of this paper regarding the LLM integration, or provide a brief architecture overview of this hybrid framework.

Response: We have revised the future roadmap section to clearly reflect how Dx-Onto can be used to reduce hallucinations in RAG-based LLMs by explicitly querying data through its semantic meanings rather than relying solely on embeddings.

Comment 4: Clarification on Multimedia Extraction: In Section 4.2.1 (Scenario 1), the paper illustrates metadata retrieval for multimedia files (e.g., classifying a file as "ImageType"). It would be helpful to briefly explain how these unstructured artifacts are ingested into the ontology. Is this mapping expected to be done manually by project administrators, or is there an automated pipeline (e.g., using computer vision or text extraction metadata)?

Response: The core scope of this ontology focuses on the semantic data model rather than the extraction mechanics, which is why the specific pipeline details were initially omitted. However, for the experiments, we implemented an automated pipeline utilizing video frame sampling and multimodal LLM translation for processing video and image content. In practical applications, because Dx-Onto acts purely as a structured data model and not an extraction method, it is designed to support both automated pipelines and manual administrative workflows seamlessly.

Further comments on the figures.

Comment 1: Quality and Legibility of Ontology Diagrams (Figures 2, 3, and 4): While the conceptual diagrams are comprehensive, the text inside the nodes in Figure 3 (The nine strategic dimensions) and Figure 4 (The overall taxonomy of Dx-Onto) is extremely small and blurry, making them very difficult to read. Please replace these with high-resolution vector graphics (e.g., PDF or SVG format converted to high-DPI TIFF/PNG) or consider splitting Figure 4 into smaller, modular sub-figures so that readers can clearly examine the properties and class hierarchies.

Response: All ontology diagrams have been updated and rendered as high-resolution SVG graphics.

Comment 2: Consistency in Naming Conventions: Please ensure that the naming conventions (such as camelCase, PascalCase, or hyphens) used for classes and properties in the text exactly match those visualized in Figures 2, 3, and 4. For instance, verify that terms like "DxProject" or specific object properties are written identically in both the manuscript text and the diagrams to prevent reader confusion.

Response: We have verified and standardized all naming conventions throughout the text and diagrams as suggested.

Comment 3: Improvement of Figure 5 (Performance Graphs): Figure 5 illustrates the query execution times across different scales of dataset volumes. To make this figure more informative:

• Please ensure the error bars (reflecting the Standard Deviation shown in Tables 3, 4, and 5) are clearly visible or clarified in the caption.

• Consider using a logarithmic scale for the Y-axis if it helps to better present the scalability trend from low-volume to high-volume data.

• The font size of the axis labels and legends should be slightly increased for better readability.

Response: We have removed this figure from the manuscript and instead utilize comprehensive tables to explain these results, as both present the same data trends.

Comment 4: Table Enhancements (Tables 3, 4, and 5): The quantitative data in Tables 3, 4, and 5 is detailed and well-structured. However, instead of separating them into three distinct tables, the authors might consider merging them into a single, comprehensive table with hierarchical column headers (Low, Medium, High volume). This would allow readers to compare the performance metrics (Mean, SD, Median, p95) of Q1, Q2, and Q3 across different volumes more efficiently.

Response: We have reworked the tables into a single consolidated format with hierarchical headers. This summarizes the data in a more efficient and readable manner while reducing the total number of tables required.

Reviewer 3 Report

Comments and Suggestions for Authors

The authors should rename the second section to “Related Works” to better align with standard academic structure.

The authors should include a dedicated “Background” section to explain key concepts relevant to the study, such as semantic ontology, ontology types, digital transformation, knowledge management, and the main challenges associated with digital transformation initiatives.

The authors must clearly define the main research problem. From lines 52–69, multiple problems are discussed simultaneously, making the central problem difficult to identify. The discussion combines semantic interoperability issues, heterogeneous data formats, knowledge silos across departments, inefficient and error-prone manual knowledge extraction, low adoption of ontology-based approaches, and the absence of a comprehensive core ontology for Dx projects. These issues should be separated and structured more clearly to distinguish causes, consequences, and research gaps.

The authors should discuss how the unresolved challenges of ontology engineering may affect its practical implementation and long-term effectiveness. Although ontology engineering is presented as a solution, the literature also recognizes it as a difficult process with several remaining limitations.

The authors should justify more clearly why ontology engineering was selected as the preferred approach for this study. This explanation should be included in Section 3 and supported by stronger arguments comparing ontology engineering with alternative knowledge integration approaches.

The authors should also discuss the role of team expertise in ontology engineering. Since ontology engineering requires specialized knowledge and remains a complex process, limited experience among team members may negatively affect the development, adoption, maintenance, and scalability of the proposed ontology.

Author Response

Comment 1: The authors should rename the second section to “Related Works” to better align with standard academic structure.

Response: We have addressed this comment by renaming the second section to "Related Works" in the revised manuscript to better conform to standard academic structure.

Comment 2: The authors should include a dedicated “Background” section to explain key concepts relevant to the study, such as semantic ontology, ontology types, digital transformation, knowledge management, and the main challenges associated with digital transformation initiatives.

Response: We have addressed this comment by adding a dedicated "Background" subsection within the Related Works section to thoroughly explain all of these key foundational concepts.

Comment 3: The authors must clearly define the main research problem. From lines 52–69, multiple problems are discussed simultaneously, making the central problem difficult to identify. The discussion combines semantic interoperability issues, heterogeneous data formats, knowledge silos across departments, inefficient and error-prone manual knowledge extraction, low adoption of ontology-based approaches, and the absence of a comprehensive core ontology for Dx projects. These issues should be separated and structured more clearly to distinguish causes, consequences, and research gaps.

Response: We have addressed this comment by restructuring the problem statement in the Introduction. The text now clearly separates and distinguishes the operational causes, organizational consequences, and the resulting research gaps.

Comment 4: The authors should discuss how the unresolved challenges of ontology engineering may affect its practical implementation and long-term effectiveness. Although ontology engineering is presented as a solution, the literature also recognizes it as a difficult process with several remaining limitations. The authors should justify more clearly why ontology engineering was selected as the preferred approach for this study. This explanation should be included in Section 3 and supported by stronger arguments comparing ontology engineering with alternative knowledge integration approaches. The authors should also discuss the role of team expertise in ontology engineering. Since ontology engineering requires specialized knowledge and remains a complex process, limited experience among team members may negatively affect the development, adoption, maintenance, and scalability of the proposed ontology.

Response: We have addressed this comment by adding a comprehensive discussion in Section 3. This new text explicitly justifies our choice of ontology engineering over alternative approaches, addresses its practical limitations and long-term sustainability, and discusses how team expertise impacts the scalability and maintenance of the proposed ontology.

Round 2

Reviewer 2 Report

Comments and Suggestions for Authors

The revised manuscript is well-structured and significantly improved. The addition of the empirical benchmark in Section 8 effectively validates the practical utility of Dx-Onto against an existing baseline using a real-world corpus. This comparative analysis, alongside the scalability evaluations, successfully addresses the concerns regarding validation and domain specificity.

To ensure the manuscript is fully ready for publication, the authors should address the following minor technical and formatting corrections:

In Section 10 (line 701), please remove the accidental LaTeX dollar signs from the plain text. The sentence should read, "As illustrated in Figure 7, the architecture operates..." instead of using mathematical delimiters around the figure number.

In Section 6, within the Use Case 1 SPARQL query (lines 418 and 419), there is a syntax error due to missing logical comparison operators. The current code block should be corrected to explicitly state (?projectName = "Satun travel project" && ?fileType = "image") and (?projectName = "Coding School project" && ?fileType = "image" || ?fileType = "word")) to ensure valid query execution.

In Section 8.1 (lines 545 and 564), please correct the typographical error regarding the Large Language Model version name. The current text references "Qwen3.6-plus", which appears to be a typo; please update this to the exact name of the model deployed in your study to maintain technical accuracy.

In Section 5.1 (lines 318 to 322), please eliminate the textual redundancy where Figure 3 and the central class dx:DxProject are introduced twice in consecutive sentences. The authors should combine these lines into a single, concise statement, such as: "The architecture of the Dx-Onto schema is illustrated in Figure 3. The ontology is structured around the central class dx:DxProject, which acts as the semantic hub connecting all critical aspects of a digital transformation initiative."

Author Response

Comment 1:  In Section 10 (line 701), please remove the accidental LaTeX dollar signs from the plain text. The sentence should read, "As illustrated in Figure 7, the architecture operates..." instead of using mathematical delimiters around the figure number.

Response 1:   Thank you for pointing this out. We have removed the unnecessary LaTeX mathematical delimiters that we put by mistake in this revision.

 

Comment 2:  In Section 6, within the Use Case 1 SPARQL query (lines 418 and 419), there is a syntax error due to missing logical comparison operators.

 

Response 2:  Thank you for pointing this out. We apologize for the oversight. This was a typographical error that occurred during the final formatting and preparation of the manuscript, as the original query was tested and executed successfully. We have revised the SPARQL FILTER expression in Section 6 accordingly to ensure it accurately reflects the valid, executable syntax.

 

Comment 3:  In Section 8.1 (lines 545 and 564), please correct the typographical error regarding the Large Language Model version name. The current text references "Qwen3.6-plus", which appears to be a typo; please update this to the exact name of the model deployed in your study to maintain technical accuracy.

Response 3: Thank you for this precise observation. The model reference was indeed correct, but we acknowledge the capitalization error. We have revised the name from "Qwen3.6-plus" to the official designation "Qwen3.6-Plus" throughout the manuscript to ensure strict technical accuracy. These corrections have been applied in Section 8.1 (lines 543, 561, and 665).

Comment 4:   In Section 5.1 (lines 318 to 322), please eliminate the textual redundancy where Figure 3 and the central class dx:DxProject are introduced twice in consecutive sentences.

Response 4:   Thank you for pointing this out. We have removed the redundant description  to improve readability as suggested.

 

Reviewer 3 Report

Comments and Suggestions for Authors

The authors incorporated the comments and suggestions from the previous stage.

Comments on the Quality of English Language

No additional comments.