Semantic Services for Intelligence Preparation of the Battlefield (IPB) Composition

Timothy Darr, Perakath Benjamin, Richard Mayer, Ronald Fernandes, Atul Jain Knowledge Based Systems, Inc.

{tdarr; pbenjamin, rmayer, rfernandes, ajain}@kbsi.com

ABSTRACT

This paper describes an intelligence Rapid Product Generator (iRPG) knowledge management framework. The iRPG is designed for use by the ISR-C2 community to support the warfighter in the creation, analysis, and distribution of tactical intelligence data. The ultimate aim is to support generation and use of Generic Intelligence Requirements Handbook (GIRH) and Intelligence Preparation of the Battlefield (IPB) data. The resulting capability for rapid generation of intelligence products will enable warfighter-evolved systems; that is, users will be able to compose solutions to intelligence needs in real time using pre-existing data sources and services. The iRPG will be a standards-based framework, making use of the service-oriented architecture (SOA), and supporting distributed data models and ontologies. iRPG will include the following features: a knowledge-products ontology derived from GIRH or IPB requirements; a set of design integration guidelines for application services; implementations of workflow and discovery services; and a method for annotating non-semantic web services for integration into the ISR-C2 framework.

KEYWORDS: intelligence preparation of the battlefield (IPB), service oriented architecture (COA), semantic services, business process composition.

1. INTRODUCTION

The intelligence Rapid Product Generator (iRPG) model development platform can be applied to system engineering, knowledge modeling, and ontology consulting efforts. This powerful capability consists of an operational framework housing system and knowledge modeling tools. iRPG implements proven concepts and presents them to the system developer or analyst in an efficient and well-structured form.

The iRPG platform is based on the IDEF [1] and UML [2] methodologies, and builds on many other standards, for example OWL [3], BPEL [4], WSDL [5], SPARQL [6]. iRPG includes the following features: � ontology and process modeling methods (IDEF5,

IDEF3); � a graphical composite editor for composing

workflows (i.e., business processes); � components for simulating business processes such

as ARENA [10] and WORKSIM® [11]; and � components for automatically emulating a business

process and analyzing its output.

iRPG can be applied by the services in support of the ISR-C2 community and will be targeted for use by the warrior with a minimum of specialized support. Key aspects of iRPG include:

(i) the centrality of a standard domain ontology that represents the intelligence product that is being created;

(ii) a minimalist shared domain ontology for communicating knowledge products and GIRH1 / IPB 2 [8] questions for the purpose of invoking SOA capabilities;

(iii) application services are only required to answer domain ontology questions;

(iv) use of standards whenever possible; (v) leverage existing products (IDEF and UML model

development platforms, BPEL execution engines, semantic web technologies);

(vi) a SOA framework that minimizes the need for writing new code each time a new processing capability is required and provides optimal means to reuse existing computing assets;

(vii) a semantic annotation capability that provides a method to annotate existing web services with semantic content from the iRPG ontology,

1 General Intelligence Requirements Handbook

2 Intelligence Preparation of the Battlefield

408978-1-4244-6622-1/10/$26.00 ©2010 IEEE

providing a rapid migration path from existing, non-semantic web services into the ISR-C2 framework; and

(viii) the use of the standard BPEL language for modeling ISR-C3 workflows that enables interoperability and portability of process definitions across multiple systems. Any BPEL engine will be able to take a given ISR-C2 workflow described in BPEL, invoke the individual services and return the output.

2. CONCEPT OF OPERATIONS

The iRPG concept of operations consists of two parts: a CONOPS for the development and integration of application services into the iRPG framework; and a CONOPS for the use of the iRPG framework to answer a domain ontology question.

Figure 1 shows the CONOPS for developing application services. There are two users in this CONOPS: an application service developer, who develops new services and integrates existing services into the iRPG framework for the purpose of answering a domain ontology question; and a warfighter application analyst, who creates workflows to assemble existing services in a way that can answer a domain ontology question that cannot be

answered using a single application service. The application service developer is an experienced programmer who is able to create or integrate a service into the iRPG framework according to the iRPG application service API standards. The warfighter application analyst understands the domain ontology and is able to use the iRPG tools to select and assemble existing services into a service workflow to answer a question that is not answerable by existing services or workflows.

