General Ontology Structure for I-centric communications systems

simple example how to map between ontologies of two different light objects. In this case, the parameters are just a short list of numbers or strings. Corresponding ‘allowed parameter values’

are assigned to each other.

The mapping function enables I-centric Services designed for activating objects of type ‘Light 1’ to activate objects of type ‘Light 2’ too, and vice versa. In general, a mapping function has to provide possibilities such as:

- mapping between different numbers of parameters,

- exchange of parameters or data types, and

- arithmetic translation of parameters.

Another problem, which can be solved by mapping ontology, is caused by evolutionary charac-teristic of software-based systems. An object once developed may be altered to improve its functionality. Typically, that means the interface of that object is altered and cannot be used at all without modifying all clients too. Using ontology mapping in such a case can ease the usage of a modified object by mapping the ‘old’ operation to the ‘new’ one without modifying ‘old’

clients.

The functions introduced above have to be reflected by the ontology used in I-centric communi-cations systems. The next section introduces the proposed structure of the ontology.

name, an input parameter(s), and an output parameter(s). That reflects the needed informa-tion to describe procedural interfaces as any object oriented programming language does. The input parameter and output parameter can be described as Interface Definition Languages do by specifying the data structures they contain.

In addition, all allowed values that these data structure can contain have to be specified. That can be done using a constraint language like [W-OCL] or a mechanism to specify data type restrictions as introduced in the XML Schema specification [XSD]. The restrictions or con-straints have to be incorporated with the definition of the data structures.

An example using pseudo syntax is given below to illustrate USAGE.

USAGE of TVset Operations

Operationname = ‘switch’

InParameter (string) value restricted to ‘ON|OFF’

OutParameter = non Link = ‘Radio’

A client receiving a USAGE part as given above has to interpret the given information. Based on the evaluation, the client is able to construct commands to be sent to the object compliant to the given ontology and the respective USAGE part (e.g. switch(ON)). LINK is referring to an operation having the same syntax and semantic, which is part of another ontology as de-scribed in section 3.2.3.2 (in the example LINK is referring to the Radio ontology function

‘switch’).

Usage

Operations Link

InPara OutPara OpName

Figure 30: Usage Part of the Ontology

The MAPPINGS part defines what mappings are possible between the USAGES part of dif-ferent ontology instances. MAPPINGS identify a TARGET ontology (TARGET) and specifies which operations can be mapped to the target ontology. The MapFunction defines an algorithm, which has to be applied to the In-Parameters and Out-Parameters to be compliant to the target ontology.

Figure 31 shows the structure of the MAPPINGS part of an ontology. Below a concrete exam-ple of how to describe a mapping between two ontologies is given. Pseudo syntax is used again to show which parameter of the source ontology has to be mapped to the target ontology.

MAPPINGS of Light1 Target = set of Light2 InPara

SourcePara = input TargetPara = value

MapFunction: input(ON) = value (1), Input(OFF) = value (0) OutPara

non

The mapping above illustrates the example given in Figure 27 again. A client able to issue commands to Light1 (e.g. switch(on)) can have this command mapped according to the ontology of Light2 (e.g. switch(on) is mapped to set(1)).

The exact specification of the MAPPINGS part depends on the selected technology to describe the ontology. Therefore, a complete specification is given in the realization part of this thesis (see section 4.3.2).

Mappings

Target InPara OutPara

SourcePara TargetPara MapFunction Figure 31: Mapping Part of the Ontology

The DESCRIPTION part of the ontology describes the semantic of an ontology and provides several types of notations for that. To support the developer of comfortable graphical user inter-faces, the DESCRIPTION part first defines the human language a description is given in. De-scriptions can be given in different languages in parallel to support multilingual services or user interfaces.

Furthermore, the DESCRIPTION part provides textual descriptions as well as multimedia con-tent to be used to visualize the semantic of the ontology. All information provided within the DESCRIPTION part is to assist human users to understand the purpose of a discovered object.

Object-to-object interaction will not evaluate the DESCRIPTION part at all.

Description

Language Text Picture Other

Figure 32: Description Part of the Ontology

The ontology structure introduced so far enables the description, discovery, validation, and mapping of interface descriptions provided for objects within individual communication spaces.

In addition to that, the ontology structure should also suit the knowledge or the information handled within I-centric communications systems (e.g. to describe individual preferences or content to be exchanged between different individuals).

For such situations, a modified ontology structure can be used. The USAGE part has to be ex-changed by a simple INFORMATION part, which define the data structure and restrictions for the information to be exchanged. The same mechanism as introduced for InPara/OutPara can be applied then. An INFORMATION part can also be linked or mapped to another ontology. Link-ing INFORMATION indicates that two pieces of information are semantically and syntactically same. Mapping INFORMATION part describes the translation between the information stored in different profiles.

An example for mapping between profile info is given in the following. An individual might have the preference to get graphical user interfaces displayed with blue background color. A generic user profile then will contain the preference ‘blue’. Whereas a more hardware related profile will store the same information as ‘RGB(50,10,200)’. The mapping between both pro-files enables a checking algorithm that finds out whether both representations are semantically same.

The introduction of using ontologies for specifying the interfaces and information to be ex-changed between different components of the Open Profiling Framework leads to a flexible infrastructure. Components can be discovered automatically, exchanged information can be evaluated against its ontology, and the process of software maintenance is eased by reducing the programming overhead when some of the components change.