12	Ontological Structures for Higher Levels of Distributed Fusion Mieczyslaw M. Kokar, Brian E. Ulicny and Jakub J. Moskal

CONTENTS

12.1  Introduction

12.3  Querying the Net

12.4  Interoperability and Inference

12.5  Inferring Relevant Repositories

12.6  Inferring Relevant Things

12.7  Restricting Queries to Geographical Regions

12.8  Discussion: Inference of Suspicious Activities

12.9  Conclusion

References

12.1  INTRODUCTION

Today most, if not all, online information is either stored in various data stores (databases) or available in streaming form from either sensors or other sequential information providers. Both types of information sources can be termed information producers. On the other hand, this information is utilized by the various information consumers who require the information to achieve their informational goals or to support their decision processes. The producers and the consumers are all interconnected, resulting in what is called a net-centric environment, often referred to as Net-centric Enterprise Architecture in the business domain (cf. Network Centric Operations Industry Consortium n.d.) or as Net-centric operations in the military domain (cf. Cebrowski and Garstka 1998). Some of them play both roles at the same time. Information consumers have on-demand access to information producers. The ultimate goal is to have a user-defined operational picture on each consumer’s screen.

A representation of the information producers and consumers nodes is shown in Figure 12.1. Here both information producers and consumers are viewed as services. Since our intent is to associate semantic descriptions with each such service, we call those Semantic Information Services (SIS). All of the services are described using terms from an ontology. Here we use the term “ontology” as defined by Gruber (2009): “an ontology defines a set of representational primitives with which to model a domain of knowledge or discourse.” Some representative ontologies are shown at the bottom of the figure.

FIGURE 12.1 Information producers and consumers—Semantic Information Services (SIS).

In this chapter, we present some results of an effort to achieve the goals of net-centric operations, displaying necessary (and only necessary) information on the consumer’s display when they need it and in a form that they can understand and act upon. In this approach, the consumer can query the network for information relevant to the consumer’s current need. To explain how this goal can be achieved, we show a step-by-step process that starts with issuing a query to viewing a reply to the query. Each of the steps involves some ontological reasoning. To illustrate the approach, we provide fragments of ontologies that are necessary to derive the inference results.

This chapter is organized as follows. First, we provide a short explanation of ontologies. Then we show the particular activities of the whole process:

1.  Annotation of information sources

2.  Query formulation

3.  Inferring the relevance of the particular information sources

4.  Inferring the relevance of information based on the location of the objects being queried about

5.  Inferring whether the particular objects are relevant to the queried situation

12.2  ONTOLOGIES

One of the basic principles of the approach to information integration described in this chapter is the representation of all the information in a common vocabulary. For the approach to be flexible, the vocabulary needs to be extensible and have formal, computer-processable semantics. This kind of vocabulary is known as ontology. As used in the knowledge representation domain, the term “ontology” stands for an explicit, formal, machine-readable semantic model that defines the classes, instances of the classes, interclass relations, and data properties relevant to a problem domain (Gruber 2009).

FIGURE 12.2 A simple ontology for the computer domain.

To introduce the basic concepts of ontology, we use a simple example in which we demonstrate how to represent those basic ideas for the computer domain. A very simple ontology for this domain is shown graphically in Figure 12.2. In this ontology, computers are represented as a class (a rectangle-labeled Computer in Figure 12.2). A specific computer, the one I bought 3 years ago (which we call here My3YrMac), is an instance of the class Computer. It is represented as dashed line rectangle. However, the computer I bought was a laptop. Laptop can be another class, which is subclass of Computer. My laptop thus is an instance of the class Laptop. This fact is shown by a dashed line connecting My3YrMac to MacOSLaptop. As we can see, Laptop is subclassified further so that MacOSLaptop and WindowsLaptop are subclasses of Laptop. Classes are interrelated. For instance, another class, Keyboard, is related by the partOf relation to Computer. The partOf relation may be used to capture the fact that a specific instance of Keyboard is part of a specific computer. In this example, DeskTopKeyboard1 is part of Desktop1. Instances of particular classes can have various data properties. For example, every laptop has the data property of weight. Thus weight may be a data property of the class Computer (as well as of any class of physical objects). It can then be used to state the fact that the weight of my laptop is 2.8 lb.

The choice of the classes, relations and properties is obviously domain-dependent—if one wants to describe things in the domain of computers, one does not introduce classes like Politician or Horse. But the ontologist (the person who develops an ontology) has flexibility in terms of both the selection of terminology and the selection of concepts. For instance, the ontologist might want to classify laptops by the manufacturer, or by the price range. It all is a matter of what is more useful in the application that uses such an ontology.

