Ian Finch and Eleanor
Small
Connect Centre
Department of Computer
Science
University of Liverpool
Liverpool
L69 3BX
United Kingdom
E-mail: ian@csc.liv.ac.uk
Tel: +44 151 794
8271
Fax: +44 151 794
3715
INTRODUCTION
Although there is a large amount of geographic information available on the World Wide Web, it is extremely difficult for a user to locate the data they need. Typically they must take one of the following approaches:
This paper describes a method to combat this problem, using `information brokers' which store the metadata about geographic information on the Web. Using a graphical user interface (GUI), coded as a Java applet and embedded in a Web page, the user enters into a conversation with one or more brokers to locate information of interest.
The power of this approach arises from the fact that the information brokers (which have been coded in Perl in the prototype system) and the GUI speak a common language (the Knowledge Query and Manipulation Language; KQML) and can therefore easily exchange information. Furthermore they share a common vocabulary (or ontology) which ensures that when they refer to some entity (for example a map) during a conversation, they both have the same understanding of what that entity is and how it can be manipulated.
A method has also been developed for allowing the information brokers to gather their metadata from the Web and this too will be described.
FROM METADATA TO A COMMON LANGUAGE
As mentioned in the introduction, apart from asking a person where to obtain information, there are two main methods for locating geographic information on the Web; using a search engine or surfing in appropriate areas of the Web. The major problem with both of these approaches is the same; they rely somewhat on luck. With a search engine, the user hopes that they have chosen the correct keywords to search with. If a suitable Web page exists, it is also a requirement that the search engine knows of that page's existence and has `up to date' knowledge of its contents. With the surfing approach, luck plays an even greater role, with the user only finding the desired information if they happen to follow the correct set of links.
Thus, in the current situation, a person seeking geographic information may spend a considerable amount of time searching the Web and may not find the best source of data for their requirements (or indeed any useful information at all).
The underlying problem is a lack of metadata associated with the geographic information on the Web. It must also be noted that this metadata offers no advantages unless a way of manipulating it is also devised. This then allows any agents (such as the GUI and the information brokers) to communicate with each other in the most efficient way. The system described in this paper defines five levels of information, each layered on top of the other. These are:
Metadata is the information about this geographic information. Continuing with the map example, this would contain the location and extent of the area to which the map refers, together with information about the projection used for the map.
The vocabulary (or ontology) is the glue which enables the various agents (brokers and GUI) to communicate. Just as for human communication, it is essential that all participants mean the same thing for each word they use. Each word in the vocabulary will therefore be known by each agent and there will be a single definition of its meaning. The word `map' will thus refer to an image, together with metadata giving its location, extent and projection. Note that both the image and its metadata must be present for some entity to be a `map'. Thus, if an image is clearly a map to a human, but has no metadata associated with it, then it cannot be a map as far as the agents are concerned. Conversely, an image may not appear to be a map to a human, but as long as it has the correct metadata associated with it, then the agents will consider it to be a map.
Moving on from the vocabulary, it is necessary to create rules which specify how the words from the vocabulary can be combined to create valid requests and answers. These requests and answers (or sentences) make it much easier for the agents to understand each other. The rules restrict the infinite number of combinations of words to a very small set.
Finally, to allow exchanges between agents to take place easily, it is necessary to have rules governing how sentences can be combined. These rules allow standardisation of the conversations between agents. For example one valid conversation may be a request for information from one agent followed by a rejection of the request by another agent.
To clarify these levels of information and their relationship with each other, the following section examines how the types of information were represented in the prototype system, using the Knowledge Query and Manipulation Language.
THE KNOWLEDGE QUERY AND MANIPULATION LANGUAGE
The Knowledge Query and Manipulation Language (KQML) was developed by DARPA to allow agents to exchange information in a standard manner. It has been used by a number of researchers in the fields of Artificial Intelligence and Distributed Systems, and has proved to be both powerful and versatile. It must, however, also be noted that more recent information interchange protocols have been developed, notably CORBA.
The basic idea behind KQML is that agents send each other `performatives'; instructions to perform some operation (such as evaluating an expression and sending back the result). These performatives are encoded as lisp expressions for easy parsing, and sent as simple ASCII strings. A performative will consist of a keyword indicating the type of performative it is (an `evaluate' performative, for example) and then a series of keys and values indicating the language (or protocol) which is to be used, the ontology to use and the actual content of the performative (which in the case of the `evaluate' performative is the expression to be evaluated). As an example, one agent might send the following performative to another agent asking it to perform an addition:
(evaluate :language arithmetic :ontology general :content "1 + 7")This can now be tied into the levels of information described above, beginning with the data level. Since all data must be available on the Web, each piece of data can be uniquely described by its Web address (that is, its URL).
Metadata must then be associated with this data. The actual method for implementing this would be up to each agent in the system. There is no need to standardise this across the system, provided that each agent has the appropriate metadata available for it to use or pass on. This leads on to the vocabulary (or ontology) level.
In order that the agents can communicate effectively, they need to share a vocabulary, knowing, for example, the metadata that is associated with a satellite image. Thus, one agent (the user's Web browser, for example) can request a map from another agent (an information broker, maybe), confident of obtaining the correct response. As an example, consider the map. In the system discussed here, a map is an image which can be manipulated by the user, allowing points and areas to be specified. Thus, the user could call up a map of Europe, draw a box around the British Isles and then zoom in on this area, perhaps automatically loading a new map with more detail (rather than simply scaling the area in question). It is obvious, therefore, that a map is more than a simple image; there must be associated metadata linking the pixels in the image to a geographic location reference system. So, within our ontology, a map is an image, together with metadata which allows it to be linked to the real-world area it represents. A simple scan of a page from an atlas, with no associated metadata, is therefore not a 'map', but just an 'image'. Conversely, a radar image which has the appropriate metadata associated with it, is a 'map'. The vocabulary as a whole is given a name (for example `gis') and this can then be used as the value for the 'ontology' key in the performative, to ensure that a common vocabulary is being used.
(evaluate :language gisLang :ontology gis :content (find :type map :area liverpool))Note the use of the language key to specify the language being used. This is similar to the ontology, but instead of defining the meaning of words (such as `map' and `liverpool' in the above example), it defines the meaning of actions (such as `find' above).
The final level of information is the `conversation', which consists of a sequence of sentences between two or more agents, according to a set of rules. In the system described here, one agent sends an `evaluate' sentence. This can only be responded to using one of four performatives; sorry, error, later or reply. The `sorry' response means that this is a valid sentence, but the second agent is unable to fulfil the request. The `error' response means that there is something wrong with the performative. The `reply' response means that the evaluation has been successful and here is the result. The `later' response means that the evaluation can be performed, but the result will not be available immediately. The `later' response will then cause the first agent to respond indicating whether it wishes to `callback' to retrieve the result at some later time, `subscribe' (let the second agent send the result when it evaluates it) or `discard' the result (in which case the second agent can abort its evaluation). In this way, a set of rules can be constructed, specifying whether a given conversation is legal or not.
Thus, using KQML, the five levels of information described in the previous section can be represented in a computer-understandable form.
THE PROTOTYPE SYSTEM
As discussed above, the prototype system uses a structured communication protocol, consisting of five levels of information; from the actual geographic information to the rules for conversation. The system consists of three types of agent; the user's GUI (implemented as a Java applet running in a Web browser), the information brokers (implemented as servers written in Perl) and the Web servers (not implemented as part of the prototype system).
An example interaction will illustrate the operation of the system. Suppose that the user wishes to obtain some radar imagery of Liverpool. The first step is for the user to open the Web page containing the Java GUI. This will automatically connect them to their default information broker. The GUI begins by requesting from that broker the most general map they possess (usually a map of the world). This is sent to the GUI, which then displays it for the user. The user can now use a `rubber rectangle' to select portions of the map and zoom in for more detail. Each time the zoom button is pressed, the GUI asks the broker for more detail. If the broker knows of a more detailed map, it retrieves it for the user and that is displayed. Otherwise, the GUI simply scales up the appropriate portion of the map which it already possesses. Notice that the GUI must have the more detailed map to display immediately (depending, of course, on the speed of the network/modem). Thus, if the broker send back the `later' response (discussed in the previous section), which means that the information will be available, but not immediately, the GUI will discard that request and scale the current map (not informing the user of this).
CONCLUSIONS
This approach offers many advantages over other ways of locating geographic information on the Web: