Automating Ontology Mapping in IT Service Management: A DOLCE and ITSMO Integration

Top-level and domain ontologies in IT

Top-level ontologies: TLOs such as SUMO, BFO, and DOLCE provide abstract frameworks for representing reality, which can be specialized to any domain (Borgo et al., 2023; Smith, 2008). SUMO offers a broad formal ontology; basic formal ontology (BFO) focuses on fundamental categories for scientific domains; and descriptive ontology for linguistic and cognitive engineering (DOLCE) emphasizes cognitive distinctions and has been applied across various fields, including IT. Notably, DOLCE’s design makes it flexible for conceptual modeling, which is a reason for its adoption in our work. In the IT context, both BFO and DOLCE could, in principle, represent ITIL concepts (such as configuration and incident), but DOLCE’s cognitively oriented categories are better suited for describing processes and artifacts in IT service management. Indeed, ITIL’s core concepts (like Configuration Item and Incident) structurally map to key classes in upper ontologies (e.g., endurant/perdurant in DOLCE or continuant/occurrents in BFO). This study uses the DOLCE-lite version as the foundational ontology (TLO) to be extended into the IT domain (DOLCE overview, ISTC-CNR).

Domain ontologies for ITSM: Several ontologies have been developed for IT and related domains. Examples include the software ontology (SWO) for software tools, common core ontologies for general concepts, and specifically the IT service management ontology (ITSMO, w3id) (El Yamami et al., 2019; Pastuszak, Czarnecki and Orlowski, 2012). ITSMO is designed to model IT service management processes and entities, aligning with the ITIL framework. It defines classes such as Incident, Service, Configuration Item, etc., and is intended to work alongside other standard vocabularies (e.g., GoodRelations, Dublin Core, and FOAF) for interoperability. Because ITSMO already encapsulates many ITIL concepts (like Incident, Configuration Item, Process, Service), it provides an excellent domain-specific ontology to integrate with a TLO. By mapping ITSMO to DOLCE, we aim to create a new ontology that contains the high-level semantic structure from DOLCE plus the domain specifics of ITSMO. This approach follows recommendations in the literature emphasizing the use of upper ontologies to standardize and ease interoperability of domain models.

ITIL framework: Information Technology Infrastructure Library (ITIL) is a set of best practices for IT service management, encompassing processes like incident management, configuration management, service delivery, etc. (El Yamami et al., 2019; Pastuszak, Czarnecki and Orlowski, 2012). ITIL provides an industry-defined structure of how IT services are managed and improved. Representing ITIL in an ontological form helps formalize concepts and their relationships, enabling automated reasoning and integration with other knowledge resources. Prior works have created ontologies or models for subsets of ITIL processes—for example, an ontological model for ITIL’s service level management process and rule-based models to implement ITIL processes. These efforts show the benefit of ontologies for ensuring consistency and clarity in ITIL implementations. However, they typically address specific processes or require manual modeling. By using ITSMO (which covers ITIL concepts) and aligning it with DOLCE, our work builds on these efforts to create a more comprehensive ITIL-based ontology without manual schema creation.

Ontology mapping approaches

Ontology mapping (or alignment) is the task of identifying correspondences between semantically related entities (classes and properties) in different ontologies. A classic review by Choi et al. (2006) categorizes ontology mapping outcomes into three types: (1) pairs of related classes identified (simple mappings), (2) a mediating ‘bridge’ ontology that connects the two (partial reference alignment), and (3) a merged ontology combining both original ontologies. Our goal corresponds to outcome of third type—creating a unified ontology by merging DOLCE and ITSMO classes via subclass relationships (Figure 2). In this process, each ITSMO class will be linked as a subclass of a DOLCE class. If an ITSMO class has no suitable parent in DOLCE (no mapping found), it will default to being a subclass of the root class Thing. This mapping model ensures that domain-specific classes attach to the upper ontology hierarchy, a strategy similar to those proposed in prior alignment studies.

Figure 2

Several methodologies for ontology mapping have been explored in the literature:

