Using Semantic Web Technologies for context-aware Information Providing to Mobile Devices

In this paper we discuss our ongoing implementation of a semantic web scenario. Visitors of the L3S Research Center should be enabled to make a self-guided tour by equipping them with a Pocket PC. On their tour they are provided with context-aware information about researcher projects and knowledge about the respective domain. The presented information is adapted to the specific information interests of the user. This scenario is based on the Cooltown Project by the HP labs. 1. BACKGROUND 1.1 The Semantic Web By definition the Semantic Web is ”an extension of the current web, in which information is given well-defined meaning, better enabling computers and people to work in cooperation” (see [1]). This extension has already proceeded. The W3C [17] defines the architecture of the Semantic Web as a layer model (see [2]) which is based on the Resource Description Framework (RDF) [14]. RDF takes advantage of URI, Namespaces, XML and XML Schema which are building the base of the RDF Specification. Standards like RDF and RDF Schema [13] and especially a high level standard like the Web Ontology Language (OWL) [16] allow developers to create a vocabulary of concepts. These vocabularies are called Ontologies. Ontologies provide a shared and common understanding of a domain that can be communicated between people and application systems like agents. They are developed to facilitate knowledge sharing and reuse [5]. In the simplest case, an ontology describes a hierarchy of concepts related by relationships [6]. In a more sophisticated ontology, suitable axioms are added in order to express other relationships between concepts and to constrain their intended interpretation. 1.2 Cooltown The Cooltown Program [3], a program of HP Labs, acts in accordance to the definition of the Semantic Web as aforementioned. Given that an Ontology is a fundamental requirement to implement Semantic Web scenarios, a core aspect of the Cooltown Idea is that ”everything people, places and things has a web presence”. This aspect is of particular importance whenever web services or other applications do reasoning to humans. Other facets of the Cooltown Vision are that humans know the promise of mobile web services and that devices and services cooperate federated and context-aware. In an implementation of a scenario, in which visitors of Lasar Segall museum in Sao Paolo, Brazil, are equipped with mobile devices, these core ideas of Cooltown were included (see [4]). We model on a similar scenario: Visitors of the L3S Research Center [9] should be enabled to make a self-guided tour by equipping them with a Pocket PC. On their tour they are provided with context-aware information about researcher projects and knowledge about the respective domain. 1.3 A Concrete Scenario: Cooltown @ L3S Research Center In order to point out the need for our architecture of a system that provides context-aware information by using Semantic Web Technology we introduce an concrete example: Tom, who is working on his master thesis in the range of ”Adaptive Hypermedia”, visits the L3S Research Center in order to pick up literature. For that he equips himself with a Pocket PC and starts his tour. While he is walking around, websites are displayed on the Pocket PC giving him information about research projects, persons who work on these projects and suitable background knowledge. As these websites appear conformable to his actual position, Tom has the ability of having conversations with the corresponding researchers. When Tom passes a seminar room he is specially advised to a lecture entitled ”Personalization on the Web” that initiates in 15 minutes, that perfectly fits to his research interests. Tom is looking forward to this lecture and clicks on a link to a corresponding paper and sends it to the next printer. Now a map is displayed on his mobile device that directs him to the printout. Tom has the feeling of being at the right place to do research for his thesis because most of the information that was displayed on the Pocket PC fits with his interests. As the provided information satisfies the users needs, the described scenario fits in very well in the Cooltown Idea. On some sections we will pick up this example to illustrate our approaches. 2. TECHNICAL REALISATION 2.1 Architecture A general structure of the context-aware information providing system is shown in Figure 1. The system is distributed into a client and a server application. But different from regular tour guidance systems this is not a straight Push Technology as the client application and also the user can inherit an active part. We can differentiate two cases of how to cause a switch of website, that is displayed on the mobile device: 1. change of position: When Tom passes a seminar room (see section 1.3), the position localizator (see section 2.2) which is part of the client application indicates his new position and sends a direct request to the textitCommunication Servlet. 2. user interaction: By clicking on the link to the corresponding paper (see section 1.3) Tom takes an active part in requesting information. Thus the tasks of the client application are outlined as: position localization (see section 2.2) and providing browser functions. Figure 1: Architecture of the context-aware information providing system: It shows the different components of the system and indicates a general sequence of actions. The adjustment of the components also clarifies Typees of components like communication components, controlling components, service components (RequestAnalyzer, Reasoner, HTMLCreator) and data components. Although the server application does not take an active part in communication we also do not deal with a straight Pull Technology. If the server application is requested for information according the case change of position, this request does not reference to a specific website but only delivers the user’s actual position. So the server application has to identify the information that suits to the current location and to the current user. Thus main competences of the server application are: creating and publishing websites. Before illustrating the sequence of action in creating websites we have to outline the character of data management: Information about a particular Researcher, Research Group or a Thing (i.e. a seminar room, see section 1.3) are called web resources and are stored in xml files, that are enriched with metadata. Interrelations between these web resources are defined in an ontology just like profiles, rules and other vocabulary (see section 3). Before pointing out the interaction between requests, reasoning, data and the preparing of data we distinguish between four cases of websites: 1. Type A Site: Such websites are static; they are always created by the application in the same way. When Tom starts his tour, he first has to adjust his personal profile on a website in the Pocket PC. 2. Type B Site: These are sites that are generated according to a personalized Style sheet. As a result of Toms adjustments in his personal profile, a suitable Style sheet (personalized Style sheet) is assigned to him. This personalized Style sheet is used to create a lightly personalized website (according to i.e. language or background) out of a web resource. 3. Type C Site: We refer to Type C Site in the case of the preselection of web resources according to a personal profile. So the provided website is a Type B Site that was preselected. 4. Type D Site: In contrast to the other forms, these sites are not based on web resources in sense of xml/html files. Type D Sites appear as results of a search. For this purpose a new web resource is modelled only inside the application. Depending on this cases the server application has to provide the information. As the server application must be able to differentiate these cases, it has to analyze the request. Thus the Communication Servlet passes the query to the Request Analyzer which is controlled by the Main Controller. The Request Analyzer delivers the results that are derived from the Ontology to the Main Controller (See Figure 1). Depending on the four pictured cases we have the following streams of action: 1. Case ”Type A Site”: The Request Analyzer returns a specific URI that references to an already built website and is sent directly to the client application. 2. Case ”Type B Site”: The Request Analyzer returns a specific URI that references to a web resource. Then the Main Controller calls the Reasoner for the personalized Stylesheet that is associated to the actual user and after that the Main Controller calls the HTML Creator which results in an URI for the generated site. 3. Case ”Type C Site”: Getting the personalized Style sheet is equivalent to the preceding case. Additionally the Reasoner has to discover a suitable web resource by requesting the metadata of the resource. If successful, a website is generated and the dedicated URI is sent to the client application. 4. Case ”Type D Site”: The Request Analyzer returns a special task and corresponding parameters which are analyzed by the Reasoner. The Reasoner writes his results into a xml model. With that and with a standard style sheet the Main Controller calls the HTML Creator which results in an URI for the generated site. In section 3 we address the issue of ”Typ D Sites” in terms of list of questions which the system can handle. 2.2 Position Localization To provide context-aware information not only in terms of personalization but also adapted to the facilities of the L3S we have to localize the position of the user. In accordance with our architecture, outlined in section 2.1, the Position Localizator is part of the client application. So an implementation of the Position Localizator has to be realised with the components of the mobile device. As the Pocket PC of our scenario (see section 1.3) is equipped with a wireless Lan adapter pursuant to the standard IEEE 802.11b we use the f