Comparative Analysis of Methodologies for Domain Ontology Development: A Systematic Review

Interlocking Institutional Worlds (IWs) is a concept explaining the need to interoperate between institutions (or players), to solve problems of common interest in a given domain. Managing knowledge in the IWs domain is complex, but promoting knowledge sharing based on standards and common terms agreeable to all players is essential and is something that must be established. In this sense, ontologies, as a conceptual tool and a key component of knowledge-based systems, have been used by organizations for effective knowledge management of the domain of discourse. There are many methodologies that have been proposed by several researchers during the last decade. However, designing a domain ontology for IWs needs a welldefined ontology development methodology. Therefore, in this article, a survey has been conducted to compare ontology development methodologies between 2015 and 2020. The purpose of this survey is to identify limitations and benefits of previously developed ontology development methodologies. The criteria for the comparison of methodologies has been derived from evolving trends in literature. Our findings give some guidelines that help to define a suitable methodology for designing any domain ontology under the domain of interlocking institutional worlds. Keywords—Knowledge management; interlocking institutional worlds; domain ontology; comparison of methodologies; ontology


I. INTRODUCTION
A social reality has elements, and each element is called an institutional fact. For example, in a context A, a physical reality B will be titled as an institutional fact C. The name, marital status and citizenship of a person are examples of institutional facts. Speech act are formal statements created by officials of organizations. These speech acts create and destroy institutional facts. The nomination is a speech act performed by parents who register the birth of a child in a government register. Laws and regulations are created by acts of different branches of government. For example, two institutional facts, wife and husband, are created by the marriage speech act. This speech act destroys two institutional facts such as an unmarried women and a single man. Speech acts can also be used in creating institutions. For example, any positive physical posture as a speech act may or may not be positive in another area (jurisdiction). Institutional reality may be immaterial, but it is still real. The financial crisis of the subprime mortgages of 2008 had at least an impact on the world as the undeniably physical tsunami of 2004.
Furthermore, it often happens that two or more parties participate in a speech act, for e.g., a marriage involves two persons, a husband and a wife. Olympic Games as a speech act, requires participation of several institutional facts. International Olympic Committee (IOC) as a supervisory body, which creates committees (national Olympic committees -NOCs) at national level. And each NOC manages Olympic teams and venues as directed by the IOC. An organizing committee (OCOG) for particular Olympic Games is created for a selected area (city) with one or multiple venues. Independent national sports federations follow rules spoken by international sports federations. The IOC provides policies for athletes, NOCs and OCOGs. Finally, it is necessary for sports federations to define sport rules that allow awarding of medals (bronze, silver and gold) for all Olympic Games. This is problematic for tournament-oriented sports like tennis, which usually have a winner and a loser in the final game. Therefore, these sports generally take place even if there is no third place in their games. The bronze medal, in Olympic events, is an element of fixed reality and this may not be true in other institutions.
In this context, if we define the institutional world as the set of types of speech acts and instances that a given institution is authorized to carry out, we can say that the institutional worlds interlock if they are connected in the manner indicated above. This conceptualization that includes both endurants and perdurants, helps in interoperability of information systems.
Semantic web, as a machine-readable web, needs ontologies as its primary and most important component. Ontology describes conceptions and their associations in the domain of discourse [1]. Knowledge based applications require ontologies and they serve as formal models and machine understandable description of a domain. Ontologies help in sharing domain knowledge to other relevant or irrelevant domains. For example, [2] test how sharing of knowledge can improve employee individual performance as well as team performance. Due to the distributed nature of organizational knowledge, the Knowledge based applications, with the help of ontologies, must be able to integrate knowledge of heterogeneous sources and present an overview of the knowledge available in the organization [3]. In this context, finding a suitable ontology for a domain is one of the bigger research challenges [4]. Ontologies, as a conceptual tool and key component of knowledge-based systems, have been used by organizations, for effective knowledge management of the domain of discourse. In the past decade, investigation and development in ontology has had a large stimulus, the industry has shown an interest in developing novel applications in semantic technology which have resulted in the wide adoption of ontology-based solutions by government, academia and commercial industry. In this context, ontology-based solutions with improved knowledge management help in better decision making. Furthermore, ontology approach makes it easy to share conceptualization of a domain [1], and this sharing offers more opportunities for stakeholders to solve their real-time problems.
A single medium-sized organization can have more than 1000 information systems. Most organizations interact with hundreds of others in the supply chain and other relationships. For example, the UK National Plan for National IT Health Services mentioned in the introduction, attempts to integrate hundreds of thousands of information systems. Our discussion above on interlocking institutional worlds shows that almost all applications involve multiple institutional worlds belonging to different institutions that interlock in complex ways. For now, the construction of a domain ontology for such a large and complex IWs domain (e.g. waste management, semantic Web, Olympic Games, postal codes, preparation of maps and governance of geographic information and flood management) is also difficult, laborious and time consuming.
The analysis of developed ontologies, and methodologies for developing ontologies, help us gain an understanding of ontology engineering. For example, a survey conducted in [5] analyzed ontology related activities of the schema.org community. However, this survey did not discuss the impact of methodologies on ontology development and did not compare their ontology engineering efforts with others. It should be mentioned here that our survey has comparison criteria different than [5]. We compare methodologies based on domain analysis, conceptualization, level of detail, collaborative construction, implementation, evaluation, instantiation, maintenance, documentation, ontology localization, support for reusability, support for integration, support for interoperability, resource estimation human, example of application/project and methodology rooted in established methodologies. Author in [5] included some parameters with respect to the above-mentioned criteria. Therefore, the design of a domain ontology for the IWs domain requires a well-defined ontology development methodology. In this context, we write this paper to survey and compare with criteria, which we think are important, for proposing a wellestablished methodology for designing domain ontology for the IWs domain. This survey will help us find missing components in developed methodologies for ontology development.
With this in mind, the purpose of this research is to propose a methodology for the development of domain ontology for the IWs domain. Consider a question that arises from the emphasis on developing ontology for IWs domains: How ontology development methodology can be proposed to design a domain ontology of IWs?
This section deals with an overview of the research, followed by Section 2 which outlines the literature of this study. Section 3 presents the review method, Section 4 is about discussions and lastly, Section 5 is the conclusion of this article.