In the first part of this example CONOPS, the application service developer creates a new service that is able to assess a course of action (COA) against cultural factors for a given region. The COA is obtained from a source-data repository. The application developer designs the service to conform to the iRPG application service interface, and registers the new service with the iRPG discovery service. As part of this registration process, the application developer indicates the domain ontology questions that the service can answer, and lists additional semantic descriptive information about the service, such as provenance or confidence information associated with the source data and algorithms used. This new service is now available for use by other application developers.

Figure 1. Application Service Development CONOPS

409

Figure 2. iRPG Application Service Execution CONOPS

In the second part of this example CONOPS, a warfighter application analyst works with a decision maker to develop an application service workflow. This workflow answers a domain ontology question; it achieves this capability by selecting and assembling a collection of existing application services (some of which may themselves be workflows) into a workflow service. Once this is done, the workflow is registered with the iRPG discovery service like any other service, along with the associated domain ontology question that it answers, and provenance information. Unlike a standalone application service, a workflow service is deployed to the BPEL execution engine, which manages the execution of the workflow in runtime.

The latter part of the CONOPS of Figure 1 illustrates three important iRPG capabilities: the enablement of warfighter-evolved applications; the ease with which new services can be assembled by non-programmer domain experts; and the enablement of leave-behind knowledge products. Warfighter-evolved applications allow the warfighter to assemble services to answer questions of the “unintended user.” While the creation of a new workflow is constrained by the concepts in the domain ontology, it is possible to assemble novel workflows, on the fly, to address previously unanswered questions, or to answer previously answered questions in novel ways using alternate services. Once an application service has been

created and registered with the iRPG discovery service, an analyst or decision maker that is knowledgeable in the domain can use the iRPG interface to drag-and-drop and connect existing services into a workflow. No programming knowledge is required.

Lessons learned are also captured through the iRPG; the tool will include a repository for storing all workflows that have been used in the past. Consider, for example, the case that a commander who arrives in an area of responsibility with a specific objective such as to "increase connection between the local population and the local government." The proposed course of action (COA) to achieve this objective might be to: (a) build roads so that the local population can more easily reach out to the local government; and (b) distribute humanitarian aid through the local government. In the course of executing this COA, the commander discovers that the COA has no effect: the local population believes that the local government is not trustworthy and does not have the resources to deliver the promised aid and therefore does not associate the improvements with the local government. Without leave-behind knowledge products, the next commander may arrive in the same (or similar) area of responsibility and attempts the exact same COA. Leave-behind knowledge consists of previously defined processes, answers to questions, ontologies, and other models that are relevant to the area of responsibility. Identical results can be expected. iRPG will mitigate this

410

lack of communication and knowledge sharing by storing workflows and the results experienced so that a new commander can utilize past experience and knowledge products in formulating a COA plan.

Figure 2 shows the CONOPS for executing an application workflow for the purpose of answering a domain ontology question. The user for this CONOPS is a commander or other decision maker who is familiar with the warfighter wiki or other portal where domain ontology questions can be asked or answered. In this CONOPS, the decision maker logs onto the warfighter wiki to get an assessment of a proposed COA for their AOR. The decision maker selects the appropriate domain ontology question and provides any additional information that might be needed. The warfighter wiki uses the specified information to query the discovery service for any workflows that can answer the question. Advanced querying capability will take into account the provenance or uncertainty of the desired workflow. The discovery service invokes the returned workflow with the specified parameters using the BPEL execution engine. The BPEL execution engine invokes each service in the workflow according to the steps as specified in the workflow, and manages the passing of parameters and results from one service to another. When the workflow is complete, the BPEL engine returns the result to the warfighter wiki for display to the decision maker.

3. ARCHITECTURE Figure 3 shows the iRPG architectural framework, which consists of the following components: � iRPG core ontology - a minimal, upper level

ontology to represent GIRH / IPB knowledge products and to support interoperability among the application services..