• Lexical matching: Early and still-common methods rely on string similarity of class labels or descriptions. Tools like AgreementMakerLight (AML) and LogMap use lexical and simple semantic cues to match classes (Faria et al., 2013; Jiménez-Ruiz and Cuenca Grau, 2011). For example, Noy and Musen’s PROMPT framework supports semi-automatic merging using lexical hints and user input. However, lexical methods often fail when two ontologies use different terminologies or when class names/descriptions do not obviously match. In our case with different domains (IT vs. foundational concepts), we share a few lexical similarities. Indeed, using AML and LogMap off-the-shelf produced no valid mappings between DOLCE and ITSMO, aside from trivial exact name matches. This underscores the limitation of purely lexical approaches in our scenario.

• Graph-based structural matching: Some systems compare the graph structures of ontologies, attempting to align classes by the similarity of their neighborhoods (relationships to other classes). Examples include Falcon-AO and COMA (Noy and Musen, 2001), which use structural indices and matching of class hierarchies (Choi, Song and Han, 2006). Euzenat and Shvaiko (2013) provide a comprehensive overview of such structural methods. Structural approaches can capture context beyond just names by leveraging the ontology’s taxonomy and properties. However, if the two ontologies’ structures differ significantly, these methods may struggle to find alignments that are semantically meaningful. In our case, the DOLCE taxonomy is organized by philosophical categories (e.g., Endurant, Perdurant, and Abstract), whereas ITSMO is organized by ITIL concept categories (e.g., Service, Configuration, and Process). A pure structural match might not align these correctly because their hierarchies reflect different organizing principles.

• Embedding-based methods: Recent research has turned to distributed representations (embeddings) of ontology entities. Techniques like RDF2Vec and OWL2Vec* learn vector embeddings for classes by walking the graph structure of ontologies and using neural language models to capture contextual semantics (Chen et al., 2021; Ristoski and Paulheim, 2016). Such embeddings can encode both lexical information and graph structure in a continuous vector space. Cosine similarity between class embeddings can then suggest mappings (Karadeniz and Ozgur, 2019). Embedding methods have shown high accuracy in discovering relations or class alignments in large ontologies and knowledge graphs. However, they usually require a substantial corpus or graph to train on either a large ontology or external data. In our study, both DOLCE-lite and ITSMO have fewer than 100 classes each, which is extremely small for training embedding models from scratch. Pre-trained models (like those from general text or large knowledge graphs) might not capture the nuances of these ontologies. We included RDF2Vec and a similar Node2Vec approach in our experiments for comparison, but as expected, their performance was poor given the data scarcity. These results align with the notion that embedding models need large training sets (on the order of millions of triples) to be effective.

• Deep learning and transformer models: Building on embeddings, researchers have applied deep neural networks and transformers to ontology alignment. BERTMap (He et al., 2022) uses BERT to generate contextual embeddings of class descriptions and aligns ontologies via a fine-tuned transformer model. These approaches often achieve higher precision by learning from labeled mappings, but they require training data (aligned ontologies or at least positive/negative class pairs) to fine-tune the model. In zero-shot settings (no training pairs), one can still use transformer language models to encode class semantics. For example, He et al. (2023) and Qiang et al. (2024) explored using large transformers to adapt ontologies to new domains, showing that LLMs can capture domain nuances if guided properly. The downside is that large models are resource-intensive and sometimes prone to errors without fine-tuning (e.g., they might ‘hallucinate’ incorrect mappings if prompted naively). Our work employs transformer models in two ways: (a) using pre-trained sentence embedding models (like SBERT or similar) to encode class definitions, and (b) using GPT-4 directly as a predictor to judge class similarity via prompting. We also fine-tuned a pretrained large model (DeBERTa) on an ITIL-related text corpus to see if domain adaptation improves alignment (He et al., 2021; He et al., 2023).

