An Ontology Development Methodology Based on Ontology-Driven Conceptual Modeling and Natural Language Processing: Tourism Case Study

Abstract

Ontologies provide a powerful method for representing, reusing, and sharing domain knowledge. They are extensively used in a wide range of disciplines, including artificial intelligence, knowledge engineering, biomedical informatics, and many more. For several reasons, developing domain ontologies is a challenging task. One of these reasons is that it is a complicated and time-consuming process. Multiple ontology development methodologies have already been proposed. However, there is room for improvement in terms of covering more activities during development (such as enrichment) and enhancing others (such as conceptualization). In this research, an enhanced ontology development methodology (ON-ODM) is proposed. Ontology-driven conceptual modeling (ODCM) and natural language processing (NLP) serve as the foundation of the proposed methodology. ODCM is defined as the utilization of ontological ideas from various areas to build engineering artifacts that improve conceptual modeling. NLP refers to the scientific discipline that employs computer techniques to analyze human language. The proposed ON-ODM is applied to build a tourism ontology that will be beneficial for a variety of applications, including e-tourism. The produced ontology is evaluated based on competency questions (CQs) and quality metrics. It is verified that the ontology answers SPARQL queries covering all CQ groups specified by domain experts. Quality metrics are used to compare the produced ontology with four existing tourism ontologies. For instance, according to the metrics related to conciseness, the produced ontology received a first place ranking when compared to the others, whereas it received a second place ranking regarding understandability. These results show that utilizing ODCM and NLP could facilitate and improve the development process, respectively.

1. Introduction

In recent years, semantic technologies have advanced rapidly. The semantic web is one of such technologies concerned with transforming the Web from a repository of human-readable content to a format that can be easily understood by machines [1,2]. The popularity of semantic data models such as ontologies and knowledge graphs has grown significantly in recent years [3]. Ontologies are considered to be the backbone of the semantic web [4]. Ontology is defined as an “explicit specification of a conceptualization” [5]. Given that ontologies provide context and meaning to data, they are essential for efficient knowledge extraction and reuse. Additionally, they offer a remedy for syntactic and semantic interoperability problems, which hinder efficient information exchange and collaboration among heterogenous systems [6]. Thus, ontologies have been employed in a wide range of applications across different domains [2]. Including, but not limited to, climate policy development [7], robot inspection systems [8], study of terrorism [9], knowledge about digital extortion attacks [10], drones’ semantic trajectories [11], and sentiment analysis [12].

In this context, ontology engineering has lately garnered great attention [13]. It is defined as “the set of activities that concern the ontology development process, the ontology life cycle, and the methodologies, tools and languages for building ontologies” [14]. One of the objectives of this branch of engineering is to offer a method to develop ontologies. For several reasons, developing domain ontologies is a challenging task. One of these reasons is that it is a complicated and time-consuming process [15]. Further challenges and possible future directions have been proposed in [16].

Ontology development methodology provides guidelines about the organization of activities and tasks, the definition of transitions between them, the selection of methods applied in each task, recommendation of the most suitable tools, and so on. Despite the fact that a variety of methodologies have been proposed [4,15,17], there are still many open issues about ontology development that have yet to be answered [13]. New methodologies continue to be introduced as they propose ontology development from different perspectives and focus on different aspects [15]. In brief, there is no common consensus on an ideal methodology; however, the purpose of developing the ontology may aid in the selection of the most suitable methodology.

One of the most essential activities in the process of ontology engineering is conceptualization. It is concerned with recognizing concepts in the real world in order to construct a model of the relevant domain [18]. Enhancing the activity of conceptualization has a significant impact on the final ontology’s quality. The reason for this is that the quality of any model-based artifact is highly constrained by the quality of the model itself [19]. The researchers presented a novel method called ontology-driven conceptual modeling (ODCM) [20], which is defined as the utilization of ontological ideas to construct engineering objects that enhance theory and practice of conceptual modeling. OntoUML is one of the most popular languages in ODCM, which is “a language whose meta-model has been designed to comply with the ontological distinctions and axiomatization of a theoretically well-grounded foundational ontology named UFO (Unified Foundational Ontology)” [21]. UFO is “an axiomatic formal theory based on contributions from Formal Ontology in Philosophy, Philosophical Logics, Cognitive Psychology, and Linguistics” [22].

Natural Language Processing (NLP) is one of the most significant sciences utilized in the semantic web. NLP analyses human natural language in text format using computer techniques to obtain meaningful semantic information [23]. Several NLP methods have been utilized in conjunction with ontologies in many studies, for instance, [24,25,26].

The goal of this research is to propose an enhanced ontology development methodology (ON-ODM). Ontology-driven conceptual modeling (ODCM) and natural language processing (NLP) serve as the foundation of the proposed methodology. The proposed ON-ODM methodology is applied to build a tourism ontology, which will be useful for many applications such as e-tourism. The remaining sections of the paper are organized as follows. The paper begins with a review of the literature. The proposed methodology is then described in detail, followed by the results and discussion. Finally, the paper ends with conclusions and recommendations for further research.

2. Literature Review

Several ontology development methodologies have been defined in the literature. This is because there is no single correct methodology for constructing ontologies, where target application and necessary features aid in the selection of the most appropriate methodology. Therefore, authors competed to suggest methodologies that consider the development process from different perspectives and focus on various aspects. This section summarizes some such methodologies that have been proposed in the past five years.

Table 1. Comparison of ontology development methodologies (ODM) from 2018 to 2023.

ODM	C1	C2	C3	C4	C5	C6	C7	C8	C9	C10	C11	C12	C13	C14	C15	C16	C17	C18	C19	C20
[15], 2023	✓	✓	✓	✓	✓	×	✓	✓	✓	×	✓	✓	✓	×	✓	✓	✓	×	✓	F
[17], 2023	✓	✓	✓	✓	✓	×	✓	×	×	×	✓	×	✓	✓	×	×	✓	✓	✓	S
[13], 2022	✓	✓	✓	✓	×	✓	✓	✓	✓	✓	✓	✓	×	✓	✓	×	✓	✓	✓	S
[27], 2022	✓	×	✓	✓	×	✓	×	×	✓	×	✓	×	×	×	×	×	×	×	×	S
[28], 2022	✓	✓	✓	✓	×	✓	×	✓	×	×	✓	✓	✓	✓	×	×	✓	✓	×	S
[29], 2021	✓	✓	✓	✓	×	✓	✓	✓	✓	×	✓	✓	✓	✓	✓	✓	✓	✓	✓	S
[30], 2021	✓	✓	✓	✓	×	×	✓	×	×	×	×	×	×	×	×	×	✓	✓	✓	S
[31], 2021	✓	✓	✓	✓	×	×	✓	×	×	×	✓	✓	✓	✓	✓	×	✓	✓	✓	S
[32], 2020	×	✓	✓	✓	×	×	✓	×	×	×	✓	×	✓	✓	×	×	✓	✓	✓	F
[33], 2020	✓	✓	✓	×	×	×	✓	×	×	×	×	×	×	×	×	×	✓	✓	✓	S
[34], 2020	✓	✓	✓	×	×	×	✓	×	×	×	×	×	×	×	×	×	✓	✓	✓	S
[35], 2020	✓	×	✓	✓	×	×	✓	×	✓	×	✓	×	×	×	×	×	✓	✓	✓	S
[36], 2020	✓	✓	✓	×	×	×	✓	✓	×	×	✓	✓	✓	×	✓	✓	✓	✓	✓	S
[37], 2020	✓	✓	✓	×	×	×	✓	×	×	×	✓	✓	×	×	×	×	×	×	✓	S
[38], 2019	✓	✓	✓	✓	×	×	✓	✓	✓	×	✓	×	✓	×	×	×	✓	✓	✓	S
[39], 2019	✓	✓	✓	×	×	✓	✓	✓	✓	×	×	×	✓	×	×	×	✓	✓	✓	S
[40], 2019	✓	✓	✓	✓	×	×	✓	×	✓	×	✓	×	×	×	×	×	✓	✓	✓	S
[41], 2019	✓	✓	✓	✓	×	✓	✓	×	×	×	×	×	×	×	×	×	✓	✓	✓	S
[42], 2018	✓	✓	✓	✓	×	✓	✓	×	×	×	×	✓	×	×	×	×	✓	✓	✓	S
[43], 2018	✓	✓	✓	✓	×	×	✓	×	×	×	✓	×	×	×	×	×	✓	✓	✓	S
ON-ODM	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	S

compares 20 methodologies to the proposed ON-ODM. The comparison is based on 20 different criteria that cover all stages of the development process.

Some criteria have been collected from [13,15,29,31,35,36,44], in addition to another set suggested in the current study. An outline of these criteria is given below.

• Domain requirements analysis (C1): analyzes the domain requirements.
• Conceptualization (C2): contains a conceptualization phase.
• Implementation (C3): transforms from model to ontology.
• Instantiation (C4): provides a method for populating the ontology.
• Enrichment (C5): enriches ontology concepts or relations automatically.
• Verification against CQs (C6): verified by answering competency questions.
• Evaluation (C7): applies evaluation techniques to assess the ontology’s quality.
• Maintenance (C8): supports ontology maintenance.
• Documentation (C9): offers comprehensive documentation with the ontology.
• Publication (C10): publishes the ontology online.
• Origins of methodology (C11): is based on well-designed methodologies.
• Reusability (C12): can be easily reused.
• Integration (C13): can be easily integrated with other ontologies.
• Interoperability (C14): concepts can be easily shared with other ontologies.
• Collaborative Construction (C15): supports construction by multiple engineers.
• Localization (C16): supports multiple languages.
• Detailed steps (C17): phases and activities are described in detail.
• Case study (C18): the methodology applied to a case study.
• Tools (C19): utilized tools are described clearly.
• Degree of automation (C20): fully automated (F) or semi-automated (S).

As noticed from Table 1:

• More than 75% from the methodologies provided C1, C2, C3, C4, C7, C17, C18, and C19.
• C11 was offered by 14 methodologies out of 20.
• Between 20% and 50% of the methodologies proposed C6, C8, C9, C12, C13, C14, and C15.
• Fewer than 25% fulfilled C5, C10, C16.
• Only two methodologies applied entirely automated processes. This is due to the fact that fully automated methods have some disadvantages when compared to other methods [27,42]. For instance, they may cause unexpected errors that compromise the integrity of the content.

