In this paper, we present eXtreme Design with Content Ontology Design Patterns (XD): a collaborative, incremental, iterative method for pattern-based ontology design. We also describe the first version of a supporting tool that has been implemented and is available as a plugin for the NeOn Toolkit. XD is defined in the context of a general approach to ontology design based on patterns, which is also briefly introduce in this work.
Ontology design patterns (ODPs) [
XD adopts the notion of ontology project, a development project characterized
by two main sets: (i) the problem space, which is composed of the actual modeling
issues, here referred to as the local problems, that have to be addressed during
the project e.g., to transform a set of microformats to an RDF dataset, to model
roles that can be played by people during certain time periods; (ii) the
solution space, which is made up of reusable modeling solutions e.g. a reengineering
practice for associating microformats’ attributes to a certain RDF vocabulary’s
relations, a piece of an ontology that models time-indexed roles i.e. a CP.
The general approach is schematized in Figure 1. Each element in the solution
space is an ODP associated with a Generic Use Case (GUC), the latter
representing the problem that the ODP provides a solution for, as introduced by [
All matching ODPs are selected and used according to specific guidelines and possibly with some tool support.
In this paper, we focus on XD guidelines for CPs, where GUCs and LUCs are
expressed in the form of natural language competency questions, and ODPs are
CPs. In the rest of the paper XD is used for referring to XD with CPs.
XD is partly inspired by software engineering eXtreme Programming (XP) [
Although XD has similarities with the two approaches, its focus is different:
where XP diminishes the value of careful design, this is exactly where XD has
its main focus. XD is test-driven, and applies the divide-and-conquer approach
as well as XP does. Also, XD adopts pair design, as opposed to pair
programming. The intensive use of CPs, modular design, and collaboration are the main
principles of the method. While a rigorous evaluation of the whole methodology
is still in our future plans, the effectiveness of CPs in ontology design has been
rigorously evaluated in [
The paper is structured as follows: in Section 1.1 we briefly discuss the state of art on ontology design methodologies and ontology design patterns. Section 2 discusses the principles of the method and details the XD workflow with the help of a simplified scenario taken from a real case study. Section 3 describes XD tool, a NeOn Toolkit2 plugin for pattern-based design support. 1.1
The notion of “pattern” has proved useful in the context of design within
many areas, such as architecture, software engineering, etc. So far, very few
purely pattern-based methodologies have been proposed. In ontology
engineering, pattern-based methods are present primarily on the logical level, where
patterns support methods for ontology learning, enrichment and similar tasks
like in [
In this section, we describe the methodological guidelines for applying XD with Content ODPs (CPs), through the definition of an iterative workflow and a case example showing an actual iteration.
The XD method with CPs is the result of the observation and consequent description of the way we (in our lab) use to develop ontologies with CPs. Since 2005, we have been developing CPs, teaching pattern-based ontology design in conference tutorials and PhD courses, and for much longer we have been using and refining this approach for our professional work.
In order to teach pattern-based design to PhD students and practitioners, we needed to provide trainees with guidelines to follow. This requirement provided us with a good occasion for defining the XD method with CPs, and also with a context for running the method with different teams, and applying possible refinement/adjustment. So far, we have identified the main principles and setting of the method, defined the iterative workflow, identified a set of requirements for tool support, started supporting tools development, and identified and started investigation of open issues.
XD principles. XD principles are inspired by those of the agile software
methodology called eXtreme Programming (XP) [
The XD method is inspired by XP in many ways but its focus is different: where
XP diminishes the value of careful design, this is exactly where XD has its main
focus. Of course, designing software and designing ontologies is inherently
different, but still there are many lessons to be learnt from programming. XD is
test-driven, and applies the divide-and-conquer approach as well as XP does.
Also, XD adopts pair design, as opposed to pair programming. Although we
did not perform yet a formal evaluation of pair design’s effectiveness, we have
collected trainees feedback through informal discussions and questionnaires
after the executions of XD with different trainees teams. Most of them feel to
take benefit from on-the-fly brainstorming, and perceive to improve the effect of
learning-by-doing with this setting. We have planned to conduct more rigorous
evaluation of the method which also involves the analysis of this aspect.
The intensive use of CPs, modular design, and collaboration are the main
principles of the method. The effectiveness of CPs in ontology design has been
rigorously evaluated in [
The main principles of the XD method can be summarized as follows:
– Customer involvement and feedback. The development of an
ontology is part of a bigger picture, where typically a software project is under
development. Ideally, the customer should be involved in the ontology
development and its representative should be a team, whose members are aware
of all parts and needs of the project. For example, the roles that should be
represented include: domain experts i.e. persons with deep knowledge of the
domain to be described by the ontology; those who are in charge of
maintaining the knowledge/data bases i.e. persons who know the views over the
data that are usually required by users; those who control/coordinate
organization processes i.e. persons who have an overall view on the entire flow of
data; etc. Depending on the project characteristics, and on the complexity of
the organization, the customer representative can be one person or a team.
It is important that the team of designers is able to easily interact with the
customer representative in order to minimize the possible number of
assumptions that they have to make on the incomplete requirement descriprions i.e.
assumptions on the implicit knowledge, without discussing/validating them
first. Interaction with the customer representative is key for favoring the
explicit expression of knowledge that is usually implicit in requirement
documents, including competency questions. Furthermore, the customer
representative should be able to describe what tasks the application involving the
ontology is expected to solve.
– Customer stories, Competency Questions (CQs), and contextual
statements. The ontology requirements and its tasks are described in terms
of small stories by the customer representative. Designers work on those
small stories and, together with the customer, transform them in the form
of CQs and contextual statements. Contextual statements are accompanying
assertions that explicit knowledge that is typically implicit in CQs. CQs
and contextual statements will be used through the whole development, and
their definition is a key phase as the designers have the challenge to help the
customer in making explicit as much implicit knowledge as possible.
– CP reuse and modular design. If there is a CP’s GUC that matches a
LUC it has to be reused, otherwise a new module i.e. a CP with its GUC,
is defined based on the LUC under development and shared with the team
(and ideally on the Web3).
– Collaboration and Integration. Integration is a key aspect of XD as the
ontology is developed in a modular way. Collaboration and constant sharing
of knowledge is needed in a XD setting, in fact similar or even the same CQs
and sentences can be defined for different stories. When this happens, it is
important e.g. that the same CP is reused.
3 For example on http://ontologydesignpatterns.org
– Task-oriented design The focus of the design is on that part of the
domain of knowledge under investigation that is needed in order to address the
user stories, and more generally, the tasks that the ontology is expected to
address. This is opposed to the more philosophical approach of formal
ontology design where the aim is to be comprehensive with respect to a certain
domain.
– Test-driven design. Stories, CQs, and contextual statements are used in
order to develop unit tests. A new story can be treated only when all unit
tests associated with it have been passed. This aspect enforces the
taskoriented approach of the method. It has to be noticed that in this context,
“unit tests” have a completely different meaning with respect to software
engineering unit tests. An ontology module developed for addressing a
certain user story associated to a certain competency question, is tested e.g.
(i) by encoding in the ontology4 a sample set of facts based on the user
story, (ii) defining one or a set of SPARQL queries that formally encode
the competency question, (iii) associating each SPARQL query with the
expected result, and (i) running the SPARQL queries against the ontology and
compare actual with expected results. Unit tests for ontologies have been
analyzed already in [
The next section shows details of the XD iterative workflow. 2.1
4 According to the common way of using the term “ontology”, in this context we do not distinguish between TBox and ABox, or ontology and knowledge base. Here, an ontology includes also facts.
Task 1. Get into the project context. The development starts with a group of designers and a group of domain experts i.e. the customer representative. In principle they do not know much about each other, do not have a precise idea of what will be the result of the project, are used at different terminology, and have a different background. This task has a twofold objective: (i) make the customer representative aware of the method and tools that will be applied during the project, (ii) provide the designer team with an overview of the problem, its scope, and initial terminology.
The result of this task is the setting up of a collaborative environment where customer and designers will share documentation and argument about modeling issues, including terminology i.e. a wiki for the project.
Task 2. Collect requirement stories. The customer representative is invited to write stories, possibly from real, documented scenarios, that samples the typical facts that should be stored in the resulting ontology5. All stories are organized in terms of priority, and possible dependencies between them are identified and made explicit6. Each story is described by means of a small card, 5 We do not distinguish between TBox and ABox, ontology and knowledge base. With the term ontology we encompass both according with the current trend in the Semantic Web community. 6 E.g., a story can be modeled only if another story already has been successfully addressed like the one depicted in Table 1, which includes the story’s title, a list of other stories which it depends on, a description in natural language, and a priority value7. It is important to notice that this task is not intended to be performed only once during the project. Stories can be added by the customer during the whole project life cycle. For example, if a new requirement emerges new stories can be written.
signers selects a story that will be the focus of their work for the next iteration. A new wiki page for the story is created: the name of the page is the title of the story, and its content is set up based on the information that are in the card. By performing this task a pair enter a development iteration. For example, consider that a pair has selected the story described by the card in Table 1.
it derive a set of CQs. In order to do that, designers could involve the customer for having feedback/clarifications. First the story is split into simple sentences, meaning that complex example sentences may be broken up into shorter sentences to increase clarity. The sentences are abstracted so that they describe a class of facts instead of a specific one. The sentences are then transformed into CQs. For example, the story “Tuna observation” is transformed to the following CQs8, which are added in the story wiki page: – CQ1: What are the exploitation state and vertical distance observed in a given climatic zone for a certain resource? – CQ2: What resources have been observed during a certain period in a certain water area? Additionally, the following contextual statement is derived from the discussion with the customer representative9: – A resource contains one or more species. 7 Priority values are assigned by designers based on interaction with the customer representative. The values can vary and depends on project’s conventions. 8 The elaboration of the story is a complex cognitive procedure which is not explained here. It would deserve a dedicated discussion which is out of scope of this paper. 9 There would be additional ones, we have simplified for the sake of brevity. – Species are associated to vertical distances. As a consequence, the vertical distance of a resource is inferred through the vertical distance of the species. Contextual statements are listed in a dedicated wiki page, and are handled by the pair in charge of the integration task.
ues by selecting one of the CQs. For example, CQ1.
Task 6. Match the CQ to GUCs. This task has the aim of identifying
candidate CPs based on the CQ, which express part of the LUC. The matching
procedure can be done either with some tool support e.g., keyword based searching, or
manually e.g., if the designers have a good knowledge of available CPs. We here
assume that designer manually perform the matching against the
ontologydesignpatterns.org repository [
Task 7. Select the CPs to reuse. The goal of this task is to select which of those patterns should be used for solving the modeling problem. We may decide that time interval adds too much extra effort, besides the needed year of observation, in which case we will only select situation.
Task 8. Reuse and integrate selected CPs. The term “reuse” here refers
to the application of typical operation that can be applied to CPs i.e.
import, specialization, and composition [
Task 9. Test and fix. The goal of this task is to validate the resulting module with respect to the CQ just modeled. To this aim, the task is executed through the following steps: (i) the CQ is elaborated in order to derive a unit test e.g., SPARQL query; (ii) the instance module is fed with sample facts based on the story; (iii) the unit test is ran against the ontology module. If the result is not the expected one i.e. the test is not passed, the module is revised in order to fix it, and the unit test ran again until the test is passed; (iv) run all other unit tests associated with the story so far until they all pass. Notice that all unit tests are described in dedicated wiki pages that are properly linked to the associated story. If all CQs associated to the story have been addressed, the pair can pass to Task 10, otherwise they “go back” to Task 5. In our example, the unit test associated to CQ1 is the following: SELECT ?exp ?dist ?resource ?zone WHERE { ?obs a :AquaticResourceObservation . ?obs observedResource ?resource . ?obs inClimaticZone ?zone ?obs inState ?exp . ?obs atVerticalDistance ?dist } Task 10. Release module. This task identifies the end of an iteration for a pair and its result is an ontology module. Once a whole story has been addressed, and the resulting module has been successfully tested, the new module can be released. The module is assigned with a URI and published in order to be shared by the whole team. If the module can be publicly shared, it can be published in open Web repositories such as ontologydesignpatterns.org. The module is then passed to the pair in charge of the integration. The pair of designer selects a new story if there are still some unaddressed.
Task 11. Integrate, test and fix. Once a new module is released, it has to be integrated with all the others that constitute the current version of the ontology. At least one pair is in charge of performing integration and related tests: new unit tests are defined for the integration, and all existing ones are again executed as regression tests before moving to next task. In this task, all contextual statements are taken into account and all necessary alignment axioms are defined. The module is now under the complete control and editing of the pair in charge of the integration. The products of this tasks are new unit tests and alignment axioms, all properly documented in the wiki.
been passed, a new version of the ontology can be released. 3
The eXtreme Design plugin for NeOn Toolkit11 (XD tool) supports patternbased ontology design. Its current version12, focusses on XD with CPs, and supports some of the tasks described in Section 2. The main goal of XD tool is to improve the user experience with ontology design editors by providing them with a new interaction approach to ontology design. Instead of performing languageoriented operations e.g. instantiate a class, define a subclass, etc., the designer handles “pieces” of ontologies i.e. CPs, and is helped in performing modular design and applying design good practices.
The tool provide an Eclipse perspective, named “eXtreme Design”, that includes 11 http://www.neon-toolkit.org 12 Available at http://stlab.istc.cnr.it/stlab/Download the following components: CP browser and CP details view, XD annotation dialog, XD selector, XD assistant, XD wizards. In the following sections, these components are described in detail. 3.1
The CP browser relies on a remote connection to registries of CPs. By default, XD tool allows to browse all CPs available at ontologydesignpatterns.org. The repository of CPs is visualized according to a semantic description based on the codolight 13 ontology. This approach makes the XD tool able to easily add new repositories to the browser, once it is provided with a codolight-based OWL description of them. This view allows the user to browse and select CPs as shown in Figure 5(a). The CP details view shows all available annotations of the selected CP. From the CP browser, a CP can be specialized and imported in the ontology under development.
(a) CP browser.
(b) XD annotation dialog. The XD annotation dialog, shown in Figure 5, supports multilingual annotation of ontology modules or CPs. This dialog supports a number of default vocabularies, and custom ones can be added. One of the vocabularies available by default is the CP annotation schema14, an OWL ontology particularly suited for annotating CPs. 3.3
The XD selector provides the infrastructure for plugging into XD a component
implementing a matching/searching algorithm that starting from a CQ gives
as output a selection of candidate CPs. Currently only the APIs have been
implemented, we are working at two proofs of concept components: an instance
of Watson [
This component is able to provide the user with feedback related to possible mistakes and suggestions on good practices in a certain modeling situation. The XD assistant has a plugin-based architecture that make it easy to extend the help elements based on new emerging good/bad practices.
The XD assistant communicates two types of messages to the user: (i) Warnings: these messages are visualized when there is a strong suspect of wrong design. E.g. there is an anti-pattern in the module; (ii) Suggestions: these messages are visualized in order to suggest axioms currently missing in the module, that could improve the design. 3.5
XD also features a set of wizards. At the moment it includes a wizard for supporting CP specialization. The wizard can be accessed in the CP browser view, (a) Step 3: create specialized entities.
(b) Step 4: check statements that are true. by the command “specialized” included in the contextual menu that can be activated by right.clicking on the CP to be specialized (selected from the repository). The wizard guides the user through the following steps: Step 1. The user selects the project and the target ontology (if any). Additionally, the user has to check one of three possible results that can be produced by the wizard:(i) Create a new module/CP and import it in the target ontology ; (ii) Create a new module/CP and store it in the indicated project ; (iii) Merge the resulting entities in the target ontology.
Step 2. All entity leaves are displayed to the user that is invited to select the entities to be specialized.
Step 3. For each selected entity the user creates the new specific one as shown in Figure 6(a).
Step 4. The wizard suggests possible axioms that can be added to the ontology by means of natural language statements. The users can automatically produce these additional axioms by selecting the assertions that they consider “true” in their context. This step of the wizard is depicted in Figure 6(b). Step 5. Finally, an overview of natural language assertions corresponding to the formal axioms stated in the developed module is shown. This step has the aim of giving the users the possibility to review the result before to produce the module. They can always go back to a certain step in order to fix possible mistakes. 4
In this paper, we have discussed eXtreme Design (XD), an approach to ontology design based on the application, exploitation, and definition of ontology design patterns (ODPs). In more detail, we have presented two main contributions: a collaborative, incremental, and iterative method for pattern-based ontology design; and a first version of the XD tool, a NeOn Toolkit plugin that currently supports CP repository browsing and selection, a good practice assistant, and a wizard for CPs’ specialization.
XD main principles are collaboration, integration, testing, and the extensive
use of CPs. XD has been inspired by good practices typically adopted by the
eXtreme Programming (XP) [
In order to ease the execution of the method some automatic support is needed. For example, matching CQs with GUCs is a complex task and automatic support for filtering candidate CPs is necessary in order to exploit at best the evolving repositories of CPs. For addressing this type of needs, we have developed a NeOn Toolkit plugin, named “XD tool”, that currently support CP browsing, annotation, and specialization. Furthermore, it provides APIs for pluggin-in components that implement matching algorithms. A lot of work is still ongoing, including the development of two components supporting matching/selection of CPs. As future work, we have planned to continue with XD tool development, and to conduct frequent user studies in order to evaluate and improve the methodology as well as to collect feedback and suggestions on the XD tool.