Since the intent of having formal ontologies is to be able to process them by computers, ontologies need to be represented in a formal language. There are various approaches to representing formal ontologies including OWL (W3C 2009), conceptual graphs (Sowa 1992), topic maps (Pepper and Moore 2001), KIF (Knowledge Interchange Format 1992), and others. Our choice of language is OWL, a W3C standard. However, whenever OWL is not expressive enough to capture the meaning of a concept or a relationship, we will supplement it with rules and possibly some procedures (e.g., calls to a procedural language like Java).

Ontologies do not need to be developed from scratch. Recently, significant efforts went into the development of “data models” and “markup languages.” Data models are represented either in a database schema description language, or in the Universal Modeling Language (UML). Markup languages are essentially vocabularies represented in XML. In some cases, data models are also represented in XML. For instance, the widely known data model JC3IEDM (the Joint Consultation, Command and Control Information Exchange Data Model 3.1) (2005), developed by the Multilateral Interoperability Programme (MIP), is a long-standing, NATO-supported model intended to foster international interoperability of command and control information systems through the development of a standard data model and exchange mechanism. The data model was first released in the mid-1990s as the Generic Hub (GH) Data Model. It captures information about 271 entities, 372 relationships between entities, 753 entity attributes, and over 10,000 value codes. Representations of this model in both ERwin and XML exist. In the past, we have developed an automatic translator for JC3IEDM (Matheus and Ulicny 2007), which takes an XML representation of JC3IEDM and converts it to OWL.

12.3  QUERYING THE NET

Now we will show how we make use of ontologies for the purpose of querying for information that is of interest to the user, finding out which of the information sources are relevant to the query, retrieving the information and integrating it into a homogeneous representation. We first start with the querying.

While it would be highly desirable to be able to express queries in natural language, because this would be the easiest way of formulating queries by humans, this option is both not quite achievable with the currently available technology and also not particularly advisable since it may cause all kinds of misinterpretation errors. In particular, it is very likely that the natural language expression presented by the user to the computer system may be either vague or imprecise. The computer’s interpretation of such a query may be quite different than the user’s intent. So from this point of view, providing a more structured language in which the user can formulate queries and interpret the results returned by the computer may be a better option.

Current querying technology provides a number of options for formulating queries. For instance, everybody uses search engines, like Google, to find information on the web. In doing so, the user typically provides a number of keywords, which are then used by the search engine to find documents that contain at least some of the provided keywords. Note, however, that the search engine returns a ranked list of tens of thousands of documents, but not the answers to a query. The users still need to open some of the documents found and figure out the answer to a query on their own.

Flexible querying, which is of interest here, can be viewed as a case of the activity known in the literature as “question answering.” An overview and a comparison of a number of approaches and systems for question answering can be found in Ulicny et al. (2010). Since in this chapter we are interested in the methods that may be part of a number of different systems, rather than in the systems themselves, we provide just a short description of those approaches.

The vast majority of systems that store and retrieve data are based on representing the data in structured database formats, in which the structure of the tables, and the significance of each column, is specified in advance. Structured Query Language (SQL) commands and queries are then used to insert and retrieve data elements in tabular form. While it has become increasingly sophisticated over the years, SQL was initially envisioned as a natural language interface to databases. In web-enabled database applications, the SQL queries and commands are mostly hidden from the user and are dynamically constructed and executed when a user fills out and submits a form on a web page.

Wolfram Alpha represents a more sophisticated version of structured data querying. Wolfram Research is the producer of the major symbolic mathematical computation engine Mathematica. The Wolfram Alpha engine sits on top of quantitative data and other reference works that have been “curated” from authoritative sources (Talbot 2009). When a user queries Wolfram Alpha, the engine attempts to interpret the query’s intent so as to produce an output format that is the most likely to satisfy that query intention (sometimes providing both a geospatial overlay and timeline as output), without requiring the user to formulate the underlying Mathematica query him-or herself. While the curation process insures the trust relationship between the consumer and the producer, the recall of the retrieval process is still far from satisfactory.

Information producers may provide metadata for their data. For instance, a document might have metadata about the date when it was created, the author of the document, the location of the event described in the document, and such. This kind of metadata may be used in answering questions. MetaCarta’s technology is an example of system that uses this approach. MetaCarta (2010) processes documents in order to identify any expressions indicating locations (e.g., location name, postal code, telephone area codes), and marks up a representation of the document with geo-coordinates corresponding to those locations. The system can then be queried for documents that contain some combination of keywords and that have some geo-coordinates within a specified bounding box or radius. While this technology is pointing in the direction we are discussing in this chapter, it still does not go far enough to provide the flexibility of querying that is needed by today’s users.