Thus, the aim of this research is to propose the ON-ODM semi-automatic methodology that supports all the criteria discussed in Table 1.

The proposed methodology has been applied to the tourism domain. In this sector, a wide variety of ontologies have been introduced. The following are some that are accessible for download and will be used later on during the evaluation process:

• HONTOLOGY [45];
• IMHO_EVENTS [46];
• IMHO [46];
• TRAVEL [47].

3. Proposed Methodology

The study proposes an enhanced ontology development methodology (ON-ODM) that offers detailed guidelines for all crucial activities, from requirements specification to ontology assessment. ON-ODM is domain-independent and can be applied to any domain. In this paper, ON-ODM is applied to the context of tourism, because of its significance and impact on promoting the economy of any nation. Egyptian tourism is suggested as a case study due to its richness of tourist cities and monuments, which leads to an abundance of data to be used in the application. Figure 1 depicts the proposed methodology, which is made up of seven major modules. The following subsections provide a detailed explanation of these modules.

3.1. Requirements Acquisition Module

The aim of this module is to acquire the list of requirements that the output ontology should fulfill. In ON-ODM, the acquisition of requirements begins with the identification of the domain’s main information and user needs. It is followed by an analysis of these needs, and the final list of ontology requirements is specified after that. This module’s input consists of the available domain documentation in a variety of forms, in addition to related online resources and knowledge about the domain from experts. The output of this module is the list of ontology requirements in three different forms, which will be covered in further detail in the next subsections.

3.1.1. Identification

In this step, at first, the ontology engineer should list all of the resources that are accessible so that they can be used to obtain the necessary information and requirements. These resources include the following:

• Related domain documentation including textbooks, reports, HR documents, proposals, and more.
• Glossaries, descriptive dictionaries, and other lexicographic resources.
• Related online resources such as portals, videos and other Internet materials.
• Interviews with domain experts.

Then, all the above resources are utilized to extract the main information about the domain and the user needs that should be addressed later by the ontology. Natural language statements are used to outline this description in a document. A document called the Domain Description Document (DDD) is proposed. This document’s significance lies in several points:

• In the subsequent activities, it will aid in defining the specifications that should comprise the ontology.
• At the end, it will be employed to evaluate the ontology and determine whether or not it fulfilled the customer expectations for which it was created.
• It will be included in the ontology documentation, for its main role in helping to elucidate the domain, which will facilitate the use of the ontology in various applications.

Table 2. The suggested DDD applied to the tourism domain.

Domain:

Tourism

Description:

A sector of economy that deals with all aspects of travel, including activities, services, products, and more…..

Goals:

Visitor satisfaction. Community development. Resource protection. Economic development.   ……….

Scope:

Egyptian tourism

User Requirements:

Requirement 1: Buy museum ticket   Roles: Citizen, Tourism company   Description: The user shall be able to purchase and print a museum ticket online.  Requirement 2: Browse directory   Roles: Citizen   Description: The user shall be able to browse the directory of (tourism companies, hotels, museums, and so on), in order to know their contact information. ………..

Resources:

…….

shows the suggested DDD template applied to the tourism domain

This is a sample of how the DDD can be used to describe the domain and express the user requirements that reflect their final expectations.

3.1.2. Analysis

Currently, the DDD has a wide range of user requirements that have been listed as points. Now, it is time to analyze these needs and turn them from their present form into a set of distinct and well-defined functions that are devoid of repetitions and impractical requirements. The use case diagram can be helpful for this target. It is one of the UML diagrams that focuses on the system requirements as seen from the user’s perspective and expresses them as system functionalities. Additionally, it shows the interaction between users (actors) and functions (use cases). The use case’s most significant advantage is that it offers a technique to represent the domain in a diagram that is easy for different roles to comprehend, review, and evaluate. Any of the UML design tools can be utilized in this activity, in the tourism case study, the Rational Rose tool [48] is used.

A portion of the citizen actor use case diagram is illustrated in Figure 2. It includes 15 of the total number of functions that a citizen is capable of performing. For instance: “Obtain photographic permit”, “Organize activities and events”, “Browse directory”, and so on. The figure illustrates that twelve use cases are initiated directly by the citizen, while three are extended from other use cases.

3.1.3. Specification

In this activity, the previous list of refined requirements will be transformed into a final set of competency questions (CQs). This approach, which was first described in [49], is one of the widely used methods for specifying ontology functional requirements. These questions are crucial for guiding the ontology development process, since the ontology in its complete version must be capable of answering them. Furthermore, they can be combined with expected results to be employed later in the ontology’s evaluation.

Table 3. Proposed competency questions (CQs) for the Egyptian tourism case study.

CQ1-1: What is the available information about “Tutankhamun”?

CQ1-2: How many antiquities were recovered back to Egypt?

CQ1-3: Where are the “Pyramids” located?

…....

CQ2-1: What and where are the historical museums?

CQ2-2: Where is the “Grand Egyptian Museum” located?

CQ2-3: What are the different categories of museums available in Egypt?

…....

CQ3-1: What are the available tourism companies and their addresses?

CQ3-2: What is the contact information of “Miracle” company?

CQ3-3: What are the full details about trips visiting “Marsa Alam”?

