The backend of the system is primarily a database of bus schedules and routing information provided by the Port Authority. The Port Authority system consists of 15,218 stops (although some stops have multiple names). There are 2423 routes (including variations of routes according to time of day or week).
Although we have the database tables that the Port Authority uses internally, we had to make several alterations in how the data is stored to make it possible to find the information we need to provide to the user because the original structure was not suited for retrieving time information. Also, the Port Authority data often contains abbreviations for stops -- sometimes several different abbreviations for the same stop. These abbreviations were converted to a consistent form that is more suitable for speech input and output. To more easily match stop names, we chose to fully expand all abbreviations, since that allows us to say that ``5th Ave'', ``5th Ave.'', and ``Fifth Avenue'' all reference the same street, but maintains its distinction with ``5th Street''.
Stops can be specified in one of three ways: the nearest intersection to the stop (``Forbes [Avenue] at Murray [Avenue]''), a neighborhood (``Oakland''), or a landmark or other point of interest (``Pittsburgh International Airport'', ``Waterworks Mall''). Of these, only the first are stored in the database. Thus we map neighborhoods and landmarks to intersections. However, both neighborhoods and landmarks can refer to several different stops. We need to be able to denote stops as departure or arrival points, and also identify which stop in a list is the one being referred to, given the context of the rest of the query. For example, not all stops within a neighborhood are on every route that goes through that neighborhood. At this point, this is handled by a ``Stop Matcher'' module that creates a mapping between a neighborhood or landmark and the appropriate stop. It will currently only return a single stop, although it will eventually need to return multiple stops.
The backend receives query information from the dialog manager, which consists of the type of query, information identifying the departure and arrival points, possibly a specific route, and time information. The departure and arrival information is passed through the Stop Matcher module to identify which stops to search for in the database. After executing one or more lookups to retrieve information from the database, the module then responds to the dialog manager with a result, which either contains the answer to the user's query, or a failure code identifying a problem (for example, asking for a time for a bus going between two stops that are not connected by any bus route).