Logic-based systems, such as Powerset, recently acquired by Microsoft and incorporated into its Bing search engine, parse texts into a logical representation, using sophisticated natural language processing. After analyzing free text and converting it into a logic-based representation, questions can be formulated as queries over these logical clauses and returned as answers. While this is the direction we are interested in, we are not discussing this solution here for two reasons: first, because it still includes natural language processing, and second, because these are proprietary solutions to which we do not have access.

In the following, we show how a query is represented in the query language for the Semantic Web–SPARQL. As an example, we have selected the maritime domain, although most of the terminology and content is only loosely related to the terminology used in the U.S. Navy.

We are assuming that the user (an information consumer) would like to issue a query that in natural language could be expressed as follows:

Show me all watercraft located in Region1 that may be involved in a suspicious activity.

Such a query could be expressed in SPARQL as

To be interpretable by a SPARQL query engine, the terms in this query would need to be either SPARQL’s keywords or be terms of a specific ontology. While this query will be the guide for the remaining discussion within this chapter, we will address various issues with this problem specification in small incremental steps. So, we begin by discussing the simpler query:

$"\mathrm{Show}\mathrm{me}\mathrm{all}\mathrm{watercraft}."$

(1)

The main purpose of this exercise with such a simple query is to expose the issue of determining the relevance of particular repositories to a query. In other words, assuming that all the accessible repositories are described in terms of an ontology, the issue is to identify which of the repositories contain some information that is relevant to the query.

An example of a partial view of an ontology (we call it the Query Ontology) that would be needed to represent such a query is shown in Figure 12.3.

This ontology includes eight classes organized in a hierarchy. The top-level class Object represents anything that might be of interest to us. Query is a class of all possible queries. Whenever a query is generated, it is assumed that an instance of this class would be created. For this particular example, we are assuming that the earlier mentioned query is represented by an instance called “CurrentQuery” (shown in the next view of this ontology—Figure 12.4). Repository is a class whose instances are specific repositories available on the network. The Vehicle class has a subclass called Watercraft, which in turn has a subclass called Boat. The main reason for having this classification is to see whether the execution of query (1) distinguishes between repositories that contain information about boats, watercraft, and vehicles in general (e.g., automobiles).

FIGURE 12.3 A Query Ontology.

FIGURE 12.4 Query Ontology and some of the class instances.

The Query Ontology includes two relations (in OWL, relations are called properties). The property inQuery has Query as its domain and Object as its range. This implies that the relation inQuery will include pairs of instances—the first element being an instance of Query and the second an instance of Object. The second property is contains, with domain Repository and range Object. This property represents that a repository contains (a class of) objects.

Since in this chapter we use RDF and OWL for representing knowledge, we will also use the RDF notion of triple for representing instances of properties. A triple consists of three parts, called predicate, subject, and object. The predicate is the identifier of a property, the subject is the identifier of an element from the domain of the property, and the object is the identifier of element from the range of the property.

To complete the description of the Query Ontology, we need to describe the classes RelevantThing and RelevantRepository. So first of all, the intent of having the RelevantThing class is to capture those objects that may be relevant to a given query. This class would be populated dynamically, based on a specific query. We will provide the mechanics of this dynamic construction after we discuss the instances of the ontology. Similarly, the class RelevantRepository is for capturing those repositories that are relevant to a given query. Again, this class is populated dynamically by the system since the designer of the ontology cannot be aware of every query the user might want to issue.

TABLE 12.1
Tabular Representation of the Property Contains

contains	Repo1	Watercraft
contains	Repo2	Domino
contains	Repo3	Boat
contains	Repo4	TheGeneralLee

Figure 12.4 shows a view of the Query Ontology after some of the classes have been instantiated. The instances are represented as dashed line rectangles and connected to their classes by dashed line arrows annotated with an “io” (for instance of). As we can see from this figure, there are four repositories on the network: Repo1, Repo2, Repo3, and Repo4. Additionally, there are three instances of Vehicle. TheGeneralLee is an instance of the top class Vehicle (it’s a car, but this is not inferable from this ontology). Domino is an instance of Watercraft, and MonkeyBusiness is an instance of Boat.

Although this is not visible in the graphical representation of the Query Ontology, this ontology also contains information about the properties inQuery and contains. Since query (1), represented in the ontology as CurrentQuery, mentions only Watercraft, the ontological description of the inQuery property also includes only one triple (predicate, subject, object):

$\langle \text{inQuery CurrentQuery Watercraft}\rangle$

(2)

We can also show the property information in tabular form. For example, Table 12.1 shows the property contains. Note that the repositories are described at two different levels of abstraction. Repo1 and Repo3 specify what classes of objects they contain (both Watercraft and Boat are classes). Repo2 and Repo3, on the other hand, specify what instances they contain (Domino and TheGeneralLee are not classes, but rather instances of other classes—Watercraft and Vehicle, respectively).

12.4  INTEROPERABILITY AND INFERENCE

The two main advantages of using ontological representation are the interoperability and the ability of inferring facts that are only implicit in the representation. Interoperability is demonstrated when one network node sends information to another, and the other node “understands” the information. For instance, when a node sends information to a querying node that Repo2 has information about MonkeyBusiness, which is a Boat, the querying node can take advantage of this information by inferring that MonkeyBusiness is a Watercraft, and thus is relevant to CurrentQuery. Thus interoperability is intimately related to inference. Without inference the information that MonkeyBusiness is a Boat might be useful to the querying node, but not to the specific query at hand. For instance, the query might actually ask explicitly about watercraft and boats. With the inference capability, however, the queries do not need to be that specific.

The term “inference” is often used in many different meanings. For instance, the running of an algorithm that computes the value of a function, given the values of the function’s parameters, is often termed automatic inference. Note, however, that for such an inference to be possible, two conditions must be satisfied: (1) an algorithm for the function must be implemented and (2) the only query that this algorithm can execute is the query for the value of this function, given the values of the function’s parameters. Obviously, one could implement a number of functions and then allow each of the algorithms to be queried by providing a function’s name and the list of parameter values in a prespecified order. One can do this kind of thing in MATLAB^®, or in any other function library.

Here, however, we are interested in the capability of formulating new queries expressible in a query language and deriving answers to such queries using logical inference. A full explanation of this kind of inference is beyond the scope of this chapter, so we only provide a simplified view of this kind of inference and then show examples of inferences throughout the rest of this chapter.

Logical inference is possible within a formal system, i.e., a system that includes a formal language, a theory (or axioms), and inference rules. Formal language is a language that has formal syntax and formal semantics. Formal syntax means rules for determining whether a given expression is in the language or not (sometimes referred to as legal sentences or well-formed formulas). Formal semantics refers to interpretations, which are mappings from the language to a mathematical domain (a set of individuals) and from sentences to truth values. Theories are then represented by axioms—sets of sentences in the language. Inference rules are rules that can be applied to the axioms of a theory to derive new sentences, which then become part of the theory. A formal system should be sound, i.e., given a consistent set of true sentences, it derives only true sentences, i.e., sentences that map to the value “true” by the interpretation function. Another desirable, but unachievable, feature of a formal system is completeness, i.e., the ability to infer all possible true sentences using the rules of inference.

An inference engine can then take a set of sentences in a formal language and apply the inference rules of the formal system to derive new sentences. The most important aspect of this process is that the inference engine is generic, i.e., it can be applied to any set of axioms expressed in the given language. Thus, referring back to the example of the calculation of the value of a function, the queries sent to the inference engine can be anything expressible in the formal language, rather than a predefined set. Thus the limit of inference is bound by the language, and not by a predefined set of functions and queries. While this discussion was abstract, we hope the reader will appreciate the value of logical inference from the rest of this chapter.

In this chapter, all of the examples are expressed in the Web Ontology Language (OWL) (W3C 2009a,b). OWL is a formal language with model theoretic semantics. A number of generic inference engines for this language exist. In our work, we use the BaseVISor inference engine (Matheus et al. 2006). This engine is freely available for research purposes, as are some others. BaseVISor is implemented in Java. It supports the OWL 2 RL dialect of OWL. OWL 2 RL includes most of the constructs of OWL 2, but additionally, it also supports the expression of user-defined policies (collections of rules). The importance of rules stems from the fact that rules allow to express some more complicated relationships than just pure OWL can. BaseVISor is an inference engine applicable to OWL axioms and user-defined policies represented as rules. It is a forward-chaining rule engine since the rules are executed in the “forward” direction. That is, rules are applied for as long as there is new information that can be derived by rule applications. Since at the low level all the axioms are represented as triples, BaseVISor has been optimized for processing RDF-and OWL-expressed information.

12.5  INFERRING RELEVANT REPOSITORIES

As was shown in the previous discussion, each of the repositories is annotated (see Table 12.1) in terms of the contains property. However, it is not known which of the repositories are relevant to a given query. These facts must be inferred using an inference engine. The inference process needs to rely on the facts stored in the ontologies. Thus, first, the query needs to be represented in ontological terms, and then the inference can be carried out. In this section, we are assuming that the query representation has been done and that some initial inference on the query representation has been carried out. We assume that this inference process has populated the class RelevantThing (see Figure 12.3) with instances of the things that may be relevant to the query. The details of this inference will be presented in the next section.

