DIWAX Help System



Previous topic Next topic No directory for this topic Expand/collapse all hidden text  


Previous topic Next topic Topic directory requires JavaScript JavaScript is required for expanding text JavaScript is required for the print function Mail us feedback on this topic!  

DIWAX is a decision support system (DSS) in the field of macroeconomic analysis, i.e. it brings together knowledge from a specific problem domain (applied macroeconomics)  with tailored software tools that make the decision process (diagnostics and forecasting) easier, clearer and more robust. It provides an infrastructure for encapsulating macroeconomic reasoning based on empirical and theoretical evidence in order to support recording, explaining and forecasting economic activity on the aggregate level of a sector, industry or the total economy.


The following design principles explain the underlying philosophy that guides the ongoing development of DIWAX. Consequently, these principles shape the way the software can support you in your daily work. So - despite the fact that some information in this chapter may look somewhat technical or abstract  at first sight - familiarizing yourself with these fundamentals will dramatically increase your understanding of how to make effective use of the software. And don't worry: getting a general impression of the overall design principles is much more important than understanding every detail.


This document also explains major concepts and terms used throughout this help system.


Relational metadata for computer-assisted reasoning

To make computers productively assist human experts, the problem domain must be described and structured in a meaningful way. A computerized representation of the problem domain should mimic the cognitive style of human experts as closely as possible. This  is the key success factor for every DSS as it allows  the machine and its user  to speak a similar language. This enables the software to follow  what the human expert does and to respond appropriately (by making suggestions, sending warnings, providing context-sensitive tools, etc.).


Illustrative example When pasting a time series of GDP data into an Excel spreadsheet you and Excel do not speak the same language and, consequently, you cannot interact at eye level. Excel has no idea what the numbers in its cells mean, where they come from, how old they are, what frequency they have, whether they are price-adjusted or not, etc. You may type all this information in header cells, but Excel will still not know what you mean. You are implicitly attaching much more information to this time series than Excel does. Consequently, it cannot assist you effectively when it comes to processing this data (checking its consistency with respect to other time series or calculating years from quarters, etc). Instead, you have to type in a formula that explicitly tells the spreadsheet what to do with the data; unfortunately, this formula works uni-directionally only: it tells cell B how to respond to the content in cell A, the opposite direction does not work on the same cells. To put it short: The power of spreadsheet processors that makes them such universally usable workhorses for quick calculations is at the same time one of their major shortcomings: they know too little about the data and they do not come with the means to classify them in a suitable way for a specific problem domain. Instead, they allow the user to do things that are economically nonsense (like multiplying annual and quarterly growth rates)  and at the same time they lack the capacity to deliver decent support when it comes to doing reasonable routine work.


DIWAX addresses the representation problem by providing a well-structured shell for domain-specific metadata organized as a relational database. By means of this metadata DIWAX can attach the same meaning (in terms of economic and technical properties) to time series and other data as the user does. The metadata database can be thought of as a set of tables, each table for a different category of metadata (AREA, SECTOR, PRODUCT, ...). A metadata table has as many rows as there are alternative values for the respective category. The entries of each row (also referred to as a "record" of metadata) reflect the set of individual properties associated to this metadata value (ID, NAME, ...). The relational design guarantees that every property is coded at the most abstract level; this avoids redundancies and allows the software to perform basic inference tasks and consistency checks.


Some metadata must be universally available because they influence how the systems corresponds to alternative values (e.g. classification of a time series as showing absolute values or growth rates), others are only used to unambiguously identify a property value (e.g. classifying a time series as "German" or "French" data). The first category of metadata is therefore system-defined (it comes with the DIWAX installation) whereas the second one is user-defined (i.e. editable and extensible by the user). Wherever possible, internationally standardized classifications should be used. Many of them are already part of the DIWAX ecosystem and available for download (more on this below).


Items and Links as building blocks of the reasoning network

Business cycle analysts typically think in terms of "economic activity" (as information carrier) and not in terms of "time series" (which are just signal carriers). Therefore, one basic class of building blocks is the representation of a specific economic activity, called an "item" (example: "Consumption of durable goods by private households in Germany").  The other basic class is called "link" and marks a relation between one item and other items. A link may have the form of a mathematical equation but it need not to; it could also be a rule or a piece of hierarchical information.


The definitions of  items and links are part of the metadata database and each of them makes heavy use of other metadata categories to describe themselves in a way that clearly identifies them and their role in the overall analysis.


As distinct from econometric software packages that are built around time series and equations, DIWAX is built around items and links. Together they make up the "reasoning network" with the items as nodes and the links as connections along which the stream of reasoning flows.


See also: Items and Themes, Links and Models


Agent-based platform architecture

DIWAX follows an agent-based platform design. This architecture makes the software easily scalable and very flexible when it comes to adapting it to advanced analytic requirements.


Generally speaking, agents are pieces of software that are in charge of a specific aspect within the overall task that an application is made for. To some degree, they are autonomous in what they do to fulfill their assigned duties. Technically, this is made possible because an agent bundles all the data that is necessary for his respective duty with all relevant methods that can be applied to these data. Agents cooperate with each other via messages that contain requests or notifications and each agent has its own graphical user interface for human-machine interaction. A local DIWAX installation is a platform that provides a living space for a population of a variable number of agents. You may compare it to your computer's operating system that also acts as a platform for all applications that are installed and executable on your local machine.


