The Design Principles and Practices of Interoperable Smart Spaces - Advanced Design Approaches to Emerging Software Systems - page 39

less manageable while the ontology size and the
application logic complexity increased.
With the triple-blind implementation, KPs
access the SS through methods offered by the
ontology dependent convenience libraries gen-
erated off-line by an ontology processing tool.
Convenience libraries map ontology classes into
language classes, hiding the RDF graph from
the programmer. Built on top of the KPIs, a
convenience library is required for each program-
ming language. The “triple-blind” development
approach is expected to become the preferred
approach of KP programmers. However, this
approach requires the availability of SSA devel-
opment tools.
The model based approach supports the devel-
opment of entire SSAs, each consisting of a set of
KPs. This approach is suitable for end-users and
those developers that do not have a deep knowl-
edge of ontology manipulation. The model based
KP development relies on a graphical tool called
SmartModeller (Katasonov & Palviainen 2010),
which allows modeling of the KP logic by using
existing reusable building blocks stored in a KP
repository. Actions, which are not available, need
to be coded manually, and once tested, they can
be stored in the repository for further reuse. The
tool follows the metamodel that is consistent with
the IOP principles and exploits its own software
ontology for producing the logic part of the source
code for KPs. Currently, a code generator has
been implemented for Java and Python, but other
languages may be supported in the future. Gener-
ated KPs can also be tested by the SmartModeller.
In all of the KP development methods, the
repository of reusable KPs is considered to be
the main instrument to meet the IOP productiv-
ity principle. In order to properly manage such a
repository, the following incremental steps should
be taken: i) the definition of a KP taxonomy, ii)
the definition of a KP ontology, used not only at
development time but also at run time, and iii)
turning KPs into services, with the aim of making
these services discoverable at run time, by match-

ing the user context to the service ontology. In this
chapter, only the first step, i.e. the definition of a
KP taxonomy, is considered.

KP Taxonomy

The purpose of the KP taxonomy is to facilitate
a smooth growth of SSAs and to maximize KP
reuse by assisting the developer in searching for
an applicable KP from the KP repository and stor-
ing new ones therein. Different classifications of
KPs are possible, based on the adopted criteria. In
the following, we will present two classifications,
based on (i) the reusability level of KPs and (ii)
the role of KPs in the smart space.
With respect to their reusability level, the KPs
are classified into the following four classes:

1. Application specific or Domain specific
KPs that represent a specific domain (e.g.
personal space) or application area (e.g.,
health monitoring applications).
2. Adaptable KPs that can be adapted to in-
stantiate new domain specific KPs.
3. Common KPs that can be used as such or con-
figured by parameters for multiple domains.
The parameters could be set at design time
or at run time. Common KPs may become
integration elements between domains, used
in cross-domain applications.
4. Core KPs that impact the IOP architecture
at the service level, extending the initial
version of the IOP.

A KP usually originates as an application-
specific KP, later promoted through the entire
KP category-chain, through a generalization
process. At the time of writing, although several
KPs were still in their early stage of development,
they were expected to become building blocks
of IOP extensions, introduced as “Common” or
“Core” KPs. This is the case, for example, for all
the KPs that support context-awareness, dispatch
transport independent messages and manage