In order to infer the relevant repositories, the ontology must contain some information about what it actually means for a repository to be relevant. In our example, we formulate the relevance as follows.

A repository is relevant if it contains information about relevant things.

To express this fact (axiom) in OWL, we need to use the concept of OWL Restriction. In short, an OWL Restriction is a class whose instances are defined based on the values of the properties for which this class is the domain. So in this example, the class in question is RelevantRepository (a subclass of Repository). The property we use here is the property of contains, whose range is RelevantThing (remember that we assume the instances of this class have already been inferred). So we define RelevantRepository as the class for which the property contains has some values in RelevantThing. A snippet of OWL code that captures the essence of this fact is as follows:

The result of running BaseVISor is

RelevantRepo found three results.

Variables (X)

q:Repo1

q:Repo2

q:Repo3

This is obviously a correct result. BaseVISor was able to infer that Repo1 was relevant simply because Watercraft was explicitly in the query. It was also able to infer that Repo2 was relevant based on the fact that Domino is a Watercraft. Note that Repo2 did not mention anything about Watercraft in its annotation (Table 12.1). Repo3 was inferred to be relevant because it contained information about Boat, and because Boat is a subclass of Watercraft. Repo4 was (correctly) not considered relevant to this query since TheGeneralLee is a Vehicle but not a Watercraft.

The earlier explanation of the BaseVISor inference is based on intuition and common sense. A more formal explanation will be provided after we discuss the inference of RelevantThing.

12.6  INFERRING RELEVANT THINGS

The definition of the class RelevantThing is a bit more involved; it includes OWL’s notion of inverse property. An inverse property is defined in OWL as the inversion of domain and range of the property. So in this case, while the property inQuery has domain Query and range Object, the inverse has domain Object and range Query. The use of the inverse property is needed here because, similarly as in the case of RelevantRepository, we want to define the class RelevantThing as those objects for which the property—the inverse of inQuery—has the value of CurrentQuery.

Unfortunately, when we do just this, the reasoner only returns Watercraft as the relevant thing and Repo1 as a relevant repository. Although this is a correct inference based on the restriction on the inverse property, this is not exactly what we want. We would also like to see that subclasses of Watercraft (in this case Boat) as well as all the instances of Watercraft (Domino) and of Boat (MonkeyBusiness) show up as relevant things. While some of this kind of inference could be achieved within OWL, here we use rules for this purpose. In particular, we add two rules—one for finding the instances of the classes that are already in RelevantThing and another for the subclasses of the classes that are in RelevantThing. These rules are expressed in English as shown in the following:

1.  If C is an instance of RelevantThing and C is of type Class and I is an instance of C, then I is an instance of RelevantThing.

The OWL code for the definition of RelevantThing is shown as follows:

Note that we also used an additional OWL construct—unionOf. This construct is needed here so that the result of inference is complete. This construct puts together the already known instances of RelevantThing and those inferred.

With this rule, the reasoner can infer that also Domino and MonkeyBusiness are relevant things and that Repo2 is also a relevant repository. This inference still does not satisfy our expectation since it misses the fact that Boat is a relevant thing, too, and consequently Repo3 is a relevant repository. To achieve this result, we need to add one more rule so that subclasses of relevant classes are included in RelevantThing. In English, this rule can be expressed as follows:

2.  If C is in RelevantThing and C is a class and S is a subclass of C then S is instance of RelevantThing.

The result of running BaseVISor on this ontology supplemented by the two rules is shown as follows:

ThingsOfRelevantThings found five results.

Variables (X)

owl:Nothing

q:Watercraft

q:Domino

q:MonkeyBusiness

q:Boat

This result captures our intent. One might wonder what owl:Nothing is doing in the answer, but the reader should not be too concerned with this result. Owl:Nothing is an instance of every class, just as the empty set is a subset of every set.

12.7  RESTRICTING QUERIES TO GEOGRAPHICAL REGIONS

To demonstrate the querying about objects located in particular geographical regions, we use an ontology shown in Figure 12.5. This ontology consists of two parts—a sub-ontology for describing geographical features (on the right) and another sub-ontology for describing map objects. Each of these parts includes a top-level class—Object and MapObject, respectively.

FIGURE 12.5 A geographical feature ontology.

