Reasoning about Resources and Hierarchical Tasks Using OWL and SWRL Daniel Elenius, David Martin, Reginald Ford, and Grit Denker SRI International, Menlo Park, California, USA firstname.lastname@sri.com Abstract. Military training and testing events are highly complex affairs, potentially involving dozens of legacy systems that need to in- teroperate in a meaningful way. There are superficial interoperability concerns (such as two systems not sharing the same messaging formats), but also substantive problems such as different systems not sharing the same understanding of the terrain, positions of entities, and so forth. We describe our approach to facilitating such events: describe the systems and requirements in great detail using ontologies, and use automated reasoning to automatically find and help resolve problems. The com- plexity of our problem took us to the limits of what one can do with owl, and we needed to introduce some innovative techniques of using and extending it. We describe our novel ways of using swrl and dis- cuss its limitations as well as extensions to it that we found necessary or desirable. Another innovation is our representation of hierarchical tasks in owl, and an engine that reasons about them. Our task ontology has proved to be a very flexible and expressive framework to describe re- quirements on resources and their capabilities in order to achieve some purpose. 1 Introduction In military training and testing events, many heterogeneous systems and re- sources, such as simulation programs, virtual trainers, and live training instru- mentation, are used. Often, the systems were not designed to be used together. Therefore, many interoperability problems arise. These problems range from the superficial – such as two systems not sharing the same messaging formats – to more substantive problems such as different systems not sharing the same understanding of the terrain, positions of entities, and so forth. In [1], we described an approach for automated analysis of military train- ing events. The approach used owl ontologies describing the systems and the purpose for which they were to interoperate. A custom Prolog program was used to produce warnings concerning potential interoperability problems, as well as “configuration artifacts” such as a chain of mediation components that could be used to connect two systems that otherwise would not be able to communicate. A. Bernstein et al. (Eds.): ISWC 2009, LNCS 5823, pp. 795–810, 2009. c  Springer-Verlag Berlin Heidelberg 2009