Ontology Design Patterns (ODPs) are intended to guide nonexperts in performing ontology engineering tasks successfully. While being the topic of signi cant research e orts, the uptake of these ideas outside the academic community is limited. This paper summarises some issues preventing broader adoption of Ontology Design Patterns among practitioners, suggests research directions that may help overcome these issues, and presents early results of work in these directions.
While the rst requirement above can be said to be ful lled by the ODPs published online (the majority of which result from projects and research involving both researchers and practitioners), the latter two requirements have largely been overlooked by the academic community. Many patterns are poorly documented, and at the time of writing, none have been su ciently vetted to graduate from submitted to published status in the prime pattern repository online2. Toolset support is limited to some of the tasks required when employing patterns, while other tasks are entirely unsupported. Furthermore, the most mature pattern usage support tools are implemented as a plugin for an ontology engineering environment which is no longer actively maintained3.
In the following paper, these ODP adoption challenges are discussed in more detail, and the author's ongoing work on addressing them is reported. The paper focuses exclusively on Content ODPs as de ned in the NeOn Project4, as this is most common type of Ontology Design Patterns with some 100+ patterns published. The paper is structured as follows: Section 2 introduces relevant related published research on ODPs, Section 3 focuses on the tasks that need be performed when nding, adapting, and applying patterns, Section 4 details the challenges preventing the adoption of ODPs by practitioner ontologists, Section 5 proposes solutions to these challenges, Section 6 presents the initial results of applying some of those solutions, and Section 7 concludes and summarises the paper. 2
Ontology Design Patterns were introduced as potential solutions to these types
of issues at around the same time independently by Gangemi [
Since their introduction, ODPs have been the subject of some research and
work, see for instance the deliverables of the EU FP6 NeOn Project5 [
The use and understanding of ODPs have been heavily in uenced by the work
taking place in the NeOn Project7, the results of which include a pattern
typology [
Ontology Design Patterns have also been studied within the CO-ODE project[
The eXtreme Design method provides recommendations on how one should structure an Ontology Engineering project of non-trivial size, from tasks and processes of larger granularity (project initialisation, requirements elicitation, etc) all the way down to the level of which speci c tasks need be performed when employing a pattern to solve a modelling problem. Those speci c pattern usage tasks (which are also applicable in other pattern-using development methods) are:
3.1
In XD, the task of nding an appropriate design pattern for a particular
problem is viewed as a matching problem where a local use case (the problem for
which the ontology engineer needs guidance) is matched to a general use case
7 http://www.neon-project.org/
8 http://odps.sourceforge.net/odp/html/index.html
9 http://oppl2.sourceforge.net/
(the intended functionality of the pattern) encoded in the appropriate pattern's
documentation. In order to perform such matching, the general use case needs
be expressed in a way that enables matching to take place. In practice, pattern
intent is encoded using Competency Questions [
Having located a pattern appropriate for reuse in a speci c scenario, the ontology engineer needs to adapt and specialise said pattern for the scenario in question. The speci c steps vary from case to case, but a general approach that works in the majority of cases is as follows:
The XD Tools provide a wizard interface that supports each these steps. They also provide a certain degree of validation of the generated specialisations, by presenting the user with a list of generated axioms (expressed in natural language) for the user to reject or accept. 3.3
Once a pattern has been adapted for use in a particular scenario, the resulting solution module needs to be integrated with the ontology under development. This integration involves aligning classes and properties in the pattern module with existing classes and properties in the ontology, using subsumption or equivalency mappings. This integration process may also include refactoring of the existing ontology, in the case that requirements dictate that the resulting ontology be highly harmonised. There is at the time of writing no known tool support for ODP instantiation integration, and this process is therefore performed entirely by hand. 4
As indicated above, there is a thriving research community studying patterns
and developing new candidate ODPs. Unfortunately the adoption of Ontology
Design Patterns in the broader Semantic Web community, and in particular
among practitioners, is limited. The author has, based on experiences from
several studies involving users on di erent levels (from graduate students to domain
experts from industry) [
As explained, there are two methods for nding appropriate design patterns for
a particular modelling challenge - users can do matching by hand (by consulting
a pattern repository and reading pattern documentations one by one), or users
can employ the pattern search engine included in XD Tools to suggest candidate
patterns. In the former case, as soon as the list of available patterns grows to a
non-trivial number (such as in the ontologydesignpatterns.org community
portal), users nd the task challenging to perform correctly, particularly if patterns
are not structured in a way that is consistent with their expectations [
In the latter case, signal-to-noise ratio of pattern search engine results is often discouragingly low. In initial experiments (detailed in Section 6) the author found that with a result list displaying 25 candidate patterns, the correct pattern was included in less than a third of the cases. In order to guarantee that the correct pattern was included, the search engine had to return more than half of the patterns in the portal, essentially negating the point of using a search engine. Also, the existing pattern search engine included in XD Tools does not allow for ltering the results based on user criteria, which makes it easy for a user to mistakenly import and apply a pattern which is inconsistent with ontology requirements, e.g., on reasoning performance or other constraints. 4.2
The process of integrating a specialised pattern solution module into the target ontology is not supported by any published tools, and consequently relies entirely on the user's ontology engineering skill. Users performing such tasks are often confused by the many choices open to them, and the potential consequences of these choices, not limited to: { Which mapping axioms should be used between the existing classes and properties and those of the solution module, e.g., equivalency or subsumption? { Where those pattern instantiation module mapping axioms should be placed: in the target ontology, in the instantiated pattern module, or in a separate mapping module? { The interoperability e ects of customising patterns: for instance, what are the risks in case pattern classes are declared to be subsumed by existing top level classes in the target ontology? { How selections from the above composition choices a ect existing ontology characteristics such as reasoning performance, etc.
Users often express dissatisfaction with the varying degree of documentation
quality [
It is not uncommon for patterns to include and build upon other patterns, and these dependencies are not necessarily intuitive or well-explained. On several occasions the author has been questioned by practitioner users as to why, in the ontologydesignpatterns.org repository, the pattern concerning time indexed events makes use of the Event class that is de ned in the (non time-indexed) Participation pattern. The consequence of this dependency structure is of course that any user who models time indexed events using patterns automatically also includes non time-indexed participation representations in their resulting model, which very easily gives rise to modelling mistakes.
In more practical terms, the XD Tools were designed to run as a plugin for the NeOn Toolkit ontology IDE. This IDE unfortunately never gained greater adoption. Additionally, XD Tools and its dependencies require a speci c older version of NeOn Toolkit. This means that ontology engineers who want to use newer tools and standards are unable to use XD Tools, but rather have to do their pattern-based ontology engineering without adequate tool support. 5
The author's ongoing research aims to improve upon ODP usage methods and tools, in the process solving some of the issues presented above. To this end, a number of solution suggestions have been developed, and are currently in the process of being tested (some with positive results, see Section 6). The following sections present these suggestions and the consequences they would have on both patterns and pattern repositories. Implementation of these suggested improvements within an updated version of the XD Tools targeting the Protege editor is planned to take place in the coming months.
In order to improve recall when searching for suitable ODPs, the author suggests making use of two pieces of knowledge regarding patterns that the current XD Tools pattern search engine does not consider: rstly, that the core intent of the patterns in the index is codi ed as competency questions, which are structurally similar to such queries that an end-user may pose, and secondly, that patterns are general or abstract solutions to a common problem, and consequently, the speci c query that a user inputs needs to be transformed into a more general form in order to match the indexed patterns level of abstraction.
The rst piece of knowledge can be exploited by using string distance metrics to determine how similar an input query is to the competency questions associated with a pattern solution. Another approach under study is to employ ontology learning methods to generate graphs from both indexed pattern competency questions and input queries, and then measuring the degree of overlap between concepts referenced in these two graphs.
The second piece of knowledge can be exploited by reusing existing language resources that represent hyponymic relations, such as WordNet. By enriching the indexed patterns with synonyms of disambiguated classes and properties in the pattern, and by enriching the user query using hypernym terms of the query, the degree of overlap between a user query (worded to concern a speci c modelling issue) against a pattern competency question (worded to concern a more general phenomenon) can be computed. 5.2
The challenge of integrating an instantiated pattern module into a target ontology is at its core an ontology alignment challenge. Consequently existing ontology alignment and ontology matching methods are likely to be useful in this context. The behaviour of such systems against very small ontologies such as instantiated pattern modules, is however not well known. The advantage that patterns have over general ontologies in this context is the knowledge that patterns are designed with the very purpose of being adapted and integrated into other ontologies, which is not true in the general ontology alignment use case. Therefore, the pattern creator could a priori consider di erent ways in which that pattern would best be integrated with an ontology, and construct the pattern in such a way as to make this behaviour known to an alignment system.
The author suggests reusing known good practice from the ontology alignment domain, and combining this with such pattern-speci c alignment hints embedded in the individual pattern OWL les. For instance, a pattern class could be tagged with an annotation indicating to a compatible alignment system that this class represents a very high level or foundational concept, and that consequently, it should not be aligned as a subclass; or a pattern class or property could be tagged with annotations indicating labels of suitable sub- or superclasses in the integration step.
Additionally, improved user interfaces would aid non-expert users in applying patterns. Such user interfaces should detail in a graphical or otherwise intuitive manner the consequences of selecting a particular integration strategy, in the case that multiple such strategies are available for consideration. 6
The author has developed a method of indexing and searching over a set of Ontology Design Patterns based on the ideas presented in Section 5. The method combines the existing Lucene-backed Semantic Vectors Search method with a comparison of competency questions based on their relative Levenshtein edit distances, and a comparison of the number of query hypernyms that can be found among the pattern concept synonyms. Each method generates a con dence value between 0 and 1, and these con dence values are added together with equal weight to generate the nal con dence value which is used for candidate pattern ordering. While the approach requires further work, early results are promising, as shown in Table 1.
The dataset used in testing was created by reusing the question sets provided by the Question Answering over Linked Data (QALD) evaluation campaign. Each question was matched to one or more ODPs suitable for building an ontology supporting the question. This matching was performed by two senior ontology experts independently, and their respective answer sets merged. The two experts reported very similar pattern selections in the cases where only a single pattern candidate existed in the pattern repository compliant with a competency question (e.g., the Place10 or Information Realization11 patterns), but for such competency questions where multiple candidate patterns existed representing di erent modelling practices (e.g., the Agent Role12 or Participant Role13 patterns), their selections among these candidate patterns diverged. Consequently, the joint testing dataset was constructed via the union of the two experts' pattern selections (representing the possibility of multiple correct modelling choices), rather than their intersection. Recall was de ned as the ratio of such expert-provided ODP candidates that the automated system retrieves for a given input question.
As shown in the table, the average recall within the rst 10, 15, 20 or 25 results is 3-4 times better using the author's composite method (Composite3) than using the existing XD Tools Semantic Vectors Search (XD-SVS). It should be noted that while Composite3 also increases the precision of the results compared to XD-SVS by a similar degree, that resulting precision is still rather poor, at 5-6 %. The potential pattern user will consequently see a lot of spurious results 10 http://ontologydesignpatterns.org/wiki/Submissions:Place 11 http://ontologydesignpatterns.org/wiki/Submissions:Information\ _realization 12 http://ontologydesignpatterns.org/wiki/Submissions:AgentRole 13 http://ontologydesignpatterns.org/wiki/Submissions:ParticipantRole using either of the approaches. This is understood to be a potential usability problem, and an area for further work.
A factor believed to be limiting the success of this method is the fact that resolving ODP concepts and properties to corresponding concepts and properties in natural language resources (in this case WordNet) is an error-prone process. This is largely due to the ambiguity of language and the fact that concepts in ODPs are generally described using only a single label per supported language. If pattern concepts were more thoroughly documented, using for instance more synonymous labels, class sense disambiguation would likely work better, and ODP search consequently work better also. Additionally, WordNet does contain parts of questionable quality (both in terms of coverage and structure), the improvement of which may lead to increased quality of results for dependent methods such as the one presented here. 7
This paper has introduced and discussed some concrete challenges regarding the use of Ontology Design Patterns, with an emphasis on tooling-related challenges that prevent non-expert users from performing Ontology Engineering using such patterns. Those challenges primarily concern; a) the task of nding patterns, b) decisions to make when integrating pattern based modules with an existing ontology, and, c) pattern and tooling quality. The author's work aims to overcome these challenges by developing improved methods and accompanying tools for today's Ontology Engineering IDE:s (i.e., Protege), better supporting each step of ODP application and use.
The author has developed an ODP search method exploiting both the similarity between pattern competency questions and user queries, and the relative abstraction level of general pattern solutions versus concrete user queries, a method shown to increase recall when searching for candidate ODPs signi cantly. Future work includes improving recall and precision further, and developing methods and tooling to support the ODP integration task.