• Large language model (LLM) prompting: The emergence of powerful LLMs (GPT-3.5, GPT-4o, etc.) provides a new paradigm: instead of training a specific alignment model, we can ask an LLM to perform the mapping task (Qiang et al., 2024). Recent work has attempted to use GPT-family models to generate or validate ontology alignments. LLMs can leverage both the semantic meaning of class names/descriptions and general world knowledge. A challenge is that LLM outputs are not deterministic and can vary each run. They also are not guaranteed to understand the ontologies’ strict logical constraints. However, when ontologies are small, one advantage is that we can provide all class information as prompt context. In our case, the combined class descriptions of DOLCE-lite and ITSMO (a total of ~80 classes) fit within GPT-4o’s input limit. This enabled us to prompt GPT-4o with the entire list of classes and ask it to rate the similarity of each DOLCE class to a given ITSMO class. By repeating such prompts and aggregating results, we aimed to reduce random variance from the LLM. Our approach is in line with Amini et al. (2023), who suggest zero-shot LLM-based alignment, and it extends it by introducing multiple prompt trials and statistical filtering for stability.

In summary, existing approaches each have limitations in our scenario: lexical and structural methods falter due to cross-domain differences and sparse data, embedding methods suffer from the small ontology size, and deep learning models need training data which we lack. LLM prompting emerges as a promising approach for zero-shot ontology alignment, albeit one that must be carefully controlled for consistency. In this study, we exclude purely manual or lexical methods and focus on embedding-based, GNN-augmented, and LLM-based strategies, adapting them to work with minimal data and no human supervision.

Ontology data preparation

