Methodological Exploration of Ontology Generation with a Dedicated Large Language Model

Abstract

Ontologies are essential tools for representing, organizing, and sharing knowledge across various domains. This study presents a methodology for ontology construction supported by large language models (LLMs), with an initial application in the automotive sector. Specifically, a user preference ontology for adaptive interfaces in autonomous machines was developed using ChatGPT-4o. Based on this case study, the results were generalized into a reusable methodology. The proposed workflow integrates classical ontology engineering methodologies with the generative and analytical capabilities of LLMs. Each phase follows well-established steps: domain definition, term elicitation, class hierarchy construction, property specification, formalization, population, and validation. A key innovation of this approach is the use of a guiding table that translates domain knowledge into structured prompts, ensuring consistency across iterative interactions with the LLM. Human experts play a continuous role throughout the process, refining definitions, resolving ambiguities, and validating outputs. The ontology was evaluated in terms of logical consistency, structural properties, semantic accuracy, and inferential completeness, confirming its correctness and coherence. Additional validation through SPARQL queries demonstrated its reasoning capabilities. This methodology is generalizable to other domains, if domain experts adapt the guiding table to the specific context. Despite the support provided by LLMs, domain expertise remains essential to guarantee conceptual rigor and practical relevance.

1. Introduction

Ontologies formalize knowledge representation and facilitate interoperability across various domains. Specifically, they serve as tools for formalizing the structure of reality within epistemological frameworks. Introduced to artificial intelligence (AI) by McCarthy [1], ontologies gained technical precision through Gruber’s [2] definition as “agreements on shared conceptualizations”. Davis et al. [3] emphasized the structural role in configuring knowledge through concepts and relationships, while Neches et al. [4] highlighted their capacity for knowledge reuse in data-driven systems [5].

However, ontologies face theoretical and practical limitations. Davis et al. [3] demonstrated that formalization choices affect representational neutrality. Guarino [6] and Guarino et al. [7] identified excessive simplification in formal logic, exacerbated by conflating logical and ontological structures. Guarino criticized the so-called “phantology”—the fallacy of treating ontological categories merely as logical predicates, thereby stripping them of their semantic content and reducing ontology to a purely syntactic exercise. Additionally, distinguishing between sortals (substance identifiers) and non-sortals (property characterizations) lacks universal criteria [6]. The author distinguished between sortals that identify substances and non-sortals that express characterizations; yet the challenge of establishing universal criteria for this distinction remains unresolved. Finally, Guarino and Giaretta [7] highlighted that the semantic quality of an ontology depends on the syntax adopted to formalize it, with the consequence that the structure of the language used can influence—and even distort—the reality representation [5].

Large language models (LLMs) offer novel approaches to ontology construction by enabling dynamic knowledge representation and implicit class inference, facilitating discovery of emergent ontological categories. LLMs can mitigate excessive simplification through context-sensitive, nuanced representations unconstrained by predetermined schemas.

Despite these advantages, LLMs cannot replace human oversight due to hallucination phenomena—generating inaccurate information. Reliable ontology development requires human-in-the-loop validation, where human intervention verifies, corrects, and integrates LLM-generated knowledge to ensure consistency, reliability, and accurate reality representation.

We employed ChatGPT-4o to support ontology construction in the automotive domain, focusing on adaptive interfaces for highly autonomous vehicles (HAVs). The resulting ontology distinguishes between customizable and standardized interface elements.

Personalization represents a critical challenge in emerging technologies, particularly for user preference management. Driver diversity necessitates adaptive interfaces; failure to accommodate varied preferences compromises driving experience and safety. Reconciling personalization with standardization requires balanced approaches. An ontology capturing this interplay in HAVs aligns with Aristotelian “mesotes”—the virtuous mean between extremes [8]. The ontology provides structured semantic representation for organizing and processing user preferences [9], enabling continuous learning and progressive adaptation to user habits, thereby enhancing personalized driving experience. The ontology supports personalized interface adaptation based on user profiles [10].

While personalization is key, some interface elements require standardization to maintain safety and consistency. The ontology formally specifies customizable versus immutable interface components, preventing errors while maintaining safety. This separation facilitates user-aligned interface development while standardized elements ensure consistency and safety, reducing human error from interface variations or behavioral differences. Balancing customization and standardization are essential for widespread HAV adoption [11,12,13].

Manual ontology creation requires specialized expertise and extensive time investment. This study explores LLM-based semi-automation using GPT-4o [14] to accelerate ontology development while improving process efficiency and result quality. The approach employs targeted, diversified prompting to elicit structured LLM responses as ontology construction foundations, subsequently enriched through manual curation. A reference table provides phase-specific guidelines for model guidance, with systematic output evaluation ensuring quality and reliability.

The main contributions include the following: (1) methodology integrating LLM support with human validation for ontology construction; (2) integration of established ontology engineering practices; (3) application to the automotive domain; (4) a structured validation framework across logical, structural, semantic, and functional dimensions; and (5) comprehensive validation through logical, structural, semantic, and functional evaluations, including SPARQL-based reasoning tests.

The structure of this study is as follows. Section 2 analyzes related works on LLM-based otology generation (Section 2.1) and HAV domain ontologies (Section 2.2). Section 3 describes the methodology, emphasizing prompting techniques and ontology extension strategies. Section 4 presents the final ontology. Section 5 details evaluation and validation: (a) logical consistency and quality verification (Section 5.1); (b) structural evaluation of taxonomic structure (Section 5.2); (c) semantic evaluation examining entity similarity and conceptual distance (Section 5.3); (d) functional evaluation testing the knowledge inference and query answering capabilities (Section 5.4). Section 6 discusses the results.

2. Related Works

This section discusses two key aspects. Section 2.1 examines techniques developed for using LLMs in ontology creation. Section 2.2 analyzes the main contributions in the literature on ontologies applied to autonomous driving and driver profiles.

2.1. LLMs in Ontology Development

Several studies employ LLMs to automate ontology creation aspects, leveraging natural language processing (NLP) for human-level understanding and generation.

De Gelder et al. [15] proposed an object-oriented framework defining road traffic scenarios as classes with attributes, methods, and inter-object relations. Babaei Giglou et al. [16,17] developed LLMS4ol, investigating LLM applications in ontology learning tasks: term typing, taxonomy discovery, and relation extraction across knowledge domains. Kommineni et al. [18] demonstrated competency question (CQ) utilization for concept and relationship extraction in ontology construction, analyzing 61 deep learning publications with ChatGPT-3.5-generated and expert-refined CQs [19]. Crum et al. [20] leveraged implicit LLM knowledge through prompt engineering to identify ontological disjunctions, demonstrating reliable disjunctive relation detection with effective prompting strategies. Lo et al. [21] presented an ontology learning from LLMs for automated ontology construction using a generative pre-trained transformer (GPT) and custom fine-tuning. Mukanova et al. [22] developed methods for LLM-based text processing and semantic data extraction, storing results in intermediate formats before programmatic ontology instantiation. Tupayachi et al. [23] created integrated methodologies leveraging pre-trained LLMs for ontology and scenario-based knowledge graph generation from research papers and technical manuals, utilizing ChatGPT API as a reasoning engine with NLP modules and structured prompts. Mateiu et al. [24] described ontology enrichment using fine-tuned GPT-3 for converting natural language to description logic expressions in Turtle functional syntax. Vieira da Silva et al. [25] explored LLM-based capability ontology generation from natural language descriptions, demonstrating promising zero-shot results. Ciatto et al. [26] presented schema-based methods using interrelated classes, properties, and query templates for automated ontology population through repeated LLM querying. Fernandez [27] investigated LLM integration in ontology engineering for extending existing ontologies, testing framework effectiveness in common greenhouse ontology (CGO) with a semantic explanation and navigation system (SENS).

However, the use of LLMs must address the problem of hallucinations, i.e., generating invented information. Hallucinations in AI models have to be managed with a clear and structured strategy. Kommineni et al. [18] and Mukanova et al. [22] suggest predefined ontology models containing structured, interpretable knowledge representations. Zhangcheng et al. [28] proposed domain-specific fine-tuning for improved ontology matching performance and benchmark creation for accurate hallucination evaluation. The literature review identifies key guidelines for LLM adoption in ontology construction, emphasizing careful guidance and structured management for model scope delimitation.

Our contribution focuses on methodological LLM–human integration rather than algorithmic innovation—an underexplored approach crucial for real-world LLM adoption where usability, transparency, and adaptability supersede computational performance.