GeoFeature is a subclass of Object; it has a subclass—Region. This part also includes the class Vessel, which is attached to this ontology just to indicate that the class of object we are interested in is Vessel, rather than, say, Person or School. The main property for this part is contains, as well as its inverse—locatedIn. These properties will be used to capture facts about which regions contain particular objects.

The sub-ontology on the left is essentially an ontology for describing maps, which are two-dimensional surfaces with some objects attached to particular locations. The top-level object, MapObject, has two subclasses—Rectangle and Point. This part also includes four properties. The properties covers and inside are inverses of each other. Both of them are transitive properties. This means that whenever two facts hold—〈inside A B〉 and 〈inside B C〉, this implies that the fact 〈inside A C〉 also holds. In other words, whenever the first two facts are known, an inference engine can infer the third fact.

Rectangle has two properties—SW and NE. As the reader may guess, these are the properties that allow one to uniquely locate a rectangle on a map by showing two points (instances of class Point) that represent two corners of the rectangle—the South-West corner and the North-East corner, respectively. The SW and NE properties are declared (in the OWL code, not shown in the figure) to be functional. This means that for each rectangle there may be declared at most one value of the SW and NE properties, which is equivalent to saying that each rectangle has unique corner points on the map.

The two parts of the ontology are linked by the map property. In a sense, this property relates two vocabularies—the vocabulary of geographical features and the vocabulary of geometry.

To demonstrate the use of the geographical feature ontology, we first show an example of an ontological representation of a geographical region, with some vessels located in the region, and a query that could be issued by a user.

Figure 12.6 shows an example of instance annotation in the geographical feature ontology.

FIGURE 12.6 An example of an annotation of regions and objects.

The focus for this example is the region of Persian Gulf. It is mapped to a rectangle, called here PersianGulfContour, via the map property. This rectangle has two corners called here PGSWPnt and PGNEPnt. Each of the points has two data type properties called Lat and Lon (for latitude and longitude, respectively). The reader should not pay too much attention to the decimal values for this rectangle since the main issue here is to show how such an ontology can be used, rather than provide a precise geographical description of a particular region. This ontology also describes three other geographical features—the Strait of Hormuz (located in the Persian Gulf) and the Gulf of Oman, located in the Arabian Sea. Additionally, it includes three vessels—the Enterprise, located in the Persian Gulf, the Ohlafi, located in Strait of Hormuz, and the Baha, whose location is specified by its longitude and latitude.

All of this information has been given to the ontology explicitly. Running the reasoner on this ontology uncovers a few new facts, mainly because of the properties of the relations—transitive and inverse. And so the reasoner will infer that the Ohlafi is located in the Persian Gulf, the Arabian Sea contains the Gulf of Oman and that the Persian Gulf contains the Strait of Hormuz, as well as the Ohlafi and the Enterprise, and so on.

While all of these inferences may play a very significant role for interoperability, an even more interesting type of inference would need to go through combining the explicit information about the relationships among geographical features and objects with the reasoning about geometry. To achieve this, we developed a rule that relates the two sub-ontologies. In English, this rule can be expressed as follows:

3.  If an object O maps to a point OP on the map and OP’s longitude and latitude are within a rectangle R defined by its S-W and N-E corners, where R represents a region, then O is located in R.

When we implement this rule in the rule language of BaseVISor, BaseVISor infers, in addition to all the facts inferred and shown earlier, that the Baha is located in the Persian Gulf. This inference was based on the information about the geo-coordinates of the Baha, as shown in Figures 12.5 and 12.6.

12.8  DISCUSSION: INFERENCE OF SUSPICIOUS ACTIVITIES

The information annotation and processing steps we have shown in this chapter could be used for various purposes. For instance, one could use this kind of approach to query for vessels in a specific region, where the vessels are involved in some activities that could be considered as “suspicious” by the user. Here we just briefly outline the approach to achieve such a goal, rather than going into any details, since a full description of the solution of this problem would take too much space.

The first step would be to develop an appropriate ontology that could be used for annotating information, formulating definitions of what constitutes a suspicious activity, querying a network of information sources in order to find relevant information, and finally running inference in order to determine who, where, and when might be involved in such activities.

So the first question would be: what is a suspicious activity? Where does it stand in relation to other concepts? While answering such a question might lead to a very lengthy philosophical discussion, here we present our own proposal, without making any claims about the generality or correctness of our ontological interpretation. Following our experiences with developing ontologies for various applications and domains, we propose that suspicious activity, being a subclass of activity, can be viewed as a “Situation.” This view was promoted by Barwise and Perry (1983), and then Devlin (1991). On the other hand, if one follows the philosophy of Davidson (1967), one would call it an “Event,” rather than a situation. We are calling this situation just because we already have developed an ontology, called Situation Theory Ontology (or STO) (Kokar et al. 2009) which mainly incorporated the ideas from Situation Theory by Barwise and Perry (1983). So our view of suspicious activity is represented in the ontology shown in Figure 12.7.

