Figure 2 - uploaded by Guylerme Figueiredo
Content may be subject to copyright.
The modularized ship transportation model

The modularized ship transportation model

Source publication
Conference Paper
Full-text available
In recent years, there has been a growth in the use of reference conceptual models, in general, and domain ontologies, in particular, to capture information about complex and critical domains. These models play a fundamental role in different types of critical semantic interoperability tasks. Therefore, it is essential that domain experts are able...

Contexts in source publication

Context 1
... tessellate the possible space of objects in that domain, i.e., all objects belong to exactly one kind and do so necessar- ily. Typical examples of kinds include Person, Organization, Ship, and Harbor (see Figure 2). We can, however, have other static subdivisions (or subtypes) of a kind. ...
Context 2
... are naturally termed Subkinds. As an example, the kind 'Person' can be specialized in the subkinds 'Man' and 'Woman', likewise a kind 'Ship' can be specialized in the subkinds 'Cargo Ship' and 'Passenger Ship' (Figure 2). Object kinds and subkinds represent essential properties of objects (they are also termed rigid or static types [10]). ...
Context 3
... have, however, types that represent contingent or accidental properties of objects (termed anti-rigid types [10]). These include Phases (for example, in the way that 'being a living person' captures a cluster of contingent properties of a person, in the way that 'being a puppy' captures a cluster of contingent properties of a dog, or in the way that 'being an active harbor' captures contingent properties of a harbor, see Figure 2) and Roles (for example, in the way that 'being a husband' captures a cluster of contingent properties of a man, or that 'being a captain' captures contingent properties of a person, see Figure 2). The difference between the contingent properties represented by a phase and a role is the following: phases represent properties that are intrinsic to entities (e.g., 'being a puppy' is being a dog that is in a particular developmental phase; 'being a living person' is being a person who has the intrinsic property of being alive; 'being an active harbor' is being a harbor that is functional); roles, in contrast, represent properties that entities have in a relational context, i.e., con- tingent relational properties (e.g., 'being a husband' is to bear a number of commitments and claims towards a spouse in the scope of a marital relationship; 'being a student' is to bear a number of properties in the scope of an enrollment relationship with an educational institution; 'being a captain' is to bear a number of legal obligations and powers in the scope of a captain designation relationship to a ship, see Figure 2). ...
Context 4
... have, however, types that represent contingent or accidental properties of objects (termed anti-rigid types [10]). These include Phases (for example, in the way that 'being a living person' captures a cluster of contingent properties of a person, in the way that 'being a puppy' captures a cluster of contingent properties of a dog, or in the way that 'being an active harbor' captures contingent properties of a harbor, see Figure 2) and Roles (for example, in the way that 'being a husband' captures a cluster of contingent properties of a man, or that 'being a captain' captures contingent properties of a person, see Figure 2). The difference between the contingent properties represented by a phase and a role is the following: phases represent properties that are intrinsic to entities (e.g., 'being a puppy' is being a dog that is in a particular developmental phase; 'being a living person' is being a person who has the intrinsic property of being alive; 'being an active harbor' is being a harbor that is functional); roles, in contrast, represent properties that entities have in a relational context, i.e., con- tingent relational properties (e.g., 'being a husband' is to bear a number of commitments and claims towards a spouse in the scope of a marital relationship; 'being a student' is to bear a number of properties in the scope of an enrollment relationship with an educational institution; 'being a captain' is to bear a number of legal obligations and powers in the scope of a captain designation relationship to a ship, see Figure 2). ...
Context 5
... include Phases (for example, in the way that 'being a living person' captures a cluster of contingent properties of a person, in the way that 'being a puppy' captures a cluster of contingent properties of a dog, or in the way that 'being an active harbor' captures contingent properties of a harbor, see Figure 2) and Roles (for example, in the way that 'being a husband' captures a cluster of contingent properties of a man, or that 'being a captain' captures contingent properties of a person, see Figure 2). The difference between the contingent properties represented by a phase and a role is the following: phases represent properties that are intrinsic to entities (e.g., 'being a puppy' is being a dog that is in a particular developmental phase; 'being a living person' is being a person who has the intrinsic property of being alive; 'being an active harbor' is being a harbor that is functional); roles, in contrast, represent properties that entities have in a relational context, i.e., con- tingent relational properties (e.g., 'being a husband' is to bear a number of commitments and claims towards a spouse in the scope of a marital relationship; 'being a student' is to bear a number of properties in the scope of an enrollment relationship with an educational institution; 'being a captain' is to bear a number of legal obligations and powers in the scope of a captain designation relationship to a ship, see Figure 2). ...
Context 6
... (or relationships in a particular technical sense [8]) represent clusters of relational properties that "hang together" by a nexus (provided by a relator kind). Moreover, relators (e.g., marriages, enrollments, employments, presiden- tial mandates, citizenships, but also transportation contracts, trips, administration assignments and captain designations, see Figure 2) are full-fledged Endurants. In other words, entities that endure in time bearing their own essential and accidental properties and, hence, first-class entities that can change in a qualitative manner while maintaining their identity. ...
Context 7
... participate in relationships (relators) playing certain "roles". For instance, people play the role of spouse in a marriage relationship; a person plays the role of president in a presidential mandate; a harbor plays the role of a destination harbor in the scope of a trip, see Figure 2. 'Spouse' and 'President' (but also typically student, teacher, pet, destination harbor, captain, and traveling ship) are examples of what we technically term a role in UFO, i.e., a relational contingent sortal (since these roles can only be played by entities of a unique given kind). ...
Context 8
... example is the role 'Customer' (which can be played by both people and organizations). Another example is the role 'Ship Administrator' (which, again can be played by both people and organizations, see Figure 2). We call these role-like types that classify entities of multiple kinds RoleMixins. ...
Context 9
... result of filtering the model of Figure 1 according to this definition, produces a view containing only the fundamental kinds of things that exist in that domain, namely, people, ships, organizations and harbors (see Figure 2). This view is constituted by terminal symbols of the OntoUML pattern language as defined in [22], [27]. ...
Context 10
... result of filtering the model of Figure 1 according to this definition, produces a view that takes the two subkinds present in that model (PassengerShip and CargoShip) and produces a view that includes these subkinds and the classes and relations in this path until their (accidentally, in this case, common) kind is reached (see Figure 2). This view is constituted by instances of the Subkind Pattern of the OntoUML pattern language as defined in [22], [27]. ...
Context 11
... result of filtering the model of Figure 1 according to this definition, produces a view that takes the three phases present in that model (ExtinctHarbor, TemporarilyClosedHarbord and Active Harbor) and produces a view that includes these phases and the classes and relations in this path until their (acciden- tally, in this case, common) kind is reached (see Figure 2). This view is constituted by instances of the Phase Pattern of the OntoUML pattern language as defined in [22], [27]. ...
Context 12
... result of filtering the model of Figure 1 according to this definition, produces a view that takes the the roles present in that model (see Figure 1) and produces a view that includes these roles and the classes and relations in this path until their respective kind is reached (see Figure 2). This view is constituted by fragments that represent the core the Role Pattern of the OntoUML pattern language as defined in [22], [27]. ...
Context 13
... view includes all relator types in the model as well as the mediation relations connecting them to other types in the model. Taking the model of Figure 1 as an example, we have the RMV depicted in Figure 2. In this view, we have the relators Transportation Contracts (connecting Transportation Contract Clients and Ship Administrations), Ship Administration (connecting Ship Administrators and Ships), Captain Designation (connecting Captain and Ship) and Trip (connecting Departing Harbor, Destination Harbor and Traveling Ship). ...
Context 14
... any non-sortal in the model (rolemixin, mixin or category), the view should include: (i) this non-sortal and all its non-sortal supertypes, including these subtyping relations connecting them; (ii) the first sortal specializing this non-sortal as well as the patch from this sortal to the unique kind providing its identity principle [10]. Taking the model of Figure 1 as an example, we have the NSV depicted in Figure 2. In this view, we have, for instance, the rolemixin ShipAdministrator, the sortals that immediately specialize it (the roles Individual Administrator and Corporate Administrator) as well as the supertypes of each of these sortals that are in the path between them and their kinds (Person and Organization, respectively, in this case). ...
Context 15
... other words, by employing the explicitly defined MOF metamodel on which this editor is based, we have implemented algorithms to: automatically detect pattern occurrences, accessible through a detection dialog window (see example in Figure 3); extract views from OntoUML models comprising instances of these patterns. For instance, for the model of Figure 1, the tool will generate a structure of views that is equivalent to the one depicted in Figure 2. OntoUML is a pattern-driven modeling language. ...
Context 16
... chunks are themselves composed of even finer-grained chunks, namely, the aforementioned ontology design patterns. As one can observe in Figure 2, these resulting building blocks stay within the threshold of human-cognitive capacity and manipulation in short-term memory [19]. ...
Context 17
... one can observe in figure 2, the view extraction approach we propose here creates views that are composed of chunks derived from OntoUML ontology design patterns. In prelim- inary tests of our implementation against existing OntoUML models of different sizes and representing different domains, we observed that indeed the number of chunks within these views stay (in nearly the totally of cases) within the so- called Miller's Magic Number (7 ± 2 items) [19]. ...