A. Interlocking Institutional Worlds (IWs)
Interlocking Institutional Worlds (IWs) is about interagency collaboration involving multidisciplinary teams, which is an increasingly popular strategy for innovation, as it offers broader ideas and views. IWs are defined as a set of organizations working together to solve a common problem at the domain level [6, 7 and 8]. The theoretical foundations of the concepts of IWs are strongly anchored in Institutional Facts and Speech Act theories presented by [9]. Examples of IWs domains include waste management, the semantic web, the Olympic Games, postal codes, Maps preparation and Geographic information governance [6 and 10], and flood management [8]. In IWs, when organizations start to collaborate, standard and common terminology must be established to allow for smooth communication to avoid misunderstandings.
The integration or merging of ontologies focuses on explicit specifications. Furthermore, interaction or collaboration of two or more specifications is important. For supporting merging or interoperability, conceptualizations of ontologies should have systems of institutional facts. In this context, interlocking systems of institutional facts help in merging conceptualizations of ontologies. In short, an institutional world is defined as a set of institutional facts in the speech acts of an institution. Furthermore, without interlocking of institutional worlds, it is not feasible to merge specifications of two or more ontologies [6].
The methodology for development of an ontology is a guideline for ontology developers [11]. Different ontology development methodologies have been defined [12, 13, 41, 15, 16, 17, 18, 19, 20 and 21]. The methodology proposed in our previous work [13] was our initial attempt to design a methodology for designing ontology for the waste management domain. Researchers to date, have not agreed on a single methodology for developing ontologies of different domains. Therefore, ontology projects choose or develop their own methodology for the developing ontology of a domain of discourse. This selection or creation of methodology depends on application and the anticipated evolution of the particular ontology [22]. Therefore, the designing of a domain ontology for WM, a type of IWs, requires a well-defined ontology development methodology.

