Contrasting object-relational and RDF modelling in a Tourist Information System

Annika Hinze, Department of Computer Science, University of Waikato, Hamilton, New Zealand, Email: mail@annikahinze.de

Katja Loeffler, Department of Computer Science, Freie Universitaet Berlin, Germany, Email: kmartin@inf.fu-berlin.de

Agnès Voisard, Department of Computer Science, Freie Universitaet Berlin, ISST Fraunhofer Berlin, Germany, Email: voisard@inf.fu-berlin.de

Abstract

Advanced tourist information systems should deliver more than weakly-related static information about sights. Instead, semantically-rich information about sights (e.g., groups of sights with same characteristics) should be delivered to the mobile users. Furthermore, tourists should not be overwhelmed by a stream of superfluous data unrelated to their interest and location. Personalization of the information delivery to each traveller, together with his or her travel history, is therefore crucial.

In this paper, we describe the lessons learned from developing the kernel of an advanced tourist information provider using a semantic network of sight-related information and considering the travellers' interest and travel route. The system is a combination of event notification services (publish/subscribe) and location-based services (LBS). For modelling all relevant data, two approaches are compared: a RDF-based model and an object-relational model.

1 Introduction

We believe that the development of advanced mobile information systems requires the application and transfer of web-related technologies and modelling techniques into the area of mobile applications. We shall argue our case using a sample application example of a tourist information system. This paper will reveal some of the problems that emerge when web technologies are applied in this context. Below are three major issues to be considered.

Alerting Service The tourist information system should provide not only a large number of discrete pieces of static information about sights - as a travel book would do - but the information should be tailored to the tourists as they travel. Event notification services, or alerting services, have been developed for such tailoring: in this case, timely delivery of pertinent information that answers to their clients personal interests and context [10].
Semantic Web and RDF Semantically-rich information about sights (e.g., groups of sights and their relation to each other) should be available to the tourist at any time and easily accessible while travelling. The modelling techniques developed for the semantic web should be employed for two reasons: Firstly, they have been developed to capture semantically-rich information spaces (tourist information may comprise almost anything from sights to travel literature and news information, forming a large network of interconnected information items). Secondly, the tourist-oriented information should not be modelled independently of and unconnected to publicly available information sources such as the (semantically-enriched) Web.
Personalised services Tourists should not be overwhelmed by a stream of superfluous data unrelated to their interest and location. Personalization of the information delivery is therefore crucial. Here, the concept of personalised services has to be transferred into location-based services. Besides, taking advantage of the tourist's acquired knowledge - based on his or her history - can bring a new dimension. Moreover, the system has to keep track of the information that have already been presented to the tourist, such as particular items and parts of the semantic network.

This paper reports on our experience with the development of a tourist information system for mobile users. We identify the specific modelling requirements for an advanced tourist information system. We compare the use of two modelling approaches: semantic-web-related (i.e. RDF and RDFS) and traditional database-related (object-relational) techniques. We identify the advantages and drawbacks of the application of web-related techniques to mobile applications and identify open research issues. Note that our focus is on modelling and user adaptivity, not on issues that inevitably arise in such systems, such as availability and scalability.

The paper is organised as follows. Section 2 introduces a sample application scenario that serves as illustration throughout the paper. Section 3 identifies the specific requirements for mobile tourist information systems. Section 4 presents and compares the two modelling approaches using RDF and an object-relational model. In Section 5, we introduce the implementation of our prototype. The paper is rounded off by a summary of our findings and issues for future research.

2 Illustrative Application Scenario

In this section, we introduce an example scenario which is used throughout the paper to illustrate application requirements. The scenario is divided into steps for easier reference later in the paper. Consider the following scenario for two tourists doing sight-seeing in Berlin: Anne visits Berlin for the first time; Berit has been in Berlin before. They are currently at a the Gendarmenmarkt (a square in central Berlin). Both, Anne and Berit are equipped with their PDAs (with GPS), which have running client programmes of a tourist information system (such as e.g. TIP [11] - a Tourist Information Provider). In our example, the two tourists will spend their time sightseeing together - their different travelling background and interests will be reflected in the information presented to them.