…....

CQ4-1: What are the available hotels in “Luxor”?

CQ4-2: What are the rates per night in “Sheraton” hotel?

CQ4-3: Which hotels have diving centers?

…....

CQ5-1: What are the full details about “The Pharaohs Golden Parade” event?

CQ5-2: What are the events that will occur in year 2023?

CQ5-3: What are the festivals that take place in Egypt?

…....

displays sample of the proposed CQs for the Egyptian tourism case study. They are categorized into the following five main categories:

• Antiquities;
• Museums;
• Tourism Companies;
• Hotels;
• Events.

At this point, the requirements acquisition module is complete, and three alternative versions of the requirements (DDD, use case diagram, and CQs) are available.

3.2. Ontology Development Module

In this module, the ontology is constructed on the basis of previously collected requirements. ON-ODM’s development module adheres to the fundamental structure proposed in METHONTOLOGY [50], as this research places the same emphasis on the conceptualization activity. The module consists of four main activities: Specification, Conceptualization, Formalization, and Implementation. They are explained in further detail though the next subsections. This module’s result is the initial version of the ontology.

3.2.1. Specification

The initial stage entails describing the ontology data in a textual document using natural language. The ontology metadata vocabulary (OMV) [51] is a typical suggestion for the ontologies’ description. It enables ontologies to be easily accessed, exchanged over the Internet, and integrated across different domains. The Egyptian tourism ontology’s OMV is listed in

Table 4. The proposed tourism domain ontology ‘s OMV.

Egyptian Tourism Ontology Metadata Vocabulary OMV
Ontology Name:	Egyptian Tourism Ontology (EGYTOUR)
Location:	Ain Shams University, Cairo, Egypt
Party (Organization):	Faculty of Computer and Information Sciences
License Model:	Academic research
Ontology Type:	Domain Ontology
Ontology Domain:	Tourism
Ontology Engineering Tool:	OntoUML Lightweight Editor (OLED)
Ontology Language:	OWL
Ontology Syntax:	rdf xml Syntax
Ontology Task:	Describes data and services provided by Egyptian tourism. EGYTOUR represents a semantic description of domain aspects such as concepts, regulations, services, and organizational chart.
Ontology Engineering Methodology:	ON-ODM methodology for building domain ontologies.
Source of Knowledge:	Non ontological resources: (domain documentation, online resources such as “Egyptian tourism portal”, knowledge from domain experts, and corpora).
	Ontological resources: (existing ontologies)

.

3.2.2. Conceptualization

This activity is one of the strengths of the proposed methodology, because of its reliance on ODCM, which applies the ontological theories to enhance conceptual modeling [20]. The activity involves designing the model of the target domain, using one of the ODCM languages. The conceptual model of the proposed case study is designed using OntoUML language [21], whose class and relationship stereotypes are elaborated upon in [52]. OntoUML reliance on UFO foundational ontology aids in the application of a common structure that guarantees easy reusability, integration, and interoperability. The OLED [53] tool is utilized, which is a model-based environment for formalizing, developing, and testing OntoUML models.

Due to its quite large size, just two portions of the Egyptian tourism conceptual model are depicted in Figure 3 and Figure 4. Figure 3 shows a sample of the various relations that the citizen ROLE is capable of performing. For instance, the Citizen can:

• Check various SUBKINDs of Internal News including (Job Vacancies, Training Courses, Workshops, and Scholarships).
• Buy Ticket of Archaeological Site or Museum such as (Scientific, Archaeological, and so on).
• Watch Videos.
• Obtain Bulk Visitor Permit.
• Obtain Photographic Permit.
• Organize Activities and Events.
• Browse several SUBKINDs of Directory such as (Tourism Companies, Hotels, and so on).

In Figure 4, the Consumer ROLEMIXIN can make two different CATEGORIES of Reservations to:

SUBKINDs of Place including (Hotel, Resort, Restaurant, Cafe, and Cruise). Some Reservations have a Type like (Full, Half, Breakfast, and All inclusive). Hotels are composite of Floors, which are made up of Rooms. The Room may be (Single, Double, Triple, or Suite).

SUBKINDs of Transportation such as (Airplane, Ship, Bus, and Car). And the Airplane is composed of many Flights.

For both Reservations, a Bill is issued. This Bill is associated with a Payment.

3.2.3. Formalization

The prior activity’s model is expressed in a modeling language that is only comprehensible by humans. The purpose of this activity is to transform this form into a new one that is interpreted by computer programs. This can be easily performed using the OLED code generation feature. The outcome is an ontology represented by Web Ontology Language (OWL), which is one of the most well-known ontology representation languages. Currently, there is an ontology called EGYTOUR that comprises 228 classes.

3.2.4. Implementation

In this activity, the ontology engineer populates the ontology by manually adding new data properties and individuals. Then, they are assigned to the appropriate ontology classes. This can be accomplished with the help of any ontology editor. In the proposed case study, the protégé tool [54] was used. It offers many useful features, the most essential of which is that it supports collaborative construction. The resources defined in Section 3.1.1 assist the ontology engineer in obtaining the necessary information. Due to the case study’s excessive amount of data, only a portion of it is used in this activity. This portion consists of 246 data properties and 1602 individuals. Figure 5 and Figure 6 depict a sample of EGYTOUR data properties and individuals, respectively.

