Published ontologies frequently fall short of their promises to enable knowledge sharing and reuse. This may be due to too strong or too weak ontological commitments; one way to prevent this is to engineer the ontology to be modular, thus allowing users to more easily adapt ontologies to their own individual use-cases. In order to enable this engineering paradigm, there is a distinct need for developing more supporting tools and infrastructure. This increased support can be immediately impactful in a number of ways: guides engineers through best practices and promote ontology design pattern discovery, sharing, and reuse. To meet these needs, this PhD project explores the development of a comprehensive modular ontology IDE and tool suite.
One of the central tenets of the Semantic Web is to enable the sharing and reuse of knowledge. Unfortunately, published ontologies infrequently live up to these promises, as they are not developed with best practices in mind, such as modularization, documentation, and annotation.
Ontologies with too strong or too weak ontological commitments are
undesirable. Strong ontological commitments lead to overspecialization; this may
constrain ontologies to be useful only for the single usecases for which the
ontologies were developed. Conversely, weak commitments lead to overly ambigious
models, thus making it di cult to understand how to use the ontology, at all.
In order to combat this, during development an ontology should be su ciently
modularized. Such ontologies [
Furthermore, it is necessary to properly document and annotate the
developed ontology. In order to exhibit and promote the use of the ontology among
a domain, other engineers must understand how to use or adapt the ontology,
as well as understand the nature of certain ontological commitments or other
design decisions [
However, developing an ontology, while following these best practices, is a very di cult and time-consuming process, especially without proper tooling and supporting infrastructure. As such, this PhD project explores the development of a comprehensive, modular ontology integrated development environment (IDE) in order to address the needs for ontology design pattern (ODP) discovery and modularization and engineering ontologies with best practices. 2
As described in the previous section, designing modular ontologies is an answer
to some of the problems facing the Semantic Web community, namely those
regarding the sharing and reuse of knowledge [
Recently, there have been many attempts to do so, ranging from new visualizations, improved methodologies, and more accessible modeling tools. Unfortunately, these attempts are largely uncoordinated; each individual attempt is focused on improving a single aspect of the process. For example, they all do not share the same unifying platform nor necessarily work well together (and sometimes even at cross purposes). Further, some improvements may be strictly theoretical or methodological with no usable implementation.
In summary, there is currently no comprehensive nor integrated approach for developing modular ontologies according to best practices. However, there is now a critical mass of individual, tools with specialized functionalities. We believe the best approach for moving forward is to increase the support (e.g. tooling and infrastructure) available to ontology engineers by fusing together existing support. Thus, developing a comprehensive, modular ontology IDE will help increase the adoption of the modular ontology engineering paradigm and is thus very relevant to the Semantic Web community. 3
There are a number of open research questions regarding the future of modular
ontology development, especially regarding tooling and infrastructure, as
outlined by the Semantic Web community in [
As a rst approximation, Hammar et al. describe the need for a \patterncapable ontology IDE." That is, an ontology IDE that is capable of using ontology design patterns as primitives, as well as having some mechanism for pattern discovery. A modular ontology IDE takes this concept a step further and would allow users to import and modularize ODPs to also be used as primitives. Thus, we seek to answer the following questions.
RQ1. What foundational support is needed to realize such an IDE? RQ2. How can new and existing tools be combined to form a cohesive and useful whole, while still leaving room for extensibility? Our attempts to answer RQ1 are described in Section 6. For RQ2, we describe some existing tools and methods in Section 5.
In line with the previous section, we also want to show that a comprehensive, modular ontology IDE is, in fact, e ective. Thus, we will attempt to con rm the following hypotheses.
A comprehensive, modular ontology IDE will allow an ontology engineer to develop ontologies
2. that adhere to best practices for modularity, documentation, and annotation.
How we will acheive this and how we determine success are discussed in Sections 6 and 7, respectively. 5
Overall, there are many existing tools and methods for helping develop ontologies. As this PhD project is speci cally concerned with modular ontology engineering, we most carefully consider those related tools and methods. In this section, we provide broad descriptions of related work that this PhD project will expand, adapt, or otherwise utilize. We may partition the related works into three categories, based on how they intersect with the ontology engineering process: Methodology, Visualization and Rendering, and Tools and Infrastructure.
By methodology, we refer to those related works that deal with guidelines and principles for engineering ontologies. Of particular interest is the eXtreme Design (XD) Methodology and methods for documenting ontology design patterns.
The eXtreme Design (XD) Methodology is a \family of methods and
associated tools... for for solving ontology development issues" [
Karima et al. give a thorough walkthrough on how to document ontology
design patterns [
This category refers to those tools and methods that facilitate alternative views of an ontology. For example, functional syntax for OWL or Turtle or Manchester Syntax are alternate renderings of the same information. As the semantic web community more deeply and consistently interacts with domain experts, it is very important to nd vehicles for representing an ontology that is easy for people to intuit. Below, we describe two recent tools for doing this. As part of the evaluation of this PhD project, we will also evaluate the e cacy of presenting ontological information in this manner.
OWL2Rules is an augmentation1 to the OWLAPI's LATEX rendering framework.
This tool is capable of representing the axioms of an ontology as First Order
Predicate Logic Existential Disjunctive Rules. It also incorporates the improved
LATEX formatting from [
SDont is a tool2 for creating the schema diagrams for ontologies. While there are other visualization tools (e.g. OWLgred and VOWL), SDont has been engineered to generate schema diagrams that are maximally similar to human curated schema diagrams. We intend to incorporate this tool in order to provide a more comfortable vehicle for representing the structure of a TBox.
Tools and Infrastructure refers to the tools and methods that assist in the ontology engineering process. On their own, each of these tools is enormously helpful. However, a platform utilizing them will be greater than the sum of its components.
OPLa is an Ontology Design Pattern Representation Language [
ROWL & OWLAx are Protege plugins [
In aggregate, our approach is to tie together multiple existing tools (e.g. XD for WebProtege and OWLAx), develop or enhance new tools (e.g. SDont) and combine them into a comprehensive, modular ontology IDE (CoModIDE{ pronounced `commodity'). In addition, CoModIDE would be tightly integrated with a central, \smart" repository that will facilitate ODP discovery and importing. To address our research questions, we have split the approach into two distinct phases: foundational work and IDE development.
This phase largely addresses RQ1: \What foundational support is needed to realize CoModIDE?" Phase I will have the following trajectory. After we have identi ed, developed, evaluated individual useful tools, what remains is to integrate them into a comprehensive, modular ontology IDE; we call it CoModIDE. Overall, we foresee the trajectory to be as follows.
We will need to choose a platform upon which to build the IDE. At the time of this writing, we believe that Desktop Protege is the best choice. It o ers built-in plugin support and very tight integration with the OWLAPI.
Once a platform has been chosen, we may need to re-implement the functionality of existing tools for that platform. For example, XD for WebProtege is only implemented for WebProtege and itself has several pieces of our desired functionality.
After all the tools have been integrated so that they work together, we must evaluate whether or not the CoModIDE is achieving the desired purpose, i.e. does it help users design better ontologies more quickly? We describe this step in more detail in the next section.
{ UX and Work ow: There are some functionalities that can only be considered once the IDE has been developed, such as determining the best way to guide users to document and annotate the ontology as its being designed. Additionally, we would like to implement a graphical plug'n'play interface. That is, using ODPs as primitives (similar to puzzle-pieces), connect the ODPs to form a rst-pass ontology. { Extensibility: The \modular" in CoModIDE need not only apply to the ontology design. In fact, it would behoove us to ensure that the IDE itself is modular, in order to continue adding functionality as modular ontology design evolves in the future. { Repo interfacing: It is completely necessary that the IDE support interfacing with a central repository and a pattern representation language. At this time, we expect that to be ontologydesignpatterns.org and OPLa, respectively. 7
We have posited that a comprehensive, modular ontology IDE will allow engineers to more quickly design ontologies, while following best practices. To determine if we have successfully done so, we will conduct evaluations in two parts.
First, each individual functionality of the IDE must be tested. For some of
these tools (e.g. ROWL [
After all the tools and desired functionalities have been implemented and evaluated, we will evaluate the sum-total: CoModIDE. This will necessarily be a user evaluation.
We will have a test group and control group. Each group will be given a
moderately compex modeling task. The test group will be asked to design the
ontology using CoModIDE; the control group will not. We will then measure
the amount of time it took to complete the design task, measure its e cacy
at providing answers to pre-selected compentency questions, and identify if the
ontology has been designed modularly and with best practices, as according to
[
At the time of this writing, we have only implemented the very beginning stages of our proposed approach and do not have any results to report. However, for the established tools (e.g. ROWL or XD for WebProtege), see their respective references. 9
It is not that others have failed, but that there is nally a critical mass in successful, existing tools and methods for modular ontology design. Thus, we believe that unifying them will result in a better tool for producing better ontologies.
By unifying the tools, we believe that we will decrease the time spent switching between tools, formats, and the like. The ability to communicate with a central repository, such as ontologydesignpatterns.org will greatly facilitate pattern discovery and utilizing a standardized pattern representation language, such as OPLa, will allow engineers to make better decisions more quickly. Acknowledgement. The author acknowledges funding from the Dayton Area Graduate Studies Institute (DAGSI) and thanks Pascal Hitzler for his significant input.