Executive Summary

In this article, we describe an approach to automating the generation of Java™ agent configuration files which leverages the Web Ontology Language (OWL), the SPARQL query language, and Extensible Stylesheet Language Transformations (XSLT). 

A general model of the agent domain (non-implementation specific) is defined in the OWL-DL sublanguage which describes agent payloads along with default configurations for those payloads.   We leverage this general model to automatically generate payload configurations for a specific agent implementation, our Java Cyber Agent Framework (JCAF), by defining a small “utility ontology” that maps general model’s property names to specific JCAF implementation property names.  We then merge the two ontologies, and use SPARQL to query the combined ontology to retrieve a particular payload’s property values along with the Java implementation’s property names.  We get the query result as XML, and post-process it using XSLT, which transforms it into the Java-style property format needed to configure the payload for the JCAF. 

1    Introduction

There are many good reasons to express a knowledge model using OWL-DL.  First, OWL is a W3C standard, and there are many open-source and commercial tools available that support it.  Second, OWL-DL supports the use of automated reasoning systems while guaranteeing computational completeness (all entailments are guaranteed to be computed) and decidability (all computations will finish in finite time). Third, OWL has a standard Query Language, SPARQL [1], which is supported by many tools, including the open-source Protégé [2] and Jena [3] tools.  Fourth, because the SPARQL standard includes a standardized way of getting query results as XML, we have the option of applying common XML technologies such as XSLT [4] to transform the results of our model queries into forms that can be utilized by our Java™ agents at run-time. This article focuses on the value that the latter two capabilities bring to knowledge models captured in OWL.  Figure 1 depicts the overall concept. 

Figure 1 – From Formal Model to Run-time Files Using OWL, SPARQL Query, and XSLT

While most would agree formal model verification and automated reasoning are the key benefits of using OWL, these are not the focus of this article – these benefits are covered amply elsewhere.  Rather, in this article, we highlight some additional benefits of capturing knowledge in OWL, namely the query and transformation of knowledge.  In particular, we describe our approach to structuring a knowledge base in OWL to facilitate automated generation of Java™ agent configuration files using SPARQL and XSLT. 

2    Automated Generation of Payload Configuration

2.1    JCAF Payload Configuration

3 Sigma Research has developed a Java Cyber Agent Framework (JCAF) during the course of our research.  This Java™-based framework includes a simple agent implementation, and allows us to create and distribute payloads to those agents over the network at run time. A payload typically consists of executable code and supporting resource files.  The framework supports the notion of a Payload Deployment Package (PDP), which is an archive containing all of a payload’s files plus a configuration file. Figure 2 shows a typical payload configuration file within the framework.  A payload configuration file is a collection of properties defined as name-value pairs.  These properties tell the agent what kind of executable is in the payload (e.g. “java”, “exe”, “script”), how many times to execute the payload, how long to delay between executions, where to send output from the payload, etc.

hasID=hello123
hasExecutable=script
hasRepetitions=10
hasMsDelay=5000
hasCommand=echo ‘Hello World!’
pub.type=rss
pub.host=5.90.150.37
pub.port=8080
pub.rss.feed=hello
pub.rss.title=Hello from %ID%
pub.rss.desc= This demonstrates ...

Figure 2 – Sample Properties for a Payload

2.2    JCAF OWL-DL Ontology

We developed an OWL-DL ontology to model the JCAF domain.  Concepts (classes) in the ontology include Network Locations, Payloads, Execution Environments, Payload Configurations, and Payload Effects.  We define properties to link the concepts together.  Additionally, we define some canonical instances (individuals) of Payload Effects and Execution Environments. We also defined a knowledge base of sample instances from each class, linked together by properties, for experimentation and testing. Most of the properties used in a JCAF payload configuration file have counterparts in the JCAF ontology.   For example, there are properties in the ontology, such as hasCommand, hasRepetitions, and hasPublishLocation, which can be used to describe typical (default) values for payload configuration.  Figure 3 depicts a portion of the ontology.  

Figure 3 – JCAF Ontology Payload Description