� Application services - provide functionality that is needed for the warfighter mission in the context of the ISR C2 program. Example capabilities include: social network and link analysis, group detection, theme detection and extraction, entity extraction, and assessment of infrastructure to support insurgent activities.

� Workflow service - provides capability for creating and executing workflows to answer GIRH / IPB questions that require more than one service or otherwise cannot be answered by a single application service.

� Discovery service - provides advanced capability for application service discovery. This service includes mapping from GIRH / IPB questions to services that can answer the question and the capability to respond to semantic queries for services with specific capabilities with the services that are best able to perform the desired capability.

� Services registry – uses existing implementations (i.e., UDDI) to provide standard service cataloging capabilities including access to SOA service descriptions.

Figure 3. iRPG Architectural Framework

411

Figure 4. iRPG Ontology Organization

3.1. Ontology

The iRPG ontology is designed as a common communication language focused on the GIRH / IPB questions and knowledge products [9]. This ontology consists of multiple sub-ontologies, each of which contains a small number of concepts and properties and can easily be integrated into other ontologies for use in ISR-C2 application services or other applications. A notional ontology organization is shown in Figure 4. The solid arrows represent ontology imports. This organization allows application services to only include the elements of the ontology that are necessary for their capabilities and reduces the cognitive overload of the application developers in understanding the ontology.

The design of the COA-Ontology strives to achieve extensibility, flexibility and reuse. Our experience is that many ontologies are monolithic and cumbersome; making them difficult to understand and difficult to reuse. The notional ontology organization shown in Figure 4 includes a common ontology containing definitions of the most basic concepts, such as Person, Event, and Location. Sub-ontologies are provided for each grouping of GIRH / IPB questions, such as an Urban-Population sub-ontology,

an Urban-Threats sub-ontology, a PSYOPS sub-ontology, etc. The service description ontology includes concepts and properties for describing application services, to include the GIRH / IPB questions that can be answered, and possibly the technical methods used to answer the GIRH / IPB questions. Any one of these sub-ontologies can be imported as a stand-alone ontology into other ontologies for the purpose of providing a common communication language.

The iRPG ontology will also support the representation of uncertainty and provenance associated with a workflow chain. According to a recently chartered W3C provenance incubator group, provenance includes "making determinations about whether information is trusted, how to integrate diverse information sources, and how to give credit to originators when reusing information" and "encompasses the initial sources of information used as well as any entity and process involved in producing a result." Additionally, the charter states that "reasoners in the Semantic Web will need explicit representations of provenance information in order to make trust judgments about the information they use". This incubator group clearly aligns with the iRPG need to represent provenance and uncertainty in a workflow chain.

Figure 5. iRPG Application Service Framework

412

3.2. Application Services Application services are developed within the framework shown in Figure 5. Application services process sensor data or knowledge products (contextual RDF) and generate knowledge products in response according to some application-specific functionality. The application service interfaces with external applications (wiki pages, other ISR-C2 application services, etc.) by way of a web services interface or SPARQL endpoint.

Each application service will be required to import the sub-ontologies defined in the iRPG ontology that the service needs to ask or answer GIRH / IPB questions. Each application will also have an application specific ontology that provides additional refinement of the iRPG core ontology; for example, an event detection application service might define more specific event types that other services might be interested in. The application service capabilities and specific ontology will be discoverable or accessible by other application services, by way of the iRPG discovery service.

When these services join the network, as shown in Figure 3, they publish their capabilities to the iRPG discovery service so that other services and applications can gain access to their capabilities. The capabilities of an application service are described in terms of the iRPG service description sub-ontology and include, but are not limited to, the GIRH / IPB questions that the service can answer.

3.3. Workflow creation and deployment capability

Individual web services of an SOA rarely constitute a complete business solution. The creation of a complete business solution is usually implemented through composition, or orchestration, of participating web services [16, 17, 18]. Business Process Execution Language (BPEL) is the orchestration language used for the defining and executing business processes. BPEL enables the top-down realization of SOAs by describing how tasks are orchestrated including what components perform the tasks, what their relative order is, how they are synchronized and how information flows to support the tasks. This standardized composition is deployable on BPEL-compliant engines. Deploying a business process on a BPEL engine translates into taking a BPEL description and asking a BPEL engine to expose the business process as a web service. A BPEL engine is also responsible for invoking the individual services.