3.3. Ontology Enrichment Module

Unlike many previous methodologies, ON-ODM considers the enrichment module as an essential step in developing ontologies. This is because it assists the ontology engineer with suggestions for classes and relationships that were missing in the initial version of the ontology. There are multiple approaches to enrich ontologies; ON-ODM suggests one that makes use of NLP techniques. Another method that depends on ontology matching was proposed in an earlier work [55]. The scope of this study is to enrich the ontology with relationships extracted from corpus. The module consists of three main activities: Preprocessing, Relations Extraction, and Enrichment. The module’s input is the initial version of the ontology in addition to the corpus documents. An enriched version of the ontology is the output. The module is thoroughly explained in the following sections.

3.3.1. Preprocessing

The names of the ontology classes should undergo some preparation before extracting the new relations from corpus. The preprocessing step is essential, because only the words that are determined at this stage will go through the subsequent activities. In ON-ODM, the preprocessing activity consists of four steps:

• Tokenization: segmenting class name into words.
• Non-alphabetic removal: removing numbers and special characters.
• Stop words removal: eliminating a list of commonly used words that contain very little beneficial information.
• Lemmatization: retrieving the base form of each word.

In EGYTOUR ontology, the preprocessing is fulfilled via the SpaCy library [56], which is a Python open-source library for advanced NLP techniques. It assists in developing applications that comprehend large volumes of text. SpaCy can be used in text preprocessing, natural language understanding, and information extraction.

Table 5. Examples of the EGYTOUR ontology’s preprocessing results.

Class Name	Output
Museum-Ticket	Museum
	Ticket
Activities-and-Events	Activity
	Event
Indoor-Offices	Indoor
	Office
Fees	Fee
Tourist-Relations	Tourist
	Relation
Directors-Affairs	Director
	Affair

lists some examples of the results of this activity.

3.3.2. Relations Extraction

In this activity, a text corpus is used to extract new candidates for relationships between classes. Any of the numerous NLP-based techniques for information extraction from text may be employed in this activity. Considering that the NLP is not the main focus of this study, a simple and straightforward method is suggested in the tourism case study. The SpaCy library [56] is used for:

• Sentence segmentation: dividing the text into sentences.
• Searching for class lemma: looking up the class in the text.
• Results Tokenization: tokenizing a sentence into words.
• Part-Of-Speech (POS) tagging: assigning type to tokens such as (noun, verb …and so on).
• Verbs extraction: extracting verbs to be used later in naming extracted relations.

The results of this activity are a list of candidates for each class. In addition to the creation of a recommended list of verbs that can be used for identifying relationships. The Open American National Corpus (OANC) [57] is used to identify those new candidates for the EGYTOUR ontology. OANC is an entirely open repository of American English electronic texts. It has 8832 files with a total of approximately 15 million words. As is well known, dealing with such large corpus is not an easy task. It is one of the significant challenges confronting NLP models. For that reason, only a sample of the EGYTOUR ontology is used to apply the extraction approach. This sample consists of 15 classes, yielding 1661 extracted candidates.

Table 6. Examples of the EGYTOUR ontology’s relations extraction results.

Class Name	Candidate	Verbs
Museum-Ticket	A combined ticket covers all the sights in the palaces, gardens, and museums	cover
Museum-Ticket	Some tickets to The Phantom Menace will, indeed, be sold in advance and no doubt be snapped up by scalpers	sellsnap
Car	The man would get the cars	get

displays two candidates returned from the extraction step.

The preprocessing and relations extraction activities are both outlined in Algorithms 1 and 2.

Algorithm 1. Relations Extraction from Corpus—Main Algorithm
INPUT: Proposed ontology (proposedonto)INPUT: Corpus documentsOUTPUT: List of occurrences for ontology classes (occlist)BEGIN
1	classeslist ← proposedonto.GETCLASSES()
2	LOAD corpus documents INTO documentslist
3	FOR EACH c IN classeslist DO
4	name ← c.GETCLASSNAME()
	//Preprosessing
5	name.REMOVESTOPWORDS()
6	name.REMOVENONALPHABETIC()
7	lemma ← name.GETLEMMA()
8	FOR EACH doc IN documentslist DO
//Call Algorithm 2 to get class occurrences in corpus document
9	occlist ← GETOCCURRENCES(lemma,doc)
10	END FOR
11	END FOR
12	RETURN (c,occlist)
END

Algorithm 2. Class Occurrences Extraction from Document
INPUT: Lemma of the ontology class (lemma)INPUT: Corpus document (doc)OUTPUT: List of document statements in which the class occurred BEGIN
	//Sentence Segmentation
1	senlist ← doc.GETSENTENCES()
2	FOR EACH s IN senlist DO
3	IF exists(lemma,s) THEN
	//POS tagging
4	POSTAG(s)
5	verbs ← s.EXTRACTVERBS()
6	outputlist.ADD (lemma, doc, s, verbs)
7	END IF
8	END FOR
9	RETURN (outputlist)
END

3.3.3. Enrichment

