COntExt: Towards Context-Aware Ontology Extension from Operational Metrics

COntExt: Towards Context-Aware Ontology Extension from Operational Metrics

Hussain Hussain 1 , Stefan Schöberl 2 , Angelika Schneider 3 and Verena Geist 2

1 Know Center Research GmbH, Graz, Austria

2 Software Competence Center Hagenberg GmbH, Hagenberg im Mühlkreis, Austria

3 Fraunhofer AISEC, Garching bei München, Germany hhussain@know-center.at, stefan.schoeberl@scch.at, angelika.schneider@aisec.fraunhofer.de, verena.geist@scch.at https://orcid.org/0000-0002-0959-623X https://orcid.org/0009-0006-0245-3558 https://orcid.org/0000-0002-8962-3276 https://orcid.org/0000-0002-3729-1265

Abstract Organizations increasingly define operational metrics in structured, machine-readable formats to monitor systems, processes, and compliance. These metric definitions implicitly encode domain knowledge, such as referencing concepts, properties, and relationships, that often extends what is captured in formal ontologies. Yet the connection between operational metric catalogues and ontological knowledge remains manual, ad-hoc, and labour-intensive. We present COntExt, a framework for context-aware ontology extension that takes structured metric definitions as input and suggests how referenced concepts and properties should be integrated into an existing ontology, utilizing the context of these metrics. The framework defines the extension problem as three sub-tasks: parent class prediction, relation type prediction, and data property assignment. Across seven ontologies spanning four domains, we evaluate different algorithms for each task. Our results show that metric-derived context improves the suggestions over ontology-context baselines for relation type prediction and data property assignment. Our work demonstrates that operational metric catalogues are a practical and underexploited source for ontology extension. This work enables organizations to maintain their ontologies at a significantly lower cost than manual engineering.

1 INTRODUCTION

Motivation. † † Preprint; a short version is accepted at KEOD 2026. Domain ontologies provide formal, shared conceptualizations that enable interoperability, reasoning, and knowledge reuse across systems. In practice, however, ontologies lag behind the domains they represent. New concepts, properties, and relationships emerge continuously, driven by evolving regulations, operational requirements, and technological change [ Zablith et al., 2015 , Elnagar et al., 2022 ] . Ontology engineers must manually identify these gaps and extend the ontology, a process that demands both domain expertise and knowledge-engineering skill. Meanwhile, many organizations already capture significant domain knowledge in a parallel, less formal artefact: structured metric definitions [ Van Looy and Shafagatova, 2016 , Yu et al., 2026 ] . Metric definitions, expressed in semi-structured human-readable forms, represent an important intermediate artefact between natural-language text and formal ontologies. A cybersecurity team, for example, may maintain hundreds of YAML-based metric definitions that reference threat types, system components, compliance properties, and their relationships, often using terminology that closely mirrors the organization’s domain ontology. However, this implicit knowledge is currently discarded from the perspective of ontology maintenance.

Figure 1: An illustration of COntExt framework. This figure shows the input to COntExt, represented by the ontology model and the operational metric files in .yaml format. The metrics parser identifies mentions of concepts (classes and properties). The identified concepts are then passed on to COntExt , which performs the corresponding tasks: 1) predicting the parent of an identified class, 2) predicting the type of relation between a pair of classes, and 3) predicting the class that owns the mentioned property. The output of COntExt can be passed on to update the ontology. The example metric (shown in Listing 1 ) is extracted from security criteria “Encryption of data for transmission”, specified in the BSI C5:2020 (CRY-02).

Problem. Existing approaches to ontology completion draw on two main sources: unstructured text corpora [ Liu et al., 2020 , Sanagavarapu et al., 2022 , Kollapally et al., 2025 ] and the structural patterns within the ontology itself [ Shen et al., 2020 , Jiang et al., 2022 , Ma et al., 2021 ] . Neither exploits the middle ground occupied by operational artefacts such as metric definitions. These artefacts are more constrained and semantically explicit than free text, yet they are richer in contextual information than bare ontology axioms.

Approach. Our approach centres on a key question: Does metric-derived context (e.g., descriptions, comments, and configuration values embedded in structured metric catalogues) provide ontology-extension signals beyond an ontology’s own linguistic and structural content? We address this question by building a C ontext-aware Ont ology Ext ension framework (COntExt) that tackles three extension sub-tasks: 1) parent class prediction, 2) relation type prediction, and 3) data property assignment. COntExt is an algorithm-agnostic framework that allows for injecting textual context with each query, making it suitable for metric-driven context. Figure 1 illustrates COntExt framework and its sub-tasks with an example of a metric-driven query. We evaluate the utility of extension methods for each task using only ontology context and then comparing it to layering metric-derived context on top of the same methods. We demonstrate the benefit of metrics-derived context for ontology extension on an ontology associated with a metric catalogue, CertGraph ontology [ Schöberl et al., 2024 ] . Our findings suggest that operational metrics are useful sources of context for relation type prediction and data property assignment on the evaluated use case. However, the context seems to degrade the extension accuracy for parent class prediction. Our source code is publicly available 1 1 1 https://github.com/sqrhussain/COntExt and can be easily adapted for similar use cases.

Contribution. We make the following contributions:

1. A metric-driven algorithm-agnostic ontology extension framework (COntExt) that takes the target ontology and metric definitions as input and suggests their integration into an existing ontology.

2. A context enrichment strategy that incorporates metric descriptions, comments, configuration values, and ontology annotations into algorithm inputs, improving suggestion relevance beyond ontology-only baselines.

3. A comparative evaluation of several algorithms across the three sub-tasks and seven ontologies.