What an agent can do at all (i.e. what kind of data it can hold, what its method battery looks like, and what messages it responds to) depends on the class that this individual agent belongs to. DIWAX comes with various agent classes addressing different aspects of macroeconomic analyses. The ones that shape the  behavior of item agents (item class) and link agents (link class) are the most prominent ones.


How an individual agent does his job (within the scope of competencies laid down by its class) depends on the individual settings that distinguishes it from other agents of the same class (these characterizing settings are called the "definition" of the agent). E.g., while all item agents have the general ability to represent economic activity, only one of them is in charge of embodying "Consumption of durable goods by private households in Germany"; this agent has a definition that exactly matches this economic activity (in pseudocode: Activity="Consumption"; Product="Durable Goods"; Sector="Private Households"; Area="Germany"). From this and related  metadata, the agent can conclude that it is representing a flow activity (relevant for how to calculate lower frequency data from higher frequency data) or that it has an impact on  "Consumption of durable goods by private households in the Euro Zone".


To better understand the agent-based design you might think of the agent classes as species with each agent as an individual of a species having his own DNA that is called the agent definition.


Some agents perform administrative or very basic jobs that are always needed to run any form of meaningful analysis.  Therefore, they are an integral part of DIWAX and are administered by the system automatically without any user intervention (e.g., the "Time" agent manages the various analytic time spans and is always up and running when the system starts).  However, the bulk of agents that you are working with is user-defined: all item agents, all link agents and also most of the helper agents (resources, reports, etc.) are absent when running a fresh DIWAX installation. This is so, because the set of relevant individual agents depends on the analysis that you want to do. Therefore, while DIWAX comes with the instruments to build, edit and run all these types of agents, the definitions that constitute the individual agents must  be provided by the users themselves.


A notional remark: The term "metadata" might be confusing due to its broad meaning. We have already seen that there is system-defined and user-defined metadata. The latter can be further subdivided into "descriptive metadata" and "definitional metadata". Descriptive metadata records are just lists of values for a specific property (e.g. a list of countries as alternative values for an area property) whereas each record in a definitional metadata table also denotes an agent definition.


See also: Agents and Managers


Community approach for collaborative work

Shaping the analytic landscape by creating metadata and configuring agents is time consuming. This is a clear disadvantage vis-à-vis instant ("quick-and-dirty") solutions like spreadsheet processors. But, this preparatory effort has to be done only once and it pays off very quickly when used on a regular basis. Plus, it need not necessarily be you who does all the definitional work, as DIWAX allows to share metadata with other users from the DIWAX community.


The technical background of this community approach is a remote server hosting a central database that every registered DIWAX user can upload his metadata to when connected to the internet. DIWAX has all the necessary rights management on board so you can decide who can read and download (or even modify) your contributions. Typically, professional macroeconomic studies are carried out by teams and not by individuals. Such teams can establish a DIWAX user group  (called "division") that allow to differentiate reading and writing rights on the user or division level. The remote server is an integral part of the overall DIWAX software system. The visible part of it (the software that is locally running on your machine) is called the DIWAX client to distinguish it from the web-based remote server that all local installations have access to.


When sharing content across  different DIWAX clients each metadata record must have a world-wide unique identifier. For this purpose, each  identifier is composed of the world-wide unique user ID (that you get when creating a new user account) and an individual record counter that DIWAX can generate locally (even if your are not connected to the remote server). This allows you to work offline and still create new metadata.


Some agents use local files to perform their tasks (e.g. report agents may have a template file that is used to create report charts or tables with pre-defined formats). Just like metadata records, these files can be shared with the community. All types of data that are published to other users (descriptive metadata, agent definitions, and agent-related files) make up the "DIWAX ecosystem".


See also: Exchanging Metadata, File Sharing, Working with Multiple Clients


Agenda: Soft reasoning techniques and extended analytical scope

Currently, DIWAX primarily focuses on quantitative business-cycle analysis based on national accounting frameworks and similar systems. This is fine for the prototype stage, but it is only the first step of the overall DIWAX project. In the (near) future, this approach will be extended substantially along two directions:


Methodologically, soft ways of reasoning will also be supported. Typically, what we know about the economic world is not crisp, but vague: We do not understand the full process but we do know more than nothing about it. Very often, subjective knowledge (experience, expert judgments) plays an important part in economic analysis. Today, artificial intelligence techniques (soft computing tools) allow for supporting this type of knowledge (e.g. rule based reasoning, fuzzy sets), helping the user to stay consistent even when the underlying items and links of the analysis represent soft data. At the same time, the addressee of applied economics is more clearly informed about how subjective knowledge feeds into the analysis. Finally, with economic studies being adequately coded using the metadata provided by the DIWAX ecosystem, research on what parts or versions of economic theory are actually used for real-world problem solving is enabled. This opens a wide and potentially fascinating field for meta-research in the field of economics.
In terms of scope, DIWAX will cover other fields of applied economics starting with market workability diagnostics which is already in the development pipeline. Further extensions will follow as the overall approach matures and gains acceptance.