iRPG supports orchestration, testing and deployment of application services at the click of a button. The IDEF3� BPEL translator parses application service WSDL files to assist the mappings of input/output data types between

services that constitute the workflow. The mapping list, along with some built-in intelligence (as no one-to-one direct mapping) serves as a guiding platform for creating the final BPEL flow. The BPEL flow once modeled, could easily be deployed and published in the iRPG service repository for answering questions. In addition to workflow modeling and deployment, the iRPG would also support modeling and generation of semantic web services by annotating existing web services with semantic content from the iRPG ontology. In the case of SOA-based service implementation, a Web Services Description Language (WSDL) can specify the operations available through a web service and the structure of data sent and received, but cannot specify a semantic meaning of the data or semantic constraints on the data. This prevents existing services from integrating into the ISR-C2 framework without costly and extensive re-design and re-implementation. The iRPG semantic SOA design framework is shown in Figure 6.

The inputs to the iRPG semantic SOA framework include: the iRPG ontology, the annotated WSDLs for the participating web services and a model of the workflow using the IDEF3 process modeling language [1] that includes a reference to the iRPG ontology. Using the variety of semantic reasoning techniques, the output of the iRPG semantic SOA framework is a BPEL flow that invokes semantically relevant application services selected by using the annotated semantic mappings stored as part of semantic web service WSDL’s [19, 20]. This BPEL can be executed on any BPEL-compliant execution engine. One possible workflow to be provided in the initial implementation of iRPG is one that assigns provenance or context information to ISR-C2 application service knowledge products.

3.4. Discovery Service The purpose of semantically annotating WSDL is to enable dynamic discovery, composition and invocation of the defined web services [13, 14, 15]. Therefore, the focus of semantic annotation of WSDL is on the abstract definition of the service such as its type definition, element, attributes, interfaces and operations declaration [13, 14].

The annotated WSDL can be exported as a method for knowledge sharing and dynamic service discovery and reuse. One such format is Semantic Annotations for WSDL (SAWSDL [12]). The iRPG discovery service uses SAWSDL and the descriptions provided by the applications services to the registry service to perform enhanced discovery of services. This allows an external application to specify higher-level or abstract descriptions of a desired service or workflow. The iRPG discovery service will reason about the request and return the service or set of services that can fulfill the request.

413

Figure 6. Design for iRPG Semantic SOA Framework

Figure 7. iRPG Discovery Service Framework

4. OPERATIONAL UTILITY

The end-user applications for the iRPG framework include the following: (i) access to GIRH / IPB data by external applications through iRPG application service SPARQL endpoints or service invocations; (ii) semi-automated population of semantic wikis with knowledge products derived from GIRH / IPB workflows; (iii) Rapid creation and distribution of rich knowledge products data related to network analysis within an urban warfare or counterinsurgency (COIN) operation; and (iv) enablement of custom workflows for creating, processing and distributing GIRH / IPB data using standards based BPEL representations.

The utility of the iRPG framework can be measured by (a) how quickly existing services can be integrated into the ISR-C2 architecture, (b) how easily new services are developed and integrated into the ISR-C2 architecture, (c) how easily external applications are able to access the

GIRH / IPB data provided by a particular service and (d) how easily workflows are developed to create new capability using existing framework services.

5. CONCLUSIONS

iRPG provides the following capability advantages to the warfighter:

� Rapid access to GIRH and IPB data by external service applications through MM-ISR-C2 application service SPARQL endpoints or service invocations;

� Semi-automated population of semantic wikis with knowledge products derived from GIRH and IPB workflows;

� Rapid creation and distribution of rich knowledge products and data related to network analysis within an urban warfare or counterinsurgency (COIN) operation (warfighter-evolved applications);

414

� Enablement of custom SOA workflows for creating, processing, and distributing GIRH and IPB data using standards-based BPEL representations;

� Warfighter-defined and –evolved applications via service workflows;

� Acquisition and cataloging of background knowledge and lessons learned for a given AOR using semantic web technologies;