B. Need for Ontology
In the last decade, ontologies have become widely adopted in a variety of fields ranging from biomedicine, to finance, engineering, law, and cultural heritage as recent review on ontology engineering in [4]. Semantic web, as a machine-readable web, need ontologies as its primary and most important component. Ontology defines conceptions and their associations in a domain of discourse [1]. Knowledge based applications require ontologies as they serve as formal models and machine understandable descriptions of the domain. Ontologies help in sharing domain knowledge to other relevant or irrelevant domains. For example, [2] tests how sharing of knowledge can improve employee individual performance as well as team performance. Due to the distributed nature of organizational knowledge, the knowledge-based applications with the help of ontologies, must be able to integrate knowledge of heterogeneous sources and present an overview of the knowledge available in the organization [3]. In this context, finding a suitable ontology for a domain is one of the bigger research challenges [4]. Ontologies, as a conceptual tool and key component of knowledge-based systems, have been used by organizations for effective knowledge management of the domain of discourse. In the past decade, the industry has shown interest in providing solutions by developing applications in semantic technology. For example, the HIV Protein Ontology in the medical domain [23]. Artificial intelligence (AI) as an opportunistic area of study, and a challenge for the research community, shows interest in knowledge representation, knowledge management and semantic associations [24]. Truly speaking, keeping in view the advantages of ontology-based approach, there are few ontology-based solutions which benefit from this approach [25]. Here it is worth mentioning that ontology based machinereadable systems help in making better decision support systems with improved knowledge management. Furthermore, ontology approach makes it easy to share conceptualization of a domain [1], and this sharing offers more opportunities for stakeholders to solve their real-time problems.