Step 1: Before starting their sightseeing tour around the Gendarmenmarkt, Anne and Berit connect to TIP and define the types of sights and the information topics they are interested in: both are interested in cathedrals and statues, Anne is interested in architecture and Berit in history (see Table 1).

Table 1: Anne's and Berit's Interests as described in our Scenario

Person	Types of Sights	Information Topics	Travelling History
Anne	cathedrals and statues	Architecture	first visit to Berlin
Berit	cathedrals and statues	History	repeated visits to Berlin

Step 2: When Anne and Berit reach the Gendarmenmarkt, they both activate a special `Give me information'-Button on their individual TIP-client programmes. The clients trigger the current GPS coordinates to be sent to the TIP server. As a result, Anne is presented with information about the sights that are near to her current location and that are either cathedrals or statues - because Anne is interested in architecture (see her profile in Table 1). Only information that refers to architectural facts is given. Berit also receives information about the same sights - but she is presented with details regarding historical facts. Anne's and Berit's way over the Gendarmenmarkt is shown in Figure 1.

**Figure 1:** Anne's and Berit's way over the Gendarmenmarkt square
$\begin{figure} \begin{center} \epsfig{file=pic/gm_scen_A+B.eps, width=8cm} \end{center} \end{figure}$

Step 3: The TIP client shows both tourists that they may visit two cathedrals, the German Cathedral (Deutscher Dom) and the French Cathedral (Französischer Dom) as well as the statue of Schiller (Schillerdenkmal). Information about the concert house (Konzerthaus) is not presented, since it does not match their interests. They decide to first visit the French Cathedral. When they are about to enter the cathedral, each of them pushes the Information-Button again.

Step 4: Anne is now provided with detailed general information about the cathedral plus specific information regarding the architecture of the cathedral. The TIP client offers Anne the option of presenting detailed and elaborate information. Berit is presented with brief general information about the cathedral plus detailed elaborated information regarding historical facts. She has been receiving more general information during her last visits - she may follow up that more general information if she likes.

Step 5: After having visited the cathedral, Anne and Berit briefly reread the provided information and continue to the statue Schillerdenkmal. From there, they are going to visit the German Cathedral (Deutscher Dom). Again, just as in the Französischer Dom, they are provided with general/specific information and facts about the topics architecture and history, respectively. Additionally, Anne is given a comparison between the architectures of the German and the French Cathedral, because she has visited both cathedrals.

Step 6: Finally, the TIP clients suggest to both tourists to visit further cathedrals in central Berlin: the Berlin Cathedral (Berliner Dom) and the Nikolai Church (Nikolaikirche). They leave the German Cathedral and continue towards the Berliner Dom.

3 Requirements Analysis and Related Work

Taking the sample scenario from Section 2, we can define various functional requirements for the envisioned system (FR 1 - 6). These requirements will be used to briefly evaluate related work (in Section 3.2) and to derive requirements regarding the modelling of data (in Section 4). The requirements presented here set up a framework that shall be used to contrast the different design approaches for the application.

3.1 System Requirements

FR1.: User profiles and Information filtering As illustrated in steps 1 and 2 of our scenario, the system needs to support personalised information delivery. The user's preferences have to be defined and stored. The information provided to the users is to be filtered according to the profile.
FR2.: Location-based information delivery To support the delivery of timely information, the system has to support the registration of the users position. Additionally, a filtering of the delivered information is necessary so that only information relevant to the current position is delivered. (see Step 2 of the scenario).
FR3.: Information delivery based on hierarchical information structure The system should support information delivery that provides different detail-levels of information. The presented information depends on the level of user interests (e.g., from general information to detailed expert knowledge). If a user presses the `more information' button again (cf. Step 4), more detailed information is given. Thus, the stored information regarding the sights has to reflect a hierarchical structure. We refer to these (possibly interconnected) information hierarchies as the vertical information network.
FR4.: Clusters of sights Beside providing information for each stored sight, the system should also offer the possibility to group the sights in semantic clusters. A semantic cluster (also called group or class) is a collection of sights that are semantically close to each other, i.e., their semantic relations are emphasised in the cluster. For example, the sights located at the square Gendarmenmarkt or all cathedrals in Berlin could form clusters. In Step 5 of our scenario, Anne is provided with joint information about the German and French Cathedral. The clustering of sights and the storage of information about clusters is referred to as horizontal information network.
FR5.: User History Revisiting users are not presented with information that has already been delivered to them. Instead, a connection to their previous visit is made and more detailed information is offered. For example, in Step 4, Anne is given detailed information because she has visited the cathedral before. The system stores information about the users travel history. The delivery of information regarding visited clusters also requires the user history to be stored.
FR6.: Personalised Recommendations based on History The system should recommend the visit of sights that match the user's profile, their travel history, and their current position. For example, in Step 6, both tourists are recommended to visit further cathedrals in Berlin because they already visited a number of cathedrals (so they might be interested), the sights are near by, and they match their profiles.

