The INTENT Ontology: An Ontology for Intent-based Data Operation in the Computing Continuum

Summary
The paper proposes an ontology for intent-based data operations in the cloud-edge-IoT continuum, reusing TIO, PROV-O, SOSA, FOAF, and ORG. The topic is timely and the FILL industrial case study is concrete.

Strengths

Timely and well-motivated topic
Sensible reuse of established vocabularies
Clear five-dimension scoping
Concrete industrial validation scenario

Issues

1. No accessible ontology resource.
2. Unconvincing evaluation. All 10 test intents in Table 5 achieve perfect 1.0 precision and recall.
3. Missing formal content. The paper describes classes in prose and diagrams but provides no OWL axioms, SHACL constraints, namespace declarations, or SPARQL queries. The competency questions in Section 3 are never systematically answered in Section 6.
4. Architecture mixed with ontology. This is a formatting issue, which can be fixed easily.
5. Weak differentiation from TIO. The novelty claim needs sharper articulation.

I would encourage authors to fix these issues and resubmit. The conceptual framework is reasonable, but the missing resource, formal gaps, and limited evaluation prevent acceptance in the current form.

(1) Quality and relevance of the described ontology.
- The authors introduce the INTENT Ontology. The paper has a solid foundation using well-known and maintained ontology methodologies such as TMF, PROV-O, FOAF, & SOSA. The Authors provide clear challenges and an approach to these challenges (INTENT ontology). They provide a running example based in the manufacturing domain to demonstrate the concept of intent-based data management. The paper's additional effort to unify intents, users, resources, applications, and workflows into a single entity is very relevant.

(2) Illustration, clarity, and readability of the describing paper, which shall convey to the reader the key aspects of the described ontology.
- However, while the paper frames the research as human and system-oriented, the paper shifts more heavily into the system side compared to the human side, which, when talking about the intent of the users, weakens the paper. Understanding the behaviors of humans can give more insight into the intent that the papers claim to hold as important.
- Papers like OntoPret: Look at the human side to reason about and over human behavior in collaborative settings. While the paper isn’t directly in the same field of influence, understanding the human users and their mental models can provide insights into their intent.
- Conducting interviews with the target users will provide even more insights into what and how users will use this framework. We as researchers have one idea as to how this framework will help, but in reality, the real working humans that will interact with this might not need the same requirements that we predict (human behavior is weird and unpredictable). If we develop something that we think is useful without the input of actually wokers, we run into the potential to develop something that is inevitably useless. Understanding the goals, how these decisions are made, and their interpretation is important.
- Formalizing the Agents beyond their roles.
- Have you looked into user profiles/personas for the agents (both the individual humans and the organizations)? Having an individual understanding of these agents beyond the high-level roles can strengthen the understanding of intent.
- Security issues
- How are we managing security issues with these user identifications?
- Evaluating the users
- The current paper tells one side of a story. The evaluations are centered around the system, which is fine, except we are looking at the human user as well. Evaluating their interactions is necessary.
- Look into using a SUS.
- Other Comments
- Line 40 “ is to make easier”: missing a word here.

(3) External Source (GitHub Repository).
- The authors did not link a repository for this work. It would have been nice to have some documentation on the CQs, any schema(s) that may have been created for the INTENT ontology, and any ttrl files. Not having an accessible repository to the ontology hinders this work's claims. I strongly suggest that the authors create a repository specifically for the INTENT ontology and link to it in the paper. (I couldn't find it when I looked, only a link to the FOAF repository). Reproducibility and accessibility for reviewing ontologies are incredibly important (especially in today's culture of research).

# Summary

The paper presents the INTENT ontology, which aims to represent high-level goals (called intents) in industrial applications independently of the underlying technical infrastructure. The manuscript describes the ontology's main classes in prose and illustrates its intended use through a case study.

# Strengths

The paper addresses an important problem: representing goals at a level of abstraction that is not tied to a specific deployment infrastructure. The inclusion of an industrial use case is also valuable, as it helps illustrate the intended application of the ontology.

# Weaknesses

## W1 Readability

The main weakness is that the paper is difficult to understand. Several key terms, such as "computing continuum," "intent lifecycle," "cloud-edge-IoT continuum," and "coordinated computational fabric," are used without sufficiently precise definitions. In addition, many of the paper’s central claims are expressed in language that sounds technical but remains too abstract to evaluate. For example, phrases such as "formal conceptualization of intent handling," "showing the ontology’s expressiveness," and "operationalizing the ontology as a knowledge graph" are not explained in enough detail.

This lack of precision also affects the validation section. For example, the term "container" appears to be central to the evaluation, but it is not clear what kind of container is meant. At first, I thought a container is to be understood in terms of Software Engineering (e.g., a Docker container), but formulations such as "the workflow class acts as an organizational container," suggests that "container" can also refer to a class in an ontology. Ambiguities like these make it difficult to understand both the ontology and the experimental setup.

## W2 Fit to the call for papers

Ontology description papers are expected to be short descriptions of the ontology, its design principles, and its intended use in a brief and pointed manner. At 29 pages, it is much longer than expected for this category. Moreover, Section 5, "Ontology Description," runs from page 10 to page 20 and largely verbalizes the contents of the ontology rather than providing a concise explanation of the ontology's core design principles and key design decisions.

A further issue is accessibility. Ontology description papers are expected to make the ontology freely and openly available. I could not find a link to the ontology in the manuscript, nor was I provided with access to the ontology as part of the review material.

## W 3 Lack of evidence to substantiate claims

The abstract, introduction, and conclusion make several strong claims about the proposed ontology:

The INTENT ontology:

1. helps humans deploy applications in heterogeneous environments by connecting different domains (see abstract)
2. supports semantic querying, validation, and interoperability (see introduction)
3. can increase trust and governance in connected systems (see conclusion)

These are substantial claims, but the evidence provided in the paper is insufficient to support them:

1. Section 6 presents a single case study. While this use case is helpful as an illustration, one scenario is not enough to justify broad claims about interoperability across heterogeneous environments or about the ontology’s ability to connect different domains.

2. The claims about semantic querying and data validation are also difficult to assess because the discussion remains entirely at the level of prose. The paper does not provide concrete examples of queries, validation rules, input data, expected outputs, or failure cases. As a result, I am unable to determine what kinds of semantic queries are actually supported, what is being validated, or how the ontology contributes to these processes.

3. The claim that the ontology increases "trust and governance" is not developed at all. The paper does not define what trust or governance mean in this context, nor does it provide a method for assessing whether either has improved. Without clearer definitions, evaluation criteria, or empirical evidence, this claim remains entirely unsubstantiated.

# Recommendation

The paper addresses an important problem and proposes a potentially useful ontology, but the manuscript is not yet suitable for publication as an ontology description paper. The paper is too long, key terminology is not clearly defined, the ontology itself is not made available, and the purported benefits of the ontology cannot be verified without supplemental materials.

I encourage the authors to address the weaknesses outlined above and resubmit their work. The idea of representing goals, or intents, at an abstract level is a promising one, but the paper would benefit substantially from a more detailed and reproducible presentation. In particular, concrete examples, including queries, inputs, outputs, and validation steps that readers can rerun on their own machines, would make the contribution much easier to assess.