C. Ontology Development Methodologies
The main purpose of an ontology proposal was to share domain information between software agents and people. As a result of such interest in ontologies, several ontologies have been designed, each ontology with a different purpose, in different disciplines, such as Gene Ontology (GO) in the biomedicine domain [15].
The study of principles, methods and tools for designing upper or domain ontologies, is a primary focus of the ontology engineering discipline. In this context, a methodology provides guidelines for the development of ontologies. In order to help and support ontology development, several methodologies have been proposed by researchers.
Ontologies help in communication for better decision making, promote sharing of knowledge, facilitate storage of information, and support the reuse of knowledge [3]. An ontology can be developed manually using an ontology editor like Protégé, or automatically using suitable ontology designing algorithms that are implemented in some programming language such as Java. Many researchers design ontologies manually, such as [13], or automatically, for example [26], for particular domains of study.
For designing a domain or upper ontology, it is necessary to follow a set of defined and ordered steps. In order to help and support ontology development, several methodologies have been proposed by researchers. However, there is a need for a well-documented, mature and widely accepted methodology for ontology engineering. In this article, a survey has been prepared to compare methodologies designed during 2015-2020 for developing domain ontologies in different domains. A methodology is a set of well-designed techniques and methods that guarantee the quality of the results of an ontology design process. Author in [27] describes a series of related concepts related to methodologies for designing ontology.
• Method: The order or a series of steps to develop a product.
• Technique: A procedure for achieving a goal. Therefore, the methodology provides a framework for building ontology for the domain of knowledge.
• Methodology: A set of methods and techniques that guarantee the quality of the results of an ontology design process.
Knowledge Engineering: it is the discipline derived from artificial intelligence and is responsible for the design and development of knowledge-based systems.
As stated by [4], ontology engineering has not changed significantly over the last decade. It is observed by [28] that each methodology follows a different approach. There is no correspondence between the different methodologies. There is no technological support for most methodologies, i.e., they cannot be easily applied in the task of building an ontology.
In order to help and support ontology development, several methodologies have been proposed by researchers [4]. But work on new methodologies for developing ontologies does not seem to have progressed greatly. As a result, a methodology proposed by [29] is the most used or cited methodology for designing a domain ontology. There may be several reasons for this, but one of the main reasons is poor or even lack of documentation about methodologies that have been applied to develop the ontology of a project. Several researchers have made efforts to compare methodologies for designing domain ontologies.
An overview of the developmental aspects of ontology was presented in [30]. According to this survey, there are three methodologies to use, to help developers build a domain ontology. The common methodology described in [31] provides a guideline for each stage of the development of an ontology. In comparison with METHONTOLOGY, this method can identify management activity and would be an effective and applicable approach for building domain knowledge models. Finally, similar to the two methodologies, the methodology proposed by [32] was created based on experience of the TOVE project, which was developed in six phases, beginning with the reasons for the capture, and ending with an established condition. To conclude, ontology designers can design ontologies in their own ways or follow a predefined methodology. Unlike any other development project, ontology is dynamic and flexible, and is not tied to a certain development or progress process to be created.
In [33], a survey is conducted on several aspects of ontology development such as ontology, methodologies for developing ontologies and automated or semi-automated tools for designing ontologies. However, the survey does not present comparisons of researchers' contributions in terms of proposed or adopted techniques and methods for designing domain ontologies.
Similarly, domains have terminologies, and a well-designed methodology helps in designing ontology for domain terminologies as observed by [34]. Subsequently, based on five criteria, they made comparisons of ontology development methodologies. In this comparison, a conclusion is made that TERMINAE and METHONTOLOGY are the appropriate methodologies for designing domain ontologies. In this context, [35] argue that developing ontology development methodologies is a tedious and complex task. Existing studies show that a methodology developed based on experience of one or a few projects, may or may not be effective for creating domain ontologies. It means, there is a gap in the existing methodologies. The following points are concluded from [34]. First of all, according to established comparison criteria, none of the methodologies is mature enough. Secondly, there is an absence of documentation or poor documentation on techniques, activities and methods used in ontology construction. There are some exceptions, in particular, METHONTOLOGY. Additionally, some methodologies support reengineering concepts and reusability, with few methodologies providing recommendations for these aspects. Similarly, little attention has been paid by researchers to the collaborative construction aspect of domain ontology. In this context, [36], paid attention to collaborative way of ontology construction. As conventional strategies have been used by researchers for collecting ontology conceptions, it is important to propose and use novel techniques and methods for designing domain ontologies. One of the critical problems for the implementation of any ontology that should be addressed, is the problem of selecting a well-established and appropriate methodology for ontology construction. Here, quality of implementation of domain ontology is related to or dependent on selection and adoption of a well-established methodology. Therefore, the study by [37] examined and made a comparison of the best-known ontology development methodologies based on the development life cycle of a common ontology. This study [34] also aimed to define and use, the appropriate and mature methodology for the construction of Semantic Conflicts Detection Ontology (SCDO). Additionally, it also aimed at providing ontology developers with useful information that would facilitate the process of choosing the appropriate methodology for their ontologies. Hence, METHONTOLOGY was chosen and recommended by [34] to be used for the implementation of SCDO.
In [38], an investigation based on specific criteria was conducted on collaborative ontology engineering methodologies and the ontology engineering environment. This study recommends collaborative ontology construction, and collaborative construction needs integrated environments for ontology development. This survey makes it a priority to analyze experience reports and case studies. This analysis could be fruitful for defining future research roadmaps for collaborative ontology development. Finally, this study recommends the use of an integrated development environment for collaborative ontology construction.
Author in [39] conducted a survey on ontology development methodologies for the public administration domain. In this survey, common ontology development aspects were chosen for comparing methodologies (for example, ontology construction strategies) as well as aspects related to project management (for example, the recommended process model or taking into account the collaborative development of ontologies). Author in [39] summarizes that none of the methodologies is suitable for the development of ontology in the public administration domain.
According to the analysis carried out by [40], the following conclusions were drawn: According to this survey, no methodology meets IEEE standards; although METHONTOLOGY [41] is the most mature. This study found this methodology [32] more formal than others but this methodology was found to be missing re-engineering aspects of ontology. Similarly, the methodology proposed by [31] also missed re-engineering aspects of ontology and omitted welldocumented documentation. Similarly, the methodology proposed by [42], omitted detailed documentation, reengineering of ontology and had no ontology development life cycle. Furthermore, CO4 and (KA) 2 [43] discuss collaborative ontology construction but with few details. This study concludes following: 1) None of the methodologies is mature enough because each research develops the ontology in its own way.
2) Another important aspect of ontology development is interoperability and its implementation. Domain ontologies developed using the SENSUS [42] methodology have the same high-level ontology structure and can be easily interoperated.
3) Most of the surveyed methodologies provide few details except METHONTOLOGY.
It should be mentioned here that our survey has comparison criteria different than [40]. We compare methodologies based on domain analysis, conceptualization, level of detail, collaborative construction, implementation, evaluation, instantiation, maintenance, documentation, ontology localization, support for reusability, support for integration, support for interoperability, resource estimation human, example of application / project and methodology rooted in established methodologies. While [40] included some parameters with respect to the above-mentioned criteria.

