NetWeaver Developer

NetWeaver Developer is a knowledgebase development system. This article
 * 1) gives a brief history of the system,
 * 2) summarizes key features of the software,
 * 3) is a bit of a primer, describing basic attributes of a NetWeaver knowledgebase, and
 * 4) provides secondary references that independently document some of the NetWeaver applications developed since the late 1980s (see the  section in this article, as well as applications documented for the EMDS system).

First, though, a word about knowledgebases. While there are various ways of describing a knowledgebase, perhaps one of the more central concepts is that a knowledgebase provides a formal specification for interpreting information. Formal in this context means that the specification is ontologically committed to the semantics and syntax prescribed by a knowledgebase processor (aka, an engine).

A brief history
NetWeaver was created in late 1991 as a response to ease knowledge engineering tasks by giving a graphical user interface to the ICKEE (IConic Knowledge Engineering Environment) inference engine developed at Penn State University by Bruce J. Miller and Michael C. Saunders. The first iterations were simply a visual representation of dependency networks stored in a LISP-like syntax. NetWeaver quickly evolved into an interactive interface where the visual environment was also capable of editing the dependency networks and saving them in the ICKEE file format. Eventually NetWeaver became "live" in the sense that it could evaluate the dependency networks in real time.

NetWeaver basics
A NetWeaver knowledgebase graphically represents a problem to be evaluated as networks of topics, each of which evaluates a proposition. The formal specification of each topic is graphically constructed, and composed of other topics (e.g., premises) related by logic operators such as and, or, not, etc. NetWeaver topics and operators return a continuous-valued ‘‘truth value’’, that expresses the strength of evidence that the operator and its arguments provide to a topic or to another logic operator. The specification of an individual NetWeaver topic supports potentially complex reasoning because both topics and logic operators may be specified as arguments to an operator. Considered in its entirety, the complete knowledgebase specification for a problem can be thought of a mental map of the logical dependencies among propositions. In other words, the knowledgebase amounts to a formal logical argument in the classical sense.

When logic meets graphics
Cognitive theory suggests that human beings have two fundamental modes of reasoning: logical (albeit however informally some folks may do that when left to their own devices) and spatial. Interesting things happen when logic is implemented graphically.

First, the knowledge of individual subject-matter experts engaged in knowledge engineering often is not fully integrated when dealing with complex problems, at least initially. Rather, this knowledge may exist in a somewhat more loosely organized state, a sort of knowledge soup with chunks of knowledge floating about in it. A common observation of knowledge engineers experienced in graphically designing knowledgebases is that the process of constructing a graphic representation of problem-solving knowledge in a formal logical framework seems to be synergistic, with new insights into the expert's knowledge emerging as the process unfolds. (At the moment, this assertion is largely anecdotal. Contributors to this article need to find a suitable way to document this point, because it is actually a rather important finding not simply limited to NetWeaver, but knowledge engineering more broadly).

Second, synergies similar to those observed in organizing the reasoning of individual subject-matter experts also can occur in knowledge engineering projects that require the interaction of multiple disciplines. For example, many different kinds of specialists may be involved in evaluating the overall health of a watershed. Use of a formal logic system, with well defined syntax and semantics, allows specialists’ representation of their problem solving approach to be expressed in a common language, which in turn facilitates understanding of how all the various perspectives of the different specialists fit together.

About NetWeaver knowledgebases
A NetWeaver knowledgebase has been defined by the developers as a network of networks (Miller and Saunders 2002). Each network corresponds to a topic of interest in the problem being evaluated by the knowledgebase.

NetWeaver knowledgebases are object-based. There are two basic types of objects: networks, and data links, each of which is represented in the logic structure by a programming object which has both state and behavior.

The NetWeaver engine is a Windows dynamic link library (DLL) developed by Rules of Thumb, Inc. (North East, PA). NetWeaver Developer is an interface to the engine that is used for designing knowledgebases.

Logic networks
A knowledgebase represents knowledge about how to solve a problem in terms of the topics of interest in the problem domain, and relations among these topics. Each logic network in a NetWeaver knowledge base represents a proposition about the condition of some ecosystem state or process.


 * State - The key state variable of a logic network is its truth value which expresses the degree to which evidence from antecedent networks and data links support or refute the proposition. Logically, network A is said to be antecedent to network B if B depends upon A because network A must be evaluated before network B can be evaluated.
 * Behavior - The basic function of a network is to evaluate the truth of its proposition. NetWeaver networks have three basic behaviors related to this function:
 * They query their antecedents to determine the latters' state.
 * They evaluate their own state, given the state of their antecedents.
 * They inform higher level networks that depend on them about their state.

Data links
A data link is an elementary dependency network with slightly modified behavior.
 * State - Like a network, a data link may evaluate to a truth value, given a data input. A data link may also hold a data value that is subsequently transformed by mathematical operations defined for a calculated data link.
 * Behavior:
 * In NetWeaver Developer, data links prompt the user for data input.
 * On receipt of data, data links evaluate their state, given the data input (simple data links), or pass the data value to a special data link that performs some transformation of input data (calculated data link).
 * They inform higher level networks that depend on them about their state.

Truth values
The truth value is the basic state variable of networks and data links. It expresses an observation's degree of membership in a set. Evaluations of degree of set membership are quantified in the semantics of fuzzy logic. Equivalently, think of the truth value metric as expressing the degree to which evidence supports the proposition of the network or data link; in EMDS, the symbology for maps displaying network truth values is based on the concept of strength of evidence. For additional discussion on this topic, see Interpretation of Truth Values.

Data links are frequently used to read a datum and evaluate its degree of membership in a concept that is quantified in a fuzzy argument (an argument that quantifies fuzzy set membership). Thus, in a data link the argument is a mathematical statement of a proposition. Some simple examples include:


 * If the datum fully satisfies the argument, then the truth value of the data link is 1 (full support).
 * If the datum is fully contrary to the argument, then the truth value of the data link is -1 (no support).
 * If the datum partially satisfies the argument, then the truth value of the data link is in the open interval (-1, 1). Note in particular that negative truth values greater than -1 do not connote negative truth.  Rather, such values connote low membership, or low support.
 * If the data is not known, then the truth value of the data link is 0 (undetermined).

Interpretation of truth values within networks must be treated more generally, because the truth value of a network may depend on several to many logic operators. Simple examples related to the two key logic operators, AND and OR, are:

relation, then the truth value of the operator is -1 (no support).
 * If ‘’’all’’’ logical antecedents to an AND operator fully support the AND relation, then the truth value of the operator is 1 (full support).
 * If ‘’’any’’’ logical antecedent to an AND operator is fully contrary to the AND
 * If ‘’’any’’’ logical antecedent to an OR operator fully supports the OR relation, then the truth value is 1 (full support).
 * If there is no evidence for or against an AND or OR relation, then the truth value of either operator is 0 (undetermined).

As with data links, networks may also evaluate to partially true. Two conditions give rise to this condition in NetWeaver:
 * One or more data items are missing and cannot be supplied, and therefore contribute a value of 0 to an AND.
 * One or more data items that influence the truth value of a dependency network have been evaluated against a fuzzy argument and found not to have full membership in the fuzzy set defined by the fuzzy argument (the data provides only partial support for the proposition).