In this activity, the ontology engineer decides the appropriate action towards each candidate. It is also possible to consult domain experts to benefit from their guidance about the correct decision. Thus, the intervention of a human in this step is crucial in order to avoid ambiguity and redundancy. The engineer approves the candidate if: (1) new, (2) meaningful, and (3) both classes exist in the ontology. While they reject the candidate if: (1) the relation already exists in the ontology, (2) has no meaning, or (3) one of the classes is not defined in the ontology. The approved candidates are added to the ontology as object properties between the participating classes. For instance,

Table 7. Examples of the EGYTOUR ontology’s enrichment results.

Candidate	Actions	Reasons
Cover	Approved Add new object property between “Ticket” and “Place” classes
sell snap	Rejected Rejected	Already defined Scalper class does not exist
get	Approved Add new object property between “Person” and “Car” classes

shows the actions performed with examples from Table 6.

As a result of the enrichment process, 71 additional object properties are defined for the 15 classes specified in the previous activity. The metrics of the most recent version of the EGYTOUR ontology are illustrated in Figure 7.

3.4. Ontology Assessment Module

There are many approaches for measuring the quality of the constructed ontology from different perspectives. Summaries of these approaches were proposed in many papers, such as [58,59,60,61,62,63]. The ontology engineer decides the best-fitting approach for each situation. In ON-ODM, two different approaches are suggested: (1) CQ-based verification and (2) Metric-based evaluation. Both approaches have many advantages, including:

• Cover different quality dimensions (expressiveness, accuracy, understandability, cohesion, and conciseness).
• Easily applied.
• Flexible and adaptable for application in a variety of contexts.

They will be described in depth in the next sections.

3.4.1. CQ-based Verification

In this method, the ontology is verified against a collection of predefined criteria, which are represented in the form of competency questions. This approach aids in evaluating the expressiveness criteria [59], that depends on the ontology’s ability to provide answers to competency questions. As the process of CQs specification was already a main step (Section 3.1.3) in ON-ODM, this will facilitate its application in assessing the produced ontology. In the current step, the ontology engineer writes SPARQL queries to answer CQs, executes the queries on the produced ontology, and then compares the outcomes with the expected results, which were also defined in Section 3.1.3.

Table 8. Examples of EGYTOUR’s SPARQL queries.

CQ	SPARQL Query
CQ1-1	SELECT ?TutText      WHERE      {        tour:Tutankhamun tour:O-hasdescription ?Description.        ?Description tour:hasText ?TutText.      }
CQ2-1	SELECT ?Historical ?Governrate ?Description      WHERE      {        ?Historical tour:O-inLocation ?Loc.        ?Loc tour:O-inGovernrate ?Governrate.        ?Historical tour:O-hasdescription ?Desc.        ?Desc tour:hasText ?Description.      }
CQ3-1	SELECT ?Company ?Address      WHERE      {        ?Company rdf:type tour:TourismCompany.        ?Company tour:hasAddress ?Address.      }
CQ4-1	SELECT ?Hotel      WHERE      {        ?Hotel rdf:type tour:Hotel.        ?Hotel tour:O-inLocation ?Loc.        ?Loc tour:O-inGovernrate tour:Luxor.      }
CQ5-1	SELECT ?Day ?Month ?Year ?DescText      WHERE      {        ?Event rdf:type tour:PromotionalEvent.        tour:The_Paraohs_Golden_Parade        tour:O-hasdescription ?Description.        ?Description tour:hasText ?DescText.        ?Event tour:inDay ?Day.        ?Event tour:inMonth ?Month.        ?Event tour:inYear ?Year.      }

provides some examples of SPARQL queries suggested to evaluate the EGYTOUR ontology.

3.4.2. Metric-Based Evaluation

The second approach is based on the computation of ontology quality metrics. Several metrics correlated to different ontology dimensions have been developed. The author of [60] offers a free online platform called OntoMetrics [64] for metric definition and calculation. In the proposed case study, OntoMetrics was used to calculate 11 different metrics, which are categorized into three groups (Schema, Knowledgebase, and Graph). Further information about calculation of the utilized metrics is provided in

Table 9. OntoMetrics equations.

