<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>A Pattern-based Ontology Building Method for Ambient Environments</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Wolfgang Maass</string-name>
          <email>wolfgang.maass@hs-furtwangen.de</email>
          <email>wolfgang.maass@unisg.ch</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Sabine Janzen</string-name>
          <email>sabine.janzen@hs-furtwangen.de</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Institute of Technology Management, University of St. Gallen Dufourstrasse 40a</institution>
          ,
          <addr-line>CH-9000 St. Gallen</addr-line>
          ,
          <country country="CH">Switzerland</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Research Center for Intelligent Media (RCIM) Furtwangen University</institution>
          ,
          <addr-line>Robert-Gerwig-Platz 1 D-78120 Furtwangen</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Ambient environments are characterized by an ever increasing amount of information that needs to be selected and organized in order to make correct assumptions about users, entities, etc. within a specific context. This issue can be addressed by using ontologies that meet the specific requirements of such environments. In this paper, we survey ontology engineering methods that represent an adequate approach to creating adequate ontologies. Because unprecedented, we introduce a Pattern-based Ontology Building Method for Ambient Environments (POnA) and exemplify this method through the development of a domain-specific ontology for cosmetic products within ambient shopping environments.</p>
      </abstract>
      <kwd-group>
        <kwd>Ambient environments</kwd>
        <kwd>design patterns</kwd>
        <kwd>ontology engineering methods</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        In recent years, research in intelligent environments and entities has increased.
The embedding of adaptive information and communication services into
everyday physical things characterizes ambient environments (Ambient Intelligence
(AmI)). A number of prototype systems for ambient environments have been
designed and implemented, such as [
        <xref ref-type="bibr" rid="ref1 ref2 ref3 ref4">1–4</xref>
        ]. The challenge is to interpret sensor
data so that adaptive behavior of ambient environments can be generated which
naturally supports users in, for instance, situations of problem solving, relaxing,
informing, and communicating with other users. Available information needs to
be selected and organized so that ambient environments are able to make correct
assumptions about users and physical entities within a specific context [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ].
However, a major shortcoming of these AmI systems is weak support of knowledge
sharing [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ], i.e., AmI systems are typically based on proprietary and fixed sets of
representations that are designed for particular AmI applications. This, in turn,
poses hurdles for integrating external information that is stored in the
infosphere of digital environments, such as the World Wide Web (WWW). Bridging
the gap between sensor-data-driven applications and infospheres requires
interoperable knowledge representations. Through this, information can be reused in
both directions. Because both AmI environments and infospheres can become
quite complex, a more principled, ontology-driven approach for the creation of
appropriate knowledge representations is required [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]. Initial approaches were
top-down approaches based on foundational ontologies that drilled down
conceptual structures until they reached a conceptual level compatible with
information derived from sensor data (e.g., [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]). For complexity reasons, these systems
neglected most of the ontological structure that are given by the overarching
ontology, which meant that the ontology was only helpful at design time. In these
systems, semantics coded into ontological structures were typically not used at
run-time.
      </p>
      <p>
        Some applications that used ontologies indicated the value of smaller pieces
of more abstract ontological structures, called design patterns, that could reused.
The idea of design patterns has several origins, such as Christopher Alexander’s
work on design patterns in architecture, Kevin Lynch’s work on mental models
of city structures, and computational knowledge patterns [
        <xref ref-type="bibr" rid="ref8 ref9">8, 9</xref>
        ]. Ontology design
patterns are conceptual macros that are repeatedly used by experts for solving
problems in their particular domains (cf. [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]). They are a means for
extracting knowledge from experts that can be used for designing applications with a
holistic understanding of a domain. Furthermore, machine-processible
representations of design patterns can be used for the generation of a system behavior
itself.
      </p>
      <p>
        AmI environments try to support natural behavior. Therefore ontology