These functional requirements determine the features to be implemented for the system and the underlying data model (see Section 4).

3.2 Related Work

The combination of location-based services, event notification and semantic modelling is not common. Several system exist that process location-based information; few systems encompass the notion of events or profiles. A large variety of event notification systems has been implemented, very few are used in the context of tourist information. For an extensive analysis of related approaches see [11]. Here, we briefly analyse four systems with related approaches that have been developed specifically for mobile tourist information delivery: Guide [9], Crumpet [16], Catis [15], and Cyberguide [1]. The Guide system is an earlier system and does not support GPS locations but broadcasts information near sights (in Lancaster). User profiles are used for the information filtering; an user history is kept and considered when recommending sights. In Crumpet, the user profile is developed by tracking the users travel movement, i.e., the users history. Several mobile devices are supported for user information. Catis is a flexible system that uses user profile, location, event history and other context data to filter the delivered information. It provides flat unstructured information, i.e., no semantic or hierarchical structure is used. Cyberguide is a indoor guide system, no user profiles are supported. Location and orientation of the user within a building are used to filter the provided information. The system has a wide range of additional features, e. g., group communication. Table 2 summarises our evaluation for the selected systems.

Table 2: Analysis of (selected) related work according to requirements (Symbols: + system fulfills requirement, - system does not fulfill the requirement)

Requirement	FR1	FR2	FR3	FR4	FR5	FR6
Guide	+	(-)	-	-	-	+
Crumpet	+	+	-	-	-	-
Catis	+	+	-	-	-	+
Cyberguide	-	+	-	-	-	-

Another related approach is that of an ongoing project at the Fraunhofer ISST, namely Personalised Web Services for the Olympic Games in 2008 in Beijing[12], where the focus is on context and user situation together with the dynamic matching of services.

4 Data Modelling

In this section, we evaluate two data models (using different techniques) for their suitability for the envisioned application. Initially, we translate the general system requirements defined in Section 3 into specific requirements regarding the data model. Then, we compare the two modelling approaches, one from the semantic web community (RDF model) and one from the database community (object-relational model).

4.1 Data Model Requirements

Based on the functional requirements introduced in Section 3, we identify the following requirements regarding the data modelling (MR 1 - 8) for the envisioned system. These requirements will be used to analyse the data models.

MR1.

User profiles: For each user, a profile must be stored. User profiles refer to (predefined) topics of information.

MR2.

Location: The location of users and sights must be represented in the system.

MR3.

Hierarchy of information: Information regarding sights (data objects) is ordered into topics (e.g, architecture, history, shopping, etc.). For every sight and for each topic available for that sight, a hierarchy of information regarding the sight has to be stored. An example for two sights is shown in Figure 2. This is example data that may be used in steps 4 and 5 in our scenario.