According to this ontology, SuspiciousActivity is a subclass of Situation. Situation, on the other hand, is a subclass of Object that is linked with other classes—Goal, Individual, Relation, Attribute, and Rule via appropriate properties. So first of all, a Situation, or a SuspiciousActivity in particular, is an entity, a “first class citizen” of the ontology. It can have its own attributes and its own existence. Goal is what gives focus to a situation. Sometimes this is called relevance, or intent. Otherwise, without a specific goal, anything could be related to a situation. Goal is expressed as a relation. More specifically, for any situation, it is a single tuple that belongs to a relation, as expressed in set-theoretic terms. Perhaps the most important properties of Situation are relevantIndividual, describing the objects that participate in a specific situation, and relevantRelation, which describes the relations that must hold among the individuals, in order for the situation to take place. The existence of a specific relation is implied by a rule, either an axiom in the ontology or a rule specified in a rule language (e.g., the BaseVISor rule language). Situations, as any objects, can have their own attributes. Most typical attributes of situations include Time and Location.

FIGURE 12.7 An extended STO.

If we are interested in a specific domain, we need to extend the STO with some domain-specific concepts. For example, if we are interested in the maritime domain, we show such an extension with the classes of Vessel, Port, and Nation, which are subclasses of the class Individual. To support descriptions of suspicious situations, we introduced the properties of atPort (to say that a given vessel is at a specific port), flagState (to say that a given vessel carries a flag of a given nation), and embargoed-Nation (to say that a given nation is on the embargo list).

To show an example of a situation of type EmbargoViolation, we show a case in which the information sources include data on a Cuban vessel being reported at Boston Harbor, while an embargo on Cuba is in effect. The dynamic construction of the situation of interest starts with the creation of an instance of Situation and an instance of Goal. An instance of Situation is generated by the system. Suppose it is represented as BostonHarborAug19-1975.

The goal is the same kind of entity as query in our previous examples. As can be seen from Figure 12.7, Goal is related to an instance of Relation. Suppose the query is: “Is there a suspicious activity in Boston Harbor on August 19, 1975?” Suppose this query is represented in OWL as CurrentGoal, which in turn is related to an instance of the relation (property), which is expressed here as a triple 〈rdf:type BostonHarborAug19-1975 SuspiciousActivity〉. Here rdf:type stands for the relation “instance of”; this is a term of the OWL language. Note, however, that even though this triple looks like a fact that is in the current ontology, it cannot be asserted into the ontology since it represents a query—a question rather than a fact. In the literature (Sowa 2005, Hayes n.d.), these kinds of statements are called “propositions,” to distinguish them from facts.

FIGURE 12.8 Representation of an Embargoed Port situation.

The next step in the processing of this query, as in the first example of this chapter, is to derive the information that is relevant to this query. This may involve various kinds of processing, which may also include logical inference. In particular, the ontology of situations and suspicious activities may provide information on what types of Individual may be relevant individuals and what types of Relation may be relevant relations. For instance, our ontology in Figure 12.7 shows that the relevant types of Individual are Vessel, Port, and Nation, while the relevant relations are atPort, flagState, and embargoedNation.

The result of the processing of this situation is (partially) shown in Figure 12.8. In this figure, we can see the current situation (BostonHarborAug19–1975), attributes of this situation (location and time), relevant individuals, and the relevant relation shipAtEmbargoedPort, which is a sub-property of relevantRelation. It is assumed that the class EmbargoViolation is defined by the relevant relation shipAtEmbargoedPort. According to the ontology, this relation is implemented by a rule, which then can be executed by BaseVISor.

12.9  CONCLUSION

The main objective of this chapter was to show the utility of ontologies in situation awareness in particular and in information integration in general. The discussion was focused on a network centric environment in which multiple information producers and multiple information consumers exist. In this kind of scenario, it is quite difficult for a user to know what information is available at particular network nodes. A solution to this kind of a problem is to annotate all of the information sources so that an automatic information collection system can decide whether a particular information source has some potentially relevant information to a user’s query. Since the user queries are generated dynamically, and since the variety of the types of queries may be infinite, it is not possible to list all of the possible queries during the design of a net-centric system. Instead, a way of inferring the relevance of a specific information source to a given query is needed. We have shown both the inference of which sources are relevant and which things are relevant to a given query.