Ontology descriptions: We use DOLCE-Lite (OWL; https://www.loa.istc.cnr.it/ontologies/DOLCE-Lite.owl), and ITSMO via the canonical resolver https://w3id.org/itsmo (see References for persistent sources), each containing class definitions, relationships, and axioms, and can be represented as string values in natural language with RDF syntax on top of strings. To focus on class mapping, we extracted the label and textual definition of each class (e.g., rdfs:label, rdfs:comment in OWL) as its description. Table 1 summarizes key metrics of the two ontologies:

As seen, DOLCE-lite (in the version we used) has 37 classes, while ITSMO defines 43 classes (Note: some classes in ITSMO are high-level groupings of ITIL entities, whereas DOLCE’s classes partition into abstract categories.). The moderate number of object properties (relations) in each indicates that both ontologies encode rich relationships, though our mapping will consider only class-level alignment in this phase.

We treat each class’s textual description as its primary semantic content. For DOLCE, these descriptions are philosophical, and for ITSMO, they are ITIL-specific:

OWL class description from DOLCE:

<!-- http://ontology.it/itsmo/v1#DataCenter -->
<owl:Class rdf:about=”http://ontology.it/itsmo/v1#DataCenter”>
<rdfs:subClassOf rdf:resource=”http://ontology.it/itsmo/v1#Building”/>
<rdfs:comment xml:lang=”en”>is a facility used to house computer systems and associated components></rdfs:comment>
<rdfs:label>DataCenter</rdfs:label>
</owl:Class>

OWL class description from ITSMO:

<!-- http://www.loa-cnr.it/ontologies/DOLCE-Lite.owl#event -->
<owl:Class rdf:about=”http://www.loa-cnr.it/ontologies/DOLCE-Lite.owl#event”>
<rdfs:subClassOf rdf:resource=”http://www.loa-cnr.it/ontologies/DOLCE-Lite.owl#perdurant”/>
<rdfs:comment>An occurrence-type is stative or eventive according to whether it holds of the mereological sum of two of its instances, i.e. if it is cumulative or not. A sitting occurrence is stative since the sum of two sittings is still a sitting occurrence. In general, events differ from situations because they are not assumed to have a description from which they depend…</rdfs:comment>
</owl:Class>

These texts are the input to our embedding models and also provided to the LLM in prompts. One important assumption we make is that all relevant information about a class is contained in its description and label, that is, we do not utilize the ontologies’ relational structure beyond basic subclass hierarchies. We ignore complex axioms or property restrictions in this mapping step, both to simplify the task and because such details might not align directly between a TLO and a domain ontology.

Similarity computation approaches

We employ two primary approaches for computing similarity between classes of DOLCE and ITSMO:

1. Embedding cosine similarity: Each class description is converted into a vector embedding in a semantic space, and then cosine similarity is calculated between vectors of a DOLCE class and an ITSMO class. High cosine similarity indicates that the two classes have similar contextual meaning. Figure 3 illustrates this process. We experimented with multiple embedding generation methods (detailed in Section ‘Embedding Generation Methods’), including graph embeddings and pre-trained language model embeddings.

2. LLM-based compatibility scoring: To exploit the global context of both ontologies, we prompt GPT-4o with all class descriptions from DOLCE-lite and ITSMO in a single request. The system prompt supplies short encyclopedia-style definitions of the two ontologies, while the user prompt concatenates JSON-ready records for every class (label, rdfs:comment, super-/sub-class links stripped of embedding fields)

Figure 3

The model is instructed to return a JSON object where each DOLCE class key maps to (see Figure 4):

Figure 4

• An itsmo_classes dictionary whose keys are candidate ITSMO classes and whose values are integer confidence scores 0–10, and

• A brief reason string justifying the mapping.

JSON output example:

{
    “endurant”: {
    “itsmo_classes”: { “Service”: 9, “Process”: 7 },
    “reason”: “Endurants are persistent entities that align with ITSMO ‘Service’…”
},
…
}

Because the entire cross-product is scored at once, the output already contains a similarity matrix between the 37 DOLCE and 43 ITSMO classes. We repeat the prompt 500 times with temperature = 0.8 to sample the model’s epistemic uncertainty. Each run is parsed to valid JSON; confidence scores are accumulated and averaged, producing a stable matrix S(D_i, I_j) ∈ [0,10].

For every DOLCE class D_i we then:

1. ‘rank ITSMO classes by mean score’;

2. ‘keep the top-k = 3 entries whose mean exceeds a Z-score threshold (see Section ‘Candidate Filtering via Z-Score Clustering’)’;

3. if no score survives the threshold, mark ‘no match’.

This full-context prompting strategy eliminates the need for thousands of pairwise calls and lets GPT-4o reason over relations among all classes simultaneously, similar to recent agent-based alignment frameworks (Qiang, Wang and Taylor, 2024).

For each DOLCE class, both methods produce a ranked list of ITSMO classes by similarity. In approach (A), the similarity metric is cosine similarity; in (B), the metric is the average LLM score. We use a one-to-many matching strategy, meaning we consider all ITSMO classes as potential matches for each DOLCE class. Our aim is to find, for each DOLCE class, up to three top candidates in ITSMO that could be its subclasses.

Important assumption: We assume no external knowledge beyond the class descriptions. For instance, the LLM is not asked general ITIL questions; it strictly sees the ontology content. This focuses the task on ontology alignment rather than relying on the LLM’s world knowledge (though inevitably some general knowledge might influence GPT-4o’s understanding of terms).

Embedding generation methods

We tested several methods to generate class embeddings for the cosine similarity approach:

Each embedding set is evaluated independently in the mapping step. We will later compare which embedding type led to better alignment accuracy (Section ‘Results’).

Note on small ontology challenges: Both RDF2Vec and Node2Vec tend to underperform on small ontologies (<100 classes) when trained without external corpora or literals; with enrichment (e.g., text literals and background graphs), they may yield meaningful signals, but in our setting they lagged behind transformer-based text embeddings. The transformer-based embeddings have the advantage of being pre-trained on large corpora, so they bring in general semantic understanding (e.g., knowing that ‘hardware’ and ‘server’ are related, or that ‘incident’ implies an event). Fine-tuning on ITIL-specific text aimed to inject domain-specific context (like understanding ‘change request’ in ITIL terms). Nonetheless, fine-tuning a model as large as DeBERTa on only ~17k short texts is borderline in terms of data adequacy—we observed only slight improvements, and indeed our results will show that the fine-tuned model did not dramatically outperform its base version (see following results).

Graph neural network for embedding enrichment

To incorporate the graph structure of the ontologies into our semantic representations, we applied a Graph Neural Network (GNN) model that refines the class embeddings by considering their neighborhood in the ontology graph. The intuition is that classes are not isolated: for example, Incident in ITSMO might be linked to Service or Impact classes; capturing these connections could help align Incident to a DOLCE class like Perdurant (Event), which also might connect to Process or State in DOLCE.

We used a two-layer GraphSAGE GNN with mean aggregation (Hamilton, Ying and Leskovec, 2017). The process is as follows:

Neighbor aggregation: For each node v, the embeddings of neighboring nodes N(v) and the node v itself are aggregated.

Aggregation function: The aggregation function used is the mean:

Embedding update: The aggregated embedding is transformed using a trainable weight matrix W:

Message passing (Layer 2): We repeat a similar operation, now each node gathers the embeddings of neighbors updated by Layer 1, computes the mean, and applies the second layer transformation.

For the second layer, the process is repeated, but the input is the embedding z¹(v) from the first layer:

Output projection: After two GNN layers, we add a final linear layer that projects the node embeddings back to the original embedding size (e.g., 768-d if BERT was used). This ensures the enriched embeddings reside in the same vector space as the originals, making them comparable to the original embedding-based similarity scores.

Training objective: We train the GNN in an unsupervised manner, using a reconstruction loss. Specifically, we aim to make the GNN’s output embeddings as close as possible to the original input embeddings for each node. The rationale for this is to preserve the original semantic information (which came from text or pre-trained models) while injecting structural context by forcing the GNN to account for neighbors. We used the Adam optimizer and employed early stopping if the loss did not improve, to prevent overfitting.

The model is trained on a reconstruction task, minimizing the mean squared error (MSE) between the output embeddings h_v and the original embeddings x_v:

where h_v,i and x_v,i are the ith components of the output and input embeddings for node v, respectively.

Hypothesis: We hypothesized that enriching embeddings with GNN would improve mapping results. The GNN could, for example, adjust embeddings so that classes that are siblings or share a parent in the ontology get more similar vectors, which might help correctly cluster them. It also might ‘smooth’ noisy embeddings—if one class’s text embedding was off-target, the GNN will pull it closer to its neighbors’ vectors.

We trained separate GNN models for each embedding type on each ontology (DOLCE and ITSMO graphs considered independently). The resulting enriched embeddings (denoted as GNN_node2vec, GNN_bert_base, etc.) were then fed into the similarity and mapping pipeline just like the original embeddings. Figure 5 depicts the GNN enrichment process, showed that the GNN training converged, with different initial embeddings leading to different loss levels. Notably, when initialized with the text-embedding-3-small vectors, the GNN achieved the lowest reconstruction error, suggesting those embeddings were most consistent with the ontologies’ graph structure.

Figure 5

In practice, as we will discuss, the GNN’s effect was mixed: it did modify the similarity distributions (we observed some smoothing of cosine similarities across class pairs), and it increased the recall of correct mappings in the top-3 cluster for some methods, but it sometimes reduced the top-1 precision. This is likely due to the very small size of our graphs—with only dozens of nodes, the GNN has limited room to improve representation and might instead overfit to trivial patterns (like making all siblings more similar even if they are semantically different). We include the GNN results to analyze this effect.

Candidate filtering via Z-score clustering

Regardless of similarity method (embedding or LLM), each DOLCE class ends up with a ranked list of ITSMO classes. However, not every DOLCE class will have a valid corresponding subclass in ITSMO—some DOLCE upper categories might not be represented in the ITSMO scope. We therefore need a way to decide how many of the top candidates (0, 1, 2, or 3) to accept as final mappings for each DOLCE class.

We achieve this by analyzing the distribution of similarity scores for each DOLCE class and applying a Z-score threshold:

After similarity computation—cosine similarity for embeddings or mean confidence for GPT-4o—we have, for every DOLCE class D, a score vector

We compute the mean (μ) and standard deviation (σ) of these scores for class D.

We identify the top three highest-scoring ITSMO classes:

For each shortlisted score, compute its Z-score relative to D’s distribution:

Z high Z_k means the candidate deviates positively from the background of random matches for that particular DOLCE class.

Empirical tuning on a manually checked validation subset showed that LLM-derived scores have a broader spread than embedding-based scores. Accordingly, we set two method-specific cut-offs:

The Z-score filter acts as an outlier detector: only those ITSMO classes whose similarity to a given DOLCE class exceeds the class-specific mean by ≥0.005 σ (LLM scores) or ≥1.3 σ (embedding scores) are accepted. This suppresses spurious matches that often arise for very general DOLCE nodes such as Entity or Abstract, whose score distributions are otherwise almost flat. At the same time, the rule still permits legitimate one-to-many alignments—on average 1.8 ITSMO subclasses are retained per mapped DOLCE class—yielding a clean set of candidate subclass assertions that forms the draft merged ontology, later verified by an OWL reasoner and a domain expert.

Gold-standard creation and evaluation protocol (human in the loop, top-k checking)

Stage A—Candidate proposals (LLM-assisted). We first used an LLM to generate candidate alignments from DOLCE to ITSMO. For each DOLCE class, the model proposed one or more ITSMO classes together with a confidence-like score and a short rationale. This step served only to produce suggestions and to accelerate expert review.

Stage B—Expert consolidation (human evaluation). A domain expert then adjudicated the candidates: for each DOLCE class, the expert confirmed, replaced, or rejected the proposed pairs (binary validation at the pair level), and could introduce no-match labels when appropriate. The outcome is a human-evaluated gold standard matching: either a single adjudicated ITSMO class for DOLCE class or no-match. This adjudicated mapping subsequently materialized in the merged ontology and is the mapping we would deploy. After materialization, we ran OWL 2 DL reasoners (HermiT and Pellet) over the merged ontology to check logical consistency and class satisfiability. No inconsistencies or unsatisfiable classes were reported, providing an orthogonal, symbolic confirmation of the validity of the expert-consolidated gold (Thieblin et al., 2021).

Stage C—Automatic methods to be evaluated. Independent of Stages A and B, we evaluated several automatic scoring methods that, for each DOLCE class d, produce a ranked list of ITSMO classes: (1) embedding-based similarity (multiple encoders), (2) GNN-enriched variants, and (3) an LLM scoring pipeline that assigns scores to (d,c) pairs. For fairness, the LLM scoring outputs were normalized to the same range as vector-based scores and treated exactly like another method. None of these methods influenced the gold labels.

Stage D—Top-k extraction. For each method m and class d, we extracted the top-3 candidates (or fewer if fewer candidates were available): $C_m^{(3)}(d) \hspace{0.33em}= \{c_{d, 1}, c_{d, 2}, c_{d, 3}\}$

Stage E—Metrics against human-evaluated gold standard. All metrics are computed exclusively against the expert gold. We report Top-1 Accuracy (%) and Top-3 Inclusion (%).

Non-circularity. The expert-adjudicated gold defines correctness; all methods—including the LLM scoring variant—are evaluated against this human gold. The initial LLM proposals in Stage A were assistive and did not determine the labels: the expert had full authority to confirm/reject/replace and to assign a no-match. Therefore, proposal and evaluation are decoupled, and no circular evaluation is performed; the HermiT/Pellet reasoning results further support the soundness of the consolidated gold.

Embedding analysis and similarity distribution

Before looking at accuracy numbers, it is informative to see how the various embedding strategies differed. We visualized the embeddings for all classes of both ontologies in a 2D plane using PCA (principal component analysis). Figure 7 shows one such visualization for a representative embedding set (e.g., BERT-base). In almost all embedding methods, the DOLCE class vectors and ITSMO class vectors occupy distinct regions of the space. They are nearly linearly separable as two groups, which is not surprising: the two ontologies have different vocabularies and contexts, so a model can usually distinguish ‘this is a DOLCE concept’ versus ‘this is an ITSMO concept’. However, this separation does not imply that the closest ITSMO vector to a given DOLCE vector is a correct mapping. Linear separability means a simple classifier could tell which ontology a class belongs to, but our task is to bridge them, which requires deeper semantic alignment. Indeed, many of the nearest-neighbor pairs in the raw embedding space were not meaningful mappings, hence the need for further refinement and filtering.

Figure 7

To measure GNN impact on the embedding pairs during cosine similarity calculation, we quantify these effects on the ranking distribution by (1) the per-column variance of ITSMO→DOLCE cosine similarities, (2) the per-column IQR (interquartile range), and (3) the normalized entropy (0–1) of each DOLCE column. We also report a two-sample Kolmogorov–Smirnov (K–S) test comparing all similarity values before vs. after GNN, and the mean column-wise maximum similarity (‘mean max’) as a proxy for peak concentration on the top candidate (see Table 2).

The ‘smoothing/balancing’ effect of our GNN is embedding-dependent: it is strong for distributional graph embeddings (RDF2Vec), negligible for modern transformer text embeddings, and Node2Vec under our settings. We therefore refine our claim: GNN post-processing can substantially stabilize similarity distributions when base embeddings are noisy/high-variance but provides limited gains when base distributions are already tight.

Mapping accuracy and comparison of approaches

Table 3 summarizes the mapping accuracy results for each approach we tested. Each row corresponds to an embedding or method (with and without GNN enhancement), plus a random baseline and the GPT-4 LLM approach. The key columns are the Top-1 Accuracy (%) and Top-3 Inclusion (%) as defined above, and Matched Classes, which is the total count of ITSMO classes mapped (including duplicates if a class appeared as a top candidate for multiple DOLCE classes).

Several clear patterns emerge:

• LLM leads. GPT-4o tops the table (73.5 % Top-1, 82.4 % Top-3), confirming that zero-shot LLM reasoning is the most reliable alignment signal.

• Transformer embeddings are solid runners-up. DeBERTa-v3-large achieves ~64% Top-3; fine-tuning on ITIL text adds little, indicating that large pre-trained models already capture enough semantics for small ontologies.

• Classical graph embeddings collapse. RDF2Vec and Node2Vec score at or below a random 27.6% Top-1 baseline, showing that structural cues alone are ineffective at this scale.

• GNN smoothing is inconsistent. GraphSAGE sometimes boosts Top-3 recall but typically lowers Top-1 precision; the tiny graphs provide too little structure for a net gain.

• Fine-tuning gains are marginal. Extra domain data did not noticeably raise performance, underscoring the strength of zero-shot transformers.

Overall, the pipeline maps about four-fifths of ITSMO classes to plausible DOLCE parents without manual labels, with GPT-4o providing the decisive edge and transformer embeddings offering a practical non-LLM fallback.

Practical applicability and value

From a practical perspective, the ability to generate an initial ontology mapping automatically can greatly accelerate knowledge graph development in enterprises. In our case, the new ontology provides a formal integration of ITIL concepts (via ITSMO) with an upper ontology (DOLCE). This merged ontology can now serve as a backbone for building an IT knowledge graph that is both consistent (through DOLCE’s rigor) and rich in domain detail (through ITSMO).

One of the most significant implications of our work is proof that ontology engineers can leverage AI to do the heavy lifting of class alignment. This could lower the barrier for organizations to adopt semantic technologies. Instead of requiring a panel of ontology experts in ITIL to map every class, one could run an automated alignment like ours to get a draft ontology, which an expert then only needs to review and refine, not create from scratch. Even with our ~82% accuracy, an expert would only need to correct or add mappings for the remaining 18%, a much smaller effort than manual mapping of 100% of classes.

Our method could be seen as an Agent-assisted ontology engineering: the AI does the first pass mapping, then experts refine. This is akin to how, in other domains, an AI Agent is used to generate a draft design or plan, which humans finalize.

Scalability and domain generality

Scalability: A current limitation of our pipeline is the reliance on GPT-4o prompts for best performance. GPT-4o was used with the entire set of classes as input, which worked because we only had ~80 classes to compare. If we were to map a much larger ontology (say thousands of classes) to another, we cannot simply include all class descriptions in a single prompt at larger scales. While modern GPT-4-class models support long contexts (≥128k tokens and, for the GPT-4.1 family, up to ~1M tokens), very large ontologies may still exceed practical context and cost budgets; thus, we adopt blocking or hierarchical strategies. The computational cost of 500 GPT-4o queries for each class is non-trivial as well—though for 37 DOLCE classes it was manageable, for hundreds it would be expensive and slow. That said, we can optimize: if domain ontology has N classes and TLO has M classes, doing N × M LLM evaluations is the worst case. In practice, a hierarchical or blocking approach could limit comparisons (e.g., first map broad categories, then refine within sub-trees). Alternatively, one could use a smaller LLM or a fine-tuned model to emulate GPT-4o for large tasks. Scalability of embedding methods is better—computing embeddings for thousands of classes is fine, and even GNN on thousands of nodes is fine. So if needed, one might resort to a hybrid: use embeddings to narrow down candidate matches, then use an LLM on the short-listed pairs.

Generality to other domains: We believe our approach is quite general. The prerequisite is having a top-level ontology and a domain ontology to align. Many domains have their own ontologies (medical, financial, manufacturing, etc.) and could use a foundational ontology alignment. For example, mapping a medical ontology to BFO, or a geospatial ontology to SUMO. The challenges might be domain-specific (e.g., jargon that LLMs might not know well), but with domain literature or description text, it should be feasible. The key components—embedding computation, optional GNN enrichment, LLM prompting, Z-score filtering—are domain-agnostic.

However, one must be cautious: an ontology alignment is only as good as the ontologies’ documentation. If class descriptions are poor or non-existent, embedding and LLM methods falter. We were fortunate that both DOLCE and ITSMO have decent textual descriptions for classes. This is a limitation in generality—we assume well-documented ontologies.

Automated ontology extension: Another aspect of scalability is extending beyond just mapping existing classes to adding new classes. Our current mapping is a one-time alignment. The future extension (as mentioned in the ‘Future Work’ section below) involves discovering if there are concepts in the IT domain not covered by ITSMO and adding them. That moves beyond mapping into ontology learning.

Limitations and potential improvements

Despite the success, there are important limitations to acknowledge:

Although the same family of LLMs was used to propose candidates, the evaluation relied exclusively on human gold labels obtained via expert adjudication; therefore, the study does not employ circular evaluation. The LLM’s role is strictly assistive—to prioritize candidates and reduce expert time—not to arbitrate correctness.

Future extensions

We envisage three technical strands.

• Ontology expansion. Using the merged ITO-seed as a backbone, we will mine enterprise corpora—incident tickets, CMDB records, knowledge articles—via NER + relation-extraction models to surface terms and relations not yet represented. Candidate concepts will be clustered in embedding space, provisionally typed by an LLM, and inserted as new subclasses or properties, followed by reasoner validation and expert veto. The cycle ‘text → candidates → ontology update’ can iterate continuously.

• Richer alignment. Extending beyond subclass links, we will map object/data properties and allow justified multi-inheritance or equivalence assertions. Instance data will be reconciled against the ontology to flag misclassifications and refine the schema. The same pipeline can merge additional domain ontologies (e.g., business-process or security models) through the common DOLCE spine, yielding an interoperable, cross-domain knowledge fabric.

• Tooling and deployment. A lightweight interface will present model-suggested mappings with confidence scores, let engineers approve or correct them, and feed the feedback into active-learning retraining. Pilot deployment in an IT-service desk will measure downstream impact—for example, incident routing accuracy and data-entry consistency—to quantify the value of AI-assisted ontology maintenance.