Metric	Equation		Description
Attribute Richness (AR)	$\mathrm{AR}=\frac{\left|\mathrm{att}\right|}{\left|\mathrm{C}\right|}$	(1)	|att| is the total number of attributes |C| is the total number of classes in the ontology
Inheritance Richness (IR)	$\mathrm{IR}=\frac{\left|\mathrm{H}\right|}{\left|\mathrm{C}\right|}$	(2)	|H| is the number of subclass relations |C| is the total number of classes
Relationship Richness (RR)	$\mathrm{RR}=\frac{\left|\mathrm{P}\right|}{\left|\mathrm{H}\right|+\left|\mathrm{P}\right|}$	(3)	|P| is the number of non-inheritance relations |H| is the number of inheritance relations
Average Population (AP)	$\mathrm{AP}=\frac{\left|\mathrm{I}\right|}{\left|\mathrm{C}\right|}$	(4)	|I| is the total number of instances of the knowledge base |C| is the total number of classes
Class Richness (CR)	$\mathrm{CR}=\frac{\left|\mathrm{C}’\right|}{\left|\mathrm{C}\right|}$	(5)	|C’| is the number of classes in the knowledge base |C| is the total number of classes
Absolute Root Cardinality (ARC)	$\mathrm{ARC}={\mathrm{n}}_{\mathrm{ROO}\subseteq \mathrm{g}}$	(6)	$n_{ROO\subseteq g}$ represents the number of elements in the set of root nodes ROO in the directed graph g
Absolute Leaf Cardinality (AC)	$\mathrm{AC}={\mathrm{n}}_{\mathrm{LEA}\subseteq \mathrm{g}}$	(7)	$n_{LEA\subseteq g}$ represents the number of elements in the set of leaf nodes LEA in the directed graph g
Average Depth (AD)	$\mathrm{AD}=\frac{1}{{\mathrm{n}}_{\mathrm{P}\subseteq \mathrm{g}}}{\displaystyle \sum }_{\mathrm{j}}^{\mathrm{P}}{\mathrm{N}}_{\mathrm{j}\in \mathrm{P}}$	(8)	P represents the set of paths in the directed graph g $n_{P\subseteq g}$ is the number of elements in P $N_{j\in P}$ is the number of elements on the path j.
Maximum Depth (MD)	$\mathrm{MD}={ \mathrm{N}}_{\mathrm{j}\in \mathrm{P}}\forall \mathrm{i}\exists \mathrm{j}\left({\mathrm{N}}_{\mathrm{j}\in \mathrm{P}} \ge { \mathrm{N}}_{\mathrm{i}\in \mathrm{P}}\right)$	(9)	$N_{j\in P}$ is the number of elements on the path j $N_{i\in P}$ is the number of elements on the path i which belong to the set of paths P in the directed graph g
Average Breadth (AB)	$\mathrm{AB} \frac{1}{{\mathrm{n}}_{\mathrm{L}\subseteq \mathrm{g}}}{\displaystyle \sum }_{\mathrm{j}}^{\mathrm{L}}{\mathrm{N}}_{\mathrm{j}\in \mathrm{L}}$	(10)	L represents the set of levels in the directed graph g $n_{L\subseteq g}$ is the number of elements in L $N_{j\in L}$ is the number of elements on the level j.
Maximum Breadth (MB)	$\mathrm{MB}={\mathrm{N}}_{\mathrm{j}\in \mathrm{L}}\forall \mathrm{i}\exists \mathrm{j}\left({\mathrm{N}}_{\mathrm{j}\in \mathrm{L}} \ge { \mathrm{N}}_{\mathrm{i}\in \mathrm{L}}\right)$	(11)	$N_{j\in L}$ and $N_{i\in L}$ are the number of elements on the level j and i respectively that belong to the set of levels L in the directed graph g

. As indicated in [65], these metrics are correlated to four ontology dimensions, as shown below:

• Accuracy: Equations (1)–(3) and (8)–(11)
• Understandability: Equation (7)
• Cohesion: Equations (6) and (7)
• Conciseness: Equations (4) and (5)

3.5. Publication

The goal of this activity is to create a translation file for the final version of the ontology and then publish it online. This activity is strongly suggested, so that the constructed ontology supports localization and becomes available to others. Furthermore, the OMV suggested in Section 3.2.1 facilitates the ontology’s access and exchange over the Internet. The current version of the EGYTOUR ontology is available only in English. However, for the final release, an Arabic translation file will be created. Web Protégé [66] can be used to easily accomplish the publication activity.

3.6. Maintenance

This module handles making any necessary updates or corrections to the ontology. This occurs in two cases: after evaluation or after publishing the online version. Such updates may be required, as it is possible that the ontology might lack certain domain knowledge or contain some errors.

3.7. Documentation

The ON-ODM methodology gives the utmost importance to documentation. Since the first activity, many documents have been presented in different forms. The documentation activity continues until the completion of the ontology and its publication on the Internet with documents that explain all of its components to facilitate ontology reusability, integration, and interoperability.

4. Results and Discussion

The objective of this section is to list and discuss the evaluation results of the ontology that has been developed using the proposed methodology (ON-ODM).

4.1. CQ-Based Evaluation Results

The EGYTOUR’s SPARQL queries defined in Section 3.4.1 were executed on Protégé [54]. These queries represent one question per each CQ group defined by the domain experts in Section 3.1.3. Figure 8, Figure 9, Figure 10, Figure 11 and Figure 12 show how EGYTOUR was able to successfully answer all queries.

4.2. Metric-Based Evaluation Results

The OntoMetrics results of the EGYTOUR ontology are displayed in

Table 10. OntoMetrics results.

Ontology	Classes	AR	IR	RR	AP	CR	ARC	AC	AD	MD	AB	MB
HONTOLOGY	284	0.1092	0.9613	0.3209	0	0	17	247	2.7254	5	7.375	29
IMHO_EVENTS	88	3.9886	0.9773	0.6371	1.4886	0.0114	2	87	1.9773	2	44	86
IMHO	138	4.3043	0.9855	0.68	1.4638	0.0072	2	137	1.9855	2	69	136
TRAVEL	35	0.1143	0.8571	0.434	0.4	0.2286	12	24	2.0833	4	3	12
EGYTOUR	228	1.0789	1.693	0.3216	7.0263	0.4605	4	189	3.135	6	5.7805	69