It is worthwhile here to note that using OWL allows us to split model information into multiple ontology files.  Assertions can be made in one ontology file about items defined in another ontology file.  This allows us to partition our model into coherent and semi-independent “bags” of facts, and then combine “bags” as needed to form larger models that can be queried and reasoned over.  This partitioning allows us to “separate concerns” between ontology files.  In the JCAF model, we defined concepts (classes and properties) in one file, and sample instances in another.  As we will see later, we created a third ontology file to contain property name mapping statements.

2.3    Automating JCAF Payload Configuration

At the time the JCAF ontology was initially developed, the goal did not yet exist to generate payload configuration files from it.  When this goal was identified, a few key issues presented themselves:  (1) only a subset of properties in the ontology are relevant for payload configuration, (2) relevant properties are not always directly connected to a payload configuration instance, i.e. they might be “two hops” away instead of one, and (3) the names of the properties in the ontology and the names used in the configuration files are often very different (e.g. the property hasRssTitle in the ontology corresponds to the pub.rss.title property in a configuration file). Our approach addresses all three of these issues.  First, we make configuration properties easy to distinguish from other properties by making them sub-properties of a parent property configDataProp.   E.g.:

…
:configDataProp   a   owl:DatatypeProperty .
…
:hasRssTitle   rdfs:subPropertyOf   :configDataProp .
…

This approach makes payload configuration properties easy to distinguish from other kinds of properties.  I.e. we can simply restrict our query to those properties that are sub-properties of configDataProp.  This approach alleviates the need to encode each specific property name, e.g.  hasRssTitle, into our queries or into source code somewhere.  Furthermore, this approach allows us to add new payload configuration properties to the JCAF ontology in the future and automatically discover them without having to make any changes to the queries or to source code.  This greatly reduces the coupling between the queries and the details of the JCAF ontology, thus reducing software maintenance as the overall JCAF system grows and matures.  

Second, because relevant JCAF configuration properties are not always directly connected to a payload configuration instance, our query for properties searches for configDataProp properties that are either one or two “hops” from a payload configuration object.  E.g. in Figure 3, if gathering properties for HelloRssPayloadConfig, we would include configDataProp properties “one hop” from the HelloRssPayloadConfig individual – such as hasMsDelay, hasRepetitions, and hasCommand – as well as any configDataProp properties two hops from it (i.e. those that are hanging off of objects that are hanging off of the HelloRssPayloadConfig individual) – such as hasRssFeed (the RSS feed name) and hasPubPort (the port where the RSS Server is listening).

Third, we apply a very general approach to property name translation for localized configurations.  Rather than hard-coding name translations in source code somewhere, we again take an ontological approach.  Since OWL allows us to make statements about resources in other OWL files, we define a small utility ontology that defines a new property, javaPropName, and uses it to map payload configuration property names to corresponding Java™ property names, e.g.

…
cyb:hasRssTitle   :javaPropName   “pub.rss.title” .
cyb:hasCommand    :javaPropName   “hasCommand” .
cyb:hasPubPort    :javaPropName   “pub.port” .
…

I.e., this states that the JCAF ontology property hasRssTitle has the Java property name “pub.rss.title”.   We define one such translation for every ontology property that is applicable to JCAF payload configuration files as shown in Figure 4.

Figure 4 – Assigning Java Property Names to Ontology Properties

Putting such definitions into a separate utility ontology keeps this localized information out of the more general JCAF ontology while allowing it to be used in our queries.  We just combine the contents of this utility ontology with the JCAF ontology, and then issue queries against the combined model.

2.4    SPARQL Query

The SPARQL query shown in Figure 5  can be applied to the combined model to find default configuration properties for a given payload %P.

# Get java property names asso. w/ payload conf.
PREFIX rdfs:   
   <http://www.w3.org/2000/01/rdf-schema#>
PREFIX cyb:
   <http://3sigmaresearch.com/2008/jcaf#>
PREFIX config:
   <http://3sigmaresearch.com/2008/jcafconf#>