III. REVIEW METHOD
A systematic literature review is a method of finding, assessing and inferring available empirical studies on a topic. There are many reasons for making a systematic review, the most common of which are as follows [44]: • To identify gaps in the research progress.
• To evaluate current proofs about a technology or method.
• To propose a research roadmap for future research.
• To help in proposing new hypothesis.
102 | P a g e www.ijacsa.thesai.org Although the work of [45, 46 and 47] has been described in several ways, the steps of the examination method presented by [44] for general applications are relatively similar. In this article, the research process follows the steps as outlined here [47]: research planning, pinpointing of research, choosing primary studies, and finally, classification of selected research items.

A. Research Planning
Academic research questions are primary concerns while conduction of a systematic literature review must be answered by researchers in their research. Keeping in view the empirical studies, such as [44, 45, and 48], we postulate the following research question discussed in the following subsections to study the design of ontologies: How ontology development methodology can be proposed to design a domain ontology of IWs?

B. Research Identification
Our search strategy was as follows: we started our research work by finding general search keywords and search terms, and combined searches to identify as many relevant documents as possible. Moreover, we had consulted ontology experts for the identification of the relevant documents. The following electronic databases were used to search using keywords: IEEE Explore; Springer Link; AIS (Association for Information System) Electronic library; ScienceDirect; Google scholar; Business Source Premier; ISI Web of Science; ACM Digital library; Inspec; Scopus; ProQuest Science Journals; DBLP; and Wiley Online Library. Following keywords or phrases has been used for the identification of the relevant articles: • Ontology development

C. Selection of Primary Studies
After selecting the relevant articles, we removed the duplicate articles and the titles that were not relevant to ontology development methodologies. With, 90 articles in hand, we read the summaries with following criteria: • Exclude if the paper was not about domain ontologies.
• Exclude if the paper was about automatic ontology construction.
• Exclude if the paper was not about designing a methodology for ontology development.
• Exclude if the paper was a literature review.
Finally, we made selection of 16 articles for review, from 2015 to 2020. The overall process was substantially in line with Fig. 1, also used by [48]. 103 | P a g e www.ijacsa.thesai.org

D. Comparison of Methodologies for Designing Domain Ontologies
The methodology for ontology development, a guideline for ontology developers, discusses about process and methods for ontology development [11]. Different ontology development methodologies have been defined [12, 13, 14, 15, 16, 17, 18, 19, 20 and 21]. The methodology proposed in our previous work [13], was our initial attempt to design a methodology for designing ontology for the waste management domain. In this context, different researches designed their domain ontologies in different ways and there is no single viable method for doing so as discussed by [22].
Additionally, different methodologies focus on development of ontologies differently and include distinct aspects of ontology development. For example, few focused on scope of ontology and domain analysis and there was no design phase and no detail about activities they performed during ontology development. This study made a comparison of several methodologies, along with identification of a criterion, on the basis of which it was necessary to analyze and compare the methodologies. Selected evaluation criteria were defined by observing needs and trends that have evolved over the last decade, which cover sixteen different aspects of methodology for developing domain ontologies. These evaluation criteria will help the reader to understand different ontology development methodologies and will help to select a suitable methodology for designing their domain ontology of the domain of discourse.

