This paper presents the PhD project, by the first author, that develops, in frame of the OntoElect methodology, the methods, techniques, and software tools for conceptualizing and formalizing the requirements for engineering an ontology in an arbitrary domain. It takes in the terms extracted from a representative collection of high-quality textual documents written by the experts in the target domain and therefore describing this domain. It produces the representative set of the requirements by the knowledge stakeholders as ontological fragments conceptualized as UML class diagrams and formalized in OWL+SWRL. The paper presents the vision of the solution and the plan towards building it based on the background knowledge and related work in the fields of Conceptual Modeling and Ontology Engineering. It also outlines the plan for experimental evaluation and validation of the solution.
This paper presents the Ph.D. project that further develops, in frame of the OntoElect
methodology [
tology). OntoElect is the basic methodological and theoretical framework for this project.
Conceptualization and Formalization phase builds and refines the high-level contexts (instances) during ontology development process.
In general, knowledge stakeholders in a domain, like for example, Tourism or Finance, are clearly not knowledge engineers. Therefore, it is naive to request that they provide their requirements using an ontology representation language, like OWL. Moreover, it is naive to expect that they will readily provide their requirements as it is not their business. Therefore, OntoElect solicits their requirements indirectly, relying on the existence of a high-quality and representative collection of documents describing the domain. The documents come as texts in a natural language. Hence, the input and any other supplementary data for conceptualization are natural language text fragments. From the other hand, the output has to come in a formal ontology representation language in order to enforce single interpretation and be machine processable. This is why the task of conceptualizing and formalizing requirements for ontology development is challenging. This challenge includes several complex problems that will be attacked in this PhD project.
The reminder of the paper is structured as follows. Section 2 Outlines these problems and offers a high-level vision of the overall solution. Section 3 looks at the related work in the fields of Conceptual Modeling and Ontology Engineering to seek insights, relevant background knowledge, and the bits of already existing technologies that may help solve the challenge of the project. Section 4 explains how the developed solutions will be evaluated experimentally. Finally, Section 5 concludes the paper. 2
There is a problem with meaning interpretation for the different terms and contexts
which appears between people in different communities. For example, a particular
term may have a more specific interpretation by a domain expert which may well
differ from the interpretation by an ontology engineer. Regarding engineering, it can
be called as a lack of specification when different engineers have different ideas about
the particular requirement and its context. Hence, conceptualization and formalization
phase is designed to solve this problem. To overcome this mismatch in
interpretations, the project bases itself on the approach of stepwise elimination of different
aspects that cause mismatches. This approach has been framed out as a part of
OntoElect methodology [
The outlined sequence of steps takes in the ranked list of the terms describing the domain. These terms are guaranteed to be significant and saturated by the Feature Elicitation phase of OntoElect. Therefore, the input is regarded as the list of the required features. The objective is to transform this list of the required features to formalized ontological fragments (requirements), carrying the positive and negative votes of the involved features in their aggregated significance scores. Requirements are further used in Ontology Evaluation phase to compute the fitness of the ontology.
Conceptualization and formalization is done by a knowledge engineer, using the suite of software instruments that will be developed in this project, through: (i) grouping and categorizing extracted required features; (ii) selecting the significant concepts from the list of required features and forming the feature taxonomy; (iii) computing the propagated scores up the concept/property hierarchies; (iv) selecting the most significant concept features; (v) elaborating natural language definitions for the most significant concept features and formalizing these as ontological fragments using UML and OWL; and (vi) documenting requirements.
Feature grouping is merging several features which are lexically different but
carry equivalent semantics. The relevant cases include: plural and singular forms of the
same term, for example “temporal constraints” and “temporal constraint” are the same
terms and have to be merged; the terms that had or had not lost two-letter
combinations due to peculiarities of their representation in PDF documents due to the
differences in Adobe versions, for example “de nition” and “definition” are also the same
terms. The significance scores of the merged terms are summarized. One possible
solution to group features semi-automatically using a proper string similarity measure,
as suggested in [
Analyzing the individuals (see also feature categorization below), for example taken from a relevant linked open data repository or the individual features available from the required feature list, may help receive more confidence in the relevance of a property to a concept.
Looking at feature groups may reveal important information about their subsumption or meronymy (and, possibly, other interesting properties). Indeed, the most abstract feature in a group may be interpreted as the root in the group hierarchy. Consequently, the features which are extended from the root feature by adding words most probably subsume to the root. Meronymy hierarchies involve the features which are either parts of a whole or the wholes for their parts. Putting together all these group hierarchies will result in a feature taxonomy, which is the output of the Feature Grouping step.
Building the feature taxonomy for the set of required features is important as both
types of hierarchical relationships among features influence the significance of
features through inheritance. Indeed, if a feature subsumes to another feature then it
inherits some of its properties, so its significance is formed to a particular extent by
these inherited properties. Hence, a parent in a hierarchy may expect that it is
rewarded by its children through the propagation of their significance scores. OntoElect
suggests [
A step which is somewhat orthogonal to grouping, as it looks into the semantic nature of a feature is categorization. Feature categorization stands for deciding if a feature, due to its semantics, represents a concept, a property, or an individual. Property features are further grouped in relevant ontological fragments to represent formalized requirements. Individual features – by being the instances of a concept or a property – form the corpus of evidence pointing that the concept possesses the property at the schema level. Concept features are further used to form subsumption or meronymy hierarchies in the concept taxonomy and form the “anchors” for ontological fragments.
The most significant concept features (due to their scores in the feature taxonomy), having the potential for high impact on the requirements, may be selected. For that, concept features are viewed in a ranked list and the group of features covering the desired proportion of importance is promoted.
The promoted concept features are used to form the concept taxonomy and be the central concepts for the formalized requirements. Each of these promoted concept features is, at the end of the workflow, conceptualized in a formalized ontological fragment – as a conceptual model (in UML) and a piece of code in an ontology specification language (in OWL+SWRL). Conceptualization means that all the relevant property features and features representing individuals are consolidated in the ontological fragment in a harmonized way to form a coherent piece of a required descriptive theory for the domain.
Conceptualizing a concept feature starts with elaborating its natural language
definition based on the high-impact documents describing the domain. These
documents may be acquired from the document collection from which the required
features have been extracted. To ensure the relevance and high impact of these sources, a
snowball sampling in citation networks approach (e.g. [
Based on the natural language definition, a conceptual model is developed for a concept feature, including also its properties and relationships to the other relevant concept features.
Currently, OntoElect does not recommend any instrumental software tool to help
transform the definition of a concept written using a natural (e.g. English) language to
a UML model. Current working practice suggests that it is a two-step process. The
first step is elaborating the model manually, using the ArgoUML editor4. Protégé
ontology editor5 is further used at the second step for manual coding the ontology in
OWL 2 with an account for DL restrictions [
One potentially interesting idea is inspired by the works in automatic program
generation. The instructions in a programming language are generated from natural
language sentences using different techniques. One of the promising approaches is to
employ machine learning approach. To do so, it is required that a set of typical
sentences and resulting code instructions is provided to train the model. When done, the
trained model is applied to incoming sentences and outputs code instructions. A
similar approach may be used for descriptive sentences from one side and UML model
outputs from the other side – please see an example in Fig. 3. An appropriate starting
point for the training set could be the library of ontology design patterns [
The transformation of a UML model of an ontological fragment to OWL + SWRL could also be automated. The approach could be using a rule-based technique, or a machine-learning approach described above.
OntoElect is more specific in recommending a way for documenting the ontology under development. It suggests that the ontology is documented in a set of Semantic MediaWiki8 pages. Some of those pages provide the overviews of the ontology modules, but the rest, which are the majority, are dedicated to documenting the concepts – one page per concept. A documentation wiki page of a particular concept contains: the natural language definition of the concept; the UML class diagram of the concept’s conceptual model; the description of the properties grouped according to the property types: datatype and object properties. This sort of documentation, for requirements, would be straightforwardly generated based on the results of conceptualization and formalization. 3
Ontology engineering is a broad field which a substantially big research community devoting their effort to push forward the State-of-the-Art. Therefore, it is not tractable to overview all the achievements in ontology engineering. In this paper we focus, in our review of the related work, only on those results that gave us insights in developing our vision and circumscribing the problems to be solved, as presented in Section 2. Therefore, our concise related work review is grouped below along the problems that need to be solved.
ied in the Knowledge Acquisition and Information retrieval fields. There were plenty
approaches developed by applying syntactic, semantic, and linguistics analysis (e.g.
Jaccard, Jaro, Euclidean algorithms) be revealing the degree of the measure similarity.
Using clustering algorithms like K-means, Agglomerative Hierarchical, or EM and
methods such as pattern-based extraction, conceptual clustering, concept learning,
ontology learning from instances [
Feature Categorization. A lot of existing approaches are based on the predefined tokenization or part-of-speech tagging (POS) patterns for identifying relatedness which developed by NLP techniques. The most well-known comprehensive toolkits for natural language processing are General Architecture for Text Engineering (GATE), Natural Language Toolkit (NLTK), and Stanford Core NLP. Conceptualization. Several methodologies contributed the techniques for conceptualization in ontology engineering. The Klagenfurt Conceptual Pre-Design Model
(KCPM) an intermediate phase between requirements analysis and conceptual design.
The proposed approach was targeted on harmonization the developer’s and user’s
view. The relevant part of this work for the presented project is in particular in the
modeling notions: thing and connection types, a perspective view and constraint [
ting significance scores is very specific in the ontology development process. Hence, to the best of our knowledge, there is no published work that uses feature significance scores for requirements (or ontology) conceptualization.
Syntactic ontology design pattern (OPs) was developed based on the linguistic
structures or schemas in order to extract some conclusions about the meaning of the words
they express [
Text to UML model Transformation. Several publications deal with the
transformation of text to UML. Most of them use XML serializations and XSLT [
neering, Schema reengineering, and Transformation of Logical Patterns techniques
were developed for relevant transformations, for example a non-OWL DL or informal
concept models to OWL DL ontology fragments. The conceptualization activity in
METHONTOLOGY provide a full-stack guide for converting informally presented
concepts and relations into semi-formal specifications. Several tools have also been
developed for the purpose of this or similar transformation, such as LEXTER [
Ontology engineering methods9 were developed not only for the creating ontology from scratch but also to be able to reuse the already existed ontologies. Here are several purposes that they are used for: (i) building ontology from scratch, (ii) upgrading an existing ontology, (iii) acquiring knowledge for particular tasks, (iv) solving particular problems during ontology development process. The most well-known ontology engineering methods are alignment, merging, evaluating (e.g., Cyc, Uschold and King’s, re-engineering (METHONTOLOGY), etc.) which allow ontology engineers to build and edit ontologies using the combination of frames, description logic, first logic order and other different approaches.
cess editor was developed to enable the ontology documenting process. This approach
is based on combining graphical process modeling techniques, wiki-based
lightweight knowledge capturing approach, and a background semantic knowledge
base [
The envisioned approach, together with the instrumental software tools, for conceptualizing and formalizing requirements in ontology engineering needs to be experimentally evaluated and validated. A straightforward way to evaluate the (correctness) of the solution is to compare its results to a Golden Standard. Consequently, a way to validate the solution is to offer it to knowledge engineers for a trial. Further, their impression of the usability and performance of the solution is compared to their normal mode of work – without the solution.
As a Golden Standard for evaluation, it is planned to use the available working repository of the Syndicated Ontology of Time (SOT). SOT is developed using OntoElect as the ontology engineering methodology. Therefore, this repository contains all the types of intermediate and final results for the key concepts of the currently developed ontology for the Time Representation and Reasoning domain. The repository belongs to our group and therefore is fully available as background knowledge. In evaluation, it is planned to compare the outputs of the developed tools to the same outputs developed by human knowledge engineers.
In validation experiments, the knowledge engineers who developed SOT manually
will do the same development for the selected key concept features [
After the evaluation and validation of the solution in the SOT use case, another use
case in a different domain will be elaborated. One of the potential candidate domains
is Knowledge Management. An industrial use case for this domain is framed out
9 This description has been deliberately kept concise because of the page limit.
Definitely, more relevant ontology engineering methods exist, including ontology
learning, and will be reviewed in the planned survey paper.
based on the full text document collection of 15 journals provided by Springer Nature.
For a part of this domain the work on extracting features is in progress [
The PhD project presented in this paper is in its initial phase. So, the only preliminary result is the vision of the solution that will help achieve the goal of the project: help domain knowledge stakeholders and knowledge engineers be coherent in interpreting the requirements for representing knowledge to describe the domain formally, in an ontology.
While elaborating our vision of the research problem and possible solution to it, we also presented a workflow that will help solve the challenge in several interrelated steps. These steps are, in their turn, the problems that require solutions. These solutions are planned to be sought in the project.
Our initial plan for evaluating and validating the solution is also presented in the paper. We hope that the outcome of the project will be beneficial for the Ontology Engineering community at broad and also for the experts who carry their knowledge about various domains of interest.