**Figure 2:** Information Structure for two sights: For each sight, the information is ordered according to *topics*. For each topic, information with increasing *level of detail* is available.
$\begin{figure} \begin{center} % \begin{latexonly} \epsfig{file=pic/fd_dd01.eps, width=9cm} \end{center} \end{figure}$

MR4.

Clusters of data objects and assigned information: Data modelling must support clustering (grouping) of sights and the assignment of a hierarchy of information. Collection consist of one or more elements as shown in Figure 3. This modelling requirement is based on the functional requirement FR4.

**Figure 3:** Information Structure for a Semantic Clusters
$\begin{figure} \begin{center} \epsfig{file=pic/semexample_2_00.eps, width=10cm} \end{center} \end{figure}$

MR5.

Personal history data: The system must store the travel history of the users, i.e., the visited locations and the provided information (levels). These information has to be available for information selection and recommendations.

MR6.

Effective retrieval of data: Query languages available for the data model have to support a wide range of filter queries (for details regarding the language requirements see [11]).

MR7.

Efficient storage and retrieval of data: Due to the restrictions of mobile access to the data while travelling, the retrieval has to be efficient. The amount of user-related data (e.g., user histories) will grow over time - demanding efficient storage strategies.

MR8.

Extensibility of Data Set: The data structure has to support new information within the existing framework and also extensions to the framework itself.

4.2 Semantic Web Approach: RDF

We now introduce and analyse a semantic web approach to modelling the application data. In the next section, we describe the contrasting database-related approach.

We initially analysed two data modelling techniques from the area of semantic web, namely Topic Maps [3] and RDF [13] (for details see [14]). Here, we focus on the RDF-based modelling approach. We assume that the reader is familiar with the basic concepts of RDF [13] and RDFS [5]. In this paper, we use the graph notation of RDF.

**Figure 4:** RDF Data Model and Example Data
$\begin{figure} \begin{center} \epsfig{file=pic/tip_klein_paper_1.eps, width=16cm, height=6.5cm} \end{center} \end{figure}$

Figure 4 shows a section of the RDF graph of the example data regarding sights (users and their histories are not shown here). We distinguish four classes of locations: statue, square, building, and cathedral, where cathedral is a subclass of building. The hierarchical information in various topics for single sights (e.g., as introduced in Figure 3) is assigned to the classes by the property topic having the sub-properties general, architecture, history, and today. The property is of range rdf:Seq allowing an ordered list of property values for each resource.

For the semantic grouping of sights we use a class group with its properties contains, currentSight, and hasInfo. The property contains is of range rdf:Bag and therefore allows the creation of loose collections of sights. currentSight refers to the sight at which the tourist is located when this group is accessed. The clusters for recommending sights are described by cluster which also has the property contains.

Analysis of the RDF-based Model.

The user profile details (MR1), location of the user (MR2), and the user travel history (MR5) are temporal data. For efficiency reasons, we did not model them in RDF but in a relational database. Functions for the handling of location data efficiently (as known from location-based services) have to be provided by the system implementation.

The subPropertyOf relationship allows for simple implementation of the hierarchy of topic information (MR3). Clusters of data objects can be built using the rdf:Bag construct which allows to form loose collections of objects. Additional information regarding a cluster (MR4) can be assigned using a property-value pair.

The effective and efficient access and storage of the information (MR6+MR7) heavily depend on the query language and the storage system used for the implementation. In theory, the model and the data base are easy to extend (MR8) due to the simplicity of extending RDF and RDFS data. For a certain implementation, the extensibility depends on the used storage system. A disadvantage of current RDF storage systems is the necessary translation into other data models. We used the Sesame system [7], which allows the storage and manipulation of RDF data in a database. Sesame supports the RDF languages RQL [6], SeRQL [8], or RDQL [17]. All queries are translated from an RDF-query language into the native database query language (e.g., SQL). Relationships between the data might be lost in the translation process. Additionally, the result set is translated back into RDF. For several RDF query languages, the result of a query cannot be queried further. This behavior leads to serious performance problems (for details see [4]).