2.2. Existing Ontologies in the Domains of Highly Automated Vehicles and Driver Profiling

Several ontologies address autonomous driving aspects, from vehicle/driver behavior modeling to interoperability and safety management, targeting driver profiles, and customizable/standardizable concept distinctions.

Ossig et al. [29] developed automated vehicle behavior ontology for human-centered automated driving research, addressing conventional terminology inadequacy for automated systems. Their ontology conceptualizes automated vehicle behavior across automation levels, distinguishing occupant characteristics, automation properties, and vehicle attributes. Similarly, Trypuz et al. [30] proposed basic formal ontology-grounded approaches aligned with the SAE J3016 standard [31], formally defining automation levels and capturing relationships among vehicle components, driving activities, and humans.

Pereira et al. [32] introduced an ontology for shared autonomous vehicles (SAVs), modeling the entities, properties, and relationships. For safety and interoperability, Zhao et al. [33] developed core ontologies for safe autonomous driving, incorporating maps, control, and vehicle ontologies supporting real-time ADAS and autonomous environment safety enhancement. Gheisari et al. [34] addressed Cloud of Things (CoT) infrastructure heterogeneity and smart city privacy concerns. Westhofen et al. [35] designed environmental knowledge ontologies enabling automated traffic scene analysis through reasoning engines for critical traffic factor identification.

Syzdykbayev et al. [36] formulated ontologies capturing interactions among mobility vehicles, pedestrians, and autonomous systems, accounting for preferences and requirements and facilitating intelligent cooperative behavior.

For driver profiling, Fernandez et al. [37] developed ontologies representing driver behavior and traffic environment interactions, supporting fuzzy rule-based classification systems for behavioral profile categorization. Sarwar et al. [38] proposed DriverOntology, a formal model organizing driver characteristics into structured representations enabling systematic categorization.

Existing HAV and driver profiling ontologies acknowledge driver preference importance and driving style diversity but lack specific models for autonomous vehicle driver preferences. Interface customization remains unexplored, particularly regarding standardization–customization element distinctions. While several ontologies address autonomous vehicle and driver behavior, comprehensive models systematically integrating customization and standardization are absent, highlighting significant gaps in ontological frameworks balancing standardization with personalization for optimized safety and comfort in automated driving contexts.

3. Methods

This section presents a structured, iterative methodology for LLM-supported ontology development, combining human expertise with AI prompting across six phases: theoretical definition (Section 3.1), domain exploration and analysis (Section 3.2), ontology synthesis (Section 3.3), formalization (Section 3.4), self-assessment (Section 3.5), and integration (Section 3.6).

Figure 1 illustrates the step-by-step ontology development process with numbered phases, indicating manual human tasks and automated AI execution within each phase. Additionally, certain sub-phases are performed manually by humans, while others are executed automatically by AI, as indicated within the process.

The ontology development process spans from theoretical definition to final validation through distinct phases with specific objectives. A domain-knowledgeable user—though not necessarily a subject matter expert—is involved from the initial stages, providing structured input and guiding the conceptual modeling based on domain understanding.

• Phase 1: Theoretical definition establishes domain scope and ontology purpose through key questions defining basic conceptual structure. This phase ensures application-specific requirement fulfillment by identifying and organizing classes, subclasses, properties, and relations, providing theoretical foundations (Section 3.1).
• Phase 2: Exploration and analysis employs LLM interaction for ontology generation (Section 3.2), using (A) exploration prompts for key element identification and (B) analytical prompts for detailed class, subclass, and relation definition, enabling structured ontology development.
• Phase 3: Ontology synthesis guides LLM through synthesis prompts integrating elements from previous phases, producing coherent, integrated ontology representations while eliminating redundancies and ensuring completeness (Section 3.3).
• Phase 4: Ontology formalization directs LLM conversion of ontology into machine-readable Turtle format through formalization prompts, enabling deployment in computer systems for automated reasoning and model interoperability (Section 3.4).
• Phase 5: Self-assessment tasks LLM with ontology evaluation by verifying: (a) concept coverage relative to

  Table A1. ChatGPT-4o class and subclass definition guiding table.

  No	Questions	Answers	Examples
  1	What are the main purposes of the ontology?	(i) Identifying and representing driver profiles (ii) Personalizing driving experience based on profiles (iii) Ensuring compatibility of profile information across multiple platforms and devices, with potential transferability between different vehicles	(i) Creating a profile that recognizes a young driver with sporty driving preferences (ii) Automatically adjusting temperature and seat based on saved preferences (iii) Transferring driving settings from a rental vehicle to a private one via the cloud
  2	Which components can access the structured information contained in the ontology?	(i) User interfaces (ii) Driver assistance systems (iii) Driver safety systems	(i) A touchscreen display that allows the driver to modify the driving profile directly from the dashboard (ii) An automatic parking system that adapts the behavior based on the driver’s preferences (iii) The driver monitoring system that warns if it detects signs of fatigue based on the profile data
  3	What are the main driver profiles?	(i) Identify the driver categories to be represented (ii) Define the features of the driver profile (iii) Identify the preferences to customize for autonomous driving (iv) Determine the driver’s demographic and behavioral data	(i) Create a profile for an experienced driver and one for a novice driver (ii) Include information, such as age, preferred driving style, and comfort preferences (iii) Preferences for highway speed, safe distance, or use of automatic mode (iv) Collect information such as level of driving experience, reaction time in emergency situations
  4	Which profile properties are customizable?	(i) Comfort settings (ii) Driving preferences (iii) Multimedia preferences (iv) How to interact with infotainment systems (v) Presentation of the interface for customizing profiles	(i) Climate temperature, seat position, interior lighting (ii) Sport or eco-friendly driving mode, steering sensitivity and engine response (iii) Favorite radio stations or playlists, preset volume (iv) Voice or touch screen commands for navigation, personalized voice responses (v) Frequency with which the system suggests changes to driving or entertainment preferences (vi) Layout of the graphical interface based on visual preference, such as dark or light mode
  5	Which profile properties cannot be modified by the driver?	(i) Driver identification (ii) Critical information for safety and regulatory compliance (iii) Data collected during vehicle use (iv) Information regarding the physical and mental health of the driver (v) Data encryption (vi) Critical feature access	(i) Facial or fingerprint recognition for vehicle access (ii) Mandatory recording of driving times and breaks for commercial vehicles (iii) Automatic recording of speed and kilometers traveled for insurance purposes (iv) Monitoring of heart rate or fatigue to prevent accidents (v) Techniques to encrypt sensitive data (vi) Access control mechanisms for essential vehicle functions, such as automatic braking or acceleration control
  6	What data should be protected in terms of privacy?	(i) Personal and sensitive data of the driver (ii) Definition of access policies and data management	(i) Biometric data, navigation history, travel information (ii) Access to specific personal data (e.g., preferred routes) can only be authorized by the vehicle owner
  7	How to ensure that standard elements are not modified by the driver?	(i) Setting system-wide restrictions (ii) Periodic verification by the system (iii) Continuous validation of critical data via software updates	(i) Restrict security-related modifications through administrator-level credentials (ii) Automatic check of security settings every time the vehicle is started (iii) Periodic software updates confirming that security parameters have not been altered
  8	How will driver profiles be updated?	(i) Via accessible user interfaces (ii) Automatic synchronization with cloud platforms (iii) Updates based on driver behaviors	(i) User can change their preferences via a mobile app connected to the vehicle (ii) Automatic update of profile preferences when the vehicle connects to the Internet (iii) The system suggests updating preferences based on changes detected in the driver’s behavior over time
  9	What legal or regulatory requirements must be met to define the interfaces of HAVs?	(i) Compliance with local and international regulations (ii) Compliance with data protection directives (iii) Ensuring the security and transparency of the interfaces	(i) Compliance with autonomous driving laws and road safety standards in various countries (ii) GDPR in Europe requiring protection of personal data collected by vehicles (iii) Providing the user with an interface that clearly displays the data collected and its intended use
  10	What is the context of use of the ontology?	(i) Identifying the contexts of use (ii) Defining context-specific usage scenarios	(i) The system recognizes whether the vehicle is in the city or on a highway and adapts the driving profile accordingly (ii) In urban environments, the profile may activate cautious driving settings, whereas on highways, it may optimize efficiency at higher speeds

  , (b) missing elements, (c) innovations versus reference versions, and (d) completeness improvements. This analysis identifies ontology strengths and improvement areas (Section 3.5).
