Mobile Ontology motivation

The SPICE platform is composed of multiple components that interact and exchange information or data in order to provide new and innovative services. A common view on the exchanged information, i.e. on their semantics, is needed, and therefore an ontology can be used to play this role. The Mobile Ontology defines a data format that is shared by the different SPICE components and that, moreover, allows them to do some reasoning.

The Mobile Ontology is divided in sub-ontologies that cover different domains and allow extensibility and reusability. A more detailed motivation for the specification of each sub-ontology is given in the following paragraphs.

Services - SPATEL

The SPICE project has defined a high-level language for designing composite services, i.e. services that are built from existing service components. This language, which is called SPATEL, has two main usage scenarios: it can be used by a service designer to define "manually" the logic of a service composition or it can be used by an automatic composition engine to produce the logic of the composition based on semantic annotations attached to the model elements making the service description.

Having the concepts of the SPATEL language in the form of an ontology allows the different tools exploiting SPATEL descriptions to take advantage of ontology techniques to reason on SPATEL definitions. Moreover, SPATEL service description have the possibility to embed various kinds of semantic and QoS annotations, in the form of explicit links to the elements of an ontology, in order to enable scenarios where automatic discovery and selection of services are needed.

Service Context

The SPICE platform offers several services and the functionalities for their publication and discovery. The Service Context sub-ontology is intended to be used by the Service Broker during the task of selecting and composing the most appropriate service in response to a user's service request. The information about which service is best suited in a given situation is stored in the service context sub-ontology. It captures the characteristics of services that are useful in ranking services in different circumstances. For example, a service can be selected because it is used "most often", or it is "located closest" to the user, or it uses "lest system resource", or it runs "fastest", etc. Accordingly, the information about "how often it is used", "where it is located", "how much system resource it uses" and "how fast does it run", etc is stored in the service context sub-ontology.

Profile

The various services require user information, in particular situation-dependent user preferences, to customize their services to the user’s wishes and expectations. It would be a great hassle if each service requested and managed the required user information on its own, and if the user had to provide the required personal data to each single service. Hence, for each platform user, one overall user profile is defined that includes service-specific sub-profiles, and provides the base for sharing user information among different services. In addition, also situation-dependent sub-profiles can be included, i.e. sub-profiles that shall be applied for service personalization in case a specific user situation arises. In particular the latter feature is not sufficiently supported by existing schemas such as CC/PP.

While providing a common user profile structure for use throughout the whole service platform, the profile sub-ontology yet allows extending the profile structure with service-specific user attribute vocabularies such as FOAF or vCard. Mappings between the user attribute vocabularies can then be used for the translation between specific user instances. Such mappings can also be applied in the roaming situation, in which a user profile or parts thereof shall be transferred from the home service platform to a visited service platform.

Presence

Presence is used to convey information about how to contact and communicate with a person and his current status. Typical examples are instant messenger applications that display the availability of communication buddies. IETF has defined presence more accurately and standardized an exchange format, a data model and an extensible set of presence information. Examples of such presence information include the activity of a user, information about its communication devices, the type of place a person is in, information about the time zone, etc. The Open Mobile Alliance (OMA) has endorsed the IETF standards defining a 'Simple Presence Enabler'. In the IP Multimedia Subsytesm (IMS) the presence standards of IETF and OMA play an important role for offering presence services to mobile users. As a consequence of this extensive standardization, presence is often used to exchange information about a user and his devices.

The presence sub-ontology maps the presence standards to the semantic model defined by the Mobile Ontology. This way we re-use existing standards for modeling reachibility information in SPICE rather than re-define our own models. Consequently the SPICE platform benefits from the presence sub-ontology in two ways: (1) the presence sub-ontology facilitates the process of making presence related information in the SPICE knowledge layer available to presence-based clients, and (2) SPICE intelligent service enablers can easily re-use presence information as they only need to comply with the semantic model defined by the Mobile Ontology. The exchange of information between presence services and the SPICE knowledge layer is facilitated by the presence gateway that maps between native presence formats and ontology instances in both directions. The presence sub-ontology is therefore an important element for optimal IMS support.

