We applied the Heracles system to the travel domain, integrating the information sources that are needed for travel planning into a single application, the Travel Assistant. This real-time application can plan a trip in a semi-automated fashion, gathering live data from web sources and other programs.
When the user initiates a new trip, the system extracts a list of people from his Outlook calendar that he has scheduled meetings with in the next two months. When the user selects whom to meet with, the system retrieves the person's company name and the address of the company from the Outlook Address Book. The company address is used as the default destination of the trip. The starting address is retrieved from the user's personal profile. The system also retrieves the dates, start time, and end time of the meeting from the Outlook calendar. As soon as the dates of the meeting and the address of the destination are available, the system retrieves the weather forecast from the Yahoo! weather site (weather.yahoo.com).
Figure 1 shows the selection of the meeting in the Travel Assistant. There is a set of boxes showing values, which we call slots. A slot holds a current value and a set of possible values, which can be viewed in the pull down list if we click the arrow at the right edge of the slot. For example, there are two slots in the first line: a slot Person and another slot Company Name, holding values Jim Hendler and DARPA, respectively.
Once the system has the details of the meeting, the next step is to determine how to get to the destination. There are three possible modes of transportation: Fly, Drive or Take a Taxi. Each mode has different choices and information, which are organized into groups of slots called templates and then arranged hierarchically into templates and subtemplates. For example, the Fly subtemplate introduces information about the closest airports and available flights, whereas the Drive subtemplate provides maps and driving directions.
The system recommends the transportation mode based on the distance between the origin and destination. The system computes the distance by first geocoding (determining the latitude and longitude) of the origin and destination addresses using the MapBlast Web site (www.mapblast.com). Then, using the geocoded information, a local constraint computes the distance between the two points by applying a distance calculation formula. In our example, the distance between Los Angeles and Washington D.C. is 2,294 miles, so the system recommends that the user Fly.
Once the user confirms that he wants to fly, the system shows the details of the Fly subtemplate (Figure 2). Based on the destination address passed from the top-level template, the system queries the Travelocity Web site (www.travelocity.com) to get airports in the Washington D.C. area ordered by distance. The system recommends DCA (National Airport) because DCA is the closest airport to the meeting location. Once the airports have been selected, the system then queries ITA Software (www.itasoftware.com) to retrieve the flights from LAX to DCA.
The interface informs the user of its processing status using the colors shown in Figure 2.A slot can appear in four different colors as its status changes. A slot is initially black when it has only the default set of values. A slot becomes blue if it is the user who entered a value for it. While the system is computing a possible value for a slot, it turns red, and once the system produces a suggested value it changes color to green.
As shown in Figure 2, when the user changes DCA (National) to IAD (Washington Dulles), the arrival airport slot becomes blue because it is the user's choice. The system starts to get a new set of flights from LAX to IAD using the ITA Software site. The slots holding the flight information turn red until the new data is returned from. When the system finally recommends the new values for the slots, they become green.
The user can always override what the system suggests. The system initially finds flights for any airlines, but if the user fixes the airline to be Continental, for instance, the Travel Assistant will present only the Continental flights. The user's choices also serve to narrow the possible options.
The Travel Assistant helps the user evaluate tradeoffs that involve many different pieces of information and calculations. For example, Figure 3 illustrates how the system recommends the mode of transportation to the departure airport. This recommendation is made by comparing the cost of parking a car at the airport for the duration of the trip to the cost of taking a taxi to and from the airport. The system computes the cost of parking by retrieving the available airport parking lots and their daily rates from the AirWise site (www.airwise.com), determining the number of days the car will be parked based on scheduled meetings, and then calculating the total cost of parking. Similarly, the system computes the taxi fare by retrieving the distance between the user's home address and the departure airport from the Yahoo! Map site (maps.yahoo.com), retrieving the taxi fare from the WashingtonPost Taxi Fare site (www.washingtonpost.com), and then calculating the total cost. In the figure, the system recommends taking a taxi since the taxi fare is only $23.00, while the cost of parking would be $64.00 using the Terminal Parking lot. When the user changes the selected parking lot to Economy Lot B, which is $5 per day, this makes the total parking rate cheaper than the taxi fare, so the system changes the recommendation to Drive.
The system actively maintains the dependencies among slots so that changes to earlier decisions are propagated throughout the travel planning process. For example, Figure 4 shows how the Taxi template is affected when the user changes departure airport in the higher-level Fly template. In the original plan (top template of Figure 2), the departure time from the origin airport (LAX, Los Angeles International) is 6:30 AM. The user's preference is to arrive an hour before the departure time, which means that he would need to arrive at LAX by 5:30 AM. Since according to Mapblast driving takes 22 minutes from his home to LAX, the system recommends that he leaves home at 5:08 AM. When the user changes the departure airport from LAX (Los Angeles International) to LGB (Long Beach), the system retrieves a new map and recomputes the driving time to the Long Beach airport. Changing the departure airport also results in a different set of flights. The recommended flight leaving from LGB departs at 6:55 AM, and the driving takes 34 minutes from his home to LGB. In order to arrive at LGB by 5:55 AM, the system now suggests he leave home at 5:21 AM.
The Travel Assistant allows the user to control the various tradeoffs between the many choices that need to be made in planning a trip. For example, when selecting the hotel, the user can specify that he wants the cheapest one possible, the one closest to the airport, or the one that is closest to their meeting. Figure 5 shows the expansion of the Hotel subtemplate. The system retrieves the hotel, address, and fax information from the ITN site (www.itn.com) and the map from the airport to the hotel from the Yahoo! Map site. In the figure, the system initially suggests the hotel that is closest to the meeting and when the user changes that to the one closest to the airport, the system recomputes the set of hotels (ordered by distance), suggests the closest one, showing the address, price, and maps.