- We describe a strategy for performing semantic searches for analyzing military intelligence. Our strategy allows the analyst and the query engine to work together to reduce a complex query into simpler queries. The answers for the simpler queries are combined into answers for the original query. The queries can be refined using rules defined by the analyst or analytics created by a data scientist. Our strategy uses an alternative approach to semantic modeling than the state-of-theart approaches based on OWL. OWL is an implementation of a branch of mathematical logics designed specifically for semantic modeling called description logics. Our strategy uses a branch of mathematical logics called type theory. We use type theory because of the long history of developing systems based on type theory for reasoning interactively. We demonstrate with an example how the strategy can be used to answer questions posed by analysts that couldn't be answered using conventional methods.
INTRODUCTION
"The Army is working closely with the intelligence
community and other Defense Department partners, including
the Navy, in developing cloud-based systems for battlefield
intelligence."[
The current state-of-the-art for military intelligence
analysis focuses on the analyst using visual aids and various
retrieval techniques, such as faceted search and querying, to
perform this inference manually [
Some of the analytics used in a query or search may be
different from the analytics used in ETL (extraction,
transformation, and load). In ETL, analytics are used primary
for entity and feature extraction, entity resolution, and entity
fusion [
The behavior of an analytic can be specified as the logical implication of the postcondition from the precondition. The precondition is a logical statement that must be satisfied in order for the analytic to produce valid output. The postcondition is a logical statement that describes the characteristics of the concepts and relationships produced by the analytic. In the simplest case, the specification of an analytic could be defined as ! → ! , where ! is the precondition and ! is the postcondition. For example, the precondition of the analytic for associating a family and an external organization would be 'for any ? ! ∈ Family and ? ! ∈ National(Organization there exists a ? ! ∈ Family such that ? !!attack!? ! and ? !!attack!? ! '. The postcondition would be ' ? !!common!interests!? ! '.
The examples above may mislead the reader to believe that
first-order logic would be sufficient for expressing the
precondition and postcondition. However, first-order logic
doesn't support cases when analytics can operate on a set of
concepts and roles. For example, consider an analytic that uses
numeric calculations to determine relationships, such as
common neighbor algorithms [
The query engine could use the specification of an analytic as a rule for solving an intelligence requirement. If the specification of an analytic is ! → ! and the intelligence requirement can be reduced to !, then the solution to the intelligence requirement would be the concepts and relationships that the analytic produces that satisfy !.
In this paper, we present a strategy for analyzing intelligence data using an interactive query language. When a user specifies a query, the query engine solves the query by refining it into new queries. If any of the new queries cannot be answered, it asks the user to assist it. The user assists the query engine by specifying an analytic or rule that can solve the query or reduce the query into new queries. This process continues until all queries are answered or until there is a query that cannot be answered. The query engine keeps track of this process and combines the answers from the generated queries into an answer for the original query. At the heart of the query language is the type theory TT-IQ, Type Theory for Interactive Querying. The query engine for TT-IQ consists of a framework that allows a data scientist to define analytics that can be included in query processing and for analysts to add new rules.
This paper is outlined as follows. First, we present work related to our strategy. Then, we use an example to demonstrate interactive querying. Next we give an overview of TT-IQ. Finally, we conclude the paper with a discussion of our strategy.
II.
Our strategy is similar to approaches that use a semantic
network or ontology for refining queries. These approaches,
such as QUICK [
Researchers at GMU have spent over 15 years developing
strategies that could be used for interactive querying [
K-DTT [
Type theory isn't the only method of using higher-order
logic for semantic modeling. Classical higher-order logics have
been used for semantic modeling as well [
Rule-based approaches for semantic search, such as
TupleGenerating Dependencies [
III.
In this section, we give an overview of how interactive querying is performed. Interactive querying is analogous to proving a type judgment. Informally, a typing judgment consists of a goal and a set of assumptions. The goal is the assertion we want to prove. The assumptions represent facts and statements from the knowledge base. Therefore, it consists of logical statements about the semantic meaning of concepts and relationships.
Fig. 1 shows an example proof created from an interactive query for attacks in a region that may have involved a specific person. We assume the analyst only knows that the person has a set of features observed by an interrogator, such as facial marks, height, and the number of a cell phone belonging to the detainee. This query is stated as a judgment that appears as the root of the proof tree. Here we state the judgments informally in natural language. The assumptions in the judgments in Fig. 1 contain a definition of a type representing the concepts Attack and Person; an object representing the features of the detainee; features of the detainee; declarations of the predicate symbols, such as involving; and definitions of data types that represent cell phone numbers and regions. The assumptions also contain a taxonomy of properties and features. The taxonomy is defined as a partial ordering on predicate symbols and attribute names.
The query engine determines which tactics can be applied
based on whether the conclusion of a tactic matches the goal of
a judgment. The query engine uses the type compatibility
relationship [
Each tactic has a conclusion and zero or more antecedents. When a tactic matches a judgment, the query engine creates new judgments for each antecedent. For example, the Narrow Concept tactic is a built-in tactic that replaces a type ! in a term with a subtype of !. This tactic has two antecedents. One antecedent is a judgment that asserts the replacement type is a subtype of the substituted type. The other antecedent is the same as the conclusion except all occurrences of the supertype are replaced with the subtype. Fig. 1 only shows the second antecedent because the first antecedent can be proved automatically using TT-IQ's subtyping relationship.
In practice, the query engine will only show the judgments that require assistance from the user. There may be multiple tactics that can be applied to a judgment. The compatibility relationship can rank the tactics that match best. However, if two tactics have the same rank, then the user will need to select the tactic to apply.
Narrow Predicate is similar to Narrow Concept, except Narrow Predicate replaces a predicate symbol with another predicate symbol. Therefore, Narrow Predicate has antecedents to prove that the replacement predicate is a sub-property of substituted predicate. This requires two antecedents: an antecedent to prove that the replacement property is a subproperty of the existing property and an antecedent to prove that the type of the sub-property is a subtype of the type of the super-property. The first antecedent has to be proved using the taxonomy of the properties and features. The tactic also has a third antecedent that contains the sub-property instead of the super-property. The proof tree in Fig. 1 shows the judgment produced from the third antecedent. In particular, it shows "involving" replaced with "near".
The judgments produced by Concept Introduction illustrate the need for dependent judgments. Normally in type theory and in sequent calculus, judgments of the same parent are independent of each other. However, when using interactive proofs to query for data, terms created on one branch could be used in a judgment on a different branch. Notice that two of the goals produced by Concept Introduction contain ≔ . This special constructor informs the query engine to create a reference to the term that satisfies the type on the right hand side of≔. At some point, a tactic will be invoked that uses an analytic to create objects or find objects in the knowledge base to bind to the reference.
The Geo Search tactic uses an analytic to bind a reference to a collection of terms that are within a specific region. Geo Search uses the goal as the criteria to search for objects within a specific region in the knowledge base. More specifically, Geo Search has a conclusion that has a type that contains one attribute, location. The type of location is the supertype of all types that could be used as the criteria for a geospatial search, such as KML. This type matches any type that has an attribute that is compatible with KML and the name of the attribute is interchangeable with location. The taxonomy determines which attributes are interchangeable with location. The tactic uses this attribute as the search criteria. In practice, the tactic may also require a time range.
Person Observation is a tactic that is created by a data scientist. In other words, it is an analytic that creates concepts inductively. This means it creates the definition of a type by generalizing existing data. Let's assume that Person Observation examines SIGINT data for calls originating form or made to the telephone number of the cellphone in the possession of a detainee. The time and location of the each call is used as an observation point of the person. In theory, a new triple is added to the knowledge base that links the person to the time and location of the call. In practice, the query engine may not create the triples. Instead, the query engine may define a way to create the triples on demand without altering the knowledge base unless directly instructed to do so. This approach is essential for cloud-scale data because it doesn't perform any destructive modifications if the analyst wants to back out changes. Instead the query engine could have a local cache containing the new triples. The modifications could be made permanent only when explicitly specified by the analyst or a data scientist.
The antecedent and conclusion of a tactic based on an analytic is determined by the precondition and postcondition of the analytic. The system uses the precondition as the antecedent and the postcondition as the conclusion. For Person Observation the postcondition states that there exists a concept ! where each object is a Person that has the features of the detainee and whose locations correspond to the locations of the cell phone. The precondition requires that there exists a person in the knowledge base who has the features of the detainee. To satisfy the precondition, the analyst will need to add the detainee to the knowledge base. The precondition also requires that we can determine the locations of the cell phone. We assume another analytic will determine this location. For brevity, assume that the query engine can prove this automatically. As a result, it isn't included in Fig. 1.
We envision a suite of tactics that discover relationships between an entity and an event. These tactics use analytics that can create new relationships. In other words, they can add new triples to the knowledge base. Nearness Predicate belongs to this suite. Nearness Predicate uses an analytic that creates new triples using the near predicate. In other words, it creates triples of the form (! near !) where ! is an entity and ! is an event.
IV.
OVERVIEW OF TT-IQ
In this section, we give the formal definition of TT-IQ. Due to space limitations, we omit some rigor that would be found in a normal presentation of type theory.
Both types and objects are terms. We define the terms ! and ! as follows. !, ! ≔ ⊥ !! !|! ! ! !!, … , !! !. ! !.size tt|ff !! = !!, … , !! = !! |[!!, … , !!!]!! !! ∧ !! ! ∨ !! ! → !!|¬!|! !!, … , !! prop !! ℛ !!: !!× …×!!!: !! !∗| !: !|!′ |∀!: !. !′|∃!: !. !′!|∀! ≤ !. !!|!∃! ≤ !. !!|!!
In the definition of terms, ! and ! range over strings and numbers respectively; ! ranges over attribute names; and ! and ! range over variables. The term ⊥ represents null. The terms tt and ff represent true and false, respectively. The terms of the form !! = !!, … , !! = !! represent records. Each !! = !! in a record represents an attribute where !! is the name of the attribute and !! is the value of the attribute. The terms of the form !. ! represent selecting the value of an attribute whose name is ! from a record ! . Terms of the form [!!, … , !!!] represent lists. Terms of the form !.size represent the number of elements in the list !. ! and ! range over predicate symbols and function symbols, respectively. ! is the type of strings and ℛ is the type of numbers. We call the terms ! , ! , ! , !(!!, … , !!) , !. ! , !.size , tt , ff , !! = !!, … , !! = !! , and [!!, … , !!!] objects. We call all of the other terms, such as !: !|!′ and ∃!: !. !′, types.
Terms of the form !!: !!× ⋯×!!!: !!represent record types and terms of the form !∗represent list types. The type p ro p represent the type that contains types that represent logical formulas, such as ! ∧ !′ and ! !!, … , !! . Any type created using terms in p ro p will also be in p ro p . For example grt! 5,4 ∧ !grt! 7, 3 is a member of p ro p . Terms of the form !: !|!′ represent set types. Intuitively a set type !: !|!′ !represents a list of objects of type ! where each member of the list makes the type representing the logical formula !′ true. We call ! a reference. We use ! to support injecting terms created by an analytic running in a separate subsystem. Notice there are two kinds of quantifiers, those that range over objects,!∀!: ! and ∃!: !, and those that range over types, ∀! ≤ ! and ∃! ≤ !. In the quantifiers that range over objects, !: ! means ! is a member of type !. So, ∀!: ! means for all terms ! that are members of the type ! . In the quantifiers that range over types, ! ≤ ! means ! is a subtype of !. So, ∀! ≤ ! means for all types ! that are subtypes of !.
Notice that types may contain objects. For example, if grt is a predicate symbol that represents greater than equal to and abs is a function symbol that represents absolute zero, then !: ℛ|grt abs ! , 0 is a type that contains the objects 0 and abs(!).
Given any two terms ! and !′ and a variable !, ![!!/!] is the term produced by replacing all free occurrences of ! in ! with !′. For example, ! ! !, ! , ! 3/! is ! ! 3, ! , 3 . For two terms ! and !, we write !: ! to mean that ! inhabits the type ! or ! is a member of the type !. For example, 3: ℛ and 3,4,5 : ℛ∗ . We give some of the rules of TT-IQ for determining which terms inhabit a type in Fig. 4. !! ⇀ !!! ⋯
!! ⇀ !!! (!! = !!, … !! = !!) ⇀ (!! = !!! , … , !! = !!!) (REC. ⇀) ! ⇀ (!! = !!, … , !! = !!)
! = !! !. ! ⇀ !!
(FIELD!SELECTION ⇀) !! ⇀ !!! ⋯
!! ⇀ !!! [!!, … , !!] ⇀ [!!! , … , !!!] ! (LIST ⇀)! ! ⇀ [!!, … , !!] (LIST!SIZE ⇀)!
!.size ⇀ ! ℑ!!(!!, … , !!)! ↦ !
!(!!, … , !!) ⇀ ! ℑ!!(!!, … , !!)! ↦ ! !(!!, … , !!) ⇀ ! (FUNCTION!APPLICATION ⇀)! (PREDICATE!APPLICATION ⇀) ℑ!!!! ↦ ! !! ⇀ !
(REFERENCE ⇀)! Fig. 2. Evaluation rules for terms that do not evaluate to themselves.
The specification of an analytic can be generalized as follows. The specification will need to contain universal quantifiers to allow the query engine to pass in types and objects to the analytic. If the analytic takes in ! types and ! objects, then the specification will need the quantifiers ∀!! ≤ !!. ⋯ . ∀!! ≤ !! and ∀!!: !!. ⋯ . ∀!!: !! . We abbreviate these as ∀! ≤ ! and ∀!: ! , respectively. An analytic may output types and objects. If an analytic generates ! types and ! objects, then the specification will need to contain existential quantifiers ∃!! ≤ !!! ⋯ ∃!! ≤ !!! and ∃!!: !!!. ⋯ . ∃!!: !!! . We abbreviate these as ∃! ≤ !! and ∃!: !!, respectively. The specification will also contain the precondition and the postcondition of the analytic. We denote these respectively as ! and !. The general term that represents the specification of an analytic is specified in (1).
∀! ≤ !. ∀!: !. ! → ∃! ≤ !!. ∃!: !!. !
In practice, the number of inputs and outputs of an analytic will be small. For example, the specification of Geo Search, an analytic that finds objects that occur within a region, is as follows.
∀! ≤ location:KML . ∀!:KML.true
→ ∃!: !∗. ∀!: !.inRegion !, !
In the specification of an analytic, the !'s and !'s in (1) represent concepts and the !'s and !'s represent individuals. An analytic may also take relationships as input and output relationships. The relationships an analytic takes as input are defined by !, and the relationships an analytic produces are defined by !. For example, the Geo Search analytic outputs a relationship inRegion !, ! . The domain is defined by the type of ! which is KML and the range is all subtypes of (1) (2) location:KML . Geo Search doesn't take any relationships as input.
Traditionally, the definition of a type theory includes rules for evaluating terms. As a result, most type theories in the literature are definitions of statistically typed functional programming languages. TT-IQ has rules for evaluation. We list a subset of the rules in Fig. 2. TT-IQ should not be considered a functional programming language. TT-IQ does not contain a construct for creating functions. Instead, TT-IQ defines a means for injecting functions and relations into it that are executed by an external subsystem or programming language. We represent the external subsystem or programming language as an interpreter. For any term !, an interpreter maps ! to a term !′ . We use ℑ to denote an interpreter. We write ℑ ! ↦ !′ to mean that ℑ interprets ! as !′ . The interpreter is used to evaluate the application of function symbols and predicate symbols. For a term !, we write ! ⇀ !′! to mean ! evaluates to !′ . The rules FUNCTION!APPLICATION ⇀ and PREDICATE!APPLICATION ⇀ indicate that the application of a function symbol or a predicate symbol to a sequence of terms is equal to the interpretation of the application of the function symbol or predicate symbol. These rules do not require that the arguments of the function symbol and predicate symbol be evaluated before passing them to the interpreter. As a result, the interpreter can determine the mode of evaluation, such as lazy evaluation or eager evaluation. The evaluation rule REFERENCE ⇀ illustrates the ability of the interpreter to manage storage of instance data. Intuitively REFERENCE ⇀ means that a reference to a concept evaluates to the set of individuals in the concept. The concept is defined by the type ! and ! is a pointer to an index, graph or other data structure that contains members of the concept.
A paramount feature of TT-IQ is subtyping. TT-IQ uses a unique feature to typing that is required for semantic modeling. Traditionally, subtyping on record types is the same as class inheritance. In other words, a record type ! is a subtype of !′ if all the attributes in !′ are also attributes in !. This means that for every attribute named ! in !′ there is attribute ! in T. However, this definition of subtyping ignores the semantic meaning of attribute names. Two attributes can have different names, but mean the same thing. As a result, TT-IQ defines subtyping so that attribute names do not have to be syntactically the same, but semantically the same. Actually, in TT-IQ attribute names do not need to be equivalent, but one attribute name has to be subsumable by the other. The definition of subtyping in TT-IQ uses a partial ordering on attribute names to define subtyping. Due to space limitations we are unable to define the complete definition of subtyping. We do show the subtyping rule for record types below. ! ≥ ! for!! = 1, … , !
′ !! ⊑ !! !! ≤ !′! !1: !1× ⋯×!!: !! ≤ !′1: !′1× ⋯×!′!: !′!
In "Interactive Querying" we showed examples of tactics. A tactic is a program or script that returns a proof tree. A proof tree represents a proof of a type judgment. Intuitively a type judgment asserts that a term belongs to a type. A type judgment has the form ! ⊢ !: !′ where ! represents an environment and !: !′ represents the assertion that ! inhabits !′. The environment, !, of a type judgment consists of type assignments, terms, predicate symbols and function symbols. It also consists of pairs of predicate symbols and attribute names. These pairs form a partial ordering, ⊑. If !!, … , !! are type assignments of terms, predicate symbols, and function symbols, then ⊑; !!, … , !! is an environment.
Only the rule engine can execute a proof rule. The rule engine is a subcomponent of the query engine. Given a rule, a proof tree, and judgment in the proof tree, the rule engine will apply the rule to the judgment. The result will be a proof tree that uses the antecedent of the rule to create children of the judgment. Fig. 3 illustrates the relationship between the query engine, the rule engine and the interpreter.
TT-IQ does not define the language in which tactics are written. An interpreter performs evaluation of tactics. Detailed discussion of the language for creating tactics is outside the scope of this paper. In this paper it suffices to say that a tactic takes as input a typing judgment and outputs a proof tree. The root of the tree has to be the input judgment. The tactic has to use proof rules to create the proof tree.
Fig. 4 contains a few proof rules for TT-IQ. We use ∃!!ELIMINATION to specify that an analytic will retrieve the individuals of a concept represented as !!or a subtype of !. The rule uses a concept reference so that we can postpone selection of the analytic until we have a judgment whose type matches the postcondition of an analytic. We use ANAYLIC!EVAL to prove judgments that require an analytic. ANAYLIC!EVAL generates concepts and individuals that satisfy a condition specified as a type. The condition can represent a relationship or the search criteria for a query. The condition is specified as the type ! in ANAYLIC!EVAL. An analytic whose postcondition matches ! is used to generate the concepts and individuals that satisfy the condition specified as !. In the rule, the analytic is ! and its postcondition is !. The top-right hypothesis is used to establish that ! matches ! if replacing the free variables in ! produces a term that is a supertype of !. The terms that replace the free variables are the inputs to the analytic, ! and !, and the outputs of the analytic, ! and !. ! is a sequence of types !!, … , !! and ! is a sequence of objects !!, … , !! . Likewise ! is a sequence of types !!, … , !! and ! is a sequence of objects !!, … , !! . Intuitively, ! and ! are the concepts and individuals required by the analytic to produce the concepts and individuals ! and ! that satisfy the relationship defined by !. All free variables in each !! and !! are declared in !. Each !! and each !! do not have any free variables.
Since ! and ! represent the input to the analytic, we need to verify they satisfy the precondition !. The three hypotheses of ANAYLIC!EVAL on the left achieve this. The top two hypotheses are judgments to verify that the inputs to the analytic have the correct types. The last of the three hypotheses verifies that ! is true with all of its free variables replaced with inputs to the analytic. The top hypothesis on the right is used to verify that the postcondition is true for the inputs and outputs of the analytic. The second hypothesis from the top on the right indicates that the output of ! on ! and ! produces ! and !. Recall from FUNCTION!APPLICATION ⇀ in Fig. 2 that an interpreter is used to produce ! and !. The hypothesis on the bottom-right indicates that each !! evaluates to a list of terms of type !! and that each !! evaluates to a term that is of type !!. This hypothesis shows that we intend to represent concepts ! as list of terms of a specific type. The ∃{}!REWRITE rule makes use of the fact that for any term !, if !: !: !|!! then !: ! and ! ⊢ !!!⃗ ≤ !!!!⃗ ! ⊢ !!⃗: !!!⃗ !, !! ≤ ! ⊢ ![!!!/!]:prop ! ⊢ ∃! ≤ !:prop
! (∃!!ELIMINATION) ! ⊢ ∃! ≤ !. (∀!: !. !!) ∧ !!!:prop ! ⊢ ∃! ≤ !!: !|!!!!′!. !!!:prop (∃{}!REWRITE) ! ⊢ !! ≤ ![ !!!!⃗/ !!⃗][!!!⃗/!⃗][!⃗/!⃗][ !!⃗/!⃗] !( !!⃗, !⃗) ⇀ ! !!!!⃗, !!!⃗! ! ⊢ ![!⃗/!⃗][ !!⃗/!⃗]:prop !!!! ⇀ !!!!!"#!! ⊢ !!: !!∗ !! ⇀ !!!!!!"#!! ⊢ !!!: !!! !, !: ∀!⃗ ≤ !!⃗. ∀!⃗: !!⃗. !! → ∃ !!⃗ ≤ !!!!!⃗!. ∃!⃗: !!!!⃗!. !!, !! ⊢ !:prop ! ⊢ ! ≤ ! ! ⊢ ∃! ≤ !. !!:prop ! ⊢ ∃! ≤ !. !′:prop! ! (NARROW!TYPE) (ANAYLIC!EVAL) !! !!!"#$%&'!!"#$%&'(!!"#$$%&' ! !! ! !!!"#!!"#$%!&" !! ! ! !! ! ! !!!"#$%&! ! !!!"#$%&"'! ! ! !"#$ !! ! ! !!! !! !!! !!!"#$!!! !!! ! !! !!!"#$%&'!!"#$%&'(!!"#$$%&' ! !! ! !!"#!!! !! !"#$%!&" !! ! ! !! ! !!!"#$%&! ! !!!"#$%&"'! ! ! !"#$ !! ! ! !!! !! !!! !!!"#$!!! !!!
Recall in Fig. 1, we used the Narrow Concept tactic to replace Attack with IED. Narrow Concept contains code to select the appropriate concept to use as the subtype for the Narrow Type rule. After it finds a subtype, it asks the rule engine to apply Narrow Type to a target type judgment in a proof tree. The rule engine creates a new judgment using the antecedent of Narrow Type as a template. The new judgment is added as a child of the target type judgment. The rule engine returns the new proof tree to Narrow Concept and Narrow Concept returns the proof tree to the query engine. Fig. 5 contains a portion of the proof tree created from the Geo Search and Concept Introduction tactics in Fig. 1.
A query engine for intelligence data needs to support
various levels of believability. We can support believability in
TT-IQ by using type modality [
The formalism of TT-IQ and the method of reasoning
employed by TT-IQ may be too complicated for an analyst.
We don't expect the analyst to specify queries in the formal
language of TT-IQ, but in natural language similar to that used
in Fig. 1. We could employ a technique similar to that used in
[
Since a type may have multiple subtypes, a tactic that finds or creates a subtype of a type could be nondeterministic. In other words, the tactic may not produce the same subtype for the same supertype. As a result, the query engine could produce different results for the same query over the same data. We can resolve non-determinism by asking the user to select the appropriate subtype. This approach would be similar to faceted search. The query engine would require the end user to select from a list of subtypes to use as a candidate to narrow the search space.
Currently, we are in the planning stage of creating an implementation of TT-IQ. We plan to create an implementation of TT-IQ using Coq and R. Coq will provide the interactive reasoning capability. R will be used as the language and runtime for defining and executing analytics. We anticipate having to add a library to R to provide a more seamless interaction with RDF than the existing R libraries.
We consider this implementation of TT-IQ a proof-ofconcept implementation. We plan to use this implementation to conduct research to address usability issues and determine strengthens and weaknesses of interactive semantic querying over automatic semantic querying.
The analyst workstation will contain an analytic framework that would provide an interface to support contribution of analytics written in a wide range of languages, such as MATLAB, C, Java, and Python.
VI.
CONCLUSION
In this paper, we showed how to apply techniques from ITPs (interactive theorem provers) to analyze military intelligence. Users of ITPs apply small programs called tactics in an iterative fashion to construct a proof. We demonstrated how tactics could be used to answer semantic queries interactively. Furthermore, we showed how to incorporate analytics that use machine learning, knowledge discovery, or network analysis into the querying process.
A. Future Work
In "Believability", we eluded to an approach to handle
uncertainty. Future work should investigate this approach.
Also, we should consider how to incorporate the approach in
[
In the future, we would like to investigate how to implement interactive querying in an existing military intelligence cloud system, such as the DCGS-A Cloud. We believe our approach to querying would be a good fit for the semantic enhancement approach adopted by the DCGS-A Cloud.
ACKNOWLEDGMENT
Rod Moten thanks Andy Zhao of Sotera Defense Solutions and Dr. Aaron Stump of the University of Iowa on their valuable feedback on the ideas expressed in this paper.