. Furthermore, four more tourism ontologies were downloaded; (HONTOLOGY [45], IMHO_EVENTS [46], IMHO [46], and TRAVEL [47]). Table 10 compares the OntoMetrics results of the five ontologies. Whereas

Table 11. Accuracy-correlated metrics.

Ontology	AR	IR	RR	AD	MD	AB	MB	AVG	Rank
HONTOLOGY	0.1092	0.9613	0.3209	2.7254	5	7.375	29	6.5	4
IMHO_EVENTS	3.9886	0.9773	0.6371	1.9773	2	44	86	19.94	2
IMHO	4.3043	0.9855	0.68	1.9855	2	69	136	30.71	1
TRAVEL	0.1143	0.8571	0.434	2.0833	4	3	12	3.21	5
EGYTOUR	1.0789	1.693	0.3216	3.135	6	5.7805	69	12.43	3

,

Table 12. Understandability-correlated metrics.

Ontology	AC	Rank
HONTOLOGY	247	1
IMHO_EVENTS	87	4
IMHO	137	3
TRAVEL	24	5
EGYTOUR	189	2

,

Table 13. Cohesion-correlated metrics.

Ontology	ARC	AC	AVG	Rank
HONTOLOGY	17	247	132	1
IMHO_EVENTS	2	87	44.5	4
IMHO	2	137	69.5	3
TRAVEL	12	24	18	5
EGYTOUR	4	189	96.5	2

and

Table 14. Conciseness-correlated metrics.

Ontology	AP	CR	AVG	Rank
HONTOLOGY	0	0	0	5
IMHO_EVENTS	1.4886	0.0114	0.75	2
IMHO	1.4638	0.0072	0.74	3
TRAVEL	0.4	0.2286	0.31	4
EGYTOUR	7.0263	0.4605	3.74	1

show the EGYTOUR metrics correlated to the four dimensions mentioned in Section 3.4.2.

As displayed in Table 10, EGYTOUR is ranked first in the IR, AP, CR, AD, and MD metrics, second in AC, third in AR, ARC, and MB, and fourth in RR and AB.

Low values of AB and MB indicate that the ontology concentrates on the vertical rather than the horizontal modeling of hierarchies. This can be improved by defining additional classes at the same level (siblings).

In EGYTOUR, only a sample of the data properties and extracted relations were used, as mentioned in Section 3.2.4 and Section 3.3.2, respectively. Applying the complete case study data will raise the AR and RR values.

Regarding the ARC metric, it counts the number of roots that do not receive is-a relations. Therefore, EGYTOUR’s ARC value is low because it contains numerous is-a relations.

Accuracy-correlated metrics measure the degree to which the ontology represents the real-world domain [65]. As illustrated in Table 11, EGYTOUR placed third in the average of accuracy-related metrics due to low AR, RR, AB, and MB values. As mentioned above, increasing those metrics will improve EGYTOUR’s rank.

Understandability-correlated metrics determine the comprehension of the elements of the ontology [65]. According to Table 12, EGYTOUR is the second-ranked ontology. This is due to the high value of AC.

Cohesion-correlated metrics refer to the degree to which the classes in the ontology are related to one another [65]. As seen in Table 13, EGYTOUR has a high average of these metrics, indicating that classes are strongly related.

The degree to which the ontological information is useful is measured using conciseness-correlated metrics [65]. Table 14 shows that among ontologies, EGYTOUR has the greatest average. This means that EGYTOUR does not provide any unnecessary or duplicate information.

5. Conclusions

Ontologies are widely used in a variety of applications and domains. Nonetheless, developing domain ontologies is a difficult and time-consuming process, which is a significant challenge. Many ontology development methodologies have already been proposed; however, there are still certain activities that have not yet been covered and others that could be enhanced. Furthermore, the scarcity of details and applications provided with the methodologies makes most of them challenging to put into practice. In this article, an enhanced ontology development methodology called (ON-ODM) is proposed. The article offers four main contributions:

• ON-ODM concentrates on the requirements acquisition module, which contributes significantly to the final outcome. Therefore, the requirements are gathered from different perspectives and presented in three different forms (Domain Description Document (DDD), use case diagram, and competency questions).
• ON-ODM recommends ODCM for the conceptualization phase, which improves the conceptual modeling by incorporating the ontological theories when building the engineering artifacts.
• ON-ODM considers enriching ontologies as a main step in ontology development cycle, so it suggests an NLP technique to extract from corpus a list of new candidates for relations between classes.
• A comprehensive case study in the field of tourism is applied. To facilitate the process for others to apply ON-ODM, it is backed with thorough details at each stage. The created ontology was assessed using two different approaches.

In the tourism case study, a portion of data was applied. However, during the application of the complete case study data, the below challenges might be encountered:

• The process of populating the ontology with manually extracted individuals.
• The large number of candidates returned during the process of relations extraction, which places a burden on the ontology engineer while reviewing and selecting the approved candidates.

In future work, there are several directions that can improve the proposed work. For instance, utilizing different techniques of advanced NLP and observing how this can affect the extracted list of candidates and, subsequently, the developed ontology. As well as applying other approaches for ontology evaluation, such as an application-based approach. Finally, investigating ON-ODM in terms of dimensions such as efficiency, ease of use, and adaptability to different and more complex domains.