Reusing knowledge resources, specifically Ontology Design Patterns (ODPs), has became a popular technique within the ontology engineering field. Such a reuse allows speeding up the ontology development process, saving time and money, and promoting the application of good practices. Recently methods and tools to support the reuse of ODPs have emerged. In addition, the existence of detailed examples of real use cases that reuse ODPs favours the adoption and application of such methods. Thus, our objective in this paper is to show an example of how to apply a method for reusing ODPs during the development of a context ontology network to model context-related knowledge that allows adapting applications based on user context. Besides, in this paper we present the main drawbacks found during the application of the reuse method as well as some proposals to overcome them.
With the goal of speeding up the ontology development process, ontology
practitioners are starting to reuse [
Regarding the ODPs, their reuse has proven different benefits [
However, methods and tools are not enough to guarantee a successful reuse of ODPs. In this regard, the existence of detailed examples of how ODPs are reused in real use cases would be of great help. This kind of guided examples would favour the adoption of ODPs and their related methodological and technological support.
Thus, our main objective in this paper is to present a guided example of how we have carried out the reuse of ODPs during the development of an ontology network about user’s contextual information, called mIO! ontology network. This ontology network is a context ontology in the mobile environment that aims to represent contextual knowledge about the user that can influence his interaction with mobile devices. In addition, we also show in this paper some lessons learned during the application of the method for reusing ODPs as well as some proposals for overcoming the drawbacks found in the method.
The remainder of the paper is structured as follows: Section 2 summarizes the state of the art on methodological and technological aspects of the ODPs reuse. Section 3 describes in detail how we have followed the guidelines to reuse ODPs as well as how we have adapted such guidelines during the development of the mIO! ontology network. Section 4 shows the lessons learned during the ODPs reuse. Finally, Section 5 concludes and shows some lines of future work.
The idea of applying patterns for modelling ontologies was proposed by [
Generally patterns are perceived as having three kinds of benefits [
Even when such benefits have been established, there is the need to provide methodological and technological support to the pattern usage with the goal of (a) minimising the reuse effort and (b) maximising the ODPs benefits. In this regard, methods and tools have recently appeared to guide and support the ODPs reuse.
On the one hand, a method for reuse any type of ODP, called XD (for eXtreme
Design), is presented in [
Document (ORSD) and a set of available ODPs, and as output an ontology network
including the ODPs reused. In summary, the workflow starts with the identification of
the requirements to be addressed by reusing ODPs and the available ODPs registries
and libraries. Next, an iterative set of tasks takes place in which (a) each problem is
divided into sub-problems, (b) a sub-problem is selected and matched with the ODPs,
(c) the ODPs are selected and applied, and (d) the result is evaluated. This cycle is
repeated until all the sub-problems are addressed. Finally, the method concludes by
integrating all the partial solutions resulting in an ontology network which contains
the ODPs selected. The XD method could be specialized to address the reuse of
concrete types of ODPs, for example, content patterns [
It is well known that the adoption of any emerging methodology or method is facilitated by providing detailed examples of how to apply them to real and complete use cases. However, as far as we know, there are no complete examples of how to apply the XD method to the reuse of any type of ODP. Thus, we present in this paper a detailed example of how we have reused different types of ODPs during the development of a context ontology network.
On the other hand, there are also tools that provide a technological support for the ODPs reuse activity. The plug-in for NeOn Toolkit4 called “XD Tools”5 allows the content ODPs reuse accordingly to this variant of the XD method. Whereas, the ontology editor Protégé 3.4.46 allows the automatic reuse7 of the following logical patterns and good practices: “Value Partition”, “Enumeration”, “N-ary Relation”, “OWL List”, and “RDF List”.
As already mentioned, the main purpose of this context ontology, called mIO! ontology network, is to represent knowledge related to the user context, e.g., information on location and time, user information and its current or planned activities, as well as devices located in his surroundings. The ontology aims at solving the challenge of configuring, discovering, executing, and enhancing services based on the user context.
The development of this ontology network about contextual information has been
carried out following the NeOn Methodology [
To reuse ODPs we have applied the general method described in [
Thus, in this section we describe (a) how we have applied the general XD method8 for reusing different types of ODPs and (b) how we have adapted and/or extended the guidelines provided by the method.
To identify the requirement to be addressed by means of the reuse of ODPs, we
have chosen the third question proposed in [
The main drawback at this point is the fact that to be able to answer this question developers should be versed in ODPs types. In this sense, based on our knowledge about ODPs, we have not selected those requirements that could be addressed by existing ODPs types but those that apparently can be solved by reusing existing ODPs.
Table 1 shows both the non-functional and the functional requirements extracted
from the ORSD9 that will be addressed by reusing ODPs. The functional
requirements belong to the following subdomains as we can observe in the identifier10
field: Interface (INT), Device (DSP), Time (TMP), Location (LOC), and User (USR).
These functional requirements can be written both as Competency Questions (CQs)
and their corresponding responses [
To carry out this task, first we have identified different libraries and repositories in which patterns could be found. Next, based on our knowledge about ODPs and on - storage device - processing device - communication interface - screen - communication interface - positioning device - lighting device - screen - microphone - screen - speaker - microphone - signal processing module - active element - casing A condenser microphone is composed by: - diaphragm of lightweight and flexible membrane - rigid backplate - cable to the preamplifier - bias voltage feeder What are the days of the week? Monday, Tuesday, Wednesday, Thursday, Friday, Saturday and Sunday When was the last time that the user was in the location X? The day Z from xx: xx: xx to yy: yy: yy
Affirmative NL Sentence The interfaces types are: - conversational - multi screen - gestural - touch - graphic - textual - natural language - vocal - command line - web A user will be in a specific location at any given time. The possible physical movement of the user is associated with this aspect their descriptions11 and uses we have sketched preliminary correspondences between the requirements selected in Task 1 and the available ODPs. Note that there are patterns that belong to several libraries or repositories.
The ODPs resources and the ODPs suitable to be reused are:
• Ontology Design Patterns (ODP) Portal12: this Wiki aims to gather ODPs in
a repository. The patterns are reviewed by a quality committee. Besides, users
can submit new patterns or modelling issues. In this portal we have found the
following suitable patterns to be reused within the mIO! ontology network
development:
o Componency
o N-Ary Participation
• W3C Semantic Web Best Practices and Deployment (SWBPD)13: this
repository contains pattern descriptions and some examples of modelling
patterns. The repository also includes other types of best practices as
guidelines, repositories of vocabularies and ontologies, learning material, and
demos. In this repository we have found the following suitable patterns to be
reused within the mIO! ontology network development:
o N-ary Relations. Pattern 1: Introducing a new class for a relation
o Specified Values in OWL: "value partitions" and "value sets"
• NeOn D2.5.1 [
To illustrate how we have mentally sketched a correspondence between requirements and possible ODPs we present here some examples.
Let us take the DSP_PC9 requirement as the starting point. We can observe that in the requirement appear the terms “components”, “composed by” and a list of the parts 11 These descriptions usually include (a) the name of the pattern, (b) a graphical description, (c) an enumeration of its elements, and (d) a set of requirements (in the form of CQs) or use cases (in the form of sentences in natural language) the pattern is intended to address.
Sometimes, the code in an ontology implementation language is also provided. 12 http://ontologydesignpatterns.org/ 13 http://www.w3.org/2001/sw/BestPractices/ that form a display. These characteristics of the requirement are clues to think about the “Part-Whole Relation” or “Componency” patterns due to the information included in the description and uses cases of these patterns. The same reasoning can be applied to the requirements DSP_PC49, DSP_PC61, DSP_PC71, DSP_PC83, DSP_PC96, and DSP_PC102.
In the case of the requirement TMP_PC4 the days of the week are enumerated. It is well known that this is a unique enumeration and the days of the week are different among them. These features can lead a developer to think in the “Specified Values: Set of Individuals” and the “Specified Values: Subclasses” patterns.
At this point the method [
In our case, the selected requirements are quite simple so it was not necessary to divide them. In fact, some of them have been grouped during the transformation because of their similarity. Besides, we have only transformed the functional requirements since the non-functional one represents a “manageable piece” itself.
To perform the transformation of the problem we propose the following approach.
We have taken into account that the functional requirements selected in Task 1 can be
written as CQs and their responses or as affirmative sentences in natural language as
Table 1 shown. In addition, we have observed that some suitable patterns to be reused
(e.g. the Taxonomy (AP-TX-01) pattern [
It should be noted that there are no guidelines to carry out the requirements transformation. In our case, we have carried out the transformation based on how general are the original requirements in the ORSD. Having in mind this approach, we have abstracted the requirements in order to make them similar to the ODPs descriptions. For example, in the requirements DSP_PC9, DSP_PC49, DSP_PC61, DSP_PC71, DSP_PC83, DSP_PC96, and DSP_PC102 a list of components is shown for each concrete device. During the transformation, we have abstracted these requirements writing them as a unique CQ that could be applied to any of them and that could be match with the CQs addressed by some available patterns.
It is important to mention here that there are two important drawbacks at this point of the reuse. First, we cannot transform the requirements only into CQs because there are ODPs that only have in their descriptions use cases written as sentences in natural language, as we have already noted. Second, ontology developers should be well versed in ODPs to discern what type of transformation they should carry out. Therefore, we have realized the high importance of making a finer identification of the most suitable ODPs in Task 2.
As it can be observed in Table 3 none of the requirements has been divided into sub-problems, but they have been simply transformed. Therefore, it was not necessary to assign a new numbering for the partial problems since they correspond to the identifier of each requirement.
The matching between the problems to be addressed by reusing ODPs and the ODPs available in libraries and repositories, identified in Task 2, is shown in Table 4.
Transformation Perform categorization/classification of interface types at different extents of granularity.
Perform categorization/classification of devices at different extents of granularity.
Suitable pattern(s) • Taxonomy (AP-TX-01) • Taxonomy (AP-TX-01)
What are the components of this device?
It is important to mention that at this point the method does not provide detailed guidelines about how to match the requirements with the available patterns. As we have explained in Task 1, we have selected those requirements that could be covered by at least one available ODP. Based on our knowledge about ODPs and on our experience reusing them, we can propose the following heuristics to quickly identify a suitable ODP to be reused while reading the requirements: • If a requirement mentions something about a list of values, we could infer that the “Specified Values in OWL: "value partitions" and "value sets"”, the “Specified Values: Set of Individuals (LP-SV-01)” or the “Specified Values: Subclasses (LP-SV-02)” patterns could be reused. • If a requirement is about types and subtypes of a given concept, we could infer that the “Taxonomy (AP-TX-01)” pattern could be reused. • If a requirement contains more than two concepts related, we could infer that the “N-Ary Participation”, “N-ary Relations. Pattern 1: Introducing a new class for a relation”, “N-ary Participation (CP-NPAR-01)” or the “N-ary Relation: New Class (LP-NR-01)” patterns could be reused.
If a requirement is about parts of something, we could infer that the “Componency”, “Componency (CP-COM-01)” or “Part-Whole Relation (CPPW-01)” patterns could be reused.
If a requirement is about the need for modularity within the ontology, we could infer that the “Modular Architecture (AP-MD-01)” pattern could be reused.
At this point, we must select the most appropriate pattern in those cases identified
in Task 4 in which there are several suitable patterns to cover the requirements. Since
there are no detailed guidelines to perform this task, we have taken the following
decisions for requirements related to more than one potential ODP:
• For the requirements DSP_PC9, DSP_PC49, DSP_PC61, DSP_PC71,
DSP_PC83, DSP_PC96, and DSP_PC102, there is no need to represent
transitive relationships. For this reason, we have selected the “Componency
(CP-COM-01)” pattern instead of the “Part-Whole Relation (CP-PW-01)”
pattern. It is important to mention that we have reused the “Componency”
pattern from the ODP Portal instead of the one included in the NeOn D2.5.1
[
It is worth mentioning that for the non-functional requirement and for the requirements INT_CA3 and DSP_PC7, the ODPs related to those requirements in Table 4 have been directly selected.
In this task we have observed that ODPs can take different roles in different stages of an ontology development process depending on their types and the problem that they address. For example, we have distinguished the following situations: • Reusing ODPs to define the architecture of the ontology network during the conceptualization activity through the “Modular Architecture (AP-MD-01)” pattern. • Reusing ODPs in the implementation activity to complete the knowledge represented; for example, we can enrich a mereological relationship through the “Componency (CP-COM-01)” pattern. 14 In this case the use of the “Specified Values: Set of Individuals (LP-SV-01)” pattern and the “Specified Values in OWL: "value partitions" and "value sets"” patterns would be equivalent. 15 In this case the use of the “N-ary Relation: New Class (LP-NR-01)” pattern and the “N-ary Relations. Pattern 1: Introducing a new class for a relation” patterns would be equivalent.
Reusing ODPs in the implementation activity to represent logical structures that are not supported by the ontology language, for example, the “N-ary Relation: New Class (LP-NR-01)” pattern.
Reusing ODPs in the implementation activity to join concepts from different ontologies, for example, thorough the “N-ary Relation: New Class (LP-NR01)” pattern.
In addition, here we show the result of applying the patterns selected in Task 5 to the mIO! ontology network16.
The reuse of the “Modular Architecture (AP-MD-01)” pattern has given rise to the modular structure that forms the miO! ontology network. Such a structure is shown in Fig. 117.
The reuse of the “Componency (CP-COM-01)” pattern has been carried out within
the Device.owl ontology by importing (See [
The result of reusing the “Specified Values: Set of Individuals (LP-SV-01)” pattern during the modelling of the days of the week is shown in Fig. 318.
Fig. 419 depicts the result of reusing the “N-ary Relation: New Class (LP-NR-01)” pattern to model the location of a user at given point of time. In the model shown in Fig. 4 has been taken into account both locations in a geo-political entity, such as a country or a city, and locations specified by coordinates.
Finally, it is worth mentioning that Task 7 (Evaluate and revise with respect to
partial problem) and Task 8 (Integrate partial solutions) have not been carried out as
authors propose in [
After the application of the general XD method to reuse ODPs during the development of the mIO! ontology network, we have realized (a) the usefulness of following a method to guide the ODPs reuse during the ontology building and (b) the advantages of reusing ODPs, ensuring the use of good practices in the ontology.
However, we have also realized the difficulty of applying the abovementioned method because of the lack of detailed guidelines in some of the tasks. For this reason in this section we report (a) some of the lessons we have learned during the application of the method as well as (b) some proposals that could be valuable for any enhancement of the method and/or for any further development that reuses ODPs.
During the execution of Task 1, we have realized that a beginner could select
requirements that cannot be solved by means of reusing ODPs when he/she answers
the questions proposed in [
We can also add that in those cases in which a beginner selects requirements that
cannot be solved by means of ODP reuse, such a developer would have at least the
following two options: (a) to propose a new pattern to cover such requirements and
(b) to cover such requirements with other knowledge resources (such as ontologies or
non-ontological resources) as proposed in [
In the case of Task 2, we also consider that experience with ODPs is required again. In this task some types of patterns, as content patterns, can be identified as suitable to be reused by means of tools (e.g., XD Tools); however, there are other types of patterns that cannot be identified using tools due to (a) such patterns have no CQs in their description to match with the requirements to be addressed or (b) the patterns are not available at on-line libraries. Thus, in these cases, the ontology developer should have large knowledge about both ODPs and repositories to identify manually the patterns.
Besides, in this task it could happen that for a given requirement there are no
patterns related or that the developers cannot find patterns suitable to be reused. In
that case, we propose the following alternatives that can be included in the method:
(a) to posting a modelling issue20 within the ODP Portal related to the given
requirement; (b) to look for others resources suitable to be reused such as ontologies
or non-ontological resources as explained in [
To carry out Task 3 the method [
Regarding to Task 4, based on our experience applying the method, this task only seems necessary if at least one requirement has been divided in Task 3. In other cases, Task 4 can be considered similar to Task 2.
We can also mention that after performing Task 5 it is possible that no pattern matches with the problem to be addressed. In this case, we propose to follow the same options already presented for Task 2.
Finally, we have observed that ODPs can be applied at different points of an ontology development. For example, in the mIO! ontology network case the “Modular Architecture (AP-MD-01)” pattern was applied during the conceptualization activity whereas the rest of patterns were applied during the implementation activity.
This paper presents an example of how to apply the general XD method to reuse different types of ODPs (logical, architectural, and content patterns). This application has been performed with a real use case within the development of a context ontology network, called mIO! ontology network22. This guided example could be used together with the method in further ontology developments, what would favour the adoption of ODPs and of the abovementioned method.
During the process we have taken advantage of following a guided method that sets and orders the tasks to carry out during the reuse of ODPs. The method also provides some examples or criteria to take into account as well as a list of catalogues where to find ODPs. Once the method was applied, we have realized that time was saved in the conceptualization and implementation activities.
However, we have also identified some points during the reuse process where the developers’ experience on ODPs seems quite important (tasks 1 and 2). In addition, we have discovered some drawbacks in the general XD method that could be solved by extending and improving the guidelines for tasks 1, 2, 3, and 5, as already explained in Section 4.
As future work we have plan to apply the XD method together with the XD Tools in a collaborative ontology development within a real use case. The idea of this new application of the method is to focus on requirements that have to be divided into 20 http://ontologydesignpatterns.org/wiki/Community:PostModelingIssue 21 http://ontologydesignpatterns.org/wiki/Submissions:SubmitAPattern 22 http://www.oeg-upm.net/index.php/es/ontologies/82-mio-ontologies different sub-problems. Our final aim is to analyze (a) what tasks the XD Tools make easier and (b) what tasks still need more detailed guidelines.
Acknowledgments. This work has been partially supported by the Spanish project mIO! (CENIT-2008-1019).