Commercial companies and government organizations have embraced a web based approach to meeting critical business and mission requirements. The new Strategic Technical Plan drafted by the Air Force Electronic Systems Center (ESC) states that “the objective future is one in which systems are made interoperable by adoption of network centric, web-enabling and open architecture technology." ^[1]

To realize this future vision, it is imperative that exploration of emerging technology continue, with the goal of determining the value and applicability of each new advance to critical government missions. To that end, the Strategic and Nuclear Deterrence Command and Control System Program Office within ESC established the Web Way Ahead effort in 2000. This is a multi-year effort to support research and experimentation with new advances in technology to evolve existing mission systems toward interoperability and network centric processing. The focus to date has been on applications of eXtensible Markup Language (XML) ^[2] and web-based security.

As part of the 2003 Web Way Ahead effort, a study was commissioned to investigate Rule Markup Language (RuleML) ^[3] to determine its applicability to interoperability in the military space domain. The purpose of this paper is to document the results of this study.

Rules are fundamental to everyday problems and are especially important in applications that are web-based. Rules specify how a business is run, decisions are made, information is shared, and defense maneuvers are deployed. As XML is embraced as the international standard for web-based data exchange, the need for XML-based rules is becoming increasingly important. A standard for XML-based rules is needed to realize the concept of a Semantic Web ^[4], and will most likely be an essential component of the future World Wide Web, as shown in the Semantic Web diagram by Tim Berners-Lee, provided in Figure 1 ^[5]. Therefore, understanding how XML-based rules may be applied to help realize the vision for web-based data exchange across the military enterprise is crucial.

Additionally, there is significant business value to be gained by implementing rules. Isolating rules from application code allows changing of rules without software modifications, providing organizations the agility to adapt to changing mission needs. Application code can be reused across different rule domains, and rules can be reused across different application domains. The efficiencies and flexibility to be gained through the use of rules make the Rule Markup Language technology worth further investigation.

Figure 1. Rules in the Context of the Semantic Web

RuleML is an XML-based markup language that is intended to support rule exchange and interoperation across disparate domains. RuleML allows rules to be expressed as modular components in a declarative way, and uses distinct, standard XML tags to define a rule base, composed of facts and rules.

Rules expressed in RuleML are not intended for direct execution; instead, they can be translated to any inference engine language, such as Java Expert System Shell (Jess) ^[6], Agent Building and Learning Environment (ABLE) Rule Language (ARL) ^[7], LISP, or Prolog. Therefore, RuleML is independent of the inference engine used to implement an application, and in fact, is designed to allow exchange of rules between different engines.

The Rule Markup Initiative ^[8] was a result of the Paci fic Rim International Conference on Artificial Intelligence 2000. A team of researchers and practitioners came together and took initial steps toward defining a standard Rule Markup Language based on XML that supports forward and backward chaining as well as inferential, transformational and trigger/reaction oriented tasks.

For more information on the history and details of RuleML, see the RuleML Home Page. ^[9]

This study would not have been possible without the continuing support and vision of Mr. Michael Caracillo, Integration Director of the Strategic Command and Control System Program Office within ESC and Mr. John Shottes, MITRE Executive Program Manager of the Web Way Ahead effort. The RuleML investigation was completed under the outstanding direction of Dr. Nancy Reed and Ms. Mary Pulvermacher of the MITRE Corporation. Domain expertise and insight was provided by Mr. John Wilson, and outstanding support in the area of eXtensible Stylesheet Language Transform (XSLT) development was provided by Ms. Karen Fox, both of MITRE.

Mr. Said Tabet ^[10] and Mr. Harold Boley ^[11], the founders of RuleML, were very supportive and provided guidance on the validity of options to resolve interoperability issues. An XSLT to transform RuleML to Jess ^[12] was developed by Mr. Tabet, and was made available for our use on the RuleML Home Page. For more information on the work of Mr. Tabet and Mr. Boley, see their personal websites. Example RuleML files provided on the RuleML Home Page were very useful in this study as well.

The purpose of this section is to document the approach taken in the study. The goals and methodology are described, along with the rule domain, inference engines and selected tools.

The goals of the Applying RuleML in the Military Space Domain task are as follows.

The high level plan is shown in Figure 2.

Figure 2. High Level Plan for RuleML Study

The first step in the study was to research what RuleML is and how it is being used today. We studied the RuleML website, including the definition and design of the language. We reviewed examples and experimented with developing rules in RuleML. The result of this investigation was a RuleML White Paper that was delivered as part of this project in May 2003.

The next step was to define an approach that would determine if and how RuleML supports interoperability. To accomplish that, the following steps were identified.

The architecture of the overall approach is depicted in Figure 3.

Figure 3. RuleML Interoperability Study Architecture

To determine the types of rules to capture, we met with domain experts in the space surveillance arena. The goal was to pick simple rules at first to see if interoperability could be demonstrated without the complication of rule complexity. If successful, we would attempt to capture more complex rules and test the results. We also wanted to keep the demonstration unclassified.

