Information Technology Reference
In-Depth Information
for its high level of abstraction and conciseness,
as well as the deepness of its ontological analysis,
which has been carried out by experts in the field.
For the core ontology, some parts of two domain
ontologies, SPICE Mobile Ontology (SPICE
2010) and CONON Ontology (Gu et al. 2004)
were selected. The selected parts are i) the core
concepts of SPICE and ii) the concepts and proper-
ties related to the quality of data from CONON.
Concurrently with the IOP principles, the
domain ontologies were specified, starting from
scenario analysis results and the information
produced and consumed by the actors involved in
the intended scenario. This information is crucial
for the understanding of the requirements of the
core and domain ontologies, although the previous
developed ontologies helped in making selections
and formulating the main concepts and properties
of these ontologies.
The application development tools, expected
to seamlessly integrate the ontology within the
applications, were also developed concurrently
with the core ontology. Moreover, several small
domain ontologies, e.g. a common ontology for
sensors were defined and applied in practice, in
spite of the need to be mapped to the sensor con-
cepts of the core ontology. This example depicts
the ontology evolution in practice: while the core
ontology evolves slowly, new ontologies emerge
all the time, so that the evolution of ontologies
needs to be tolerated and handled in one way or
another. One way is that device manufacturers
provide a mapping that maps the ontology that they
have used to the SS core ontology. This mapping is
taken into account during the application develop-
ment process, as illustrated in Figure 2. Another
way is that all of the application developers do
the mapping by themselves, or there is a service
in IOP that makes the mapping at run-time. The
last option requires an IOP maintainer, who has
special skills in ontology mapping algorithms and
their automatic execution. Naturally, the SS owner
is responsible for ontology evolution policies,
while the evolution enforcing is the responsibility
of the SS manager.
SMART SPACE APPLICATION
DEVELOPMENT
Supporting Context-Awareness
One driving force of smart spaces is their ability to
enable applications that adapt to the dynamically
changing situation of the smart environment. As
defined in section 2, a context defines the limit
of information understanding in a smart space.
Thus, the context is relevant for the agents (i.e.
KPs), applications and users. As KPs interact with
the SIB, they manage interoperable information.
The specific agent is exploited to provide context-
aware adaptation based on QoS requirements. For
instance, if a SSA finds out that a required quality
level is not met, it inserts data about the current
quality level into the SIB, which notifies the agent
responsible for quality-driven adaptation. At a
higher level of abstraction, it is possible to define
the user context by deriving it from the context
of agents which are interacting with that user in
ongoing application sessions. In this case, the
term “information usage” should be interpreted at
the granularity and abstraction level suitable for
SS end users, e.g., user profiles and preferences.
Context awareness enables filtering mechanisms
that enable scoping out of the “visibility” range
for those SS data that are not considered to be of
interest. We call such a visibility range the KP/
user scope. The scope can be defined to be the
output of the filtering process performed over the
SS. For example, if a KPI can understand ontology
A, but not ontologies B and C, its scope within
the smart space will not include the SIBs (or the
parts of them) whose data is expressed according
to B and C. Therefore, KPs may have different
visibility on the SS due to their current context.
The scope of an SSA derives from merging the
Search WWH ::
Custom Search