4. Empirical evidence that structured operational metric catalogues are a viable source for ontology extension, bridging the gap between operational knowledge and formal representations.

   Impact. Our work exploits metric definitions for ontology extension, opening an opportunity for exploring a class of input, typically overlooked by existing literature. With COntExt, organizations maintaining both a domain ontology and a structured metric catalogue can keep their ontology aligned with evolving operational definitions at substantially lower cost than manual ontology engineering.

   2 Related Work

   2.1 Ontology Extension, Completion, and Enrichment

   The interest in maintaining domain ontologies to keep them up to date has been growing for years. A large body of work focuses on adding new classes or relations based on textual corpora. [ Elnagar et al., 2022 ] develop a domain-independent framework that generates formal ontologies from unstructured text corpus. [ Sanagavarapu et al., 2022 ] use deep sequential models, such as Bi-LSTMs, to extract concepts and relations from unstructured text and enrich a base security ontology. Several works focus on language models at different stages of ontology enrichment. For example, [ Kollapally et al., 2025 ] use large language models (LLMs) for extracting triples from textual context. [ Dong et al., 2024 ] evaluate pretrained language models (PLMs) embeddings and LLMs for relation matching and prediction. [ Liu et al., 2020 ] use BERT next-sentence prediction on ontology neighbourhoods to predict parents of biomedical concepts. Finally, KROMA [ Nguyen et al., 2025 ] integrates LLMs with a knowledge retrieval pipeline for concept semantic equivalence. These examples show that contextual language models can capture ontological semantics and support automated insertion of novel terms.

   Another set of relevant works focuses on graph-based completion methods. [ Chen et al., 2025 ] provide a comprehensive survey of ontology embedding methods. Several graph neural networks (GNN)-based approaches focus on predicting the parent concept. TaxoExpan [ Shen et al., 2020 ] and TaxoEnrich [ Jiang et al., 2022 ] learn from existing hierarchies via self-supervised objectives: they use position-aware GNNs to predict where new hyponyms should attach. HyperExpan [ Ma et al., 2021 ] similarly leverages hyperbolic embeddings to model hierarchical structure. For predicting missing relations, [ Mežnar et al., 2022 ] uses structure-only link-prediction algorithms. With the exception of [ Mežnar et al., 2022 ] , all these methods combine structural features (position in a hierarchy) with semantic features of surface text , e.g., word meanings, to rank candidates.

   Our proposed framework incorporates these ontology extension tasks previously tackled by these works. However, instead of unstructured text corpora or pure graph structure with surface text, our framework enriches predictions with features from operational metric definitions that represent the most recent domain knowledge.

   2.2 Ontology and Metrics

   Research on ontology and metrics has proliferated across domains such as semantic web, IoT, biomedical, engineering, and sustainability.

   On the one hand, a line of research uses ontologies to define or construct metrics. This line of work produced several ontology-based frameworks for cohesive measurement of health and quality of life [ Cella and Hays, 2022 ] , harmonizing measures for bike (transport) network evaluations [ Grisiute et al., 2024 ] , evaluating security assurance metrics [ Wen and Katt, 2024 ] , and guiding extraction of ESG metrics [ Yu et al., 2026 ] .

   On the other hand, a more related line of work uses metrics for assessing ontologies (or related schemas). These works treat ontology metrics as formal, quantitative measures of ontology structure or content. A recurring trend is the creation of tools and frameworks for standardization. For example, NEOntometrics [ Reiz and Sandkuhl, 2024 ] implement dozens of proposed metrics, addressing a historical gap of “missing implementations”, while OntoInsight [ Sammi et al., 2025 ] guides quality evaluation with metrics and AI-driven recommendations.

   Others tackle domain-specific needs, e.g., a cybersecurity ontology [ Bryniarska and Pokuta, 2022 ] uses standard metrics to assess security models, MEDTO [ Hao et al., 2021 ] maps concepts from medical databases, used by medical experts, to an ontology to support downstream applications, a survey by [ Bain and Dutta, 2024 ] evaluates 24 COVID-19 ontologies via structural assessment, OntoLogX [ Cotti et al., 2026 ] transforms raw cyber threat intelligence logs into ontology-grounded knowledge graphs, and SHACLEval [ Reiz et al., 2025 ] defines metrics specific to SHACL constraints to ensure data graph quality. More specifically, the cybersecurity community has produced extensive catalogues and classifications of security metrics, proposing and refining taxonomies for security metrics [ Savola, 2007 , Pendleton et al., 2016 , Longueira-Romero et al., 2020 , Morrison et al., 2018 ] . Furthermore, metric-driven ontology engineering has also proliferated in the context of continuous certification and measurement [ Stephanow and Fallenbeck, 2015 , Schöberl et al., 2024 ] .

   Despite the increasing adoption of operational metrics and their association with domain ontologies, previous work has not yet investigated leveraging operational metrics to streamline or automate ontology development. Although some works, such as the one from [ Sammi et al., 2025 ] , have used metrics to guide ontology development, these works focus on refining the quality of the ontology and not its alignment with developing domain knowledge. Our work tackles this gap in particular by developing a framework that allows exploiting operational metrics as context for the extension of domain ontologies to keep ontologies up to date with the domain they represent.

   3 Framework

   This section describes the COntExt framework at the conceptual level: what it takes as input, how it decomposes the ontology extension problem, and how the context enrichment is applied. The specific algorithms are detailed in the evaluation (Section 4 ).

   3.1 Input Representation

   Ontology model. COntExt operates on any formal ontology that defines a class hierarchy, object properties (relationships between classes), and data properties (attributes of classes). The model of the input ontology consists of:

   • A class hierarchy with parent-child relationships.

   • An inventory of object properties and data properties.

   • Property axioms specifying domain and range restrictions. These axioms link classes to each other (through object property axioms) and classes to attributes (through data property axioms).

   The ontology may be supplied in any machine- and human-readable format (e.g., OWL/XML, RDF, OWX) from which these structural elements can be extracted. Textual context can be also harnessed from ontologies if available, e.g., in the form of rdfs:comment . Studying methods for extraction and model building is not within the scope of our work.

   Metric definitions. The second input is one or more structured metric definitions. Each definition is expected to be in a machine-readable format (e.g., YAML, JSON, XML) and to contain fields that reference domain concepts, either explicitly (e.g., through typed references to classes and properties) or implicitly (e.g., through descriptions, configuration parameters, and comments that mention domain terminology). COntExt requires a parser that can extract candidate class references and property references from these definitions. The specific extraction mechanism is not the topic of our work, but it depends on the format and conventions of the metric catalogue in use.

   3.2 Extension Tasks

   COntExt decomposes the ontology extension problem into three independent tasks. Each task takes a specific type of input (or ”query”), applies a pluggable suggestion algorithm, and produces a ranked list of candidates. Let us assume a set of classes 𝒞 \mathcal{C} , a set of relation types ℛ \mathcal{R} , and a set of data properties (attributes) 𝒜 \mathcal{A} that may be associated with classes. The ontology is composed of 1) a class hierarchy ( c , is-a , p ) ∈ 𝒞 × 𝒞 (c,\text{is-a},p)\in\mathcal{C}\times\mathcal{C} , 2) triples of relations ( c i , r , c j ) ∈ 𝒞 × ℛ × 𝒞 (c{i},r,c{j})\in\mathcal{C}\times\mathcal{R}\times\mathcal{C} , and 3) pairs of attribute associations ( c , a ) ∈ 𝒞 × 𝒜 (c,a)\in\mathcal{C}\times\mathcal{A} .

   Task 1 — Parent class prediction. Given a query of a class name c ∉ 𝒞 c\notin\mathcal{C} , rank all existing classes p ∈ 𝒞 p\in\mathcal{C} by their suitability as parent ( c , is-a , p ) (c,\text{is-a},p) in the hierarchy and present the top- k k suggestions. Any algorithm that can score the semantic fit of a subclass relation between a candidate term and existing ontology classes can serve as the suggestion engine.

   Task 2 — Relation type prediction. Given a query of two classes c i , c j ∈ 𝒞 c{i},c{j}\in\mathcal{C} , rank all candidate relation types r ∈ ℛ r\in\mathcal{R} by the plausibility of the triple ( c i , r , c j ) (c{i},r,c{j}) . The framework evaluates both directions, ( c i , r , c j ) (c{i},r,c{j}) and ( c j , r , c i ) (c{j},r,c{i}) , and returns a ranked list of the directed relation types. Any algorithm that can score the plausibility of a (subject, predicate, object) triple can be plugged into this task.

   Task 3 — Data property assignment. Given a query of a data property a ∈ 𝒜 a\in\mathcal{A} with inferred data type τ \tau and a set of candidate owner classes { c 1 , … , c m } ⊂ 𝒞 {c{1},\ldots,c{m}}\subset\mathcal{C} , predict which class c ∗ c^{} from the candidates should own data property a a , i.e., the plausibility of the association pair ( c ∗ , a ) (c^{},a) . The data type τ \tau may be inferred from the metric’s configuration block if this context was available, e.g., boolean from true/false target values, numeric from thresholds. Any algorithm capable of scoring the association between a property and a set of candidate classes can be used.

   3.3 Context Enrichment

   Depending on the richness of the input data, the framework can optionally enrich suggestion inputs with context beyond bare term names. We distinguish between two sources of additional context:

   • Ontology-derived context: Annotations (e.g., rdfs:comment , rdfs:label ) attached to existing ontology classes and properties, which provide definitional context.

   • Metric-derived context: Descriptions, comments, configuration values, and other fields from the metric definition that provide semantic grounding for the referenced concepts.

   Context enrichment is optional and configurable per task, allowing systematic comparison of how much additional signal operational artefacts provide beyond ontology structure alone.

   4 Evaluation

   This section presents the evaluation of COntExt. We first state the research questions that guide the evaluation (Section 4.1 ), then describe the ontologies and metric corpus used for evaluation (Sections 4.2 – 4.3 ), define the evaluation protocols for each extension task (Section 4.4 ), introduce the algorithms used for each task (Section 4.5 ) and report results organized by research question (Section 4.6 ).

   Table 1: Ontologies used in the evaluation.

   Name Domain Classes Relations Relation Types Classes with Attributes Hierarchy Depth

   Pizza Educational 86 170 3 0 6

   FIBO BE Finance 248 87 43 3 6

   SAREF ener IoT (Energy) 90 117 87 31 4

   JRC Cybersecurity 204 1350 9 7 2

   CSO sec Cybersecurity 1055 2544 2 0 8

   TAC Cybersecurity 176 94 62 382 6

   CertGraph Cybersecurity 264 161 20 104 6

   4.1 Research Questions

   RQ1 — Algorithm comparison.

   How do different algorithms compare across the three extension tasks? This question evaluates multiple algorithms for each task on all ontologies.

   RQ2 — Context enrichment.

   Does enriching algorithm inputs with ontology annotations and metric-derived context (descriptions, comments, configuration values) improve suggestion quality over baselines that only use term names as linguistic features? How does the metric-derived context compare to the ontology context?

   These questions are evaluated on all three tasks using the applicable datasets and algorithms for each.

   4.2 Ontologies

   We evaluate the framework on seven ontologies that vary in size, annotation richness, and domain, with a focus on the cybersecurity domain. Table 1 summarizes their key characteristics.

   Pizza 2 2 2 https://protege.stanford.edu/ontologies/pizza/pizza.owl is a small ontology intended for educational purposes about OWL/RDF ontologies. FIBO 3 3 3 https://edmconnect.edmcouncil.org/okgspecialinterestgroup/resources-sig-link/resources-sig-link-fibo-products-download (Financial Industry Business Ontology) [ Bennett, 2013 ] is a formal ontology that provides a common vocabulary for financial contracts and related concepts, comprising several sub-ontologies. We use the sub-ontology for Business Entities (BE) domain FIBO BE , which defines business concepts that are used for data governance, interoperability, and in regulatory reporting about business entities. The Smart Applications REFerence (SAREF) 4 4 4 https://saref.etsi.org/ [ García-Castro et al., 2023 ] is intended for interoperability between different components among various sectors in the Internet of Things (IoT). We take the subset ontology SAREF ener , which is the extension for the Energy domain. JRC 5 5 5 https://cybersecurity-atlas.ec.europa.eu/cybersecurity-taxonomy is a cybersecurity taxonomy from the European Commission’s Joint Research Centre. CSO 6 6 6 https://cso.kmi.open.ac.uk/home [ Salatino et al., 2019 ] is a large-scale ontology of research areas that was automatically generated from the Rexplore dataset, which consists of about 16 million publications. Threat Actor Context (TAC) 7 7 7 https://github.com/oasis-tcs/tac-ontology ontology is a semantic representation of cyber threat intelligence built on top of the STIX 2.1 standard to enable interoperability across different threat-intelligence-relevant information sources and technological solutions. Finally, CertGraph 8 8 8 https://github.com/Cybersecurity-Certification-Hub/security-metrics [ Schöberl et al., 2024 ] enables the automated assessment of certification-relevant security metrics by providing a semantic representation of security concepts, relationships, and evidence sources. CertGraph is also associated with a catalogue of security metrics, offering a metric-rich use case for the evaluation of metric-derived ontology extension.

   In our reference implementation, ontologies are parsed directly from OWL/XML with the lxml library. We also implement light per-source converters (under data_transformation/ ) normalising other formats such as Pizza, SAREF, FIBO, and CSO into the same OWX representation before parsing.

   Listing 1: Metric example from CertGraph security metrics. ⬇

   name : TransportEncryptionEnabled

   description : This rule assesses whether a [ Resource ] has [ TransportEncryption ] [ p1 : enabled ] correctly configured .

   category : TransportEncryption

   version : "v1"

   comments : Transport encryption is a standard practice to keep sensitive data confidential when it is transmitted .

   configuration :

   p1 :

   operator : "=="

   targetValue : True

   4.3 Metric Corpus

   The metric corpus consists of structured cybersecurity metric definitions associated with the CertGraph ontology. The corpus spans 12 security categories (e.g., AI Security, Identity Management, Transport Encryption) and contains 64 individual metric definitions in YAML format. Each metric references domain concepts through its description, configuration block, and optional comments. This corpus is used exclusively for RQ2 to test whether metric-derived context improves suggestion quality. References are tagged inline within the description field — bare [Term] for classes and [pN:propertyName] for properties — and extracted with a single regular expression. Listing 1 shows an example for a metric associated with CertGraph.

   4.4 Evaluation Protocols

   Each extension task is evaluated using a leave-one-out protocol that masks known ontology structure and measures whether the framework can recover it. This approach avoids the need for manually labelled ground truth and allows evaluation on any ontology. For RQ2, only the concepts, relations, and properties that are mentioned in the metric files are considered for evaluation.

   Parent class prediction (Task 1). For each class c c in the ontology with a known parent p p , we temporarily remove c c from the hierarchy and ask the suggestion engine to rank all remaining classes by their suitability as parent of c c . We report:

   • Mean Reciprocal Rank (MRR): the average of 1 / rank 1/\text{rank} of the correct parent across all test cases.

   • Hits@ k k ( k ∈ { 1 , 3 , 5 , 10 } k\in{1,3,5,10} ): the proportion of test cases where the correct parent appears in the top k k suggestions.

   Relation type prediction (Task 2). For each object relation axiom ( d , r , g ) (d,r,g) in the ontology, where d d is the domain class, r r is the relation type, and g g is the range class, we remove the axiom and ask the suggestion engine to rank all candidate relation types for the query pair ( d , g ) (d,g) . We report MRR and Hits@ k k as above, with the candidate set being the full inventory of relation types in the ontology.

   Data property assignment (Task 3). For each data property axiom ( c , a ) (c,a) — where class c c owns data property (attribute) a a — we construct a binary classification task. We select a neighbour class c ′ c^{\prime} that is structurally related to c c (via shared object properties or adjacency in the hierarchy) but does not own a a . The suggestion engine must identify the correct owner from the candidate set { c , c ′ } {c,c^{\prime}} . We report accuracy over all non-trivial cases (i.e., those where a valid neighbour distractor exists). The neighbour-based distractor selection is deliberately harder than random-negative sampling: because c ′ c^{\prime} is structurally close to c c , the task requires the algorithm to distinguish between conceptually related classes rather than trivially dissimilar ones.

   Significance testing. To separate genuine differences between algorithms from sampling and training noise, we compare any two algorithms on the same task with a test paired at the level of individual masked cases: a two-sided approximate-randomization (permutation) test, Holm–Bonferroni-corrected across the ontologies in the comparison, together with a per-seed sign-consistency check that exposes training (seed) variance. The per-case score is the reciprocal rank for the ranking tasks (parent class prediction and relation type prediction) and the accuracy for data property assignment. We label a difference robust only when the Holm-adjusted p-value is below 0.05 0.05 and the sign of the per-case mean difference is consistent across every training seed; otherwise the gap is reported as a statistical tie or as within training noise.

   4.5 Algorithms and Configurations

   For each task, we evaluate a set of supervised state-of-the-art methods. To evaluate context enrichment, we also implement unsupervised heuristics on top of pre-trained language models, such as BERT and SentenceTransformer, that have the capacity of including additional context. The context is the prose text existing either in the ontology annotations associated with the class, e.g., rdfs:comment , or in the textual description of the metric file corresponding to the query. We evaluate all algorithms for RQ1 (algorithm comparison), while for RQ2 (context enrichment), we only evaluate heuristics that support context enrichment. The adaptation of existing supervised methods is beyond the scope of this current work.

   4.5.1 Task 1 — Parent class prediction

   BERT Fine-tuning [ Liu et al., 2020 ] . A BERT model is fine-tuned as a binary classifier on (child, parent) concept pairs from the ontology hierarchy. Positive pairs are real parent-child relationships; negatives are structurally similar non-parent nodes. At inference, all candidates are scored by the classifier’s IS-A probability. We use this method as an example for language-model-based parent class prediction – no context enrichment is adapted for this method .

   TaxoExpan [ Shen et al., 2020 ] . A position-enhanced Graph Attention Network encodes local ego-graphs around each candidate parent position. Each ego-graph contains the candidate node, its parent, and its children, with learned position embeddings distinguishing these roles. A log-bilinear matching model scores the compatibility between the ego-graph encoding and the query concept embedding. The model is trained with InfoNCE contrastive loss. This method represents an example of GNN-based parent class prediction – no context enrichment .

   Child aggregation of SentenceTransformer embedding (ChildAgg). All ontology class names are embedded into dense vectors using a sentence-transformer [ Reimers and Gurevych, 2019 ] model – we use all-MiniLM-L6-v2 model. For each class, we replace its embedding with the mean of its own and its children’s embeddings. For a candidate class, the framework computes cosine similarity against all existing class embeddings and returns the top- k k most similar classes as parent suggestions. We develop this heuristic to be able to enrich it with linguistic context extracted from metrics and ontology annotations. To enrich this method, we append the textual context to the class name before encoding.

   Table 2: RQ1 — Parent class prediction: algorithm comparison across ontologies. Mean ± \pm std over 5 random seeds. Best score per ontology is in boldface, and statistically significant wins are underlined.

   Ontology Algorithm MRR Hits@1 Hits@3 Hits@5 Hits@10

   Pizza BERT 0.38 ± 0.09 0.38{\pm 0.09} 0.28 ± 0.06 0.28{\pm 0.06} 0.41 ± 0.15 0.41{\pm 0.15} 0.49 ± 0.17 0.49{\pm 0.17} 0.67 ± 0.14 0.67_{\pm 0.14}

   Pizza TaxoExpan 0.56 ± 0.06 0.56{\pm 0.06} 0.47 ± 0.06 0.47{\pm 0.06} 0.64 ± 0.07 0.64{\pm 0.07} 0.68 ± 0.08 0.68{\pm 0.08} 0.76 ± 0.08 0.76_{\pm 0.08}

   Pizza ChildAgg 0.68 ± 0.07 \mathbf{0.68{\pm 0.07}} 0.51 ± 0.09 \mathbf{0.51{\pm 0.09}} 0.82 ± 0.06 \mathbf{0.82{\pm 0.06}} 0.94 ± 0.05 \mathbf{0.94{\pm 0.05}} 0.96 ± 0.05 \mathbf{0.96_{\pm 0.05}}

   FIBO BE BERT 0.04 ± 0.02 0.04{\pm 0.02} 0.01 ± 0.02 0.01{\pm 0.02} 0.04 ± 0.02 0.04{\pm 0.02} 0.09 ± 0.04 0.09{\pm 0.04} 0.15 ± 0.06 0.15_{\pm 0.06}

   FIBO BE TaxoExpan 0.20 ± 0.04 0.20{\pm 0.04} 0.10 ± 0.01 0.10{\pm 0.01} 0.25 ± 0.06 0.25{\pm 0.06} 0.33 ± 0.07 0.33{\pm 0.07} 0.44 ± 0.07 0.44_{\pm 0.07}

   FIBO BE ChildAgg 0.26 ± 0.03 \mathbf{0.26{\pm 0.03}} 0.12 ± 0.03 \mathbf{0.12{\pm 0.03}} 0.34 ± 0.07 \mathbf{0.34{\pm 0.07}} 0.46 ± 0.08 \mathbf{0.46{\pm 0.08}} 0.63 ± 0.05 \mathbf{0.63_{\pm 0.05}}

   SAREF ener BERT 0.64 ± 0.11 0.64{\pm 0.11} 0.60 ± 0.12 \mathbf{0.60{\pm 0.12}} 0.64 ± 0.10 0.64{\pm 0.10} 0.70 ± 0.12 0.70{\pm 0.12} 0.76 ± 0.14 0.76_{\pm 0.14}

   SAREF ener TaxoExpan 0.66 ± 0.09 \mathbf{0.66{\pm 0.09}} 0.53 ± 0.15 0.53{\pm 0.15} 0.76 ± 0.06 \mathbf{0.76{\pm 0.06}} 0.82 ± 0.06 \mathbf{0.82{\pm 0.06}} 0.87 ± 0.06 0.87_{\pm 0.06}

   SAREF ener ChildAgg 0.48 ± 0.11 0.48{\pm 0.11} 0.31 ± 0.13 0.31{\pm 0.13} 0.57 ± 0.11 0.57{\pm 0.11} 0.72 ± 0.08 0.72{\pm 0.08} 0.93 ± 0.06 \mathbf{0.93_{\pm 0.06}}

   JRC BERT 0.17 ± 0.01 0.17{\pm 0.01} 0.06 ± 0.03 0.06{\pm 0.03} 0.24 ± 0.07 0.24{\pm 0.07} 0.34 ± 0.06 0.34{\pm 0.06} 0.44 ± 0.08 0.44_{\pm 0.08}

   JRC TaxoExpan 0.32 ± 0.03 0.32{\pm 0.03} 0.22 ± 0.07 0.22{\pm 0.07} 0.40 ± 0.04 0.40{\pm 0.04} 0.44 ± 0.04 0.44{\pm 0.04} 0.47 ± 0.06 0.47_{\pm 0.06}

   JRC ChildAgg 0.47 ± 0.03 \mathbf{0.47{\pm 0.03}} 0.29 ± 0.06 \mathbf{0.29{\pm 0.06}} 0.59 ± 0.05 \mathbf{0.59{\pm 0.05}} 0.72 ± 0.03 \mathbf{0.72{\pm 0.03}} 0.85 ± 0.04 \mathbf{0.85_{\pm 0.04}}

   CSO sec BERT 0.06 ± 0.03 0.06{\pm 0.03} 0.03 ± 0.02 0.03{\pm 0.02} 0.06 ± 0.03 0.06{\pm 0.03} 0.08 ± 0.04 0.08{\pm 0.04} 0.15 ± 0.06 0.15_{\pm 0.06}

   CSO sec TaxoExpan 0.32 ± 0.02 \mathbf{0.32{\pm 0.02}} 0.18 ± 0.03 \mathbf{0.18{\pm 0.03}} 0.41 ± 0.01 \mathbf{0.41{\pm 0.01}} 0.50 ± 0.01 \mathbf{0.50{\pm 0.01}} 0.63 ± 0.03 \mathbf{0.63_{\pm 0.03}}

   CSO sec ChildAgg 0.20 ± 0.03 0.20{\pm 0.03} 0.09 ± 0.02 0.09{\pm 0.02} 0.24 ± 0.04 0.24{\pm 0.04} 0.36 ± 0.03 0.36{\pm 0.03} 0.52 ± 0.02 0.52_{\pm 0.02}

   TAC BERT 0.18 ± 0.05 0.18{\pm 0.05} 0.07 ± 0.05 0.07{\pm 0.05} 0.22 ± 0.14 0.22{\pm 0.14} 0.29 ± 0.12 0.29{\pm 0.12} 0.49 ± 0.05 0.49_{\pm 0.05}

   TAC TaxoExpan 0.44 ± 0.09 0.44{\pm 0.09} 0.31 ± 0.10 0.31{\pm 0.10} 0.55 ± 0.06 0.55{\pm 0.06} 0.66 ± 0.08 0.66{\pm 0.08} 0.70 ± 0.08 0.70_{\pm 0.08}

   TAC ChildAgg 0.52 ± 0.05 \mathbf{0.52{\pm 0.05}} 0.35 ± 0.08 \mathbf{0.35{\pm 0.08}} 0.63 ± 0.10 \mathbf{0.63{\pm 0.10}} 0.74 ± 0.06 \mathbf{0.74{\pm 0.06}} 0.86 ± 0.02 \mathbf{0.86_{\pm 0.02}}

   CertGraph BERT 0.12 ± 0.04 0.12{\pm 0.04} 0.08 ± 0.03 0.08{\pm 0.03} 0.14 ± 0.06 0.14{\pm 0.06} 0.16 ± 0.04 0.16{\pm 0.04} 0.24 ± 0.07 0.24_{\pm 0.07}

   CertGraph TaxoExpan 0.32 ± 0.06 0.32{\pm 0.06} 0.18 ± 0.05 0.18{\pm 0.05} 0.40 ± 0.08 0.40{\pm 0.08} 0.48 ± 0.06 0.48{\pm 0.06} 0.64 ± 0.04 0.64_{\pm 0.04}

   CertGraph ChildAgg 0.38 ± 0.03 \mathbf{0.38{\pm 0.03}} 0.24 ± 0.02 \mathbf{0.24{\pm 0.02}} 0.45 ± 0.06 \mathbf{0.45{\pm 0.06}} 0.61 ± 0.05 \mathbf{0.61{\pm 0.05}} 0.72 ± 0.07 \mathbf{0.72_{\pm 0.07}}

   4.5.2 Task 2 — Relation type prediction

   BertConvE [ Liu et al., 2022 ] . A small BERT model is trained from scratch on random walks extracted from the ontology’s graph structure. Each entity and relation is a single token in a custom vocabulary. At inference, the relation position in “ c i c{i} [MASK] c j c{j} ” is predicted via masked language modelling. BertConvE is an advanced knwoledge graph completion method that uses masked language model (MLM)-like training, but it is merely structural as the nodes are thought of as tokens. Context enrichment is not applicable here.

   TransE [ Bordes et al., 2013 ] . A translating-embedding model learns entity and relation vectors from the ontology’s existing triples such that 𝐡 + 𝐫 ≈ 𝐭 \mathbf{h}+\mathbf{r}\approx\mathbf{t} for valid triples ( h , r , t ) (h,r,t) . For a class pair, each candidate property is scored by translation distance: score ​ ( h , r , t ) = 1 / ( 1 + ‖ 𝐡 + 𝐫 − 𝐭 ‖ ) \text{score}(h,r,t)=1/(1+|\mathbf{h}+\mathbf{r}-\mathbf{t}|) , evaluated in both directions. Variants include random versus sentence-transformer embedding initialization and whether hierarchy triples are included in training. While TransE is a classic structure-based knowledge graph completion method, it still has the capacity of including surface names through initialization with sentence embedding. However, the method is not adapted for context enrichment .

   Pretrained MLM prompting. For each class pair ( c i , c j ) (c{i},c{j}) , the framework constructs sentences in both directions (“ c i c{i} [MASK] c j c{j} ” and “ c j c{j} [MASK] c i c{i} ”) and scores each candidate relation by its probability at the masked position using distilbert-base-uncased pretrained MLM. Multi-token property names are handled by averaging subword probabilities. This heuristic we develop supports context enrichment: metric descriptions or comments can be prepended to the template.

   4.5.3 Task 3 — Data Property Assignment

   We re-use Task 2 models (TransE and BertConvE) by augmenting their training triples with data-property axioms encoded as ( c , a , τ ) (c,a,\tau) , where each XSD datatype τ \tau (e.g. xsd:integer ) becomes a synthetic tail entity shared across all properties of that datatype. For BertConvE the xsd-type tails are marked walk-terminating so they do not act as transit hubs in the random walks. At inference, the head slot is masked (“[MASK] a a τ \tau ”) and candidate classes are ranked by translation distance (TransE) or masked-token probability at the head position (BertConvE) – no context enrichment is used for TransE or BertConvE .

   Pretrained MLM prompting. A [MASK] is placed in a template “[MASK] can have {property}” by default. Metric context that provides target values is used to modify the template as “[MASK] is {property}” for booleans, or “The {property} of [MASK] is {targetValue}”. Candidates are scored by the average MLM probability of their subword tokens at the mask using distilbert-base-uncased pretrained model. Metric descriptions or comments can be prepended to the template for context enrichment.

   Table 3: RQ1 — Relation type prediction: algorithm comparison across ontologies. Mean ± \pm std over 5 random seeds. Best score per ontology is in boldface, and statistically significant wins are underlined.

   Ontology Algorithm MRR Hits@1 Hits@3 Hits@5 Hits@10

   Pizza BertConvE 0.73 ± 0.09 \mathbf{0.73{\pm 0.09}} 0.49 ± 0.18 \mathbf{0.49{\pm 0.18}} 0.98 ± 0.02 \mathbf{0.98{\pm 0.02}} 0.99 ± 0.01 \mathbf{0.99{\pm 0.01}} 1.00 ± 0.00 \mathbf{1.00_{\pm 0.00}}

   Pizza TransE (Random Init) 0.47 ± 0.11 0.47{\pm 0.11} 0.23 ± 0.13 0.23{\pm 0.13} 0.63 ± 0.19 0.63{\pm 0.19} 0.95 ± 0.03 0.95{\pm 0.03} 1.00 ± 0.00 \mathbf{1.00_{\pm 0.00}}

   Pizza TransE (ST init) 0.35 ± 0.11 0.35{\pm 0.11} 0.10 ± 0.11 0.10{\pm 0.11} 0.40 ± 0.17 0.40{\pm 0.17} 0.76 ± 0.21 0.76{\pm 0.21} 1.00 ± 0.00 \mathbf{1.00_{\pm 0.00}}

   Pizza MLM 0.45 ± 0.03 0.45{\pm 0.03} 0.19 ± 0.04 0.19{\pm 0.04} 0.66 ± 0.11 0.66{\pm 0.11} 0.94 ± 0.02 0.94{\pm 0.02} 1.00 ± 0.00 \mathbf{1.00_{\pm 0.00}}

   FIBO BE BertConvE 0.24 ± 0.13 0.24{\pm 0.13} 0.12 ± 0.16 0.12{\pm 0.16} 0.28 ± 0.20 \mathbf{0.28{\pm 0.20}} 0.40 ± 0.18 \mathbf{0.40{\pm 0.18}} 0.48 ± 0.16 \mathbf{0.48_{\pm 0.16}}

   FIBO BE TransE (Random Init) 0.15 ± 0.09 0.15{\pm 0.09} 0.04 ± 0.08 0.04{\pm 0.08} 0.12 ± 0.16 0.12{\pm 0.16} 0.24 ± 0.20 0.24{\pm 0.20} 0.40 ± 0.25 0.40_{\pm 0.25}

   FIBO BE TransE (ST init) 0.25 ± 0.09 \mathbf{0.25{\pm 0.09}} 0.16 ± 0.08 \mathbf{0.16{\pm 0.08}} 0.24 ± 0.15 0.24{\pm 0.15} 0.28 ± 0.16 0.28{\pm 0.16} 0.36 ± 0.15 0.36_{\pm 0.15}

   FIBO BE MLM 0.21 ± 0.10 0.21{\pm 0.10} 0.12 ± 0.10 0.12{\pm 0.10} 0.12 ± 0.10 0.12{\pm 0.10} 0.24 ± 0.15 0.24{\pm 0.15} 0.48 ± 0.10 \mathbf{0.48_{\pm 0.10}}

   SAREF ener BertConvE 0.14 ± 0.04 0.14{\pm 0.04} 0.07 ± 0.04 0.07{\pm 0.04} 0.18 ± 0.07 0.18{\pm 0.07} 0.23 ± 0.08 0.23{\pm 0.08} 0.30 ± 0.06 0.30_{\pm 0.06}

   SAREF ener TransE (Random Init) 0.02 ± 0.01 0.02{\pm 0.01} 0.00 ± 0.00 0.00{\pm 0.00} 0.02 ± 0.02 0.02{\pm 0.02} 0.02 ± 0.02 0.02{\pm 0.02} 0.02 ± 0.02 0.02_{\pm 0.02}

   SAREF ener TransE (ST init) 0.31 ± 0.04 \mathbf{0.31{\pm 0.04}} 0.21 ± 0.06 \mathbf{0.21{\pm 0.06}} 0.36 ± 0.05 \mathbf{0.36{\pm 0.05}} 0.43 ± 0.07 \mathbf{0.43{\pm 0.07}} 0.51 ± 0.07 \mathbf{0.51_{\pm 0.07}}

   SAREF ener MLM 0.12 ± 0.02 0.12{\pm 0.02} 0.05 ± 0.03 0.05{\pm 0.03} 0.10 ± 0.03 0.10{\pm 0.03} 0.21 ± 0.05 0.21{\pm 0.05} 0.30 ± 0.04 0.30_{\pm 0.04}

   JRC BertConvE 0.26 ± 0.03 0.26{\pm 0.03} 0.04 ± 0.04 0.04{\pm 0.04} 0.25 ± 0.05 0.25{\pm 0.05} 0.52 ± 0.06 0.52{\pm 0.06} 0.96 ± 0.01 \mathbf{0.96_{\pm 0.01}}

   JRC TransE (Random Init) 0.16 ± 0.02 0.16{\pm 0.02} 0.02 ± 0.01 0.02{\pm 0.01} 0.11 ± 0.03 0.11{\pm 0.03} 0.21 ± 0.05 0.21{\pm 0.05} 0.55 ± 0.07 0.55_{\pm 0.07}

   JRC TransE (ST init) 0.16 ± 0.06 0.16{\pm 0.06} 0.04 ± 0.04 0.04{\pm 0.04} 0.12 ± 0.10 0.12{\pm 0.10} 0.21 ± 0.12 0.21{\pm 0.12} 0.49 ± 0.15 0.49_{\pm 0.15}

   JRC MLM 0.38 ± 0.02 \mathbf{0.38{\pm 0.02}} 0.22 ± 0.02 \mathbf{0.22{\pm 0.02}} 0.44 ± 0.02 \mathbf{0.44{\pm 0.02}} 0.57 ± 0.02 \mathbf{0.57{\pm 0.02}} 0.69 ± 0.02 0.69_{\pm 0.02}

   CSO sec BertConvE 0.72 ± 0.01 \mathbf{0.72{\pm 0.01}} 0.46 ± 0.02 \mathbf{0.46{\pm 0.02}} 0.97 ± 0.01 \mathbf{0.97{\pm 0.01}} 1.00 ± 0.00 \mathbf{1.00{\pm 0.00}} 1.00 ± 0.00 \mathbf{1.00_{\pm 0.00}}

   CSO sec TransE (Random Init) 0.54 ± 0.02 0.54{\pm 0.02} 0.29 ± 0.03 0.29{\pm 0.03} 0.74 ± 0.05 0.74{\pm 0.05} 1.00 ± 0.00 \mathbf{1.00{\pm 0.00}} 1.00 ± 0.00 \mathbf{1.00_{\pm 0.00}}

   CSO sec TransE (ST init) 0.51 ± 0.02 0.51{\pm 0.02} 0.23 ± 0.01 0.23{\pm 0.01} 0.75 ± 0.08 0.75{\pm 0.08} 1.00 ± 0.00 \mathbf{1.00{\pm 0.00}} 1.00 ± 0.00 \mathbf{1.00_{\pm 0.00}}

   CSO sec MLM 0.52 ± 0.01 0.52{\pm 0.01} 0.25 ± 0.02 0.25{\pm 0.02} 0.75 ± 0.02 0.75{\pm 0.02} 1.00 ± 0.00 \mathbf{1.00{\pm 0.00}} 1.00 ± 0.00 \mathbf{1.00_{\pm 0.00}}

   TAC BertConvE 0.22 ± 0.05 0.22{\pm 0.05} 0.18 ± 0.05 0.18{\pm 0.05} 0.21 ± 0.06 0.21{\pm 0.06} 0.24 ± 0.05 0.24{\pm 0.05} 0.33 ± 0.08 0.33_{\pm 0.08}

   TAC TransE (Random Init) 0.02 ± 0.01 0.02{\pm 0.01} 0.00 ± 0.00 0.00{\pm 0.00} 0.00 ± 0.00 0.00{\pm 0.00} 0.02 ± 0.03 0.02{\pm 0.03} 0.03 ± 0.03 0.03_{\pm 0.03}

   TAC TransE (ST init) 0.29 ± 0.07 \mathbf{0.29{\pm 0.07}} 0.22 ± 0.08 \mathbf{0.22{\pm 0.08}} 0.33 ± 0.08 \mathbf{0.33{\pm 0.08}} 0.36 ± 0.05 \mathbf{0.36{\pm 0.05}} 0.38 ± 0.07 \mathbf{0.38_{\pm 0.07}}

   TAC MLM 0.20 ± 0.05 0.20{\pm 0.05} 0.12 ± 0.05 0.12{\pm 0.05} 0.18 ± 0.05 0.18{\pm 0.05} 0.27 ± 0.07 0.27{\pm 0.07} 0.37 ± 0.06 0.37_{\pm 0.06}

   CertGraph BertConvE 0.38 ± 0.05 \mathbf{0.38{\pm 0.05}} 0.17 ± 0.03 \mathbf{0.17{\pm 0.03}} 0.48 ± 0.07 \mathbf{0.48{\pm 0.07}} 0.65 ± 0.12 \mathbf{0.65{\pm 0.12}} 0.83 ± 0.06 \mathbf{0.83_{\pm 0.06}}

   CertGraph TransE (Random Init) 0.12 ± 0.01 0.12{\pm 0.01} 0.01 ± 0.01 0.01{\pm 0.01} 0.07 ± 0.04 0.07{\pm 0.04} 0.26 ± 0.08 0.26{\pm 0.08} 0.32 ± 0.07 0.32_{\pm 0.07}

   CertGraph TransE (ST init) 0.13 ± 0.06 0.13{\pm 0.06} 0.02 ± 0.03 0.02{\pm 0.03} 0.13 ± 0.08 0.13{\pm 0.08} 0.19 ± 0.12 0.19{\pm 0.12} 0.35 ± 0.17 0.35_{\pm 0.17}

   CertGraph MLM 0.19 ± 0.04 0.19{\pm 0.04} 0.10 ± 0.04 0.10{\pm 0.04} 0.15 ± 0.05 0.15{\pm 0.05} 0.18 ± 0.05 0.18{\pm 0.05} 0.37 ± 0.10 0.37_{\pm 0.10}

   4.6 Results

   4.6.1 RQ1 — Algorithm Comparison

   Task 1 results are presented in Table 2 on all datasets. Applying the paired significance test, only two results survive: ChildAgg outranks TaxoExpan on JRC, and TaxoExpan outranks ChilAggS on CSO sec . The remaining ontologies are statistical ties: Pizza, CertGraph and TAC, while the FIBO BE and SAREF ener flip sign across training seeds and therefore fall within TaxoExpan’s seed variance. The two robust outcomes track the structural signal available for TaxoExpan’s GNN. CSO sec is by far the largest ontology, where its learned ego-graph matching has both signal and candidate volume, whereas JRC, with only two-level hierarchy depth, does not offer meaningful ego-graphs, making ChildAgg’s frozen embeddings hard to beat.

   Table 4: RQ1 — Data property assignment: algorithm comparison across ontologies. Mean ± \pm std over 5 random seeds. Ontologies with no attributes are excluded. Best score per ontology is in boldface, and statistically significant wins are underlined.

   Ontology Algorithm Accuracy

   SAREF ener BertConvE 0.56 ± 0.03 0.56_{\pm 0.03}

   SAREF ener TransE (Random Init) 0.50 ± 0.05 0.50_{\pm 0.05}

   SAREF ener TransE (ST init) 0.47 ± 0.05 0.47_{\pm 0.05}

   SAREF ener MLM 0.64 ± 0.06 \mathbf{0.64_{\pm 0.06}}

   JRC BertConvE 0.99 ± 0.00 \mathbf{0.99_{\pm 0.00}}

   JRC TransE (Random Init) 0.52 ± 0.10 0.52_{\pm 0.10}

   JRC TransE (ST init) 0.96 ± 0.01 0.96_{\pm 0.01}

   JRC MLM 0.52 ± 0.01 0.52_{\pm 0.01}

   TAC BertConvE 0.51 ± 0.02 0.51_{\pm 0.02}

   TAC TransE (Random Init) 0.54 ± 0.02 0.54_{\pm 0.02}

   TAC TransE (ST init) 0.46 ± 0.03 0.46_{\pm 0.03}

   TAC MLM 0.62 ± 0.02 \mathbf{0.62_{\pm 0.02}}

   CertGraph BertConvE 0.59 ± 0.03 \mathbf{0.59_{\pm 0.03}}

   CertGraph TransE (Random Init) 0.53 ± 0.06 0.53_{\pm 0.06}

   CertGraph TransE (ST init) 0.50 ± 0.03 0.50_{\pm 0.03}

   CertGraph MLM 0.51 ± 0.02 0.51_{\pm 0.02}

   Table 5: RQ2 — Context enrichment of ChildAgg for parent class prediction (Task 1) on CertGraph.

   Context MRR Hits@1 Hits@3 Hits@5 Hits@10

   No context 0.49 0.44 0.51 0.58 0.60

   • Ontology comments 0.43 0.37 0.48 0.54 0.60

   • Metric description 0.34 0.25 0.38 0.48 0.53

   • Metric comment 0.29 0.16 0.42 0.46 0.52

   • Metric description + comment 0.32 0.20 0.42 0.49 0.53

   All context (metric + ontology) 0.34 0.23 0.44 0.48 0.52

   Table 6: RQ2 — Context enrichment of MLM prompting for relation type prediction: (Task 2) on CertGraph.

   Context MRR Hits@1 Hits@3 Hits@5 Hits@10

   No context 0.21 0.10 0.20 0.30 0.40

   • Ontology comments 0.21 0.10 0.20 0.40 0.50

   • Metric description 0.27 0.20 0.30 0.30 0.40

   • Metric comment 0.21 0.10 0.20 0.30 0.30

   • Metric description + comment 0.25 0.20 0.20 0.30 0.30

   All context (metric + ontology) 0.22 0.10 0.30 0.30 0.40

   Table 7: RQ2 — Context enrichment of MLM prompting for data property assignment (Task 3) on CertGraph.

   Context Accuracy

   No context 0.71

   • Ontology comments 0.64

   • Metric description 0.68

   • Metric comment 0.82

   • Metric description + comment 0.79

   All context (metric + ontology) 0.68

   Task 2 results shown in Table 3 show a significant outperformance of BertConvE in terms of MRR on Pizza, CSO sec , and CertGraph. Templated MLM wins on JRC, where the (domain, relation, range) triple reads as a natural English clause. TransE (ST init) results on FIBO BE , SAREF ener , and TAC are statistical ties. The randomly-initialized TransE is rarely competitive, suggesting that surface lexical information are more useful than pure structural training at these graph sizes. CSO sec saturates Hits@5 and Hits@10 and Pizza saturates Hits@10 due to the low number of relation types: two types for CSO and three for Pizza, both bidirectional.

   Task 3 results, shown in Table 4 , show two significant results: BertConvE outperform the rest on JRC and MLM propmting outperforms the rest on TAC. BertConvE on CertGraph falls within the training noise. The JRC result stands out, as BertConvE reaches 0.99 0.99 accuracy while both TransE variants and MLM hover around the 0.50 0.50 random baseline on the same ontology. Since Pizza and CSO sec have no attributes, and FIBO BE only has three classes with attributes, they are excluded from this experiment.

   4.6.2 RQ2 — Context Enrichment

   To answer the context enrichment question, we apply algorithms, which are capable of incorporating external context into their predictions, that is ChildAgg for Task 1 (Table 5 ) and MLM prompting for both Task 2 (Table 6 ) and Task 3 (Table 7 ). As all algorithms are in inference mode and do not require training, there is no setup for multiple random seeds. To focus on the contribution of ontology and metric context, we limit the test set in this experiment to the classes and properties mentioned in the metric catalogue associated with CertGraph – resulting in 81 cases for Task 1, 10 cases for Task 2, and 28 cases for Task 3. For each task, we evaluate the respective method with no context, with ontology context represented by rdfs:comment elements, and with metric-driven context represented by both the description and comment in the metric file.

   Task 1: Table 5 shows that additional context does not increase the score of ChildAgg on Task 1, as no context achieves an MRR of 0.49 0.49 . However, the MRR drop with the ontology-context ( − 6 -6 pp) is smaller than that with the metric context ( − 15 . . − 20 -15..-20 pp).

   Task 2: Table 6 shows that the metric-driven context increases the score significantly for Tasks 2 with an MRR gain of 6 6 pp, though the ontology-driven context achieves better Hits@5 and Hits@10.

   Task 3: In Table 7 , the same pattern repeats with the metric comment alone lifting the accuracy from 0.71 0.71 to 0.82 0.82 ( + 11 +11 pp). Ontology comments appear to have and a mildly harmful effect ( − 7 -7 pp) for Task 3. We discuss these results and their implications in the next section.

   5 Discussion

   5.1 Implications

   Structured metric catalogues are an underexploited input modality. Prior ontology-extension work mostly draws on ontology structure [ Shen et al., 2020 ] and external natural-language documentation [ Sanagavarapu et al., 2022 ] . Structured metric definitions provide an independent text source that boosts property and relation prediction scores on CertGraph in comparison to bare class names. The RQ2 results shows a 6 6 pp MRR improvement on Task 2 ( 0.21 → 0.27 0.21\to 0.27 ) and a + 11 +11 pp Task 3 accuracy lift ( 0.71 → 0.82 0.71\to 0.82 ) once metric description and comment are added. These results highlight the benefit of this input modality as a context for language-based models for ontology extension.

   More context is not universally beneficial. The same metric prose that helps Task 2 and Task 3 hurts parent class prediction in Task 1 (MRR 0.49 → 0.34 0.49\to 0.34 , Δ = − 0.15 \Delta=-0.15 ). We hypothesize that the quality of the added context plays a major role here. In particular, the text to be expected in metrics associated with CertGraph usually describes the relation between two or more classes and how their properties should be configured. This context aligns with the MLM prompt for Tasks 2 and 3. However, this description does not align with Task 1, where a class-level context could be more beneficial. In a verification experiment, we measure the cosine similarity between the query class ST-embedding and its aggregate siblings embedding, which averages at 0.533 with no context. Appending context shifts the similarity down to 0.287 for metric description, to 0.383 for metric comments and to 0.524 for ontology comments. The farther a query’s embedding from its ground-truth aggregate embedding, the less likely the true parent will be recommended. This aligns with the MRR reduction caused by the context on Task 1 (Table 5 ).

   Practical low-friction industry adoption. organizations already maintain operational metric catalogues in structured form (YAML, JSON, RDF). COntExt makes these immediately reusable as ontology-extension inputs with no additional annotation effort. This is particularly beneficial in the cybersecurity field, where adopting security metrics has been receiving growing attention. The way the context is extracted and integrated can be easily configured within this framework.

   5.2 Limitations

   Single ontology for RQ2. The metric-context findings rest on a single (ontology, metric corpus) pair, CertGraph and its cybersecurity-certification metric catalogue, because no other ontology in our evaluation suite is shipped with a paired metric corpus of comparable structure. Replicating the metric-enrichment pattern on another domain pair is necessary to argue that the effect generalizes beyond CertGraph’s particular YAML schema and prose style.

   Metric context not extended to structural methods. The RQ2 comparison evaluates metric description and comment with text-template scorers only, MLM and ChildAgg. The structural methods, TransE, BertConvE, are absent because they consume tokenized triples rather than free-form prose and do not natively expose a slot for auxiliary text. Adapting such structural methods to ingest metric content would require separate research efforts.

   No large-language-model baseline. As our work aims to exploit operational metrics efficiently, we do not include LLMs in our algorithm choices despite their known effectiveness. While some previous work suggests that LLMs still lag behind for ontological consistency and they require more validation [ Kollapally et al., 2025 , Dong et al., 2024 ] , evaluating LLMs with metrics-driven context would still be worth investigating.

   6 Conclusion

   In this paper, we have introduced an algorithm-agnostic context-aware framework, COntExt, which leverages operational metrics and other input modalities as context for the ontology extension task. Our evaluation shows that operational metrics provide viable context to the ontology extension task, demonstrating a significant improvement over ontology-driven context for relation type prediction and data property assignment tasks. Organizations can use this framework to support their ontology maintenance, with the ability to harness relevant context, such as metrics catalogues and KPIs. Future work will develop tailored algorithms for metrics-oriented ontology extension as well as a comprehensive user study involving domain experts to evaluate the efficiency and utility of COntExt framework for semi-automated ontology extension.

   Acknowledgments

   This work was funded by the Horizon Europe project EMERALD, grant agreement ID 101120688. We thank Mark Kröll for insightful discussions and valuable feedback on this work.

   Generative AI use. We have used Anthropic’s Claude Code [ Anthropic, 2026 ] to write the python scripts according to our experimental design. All the AI-generated code was thoroughly reviewed by the corresponding author at every step. We have also used Claude Code to rewrite parts of the introduction (Section 1 ) and to formalize the descriptions of the framework (Section 3 ) and the evaluation setup (Sections 4.4 – 4.5 ). AI-generated text was reviewed and often significantly changed by the authors.