We selected a small set of rules that define how to classify Satellite Element Set messages. These messages are used by the United States Air Force to share information on orbital parameters of all trackable objects that are orbiting the earth. During the course of our research, we found that RuleML could not support the specification of these rules. The details of this finding are covered in section 3.2. We then selected a different set of rules that determine the releasability of Satellite Element Set messages. These are slightly different than determining the classification and are described in more detail in section 3.3.

The rules to classify and determine releasability of Element Set messages are in the form of inference rules, in which a premise is tested, and if true, facts specified in the conclusion become part of the fact base. Inference rules are also referred to as deduction rules or derivation rules. An excellent description of rule types can be found in the following presentation by Mr. Tabet and Mr. Boley: http://www.dfki.uni-kl.de/ruleml/ruleml-krdtd/sld001.htm

The first inference engine selected was the Sandia Laboratories developed Java Expert System Shell (Jess) which uses the CLIPS ^[13] language. Jess was selected because we were already familiar with it and it easily integrates with Java. CLIPS is a LISP-like language that employs symbolic reasoning in a forward or backward chaining approach.

Next, we wanted to select an inference engine that was very different from Jess. That excluded symbolic reasoning languages, such as Prolog and LISP, since these languages are very similar in structure to CLIPS. We decided on the Agent Building and Learning Environment (ABLE) developed by IBM Alphaworks. ABLE is a framework for developing software agents, employing a Java-like language, Rules Editor and Machine Learning component. ABLE also supports XML through its ABLE Rule Markup Language (ARML).

If it could be shown that rules captured and distributed in RuleML execute uniformly in two very different inference engines, we believed its support of interoperability would be firmly established. If this was not found to be the case, then we planned to explore solutions and/or propose enhancements to achieve interoperability using RuleML.

To clearly demonstrate the results of the study, we developed a RuleML Interoperability Demonstration. The demonstration is web-based, and allows the user to view RuleML files and trigger the transformation of RuleML to Jess and ABLE languages. Built using Java Server Pages ^[14] and Java Beans ^[15], the user can also specify facts dynamically and trigger the execution of rules in each engine. The results from each engine can then be viewed side by side, so that the user can determine if Jess and ABLE executed the RuleML specified rules in a uniform manner.

Tools used in this study include XML Spy^[16] for RuleML editing, validation and transformation. Xalan version 2.5^[17] was used as the transform engine, both through XML Spy and with direct calls from Java beans and batch files.

To transform RuleML to Jess, we made use of an XSLT developed by Mr. Said Tabet ^[18], which is available on the RuleML Home Page. We created a new XSLT to transform RuleML to ABLE.

Initially, compilation and execution of the rules was accomplished by using the Jess and ABLE rule engines directly. Later, we automated the process in the RuleML Interoperability Demonstration, described above. Apache Tomcat ^[19] was used as the web server in support of the demonstration.

RuleML version 0.8^[20] was evaluated in this study.

Several iterations were necessary before a single RuleML file could be successfully executed in Jess and ABLE. The purpose of this section is to describe the major iterations, including how the rules were built, translated and interpreted by each engine.

Rules for classifying Element Set Messages were easily captured in RuleML. These rules primarily involved checking the range of values of a field in the message. These rules were successfully transformed to Jess, but did not fire correctly. We found that the "<" and ">" operators were treated as symbols in Jess, not as mathematical operators.

Next, we looked for a way to successfully express comparison of values in Jess, before attempting to capture the rules in RuleML. We built a set of rules using Jess test patterns. But, we were unable to find a way to represent test patterns in RuleML. Using templates in Jess is a good way to represent message data, but we abandoned that as well, once we determined that RuleML 0.8 did not support Jess templates.

We were unable to find a solution in which comparison rules could be captured in RuleML and then transformed and successfully executed in Jess. Therefore, we decided to change to a rule set that would be easier to represent in a markup language that is declarative, supports symbolic reasoning, and does not require mathematical operators. We selected a rule set that notionally specifies Space Message Releasability rules to move information between multi-level security domains.

Rules for classifying Space Message Releasability were simplified for use in this study, and were easily captured in RuleML. Rules were structured around the following variables:

Based on the value of each of these, the releasability of each message can be determined.

Therefore, the rules primarily involved checking values of variables. These rules were successfully transformed to Jess, and executed properly.

Since we determined in iteration 1 that the contents of a message composed of fields could not be captured easily in RuleML, we decided to change the use of the elsetMessage variable. In iteration 2, the elsetMessage variable (marked with the RuleML tag <var>) was used to capture whether the message was "classified" or "unclassified". We assumed that a Java object would manipulate each incoming message and send the information (fact) in the proper format to the inference engine. The source variable was used to identify the source of the message as being "trusted" or "untrusted". The destination variable captured the security level of the domain to receive the message. Based on all these variables, releasability of the message could be decided.

The releasability of the message was represented as an individual value (marked with RuleML tag <ind>) that would be paired with the value true or false. Releasability was not represented as a variable in this iteration, but instead more as a descriptor of the meaning of the fact. This approach to designing the rules closely followed the example in the Discount Rule Base provided from the RuleML Home Page.