design patterns must combine domain knowledge and enhancements using
information services grounded in sensor data and Web-based infospheres. In
general AmI environments are required to be context-oriented, user-centered, and
network-enabled [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. Context-orientation is achieved by adaptating to particular
situations, to objects within these situations, and to domain constraints such as
contractual restrictions. Furthermore, AmI environments adapt to users within
situations in a personalized and proactive manner. When an AmI environment
is network-enabled, any object can in principle establish relationships with any
other object or service within and beyond a particular situation. In summary,
ontology design patterns for AmI environments can be defined on various layers:
(1) users, (2) objects, (3) services, (4) physical space, (5) infosphere
(information space), and (6) social space [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. (4) through (6) establish networks among
entities from (1) through (3). A detailled discussion is beyond the scope of this
article.
      </p>
      <p>Here, we discuss a tentative design method for ontology design patterns
(POnA) and its application to the design of AmI environments with a focus on
Natural Language Processing (NLP). A review of existing methods has revealed
(cf. Section 2&amp;3) that a dedicated method suitable for ambient environments
is not yet available. Therefore we introduce a Pattern-based Ontology Building
Method for Ambient Environments (POnA) and exemplify this method through
the development of a pattern-based ontology for an AmI shopping environment.
Next, we will discuss existing ontology building approaches and their
applicability in AmI environments. In Section 3, we illustrate POnA through the
development of an exemplary ontology. We then discuss some findings (Section 4)
that exemplify patterns (Section 5). Finally, we conclude with a summary and
an outlook on future work.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Related Work</title>
      <p>
        In general, there are diverse approaches for the design and development of
ontologies [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]. Systematic methodologies concentrate on the ontology development
process and are independent of particular languages. Patterns are light-weight
versions of methodologies that include useful hints. Svatek argues that
repositories of such reusable patterns might improve the accuracy, transparency and
reasonability of an ontology [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]. In the following, systematic methodologies and
pattern-based approaches for ontology engineering are briefly described.
2.1
      </p>
      <sec id="sec-2-1">
        <title>Systematic Ontology Building Methods</title>
        <p>
          There are diverse ontology building methods for designing ontologies (for a
review of earlier methodologies cf. [
          <xref ref-type="bibr" rid="ref13">13</xref>
          ] NeOn 5.4.1.). For instance, Uschold and
King describe a methodology for building ontologies anew [
          <xref ref-type="bibr" rid="ref14">14</xref>
          ] while
METHONTOLOGY considers reuse of other ontologies [
          <xref ref-type="bibr" rid="ref15">15</xref>
          ]. The more recent NeOn
methodology focusses on the reuse and combination of distributed ontologies with a
special emphasis on ontology design patterns [
          <xref ref-type="bibr" rid="ref16">16</xref>
          ]. The Unified Process for Ontology
building (UPON) [
          <xref ref-type="bibr" rid="ref17">17</xref>
          ] applies a phase-structured software engineering viewpoint
by following the Unified Process model. All these methodologies follow a basic
pattern. First, a scope is defined by a domain of interest. Second, scenarios are
defined, which are used to identify competency questions (CQ) to be answered
by the ontology [
          <xref ref-type="bibr" rid="ref18">18</xref>
          ]. Thereafter, terms are gathered and translated into
formal concepts that are connected. The final result is called a formal ontology.
The NeOn methodology defines ontology design patterns as best practices for
more efficient ontology engineering processes. Additionally it describes generic
processes for ontology evaluation, evolution, and localization [
          <xref ref-type="bibr" rid="ref16">16</xref>
          ].
        </p>
        <p>
          Even though the NeOn methodology is rich with respect to complete
ontology life cycle, it lacks depth with regard to the application of design patterns. At
the moment, matching problems with ontology design patterns and reusing and
composing of ontology design patterns are complex tasks still left to the
knowledge engineer’s expertise [
          <xref ref-type="bibr" rid="ref16">16</xref>
          ]. In the following, we describe a methodology that
combines early phases of the NeOn methodology and the UPON methodology
for designing ontologies for AmI environments. Special emphasis is given to a
problem solving viewpoint often found in AmI scenarios.
2.2
        </p>
      </sec>
      <sec id="sec-2-2">
        <title>Building Pattern-based Ontologies</title>
        <p>
          Christopher Alexander introduced the term “design pattern” for shared
guidelines that help to solve architectural design problems [
          <xref ref-type="bibr" rid="ref19">19</xref>
          ]. He argued that a good
design can be achieved using rule sets, i.e. patterns. The potential for reusing
ontological structures through a pattern-based approach was first developed by
Clark et al. [
          <xref ref-type="bibr" rid="ref20">20</xref>
          ]. They emphasized the importance of combining concepts within
a vocabulary using “knowledge patterns”, i.e., frequently recurring, structurally
similar patterns of axioms. The notion of ontology design patterns was used by
Gangemi [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ] when presenting Conceptual Ontology Design Patterns (CODePs)
as a useful resource for engineering ontologies for Semantic web infrastructures.
CODePs are represented by textual, semiformal, and formal descriptions similar
to Alexander’s initial approach.
3
        </p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Pattern-based Ontology Building Method for Ambient</title>
    </sec>
    <sec id="sec-4">
      <title>Environments (POnA)</title>
      <p>Our goal is the development of an ontology design pattern library specific to
AmI environments that considers all six layers (cf. Section 1). These patterns
are grounded in the patterns of the Ontology Design Pattern ODP library.3 The
PoNA methodology reuses UPON’s detailed engineering approach and combines
it with an approach proposed by the NeOn methodology that is centered on
ontology design patterns. Currently, we focus on early development phases of
ontology engineering. Rigorous ontology evaluation and evolution phases will be
considered in our future work.</p>
      <p>
        Ontological design patterns have several advantages. They improve explicit
modularizations of knowledge bases and enable separation of abstract theories
from real-world phenomena [
        <xref ref-type="bibr" rid="ref20">20</xref>
        ]. Their usage ensures that better explications
concerning structure and modeling decisions are made when constructing a
formal axiom-rich ontology [
        <xref ref-type="bibr" rid="ref10 ref20">20, 10</xref>
        ]. Furthermore, ontology design patterns provide
new opportunities for ontology integration [
        <xref ref-type="bibr" rid="ref21">21</xref>
        ]. Contrary to systematic
methodologies, pattern-based approaches do not dispose of structured methodologies
that consist of specific activities and outcomes. Our hypothesis is that a
combination of systematic methodologies (cf. Section 2.1) and ontology design patterns
(cf. Section 2.2) constitute a more detailled and thus efficient approach to
designing ontologies for ambient environments.
      </p>
      <p>
        In the following, we present the Pattern-based Ontology Building Method
for Ambient Environments (POnA). Following UPON [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ], POnA consists of
four engineering phases: Requirements, Design, Implementation and Test. Each
phase is subdivided into activities, contains decision points, and provides clearly
defined outcomes. The re-use of design patterns is integrated into the design
phase. We will exemplify POnA for an AmI application in the cosmetics domain
[
        <xref ref-type="bibr" rid="ref22">22</xref>
        ].
      </p>
      <sec id="sec-4-1">
        <title>3 http://ontologydesignpatterns.org</title>
        <sec id="sec-4-1-1">
          <title>Requirements Phase</title>
          <p>
            The requirements phase aims at the identification of business needs for modeling
a domain of interest and specification of the environmental aspects of the
ontology, e.g., users and scenarios. This phase consists of the following activities: (1)
defining the domain of interest and scope, (2) identifying objectives, (3) defining
scenarios, (4) defining terminology and (5) identifying competency questions.
Defining Domain of Interest &amp; Scope According to [
            <xref ref-type="bibr" rid="ref14">14</xref>
            ] and [
            <xref ref-type="bibr" rid="ref17">17</xref>
            ], defining
a domain of interest is an important step in focusing on a particular fragment of
the world to be modeled. Therefore, prospective users and the type of ontology
to be used are circumscribed. In line with the scope of a particular ontology, the
most important concepts and their characteristics are identified. Consequently,
some parts of a domain of interest are brought into focus. Within our cosmetics
domain, we focus on ontological representations of the following product
concepts: perfume and fragrances, make-up for eyes, makeup for lips, hand care,
nail care, foot care, make-up for facial skin, liquid hair care, hair spray, hair
color, dental care, shower gel, skin care, and sunscreen. Target groups of
resulting ontologies are manufacturers, retailers and customers, which might use the
ontology for two different real-world situations:
– In-store purchase situation - The customer communicates with a
cosmetic product. She might search for an individual solution, e.g.”I have dry
skin. Which vanishing creme suits me?”
– Usage situation at home - A product advises a customer on correct
application procedure and initiates re-purchases through communication with
appropriate web-based shopping services.
          </p>
          <p>
            Identifying Objectives In this step, motivations for an ontology are collected
together with associated problems. This step is important for later reuse of
ontologies. It indicates to other knowledge engineers the importance of this
ontology and the problem types that are targeted. We found that physical products
are mainly described in a non-semantic way; their descriptions exist in terms of
static databases or XML structures (e.g., BMEcat R , ETIM/eCl@ss and GS1).
Modeling of enterprises or processes is generally sophisticated, but the
description of products rarely exceeds the scope of classification. We intend to integrate
physical products into communicative situations in ambient shopping
environments. Therefore, semantically annotated product information is required to
realize personalized communications between different stakeholders and products.
Defining Situations Situations are textual descriptions of integrated
performances of a particular interaction type. Situations conceive different entities
(objects, subjects, information, and services) and their interactions (for a
discussion cf. [
            <xref ref-type="bibr" rid="ref11">11</xref>
            ]). Situations are prototypes that reflect characteristic features of
a corresponding class of situations, e.g., shopping situations. Thus, situations
resemble frames [
            <xref ref-type="bibr" rid="ref8">8</xref>
            ], schemas [
            <xref ref-type="bibr" rid="ref9">9</xref>
            ], and use cases. For instance:
”Anna has dry skin and searches for a vanishing creme matching her skin in a shop. She wants to take a look
at the cremes that are right for her, so she asks all products in the store for a solution to her specific skin
problem. Six vanishing cremes give notice that they want to solve her problem because they are suitable for
dry skin. Anna goes to the creme closest to her and initiates a dialogue with the intelligent product. She
asks whether the creme is a gel-based moisturizer. Furthermore, she wants to know about the ingredients.
Then, Anna asks for the price as well as current discount campaigns and matching products. The creme
informs Anna about a bundle price with a 5% discount for the vanishing creme and the corresponding eye
care. Anna decides to buy both products.”
Defining Terminology The terminology was extracted from situation reports
gathered in workshops with experts and was automatically extracted based on
Web-based product descriptions. For the cosmetics domain, 130 terms were
extracted and categorized into five term categories (for an excerpt see Table 1):
Actors and Roles, Products and Features, Environment and Situation, Problems
and Solutions.
          </p>
          <p>Actors
Roles
and</p>
          <p>
            Products
and Features
Identifying Competency Questions Competency questions (CQs) are
conceptual questions that the ontology must be able to answer [
            <xref ref-type="bibr" rid="ref23">23</xref>
            ]. They were
CQ1
CQ2
CQ3
CQ4
CQ5
CQ6
          </p>
          <p>Does the product fit to me?
Does the product solve my problem?
How long does the product last?
Is my purchase decision correct?
Which product can I use for protecting my lips (in winter)?</p>
          <p>
            How can I apply the product?
identified through analysis of scenarios and terminology as well as through
brainstorming with domain experts. CQs were used during the test phase of POnA
to evaluate the quality of resulting ontologies [
            <xref ref-type="bibr" rid="ref17">17</xref>
            ]. Some examples of CQs are
presented in Table 2. The output of the requirements phase consists of CQs,
scenarios, and the terminology with corresponding term categories.
3.2
          </p>
        </sec>
        <sec id="sec-4-1-2">
          <title>Design Phase</title>
          <p>
            The design phase aims at the identification of semantic structures, more
precisely the definition of design patterns for answering CQs. First, relations
between terms are identified, which results in coarse term structures. Based on
descriptions of situation types, CQs and term structures, prototypical ontology
design patterns (PODPs) are derived and formally modeled by reusing ODPs
grounded in DOLCE [
            <xref ref-type="bibr" rid="ref10">10</xref>
            ]. Complex prototypical ontology patterns require the
combination and adaptation of ODPs. Resulting ontology design patterns are
discussed with domain experts again. PODPs are informal conceptual
structures that are derived from analysis of situations, terms, and CQs. Therefore,
PODPs resemble more mental models of real world perceptions [
            <xref ref-type="bibr" rid="ref24">24</xref>
            ] than formal
logic representations and fit very well to the requirements of AmI environments.
PODPs consist of conceptual entities, called scopes, and relations. Scopes are
themes that frequently occur in situations, terms and CQs and share a common
meaning. The design phase consists of the following activities: (1) identification
of prototypical ontology design patterns, (2) terminology setup, and (3) mapping
PODPs onto ODPs.
          </p>
        </sec>
        <sec id="sec-4-1-3">
          <title>Identification of Prototypical Ontology Design Patterns In contrast to</title>
          <p>
            UPON [
            <xref ref-type="bibr" rid="ref17">17</xref>
            ], CQs are mapped onto PODPs that in turn are mapped onto formal
ODPs [
            <xref ref-type="bibr" rid="ref10 ref19 ref20">19, 20, 10</xref>
            ]. PODPs and ODPs provide levels of granularity that
support discussions with experts much better than discussions of isolated concepts
and relationships. Generally, it is proposed that an accurate domain ontology
specifies all and only those conceptualizations that are required for answering
all the CQs formulated within the requirements phase [
            <xref ref-type="bibr" rid="ref10">10</xref>
            ]. The most general
CQ for product-centered situations is classified as a problem-solution
situation, i.e., “Which solutions exist for this problem?” Through analysis of the 55
CQs, seven POSPs are derived: Product-Pattern (P), Product-Product-Pattern
(PP), Context-Pattern (C), Product-User-Pattern (PU),
Product-InformationPattern (PI), Product-User-Context-Pattern (PUC), and
Product-Context-UserInformation-Pattern (PUIC ). Prototypical design patterns conceive a general
conceptualization of a set of situations, dominant terms, and corresponding CQs.
Furthermore, they highlight candidates for key concepts, called scopes. PODPs
have a conceptual or rather architectural nature [
            <xref ref-type="bibr" rid="ref25">25</xref>
            ] and arrange the answering
of the CQs by scopes according to the categories of the terminology (Actors
and Roles, Products and Features, Environment and Situation, Problems and
Solutions) (cf. Fig. 1).
          </p>
          <p>The P-Pattern represents solutions to problems concerning the product
itself, e.g., its price, whereas the PP-Pattern covers semantics on product bundles
and their features. The C-Pattern semantically describes the current context,
e.g., time and space of a situation, present objects, and individuals. The
PUPattern describes information that relates products with user attributes. The
PUC-Pattern enhances the PU-Pattern with contextual information. Solutions
for problems concerning additional information about the product, e.g., user
reviews, images, videos, etc. are represented by the PI-Pattern. The most
complex pattern, the PUIC-Pattern, represents solutions to problems concerning the
matching of information about products to user-specific attributes and needs
within a context. All PODPs combine scopes that were extracted from the
terminology. The product scope covers the term category Product and Features
whereas the user scope represents the term category Actors and Roles. The
context scopes contain terms subsumed by the category Environment and Situation.
The lollipop relationship between pattern P and pattern C indicate that they
conceptually contribute to what is a problem solving situation (cf. Figure 2).
More complex PODPs are derived from simpler ones, e.g., pattern PI is an
extension of pattern P. Patterns can be composed, which creates new patterns,
e.g., the PUIC pattern. By discussion of PODPs, the requirement for an
independent information scope appeared that supports CQs such as “How can I
apply this product?” The information scope refers to information about a
product, e.g. product images, application videos, and user-generated or professional
product reviews.</p>
          <p>
            PODPs dispose a template-based and compact visualization [
            <xref ref-type="bibr" rid="ref10">10</xref>
            ], which
consists of the following slots:
(a) Graphical visualization of the pattern [
            <xref ref-type="bibr" rid="ref10 ref19">19, 10</xref>
            ]
(b) Name of the pattern [
            <xref ref-type="bibr" rid="ref10 ref19">19, 10</xref>
            ]
(c) Description of the intention of the pattern [
            <xref ref-type="bibr" rid="ref19 ref26">19, 26</xref>
            ]
(d) CQs that are addressed by the pattern [
            <xref ref-type="bibr" rid="ref26">26</xref>
            ]
(e) Terms that characterize the pattern
(f) Situations that exemplify a pattern [
            <xref ref-type="bibr" rid="ref26">26</xref>
            ]
(g) Consequences, side effects, references to other patterns [
            <xref ref-type="bibr" rid="ref10 ref19 ref26">19, 10, 26</xref>
            ]
(h) Components of the pattern, e.g., product scope and information scope [
            <xref ref-type="bibr" rid="ref19 ref26">19,
26</xref>
            ]
Slot (e) represents the linkage of the different patterns. For example, the
PPPattern evolves from the P-Pattern when more than one product is part of a
communicative situation within an ambient environment. On the other hand, the
PU-Pattern has a strong reference to the P-Pattern representing one product as
well as the PP-Pattern focusing on solutions to problems concerning product
bundles (cf. Fig. 2).
          </p>
          <p>
            Terminology Set-up Next, scopes within patterns are refined and structured
by arranging relevant terms (cf. Section 3.1) and further analyzing the CQs. For
concept identification, a middle-out approach is used that starts with salient
concepts and proceeds with generalization and specialization [
            <xref ref-type="bibr" rid="ref27">27</xref>
            ]. This seems
to be the most effective approach because concepts “in the middle” are more
informative about the domain. Table 3 shows the four scopes and an extract of
their corresponding terms. The product scope covers all necessary information
Product Scope
          </p>
          <p>User Scope</p>
          <p>
            Context Scope
that is part of the product itself, e.g., information about price and material. In
contrast, external product information, such as manuals or brochures, is covered
by the information scope. The user scope covers terms and questions related to a
user whereas the context scope conceives characterizations of a general context.
Mapping PODPs onto ODPs Operations that support the reuse of formal
ODPs try to find patterns that optimally cover CQs [
            <xref ref-type="bibr" rid="ref16">16</xref>
            ]. In PoNA, PODPs are
mapped onto ODPs. Within the cosmetics domain, ODPs proposed by [
            <xref ref-type="bibr" rid="ref26">26</xref>
            ] fit
well with requirements given by PODPs (cf. Fig. 2). Typically several ODPs are
required, which leads to pattern composition. For instance, the ODP mapping of
the PI-pattern uses the ODP mapping of the P-pattern based on the Description
and Situation ODP in conjunction with the information-object ODP [
            <xref ref-type="bibr" rid="ref10">10</xref>
            ].
Currently, mapping tasks are executed manually. Our goal is to reduce the
complexity of ODP mapping tasks by automatically mapping situations, terminologies,
and CQs onto PODPs. With a library of predefined PODP-ODP mappings, we
will test ways in which the reuse of formal ontologies can be improved.
The ODP-based P-pattern and PP-pattern represented in OWL-DL has been
integrated into the Smart Product Description Object (SPDO) model that is
used in AmI environments [
            <xref ref-type="bibr" rid="ref22 ref7">7, 22</xref>
            ]. Instances of SPDO models are used as
productcentered knowledge bases for Natural Language Processing modules [
            <xref ref-type="bibr" rid="ref28">28</xref>
            ] and
product reasoning [
            <xref ref-type="bibr" rid="ref7">7</xref>
            ]. Currently, we are working on the integration of the other
patterns within the EU-project Interactive Knowledge Stack (IKS). The resulting
SPDO ontology covers all information concerning the product itself. It consists of
25 classes, 86 properties, and 104 restrictions. SPDO answers all the CQs of the
P-Pattern and the PP-Pattern. The linkage of two or more product scopes within
the PP-Pattern is realized via reasoning based on standardized Web-based rules
(SWRL4). Statements about alternative or matching products are generated by
processing certain concepts of SPDO instantiations while each SPDO describes
one particular product.
          </p>
        </sec>
      </sec>
      <sec id="sec-4-2">
        <title>4 http://www.w3.org/Submission/SWRL/</title>
        <sec id="sec-4-2-1">
          <title>Test Phase</title>
          <p>
            The quality of the resulting ontology is tested with respect to four
characteristics: syntactic, semantic, pragmatic, and social quality [
            <xref ref-type="bibr" rid="ref17">17</xref>
            ]. First, the semantic
quality is evaluated by checking the consistency of the ontology using the Pellet
reasoner. Validation of pragmatic quality consists of verifying the coverage of an
ontology over a domain and answering CQs. For the cosmetic domain, initial
semantic checking of the SPDO showed promising results. Testing the pragmatic
quality by answering CQs associated with the P-pattern and PP-pattern was
straightforward because users can use the NLP component of SPDO instances
for direct communications. Nonetheless, more detailed user studies are required.
The syntactic quality is verified within the implementation workflow whereas
the social quality can be checked only after application of an ontology in real
environments, which is part of the EU-project IKS.
4
          </p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Discussion of POnA</title>
      <p>When defining the terminology, we found a huge amount of terms with
completely different origins, e.g., user or content-specific terms. We therefore decided
to structure terms concerning their particular content categories. This additional
step was very helpful for creating prototypical ontology design patterns based on
scopes. Furthermore, we were able to clearly separate product-centered
knowledge from other ontological parts, which is important for AmI environments.
Thus, each product could be labled by dedicated semantic product information.
Through modularization by scopes and PODPs, we were able to set up a clearly
defined ontology engineering process that fits very well with the requirements
of AmI environments. To ensure a better portability to other domains and a
general representation of the structure of ambient environments, we decided on
general scopes within patterns. Domain specifications can be realized by
conceptualizations of scopes and PODPs. Additionally, we found that not all scopes can
be directly derived from analysis of situations, CQs, and terminologies. At the
moment, scope completion requires careful discussions with domain experts. In
general, we found that joint consideration of situations, CQs and terminologies
is an efficient approach for identifying requirements for ontologies because they
help to “pursue the path”.
5</p>
    </sec>
    <sec id="sec-6">
      <title>Example</title>
      <p>Within this section, the Product-User-Context-Pattern is exemplified in detail.
This PODP was chosen because product, user and context scopes are quite
advanced. Table 4 shows the representation of the pattern in the form of a
PODP.</p>
      <p>The PUC-Pattern represents solutions to problems concerning the
matching of products to user-specific attributes and needs within a context, such as
whether a vanishing creme should be matched with a specific skin type in a
Graphical
visualization
Name
Description of
Intention
Competency
Questions
Characterizing
terms
Situations
Consequences
/ Side Effects
/ References
Components
cf. Fig. 1
Product-User-Pattern (PU)
Representation of solutions for problems concerning the matching of
products to user-specific attributes and needs
Extract:
(a) Does the product /the application of the product solve my problem?
(b) Does the product fit to me?
(c) Which product can I use for protecting my lips?
(d) Will I be happy applying the product?
product: price, ingredients, user: emotions, context: temperature, day of
week
Anna is interested in a vanishing creme and wants to know whether it is
right for her skin in humid environments.</p>
      <p>PP-Pattern; PUC-Pattern
product scope; user scope: context scope
humid environment. Furthermore, the PUC-Pattern disposes of cross references
to other patterns. For instance, when product bundles (more than one product)
have to be matched with user-specific aspects, the PUC-Pattern is extended by
the PP-pattern. A mapping of the PUC-PODP onto ODPs is illustrated in Fig.
4.
6</p>
    </sec>
    <sec id="sec-7">
      <title>Conclusion and Future Work</title>
      <p>
        Ambient Intelligence implies modularized environments of computing and
specific interfaces. The characteristic of such an environment requires systems to
deal with large amounts of unstructured information from heterogeneous sources
and to support dynamic knowledge sharing and reasoning. These issues imply the
application of appropriate knowledge representations. We start from the outset
that ontologies are an efficient means for building ambient environments because
they enable efficient sharing, adding and changing of information, and inference
generation [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. By leveraging capabilities of different ontology design
methodologies, we investigated Pattern-based Ontology Building Method for Ambient
Environments (POnA) as a method with particular focus on ambient
environments. We found that a combination of systematic methodologies and different
types of design patterns can be an efficient approach to designing ontologies
for ambient environments. The POnA process focuses on the main ontology
development processes and enables an explicit pattern-based modularization and
abstraction of scopes. In our future work, we will proceed with several tasks: (1)
      </p>
      <p>Fig. 4. ODP-based PUC-pattern
evaluation of PODPs and their formalizations based on ODPs, (2) extension of
PODPs to more AmI-specific dimensions, i.e., representation of spatio-temporal
information, frames of reference, and sensoric perceptions, and (3) automatic
mapping of CQs, situations, and terms onto PODPs.
7</p>
    </sec>
    <sec id="sec-8">
      <title>Acknowledgements</title>
      <p>We would like to thank Andreas Filler and Tobias Kowatsch for their help on
this paper. This work is part of the project SmaProN that is being funded by
the Federal Ministry of Education and Research (BMBF), Germany, under the
number FKZ 17 53X 07.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Dey</surname>
            ,
            <given-names>A.K.</given-names>
          </string-name>
          :
          <article-title>Providing architectural support for building context-aware applications</article-title>
          .
          <source>PhD thesis</source>
          , Georgia Tech College of Computing, Atlanta,
          <string-name>
            <surname>GA</surname>
          </string-name>
          , USA (
          <year>2000</year>
          )
          <article-title>Director-</article-title>
          <string-name>
            <surname>Abowd</surname>
          </string-name>
          , Gregory D.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Coen</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Phillips</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Warshawsky</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Weisman</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Peters</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Finin</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>Meeting the computational needs of intelligent environments: The metaglue system</article-title>
          .
          <source>In: Proceedings of MANSE99</source>
          , Springer-Verlag (
          <year>1999</year>
          )
          <fpage>201</fpage>
          -
          <lpage>212</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Schilit</surname>
            ,
            <given-names>W.N.:</given-names>
          </string-name>
          <article-title>A system architecture for context-aware mobile computing (</article-title>
          <year>1995</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Want</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hopper</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Falcao</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gibbons</surname>
            ,
            <given-names>J.:</given-names>
          </string-name>
          <article-title>The active badge location system</article-title>
          .
          <source>ACM Trans. Inf. Syst</source>
          .
          <volume>10</volume>
          (
          <issue>1</issue>
          ) (
          <year>1992</year>
          )
          <fpage>91</fpage>
          -
          <lpage>102</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Peters</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shrobe</surname>
            ,
            <given-names>H.E.</given-names>
          </string-name>
          :
          <article-title>Using semantic networks for knowledge representation in an intelligent environment</article-title>
          .
          <source>In: PERCOM '03: Proceedings of the First IEEE International Conference on Pervasive Computing and Communications</source>
          , Washington, DC, USA, IEEE Computer Society (
          <year>2003</year>
          )
          <fpage>323</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Chen</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Finin</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Joshi</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>The SOUPA ontology for pervasive computing</article-title>
          . In Tamma, V.,
          <string-name>
            <surname>Cranefield</surname>
          </string-name>
          , S., eds.:
          <source>Ontologies for Agents: Theory and Experiences</source>
          . Springer (
          <year>2005</year>
          )
          <fpage>233</fpage>
          -
          <lpage>258</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Maass</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Filler</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Towards an infrastructure for semantically annotated physical products</article-title>
          . In Hochberger,
          <string-name>
            <given-names>C.</given-names>
            ,
            <surname>Liskowsky</surname>
          </string-name>
          , R., eds.:
          <article-title>Informatik 2006</article-title>
          . Volume P-
          <volume>94</volume>
          of Lecture Notes in Informatics., Berlin, Springer (
          <year>2006</year>
          )
          <fpage>544</fpage>
          -
          <lpage>549</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Minsky</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>A framework for representing knowledge</article-title>
          . In Winston, P.H., ed.:
          <article-title>The Psychology of Computer Vision</article-title>
          .
          <string-name>
            <surname>McGraw-Hill</surname>
          </string-name>
          , New York (
          <year>1975</year>
          )
          <article-title>incollection</article-title>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Schank</surname>
            ,
            <given-names>R.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Abelson</surname>
            ,
            <given-names>R.P.</given-names>
          </string-name>
          : Scripts, Plans, Goals and Understanding. Erlbaum, Hillsdale, NJ (
          <year>1977</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Gangemi</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Ontology design patterns for semantic web content</article-title>
          . In: M.
          <string-name>
            <surname>Musen</surname>
          </string-name>
          et al. (eds.):
          <source>Proceedings of the Fourth International Semantic Web Conference</source>
          , Berlin, Springer (
          <year>2005</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Maass</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Varshney</surname>
            ,
            <given-names>U.</given-names>
          </string-name>
          :
          <article-title>A framework for smart healthcare situations and smart drugs</article-title>
          .
          <source>In: SIG-Health Pre-AMCIS Workshop at the 15th Americas Conference on Information Systems (AMCIS</source>
          <year>2009</year>
          ), San Francisco, USA (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12. Sv´atek, V.:
          <article-title>Design patterns for semantic web ontologies: Motivation and discussion</article-title>
          .
          <source>In: Proceedings of the 7th Conference on Business Information Systems</source>
          , Poznan (
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Corcho</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fern´</surname>
            andez-L´opez, M.,
            <given-names>G´</given-names>
          </string-name>
          <article-title>omez-P´erez, A.: Methodologies, tools and languages for building ontologies: where is their meeting point? Data Knowl</article-title>
          .
          <source>Eng</source>
          .
          <volume>46</volume>
          (
          <issue>1</issue>
          ) (
          <year>2003</year>
          )
          <fpage>41</fpage>
          -
          <lpage>64</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Uschold</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>King</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Towards a methodology for building ontologies</article-title>
          .
          <source>In: In Workshop on Basic Ontological Issues in Knowledge Sharing, held in conjunction with IJCAI-95</source>
          . (
          <year>1995</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15. Fern´andez-L´opez, M.,
          <string-name>
            <surname>G´</surname>
          </string-name>
          <article-title>omez-P´erez,</article-title>
          <string-name>
            <given-names>A.</given-names>
            ,
            <surname>Juristo</surname>
          </string-name>
          , N.:
          <article-title>METHONTOLOGY: from ontological art towards ontological engineering</article-title>
          .
          <source>In: Proceedings of the AAAI97 Spring Symposium Series on Ontological Engineering</source>
          , Stanford, USA (March
          <year>1997</year>
          )
          <fpage>33</fpage>
          -
          <lpage>40</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Su</surname>
          </string-name>
          <article-title>´arez-</article-title>
          <string-name>
            <surname>Figueroa</surname>
            ,
            <given-names>M.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Blomqvist</surname>
            , E.,
            <given-names>D</given-names>
          </string-name>
          ´Aquin,
          <string-name>
            <given-names>M.</given-names>
            ,
            <surname>Espinoza</surname>
          </string-name>
          ,
          <string-name>
            <surname>M.</surname>
          </string-name>
          , et al.,
          <string-name>
            <surname>A.G.P.</surname>
          </string-name>
          :
          <source>D5</source>
          .
          <article-title>4.2. revision and extension of the neon methodology for building contextualized ontology networks</article-title>
          .
          <source>Technical report, NeOn: Lifecycle Support for Networked Ontologies</source>
          (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>De Nicola</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Missikoff</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Navigli</surname>
            ,
            <given-names>R.:</given-names>
          </string-name>
          <article-title>A software engineering approach to ontology building</article-title>
          .
          <source>Inf. Syst</source>
          .
          <volume>34</volume>
          (
          <issue>2</issue>
          ) (
          <year>2009</year>
          )
          <fpage>258</fpage>
          -
          <lpage>275</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Grueninger</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fox</surname>
            ,
            <given-names>M.S.</given-names>
          </string-name>
          :
          <article-title>Methodology for the design and evaluation of ontologies</article-title>
          .
          <source>In: Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing held in conjunction with IJCAI-95</source>
          . (
          <year>1995</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          19.
          <string-name>
            <surname>Alexander</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>The timeless way of building</article-title>
          . Oxford University Press, New York (
          <year>1979</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          20.
          <string-name>
            <surname>Clark</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Thompson</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Porter</surname>
            ,
            <given-names>B.W.</given-names>
          </string-name>
          :
          <article-title>Knowledge patterns</article-title>
          . In Staab, S.,
          <string-name>
            <surname>Studer</surname>
          </string-name>
          , R., eds.: Handbook on Ontologies.
          <source>International Handbooks on Information Systems</source>
          . Springer (
          <year>2004</year>
          )
          <fpage>191</fpage>
          -
          <lpage>208</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          21.
          <string-name>
            <surname>Gangemi</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Guarino</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Masolo</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Oltramari</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Oltramari</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schneider</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>Sweetening ontologies with DOLCE</article-title>
          .
          <source>In: Proceedings of the 13th International Conference on Knowledge Engineering and Knowledge Management. Ontologies and the Semantic Web</source>
          , Springer (
          <year>2002</year>
          )
          <fpage>166</fpage>
          -
          <lpage>181</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          22.
          <string-name>
            <surname>Janzen</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Maass</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          :
          <article-title>Smart product description object (SPDO)</article-title>
          .
          <source>In: Poster Proceedings of the 5th International Conference on Formal Ontology in Information Systems (FOIS2008)</source>
          . IOS Press, Saarbru¨cken,
          <string-name>
            <surname>Germany</surname>
          </string-name>
          (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          23.
          <string-name>
            <surname>Grueninger</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fox</surname>
            ,
            <given-names>M.S.:</given-names>
          </string-name>
          <article-title>The role of competency questions in enterprise engineering</article-title>
          .
          <source>In: Proceedings of the IFIP WG5.7 Workshop on Benchmarking - Theory and Practice</source>
          . (
          <year>1994</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          24.
          <string-name>
            <surname>Johnson-Laird</surname>
            ,
            <given-names>P.N.</given-names>
          </string-name>
          :
          <article-title>Mental Models: Towards a Cognitive Science of Language, Inference, and Consciousness</article-title>
          . Cambridge University Press (
          <year>1983</year>
          )
          <article-title>book</article-title>
          .
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          25.
          <string-name>
            <surname>Gangemi</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Presutti</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>Ontology design patterns</article-title>
          . http://ontologydesignpatterns.org (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          26.
          <string-name>
            <surname>Presutti</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gangemi</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Content ontology design patterns as practical building blocks for web ontologies</article-title>
          .
          <source>In: ER '08: Proceedings of the 27th International Conference on Conceptual Modeling</source>
          , Berlin, Heidelberg, Springer-Verlag (
          <year>2008</year>
          )
          <fpage>128</fpage>
          -
          <lpage>141</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          27.
          <string-name>
            <surname>Uschold</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gruninger</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Ontologies: Principles, methods and applications</article-title>
          .
          <source>Knowledge Engineering Review</source>
          <volume>11</volume>
          (
          <year>1996</year>
          )
          <fpage>93</fpage>
          -
          <lpage>136</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          28.
          <string-name>
            <surname>Maass</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Janzen</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Dynamic product interfaces: A key element for ambient shopping environments</article-title>
          .
          <source>In: Proc. of 20th Bled eConference, Bled</source>
          , Slovenia (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>