select distinct ?p ?pname ?v where {
  %P cyb:hasConfiguration ?conf .
  {
    # Properties one-hop from configuration.
    ?conf ?p ?v .
    ?p rdfs:subPropertyOf cyb:configDataProp .
    ?p config:javaPropName ?pname .
  }
  UNION
  {
    # Properties two-hops from configuration.
    ?conf ?q ?c .
    ?c ?p ?v .
    ?p rdfs:subPropertyOf cyb:configDataProp .
    ?p config:javaPropName ?pname .
  }
}

Figure 5 – SPARQL Query for Payload Configuration Properties, with their JCAF Property Names

For example, running this query against the combined model for the PayloadHello payload returns the following:

-----------------------------------------------------------------
| p                                     | pname               | v
=========================================================
| cyb:hasCommand         | "hasCommand"      |  "echo 'Hello World!'"
| cyb:hasRepetitions        | "hasRepetitions"    | "10"
| cyb:hasMsDelay           | "hasMsDelay"            | "5000"
| cyb:hasRssDescription | "pub.rss.desc"     | "JCAF reporting demo."
| cyb:hasRssFeed            | "pub.rss.feed"          | "hello"
| cyb:hasRssTitle               | "pub.rss.title" | "Hello from %ID%"
| cyb:hasPort                   | "pub.port"      | "8080"
| cyb:hasHost                   | "pub.host"      | "192.168.0.11"
------------------------------------------------------------------

Note that the ontology property name (column p) and the JCAF name (column pname) are both returned, as well as the values from the ontology for the property (column v).  We construct the payload configuration file using the pname and v columns.

2.5    Applying XSL Transformations

SPARQL includes a standard XML representation for query results [5].  As the final step in going from model to run-time configuration file, we run the same SPARQL query, but request that the result set be formatted as XML.  Once in XML format, we can transform it using a simple XSLT definition.  The simple XSLT is shown in Figure 6.

<xsl:stylesheet version="1.0"       
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:sp="http://www.w3.org/2005/sparql-results#">
<xsl:output method="text"/>
<xsl:template match="/">
# Generated java property file.
  <xsl:for-each select="//sp:result">
# The property below was automatically generated.
<xsl:value-of select=
"sp:binding[@name='pname']/sp:literal"/>=
<xsl:value-of select= "sp:binding[@name='v']/sp:literal" />
  </xsl:for-each>
</xsl:template>
</xsl:stylesheet>

Figure 6 – XSL Transform to Convert SPARQL XML to JCAF Property Format

We now have all the parts needed to complete our transformation.  We run the SPARQL query against the combined ontologies, and process the results with the XSLT. The resulting text is ready for use as a JCAF property file.  Figure 7 shows this final result.

# Generated java property file.
# The property below was automatically generated.
hasMsDelay=5000
# The property below was automatically generated.
hasCommand=echo 'Hello World!'
# The property below was automatically generated.
hasRepetitions=10
# The property below was automatically generated.
pub.rss.feed=hello
# The property below was automatically generated.
pub.rss.desc=JCAF reporting demo.
# The property below was automatically generated.
pub.port=8080
# The property below was automatically generated.
pub.host=192.168.0.11
# The property below was automatically generated.
pub.rss.title=Hello from %ID%

Figure 7 – SPARQL Query with XML Results Transformed by XSL

3    Summary

In summary, we have shown an approach that combines a utility ontology with an OWL knowledge base to enable automated generation of run-time files – in our case Java™ property files.  The approach insulates the more general ontology from the implementation specific information in the utility ontology.  The approach uses XSLT to transform XML output from SPARQL queries in to the final run-time file format.

4    References

[1]    Prud’hommeaux, Eric, and Andy Seaborne, ed. SPARQL Query Language for RDF.  W3C.  http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/.
[2]     The Protégé Ontology Editor and Knowledge Acquisition System.  Stanford Center for Biomedical Informatics Research.  http://protege.stanford.edu/.
[3]    Jena – A Semantic Web Framework for Java. http://jena.sourceforge.net/.
[4]    Clark, James, ed.  XSL Transformations.  W3C.  http://www.w3.org/TR/1999/WD-xslt-19990421
[5]     Beckett, Dave, and Jeen Broekstra, ed.  SPARQL Query Results XML Format.  W3C.  http://www.w3.org/TR/rdf-sparql-XMLres/