Another disadvantage is the mixed modelling of the data. The integrated and seamless access to the data might not always be ensured and may even lead to inconsistency in the data.

4.3 Object-Relational Approach

The second model is based on an object-relational approach. An object-relational database combined the advantages of object-orientation and the functionality of a relational database system. Due to the hierarchical network structure of the sight-related data, we modelled these data in an object-oriented way. We show in Figure 5 a refined model (compared to the RDF model); items similar to the RDF model are drawn in bold font. User-related data, like profiles and a user event history, are modelled in a separate relational model.

**Figure 5:** Extended object-relational Data Model
$\begin{figure} \begin{center} \epsfig{file=pic/or_erd.eps, width=16cm, height=9.0cm} \end{center} \end{figure}$

The object hierarchy is modelled in "is a" relationships; the lowest-level objects (e.g., cathedral) inherit all attributes from the more general ones. Semantic groups are built in an relationship, which allows the assignment of one sight to various semantic groups; semantic groups contain one or more sights. The sight the user is currently at (i.e., the current sight) is referred to by an attribute. The clusters for sight recommendation are modelled similar to groups.

Analysis of the object-relational model.

The user profile details (MR1), location of the user (MR2), and the user travel history (MR5) are modelled using the same technique as for the sight-related data (not shown in Figure 5). The locations of sights are modelled as attributes of sights. Functions for handling location-related data can be re-used from a spatial extension for the DBMS, e.g, from PostGIS for PostgreSQL, or Oracle Spatial for Oracle. The hierarchy of topics (MR3) is directly supported by the object-oriented features of the database model.

As can be seen in Figure 5, the grouping of sights is captured by a relationship. Information about a group (MR4) is stored as an attribute of the relation group.

As in the case of RDF, the effective and efficient access and storage of the information (MR6+MR7) depend heavily on the storage system used for the implementation. An extension of the data set results in the simple task of inserting additional data in the database. The extension of the modelling level (e.g., topics and types of sights) is a more complex task.

The advantages of this approach lie in the use of well-developed concepts that are supported by sophisticated implementations (i.e., object-oriented database systems, GIS systems). For example, attributes of objects can easily be used by data mining algorithms, e.g., for clustering the sights for recommendation according to certain characteristics. Moreover, tuning and indexing of database systems has a long tradition that can be drawn upon for this application.

On the other hand, the resulting model is more rigid and less flexible (MR8) - for a discussion see Section 5.2.

5 Implementation

In this section, we introduce our implemented TIP system and point out the implications of the two contrasting data models for the implementation.

5.1 TIP architecture

We implemented a tourist information system as envisioned in the scenario: the TIP system (Tourist Information Provider). In this section, we describe the implementation details of our system. Figure 6 shows the architecture of the TIP system.

**Figure 6:** TIP Architecture
$\begin{figure} \begin{center} \epsfig{file=pic/tip_arch.eps, width=8cm} \end{center} \end{figure}$

TIP consists of several components: a spatial component for the location information of sights and users, a profile component handling generic profiles and user profiles, an event component, the event history, and the data base of sight-related information. Tourists send their location and their ID to TIP; which, in turn, uses this information for filtering according to the user profiles and to update the event history. The spatial component and the user location component identify the sights near a user. The events component recognises repeat visitors. Taking the results of all these filter steps, the information relevant to the user is identified and provided to the user. Figures 7 and 8 show two screenshots of the TIP system. Figure 7 shows the presentation of initial sights nearby to Anne and Berit (cf. Step 2 in the scenario).

**Figure 7:** Overview over Sights nearby (Screenshot), see *Step 2/3* in the scenario [click to enlarge]

