TraveLite is a web-based, customized travel guide publisher. The application allows travelers to sort through available travel information and choose only what they decide they need or want, creating their own personalized guide, and then download that product to a PDA. In other words, in developing a guide based on their interests and needs, travelers will have the opportunity to purchase their guide, rather than a static, bland product designed for a generalized perception of what a generic traveler in a region may need.

In order to support this application, TraveLite needs to develop a database to store the content in such a way as to support searches across the available information, allowing the user to pick and choose the information they determine is necessary or useful. These selections will then be stored under an account profile until the user chooses to purchase the guide. The resulting product will then be exported into a format downloadable to a PDA.

The system relies heavily on an easy to search database that also allows the user to explore the content across various features. The primary task for the user will be to explore the range of content available, inputting various constraints and thus filtering based on needs, interests, location, or budgetary constraints. For example, some possible scenarios for this application are:

• · A traveler is visiting San Francisco and is only interested in budget vegetarian restaurants in the Mission neighborhood.
• · A traveler is visiting San Francisco, Los Angeles, and Las Vegas. While visiting San Francisco, they want to live on the deluxe end of the scale (it's their favorite city after all), however while in Los Angeles and Las Vegas, they want moderate restaurants and budget accommodations.
• · A traveler with gourmet interests wants to include all possible restaurants for their visit to California but is only interested in budget accommodations. They have a list of safe neighborhoods recommended by friends and would prefer to stay in one of these areas.
• · A fanatic scuba diver is visiting California and wants all the information available on their favorite sport. They will then search for their basic needs (accommodation, dining options) on the budget end in areas near to the diving sites.

In lieu of traditional database forms or views, customers will access the database via a web interface based on HTML and Cold Fusion () . The forms, reports and queries developed for the database are primarily for data entry and maintenance by the database developers. Some of the queries and reports also dynamically generate pre-formed, or 'stock', guidebooks for the user who simply wants quick access to a guide and is interested in purchasing one pre-created by TraveLite. For example, we have a query that creates a kid friendly guide to San Francisco and includes all the items that are marked as of special interest to children or make special arrangements to appeal to parents with children in tow. The queries will dynamically generate the guidebook thus ensuring that the content is the most up-to-date and current available in the database.

Resolving physical address

We determined that locating address information in a table of its own would serve several purposes. Providing a central, linked table for address/location data (for restaurant, accommodations, etc.) handles the problem of multiple businesses occupying the same physical space (for example, a hotel also has a restaurant). This also improves scalability of functionality/features provided in future iterations of the product, for example, geo-referencing. On this last point, by providing a single table for location in the database, TraveLite can easily add a field to support longitude and latitude information and then index this table for easy searching when used on a PDA linked to a GPS unit.

Resolving relationships between guidebooks and content

After some discussion and a consultation, we determined that the simplest way to capture and store each item chosen for each guide by individual users was to create a join table for each content table over which a query could be run. This table joins the primary key of each chosen item with the guidebook to which it belongs. In other words, when a user creates a guidebook, a new row is created in the Guidebook table with a primary key. When an item from, for example, Restaurants is chosen for that particular guide, the primary key for that restaurant and the primary key for the guidebook are both joined in table RestGuideJoin. Individual join tables exist for each content entity in the database, allowing the database to reconstruct a particular guide on-the-fly.

In this stage of the database development, we have focused on building the database content and developing the associated tables to enable searching on the features using the web interface.

The current version of our database is changed from the original and midterm structures. We have developed a better depth of features for describing Restaurants, for example, by budget and ratings (also to be applied across accommodations and transportation), meal, and cuisine.

For the prototype of this system, we are using content provided by Lonely Planet Publications, however we do conceive of this as scalable to include other travel content providers such as, for example, Fodor's and Frommers. Therefore we have now incorporated a new table to handle tracking the content and where the particular content is derived. This table provides columns for Content Provider ID, C.P. Name, Contact information, Royalty Information, Terms of Agreement and Description, a generalized description of the company. This will enable us to track our relationship to the content provider. We have also added a field to all the tables containing derived content, for example, Restaurants, City, Region, etc.

In this version of the database we have also further developed the features for accommodations, attractions, shopping and activities in much the same way that we expanded the descriptive metadata for the restaurants. For example, the attributes we've already provided for restaurants are cuisine, budget, neighborhood, meal, etc. Through an initial focus group, we determined that for many of these the primary metadata of interest were budget, neighborhood, hours of operation, etc. We also realized that many of these should be grouped by special interests to enable, for example, travelers with children to determine which attractions and activities are especially kid friendly. See table relationship diagram.

As we continue to develop our business model, we decided that, in order to create a practical and viable venture, we should also pitch TraveLite as a service to publishers as well as consumers. In creating the opportunity to partner with publishers, we can mitigate fears that we are cutting into their business. Instead, we will offer to digitize and database their content for a fee; sell it to interested consumers with a portion of revenue going back to publishers as royalty payments; and offer publishers direct access to the content to update as they gather fresh information and new content. This content management side of the application will require considerable development as all publishers have different structures for organizing travel information and differing metadata schema. We also need to develop an extranet for publishers, preferably web-based, that will enable them to access and update the content.

Further, we also need to revisit our current method of storing introductory information on the city, region and country. We need to conduct further user tests and needs assessment to determine the level of granularity required for this type of content. Are users expecting to read through this information pre-trip or would like to have it available for reference on the road? Should we pre-package a certain amount of introductory material based on geographic region (city, region, country) and simply include it as the basic part of the package? If we expect the user to download this information for use on a PDA, do we want to provide long descriptive passages on health information? Or should we break the information down to simply the important elements and supply this as one chunk of text? We will need to work through these questions with potential users to determine the answers.

As we continue to develop our application, we expect this database to go through further iterations. We hope that through further user testing and continued exploration of the needs and requirements users will have for such a system, to develop and expand our metadata to further enable them to create a guide especially tailored for their needs.