� Rapid assimilation of newly-arrived warfighters into an AOR through access to the background and lessons learned; and

� Integration and interoperability of disparate services via domain ontology

REFERENCES

[1] "IDEF Integrated DEFinition Methods", IDEF Family of Methods: A Structured Approach to Enterprise Modeling and Analysis, Date accessed: March 3, 2010, Available: http://www.idef.com/.

[2] "Object Management Group Unified Modeling Language", UML® Resource Page, Date accessed: March 3, 2010, Available: http://www.uml.org/.

[3] "W3C Recommendation", OWL Web Ontology Language Overview, Date accessed: March 3, 2010, Available: http://www.w3.org/TR/owl-features/

[4] "Web Services Business Process Execution Language Version 2.0", Date accessed: March 3, 2010, Available: http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf.

[5] "W3C Note", Web Services Description Language (WSDL) 1.1, Date accessed: March 3, 2010, Available: http://www.w3.org/TR/wsdl

[6] "W3C Recommendation", SPARQL Query Language for RDF, Date accessed: March 3, 2010, Available: http://www.w3.org/TR/rdf-sparql-query/

[7] W3C Provenance Incubator Group Wiki, Date accessed: March 3, 2010, Available: http://www.w3.org/2005/Incubator/prov/

[8] INTELLIGENCE PREPARATION OF THE BATTLEFIELD FIELD MANUAL NO. 34-130 (FM 34-130), Headquarters Department of the Army, July 1994.

[9] T. P. Darr, P. Benjamin. and R. Mayer, "Course of Action Planning Ontology", Ontology for the Intelligence Community Conference (OIC 2009), George Mason University, October 21-23, 2009.

[10] "Arena® Simulation Software", Accessed: March 3, 2010, Available: http://www.arenasimulation.com/Arena_Home.aspx

[11] "Knowledge Based Systems, Inc.", WorkSim®, Accessed: 03-March-2010, Available: http://www.kbsi.com/COTS/WorkSim.htm

[12] "W3C Recommendation", Semantic Annotations for WSDL and XML Schema, Accessed: March 3, 2010, Available: http://www.w3.org/TR/sawsdl/

[13] D. Martin, M. Paolucci, and M. Wagner. "Towards semantic annotations of web services: Owl-s from the sawsdl perspective", In Proc. of 4th European Semantic Web Conf. (ESWC), Workshop: OWL-S: Experiences and Directions, Innsbruck, Austria, 2007.

[14] V. Kunal and A. Sheth, "Semantically Annotating a Web Service," IEEE Internet Computing, Vol. 11, No. 2, pp. 83-85, 2007

[15] K. Verma et al., “Meteor-S WSDI: A Scalable Infrastructure of Registries for Semantic Publication and Discovery of Web Services,” J. Information Technology and Management, Vol. 6, No. 1, pp. 17–39, 2005.

[16] K. Sivashanmugam, J. Miller, A. Sheth, and K. Verma, "Framework for Semantic Web Process Composition", International Journal of Electronic Commerce, Vol. 9, No. 2, pp. 71-106, 2004-5 (pre-publication version)

[17] G. Kapitsaki, D.A. Kateros, I.E. Foukarakis, G. N. Prezerakos, D.I. Kaklamani and I.S. Venieris, "Service Composition: State of the art and future challenges", 16th IST Mobile & Wireless Communications Summit 2007, Budapest, Hungary, 1-5 July 2007.

[18] P. Bertoli, J. Hoffmann, F. Lecue, and M. Pistore. "Integrating Discovery and Automated Composition: from Semantic Requirements to Executable Code", In Proc. of the IEEE International Conference on Web Services (ICWS'07), Salt Lake City, USA, 2007.

[19] M. Nagarajan et al., “Semantic Interoperability of Web Services: Challenges and Experiences,” Proc. of the Fourth International Conference on Web Services (ICWS'06), Chicago, IL, 2006.

[20] K. Sivashanmugam et al., “Adding Semantics to Web Services Standards,” Proc. of the Third International Conference on Web Services (ICWS'03), Las Vegas, NV, pp. 395–401, 2003.

415