Figure 8 is a screenshot of the information presented to Anne at the French Cathedral (cf. Step 4 in the scenario). For our prototype implementation, mobile users are simulated by predefined test data. We analysed the functionalities achieved when using each of the models (RDF or object-relational) as proposed in Section 4.

**Figure 8:** Information provided to Anne at the French Cathedral (Screenshot) [click to enlarge]

5.2 Model implications in TIP

For the implementation of the RDF model, we used Sesame 0.96 with a PostgreSQL 7.3 database as the repository and Sesame RDF as the query language. Even though Sesame is one of the most advanced RDF systems, Sesame RQL does not offer the functionality¹ needed for our application. For example, aggregate functions, container queries, and mathematical functions are not supported. We implemented replacements for these features directly in Java.

Selecting the appropriate RDF query language prove to be a difficult task. RDQL does not support container, inference, reification, or schema-related queries. SeRQL does not support retrieval of the transitive closure. It also does not offer predefined functions, which makes the query writing more unwieldily/ungainly (e.g., the retrieval of direct subclasses requires the elimination of unwanted classes). Only RQL provides orthogonality of query and result set. Using RQL, open path-queries are not possible. Here, the RQL extension for querying semantic associations, the $\rho$ operator [2], could be used. The Sesame version of RQL does not implement all RQL features. None of the languages fully support the handling of RDF Bags and Sequences. We decided to use Sesame's RDF because of its wide acceptance in the semantic web community.

For the object-relational implementation, we used PostgreSQL 7.3. To achieve all required object-relational features ², we used views on tables in order to create data hierarchies.

Using the object-relational model, only relationships that have been explicitly modelled can be implemented. The relationships between sights and topics are more complex and implicit. The object-relational model does not support inheritance for relationships - instead one is obliged to use objects to capture relationships and their inheritance.

6 Conclusion