E. Criteria for Analysis
We define below the criteria used to compare methodologies for ontology development. The last six facets of the criteria are coarse-grained level of a methodology, namely localization of ontology, support for reusability, support for integration, support for interoperability, methodology rooted in established methodologies and estimation of human resources. The first nine facets of the criteria, namely domain analysis, conceptualization, level of detail, collaborative construction, implementation, evaluation, instantiation, maintenance and documentation discuss the technical fine-grained level of a methodology and help the reader in understanding a particular methodology for ontology development. Table I presents a detailed and complete comparison of the methodologies based on the established criteria. This study will compare selected methodologies for ontology development base on following criteria (C1-C16), which are attention-grabbing when it comes to the creation of domain ontologies (few are taken from [49]): • C1:Domain Analysis (specification, knowledge acquisition). Domain analysis requires a lot of resources and lacks domain-specific recommendations. The situation becomes more complex when ontology integrates knowledge from different fields. The necessary training seminars are important for understanding the terminology of the core of ontologies for team members who are unfamiliar or have a controversial understanding.
• C2:Conceptualization. Does the proposed methodology support or include conceptualization activity, as described in [50]?
• C3:Level of detail. Does the methodology provide details about techniques and methods for various activities? In this case, the level of detail criteria is evaluated on a scale from very few details as 1 to 5 (detailed).
• C4:Collaborative construction. Collaborative construction involves several stakeholders of the ontology development group to work from the same location or different locations, on the same ontology simultaneously, and without affecting the overall efficiency of the ontology development task.
• C5:Implementation (Model to language). Implementation needs a representation language for the implementation of a conceptual ontology model to ontology. In this context, manual construction from a formal conceptual model to ontology is laborious and ontology developers do not prefer it. However, construction of ontology from a formal model requires paying attention to semantic differences between the formal model and the representation language.
• C6:Evaluation (Refinement). The evaluation aspect requires the evaluator to have a good understanding of the ontology and a proper understanding of ontology is a key success factor of the ontology evaluation process.
• C7:Instantiation/ontology population/data generation. Does the methodology apply any technique and method for instantiation? The population of an ontology can be processed easily as compared to the processing of poorly structured sources such as documents, relational tables and XML data.
• C8:Maintenance/Modifications. Ontologies are constantly confronted with the problem of evolution. Due to the complexity of the changes to be made, a maintenance process, manual or semi-automatic or automatic, is increasingly necessary to facilitate this task and ensure its reliability.
• C9:Documentation. Does the methodology provide detailed documentation of methods and activities for ontology construction? Documentation helps in the understanding of the ontology, its use, reuse and future revision of the ontology.
• C10:Ontology localization. Does the methodology support localization of the ontology? Adaption of the ontology into a natural language is called localization of ontology.
• C11: Support for reusability. Ontology development is a tedious and time-consuming task. Usually, it is costly to reuse application dependent ontologies. In this context, use of upper-level or foundational ontologies helps in reducing reusability costs by providing a common conceptual structure in domain ontologies developed using same upper ontology.
• C12:Support for integration and merging. The integration of ontology is dependent on degree of overlapping between two integrating ontologies with same representing language. The quality of integration is measured, in terms of accuracy (correct mapping rate) and recall (discovered mapping rate).
• C13:Support for interoperability. Interoperability between systems requires the same supporting structure (same high-level concepts). The resulting ontologies will hence have a common global conceptual structure and it will help them in sharing their concepts.
• C14:Estimation of human resources. Team needs (people with required skills, experience and team size): ontology engineers, domain experts, technical writer for documentation, software engineers.
• C15:Sample Application/project. Are any samples of ontology designed for the planned project?
• C16:Methodology rooted in established methodologies. Is the developed methodology rooted in any wellestablished methodology like Design Science Research (DSR)?