Context

In order for intelligent services in the SPICE platform to adapt to and anticipate on the end-user's situation, gathering and interpretation of contextual information about the user and his environment is required. Such information is obtained from various sources, ranging from sensors on the user's terminal to knowledge-bases on the platform. The gathered context information is combined and interpreted with reasoning components to obtain a higher level view of the user's situation. Sensors and reasoning components that facilitate this process are distributed throughout the platform, running on a generic middleware framework. Within this framework, each component is specialized in gathering or inferring a particular type of contextual information, often utilizing the results of other components in the process. To discover and exchange information between context gathering and reasoning components, a common data format is needed that defines both the syntax and semantics of the contextual information at hand. Representing this information in an ontology ensures that all middleware components have a common understanding of the contextual information that is exchanged. Besides specifying the types of information that can be exchanged, the ontology provides generic mechanisms for expressing information about the quality of the contextual information (QoC). This allows reasoning components and SPICE services to take additional characteristics of real-world context information into account, such as the accuracy of a sensor measurement or the probability of correctness of an inference.

Distributed Communication Sphere (DCS)

The Distributed Communication Sphere (DCS) of a user refers to the collection of communication resources in the vicinity of a user that can potentially be used to provide high-level services to that user. Such resources include devices (e.g. terminals, sensors, displays, etc.), networks (e.g. networks allowing the user to access the platform and local networks like Bluetooth networks which are not directly visible from the platform), services offered by devices (e.g. multimodal services), and other users (or their representation). Components of the SPICE platform as well as applications may use the resources in the DCS of a user in order to ensure the best possible user's experience as far as using services is concerned. For example, in a multimodality scenario in order to provide multimedia content to the user, the best selection of resources in the DCS is used to render the data stream.

The DCS sub-ontology is used to represent the set of resources in the DCS of a user and their capabilities into a well-known data model. SPICE calls Communication Model to the set of symbolic data that describes the composition of the Distributed Communication Sphere of a user. The Communication Model is exposed into the SPICE Knowledge Layer so that it can be used as any other piece of knowledge information. Any component of the SPICE platform that needs some information about the resources in the DCS of a user utilizes the DCS sub-ontology to interpret the Communication Model.

Content

Metadata can exist at two levels. On the one hand, they may describe a document, for example a web page, or part of a document as for example a paragraph. On the other hand, they may describe entities within the document, a person or company or a landscape. In any case, metadata is not only used to describe a multimedia content with his technical caracteristic but it's semantic also: it can tells us about the content of a document (e.g. its subject matter, or relationship to other documents) or about an entity described in the document.

Following this idea, in WP7 has been created an ontology for content management, navigation and query based on the following concepts:

• A piece of content is a Multimedia Content and it’s a multimedia file with technical characteristics.
  To represent multimedia files with their characteristics we have created a specific sub-ontology;


• A piece of content is a logic container also. Normally an end user looks for a specific file: a news item, a course, a document, a desktop theme etc. Those logical containers can be further classified taking into account what kind of news item is being considered (current events, gossip, sport news, economy news).
  In this way we specify the type of container we are considering for the multimedia file. The following figure represents part of the SPICE content sub-ontology related to Multimedia Container;


• At last, a multimedia content has a topic: a video can be encoded by using MPEG-4 and can be a movie belonging to documental category and the topic tackled in it is the global warming and the senator Al Gore appears and directs it. This part of the ontology is strictly related to the real “content” of the multimedia file the user is looking for. This ontology can easily be a representation of the world so, in SPICE, we will develop the part related to the scenario that will be used for the common demonstrator.

These three different concepts together give a complete idea of multimedia contents available on the platform and facilitate their navigation, retrieval, searching and delivery.

Privacy

In SPICE, two kinds of user privacy management are identified: network based user privacy management and devices based user privacy management. The former is chosen so that the user can specify rules to manage her data. Central concepts in the privacy ontologies are: ConditionalPrivacyProfileSubset, PrivacyCondition, PrivacyContext, and Policy.