Similar publications

Conference Paper
Full-text available
In recent years, there has been a growth in the use of reference conceptual models, in general, and domain ontologies, in particular, to capture information about complex and critical domains. These models play a fundamental role in different types of critical semantic interoperability tasks. Therefore, it is essential that domain experts are able...
Preprint
Full-text available
In human semantic cognition, proper names (names which refer to individual entities) are harder to learn and retrieve than common nouns. This seems to be the case for machine learning algorithms too, but the linguistic and distributional reasons for this behaviour have not been investigated in depth so far. To tackle this issue, we show that the se...

Citations

... In addition, strategies exist that enable a recoding or modularization of models using an underlying foundational ontology. In model recoding [16], models are re-organized by grouping elements in terms of higher-granularity modeling primitives. In model ...
Article
Full-text available
Humanity has long since used models, in different shapes and forms, to understand, redesign, communicate about, and shape, the world around us; including many different social, economic, biological, chemical, physical, and digital aspects. This has resulted in a wide range of modeling practices. When the models as used in such modeling practices have a key role to play in the activities in which these practices are ‘embedded’, the need emerges to consider the effectiveness and efficiency of such processes, and speak about modeling capabilities. In the latter situation, it also becomes relevant to develop a thorough understanding of the artifacts involved in modeling practices/capabilities. One context in which models play (an increasingly) important role is model-driven systems development, including software engineering, information systems engineering, business process engineering, enterprise engineering, and enterprise architecture management. In such a context, we come across a rich variety of modeling related artifacts, such as views, diagrams, programs, animations, specifications, etc. In this paper, which is actually part of an ongoing ‘journey’ in which we aim to gain deeper insights into the foundations of modeling, we take a fundamental look at the variety of modeling related artifacts as used in the context of model-driven (systems) development, while also presenting an associated framework for understanding, synthesizing the insights we obtained during the ‘journey’ so-far. In doing so, we will also argue that the aforementioned artifacts are actually specific kinds of models, albeit for fundamentally different purposes. The provided framework for understanding involves definitions of domain model, the Return on Modeling Effort (RoME), the conceptual fidelity of domain models, as well as views as a mechanism to manage the complexity of domain models.
... This aspect of explanation goes exactly in the inverse direction of ontological unpacking, which is a process that reveals the implicit distinctions underlying domain models, thus, typically yielding larger and more complex models. For this reason, as discussed by Romanenko et al. [65], ontological unpacking must be complemented by complexity management tools for, e.g., model abstraction/summarization, modularization, and viewpoint extraction [66][67][68][69], which could be adapted to reduce the complexity of the model for an explanation-seeker and with a set of requests for explanation in mind. ...
... In addition, strategies exist that enable a recoding or modularization of models using an underlying foundational ontology. In model recoding (Figueiredo et al. 2018), models are re-organized by grouping elements in terms of higher-granularity modeling primitives. In model modularization , models are reorganized in cognitively tractable chunks that can be understood as a whole. ...
Chapter
Full-text available
Humanity has long since used models in different shapes and forms to understand , redesign, communicate about, and shape, the world around us; including many different social, economic, biological, chemical, physical, and digital aspects. This has resulted in a wide range of modeling practices. When the models as used in such modeling practices have a key role to play in the activities in which these modeling practices are 'embedded', the need emerges to consider the effectiveness and efficiency of such processes, and speak about modeling capabilities. In the latter situation, it becomes relevant to develop a thorough understanding of the artifacts involved in the modeling practices/capabilities. One field in which models play (an increasingly) important role is the field of system development (including software engineering, information systems engineering, and enterprise design management). In this context, we come across notions, such as views, diagrams, programs, animations, specifications, etc. The aim of this paper is to take a fundamental look at these notions. In doing so, we will argue that these notions should actually be seen as specific kinds of models, albeit for fundamentally different purposes. 5.1 Introduction Whenever we are confronted with complex phenomena, such as the processes we observe in nature, the construction of buildings, the design of information systems, etc, we tend to 'work with' an abstraction (in our mind) of the actual phenomenon; zooming in on those 'properties' of the phenomenon that matter to us, and filtering out all the properties that are not germane to the goals at hand. When we externalize this abstraction in terms of some artifact, then this artifact is a model (to us, as an individual) of the observed phenomenon. More generally, one can observe how humanity has long since used models to understand, redesign, communicate about, and shape, the world around us, including many different social, economic, biological, chemical, physical, and digital aspects. These models may take different shapes and forms, such as sketches, precise drawings, textual specifications, or tangible forms mimicking key physical properties of some original. This wide spread, and natural (Zarwin et al. 2014) use of models has resulted in many different modeling practices. When the models as created and/or used in such modeling practices have a key role to play in the activities in which these modeling practices are 'embedded', a natural need emerges to consider the effectiveness and efficiency of such processes, and speak about 123
... Modelers' ability to manage complexity is often influenced by their expertise and choice of modeling tools. Some tools lack essential features, such as support for model abstraction (Egyed, 2000), segmentation (Figueiredo et al., 2018), and clustering (Akoka and Comyn-Wattiau, 1996), which help minimize complexity. In these cases, modelers may use their expertise to find workarounds. ...
... The more relationships in a model, the less comprehension is possible due to the accompanying increase in complexity [41]. Therefore, the increased size and complexity can make models cognitively intractable [12]. ...
Chapter
Full-text available
Conceptual models need to be comprehensible and maintainable by humans to exploit their full value in faithfully representing a subject domain. Modularization, i.e. breaking down the monolithic model into smaller, comprehensible chunks has proven very valuable to maintain this value even for very large models. The quality of modularization however often depends on application-specific requirements, the domain, and the modeling language. A well-defined generic modularizing framework applicable to different modeling languages and requirements is lacking. In this paper, we present a customizable and generic multi-objective conceptual models modularization framework. The multi-objective aspect supports addressing heterogeneous requirements while the framework’s genericity supports modularization for arbitrary modeling languages and its customizability is provided by adopting the modularization configuration up to the level of using user-defined heuristics. Our approach applies genetic algorithms to search for a set of optimal solutions. In this paper, we present the details of our Generic Genetic Modularization Framework with a case study to show i) the feasibility of our approach by modularizing models from multiple modeling languages, ii) the customizability by using different objectives for the modularization quality, and, finally, iii) a comparative performance evaluation of our approach on a dataset of ER and ECore models.
... One one hand, the process of ontological unpacking reveals the distinctions that make up the conceptualization underlying domain models, thus, typically yielding larger and more detailed models. On the other hand, as discussed in [54], this activity must be complemented by complexity management tools for, e.g., model abstraction (or summarization), modularization, and viewpoint extraction [57][58][59][60], which could be adapted to reduce the complexity of the model with an explanation-seeker or a set of requests for explanation in mind. This is another direction of work that is an extension of these methods. ...
Preprint
Full-text available
The terms 'semantics' and 'ontology' are increasingly appearing together with 'explanation', not only in the scientific literature, but also in organizational communication. However, all of these terms are also being significantly overloaded. In this paper, we discuss their strong relation under particular interpretations. Specifically, we discuss a notion of explanation termed ontological unpacking, which aims at explaining symbolic domain descriptions (conceptual models, knowledge graphs, logical specifications) by revealing their ontological commitment in terms of their assumed truthmakers, i.e., the entities in one's ontology that make the propositions in those descriptions true. To illustrate this idea, we employ an ontological theory of relations to explain (by revealing the hidden semantics of) a very simple symbolic model encoded in the standard modeling language UML. We also discuss the essential role played by ontology-driven conceptual models (resulting from this form of explanation processes) in properly supporting semantic interoperability tasks. Finally, we discuss the relation between ontological unpacking and other forms of explanation in philosophy and science, as well as in the area of Artificial Intelligence.
... The algorithm presented here is only made possible because it is based on a nonclassical Conceptual Model (CM) language, namely, the ODCM language OntoUML (briefly presented in section 2.1). Two CM-CM methods in the literature are based on the same language, namely, the algorithms of Figueiredo et al. (2018), Lozano, Cabonera and Abel (2015), and Lozano et al. (2014). However, none of these are methods of model abstraction. ...
... The results presented in this paper complement the research by Figueiredo et al. (2018) as part of a general program of Ontology-Based Complexity Management of Large and Complex Conceptual Models. Whilst that work addresses the problem of model clustering by viewpoint extraction, here we focus on model abstraction, i.e., on a particular type of model summarization. ...
Thesis
Full-text available
Reference conceptual models are used to capture complex and critical domain information. However, as the complexity of a domain grows, so does the size and complexity of the model that represents it. Over the years, different complexity management techniques in large-scale conceptual models have been developed to extract value from models that, due to their size, are challenging to understand. These techniques, however, run into some limitations, such as the possibility of execution without human interaction, semantic cohesion of modules/views generated from the model, and generating an abstracted version of the model so that it can present the essential elements of the domain, among others. This thesis proposes two algorithms to facilitate the understanding of large-scale conceptual models by tackling the problem from two different angles. The first consists in extracting smaller self-contained modules from the original model. The second consists in abstracting the original model, thereby providing a summarized view of the main elements and how they relate to each other in the domain. Both algorithms we propose in this thesis require no input from modelers, are deterministic, and computationally inexpensive. To evaluate the abstraction algorithm for conceptual models, we carried out an empirical research aimed at a comparative analysis taking into account other competing approaches.
... That is, it requires models to be broken down into pieces. We account for the possibility of cutting complex models into simpler sub-models to facilitate the modeler analysis and the simulation process relying on previous work [39,40]. ...
Preprint
Full-text available
Conceptual modeling plays a fundamental role in information systems engineering, and in data and systems interoperability. To play their role as instruments for domain modeling, conceptual models must contain the exact set of constraints that represent the worldview of the relevant domain stakeholders. However, as empirical results show, conceptual modelers are subject to cognitive limitations and biases and, hence, in practice, they systematically produce models that fall short in that respect. Moreover, automating the process of formally assessing conceptual models in this sense (i.e., model validation) is notoriously hard, mainly because the intended worldview at hand lies in the mind of these stakeholders. In this paper, we provide a novel approach to model validation and automated constraint learning that combines, on one hand, Model Finding via the visual simulation of that model's valid instances and, on the other hand, Inductive Logic Programming techniques. In our approach, we properly channel the results produced by the application of a visual model finding technique as input to a learning process. We then show how the approach is able to support the modeler in identifying missing constraints from the original model. The approach is validated against a catalog of empirically-elicited conceptual modeling anti-patterns. As we show here, the approach is able to support the automated learning of constraints that are needed to rectify a number of relevant anti-patterns in this catalog.
... That is, it requires models to be broken down into pieces. We account for the possibility of cutting complex models into simpler sub-models to facilitate the modeler analysis and the simulation process relying on previous work [39,40]. ...
Article
Full-text available
Conceptual modeling plays a fundamental role in information systems engineering, and in data and systems interoperability. To play their role as instruments for domain modeling, conceptual models must contain the exact set of constraints that represent the worldview of the relevant domain stakeholders. However, as empirical results show, conceptual modelers are subject to cognitive limitations and biases and, hence, in practice, they systematically produce models that fall short in that respect. Moreover, automating the process of formally assessing conceptual models in this sense (i.e., model validation) is notoriously hard, mainly because the intended worldview at hand lies in the mind of these stakeholders. In this paper, we provide a novel approach to model validation and automated constraint learning that combines, on one hand, Model Finding via the visual simulation of that model’s valid instances and, on the other hand, Inductive Logic Programming techniques. In our approach, we properly channel the results produced by the application of a visual model finding technique as input to a learning process. We then show how the approach is able to support the modeler in identifying missing constraints from the original model. The approach is validated against a catalog of empirically-elicited conceptual modeling anti-patterns. As we shown here, the approach is able to support the automated learning of constraints that are needed to rectify a number of relevant anti-patterns in this catalog.
... The reason for this was to avoid having multiple motivations, each with potentially one cited paper, giving the appearance that this paper cannot be compared to any other. Some papers Engineering [6], [7], [11], [21], [27], [31], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63] Reasoning [11], [18], [21], [27], [30], [44], [46], [47], [48], [49], [53], [54], [61], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74] Knowledge Hiding [31], [44], [52], [57], [58], [63], [65], [69], [75], [76], [77], [78] Alignment [7], [8], [11], [18], [21], [28], [30], [40], [41], [42], [43], [44], [45], [46], [47], [50], [51], [64], [66], [68], [75], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96], [97] cited multiple motivations, and thus are listed under each motivation. The papers citing engineering as a motivation include those that aim to produce modules so that the ontology is more refined, easier to maintain, or more usable. ...
... The reason for this was to avoid having multiple motivations, each with potentially one cited paper, giving the appearance that this paper cannot be compared to any other. Some papers Engineering [6], [7], [11], [21], [27], [31], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63] Reasoning [11], [18], [21], [27], [30], [44], [46], [47], [48], [49], [53], [54], [61], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74] Knowledge Hiding [31], [44], [52], [57], [58], [63], [65], [69], [75], [76], [77], [78] Alignment [7], [8], [11], [18], [21], [28], [30], [40], [41], [42], [43], [44], [45], [46], [47], [50], [51], [64], [66], [68], [75], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92], [93], [94], [95], [96], [97] cited multiple motivations, and thus are listed under each motivation. The papers citing engineering as a motivation include those that aim to produce modules so that the ontology is more refined, easier to maintain, or more usable. ...
... Unlike the modules extracted for purposes of Engineering, which seek to permanently improve the maintainability of the ontology, a knowledge hiding module is typically 'one-and-done'. The module is produced to answer the needs of the user (e.g., a [7], [18], [21], [27], [30], [34], [41], [42], [47], [51], [57], [58], [59], [61], [62], [63], [67], [70], [74], [75], [77], [85], [92] Graphical [6], [8], [11], [28], [40], [43], [44], [45], [46], [49], [50], [52], [53], [54], [56], [60], [64], [66], [68], [69], [71], [72], [73], [76], [78], [79], [80], [81], [83], [84], [86], [87], [88], [89], [90], [91], [94], [95], [96], [97] Hybrid [31], [48], [55], [65], [82], [93] [7], [8], [11], [18], [21], [27], [28], [30], [34], [40], [41], [42], [43], [44], [45], [46], [47], [50], [51], [52], [53], [54], [56], [57], [58], [59], [60], [61], [62], [63], [64], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [89], [90], [91], [92], [93], [94], [95], [96] Both [6], [31], [48], [49], [55], [65], [88] query) and is then discarded. It is not saved or stored with the ontology. ...
Article
Full-text available
In the past two decades, the use of ontologies has grown accompanied by a diversity in ontological representations and applications to more comprehensive domains. Knowledge engineers have found it expeditious to break down large (monolithic) ontologies to work with smaller fragments. Ontology modularization is the process of extracting a fragment, or ”module”, from an ontology, based on predefined requirements. Due to both the diversity in ontological representations and motivations for modularizing, the body of research on ontology modularization techniques has become extremely large and may be intimidating to the novice ontology researcher. The objective of the paper is to present a comprehensive, albeit high-level, review of ontology modularization techniques. A systematic literature review covering January 1st 2000 to July 31st 2020 was performed to find and classify papers on ontology modularization techniques. The techniques exhibiting certain properties with respect to several features were assessed, and the modularization techniques were classified with a multi-dimensional perspective. The classifications are intended to guide one to a suitable modularization process in accordance with the requirements. The limitations of ontology modularization techniques are highlighted in the conclusion, and characteristics of a desirable framework for an ontology representation that would be best-suited for modularization are presented.