Developing An Ontology for the Meteorological Forecasting Process John Bally* Tal Boneh** Ann E. Nicholson*** Kevin B. Korb**** *Weather Forecasting Group, Bureau of Meteorology Research Centre, Melbourne, Australia Email:
[email protected] School of Computer Science and Software Engineering Monash University, 3800, Victoria, Australia **Email:
[email protected] ***Email:
[email protected] ****Email:
[email protected]
Abstract Decision support systems for weather forecasting have yet to tackle the key issues in formulating forecast policy, focussing instead on data presentation. Here we describe a method for eliciting forecasting information and outline a forecast ontology for codifying that information as a data management tool. The completed ontology will provide key ingredients for designing future decision support systems for actually negotiating, building and presenting forecast policies. Keywords Knowledge management, knowledge engineering, ontology, weather forecasting, decision support systems.
1. INTRODUCTION Existing decision support systems (DSSs) for weather forecasting focus on presenting data to the forecaster and on helping the forecaster to make some key decisions. The larger part of the data analysis and the assembly of key decisions into a forecast policy occurs in the minds of the forecasters. This is usually transformed into finished forecast products on a simple text editor. This paper reports on a project aimed at developing new technology for meteorological decision support. The early phases of the project focus on understanding the existing forecasting process and its associated technology. A major part of this effort involves developing a description of the ontology of forecasting, that is the concepts required for formulating and presenting meteorological forecasts and their interrelationships. This ontology should capture the most obvious and strongest relationships in the domain. In order to so model our domain knowledge we had to develop a methodology for knowledge elicitation to suit the special requirements of the domain, which we describe below. We begin by describing the existing forecasting process and its limitations. We then describe the elicitation process we have initiated for identifying forecasting concepts and procedures. We describe the major features of the ontology we are developing in consequence, including examples of each main type of representation. Finally, we conclude with ideas for how such an ontology, completed, can be applied in practical decision support roles.
2. THE METEOROLOGICAL FORECASTING PROCESS Operational weather forecasting is done in much the same way around the world. In Australia, the Bureau of Meteorology (BOM) is a federal organisation consisting of a head office and seven regional offices, corresponding to the different states. The head office produces some national forecast products and provides support for the regional offices. The regional offices perform the forecasting process independently and produce a range of products for their geographic area of responsibility.
70
Decision Support in an Uncertain and Complex World: The IFIP TC8/WG8.3 International Conference 2004 2.1 Weather Forecast Policy and its formation The traditional approach to the forecasting process is product-based, i.e., the end product (city forecast, wildfire forecast, coastal waters forecast, etc.) is the focus of the process. In this approach each forecaster is responsible for a number of products. Each forecast product is a package of weather information available to clients. The content, format and structure of forecast products are specified by a product definition. The product definition determines the weather elements that should be included in the product, the attributes of the product and their values. Almost any weather product includes weather elements such as temperature, wind, rainfall and clouds. The attributes are the time period and geographic area the product will cover, specificity and language used for each weather element, mode of delivery, etc. For example, two different product definitions that include the weather element rainfall might determine that: 1.
The forecast is for the next 6 to 24 hrs, the forecast type is public weather (i.e., general purpose forecast for the public), the geographic area is the whole metro area, the description should include one of the categories {light/moderate/heavy} and the type of rain {rain/drizzle/shower} and the mode of delivery is the radio. A real product example for the town of Strahan on the west coast of Tasmania for Tuesday 23/12/03 is: STRAHAN: A light shower or two, clearing this afternoon. Cool with moderate southwesterly winds.
2.
The forecast is for the next day, type is fire weather (i.e., for fighting forest fires), geographic area is a specific location, the description should be given in mm, no type of rain, and mode of delivery is the fax and the internet. Another real product example is: Fire Weather Forecast valid for Tuesday 23/12/03 Location rain(mm) Temp Humidity Wind Direction / Speed Strahan Apt 3.0 18 C 64% WSW 20km/hr
Fire Danger Low
A weather forecast policy is used to construct a consistent set of forecast products that will fulfil the requirements of the clients. The forecast policy comprises past, present and future information about weather objects (highs, lows, thunderstorms, fronts, troughs etc), areas (of fog, cloud, rain, showers etc) and meteorological values at key points (wind speed and direction, temperature, rainfall, cloud etc). The forecasters formulate a mental model (i.e., a conceptual causal model (Johnson-Laird 1988)) of the relevant weather processes, providing them with parts of a forecast policy, and then generate their forecast products, with reference to each product’s definition. This transformation of weather data into a forecast policy via the mental model by which the forecasters conceptualise the weather (Hoffman, Robert R. 1991; Trafton et al. 2000) is the core of the forecasting process. The forecasters’ mental models are generated by interaction between the forecasters. These regular group discussions aim to ensure that all of the available meteorological expertise is incorporated into the forecast policy and that all the members of the team have a consistent understanding of it and the weather situation. Some aspects of forecast policy are recorded on hand drawn diagrams and written policy statements. The current computing infrastructure supporting forecast operations in Australia stores forecast products and data, but not weather policies, which are mostly held in the forecasters' memory. The flow of information through the forecast process, depicted in Figure 1, begins with weather data, which includes surface and upper atmospheric observations, the output of computational numerical weather prediction (NWP) models, satellite and radar images. Various analyses and diagnostics are generated from this raw data and serve as important inputs into the forecast process. The transformation of weather data into forecast policy occurs by applying and combining, mostly manually, a range of forecast techniques, which are then stored in the forecaster’s mental model, with some variation between forecasters, offices and situations. There is no documentation as to which techniques are applied, how they may be grouped and the order of their application – such information is one of the outcomes of this research (see §5). Significantly, the forecasting techniques are applied within the context of an established current forecast policy, which acts as the starting point for the interpretation of new information. As a consequence, the forecast policy usually evolves conservatively, helping to maintain consistency. A range of forecast products is created from the policy, generally by typing text into pro-formae using a specialised text editor. Forecasters report that the act of composing text forecasts helps to crystallise details of the forecast policy in their minds. So, the act of forecast product creation also modifies the forecast policy. Creating products also draws on a body of unwritten knowledge about product requirements, preferred terminology, location information and specific client needs. New forecasters normally acquire this unwritten knowledge in their first year by working with more experienced staff.
71
Developing An Ontology for the Meteorological Forecasting Process
Weather Data: Model Output, Satellite Images, Observations, Manual Analysis, etc Mostly pictures
Analyse and Forecast Weather first guess
Mostly concepts Forecast Policy (Mostly Memory)
fine tune
Mostly memory
Write Forecast
first guess
Mostly typing
Fixed Data (Locations, product details, some local knowledge etc) Mostly Memory
Forecast Product
Figure 1: Flow of information through the forecast process. Dark areas represent physical (or computer) processes or data; light areas are human processes or data. Ellipses are processes; rectangles are data. 2.2 Limitations of the current approach The current approach to forecast policy formation suffers both from the manual application of much of the forecasting process and the lack of formal documentation for most components. Although forecasters discuss the forecast policy, most of the detail is “stored” as the forecaster’s individual mental model, so each version is a little different. Moreover, the forecast policy is refined as a part of the product forecast writing process and thus evolves as each product is written. The result is a set of forecast products that are not fully consistent with each other. The current (mostly manual) approach is time consuming. Each additional product request, a forecaster needs to spend an additional 5 to 15 minutes manually creating the product. This is critical in a crisis situation with unusually heavy workloads, when time constraints mean that some products will be issued late or not at all. Moreover, since most products are unstructured natural language text, they cannot be "understood" by computer systems for automatic verification or re-use. The time required for people to acquire the largely undocumented body of local knowledge (the "fixed" data of Figure 1) needed for the creation of weather products limits the effectiveness of forecasters transferred to a new region for many weeks and possibly months. This can compromise the utility of short term inter-regional transfers during crisis events, such as severe bushfires. The lack of documentation also is a barrier to transforming the process by adding computational support. 2.3 A modern approach to the forecasting process. The Forecast Streamlining and Enhancement Project (FSEP) (Ryan 2003) is a major modernisation project within the BOM. FSEP seeks to improve the quality, quantity, consistency and responsiveness of weather products and services. It takes a fundamentally different, element-based, approach to the forecasting process (LeFebvre 1995), focussing on weather elements (temperature, rainfall, etc.) and their attributes. The element attributes are the set of all attributes and their values from all the products that contain the element; the forecast process attributes are all possible elements and possible element attributes. In this approach, the forecaster is responsible for at least one, but generally many, weather elements. The forecaster forms the forecast policy with regard to the element and then reports it according to the element’s attributes. In this
72
Decision Support in an Uncertain and Complex World: The IFIP TC8/WG8.3 International Conference 2004 approach every product is made of a combination of existing reports. The element-based approach is more modular and structured, enabling the automatic generation of products, and therefore the easy addition of new products without increasing forecaster workload. Since the element-based approach is focused on generating a limited number of weather elements, it provides a structure to the forecasting process and a good basis for documentation and automation with new DSSs. These, in turn, can help in overcoming the limitations of the current approach. A prerequisite for the development of any new system aimed at improving an existing one is to understand and analyse the current system. There is a need to audit the current methods, strategies, ways of thinking and working, and the use of information, in order to obtain a broad and accurate picture of the current approach, its advantages and disadvantages. The auditing process, in turn, requires that information and knowledge should be in a form that enables their sharing and reusing. This means that it requires a comprehensive approach to knowledge management.
3. KNOWLEDGE MANAGEMENT Knowledge management is the process through which organisations take advantage of their knowledge assets by sharing and reusing these assets, thereby enhancing employees’ retention rates, eliminating redundant or unnecessary processes, streamlining operations and response time, and improving customer service (Santosus & Surmacz 2001). One of the methods that have been developed as a means to share and reuse knowledge is the explicit development of a domain ontology (Benjamins, Fensel & Perez 1998; Gruber 1993). In knowledge engineering an ontology provides a set of concepts that identify the key objects in the domain and the relationships and constraints between them. The ontology can be used to share knowledge between people (e.g., domain experts and knowledge engineers) and between applications and programs (Chandrasekaran, Josephson & Benjamins 1999; Gruber 1993). Depending on their intended applications, ontologies can vary greatly in the formality of the representation; for human communication purposes informal representation is preferred but for automatic processes a formal representation may be necessary (Uschold & Jasper 1999). Ontologies can be highly informal e.g. a glossary of terms or a collection of names of categories such as WWW indexers (Labrou & Finin 1999), structured informal (Helsper & van der Gaag 2002; Uschold et al. 1998), semi formal (Uschold et al. 1998) or rigorously formal (e.g. TOVE (Gruninger & Fox 1995)). Ontologies can also include more than one level of formality of representation. For example, the Enterprise ontology, for historical reasons, has an informal form, which was later used as the specification for the formal encoding (Uschold et al. 1998). An informal form can be used for documentation purposes (Uschold & Jasper 1999) or to support the development process (Blazquez et al. 1998). We employ a methodology called METHONTOLOGY for ontology development (Fernandez, Gomez-Perez & Juristo 1997), found to be the most well-defined methodology published (Fernandez 1999). This methodology advocates the use of structured informal representation (called the intermediate representation) to support the development of the ontology. METHONTOLOGY distinguishes between different steps in the ontology development, such as: knowledge acquisition, conceptualisation (informal representation), implementation (formal representation) and evaluation. To apply this methodology to our domain we add an explicit stage of highly informal representation and divide the process of building the ontology into four stages: 1.
Knowledge elicitation: Knowledge for the ontology is collected and documented.
2.
Highly informal representation. Knowledge is analysed and structured. A preliminary ontology is sketched, a glossary of terms is defined, and tables are constructed using natural language. This stage is important so that the ontology can be intuitively communicated to many domain experts for validation, in a workshop timeframe, to reach a consensus and to support system acceptance and maintenance.
3.
A structured informal representation: This involves the identification of domain terms as concepts, instances, verbs and properties, the construction of graphs to represent relationships between terms, and different tables to define different relationships and constraints. This stage is important as it allows development team members to communicate the ontology and reach agreements on details at the knowledge level, before encoding it (Gomez-Perez, Fernandez & de Vicente 1996).
4.
A formal representation: The ontology is encoded in a formal knowledge representation language that is machine computable. This stage is important so that the ontology can be unambiguously interpreted by software. Markup languages have already been used to formally represent meteorological ontologies, for example XML in (Hong-Kong-Observatory 2003; Kelly 2003) and RDF/DAML in (AgentCities 2003).
73
Developing An Ontology for the Meteorological Forecasting Process It is important to note that the process iterates over these tasks and that each task can modify the understanding of products of other stages, leading to further iterations. In this paper we describe the execution of stages 1 and 2 to build an ontology for the meteorological forecasting process. Stage 3 is based on stage 2, and enables the use of software tools such as ODE (Blazquez et al. 1998) or WebODE (Arpirez et al. 2001), which are based on METHONTOLOGY, for automatic encoding of the ontology into different formal representation. In the area of learning organisational behaviour and decision making, a large number of knowledge elicitation methods have been described (Hoffman et al. 1995; Langan-Fox, Code & Langfield-Smith 2000; Schraagen et al. 2000). Hoffman (Hoffman et al. 1995) distinguishes between interview methods and contrived methods. Interview methods, either individual or group interviews, are useful when experts in a domain have differing areas of specialisation or when the reliability of knowledge and reasoning is to be assessed by more than one expert. Contrived methods deliberately modify a familiar task and are found to be effective in revealing experts’ knowledge and reasoning. However, there has been little discussion about a general approach for a complete analysis of a task or about which methods would be appropriate for particular conditions. This largely depends on the type of task being analysed, the purpose of the analysis, and the resources available for the analysis, which include domain experts’ time, and the type of personnel available to do the analysis (Langan-Fox, Code & Langfield-Smith 2000; Schraagen et al. 2000).
4. ELICITING METEOROLOGICAL FORECASTING KNOWLEDGE 4.1 Our methodology Our preliminary approach is to elicit the forecasting knowledge through a series of workshops at the different regional forecasting offices across Australia. Targeting the regional offices allows us to accommodate the differences in forecast process that arise under the widely differing climates across Australia; we also hope to reach a consensus for those parts of the forecast process common to all regions. The elicitation workshops are divided into two three-hour sessions over two days and are facilitated by two people, a domain expert and a knowledge management expert. Their mix of skills has two major benefits: (1) it reduces the preliminary stage, in which the knowledge management experts learn about the domain and domain experts become familiar with knowledge management; (2) the data extraction from forecasters can probe beyond the trivial, be done in a reasonable timeframe and in a way that respects the scope and depth of knowledge of practicing forecasters. The framework for the elicitation was set by the FSEP element-based approach, which decomposes the domain knowledge into its weather elements. This has enabled us to focus on a limited number of weather elements, specifically rainfall, temperature and wind, which we elicit separately. The ontologies constructed for each weather element will be merged into a combined comprehensive ontology for the forecasting process. Throughout this paper we will present examples for the rainfall weather element. The rainfall forecast service aims to answer the questions: Will it rain? If it will, where, when, how much and what type of "rain" will fall? How certain are we about the rainfall forecast today? An example from Monday the 17th of November 2003 is: CENTRAL WEST DISTRICT: Isolated showers developing in coastal parts and increasing in the south towards evening. Westerly winds, freshening.
Our ontology is intended to capture multiple aspects of the forecast process, namely the process attributes, goals, sub-goals and methods, all of the available forecast techniques, the information and sub-techniques they contain and data sources they require. It was therefore considered important to represent the knowledge from two perspectives: (1) procedural (goals and methods), so that the representation encodes how to perform a particular task; and (2) declarative (concepts and their relationships), so that knowledge can be manipulated, decomposed and analysed. We use a combination of knowledge elicitation methods to suit the complexity of the domain, the complexity of the organisation and time constraints on the availability of the domain experts, the forecasters. The first part of the workshop was designed to capture procedural knowledge (i.e., goals and methods). Its purpose was to identify procedural information about the process, namely what are the steps taken and in what order are they executed. We used the method of individual interviews. For example, the moderator asked workshop participants to choose one of the following tasks: (1) Remember the last time you forecast rain; (2) You need to forecast rain now, what do you do? (3) Recall an interesting time you forecast rain. Key points were elicited relating to the following: What was the product requirement? What techniques were actually used? What information was sought? What data source was consulted? Elicited information was captured on a whiteboard. The second part of the workshop was designed to capture declarative knowledge. Here, the purpose was to identify new concepts (techniques, information and data sources). The discussion was no longer about specific events/products and thus many new concepts, that were not relevant to the cases described earlier, were
74
Decision Support in an Uncertain and Complex World: The IFIP TC8/WG8.3 International Conference 2004 identified. This part focussed on capturing all the concepts involved in the forecast process and was designed as a group discussion, starting with adding points from the whiteboard to a process description template. By requiring the participants to focus on techniques rather than performing their usual forecasting tasks, we were employing a contrived method within the group interview. The concepts that were written on the whiteboard were typed into the computer and categorised according to the different classifications in a template that had been prepared in advance by the facilitators. The different classes were discussed and new information added. The third part of the workshop was designed to give the forecasters an introduction to ranking methods and some examples. The purpose here was to ensure they understood the requirements and the motivation for the ranking task, in order to obtain their participation in the next part of the elicitation process, which will be done by correspondence. Forecasters were presented with examples of elicited concepts, which they ranked in a scale of 0 to 10 according to usability and similarity. They were asked to rank objects according to how usable, similar, and important the objects were with regard to a specific goal. After all the workshops are completed and the resultant data analysed, questionnaires will be sent to the regional forecasters to obtain the different rankings. This information will be used to assess attitudes towards different techniques and tools and to measure how close or different these attitudes are between forecasters and regional offices. In addition, the results of Stage 1 (the highly informal representation of the data representation) will be sent to all BOM forecasters for review, as part of the iterative ontology construction and for achieving consensus. 4.2 Elicited Data In the first part of the workshop it became clear that the element-based approach was challenging to the forecasters; because they were used to the traditional product-based approach, they found it difficult to describe the forecasting process of the specific elements. The moderator (domain expert) then changed tactics and asked them to specify the products that contain the specific element. The forecasters then provided a list of products and found it easier to describe the process of forecasting the element with regard to one of these products (e.g., “For the department of conservation and land management…. if the forecast is for the next 0 to 6 hrs (product), I look at the frontal system and reach a conclusion about the amount of rainfall…”). When the description was too general the
moderator asked the interviewee to specify what techniques had been used. This part of the workshop yielded descriptive data such as this verbal response from a participant: “If the forecasting is for more than 24 hrs ahead I use the global models and compare them and reach a conclusion…you look at the moisture trace, … you look at the models, and you may do ensemble of models, this can be averaging over all available models or choosing the worst-case scenario…someone called and wanted to know if it was going to rain between 10.00-12.00am at his party and if ‘yes’, how heavy it was going to be”.
In the second part of workshop the information obtained from the individual interviews was organised through group discussion, according to two main categories: 1.
Attributes of the process: included the general characteristics of the process. It documented information on timescales, spatial requirements, specificity and uncertainty. For example, under specificity the forecasters included: light / moderate / heavy, moving to …. 1−5; 5−10; 15+ and rain / drizzle / showers.
2.
Techniques: included a hierarchical description/breakdown of forecasting techniques. At the current stage of the analysis, goals, tools, methods and data sources were still mixed together.
This part of the workshop was also found to be useful in forming and refining consensus terminology. For example, one of the terms prepared in advance by the facilitators was “Identification of Physical Processes”. The forecasters did not feel comfortable with this term and preferred the term “Synoptic Analysis”. The top level of forecasting techniques elicited was: Synoptic analysis: the study of a collection of weather observations taken over a large area at a given moment, aimed at diagnosing current state of the atmosphere. Direct and indirect use of NWP: computer models of the atmosphere, based on fluid dynamic and thermodynamic equations, initialised with current observations and integrated forward in time to represent the future state of the atmosphere. Extrapolation from observation: inferring the future weather based on extrapolating current values and trends in the observations. Downscaling: determining the weather in a particular location, by applying small scale perturbations based on local geography and local scale meteorological processes to the larger scale state of the atmosphere. An extract of the raw data for the weather element rainfall, concerned with a portion of the hierarchy stemming from synoptic analysis, is shown in Figure 2. In this section of the forecast process, forecasters are concerned
75
Developing An Ontology for the Meteorological Forecasting Process with estimating the rain producing potential of the larger "synoptic" scale features they have identified previously. A number of factors affect rain producing potential, including the amount of moisture available to the weather system. This moisture may be near the surface of the earth, in the boundary layer (see glossary) or it may be higher up in the atmosphere. Various observation systems (e.g. surface obs, Balloon, WV, and TRMM) can be used to measure meteorological quantities that indicate the amount of moisture available. Various analysis tools (NWP, F160) can help the forecaster infer the amount of moisture available and how effectively it can be converted into rainfall. This extract of raw data is peppered with meteorological jargon and full of condensed meaning, reflecting the way forecasters talk and think about their work. Without expert knowledge and understanding, most of the information it contains cannot be extracted. - Synoptic Analysis o Estimate the rain producing potential moisture availability • boundary layer moisture o how moist surface obs trajectory (in 3D…. isentropic flow) from models o depth from NWP Conceptual models • upper moisture o soundings model • Kenny Balloon F160 • areas of upper moisture o satellite WV, TRMM Existing cloud from IR o Model o RADAR (existing rain) Figure 2: Extract of hierarchical breakdown of forecasting techniques for the rainfall weather element. The third part of the workshop, in which only examples were given, was also found to be useful in identifying/emphasising possible additional constraints on the forecasting process.
5. CONSTRUCTING THE ONTOLOGY Our final ontology will codify the elicited knowledge, representing the declarative and procedural structures we have identified in the data the 3 forms of representation described in §3: highly informal, structured and formal. The highly informal representation includes a glossary, classes of concepts, matrices of relationship between concepts and diagrams to depict procedural knowledge, and is described here. 5.1 Glossary The glossary is the domain vocabulary, containing a list of terms discovered to be important during the elicitation process. The glossary defines each such term. It also provides a description of the relationship between each term and any associated element. Below we provide examples of glossary entries for a number of different kinds of concept, including weather object, weather elements, element attributes, tools and information. Here, we organise glossary terms lexicographically within concept groups. It is anticipated that the glossary, as part of the completed ontology, will be accessed with multiple views and displayed with hyperlinks. Concept Cold Front (Weather Object)
Definition (surface) Boundary between cold and warm air masses, moving towards the warm air mass
Surface dewpoint
The dewpoint temperature at the
Relationships (Rainfall) Associated with 1−12 hrs of rain ahead of the front, bands of heavy showers or thunderstorms; a period of clear weather (1−6 hrs) immediately after the front; a period of showers 2−24 hrs after the front. One way of measuring the moisture at bottom of the
76
Decision Support in an Uncertain and Complex World: The IFIP TC8/WG8.3 International Conference 2004 (Element) Intensity(Attribute ) Analyse surface dewpoint observations (Tool) Boundary layer moisture (Information)
surface of the earth. Rainfall rate
boundary layer. light / moderate / heavy, 1−5mm / 5−10mm / 15mm +
Draw contours of surface dewpoint; relate to analyses of other weather elements; reach conclusions about the weather situation. The amount of water vapour in the boundary layer.
One way of analysing the moisture at bottom of the boundary layer. Source of moisture for the formation of surface based convective clouds. Clouds are more likely to form when moisture levels are high; grow tall and produce heavy rain.
Table 1: Glossary Example 5.2 Procedural Representation In order to analyse the data derived from the individual interviews, we used a content analysis method (Langan-Fox, Code & Langfield-Smith 2000). The descriptive data was divided into utterances and analysed phrase by phrase, with each phrase categorised into a specific coding system. The first analysis was aimed at identifying and categorising the different functions that are undertaken by forecasters. This enabled us to identify the following core functions from which the forecast process is built: •
View, interpret and compare a wide range of data, including surface observations, manual and NWP analyses, NWP forecasts fields, and satellite and radar imagery. The comparison function is sometimes done by overlaying data, but also often by side-to-side comparison, supported by having many data browser windows open simultaneously. The interpretation function is usually done manually with no system support.
•
Choose between many alternative and possibly conflicting solutions to a forecast problem, usually done by comparing information and by evaluating information against a conceptual framework. This is a key forecasting function with little or no explicit system support apart from data display.
•
Correct and adjust objective forecast guidance, done manually as part of the forecast preparation task.
•
Track the motion of small and large scale weather systems. Limited system support exists for this function (e.g., looping and marking functions on displays), but tracking systems is still laborious and imprecise.
•
Co-locate weather systems with geographical features (towns, airports, etc.).
Here is an example of this analysis. Raw Data: “For shorter terms (6 to 24 hrs) you look at the trace moisture, …, you look at the models, and you may do ensemble of models, this can be averaging over all available models or choosing the worst-case scenario, depending on the situation or how conservative the forecaster is and use the analysis of the synoptic situation to modify the models.” (The answer is with regard to the specific location.) Analysis of Data (Function Identification coding): Code (Function) View, interpret, compare Choose Correct and adjust View, interpret, compare Correct and adjust Co-locate
Text you look at the trace moisture, … you look at the models, and you may do ensemble of models, this can be averaging over all available models or choosing the worst-case scenario, depending on the situation or how conservative the forecaster is and use the analysis of the synoptic situation to modify the models The answer is with regard to the specific location
Table 2: Data Analysis (Function Identification Coding) The second analysis was aimed at identifying the different high-level methods that are included in the forecasting process. A method can involve many functions and specifies what functions should be used and how. This analysis enabled us to identify the following procedural structure in the forecasting process. The forecast process for rainfall proceeds quite differently for different timescales. At shorter timescales (0−6 hrs) it is focused heavily on observations of current rainfall and on extrapolation of those observations. At longer ones (over 24 hrs), the focus is choosing the most appropriate guidance system to use as the basis of the forecast. Once chosen, the modification of the guidance is usually limited to correction of the gross bias and some downscaling, incorporating known smaller scale and orographic effects into the forecast policy. At 77
Developing An Ontology for the Meteorological Forecasting Process medium timescales, the forecast process is most complex. It includes a significant amount of detailed synoptic analysis, which sets up the framework on which policy details are hung. Much of the time spent on synoptic analysis is used to analyse the rain producing potential of synoptic features. The results of the synoptic analysis are also used to evaluate and rank the quality of the many objective guidance systems available to the forecaster. Guidance is normally modified by synoptic reasoning, correcting perceived errors in rainfall intensity, duration, timing and type. Downscaling and incorporating known smaller scale and orographic effects are used to fine-tune the forecast for key places and areas of interest. Here is an example of this analysis of the raw data given above. Analysis of Data (Method Identification coding): Code (Method) Time scale Synoptic analysis Choose a guidance Modify guidance Synoptic analysis Modify guidance Downscaling
Text For shorter terms (6 to 24 hrs) you look at the trace moisture, … you look at the models and you may do ensemble of models, this can be averaging over all available models or choosing the worst-case scenario, depending on the situation or how conservative the forecaster and use the analysis of the synoptic situation to modify the models The answer is with regard to the specific location
Table 3: Data Analysis (Method Identification Coding) The results of this second analysis, focussing on the high-level methods, lead to the identification of a new procedural structure in the forecasting process, depicted in Figure 3. This is a generic structure that may vary slightly for different weather elements. Start
Synoptic Analysis M st ca hr w 6 No to 0
Extrapolation from Observation
Short term forecast 6 to 24hr
ed i 24 u m hr te to rm 4+ fo da rec ys as
t
Choose Guidance Choose Guidance Synoptic Analysis
Modify Guidance
Downscaling
Downscaling
Downscaling
Finish
Figure 3: A New Procedural Structure for Forecasting
78
Decision Support in an Uncertain and Complex World: The IFIP TC8/WG8.3 International Conference 2004 5.3 Declarative Representation Further analysis of the elicited knowledge from the second part of the workshop has produced the declarative part of the informal representation, made up of the following components. First, the “attributes of the process” are classified according to the following categories: •
what products needed the element (e.g. terminal area forecast, state forecast, metropolitan forecast, fire weather forecast);
•
what were the time scales for predicting (e.g. 0−6 hrs, 6−24 hrs, 24 hrs or more);
•
what was the forecasting resolution within these time scales (e.g. for 0−6 hrs the forecasting is done every 10 minutes during the first hour and then hourly for the next 5 hrs);
•
what types of spatial information it included; how specific were the locations and distributions (e.g. key points, district (nearest 50−150km), whole of metro area (to 10 km or so));
•
in what specificity should the forecast be (e.g. rate: Yes/No, light / moderate / heavy, ranges: 1to 5, 5−10); what type of rain (e.g. rain / drizzle / showers);
•
how is uncertainty reflected (e.g. mainly by text qualifiers: generally, local, possible, risk of, and sometimes by percentages of chance); and
•
what types of information delivery are available (e.g. as information embedded in a more general text forecast products, as a part of verbal descriptions of the weather delivered over the radio and telephone, and less commonly as numerical information in text tables).
Second, the elicited hierarchy of techniques has been modified, resulting in a more coherent structure. Third, the further analysis showed that the elicited concepts could naturally be divided into two dimensions, namely, tools and information. This distinction provides additional structure to the hierarchy and leads naturally to a matrix representation. We have devised a matrix representation that specifies associations between information and the existing tools used to acquire this information. These associations are extracted from the hierarchical data representation. At the current stage of the analysis, 17 tables using this matrix representation have been constructed for the rainfall weather element; here is an example. Information about: how much moisture is available? TOOLS→ INFORMATION ↓ boundary layer moisture moisture depth upper level moisture vertical moisture profile
analyse surface dewpoint obs
interpret balloon sounding
X
estimate air parcel trajectories
apply conceptual models
view satellite obs of cloud
X X X X
view radar obs of precip X
X X
X
X
Table 4: Example Matrix Representation An ‘X’ in the table means that tool (column label) is used during the forecasting process to provide particular information (row label). In this representation, there is no ordering or preferences about using the tools. These tables will be used as the basis for the rating questionnaires to be sent in the next stage of the elicitation, as described in § 4.1, which will provide such additional ordering and preference information.
6. CONCLUSIONS AND FURTHER WORK Our study aims to audit the current forecasting methods, strategies, ways of thinking and working, and their use of information, in order to obtain a broad picture of the current forecast process, its advantages and disadvantages. Here we have reported on the outcome of the first of several workshops with professional forecasters, which focussed on the three weather elements: rainfall, temperature and wind. In the immediate future we will continue with additional workshops, extending the elicitation to further elements, as well as testing and developing our existing analysis. Our current analysis was aimed at documenting the forecasting process in such a way that information will be shared and re-used. To this end we have begun developing an ontology, which will provide the foundation for future DSSs. The ontology represents the structures, both declarative and procedural, we have identified in the elicitation data. It consists of the several informal representations, which will be essential for communicating 79
Developing An Ontology for the Meteorological Forecasting Process with experts for the purposes of validation, system acceptance and maintenance. These are: 1) a glossary of forecasting terms (§5.1), including definitions and relationships to other concepts; 2) a procedural representation (§5.2), including classes of functions and methods and a new procedural structure (diagrammatic) for the forecast process; and 3) a declarative representation (§5.3), including a classification of attributes of the process; a hierarchical representation of the forecasting techniques; matrices of associations between information and tools To date, we have elicited information for each weather element separately. This will be combined into a comprehensive ontology for the weather forecasting process. Not only was this element-based approach consistent with the Bureau’s new FSEP approach, but it was essential for making the elicitation process feasible. In addition, the resulting ontology should capture both the commonalities and differences between the forecasting processes for different weather elements, yielding a more structured ontology. We anticipate that the meteorological ontology will be used in at least the following ways. (1) The representations within the ontology should assist in the development of a DSS. The procedural representation will be used to identify forecasting goals and methods, as well as key decision points and the way they are reached. This will aid in designing automated support tools. For example, a DSS should enable a suitable approach to each of the time scales and include support for extrapolating and downscaling information, particularly for the timescale 0−6 hrs (§5.2). (2) The matrices relating information and tools will aid in humancomputer interface design. The matrices will directly report which tools should be available for the user in certain situations (e.g., NWP and conceptual models should be available for up-motion information). The rating information and the conceptual hierarchy can be used for menu design, in selecting the ordering of options (e.g., if in a certain situation NWP are rated higher than conceptual models, then the option of NWP should here take precedence). (3) The ontology should also be useful in training, as it will represent explicitly both shared national components of forecasting process and regional differences. (4) Aspects of the ontology will support a variety of technologies. The description of the relationships between the concepts in the glossary can be used for rule-based applications or, for a statistical model (e.g., Bayesian network), the concepts (information and tools) can be used as the variables. For example, from the table in §5.3 "how much moisture is available?", with additional information about the tool outputs, we can derive: IF radar echoes indicate surface based convection THEN boundary layer moisture is high; and, IF surface dewpoint > 15C THEN boundary layer moisture is high; (5) The ontology will also help in deciding on relationships between concepts. For example, in the hierarchical representation “speed”, “direction” and “movement of elements” come under “system movement”, and this can be interpreted as three variables that directly interact with a “system movement” variable. Although the bulk of the work in developing DSSs for meteorological forecasting clearly lies in the future, we believe our initial work toward an ontology makes a useful start and will provide direction to our future efforts.
REFERENCES AgentCities 2003, AgentCities, WeatherAgent @ Aberdeen, University of Aberdeen, Computing Science, viewed 31, December 2003, . Arpirez, JC, Corcho, O, Fernandez-Lopez, M & Gomez-Perez, A 2001, 'WebODE: a scalable workbench for ontological engineering', paper presented to 1st International Conference on Knowledge Capture (KCAP), Victoria, British Columbia, Canada, pp 6-13. Benjamins, VR, Fensel, D & Perez, A 1998, 'Knowledge Management through Ontologies', paper presented to 2nd International Conference on Practical Aspects of Knowledge Management (PAKM'98), pp. Blazquez, M, Fernandez, M, Garcia-Pinar, JM & Gomez-Perez, A 1998, 'Building Ontologies at the Knowledge Level using the Ontology Design Environment', paper presented to 11th Workshop on Knowledge Acquisition, Modeling and Management, KAW'98, pp. Chandrasekaran, B, Josephson, JR & Benjamins, VR 1999, 'What are ontologies, and why do we need them?', Intelligent Systems, IEEE, vol. 14, no. 1, pp. 20 -6. Fernandez, M 1999, 'Overview of Methodologies for Building Ontologies', paper presented to IJCAI99, Workshop on Ontologies and Problem-Solving Methods: Lessons Learned and Future Trends, pp. Fernandez, M, Gomez-Perez, A & Juristo, N 1997, 'METHONTOLOGY: From Ontological Art Towards Ontological Engineering', presented to AAAI97, Workshop on Ontological Eng., Stanford, pp 33-40.
80
Decision Support in an Uncertain and Complex World: The IFIP TC8/WG8.3 International Conference 2004 Gomez-Perez, A, Fernandez, M & de Vicente, A 1996, 'Towards a method to conceptualize domain ontologies', paper presented to ECAI '96, Workshop on Ontological Engineering, pp 41-52. Gruber, TR 1993, 'Towards Principles for the Design of Ontologies Used for Knowledge Sharing', in N Guarino & R Poli (eds), Formal Ontology in Conceptual Analysis and Knowledge Representation, Kluwer Academic Publishers, Deventer, The Netherlands. Gruninger, M & Fox, MS 1995, 'Methodology for the Design and Evaluation of Ontologies', paper presented to Workshop on Basic Ontological Issues in Knowledge Sharing, IJCAI-95, Montreal, pp. Helsper, EM & van der Gaag, LC 2002, 'A case study in ontologies for probabilistic networks', in FCaAP M. Bramer (ed.), Research and Development in Intelligent Systems XVIII, Springer-Verlag, pp. 229-42. Hoffman, RR 1991, 'Human factors psychology in the support of forecasting: The design of advanced meteorological workstations', Weather and Forecasting, vol. 6, pp. 98-110. Hoffman, RR, Shadbolt, NR, Burton, AM & Klein, G 1995, 'Eliciting Knowledge from Experts: A Methodological Analysis', Organizational Behavior and Human Decision Processes, vol. 62, no. 2, pp. 129-58. Hong-Kong-Observatory 2003, Weather information in eXtensible Markup Language (XML), Hong Kong Observatory, viewed 1, January 2004, . Johnson-Laird, PN 1988, The Computer and the Mind: An Introduction to Cognitive Science, Harvard University Press, Cambridge, MA. Kelly, J 2003, A case study: the Australian Marine Forecasting System, Internal Working Document, Bureau of Meteorology, Melbourne, Australia. Labrou, Y & Finin, T 1999, 'Yahoo! as an Ontology: Using Yahoo! Categories to Describe Documents', paper presented to 8th International Conference on Information Knowledge Management, pp 180-7. Langan-Fox, J, Code, S & Langfield-Smith, K 2000, 'Team mental models: techniques, methods, and analytic approaches', Human Factors, vol. 42, no. 2, pp. 242-71. LeFebvre, TJ 1995, 'Operational Forecasting with IFPS', paper presented to 11th International Conference on Interactive Information and Processing Systems for Meteorology, Oceanography, and Hydrology, Dallas, Amer. Meteor. Soc., pp 249-54. Ryan, C 2003, The Forecast Streamlining and Enhancement Project, Technical Report, Bureau of Meteorology, Melbourne, Australia. Santosus, M & Surmacz, J 2001, The ABCs of Knowledge Management, CIO, Knowledge Management Research Center, viewed 30, December 2003, . Schraagen, JMC, Ruisseau, JI, Graff, N, Annett, J, Strub, MH, Sheppard, C, Chipman, SE, Shalin, VL & Shute, VL 2000, Cognitive Task AnalysisRTO-TR-24, the Human Factors and Medicine Panel (HFM). Trafton, JG, Kirschenbaum, SS, Tsui, TL, Miyamoto, RT, Ballas, JA & Raymond, PD 2000, 'Turning pictures into numbers: Extracting and generating information from complex visualizations', International Journal of Human Computer Studies, vol. 53, no. 5, pp. 827-50. Uschold, M & Jasper, R 1999, 'A Framework for Understanding and Classifying Ontology Applications', paper presented to IJCAI99 Workshop on Ontologies and Problem-Solving Methods(KRR5), pp. Uschold, M, King, M, Moralee, S & Zorgios, Y 1998, 'The Enterprise Ontology', in M Uschold & A Tate (eds), The Knowledge Engineering Review, Special Issue on Putting Ontologies to Use, vol. 13.
COPYRIGHT J. Bally, T. Boneh, A. Nicholson, K. Korb © 2004. The authors grant a non-exclusive licence to publish this document in full in the DSS2004 Conference Proceedings. This document may be published on the World Wide Web, CD-ROM, in printed form, and on mirror sites on the World Wide Web. The authors assign to educational 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. Any other usage is prohibited without the express permission of the authors.
81