• Phase 6: Ontology enrichment updates and extends ontology through: (A) manual integration of scientific literature concepts and (B) standardized elements from official regulations. This phase enriches ontology with consolidated academic and regulatory information (Section 3.6).
• Phase 7: Technical validation (Section 5) conducts comprehensive technical verification: (a) logical consistency verification (Section 5.1), (b) structural metrics analysis (Section 5.2), (c) semantics analysis (Section 5.3), and (d) inferential capabilities assessment (Section 5.4). This phase is performed by a validator, an ontology expert responsible for assessing the formal correctness, semantic soundness, and reasoning capabilities of the ontology, independently of domain-specific expertise.
• Following successful validation, ontology achieves final approval.

Our methodology’s initial phases—theoretical definition and exploration/analysis—reflect conceptual steps from classical approaches like those of Noy and McGuinness [39], while extending beyond these models through systematic LLM integration. We adapt Noy’s framework for iterative, controlled LLM interaction, where AI maintains active roles throughout the ontological development cycle.

The methodology incorporates elements from Bravo et al. [40], which defines four macro-phases: requirement specification, conceptual design, implementation, and evaluation, integrating both classical and contemporary ontology engineering approaches.

Table 1. Comparative table of ontology development approaches.

Phase	Noy & McGuinness [39]	Bravo et al. [40]	Our Method
Requirements/Domain Definition	- Definition of domain and scope - CQs to delineate scope and purpose	- Definition of motivation, users, scenarios - CQs with experts - Qualitative requirements	- Theoretical definition: same logic as [39] (domain, scope, competency questions) but more formalized with guiding questions
Term Collection	- List of relevant domain terms	- Elicitation of terms from CQs - Identification of basic concepts (nouns, relationships)	- Exploration and analysis: LLM supports the extraction of terms and concepts from CQs and domain documents
Conceptual Structure Definition	- Building class hierarchy (top-down/bottom-up/mixed) - Identification of disjoint classes	- Clustering of ontology modules - Separation into modular ontologies	- Same as [39], but assisted by LLM to refine classes, subclasses, and relational properties
Formalization of Relationships and Properties	- Definition of properties, facets, cardinality	- Definition of hierarchies, data, and object properties - DL axioms: cardinality restrictions, existential, universal	- Ontology synthesis and formalization: LLM guides the generation of formalized Turtle; definition of properties via supervised LLM
Ontology Construction and Population	- Implementation with editor - Creation of illustrative instances	- Encoding with editor - Population of modules and consistency checks	- Enrichment and extension: manual and semi-automatic extension from literature and official standards
Ontology Validation and Evaluation	- Check for correct hierarchy and relationships - Disjoint, cycles, coherent generality	- Competency evaluation (CQ → DL queries) - Quality validation: clarity, consistency, modularity	- Self-assessment (LLM evaluates coverage, gaps, innovations) - Technical validation: logical consistency, structural metrics, semantic accuracy, and competency evaluation

provides a structured comparison between our method and two foundational approaches—Noy & McGuinness [39] and Bravo et al. [40]—highlighting how our integration of LLMs enhances each ontology development phase.

Our method integrates established ontology engineering principles with controlled automation mechanisms. From Noy & McGuinness [39], it adopts logical phase sequencing (domain definition, term collection, structuring, formalization, population, validation), [competency questions (CQs) for requirements definition, and hierarchical class construction. From Bravo et al. [40], it incorporates rigorous OWL formalization, conceptual modularization, and logical validation through description logic (DL) reasoning.

The innovation lies in iterative LLM utilization guided by a guiding table structuring prompts across phases. The model assists in concept extraction, class synthesis, and automatic OWL/Turtle generation under human validation. The method enables continuous ontology updates through parsing of new sources and regulatory standards, [introducing automatic self-assessment of conceptual coverage and coherence with semi-automatic structural validation through ontological metrics.

3.1. Phase 1: Theoretical Definition

The ontology development follows Noy et al.’s [39] methodology (see also [41,42,43,44,45]), providing a structured, comprehensible domain and class hierarchy definition while adapting to driver profile requirements.

(A)

Domain and Purpose Definition

Domain-relevant questions were formulated based on domain knowledge and a scientific literature review of driver modeling and autonomous vehicle interaction, serving dual roles: (i) guiding ontology scope and purpose and (ii) functioning as CQs for assessing knowledge representation and reasoning capabilities.

To establish this, we formulated the following questions:

(a) 

What are the main purposes of the ontology? (i) Driver profile identification and representation; (ii) profile-based driving experience personalization; (iii) cross-platform profile compatibility ensuring transferability across vehicles.

(b) 

Which components can access the structured information contained in the ontology? (i) User interfaces; (ii) driver assistance systems; and (iii) driver safety systems.

(c) 

What are the main driver profiles? Defining (i) target driver populations; (ii) required profile characteristics; (iii) autonomous driving customization preferences; (iv) demographic and behavioral data.

(d) 

Which profile properties are customizable? (i) Comfort settings; (ii) driving preferences; (iii) multimedia preferences; (iv) infotainment interaction preferences; (v) frequently versus rarely modified preferences; (vi) profile customization interface presentation.

(e) 

Which profile properties are standard, not customizable by the driver? (i) Driver identification properties; (ii) safety-critical information ensuring compliant operation; (iii) vehicle usage data collection; (iv) health-related information affecting safety and driving experience.

(f) 

How to ensure that standard elements are not modified by the driver?

(g) 

How will driver profiles be updated? This question allows the identification of the possible ways in which a driver may modify their profile.

(h) 

Which data must be protected in terms of privacy? Addressing (i) personal and sensitive data processing; (ii) access policy definition.

(i) 

What legal or regulatory requirements must be respected to define HAVs interfaces?

(j) 

What is the context of the use of ontology? Specifying (i) profile employment contexts; (ii) adaptation scenarios.

(B)

Class, Subclass, and Property Definition

This creates structured entity, property, and relation representations organizing knowledge and describing driver behaviors, preferences, and autonomous vehicle interactions.

Ontology class definition follows two methodological approaches: ChatGPT-4o support for ontology definition (Section 3.2, Section 3.3,Section 3.4 and Section 3.5) and LLM-generated information enrichment through scientific literature, regulations, and standards (Section 3.6).

3.2. Phase 2: Exploration and Analysis

Ontology construction follows multi-phase processes compiling guiding question tables with contextualized answers for creating classes, subclasses, and concept relationships to guide LLM ontology development. No domain-specific documents were provided initially; LLM guidance relied solely on structured prompting based on domain knowledge and preparatory analysis.

Prompting Techniques to Guide ChatGPT in Ontology Creation

To accomplish our research goals, we utilize ChatGPT-4o model. It was developed by OpenAI (San Francisco, CA, USA). ChatGPT-4o, released in May 2024, is a multimodal large language model capable of processing and generating text, images, audio, and video [14]. ChatGPT-4o is based on transformer architecture and is designed to comprehend and generate natural language text with a high degree of accuracy and coherence.

We selected ChatGPT-4o for its advanced capabilities in generating structured outputs from natural language prompts. The goal was to assess the LLM’s reliability in automating ontology creation, focusing on a specific case study.

The methodology employs progressive, sequential prompting integrating chain-of-thought (CoT) structured reasoning with iterative, incremental processing (chaining) [46,47,48]. CoT guides model segmentation of ontology construction into sequential logical phases following reasoned paths from the main class definition through subclass, property, and relation creation to final structuring. This approach enables implicit concept deduction, identifying elements not explicitly described in

Table 2. Excerpt—ChatGPT-4o class and subclass definition guiding table.

No	Questions	Answers	Examples
1	What are the main purposes of the ontology?	(i) Identifying and representing driver profiles (ii) Personalizing driving experience based on profiles (iii) Ensuring compatibility of profile information across multiple platforms and devices, with potential transferability between different vehicles	(i) Creating a profile that recognizes a young driver with sporty driving preferences (ii) Automatically adjusting temperature and seat based on saved preferences (iii) Transferring driving settings from a rental vehicle to a private one via the cloud

. Chaining enables generative processes through interdependent stage sequences, with each phase contributing to ontology refinement through iterative optimization via analytical and automated validation prompts.

We examine the types of prompts employed at various stages of ontology development. For additional examples of prompt usage across various tasks in the domain of prompt engineering, see [49].

(A)

Information Exploration Prompts

These prompts elicit detailed model information using Table 2 content, guiding focus on key domain representation elements. Table 2 submission to ChatGPT-4o initiates ontology development, containing initial questions, proposed answers, and concrete examples enhancing model precision and requirement alignment.

Consequently, we develop Table 2 and submit it to ChatGPT 4o when initiating ontology development. Table 2 contains the initial questions formulated, the proposed answers, and concrete examples. The concrete examples enhance model precision and alignment with requirements.

Specifically, Table 2 defines core aspects of the ontology, including its purpose (e.g., representing driver profiles and enabling personalization), the components accessing the ontology (such as user interfaces and driver assistance systems), the structure of driver profiles (modifiable and fixed properties), privacy-preserving mechanisms, update procedures, compliance with legal and regulatory frameworks, and relevant usage contexts. This structured input ensures consistent, secure, and adaptive ontology generation aligned with real-world automotive requirements.

An excerpt of Table 2 is reported below, while the complete version is available in Appendix A.1.

(B)

Analytic Prompts

These prompts instruct ChatGPT-4o to define the five core ontology components: concepts, relationships, functions, individuals (or instances), and axioms [50].

(a)

Defining the structure ontology

The following prompt was submitted to ChatGPT-4o:

Prompt:

“Create the personalized and standardized Driver-Vehicle Interfaces Ontology structure based on the following structure: (1) Concepts (Classes and Subclasses): Define the main categories relevant to the domain. (2) Relationships: Specify the connections between concepts and how they interact. (3) Data Properties: Identify the key attributes associated with each concept. (4) Axioms: Establish constraints, rules, and logical definitions governing ontology. Use the reference guide table (see Table 2) to structure the ontology and include all the examples that can be explicitly extracted from Table 2”.

These prompts represent sequential requests to the model in condensed form. While unified here for presentation clarity, the actual workflow involves progressive definition of classes, subclasses, properties, and axioms following the traditional ontology engineering methodology of Noy and McGuinness, adapted for LLM-based iterative development.

The initial response from ChatGPT-4o is provided in Figure 2, and it is fully available in the GitLab repository of the University of Geneva, under the title: Developing Ontology Driver Profile-based Personalized & Standardized DVI Elements (B(a)) (University of Geneva GitLab Repository—Developing Ontology Driver Profile-based Personalized & Standardized DVI Elements (B(a)). Available at: (https://gitlab.unige.ch/Maria.Cappelli/leveraging-llm-ontology-development/-/blob/main/DevelopingOntologyDriverProfile-BasedPersonalized&StandardizedDVIsElements(B(a))?ref_type=heads) (accessed on 7 April 2025)).

(b)

Defining Implicit (Derived) Components and New Components

Prompt:

“Add a new component to the ontology structure that can be implicitly inferred from Table 2 to make the structure completer and more applicable to the domain. Integrate new concepts freely, without limiting yourself to Table 2”.

The ChatGPT-4o’s response is available in the GitLab repository of the University of Geneva, under the title: Developing Ontology Driver Profile-based Personalized & Standardized DVI Elements (B(b)) (University of Geneva GitLab Repository—Developing Ontology Driver Profile-based Personalized & Standardized DVI Elements (B(b)). Available at: (https://gitlab.unige.ch/Maria.Cappelli/leveraging-llm-ontology-development/-/blob/main/DevelopingOntologyDriverProfile-BasedPersonalized&StandardizedDVIsElements(B(b))?ref_type=heads) (accessed on 7 April 2025)).

(c)

Ontology Enrichment through OWL Constructs and Axiom Definition

Prompt:

“Extend the ontology structure by adding new OWL constructs (such as intersections, unions, complements, and property restrictions), and defining new axioms (such as subClassOf, equivalentClass, disjointWith, functional properties, etc.) to enrich relationships, enforce consistency, and specify cardinality and hierarchy between classes and properties”.

The LLM’s response is available in the GitLab repository of the University of Geneva, under the title: Developing Ontology Driver Profile-based Personalized & Standardized DVI Elements (B(c)) (University of Geneva GitLab Repository—Developing Ontology Driver Profile-based Personalized & Standardized DVI Elements (B(c)). Available at: (https://gitlab.unige.ch/Maria.Cappelli/leveraging-llm-ontology-development/-/blob/main/DevelopingOntologyDriverProfile-BasedPersonalized&StandardizedDVIsElements(B(c))?ref_type=heads) (accessed on 7 April 2025)).

3.3. Phase 3: Ontology Synthesis

(A)

Synthesis and Combination

The model synthesizes ontological components identified in previous phases through integrative prompting.

Prompts:

“Create the ontology by combining the classes, sub-classes, data properties and object properties you have already defined”.

Table 3. Summary of explicit, implicit, newly introduced, and omitted concepts.

Entity Type	Explicit	Implicit	Newly Introduced	Total
Concepts	51	9	5	65
Relationships	9	6	4	19
Data Properties	25	1	0	26
Axioms	18	3	0	21
Omitted Concepts	-	-	-	3

categorizes ontological elements by their derivation method: explicit terms extracted directly from input sources, implicit terms inferred through semantic interpretation and contextual analysis, and novel terms introduced by the LLM beyond the provided information.

The last row identifies three missing concepts that should be considered to improve alignment with the requirements outlined in Table 2.

Table 4. Excerpt—implicitly inferred, newly introduced, and omitted ontology elements.

No	Concept	Category	Description
1	AdaptiveDriver	Implicitly Inferred Elements	Inferred from the system’s capability to update the driver’s profile dynamically based on behavioral patterns observed over time.
11	AccidentHistoryData	New Concepts Introduced	Essential for customizing safety configurations and insurance parameters, though not explicitly addressed in the initial framework.
16	BiometricFatigueDetection	Items Omitted	Implicit in the driver monitoring system, so not explicitly repeated.

presents the implicitly inferred, newly introduced, and omitted ontology elements, specifying the concept name, its corresponding class, and a detailed description. These concepts were determined through a systematic comparison between the initial ontology framework provided in Table 2 and the output generated by the LLM. Classification as implicit, novel, or omitted was determined through manual evaluation based on relevance and consistency with the ontology scope. An excerpt of Table 4 is reported below, while the complete version is available in Appendix A.2.

3.4. Phase 4: Ontology Formalization

(A)

Formalization Prompts

We instructed the model to formalize the ontology using a structured language.

Prompt:

“Create an ontology in OWL format using in a consistent way. Use the prefix onto-cms: to identify the entities of the ontology. Make sure that: classes are well structured with appropriate hierarchical relationships. ObjectProperty binds to the correct classes and is defined with the appropriate rdfs:domain and rdfs:range. DataProperty is properly assigned to classes and has compatible data types”.

The resulting ontology underwent validation using the Pellet reasoner [51] to ensure structural consistency and proper definition of classes, subclasses, object properties, and data properties. Post-validation corrections included namespace standardization and prefix alignment to ensure syntactic and semantic OWL compliance.

3.5. Phase 5: Self-Assessment

(A)

Self-Assessment Prompts

The model was prompted to perform a critical self-assessment of its output.

Prompt:

“Evaluate the developed ontology by comparing it against the reference concepts outlined in Table 2. This evaluation is carried out about four major features: (1) Coverage of required concepts: Alignment with the categories and entities listed in Table 2 has to be verified. (2) Identification of missing elements: Assessment of possible shortfalls relative to the reference concepts should be made. (3) Innovations introduced in the ontology: Consider any other features that are not in Table 2. (4) Suggestions for improvement: Extensions that would help fill the gaps should be proffered”.

The summary results of the self-assessment generated by Chat-GPT 4o are reported in

Table 5. Ontology evaluation based on Table 2 requirements.

No	Concept	Category	Description
1	Coverage of required concepts	Partial to Good	Core concepts like driver profiles, preferences, and personalization are present. Legal and safety-related aspects are limited.
2	Driver profiles and preferences	Good	Classes and properties such as age, behavioralData, comfortPreferences effectively represent customizable user traits.
3	System components interaction	Present	Modeled through object properties like accessedByAuthorizedComponents, and affectsSystemComponents.
4	Customizable profile properties	Partial	Comfort-related features, such as temperature settings and user preferences, are included.
5	Non-modifiable properties	Weak	Biometric identifiers are represented; however, their immutability and protected status are not clearly specified.
6	Privacy and data protection	Limited	Certain properties imply sensitivity (i.e., biometrics); yet there is no explicit reference to encryption measures or GDPR compliance.
7	Profile updating mechanisms	Strong	Dynamic updates are well represented through adaptsPreferencesDynamically and adaptsBasedOnUsageContext.
8	Context of use modeling	Weak to Partial	Certain properties imply sensitivity (i.e., biometrics); yet there is no explicit reference to encryption measures or GDPR compliance.
9	Legal and regulatory requirements	Not Covered	No classes or properties explicitly represent regulatory or compliance aspects.
10	Innovative additions	Yes	AI-based personalization systems, such as AIBasedLearningSystem, are modeled, demonstrating advanced modeling capabilities.

.

The model performed critical self-evaluation using qualitative indicators focusing on concept coverage, property representation, requirement compliance, and conceptual innovation. This internal assessment compared the ontological content against specifications in Table 2 without applying standard quantitative metrics (precision, recall).

Table 6. Excerpt—suggested improvements and additions to ontology.

No	Concept	Category	Description
1	GDPRCompliance	Missing Element	Needed to model compliance with European data protection regulation and ensure legal use of personal data.

shows the suggestions that LLM proposes to improve the ontology. An excerpt of Table 6 is reported below, while the complete version is available in Appendix A.3.

As noted in the model’s self-assessment and further confirmed during human review, the LLM demonstrated a generally effective ability to define core ontology components. Nonetheless, the ontology enrichment stage revealed weaknesses in the use of OWL constructs, such as the omission of domain/range axioms, inadequate restriction types, and missing disjointedness axioms. These limitations required manual correction and refinement by the authors to ensure formal OWL compliance. This reinforces the need for human oversight in validating and refining ontologies generated by LLMs.

Summary of Prompting Techniques Used in Ontology Development

Finally, we summarize the prompting techniques used in the ontology creation process with ChatGPT-4o in

Table 7. Excerpt—types of prompting strategies that are applied in the driver profiles ontology process.

Technique	Description	Example	Section
Few-shot Prompting	Provides initial examples to guide the model in performing the task.	Table 2 with 10 guiding questions, such as: “What are the main purposes of the ontology? Identifying profiles; Compatibility across vehicles”.	3.1

. An excerpt of Table 7 is reported below, while the complete version is available in Appendix A.4.

3.6. Phase 6: Ontology Enrichment

The LLM-generated ontology for driving profiles, comprising personalized and standardized DVI elements, serves as a foundational T-Box requiring conceptual expansion. This enables ontological extension through additional classes, properties, and specialized subclasses, incorporating domain-relevant concepts previously omitted. Through this iterative refinement, the ontology achieves greater domain specificity and alignment with its intended application.

The enrichment process employed two complementary approaches: (A) systematic analysis of existing literature and (B) integration of HAV and HMI regulations and standards, encompassing both academic publications and regulatory frameworks.

The ontology’s extensibility demonstrates its modular architecture, enabling concept integration without compromising structural integrity. New driver profiles or assistance systems can be incorporated through straightforward subsumption hierarchies. The ontology’s flexibility accommodates emerging concepts, including novel driving modes and interface technologies.

(A)

Class Derivation from Scientific Literature Analysis

We identified scientific publications addressing interface customization using defined inclusion criteria to ensure relevance and currency. Studies addressing HMI or DVI topics were prioritized, with preference for publications within seven years, excluding foundational works given the rapid evolution of HMI/DVI technologies and autonomous vehicles. Sources were limited to peer-reviewed journals and conference proceedings.

The preceding analysis led to the following results. Atakishiyev et al. [52] emphasizes deployability and communication enhancement in autonomous vehicles for trust building and accident prevention, proposing an empirically tested framework highlighting customizable HMIs’ critical role in HAVs. Bellem et al. [53] analyzed correlations between driving styles, personality traits, and passenger preferences to optimize comfort and acceptance in automated driving contexts. Zhao et al. [54] examined V2X technologies’ role in enhancing driver–vehicle–infrastructure communication, identifying user preferences for information modalities and safety-critical functionalities in connected vehicle information systems (CVISs). The results indicate driver preference for visual warnings and descriptive verbal speech over tactile signals, with higher valuation of safety functions (rescue services, hazard warnings). Age, gender, risk perception, privacy expectations, and technological inclination influence CVIS attitudes. In their studies, Schrum et al. [55] and Sundar et al. [56] proposed data-driven frameworks for adaptive AV driving style personalization, incorporating user preferences, personality traits, and perceived behavioral similarity. Their methodologies enable passenger profile categorization suitable for ontological integration, facilitating enhanced user profile management and infotainment system interaction.

For each study, information extraction was performed manually, organizing content into categories, classes, subclasses, properties, and relationships.

Table 8. Overview of classes, subclasses, properties, and relationships performed from [52].

Class	Sub-Classes	Properties	Relationships
DriverProfile	InclusivityNeed, TechnicalBackground, FunctionalCapability	visualImpairments, hearingImpairments, mobilityImpairments, cognitiveImpairments, expert, novice, intermediate	hasInclusivityNeed, hasTechnicalBackground, hasFunctionalCapability

presents an exemplary extraction from Atakishiyev et al. [52].

(B)

Class Identification from Regulatory and Standards Analysis

Regulatory vehicle safety and inclusiveness frameworks define requirements for vehicle type approval, ADAS implementation, and accessibility solutions at European and international levels. This section analyzes representative regulations shaping contemporary vehicle technology design (see

Table 9. Mandatory interface elements in autonomous vehicles and the possibility of changing/deactivating them.

Rule	Standardized Element	Status
EU Regulation 2019/2144	Intelligent Speed Assistance	Mandatory
EU Regulation 2019/2144	Alcohol Interlock Installation Facilitation	Mandatory
EU Regulation 2019/2144	Driver Drowsiness and Attention Warning	Mandatory
EU Regulation 2019/2144	Advanced Driver Distraction Warning	Mandatory
EU Regulation 2019/2144	Emergency Stop Signal	Mandatory
EU Regulation 2019/2144	Reversing Detection	Mandatory
EU Regulation 2019/2144	Event Data Recorder	Mandatory
GDPR	Protection of sensitive data (location, biometric data, driving preferences)	Mandatory
ISO/SAE 21434	Cybersecurity of interfaces	Mandatory
UNECE R155	Integrated cybersecurity measures	Mandatory
ISO 15005:2017	Clarity and usability of interfaces	Mandatory
ISO/IEC 25010	Error management in software systems	Mandatory
ISO 26262	Functional safety and malfunction reporting	Mandatory

). While the list is not exhaustive, it offers a representative overview of the regulations that shape the design and implementation of technologies in contemporary vehicles.

EU Regulation 2019/2144 [57] mandates advanced safety devices including event data recorder and ADAS for new vehicle models (approved from 6 July 2022; mandatory for new registrations from 7 July 2024). Article 6, paragraph 1, specifies required systems: (a) intelligent speed assistance, (b) alcohol interlock installation facilitation, (c) driver drowsiness and attention warning, (d) advanced driver distraction warning, (e) emergency stop signal, (f) reversing detection, and (g) event data recorder.

These ADAS systems process a substantial amount of sensitive data concerning driver behavior and conditions. Consequently, data-handling interfaces must comply with GDPR [58] principles: lawfulness, fairness, transparency, data minimization, and accuracy. Beyond data protection, certain ADAS systems influence access to critical vehicle functions, necessitating robust authentication mechanisms and safeguards against unauthorized access.

High-level protection requires robust authentication and secure system interfaces, as per cybersecurity standards, including ISO/SAE 21434 [59] (cybersecurity guidelines for road vehicle engineering). Authentication alone is insufficient; vehicles require integrated cybersecurity measures against cyber-threats, as per UNECE Regulation No. 155 [60], encompassing technical solutions (encryption, firewalls, secure updates) and organizational aspects (access management, threat monitoring). Data protection must align with GDPR Article 32 [58] requirements for personal information integrity and confidentiality.

Interface usability represents a critical design aspect. Driver safety requires clear, comprehensible, intuitively organized interface elements minimizing distraction risk. ISO 15005:2017 [61] provides ergonomic guidelines for HMI design in transport information and control systems (TICS), promoting seamless, distraction-free interactions.

Interfaces must communicate issues and malfunctions clearly and promptly. Software error management follows standards that include ISO/IEC 25010 [62] (software reliability quality requirements) and ISO 26262 [63] (functional safety in road vehicles), mandating effective reporting mechanisms for hazardous situation mitigation.

Finally, considering that autonomous vehicles collect vast amounts of sensitive data—including location, biometric information, and driving preferences—it is essential to protect this information from unauthorized access. Compliance with standards such as ISO/SAE 21434 [59] and UNECE Regulation No. 155 [60] prevents cyber-attacks and ensures data privacy.

Regulatory and standards analysis identifies mandatory elements for autonomous vehicle interface manufacturers. We hypothesize interface elements derived from these regulations and indicate their modifiable nature. This preliminary framework can extend to encompass all autonomous vehicle regulations, enabling systematic regulatory requirement integration into interface design.

Elements identified from regulatory analysis were instantiated within the ontology under the NoncustomizableElement class, which includes subclasses representing mandatory and immutable interface components. For example, the AdvancedDistractionWarning class is formally defined as:

AdvancedDistractionWarning ⊑ NonCustomizableElement ⊓∃ modifiable. {false}

Table 10. Summary of manual vs. LLM-generated ontology components.

Type	Manual Resources	LLM-Generated Resources
Main Classes	14	5
Subclasses	3	29
Properties	7	22
Relationships	3	14

provides an overview of ontology resource distribution between manually curated and LLM-generated components.

The LLM autonomously generated most of the ontology components: 29 of 32 subclasses, 22 of 29 properties, and 14 of 17 object properties. Manual contributions were minimal, primarily serving to extend LLM-generated structures. Axioms were manually specified to ensure logical consistency and OWL compliance.

4. Personalized and Standardized Driver–Vehicle Interfaces Ontology Structure

Figure 3 shows the structure of the personalized and standardized driver–vehicle interfaces ontology.

The ontology diagram represents the conceptual structure of the driver profiling system with DriverProfile as the root concept, linked to the Driver and DriverPreferences classes. The hasProfile object property connects drivers to their profiles, while profiles incorporate preferences through hierarchical relationships. DriverPreferences encompasses subclasses including DrivingPreferences, InfotainmentInteraction, MultimediaPreferences, and ComfortSettings. The ontology includes regulatory classes (Standard, Regulation, and NonCustomizableElement), which set constraints on the system by establishing rules that must be followed. These constraints are enforced through specific properties that ensure compliance.

Figure 4 shows the structure of an ontology developed in the Protégé 5.6.5 environment [64], organized hierarchically around the Driver concept encompassing driving preferences, behavioral profiles, sensitive data, and regulatory frameworks aligned with European and international requirements.

Figure 5 represents a detailed and inferentially enriched view of the multimedia preferences node.

The MultimediaPreferences subclass is placed as a subclass of DriverPreferences, next to other driver preferences, such as ComfortSettings, DrivingPreferences, InfotainmentInteraction, and UICustomization. This indicates that the ontology is structured to represent in detail the different aspects of user preferences related to the driving experience. On the right side of the interface, the properties and annotations related to the selected class are visible. The annotations section contains a descriptive comment that clarifies the meaning of the modeled concept. Further down, in the descriptive section, it is specified that MultimediaPreferences is a subclass of both DriverPreferences and DrivingPreferences. These two relations are highlighted in yellow, indicating that they were not explicitly defined but inferred by the active reasoning engine, which processed the ontology semantics to derive new connections. Additionally, in the lower section, further logical constraints and restrictions are visible, including the relation to the DriverProfile class, indicated by the object property hasProfile, and the presence of various data properties (such as modificationFrequency, customizedViaTouchInterface, modifiable, etc.).

The ontology is available in the GitLab repository of the University of Geneva, under the title: A Personalized and Standardized Driver Vehicle Interfaces Ontology (University of Geneva GitLab Repository—A Personalized and Standardized Driver Vehicle Interfaces Ontology. Available at: https://gitlab.unige.ch/Maria.Cappelli/leveraging-llm-ontology-development/-/blob/main/APersonalizedandStandardizedDriverVehicleInterfacesOntology.rdf?ref_type=heads (accessed on 14 April 2025)).

5. Phase 7: Technical Validation of the Ontology

The ontology is subjected to a series of evaluations to ensure its quality and reliability, following a multi-step assessment process. First, we perform (a) the verification of logical consistency and the overall quality of the ontology [65] (Section 5.1). Next, we proceed with (b) the structural evaluation, which analyzes the taxonomic structure of the ontology to assess its complexity and organization [65,66] (Section 5.2). Then, we conduct (c) semantic evaluation, which examines the similarity and conceptual distance between ontology entities, supporting ontology mapping and the identification of conceptual relationships [66] (Section 5.3). Finally, we perform the (d) reasoning evaluation, which tests the ontology’s ability to deduce implicit knowledge and correctly answer queries (Section 5.4).

5.1. Logical Consistency Evaluation and Quality of the Ontology

The ontology was successfully validated using the Pellet reasoner within Protégé 5.6.5 [64]. The analysis confirmed that the ontology is fully consistent and free of structural errors. All inferences were correctly computed, and constraints satisfied, ensuring a robust ontological model. To ensure the absence of errors, we employed the inconsistent debugging functionality in Protégé 5.6.5 [64]. The debugging session was successful, confirming that the ontology was fully consistent and coherent.

Subsequently, to evaluate the consistency and overall quality of ontology, we employed the Ontology Pitfall Scanner (OOPS!), an online tool designed to detect the most common errors (known as ‘pitfalls’) in ontologies [67]. OOPS! enables the detection of errors in ontologies, offers options to customize the types of errors analyzed, and classifies each error according to its severity (critical, major, minor). OOPS! identifies three categories of errors: (a) critical: “is crucial to correct the pitfall. Otherwise, it could affect the ontology consistency, reasoning, applicability, etc.; (b) important: though not critical for ontology function, it is important to correct this type of pitfall, and (c) minor: it is not really a problem, but by correcting it we will make the ontology nicer” (https://oops.linkeddata.es/catalogue.jsp (accessed on 14 April 2025)).

OOPS! verification identified mostly minor issues, including missing annotations (146 cases) and undeclared inverse relationships (47 cases), suggesting areas for refinement. For a complete explanation of each pitfall, refer to the OOPS! Website (https://oops.linkeddata.es/) (accessed on 7 April 2025). The report produced by OOPS! is available in the GitLab repository of the University of Geneva, under the title OOPS! Results (University of Geneva GitLab Repository—OOPS! Results. Available at: https://gitlab.unige.ch/Maria.Cappelli/leveraging-llm-ontology-development/-/blob/main/OOPS__-_OntOlogy_Pitfall_Scanner__-_Results.pdf?ref_type=heads (accessed on 7 April 2025)).

5.2. Structural Evaluation

We conducted the analysis of ontology structure through OntoMetrics (https://ontometrics.informatik.uni-rostock.de (accessed on 7 April 2025)), an online tool for the analysis and evaluation of ontologies. Developed at the University of Rostock, OntoMetrics enables the calculation of various structural and semantic metrics for OWL, RDF, or RDFS ontologies. The metrics are divided into three main categories: (a) base metrics, which measure the number of elements in the ontology—such as classes, properties, axioms—thus providing an overview of its overall size; (b) schema metrics, which assess the quality and structure of the conceptual model [68,69]; and (c) graph metrics, which compute the structural characteristics of the ontology represented as a directed graph [70].

• Base metrics represent the quantitative structure of the ontology. The ontology consists of 621 axioms, 111 classes, and 47 object properties and follows the ALCHIQ(D) DL expressivity.
• Schema metrics focus on the structure and conceptual design of ontology. These metrics provide an indication of the richness, breadth, depth, and inheritance organization of the schema. The values provide a quantitative overview of the quality and complexity of the ontology. Attribute richness measures the average number of attributes (or slots) defined per class, providing an indication of the information density associated with the ontology’s objects. Inheritance richness evaluates the distribution of information across the levels of the class hierarchy. It indicates how detailed (vertical) or general (horizontal) the ontology is. The richness of relations reflects the variety of connections between classes, considering non-inherited relations (such as object properties and equivalent or disjoint classes). The attribute/class ratio compares the number of classes possessing at least one attribute with the total number of classes, providing an estimate of the richness in properties of the represented entities. The equivalence ratio measures the proportion of classes declared as equivalent compared to the total number of classes, which is useful for evaluating the level of normalization or internal alignment. The axiom/class ratio indicates the logical density of the ontology, reflecting the average number of axioms associated with each class. The inverse relations ratio evaluates how many of the properties declared in the ontology have an inverse counterpart, compared to the total number of properties [68,69].
• Graph metrics, primarily based on subClassOf relations, describe the hierarchical complexity, organization, and distribution of concepts. Cardinality expresses the quantity of specific elements in the graph. The absolute root cardinality represents the number of nodes without superclasses, i.e., the starting points of the hierarchy. The absolute leaf cardinality indicates the number of nodes without subclasses, i.e., the terminal concepts of the structure. The absolute cardinality of the siblings represents the total number of classes that share the same superclass. The depth of the graph measures the number of hierarchical levels between the root and the leaves. The absolute depth is the sum of the lengths of all the hierarchical paths, while the average depth evaluates how “vertical” the modeling of the ontology is, and the maximum depth corresponds to the length of the longest path from the root to a leaf. In contrast, the width of the graph considers the “horizontal” extension of the hierarchy. The absolute width calculates the sum of the nodes for each hierarchical level, the average width evaluates on average how many concepts there are per level, and the maximum width is the maximum number of classes present in a single level. Dispersion, or fan-outness, measures how the concepts are distributed within the hierarchy. The dispersion of the leaves is the ratio between the number of leaves and the total number of nodes in the graph, while the dispersion of siblings assesses how evenly classes are distributed across the same hierarchical level. Tangledness reflects the degree of intertwining within the hierarchy, indicating the presence of classes belonging simultaneously to multiple hierarchies by having more than one direct superclass. Finally, the total number of paths indicates the number of distinct routes between the roots and the leaves in the graph, while the average number of paths expresses the mean value of such routes per graph analyzed [70].

The OntoMetrics report is available at the following link: https://ontometrics.informatik.uni-rostock.de/tmp/20250407100841117.xml (accessed on 7 April 2025).

5.3. Semantics Analysis

Semantic evaluation employed the Wu & Palmer similarity measure [71], which is based on the taxonomic structure of the ontology and measures the similarity between two classes as a function of their distance from the lowest common subsumer (LCS), i.e., their closest common ancestor. This formula considers the depth of the concepts within the hierarchy and assigns higher values when the classes are positioned closer together, indicating greater semantic affinity [72]. The second measure is the one proposed by Li et al. [73], which in addition to the distance between the classes also considers the depth of their common ancestor, modulating the impact of these factors through two parameters (α and β) that weigh the distance and the depth, respectively [72].

The combined use of these two metrics provides a more accurate evaluation of the similarity between concepts. Wu & Palmer provide a structural indication based on taxonomy, while Li’s measure introduces a more refined component, considering the hierarchical influence of depth. In this way, we can compensate for the limitations of each method and obtain a more complete view of the semantic relationship between classes.

To concretely apply these metrics, a representative set of classes from the main conceptual domains (i.e., DriverPreferences, SystemComponents, SafetyData, etc.) was selected, and the semantic similarity was computed for several pairs of concepts.

The results obtained highlighted a clear coherence in the hierarchical structure of the ontology: classes sharing the same direct parent node showed high similarity values according to both metrics. For example, within the ComfortSettings domain, concepts such as SeatPosition, ClimateControl, and InteriorLighting obtained high scores (Wu & Palmer [71] = 0.80, Li et al. [73] = 0.44), confirming the strong semantic proximity between these elements. This coherence was also observed in other domains, such as DrivingPreferences and MultimediaPreferences, where the subclasses exhibited consistent behavior in terms of depth and conceptual distance, confirming the sound modular design of the ontology. In parallel, low-similarity pairs—such as BiometricData vs. SportMode or AccidentHistoryData vs. PlaylistSelection—returned much lower values (Wu & Palmer [71] < 0.30, Li et al. [73] < 0.12), reflecting a significant semantic distance. This behavior aligns with the conceptual separation of heterogeneous domains (e.g., security, user preferences, identification) and confirms the effectiveness of the taxonomic model in preventing overlaps between concepts designed for distinct functional purposes.

The Semantic Ontology Evaluation Report is available in the GitLab repository of the University of Geneva (University of Geneva GitLab Repository. Accessible at: https://gitlab.unige.ch/Maria.Cappelli/leveraging-llm-ontology-development/-/blob/main/SemanticEvaluationReport.md?ref_type=heads (accessed on 14 April 2025)).

5.4. Evaluation of Ontology’s Inferential Capabilities

SPARQL queries tested inferential capabilities across competency questions (CQs), addressing driver profile identification (CQ1–3), customization properties (CQ4–5), privacy constraints (CQ6–7), and behavioral inferences (CQ8–9).

Table 11. Excerpt—competency questions and validation of ontology.

No.	CQ	Category	Title	Result
1	CQ1	Profile Taxonomy	Find the types of driver profiles represented in the ontology	✓

maps the queries to the CQs, demonstrating successful requirement satisfaction.

Prior to evaluation, ChatGPT 4o enhanced ontology with additional data properties, addressing the low attribute richness identified in structural metrics, enabling more complex and meaningful SPARQL queries.

The requests listed in Table 11 directly derive from some of the conceptual requirements defined for the ontology’s development (see Section 1). An excerpt of Table 11 is reported below, while the complete version is available in Appendix A.5.

The results obtained are consistent with the expected answers, confirming the ontology’s correct behavior.

6. Results and Discussion

The ontology underwent a thorough validation process to ensure its quality and reliability.

• Logical Consistency and Constraint Satisfaction (Section 5.1): The ontology passed all consistency checks. No structural anomalies were found, and all OWL axioms were satisfiable. Inferences were correctly computed, confirming compliance with defined constraints and supporting sound deductive reasoning.
• Structural Evaluation (Section 5.2):

  -

  Schema Metrics: The attribute richness is approximately 0.15, indicating a low average number of data properties per class. Despite a broad class base, attribute-level detail is sparse. The inheritance richness is high (0.90), suggesting a predominantly horizontal taxonomy with numerous subclasses per class. Relationship richness (0.33) shows that a third of object properties are explicitly declared, pointing to moderate semantic connectivity. The attribute/class ratio is 0.0, confirming a lack of descriptive data properties. An equivalence ratio of 0.018 indicates limited use of owl:equivalentClass. The axiom/class ratio is 5.59, reflecting a high logical density and good semantic formalization. The inverse property ratio (0.021) reveals few explicitly defined owl:inverseOf properties. The class/relation ratio of 0.74 denotes a class-dense structure relative to relations.

  -

  Graph Metrics: The ontology has 13 root classes, suggesting a modular or multi-domain design. There are 64 leaf classes, denoting a wide but shallow hierarchy. With 77 sibling nodes, the class structure is horizontally diverse. The total hierarchical depth is 160, with an average depth of 2.08 and a maximum depth of 3, indicating a flat structure. Breadth metrics show 77 total siblings and an average breadth of 5.5; the most populated level contains 13 classes. Leaf fan-outness is 0.576, indicating that over half the classes are terminal. A sibling fan-outness of 0.694 implies balanced horizontal distribution. A low tangledness score (0.018) confirms that most classes belong to a single hierarchy. The number of distinct root-to-leaf paths is 77, with an average of 25.67 paths, suggesting high path diversity in class specialization.

• Semantic Similarity Evaluation (Section 5.3): High intra-branch similarity (e.g., between SeatPosition, ClimateControl, InteriorLighting) indicates strong taxonomic coherence. Thematic domains such as DrivingPreferences and MultimediaPreferences exhibit clear modularity. Low similarity between conceptually distant pairs (e.g., BiometricData and SportMode) confirms semantic clarity and functional segregation. Consistent results across two semantic similarity measures (Wu & Palmer [71] and Li et al. [73]) validate the robustness of the conceptual structure.
• SPARQL Queries Evaluation (Section 5.4): The results were consistently aligned with expectations, demonstrating that the ontology effectively supports both descriptive queries and more complex inferences. Queries 1–3 validated the taxonomy and confirmed appropriate distribution of properties. Queries 4–5 tested the ontology’s ability to capture individual preferences and behaviors. Queries 6–9 evaluated semantic constraints (e.g., modifiability, sensitivity, access control). All constraints were correctly inferred, indicating reliable OWL restriction modeling. Queries 10–11 were designed to test the ontology’s ability to support logical inferences. It was possible to (a) automatically associate drivers belonging to specific profiles (Calm and Expert) with the most suitable safety systems; (b) infer the level of accident risk based on personality and driving preferences (i.e., Aggressive and HighSpeed = High Risk). In both cases, the results obtained were consistent with the defined rules.
• Expert Review: During the evaluation process, we involved some experts in ontology engineering for an independent review of the structure and content of the developed model (see ontology development process Figure 1). They noted a lack of data properties, echoing the attribute/class ratio of 0.0. This gap limits descriptive expressiveness and inferencing capability. Following this feedback and with LLM assistance, data properties were added to key classes, enhancing semantic richness and enabling more expressive SPARQL queries.

Considering the detailed ontology development process and its inferential mechanisms, we now compare our methodology with prior approaches (Section 2).

Table 12. Comparative analysis of existing methods vs. proposed approach.

Method	Approach	Strengths of Proposed Method	Limitations of Proposed Method
De Gelder et al. [15]	Object-oriented framework	Full logical validation, complex inference support, multi-domain applicability	Requires formal modeling expertise
Babaei Giglou et al. (LLMS4ol) [16,17]	LLM for ontology learning	Structural and semantic validation, expert review, robust metrics	Higher resource demand
Kommineni et al. [18]	CQ-based generation	Superior logical coherence and hierarchy accuracy	Limited by initial CQ coverage
Crum et al. [20]	Prompt engineering for disjunctions	Full ontological structure management, complex relations handling	Prompting adaptation may be required
Lo et al. [21]	Fine-tuned GPT	Reduces hallucination, increases semantic accuracy	Demands iterative supervision
Mukanova et al. [22]	Text extraction and semantic alignment	Enhanced mapping precision via semantic similarity	Requires expert mapping validation
Tupayachi et al. [23]	Automated generation from documents	High conceptual control and logical consistency	Expert supervision still essential
Mateiu et al. [24]	NLP to description logic	Formal model reliability through reasoners and SPARQL	Sensitive to linguistic variations
Vieira da Silva et al. [25]	Zero-shot capability ontologies	Clear modularity and semantic clarity	Limited in specialized domains
Ciatto et al. [26]	Schema auto-filling	Strong balance of modularity and semantic depth	Relies on initial schema definition
Fernandez et al. [37]	Ontology extension	Precise semantic extensions with structural validation	Less scalable for large extensions

summarizes the key strengths and limitations of our method relative to those in literature.

7. Conclusions

This research proposes a methodology for ontology development leveraging LLMs, specifically ChatGPT-4o, to design an ontology for the personalization and standardization of driver–vehicle interface (DVI) elements based on user profiles, with the objective of enhancing human–machine interaction in assisted and autonomous driving contexts.

The developed ontology identifies the essential components required to represent driver profiles and their influence on DVI configuration, incorporating factors such as individual preferences, driving experience, cognitive and physical capabilities, and contextual parameters.

Advanced prompting techniques were employed to guide ChatGPT-4o, ensuring the generation of a coherent and consistent ontology while mitigating common issues such as redundant class proliferation and inconsistent relationships. The ontology was further expanded through the addition of new classes and relationships, e.g., driver typologies—ensuring scalability and adaptability.

Logical consistency was validated through inference checks, confirming structural correctness and the absence of logical contradictions. The structural metrics indicate a well-organized architecture: a notably high inheritance richness suggests a predominantly horizontal taxonomy with numerous subclasses stemming from a shared superclass. Conversely, lower values in attribute richness and attribute/class ratio point to limited descriptive depth. This deficiency was addressed by enriching key classes (Driver, DriverPreferences, DriverProfile) with additional properties, enhancing the ontology’s expressiveness and enabling advanced semantic queries.

Subsequent SPARQL-based evaluations demonstrated the ontology’s capability to handle both descriptive and inferential queries, managing constraints, access rules, and supporting applied use cases such as driving risk assessment and safety system allocation.

Semantic evaluation via similarity metrics confirmed the model’s taxonomic coherence, modular domain organization, and semantic clarity across heterogeneous concepts. The convergence of results from independent metrics further reinforced the reliability of the analysis. High axiomatic density and low tangledness values indicate well-contextualized classes with minimal multiple inheritance, contributing to a navigable and interpretable ontological structure.

This study represents a significant advancement in the application of AI for knowledge modeling across multiple sectors. This work distinguishes itself by proposing a pragmatic, generalizable, and guided methodology that integrates the generative capabilities of language models with structured human supervision. The core innovation of our approach lies in Table 2, a design tool that formalizes ontological requirements and directs automated generation, ensuring traceability, transparency, and adaptability.

The methodology is supported by a human-in-the-loop process involving two roles: the user, with domain knowledge, who guides ontology construction, and the validator, an ontology expert who performs final consistency and semantic checks.

However, to apply this method in other sectors, we need to adapt the guiding table, inserting questions, answers, and examples relevant to the sector of interest. This specificity of the table represents an expedient that requires experience in the sector to which it belongs to develop ontologies. The application of LLMs, for our case study, demonstrates the potential of this technology to improve the personalization of interfaces and the interaction between drivers and vehicles.

7.1. Limitations

The first criticality concerns the intrinsic dependency on LLMs for ontology generation. Although advanced models such as ChatGPT-4o facilitated the initial construction of the ontological framework, the quality of the output remains highly contingent upon prompt formulation and necessitates expert supervision for review, correction, and optimization of generated classes and relations. This highlights the current need for more robust automated generation methodologies capable of minimizing error margins and reducing manual refinement efforts.

Despite achieving structurally and semantically coherent results, several limitations emerged during both metric analysis and expert evaluation, primarily linked to LLM hallucination phenomena and occasional misinterpretation of prompts. Notably, one significant deficiency involved the limited presence of descriptive data properties within the generated classes. This structural hallucination undermined the ontology’s capacity to adequately model concrete instances, thereby constraining both inferential capabilities and semantic query effectiveness, despite the presence of explicit prompting instructions. This limitation, if not progressively addressed, may have a significant long-term impact on ontology’s ability to support complex scenarios where high descriptive granularity is essential—such as multi-agent interactions, behavioral personalization, or dynamic environmental modeling. Further iterations will need to increase attribute richness to ensure that ontological expressiveness aligns with real-world complexity.

Additionally, the generated taxonomy exhibited an excessively flat hierarchy, reflecting a systematic horizontal expansion of classes. This bias toward shallow taxonomic structures suggests the model’s predisposition to simplify class organization in the absence of stringent hierarchical constraints. Semantic hallucinations are also manifested through insufficient specification of inverse relations and limited definition of equivalent classes. These shortcomings led to redundancies and conceptual overlaps, with LLM failing to explicitly model equivalence and subsumption relationships where appropriate.

A further limitation concerns the current validation approach, which has primarily relied on structural metrics and formal ontology compliance. The ontology has not yet undergone operational validation within real-world vehicular systems. Practical deployment is necessary to reveal potential integration issues, enabling adjustments required for effective implementation in production environments.

Scalability and interoperability represent additional challenges. While the ontology was designed with modular extensibility, its compatibility with existing knowledge bases and AI systems employed in the automotive sector remains unverified. Integration with advanced driver assistance systems (ADASs) and adaptive driver–vehicle interface (DVI) personalization systems must be systematically evaluated.

An additional complexity stems from the accessibility and applicability of existing standards. Although numerous regulations govern driver assistance technologies and personalization systems, these standards are often fragmented, inconsistently documented, or not fully harmonized, complicating their direct incorporation into ontological frameworks. The absence of universally recognized standards may hinder both consistency and industrial adoption of the ontology.

7.2. Future Works

To advance the current research, several future directions can be proposed. First, the ontology will be implemented in advanced AI systems to enable real-time adaptation of DVI elements based on driving conditions and driver states, thereby enhancing personalization and safety. Second, empirical testing will be conducted on vehicles equipped with customizable interfaces to assess the ontology’s practical effectiveness in improving driving experience and safety outcomes. Data collected from real-world deployments will inform iterative refinement of both the structural and semantic components of the ontology.

Furthermore, advanced prompting strategies and automated refinement techniques will be explored, integrating machine learning approaches to improve LLM-generated ontologies while reducing dependence on manual interventions. A comprehensive analysis of existing standards in the automotive and AI domains will be performed to incorporate the most relevant regulatory specifications into the ontology, promoting consistency, compliance, and industrial scalability. Finally, we consider the personalization and safety. Second, empirical testing will be conducted on vehicles equipped with customizable interfaces to assess the ontology’s practical effectiveness in improving the driving experience and safety outcomes. Data collected from real-world deployments will inform iterative refinement of both the structural and semantic components of the ontology.

Finally, further future developments include the reuse and integration of existing ontologies to enrich and standardize knowledge representation; the use of pre-trained models to support and optimize the ontology generation process; the integration of continuous learning mechanisms to dynamically update the ontology based on real-time collected data; and the analysis of a quantitative comparison with manual or traditional approaches, evaluating aspects such as development time, accuracy, and semantic coverage. Expanding on these aspects, the proposed methodology will also be tested across heterogeneous domains, with the goal of further validating its robustness and adaptability to different application contexts.