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

scopes of its composing KPs, and might possibly
coincide with the user scope.
According to the IOP principle on “Context”,
context is provided by an IOP extension consisting
of a set of cooperating KPs, which collectively
provide the appropriate functionalities. The IOP
itself already supports context storage, retrieval,
and distribution; context is available to any SSA
by querying information from SIBs. Therefore,
the context extension provides the following func-
tionalities: i) context specification, acquisition and
monitoring, including data collection from context
sources and ii) context pre-processing, aggrega-
tion, and/or reasoning, including context-based
filtering. Based on this IOP extension, applications
are able to make context-aware adaptations. For
instance, context pre-processing KPs access SIBs
to collect raw data and produce new information,
such as context history and higher level context, to
be inserted again in the SIBs. Similarly, context-
aware filtering KPs act as intermediate entities
between semantic repositories and application-
specific KPs by dynamically determining the
scope of an SSA. Moreover, the run-time quality
management provides dedicated KPs that are in
charge of specific quality attributes (e.g. security,
reliability, and energy efficiency). They are capa-
ble of a context-dependent monitoring, reasoning
and adaptation of SSAs, based on the measured
quality and available resources/services in the SS.
The implementation of context-aware features
via dedicated KPs has a number of advantages:

in the development of early demonstrators
that encourage SS developers using the
IOP and promotes its widespread exploi-
tation, e.g., via low-cost and simple SS
applications.

KP Development

When a KP is developed, the following rules should
be kept in mind: KPs should i) not compromise
the ontology consistency, ii) not violate any of
the IOP principles, iii) address a single goal (a
separation of concerns) and iv) be designed to be
as reusable as possible. KP development is also
strongly influenced by the adoption of RDF as a
resource description solution. Developing KPs at
the RDF graph level is similar to programming in
the assembly language: it requires highly specific
skills and the productivity is low due to the level
of details that needs to be considered at the pro-
gramming time. Therefore, KP developers need
a more effective development approach that rises
the level of abstraction, hides the graph level or/
and the code level, and also enables KP develop-
ment by non-programmers. Therefore, we offer
three ways to develop KPs: i) “ triple-based KP
implementation ”, ii) “ triple-blind KP implementa-
tion ” and iii) “ model based implementation ”. The
main difference between these three approaches
is the visibility level of the knowledge base and
the KP code.
With triple-based implementation, KPs access
the SS through language dependent APIs called
KPIs (Knowledge Processor Interfaces) which
hide the protocol to access the smart space (i.e.
the SSAP) and support basic graph manipula-
tion functions, including insert, remove, update,
graph traversal queries and subscribes; a single
query may be matched to a sequence of steps in
the graph. KPI libraries exist for Java, ANSI-C,
C# and Python. The “triple-based” approach was
adopted in the development of the early proof-of-
concept applications. Since the direct manipulation
of RDF triples is required, this approach became

• It keeps SIB very lightweight, can be

implemented in a cost effective way and
is also usable for context-independent
applications.

• A simple and context-agnostic SIB clearly

separates the application logic from the fa-
cilities, thus increasing the interoperability
and reusability.

• Simple applications can be easily proto-

typed by working on a very simple refer-
ence model. This provides a real advantage