Another problem with situation awareness is to be able to narrow the queries to particular areas or geographical regions. In this chapter, we showed how this kind of knowledge can be represented using ontologies and how a generic inference engine can draw the appropriate inferences by means of OWL axioms and domain-specific rules.

Finally, to conclude this chapter, we provided a discussion of how much more complicated problems, like detecting suspicious activities in maritime domain scenarios, can be achieved within the same kind of framework.

Throughout the discussion, we stressed two aspects that are addressed by the use of ontologies: interoperability and inference. Interoperability means that particular nodes in a net-centric environment can understand what other nodes ask for or send. Inference means that facts that are only implicit in the information can be made explicit by the use of inference engines. Nodes can take advantage of their inference capability by inferring facts locally, rather than sending all the information over the communication links. Both the interoperability and the inference capability are limited only by the language used to represent ontologies and not by algorithms that need to be developed for any specific case.

REFERENCES

Barwise, J. and J. Perry. 1983. Situations and Attitudes. Cambridge, MA: MIT Press.

Cebrowski, A. K. and J. J. Garstka. 1998. Network-Centric Warfare: Its origin and future. U.S. Naval Institute Proceedings, 124(1):28–35.

Davidson, D. 1967. The Logical Form of Action Sentences. Pittsburgh, PA: University of Pittsburgh Press. Reprinted in Essays on Actions and Events. Oxford, U.K.: Clarendon Press (1980).

Devlin, K. 1991. Logic and Information. Cambridge, MA: Cambridge University Press.

Genesereth, M. R. and R. E. Fikes (Eds.). 1992. Knowledge Interchange Format, Version 3.0 Reference Manual. Computer Science Department, Stanford University, Stanford, CA, Technical Report Logic-92-1.

Gruber, T. 2009. Ontology. In The Encyclopedia of Database Systems, L. Liu and M. Tamer Özsu (Eds.). Berlin, Germany: Springer-Verlag.

Hayes, P. n.d. IKL Guide. Latest version available at: http://www.ihmc.us/users/phayes/IKL/GUIDE/GUIDE.html (Accessed on June 28, 2012).

Kokar, M. M., C. J. Matheus, and K. Baclawski. 2009. Ontology-based situation awareness. Information Fusion, 10:83–98.

Matheus, C., K. Baclawski, and M. M. Kokar. 2006. BaseVISor: A triples-based inference engine outfitted to process RuleML and R-entailment rules. Proceedings of the 2nd International Conference on Rules and Rule Languages for the Semantic Web, Athens, GA.

Matheus, C. J. and B. Ulicny. 2007. On the automatic generation of an OWL ontology based on the Joint C3 Information Exchange Data Model. 12th ICCRTS, Newport, RI, June.

MetaCarta. 2010. Available at: http://www.metacarta.com/products-platform-information-retrieval.htm (Retrieved January 2010).

MIP, Joint C3 Information Exchange Data Model (JC3IEDM Main), Greding, Germany, December 2005.

Network Centric Operations and Interoperability, Network Centric Operations Industry Consortium. n.d. Available at https://www.ncoic.org/home (Accessed on June 28, 2012).

Pepper, S. and G. Moore. 2001. XML Topic Maps (XTM) 1.0. Available at: http://www.topicmaps.org/xtm/1.0/

Sowa, J. F. 1992. Conceptual graphs summary. In Conceptual Structures: Current Research and Practice, P. Eklund, T. Nagle, J. Nagle, and L. Gerholz (Eds.), pp. 3–52. Chichester, U.K.: Ellis Horwood.

Sowa, J. F. 2005. Propositions. Available at: http://www.jfsowa.com/logic/proposit.htm

Talbot, D. 2009. Search Me: Inside the launch of Stephen Wolfram’s new “computational knowledge engine.” Technology Review, July/August. Available at: http://www.technologyreview.com/featured-story/414017/search-me/

Ulicny, B., C. J. Matheus, G. M. Powell, and M. M. Kokar. 2010. Current approaches to automated information evaluation and their applicability to priority intelligence requirement answering. Proceedings of the 2010 International Conference on Information Fusion, Fusion’10, ISIF, Edinburgh, UK.

W3C. 2009a. OWL 2 Web Ontology Language Direct Semantics. W3C Recommendation, October 27, 2009. Available at: http://www.w3.org/TR/2009/REC-owl2-direct-semantics-20091027/

W3C. 2009b. OWL 2 Web Ontology Language Document Overview. W3C Recommendation October 27, 2009. Available at: http://www.w3.org/TR/owl2-overview/

W3C. n.d. SPARQL Protocol and RDF Query Language Standards. Available at: http://www.w3.org/standards/techs/sparql#stds (Accessed on June 28, 2012).