In this paper, we focused on the modelling aspects of an advanced tourist information system. Beside dimensions such as time and location, common tourist information systems consider the profile of the mobile user, e.g., their preferences and interests. However, our system goes beyond such a classical approach and aims at offering two novel features: (i) a link to the history of the user - in other words, the system `knows what the user knows' - and (ii) links between sight-related information, i.e., a semantic network of tourist information.

We presented a sample scenario with tourists having different interests and a different travelling background. The scenario served to derive the functional requirements of an advanced mobile tourist application. These functional requirements have been the basis for further examinations in two different data modelling approaches: a semantic web approach using RDF and an object-relational approach. A possible data model was presented for each approach and analysed according to the requirements. Finally, the implementation of the kernel of the system was briefly described and the main implications of the two contrasting data models were given.

Our conclusions regarding the two different modelling approaches are as follows: The object-relational model has the clear advantage of being a well understood, highly developed and technically well supported model. In contrast, the RDF model and storage systems are still in the fledgling stages. At present, object-relational modelling is to be preferred over RDF-based modelling. However, we are convinced that RDF or similar formats are the appropriate means once they are more mature. For the object-relational model, the data to be modelled often has to be tailored for the model - whereas the final goal is to have a means of modelling that suits the inherent characteristics of the data. In a future, extended RDF storage and querying model, the facets of the the data will have to be mirrored directly. At present, RDF support for applications with a wider focus than stereotypical semantic web applications is rather poor; a considerable amount of research is still required.

Our current approach works successfully upon a fixed architecture of semantic clusters. However, it does not yet fully exploit the intricate information of the user histories. Data mining and other techniques may hold the key to unlocking more of the connections that user history alone can uncover. Of course one cannot constantly reanalyse all the histories of all the users because of performance issues. We propose to develop an incremental algorithm that would work on both classes and instances. This is part of our future work.

Note also that the current approach focuses on the interest of independent users. Data mining techniques will allow us to consider groups of users. The system could suggest to a user the sights that were visited by other tourists with similar travel histories. This is also part of our future work.

Finally, the next steps in our work will increasingly explore the mobility aspect of the system and the user acceptance of and experiences with the service.

References

1: G. Abowd, C. Atkeson, and J. Hong: "Cyberguide: A mobile context-aware tour guide". In ACM Wireless Networks, volume 3, pages 421-433, October 1997.
2: K. Anyanwu and A. Sheth: " $\rho$ -queries: enabling querying for semantic associations on the semantic web". In Proceedings of the International WWW Conference (WWW 2003), May 2003.
3: M. Biezunski, M. Bryan, and S. Newcomb: "ISO/IEC 13250, Topic Maps". available at http://www.ornl.gov/sgml/sc34/document/0058.htm, June 2002, Last visited: 2004-01-20.
4: V. Bönström, A. Hinze, and H. Schweppe: "Storing RDF as a Graph". In Proceedings of the Latin American Web Conference, Santiago, Chile, November 2003.
5: D. Brickley and R.V. Guha: "RDF Vocabulary Description Language 1.0: RDF Schema". available at http://www.w3.org/TR/rdf-schema/, Status: Working Draft. December 2003. Last visited: 2004-01-20.
6: J. Broekstra and A. Kampman: "Query Language Definition". Technical Report On-To-Knowledge EU-IST-1999-10132 deliverable 9, Aidministrator Nederland b.v., May 2002.
7: J. Broekstra, A. Kampman, and F. van Harmelen: "Sesame: An Architecture for Storing and Querying RDF Data and Schema Information". In Proceedings of the First International Semantic Web Conference (ISWC 2002), volume 2342 of LNCS, June 2002.
8: Aidministrator Nederland b.v.: "User Guide for Sesame", Chapter 5. The SeRQL query language. available at http://sesame.aidministrator.nl/publications/users/ch05.html, March 2000. SeRQL Manual of Sesame 0.96. Last visited: 2004-01-20.
9: K. Cheverst, N. Davies, and K. Mitchell: "The role of adaptive hypermedia in a context-aware tourist guide". In Communications of the ACM, volume 45, No. 5, pages 47-51, May 2002.
10: A. Hinze: "A-MEDIAS: Concept and Design of an Adaptive Integrating Event Notification Service". PhD thesis, Freie Universitaet Berlin, Department of Computer Science, July 2003.
11: A. Hinze and A. Voisard: "Location- and time-based information delivery in tourism". In Advances in Spatial and Temporal Databases (SSTD 2003), volume 2750 of LNCS, July 2003.
12: B. Holtkamp, R. Gartmann, and Y. Han: "FLAME2008: Personalised Web Services for the Olympic Games 2008 in Beijing". In Proceedings of the e-Challenges Workshop (e-2003), November 2003.
13: O. Lassila and R. Swick: "Resource Description Framework (RDF) model and syntax specification". http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/, December 2003. Status: W3C recommendation.
14: K. Löffler: "User-Adapted Information Delivery in Context-Aware Systems". Master's thesis, Freie Universität Berlin, Department of Computer Science, January 2004.
15: A. Pashtan, R. Blattler, and A. Heusser: "CATIS: A Context-Aware Tourist Information System". In Proceedings of the 4th International Workshop of Mobile Computing, June 2003.
16: S. Poslad, H. Laamanen, R. Malaka, A. Nick, and A. Zipf: "Crumpet: Creation Of User-Friendly Mobile Services Personalised For Tourism". In Proceedings of 3G 2001 - Second International Conference on 3G Mobile Communication Technologies, March 2001.
17: A. Seaborne: "A Programmer's Introduction to RDQL". HP Labs, available at http://www.hpl.hp.com/semweb/doc/tutorial/RDQL/, April 2002. Last visited: 2004-01-20.

Footnotes

... functionality¹: see http://sourceforge.net/mailarchive/forum.php?thread_id=3460493&forum_id=8435
... features ²: see http://archive.postgresql.org/pgsql-general/2003-5/msg00495.php

Copyright

Annika Hinze, Katja Loeffler, Agnes Voisard, © 2004. The authors assign to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.