Note also that initially, the elsetMessage and destination variables had some overlap in the potential range of values, such as the value of "unclassified". This resulted in undesired rule firings in which rules about destinations fired on facts about elset messages, and rules about elset messages fired on facts about destinations. Therefore, we found it necessary to include amplifying information around each atom in the premise to avoid undesirable rule firings. So, the individual "message" (<ind>message</ind>) was added in the rule premises with every occurrence of the elsetMessage variable to indicate that it was a message. These <ind> tags added meaning to each premise, because when translated to Jess, each would result in an additional atom that would need to be matched in the symbolic reasoning engine. This successfully avoided the undesired rule firings observed early in iteration 2.

Next, the new rule set was transformed to ABLE. However, we found that the resulting code would not execute in ABLE because ABLE did not recognize the translated <ind> tags. We considered how we might modify the XSLT, but postponed that approach, thinking we might be able (and perhaps should) develop rules that don’t involve <ind> tags that are used as descriptors. The use of <ind> tags as descriptors will only work in a symbolic reasoning engine. Therefore, we redesigned the RuleML representation of the Releasability rules to avoid use of descriptor <ind> tags in iteration 3.

The Space Message Releasability rules were modified in iteration 3 to be simpler. The clarifying <ind> tags were removed, and to avoid undesirable rule firings, the range of values for the elsetMessage and destination variables were changed to be exclusive. Releasability was no longer represented as a descriptor (<ind>) to the elsetMessage variable; instead releasability was used as the name of the variable that would represent the value of "true" or "false", indicating the results of the rule firings.

These rules were transformed to ABLE and successfully executed.

Iteration 3 rules were transformed to Jess, but did not work properly in Jess. Instead, execution of the transformed rules caused an exception to be thrown. Upon inspection of the Jess rules, it was clear that the variable releasability, as represented in the rules, had no prior value or binding in the premise. Therefore, when the rule fires, there is no value that can inferred.

Note that straightforward assignment of values to variables is possible in Jess using binding. However, we found that RuleML does not support binding of variables.

In iteration 4, the Space Message Releasability rules were modified so that the releasability variable was represented with an <ind> tag. As expected, transformed Jess rules executed properly but transformed ABLE rules did not.

The fundamental interoperability problem found here is in the use of variables between reasoning engines. In CLIPS and other symbolic reasoning languages, variables are placeholders that take on different values that are then pattern matched against facts. The variable name is replaced with its value during pattern matching, and is not used to reference the value after matching. In ABLE, variables are Java-like, and can only be referenced by name. This problem is depicted in Figure 4.

We modified the ABLE XSLT to translate <ind> tagged atoms to variables in ABLE. This did work for our rule set, and allowed the RuleML generated in Iteration 4 to work in both Jess and ABLE. However, we showed that this does not work in general. We downloaded the Discount Rule Base from the RuleML Home Page and found that ABLE did not translate properly, since the use of the <ind> tagged atoms as descriptors only work in symbolic reasoning engines.

Figure 4. Fundamental Interoperability Problem

A summary of all iterations along with findings is provided in Table 1.

The following points summarize our key findings.

Other findings include the following.

We also found that building rules that fire properly is tricky in any inference engine. Rules must be designed so that data can be captured as facts that trigger the firing of appropriate rules. In the absence of robust tools, developers with expertise in rule design and development will be required to develop viable rule bases.

One solution would be to incorporate standard mappings between tags and syntaxes or types of syntaxes into the RuleML standard. This would allow clear mapping between the RuleML syntax and those of Jess and ABLE, for example. The mappings could then be captured in the XSLTs, and would thus support interoperability.

Another possible solution would be to add tags to RuleML that allow specification of the different uses of <ind> and <var>. For example, <ind> can be used in two different ways: as a descriptor in a premise or as a literal value that holds a value of a variable. Here is an example of using <ind> tags as a descriptor, taken from RuleML developed as part of this study.

Here is example RuleML, showing how <ind> can be used to contain a literal value that represents the value of a variable. This example is taken from the RuleML Home Page.

Perhaps these two uses should be distinguished with different tags or different attributes, then translated accordingly to the destination language. This approach warrants further investigation.

Rules could be designed using standards and/or best practices so that the use of <ind> and <var> is not an issue, such as what was done in Iteration 4. This is not ideal, but will probably be necessary to some extent if Java-like inference engines are to be supported by RuleML. Robust tools could be developed to hide the design details of RuleML and enforce standards for rule design. A novice rule developer could use a GUI to specify rules in a simple way, then the design of the actual marked up rules could be created behind the scenes such that no confusion occurs between symbolic reasoning and Java-like inference engines. If these approaches are not found to be viable, it may be necessary to accept that RuleML, in its current state, supports symbolic reasoning engines only.

Finally, we hope to investigate whether an ontology could be implemented along with RuleML rule bases to clarify any differences in translation to inference languages.

The proposed solutions to the interoperability problems observed are provided in Table 2.