IV. DISCUSSION
Most of the methodologies studied provide domain analysis, conceptualization, implementation, evaluation, instantiation and provide an example of domain ontology; although most of them have not provided all the details of the techniques and activities involved. With less details, it is difficult to follow a methodology for designing ontologies for a specific domain. There are some exceptions that have provided details, in particular, [19, 51, 53, and 56]. Additionally, most of the methodologies studied (compared to Table I) do not offer support for maintenance, documentation, construction of collaborative ontologies, support for reuse, support for integration, support for interoperability, ontology localization and human resources estimation (for example, ontology experts).
As we know, ontology needs change over time; support for modification and maintenance are mandatory for an ontology. As such, there should be maintenance and support in the domain ontology. Few studied methodologies provide maintenance, collaborative construction of ontologies, documentation, ontology localization, support for reuse, support for integration, support for interoperability and estimation of human resources (for example ontology experts). For example, the maintenance is discussed by [12, 17, 20, 55, and 56]. Likewise, few researchers provide documentation; for example, documentation is provided by [12, 17, 20, 21, 27, 54, and 58]. The documentation provides help in understanding the ontology.
The development of an ontology is an evolutionary process and the availability (in the same place) of domain experts, ontology engineers, technical writers and other human resources is not always possible. The collaborative construction of ontologies will therefore make valuable human resources available worldwide. In this regard, support for the collaborative construction of ontologies will help the correct execution of the ontology construction plan. [17 and 56] provide the collaborative ontology development.
Additionally, for a large and complex domain, a single large ontology cannot be created. There would be multiple subdomains, and each subdomain needs an ontology. In this context, interoperability of subdomain information systems is needed. Interoperability between systems requires the same support structure (same high-level concepts). The resulting ontologies will hence have a common global conceptual structure and it will help them to share their concepts. The methodologies proposed by [18 and 56] support interoperability. Similarly, ontology integration of subdomain information systems is needed. This can be realized in the integration of the ontology discussed by [12, 17, 21, 55, and 56].
Creating ontology is a tedious and boring activity, and reusability allows you to reuse the existing ontology and add additional components to the target ontology. Few researchers [13, 17, 27, and 55] provide a mechanism to reuse ontology. Similarly, it is important to translate ontology into different natural languages, as it is not possible to conceive a separate ontology for each natural language (English, Malay, Urdu, Hindi, German, French, etc.). Only two [34 and 56] of the studied methodologies provide support for the localization of the ontology. In addition to this, estimating the costs of the ontology building process requires estimating the required human resources, such as domain experts, ontology engineers, and API developers. Only [17, 19, and 56] discuss little about the estimation of human resources. Finally, most of the methodologies examined in the study are not based on any well-established methodology. There are some exceptions, mainly [13], who rooted their methodology in Design Science Research (DSR).
In this context, developing ontology development methodologies, is a tedious and complex task. Existing studies show that a methodology developed based on experience of one or a few projects, may or may not be effective for creating domain ontologies. It means, there is a gap in the existing methodologies and this gap is highlighted by our analysis. The following points are concluded from this study: • None of the methodologies is mature enough.
• There is an absence of documentation or poor documentation on techniques, activities and methods used in ontology construction. There are some exceptions, mainly NeOn [56].
• Some methodologies support the concept of reusability, localization, integration, interoperability, estimation of human resources and reengineering; but not others.
• Little attention is paid by researchers to the collaborative construction aspect of domain ontology, and collaborative ontology construction is one of important aspects of ontology construction.
• As conventional strategies have been used by researchers for collecting ontology conceptions, it is important to propose and use novel techniques and methods for designing domain ontologies, such as those proposed by [6].
Design and Implementation of E-Campus Ontology with a Hybrid Software Engineering Methodology [18] An Ontology for the Waste Management The NeOn Methodology for Ontology

V. CONCLUSSION
There are many methodologies that have been proposed by several researchers during the last decade. However, designing a domain ontology for IWs needs a well-defined ontology development methodology. Therefore, in this article, a survey has been conducted to compare ontology development methodologies between 2015 and 2020. We analyzed that a non-collaborative or centralized ontology development methodology is a major trend in the development of domain ontologies. From this analysis, we recommend collaborative ontology development methodologies for keeping ontologies live, evolved and to increase their reuse potential. An important conclusion is that the collaborative ontology development methodology rooted in a well-established methodology such as Design Science Research, with interoperability, reusability, merging, localization, detailed documentation, human resource estimation and with at least one sample ontology developed using this methodology, has a good impact on the development of a domain ontology. To conclude, a collaborative methodology rooted in a well-established methodology, with supported collaboration tools for the development, maintenance and advancement of modularized ontologies, has a good impact on the development of a domain ontology.
Finally, proposing a methodology for designing a domain ontology of IWs is complex. There are criteria that need to be incorporated including C1-C16. Among these criteria, some are extracted from existing methodologies; however, there are key criteria which are missing, and which are crucial for developing a domain ontology of IWs. These are, collaborative ontology construction, interoperability, reusability, merging, localization, detailed documentation, human resource estimation and methodology rooted in previously wellestablished methodology. This paper has presented most of the criteria that we think are important for the research community of domain ontology; and can be further used to establish a well-defined methodology for developing a domain ontology of IWs. In this article, we have not included all ontology development methodologies because there are too many; some are very old, and other did not explain their methodology for ontology development.