1 Motivation

The use of ontology design patterns (ODP) has established itself as an ontology engineering paradigm [3]. There are, however, a number of open challenges to be considered by researchers concerning the future of ODPs and modular ontology engineering. In this demonstration, we are particularly interested in both recognizing the substantial need for a robust pattern representation language and increasing the availability of easy-to-use, supporting tools. For a more thorough examination of these challenges and others, please see [2].

Utilizing a pattern representation language is an important piece for improving the development process, as it begins to address a perennial challenge in the Semantic Web community: ontology sharing and reuse; and as it applies to the ontology engineer: ontology design pattern sharing and reuse. A commonly used pattern representation language is immediately impactful by allowing the ontology engineer to more explicitly express

  • how to use a pattern (e.g. what are natural “hooks" into the ODP)

  • which other ODPs have been adapted or reused to create the pattern

  • from where an ontology module was derived

Together, these examples can enable a so-called “smart" repository. Such a repository will allow an ontology engineer to more easily navigate and explore patterns and modules, thus realizing a centralized mechanism for the sharing, reuse, or adaptation of ODPs. As such, it is in the best interest of the community to utilize the pattern language.

As a first step in addressing this challenge, [4] presented the Ontology Design Pattern Representation Language (OPLa). OPLa annotations are fully compatible with OWL and its semantics are formally described. For each of our motivating examples we provide some concrete examples that illustrate exactly how OPLa can be used to formally describing those relationships.

The MicroblogEntry pattern may contain the following triples:

figure a

The first triple indicates that the Location is a “hook"for other engineers to use. The second triple indicates that the MicroblogEntry pattern has adapted the Media class from another ODP, in this case the NewsReportingEvent ODP [5, 7]. Additionally, the ModifiedHazardousSituation ODP may contain the triple

figure b

which states that ModifiedHazardousSituation is derived from the HazardousSituation ODP [1, 6]. Figure 1 provides a graphical overview for the other OPLa annotations.

However, like many forms of documentation, it is a tedious task to exhaustively perform. The key to adding complexity to any engineering process is making the change trivial to the end-user. As such, sufficient, easy-to-use tooling is necessary for facilitating process adoption. To address this, we have developed a plug-in that has been optimized for walking an ontology engineer through annotating their ontology, module, or pattern with the correct OPLa annotations.

Fig. 1.
figure 1

A graphical overview of the Ontology Design Pattter Representation Language (OPLa) [4].

Full size image

2 Implementation

Our plugin, the OPLaTab (Fig. 2), is implemented for 5. At the time of this writing, plugin registration through the wikiFootnote 1 is ongoing. We provide a portal onlineFootnote 2 for a more detailed examination of the plugin’s source code and .JAR file, and closer view of the interface and its use and installation.

The purpose of the OPLaTab plugin is to guide the user through the construction of a valid OPLa annotation. As such, it is optimized for annotating the ontology itself and its entities with only those annotations explicitly outlined in Fig. 1 and [4]. Thus, the interface is purposefully minimalist and restricted: it condenses all annotation functionality to a single screen and reduces the number of choices a user needs to make in order to insert an annotation into the ontology.

The tab’s only silent behavior is to add the OPLa namespace to the ontology.Footnote 3 All other changes to the ontology are done via the “Save" and “Remove" buttons.

The interface is separated into three parts: navigation, construction, and view/remove. The plugin currently supports the annotation of the Ontology, Classes, Individuals, Object Properties, Data Properties, Datatypes and Annotations. By selecting one of these options, the construction area will be populated with the appropriate entities. Further, the list of annotation properties will update to display only those properties that are valid for the selected entity. Finally, the view/remove area will display only OPLa annotations so that it is easy to identify which entities have yet to be annotated.

Currently, the annotation value for the annotation is user-dependent, in the absence of a standardized controlled vocabulary or repository. We briefly describe a sample workflow:

  1. 1.

    Select the ontology itself or an ontological entity.

  2. 2.

    Select the appropriate annotation property.

  3. 3.

    Enter the annotation value.

  4. 4.

    Save the annotation.

At this time, the bottom portion of the screen will update with the new annotation. The annotation may be removed by selecting the appropriate button.

Fig. 2.
figure 2

A view of OPLaTab’s interface. This view shows an example annotation be added to the loaded ontology.

Full size image

3 Conclusions, Future Work, and Demonstration

OPLaTab is a useful tool for constructing OPLa annotations. There is currently an ongiong intention to develop a comprehensive tool suite for modular ontology engineering. We see OPLa becoming a central component of this tool suite. From visualization and interactive browsing to a smart repository, each will need some way of communicating to a user exactly how ontologies and ODPs relate to each other. As we provide more sophisticated tools in this realm, there are several foreseeable next steps.

While some of these next steps will require extensions to OPLa, OPLa was purposefully developed to be easily extendable. For example, it may be possible to embed visualization information into annotations, allowing software to determine which properties are visible at different levels of granularity. The same principle can be extended for interactive browsing. Perhaps most importantly, however, is the ability to connect to a machine-readable repository of ontology design patterns and modules. This “smart" repository can act as a dynamically updated controlled vocabulary of namespaces, thus allowing an ontology engineer to select the appropriate namespace when constructing their OPLa annotations.

Additionally, we will work to improve the user experience and look to more appropriately match the workspace.

3.1 Demonstration

The demonstration will consist of a live walkthrough of annotating a loaded ontology. In the interest of space, we have outlined in more detail a step-by-step walkthrough in our online portal.Footnote 4