Enterprise Knowledge Integration Through Argumentation-Enabled Intelligent Decision Support Systems (Web@KIDSS)

Abstract

In Chap. 5, an Argumentation-enabled Web-based IDSS (Web@IDSS) was proposed to help decision makers represent, reason and integrate in formation that exits within their enterprise and/or in other enterprises and assist them in the decision-making process.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

6.1 Introduction

In Chap. 5, an Argumentation-enabled Web-based IDSS (Web@IDSS) was proposed to help decision makers represent, reason and integrate information that exits within their enterprise and/or in other enterprises and assist them in the decision-making process. This information integration is called as Enterprise Information Integration (EII).

With the current proliferation and widespread adoption of e-business, enterprises conduct business on an global level, and are often involved in collaborations and mergers with other enterprises on a global scale (Norta and Eshuis 2010; Alaranta and Henningsson 2008). In such cases, the decision/reasoning results produced by an enterprise’s Web-based DSS might need to be integrated with other Web-based DSS located within the enterprise and/or in other enterprises to obtain a comprehensive picture of the problem at an enterprise level to enable business managers to obtain better business insights and make better decisions. This information integration is called as Enterprise Knowledge Integration (EKI) as depicted in Fig. 6.1. EKI may be defined as an integration of the decisions/results generated from different Web-based DSS that may be potentially incomplete and/or contradictory into a single coherent knowledge to support either intra-enterprise decision making (i.e. decision making processes involving the departments of an enterprise) or inter-enterprise decision making (i.e. decision-making processes involving departments located in different enterprises). However, as pointed out in Sect. 2.8, the current generation of Web-based DSS are not able to represent, reason and integrate information that may be potentially incomplete and/or contradictory to provide support for either the intra-enterprise or inter-enterprise decision-making process. Due to this limitation, they do not provide any solution for EKI. To address this, in this chapter, a framework for Argumentation-enabled Web-based IDSS for EKI (Web@KIDSS) is proposed that provides a solution for EKI to facilitate either the intra-enterprise or inter-enterprise decision-making process.

Fig. 6.1

Interaction of an enterprise’s internal and external environment for Enterprise Knowledge Integration (EKI)

The proposed framework imports the reasoning chains generated by Web@IDSS and extends its functionality to publish them in a standard format over the enterprise’s intranet or the Internet. It then transforms the standard reasoning chains to DeLP format, evaluates them against the decision maker’s defined criteria defined as an integration scheme which is then followed by their integration using argumentative reasoning. The development of Web@KIDSS will advance the research in Web-based DSS as depicted in Fig. 6.2.

Fig. 6.2

Evolution towards intelligent information integration in an enterprise

The organization of this chapter is as follows: in Sect. 6.2, an outline of the problem to be addressed by using a case study to highlight the requirements and challenges for EKI in enterprise-wide decision making is given. In Sect. 6.3, an overview of the proposed Argumentation-enabled Web-based IDSS for EKI (Web@KIDSS) is provided. In Sects. 6.4–6.6, each component of the proposed framework is explained in detail and how it provides a solution to the problem highlighted in the case study is discussed. Section 6.7 concludes the chapter.

6.2 Case Study for Problem Definition

To explain the problem, consider the example of enterprise ABC, comprising different departments such as Information Technology (IT), Marketing (Mar) and Human Resources (HR), which has decided to relocate its departments to a new site. The business manager responsible for overseeing the move has instructed the manager of each department to provide recommendations and justifications for engaging the services of the XYZ relocation service to assist with the move by considering information such as:

• business-related information for the XYZ relocation service provider published on the Web along with the department’s business requirements, and

• customer feedback on the services provided by the XYZ relocation service provider.

Figure 6.3 depicts the possible interaction between the internal environment of enterprise ABC and the external environment that comprises information such as XYZ business policies and customer feedback on the services provided XYZ etc. In order to generate recommendations for relocation service provider XYZ, each department’s manager uses Web@IDSS to represent, reason and integrate XYZ business information with their departmental information (requirements) and customer feedback. Once each department in the ABC enterprise forwards its recommendation to the business manager, the latter will need to integrate the diverse recommendations about relocation service provider XYZ from each department into a coherent knowledge base which could help the business manager to reach a final decision, i.e. whether or not to engage the services of the XYZ relocation service provider. The challenges that confront the business manager are as follows:

• recommendations from each department need to be in a standard, shareable format;

• recommendations from each department need to be evaluated by testing them against the decision maker’s defined criteria. Such evaluation helps the decision maker to decide on the scope of the recommendation chain and whether or not to consider it for EKI;

• conflicts within and between the different recommendations need to be addressed in relation to the inter-enterprise or intra-enterprise decision making process.

Fig. 6.3

Interaction of enterprise ABC with external environment

In order to overcome the abovementioned challenges, the business manager requires a Web-based IDSS that offers the following functionalities:

• an interface to download the recommendations and save them in the knowledge base;

• an interface to define and apply an integration scheme over the recommendations saved in the knowledge base in order to evaluate their scope and whether or not to consider them for EKI;

• a reasoning mechanism that can resolve the conflicts between diverse recommendations and integrate them into an integrated knowledge base that may assist the decision makers in the intra-enterprise or inter-enterprise decision-making process.

To develop a Web-based IDSS with the abovementioned functionalities, the business manager’s requirements for a Web-based DSS for EKI are formalized as follows :

• sharing of recommendations in a standard format, such as AIF, that is understandable by other Web-based DSS in the inter-enterprise or intra-enterprise decision-making process;

• integration of recommendations which involves the definition and application of the integration scheme and argumentative reasoning to identify and resolve conflicts;

• justifiable explanation of the reasoning process and the results achieved;

• capability to provide a graphical representation of the reasoning process performed to achieve EKI in order to make it easily understood by non-technical persons such as the business manager.

Assumptions

• Enterprises ABC and XYZ and the feedback forum share a common vocabulary defined in OWL/RDF format and the predicates defined in the vocabulary are used for the specification of business rules.

• A declarative language for specifying the imported recommendation in the form of reasoning chains for knowledge integration in an enterprise.

• A declarative language with the capability of representing incomplete and contradictory information represented by reasoning chains.

• Information integration via an inference mechanism that can perform reasoning pertaining to incomplete and contradictory information from different sources.

• Reasoning chains have been produced by different departments of an enterprise by using Web@IDSS.

6.3 Proposed Framework for Argumentation-Enabled Web-Based IDSS for Enterprise Knowledge Integration (Web@KIDSS)

In this section, the proposed framework for the Argumentation-enabled Web-based IDSS for EKI is presented i.e. integrating the decisions/recommendations generated by different Web-based DSS into a coherent knowledge base to support the inter-enterprise or intra-enterprise decision making process. The proposed framework, presented in Fig. 6.4 consists of three layers as follows:

Fig. 6.4

Proposed framework with highlighted components exploited by Web@KIDSS

• 1. Information layer

        The information layer represents the structured information identified by decision makers for consideration during the decision-making process. This information comprises different reasoning chains published over the enterprise’s intranet or the Internet by different Web-based DSS located both within the enterprise and/or in other enterprises.

• 2. @IRRI layer

        This layer comprises a logic-based framework that enables Semantic Web applications such as Web-based DSS, to deal with information in the form of reasoning chains (e.g. recommendations generated by different Web@IDSS) which are potentially incomplete and/or contradictory and considers them for inter-enterprise or intra-enterprise decision making. It provides different modules to transform a reasoning chain into a standard, shareable format such as Argument Interchange Format (AIF) for publication on an enterprise’s intranet or the Internet. Additionally, it also provides a solution for considering different published reasoning chains, integrating them after applying the integration scheme and performing argumentative reasoning to resolve conflicts between them followed by representing them graphically to the decision maker to assist him in the decision-making process. The modules are as follows:

  • (a) Information and knowledge integration module provides functionalities for:

    • the transformation of a reasoning chain generated by a Web@IDSS into AIF format and its publication in OWL/RDF format over the enterprise’s intranet or the Internet. This ensures information from heterogenous sources is in a standard format to achieve EKI.

    • Enterprise knowledge integration which involves the following steps:

    • Import the published reasoning chains in AIF format and transform them into DeLP format (DeLP rules and facts) and save them in the knowledge base. Such transformation of reasoning chains from AIF to DeLP format enables the hybrid reasoning engine to perform the next steps.

    • Valuation of the reasoning chains which involves the following steps:

      • Re-construction of the reasoning chains from the knowledge base with the help of the argumentative reasoning module. The re-constructed reasoning chains are then modelled in the form of an argument by using the Toulmin model for the argument’s structure. The collection of reconstructed, modelled reasoning chains is called the recommendations space.

      • definition and application of the integration scheme on the recommendations space with the help of the argumentative reasoning module. This is to identify and consider only those reasoning chains for the next step that adhere to the decision maker’s required criteria. The reasoning chains that adhere to the decision maker’s defined criteria are saved in the valued recommendations set.

      • a Web-based form that displays the results produced during the valuation of a reasoning chain.

    • Generation an integrated recommendations space which involves the following steps:

      • identification and resolution of conflicts between the arguments in the valued recommendations set with the help of the argumentative reasoning module.

      • construction of new arguments once the conflicts have been resolved. This involves combining the premises of the arguments that support the same claim. The new arguments are saved in the valued recommendations set.

      • identification of unique conclusions/claims in the valued recommendations set followed by linking the supporting arguments to reach a conclusion/claim to form a reasoning chain. The construction of reasoning chains is carried out with the help of the argumentative reasoning module.

    • Graphical representation of the integrated recommendations space to assist the decision maker in the decision-making process. Additionally, this will provide functional support to the decision maker to query the knowledge base.

  • (b) Argumentative reasoning module is exploited by the information and knowledge integration module for the valuation of the reasoning chains and the generation of the integrated recommendation space.

• 3. Semantic Web applications layer

        This layer consists of Web@KIDSS which exploits the @IRRI layer and the information layer to achieve its objectives.

Before explaining the working of the proposed framework, in the next sub-section, important definitions and concepts are introduced to assist the understanding of the working of Web@KIDSS.

6.3.1 Important Definitions

In the following section, the formal syntax and semantics for Enterprise Knowledge Integration through the Argumentation-enabled Web-IDSS (Web@KIDSS) are defined.

6.3.1.1 AIF Argument Network

Rahwan et al. (2007) define an argument network $\Phi$ as a graph $G$ and set of forms $F$ consisting of

• a set $\mathcal {N}$ of vertices (or nodes) comprising I-Nodes and S-Nodes; and

• a binary relation $\mathop {\longrightarrow }\limits ^{edge}: \mathcal {N} \times \mathcal {N}$ representing edges between nodes

• a binary relation using an inference scheme from set $F$

such that $\not \exists \,\,(i, j) \in \mathop {\longrightarrow }\limits ^{uses(RA{\text{- }}node,scheme)}$ where both $i \in \mathcal {N}_{1}$ and $j\in \mathcal {N}_{1}$.

6.3.1.2 Argumentative Production System as an Argument Network

Given an argument graph $G$ and set of forms $F$ in an argument network $\Phi$, a Web@IDSS argument network $AG$ is defined as follows: $(\mathcal {W}\mathcal {M},\mathcal {R}, Args)$ where

• $\mathcal {WM}$: a set of information nodes i.e. $\mathcal {N}^{I}_{i,...,n}$, where $I$ represents the information nodes and $i$ represents the index of the node.

• $\mathcal {R}$ : a set of production rules or specifications to establish links between $\mathcal {N}^{I}_{i}$ nodes through $S$ node such that $\not \exists (i, j) \in \;\mathop {\longrightarrow }\limits ^{edge}$ where both $i \in \mathcal {N}_{1}$ and $j \in \mathcal {N}_{1}$

• $Args$: a set of arguments derived from $\mathcal {R}$, where each argument establishes a linked set of premises ($\mathcal {N}^{I}_{i})$ to a claim ($\mathcal {N}^{I}_{j}$) through $S$ node. Based on the forms of AIF ontology , the strict argument and defeasible argument are defined as follows:

  $$\begin{aligned} {\text{(Strict } \text{ argument) }} \mathcal {:N}^{I}_{i},......,\mathcal {N}^{I}_{j} \mathop {\longrightarrow }\limits ^{\textit{Uses}({\textit{R}A,deductiveScheme)}}\mathcal {N}^{I}_{k} \end{aligned}$$
  $$\begin{aligned} \text {(Defeasible argument)}: \mathcal {N} ^{I}_{m},......,\mathcal {N}^{I}_{n} \mathop {\dashrightarrow }\limits ^{\textit{Uses}({\textit{R}A,defeasibleScheme)}}\mathcal {N}^{I}_{o} \end{aligned}$$

The binary relation $\mathop {\longrightarrow }\limits ^{edge}$: $\mathcal {N} \times \mathcal {N}$ representing edges between nodes in Web@IDSS can be categorized as follows:

• Counter-argument: $\mathcal {N}^{I}_{i} \mathop {\dashrightarrow }\limits ^{Uses(CA{\text{- }}Node)}\sim \mathcal {N}^{I}_{j}$ such that $\mathcal {N}^{I}_{i}$ is a counter-argument $\mathcal {N}^{I}_{j}$

• Static defeat: $\mathcal {N}^{I}_{i} \mathop {\dashrightarrow }\limits ^{Uses(PA{\text{- }}Node)}\mathcal {N}^{I}_{j}$ such that $\mathcal {N}^{I}_{i}$ is has priority over $\mathcal {N}^{I}_{j}$

• Dynamic defeat: $\mathcal {N}^{I}_{i} \mathop {\dashrightarrow }\limits ^{Uses(PA {\text{- }}Node)}\mathcal {N}^{I}_{j}$ such that $\mathcal {N}^{I}_{i}$ has priority over $\mathcal {N}^{I}_{j}$

• Sub-argument: To represent the sub-argument relationship in AIF format, a blank-node is added into the argument network i.e.

  $\mathcal {N}^{I}_{i} \mathop {\dashrightarrow }\limits ^{Uses(Blank{\text{- }}Node)}\mathcal {N}^{I}_{j}$ such that $\mathcal {N}^{I}_{i}$ (claim of an argument) is a sub-argument of $\mathcal {N}^{I}_{j}$ (premise of an argument).

6.3.1.3 Predecessor and Successor Nodes in the Network

Given a graph $AG$ consisting of a set of nodes $\mathcal N$ and a relation $\mathcal {S} \subseteq \mathcal {N} \times \mathcal {N}$ defining the set of edges between the nodes, for each node n $\in$ $\mathcal {N}$, the set of its predecessor and successor nodes is defined as follows:

• A predecessor node : $\{x \in \mathcal {N} \mid (x, n) \in \mathcal { S}$ },

• A successor node : $\{x \in \mathcal {N} \mid (n, x) \in \mathcal {S}$ }.

6.3.1.4 Recommendations Space

A collection of recommendations, each in the form of a reasoning chain $\lambda _{(identifer, result)}$ contributed by source ‘i’ is known as a recommendations space. Mathematically, a recommendations space is defined as follows:

$$\begin{aligned} \Theta = \sum ^{n}_{i=0}\left\{ [i]\lambda _{(identifer,result)}\right\} \end{aligned}$$

(6.1)

6.3.1.5 Integration Scheme

An integration scheme, the decision maker’s defined argumentation scheme (Katie Atkinson 2008), is a tuple with the following form:

$$\begin{aligned} \mathcal {IS} = \{name,(premise_{i},......., premise_{n}),\, conclusion,\, critical questions, variant\} \end{aligned}$$

(6.2)

where

• name is the label of the scheme which identifies the scheme;

• premise is a set of facts to be matched;

• conclusion is the result of the scheme;

• criticalquestion is a set of queries;

• variant is a boolean flag for conflict blocking. If variant is true, the conflicts are blocked and the reasoning chain will not be considered for any further processing; whereas if the flag is false, then reasoning chains with conflicts are still considered for further processing.

The critical questions can be categorized as exceptions and assumptions. The premises provide reasons for accepting the conclusion only if the assumptions are true and there are no exceptions. If either an assumption is false or an exception is true, unless the premises provide reasons for accepting the conclusion, the conclusion would not be valid (Katie Atkinson 2008). Thus, both assumptions and exceptions attack the conclusion of the scheme.

6.3.1.6 Valuation Operator and Valued Reasoning Chain

The application of the integration scheme to a reasoning chain is termed ‘valuation of a reasoning chain’ and the resulting reasoning chain is called a valued reasoning chain. Mathematically, the valuation operator $\between$ is defined as a binary operator as follows:

$$\begin{aligned}{}[rc1]\lambda _{(A,a)}^{val} = \left\{ [rc1]\lambda _{(A,a)}\between \mathcal {IS}\right\} \end{aligned}$$

(6.3)

During the valuation of a reasoning chain, all the premises and critical questions originating from the integration scheme are executed on the corresponding reasoning chain. If the premises match the reasoning chain and queries return true on the execution over the reasoning chain, the reasoning chain is considered to be a valued reasoning chain. The reasoning chain is still considered valued if the reasoning chain premise does not match or queries return false, but the conflict blocking flag, i.e. svariant is false.

6.3.1.7 Focus Operator

$\otimes$ is a binary operator, such that

$$\begin{aligned}{}[rc1]\lambda _{(A,a)}^{val} \otimes [rc2]\lambda _{(B,a)}^{val} \end{aligned}$$

(6.4)

is called a ‘focus operator’. This corresponds to AND operator. If two arguments belonging to different reasoning chains have the same claim, the application of the focus operator produces these arguments in a resulting set.

6.3.1.8 Merge Operator

$\boxplus$ is a binary operator (Fan et al. 2010), such that

$$\begin{aligned}{}[ar1]a,b,c\dashrightarrow d \boxplus [ar2]\, e,b,c\dashrightarrow d \end{aligned}$$

(6.5)

is called a ‘merge operator’. This corresponds to the OR operator and it applies to arguments that make the same claim. The application of this operator results in the construction of a new argument that carries all the unique premises of the arguments and links them to a common claim.

6.3.1.9 Unique Operator

$\odot$ is a binary operator, such that

$$\begin{aligned}{}[rc1]\lambda _{(A,a)}^{val} \odot [rc2]\lambda _{(B,a)}^{val} \end{aligned}$$

(6.6)

is called a ‘unique operator’. The application of the unique operator on reasoning chains and returns all those arguments whose claim is unique between the reasoning chains.

6.3.1.10 Conflict Operator

$\oslash$ is a binary operator, such that

$$\begin{aligned}{}[rc1]\lambda _{(A,a)}^{val} \oslash [rc2]\lambda _{(B,a)}^{val} \end{aligned}$$

(6.7)

is called a ‘conflict operator’. The application of this operator to reasoning chains will return the set of arguments along with their counter-arguments and undefeated or blocking dialectical trees.

6.3.1.11 Preference Operator

> is a binary operator such that

$$\begin{aligned}{}[a]giveDiscount(XYZ) >[b] \sim giveDiscount(XYZ) \end{aligned}$$

(6.8)

is known as a ‘preference operator’. The decision maker can define a preference relation explicitly for an argument and its counter-arguments.

6.3.1.12 Integrated Recommendations Space

The integration of recommendations, each in the form of a valued reasoning chain $\lambda ^{val}_{(identifer, result)}$ contributed by a source ‘i’ is known as an integrated recommendations space. Mathematically, an integrated recommendations space is defined as follows:

$$\begin{aligned} \Theta _{integrated}= \sum ^{n}_{i=0}\left\{ [i]\lambda ^{val}_{(identifer,result)}\right\} \end{aligned}$$

(6.9)

6.3.1.13 Query

A query ‘q’ consists of a predicate, and can be executed on the argument set ‘Args’ with the help of function executeQuery(q) $\in \mathcal {F}$ to check the support for the predicate in the recommendations space.

6.3.2 Working of the Proposed Framework for Web@KIDSS

In this section, the working of the proposed framework for the integration of reasoning results produced by different Web@IDSS located both within the enterprise and/or in other enterprises after resolving the conflicts between them to assist the decision maker in the decision making process is discussed. Figure 6.5 presents a flow chart of the working of the proposed framework. The sequence of steps in the proposed framework is as follows:

Fig. 6.5

Flowchart illustrating steps performed by Web@KIDSS for enterprise knowledge integration

• 1. Publication of EII in a standard format

        The Web@IDSS needs to publish decisions/results in a shareable format over the enterprise’s intranet or the Internet so that they can be merged/considered by other Web-based DSS to assist the inter-enterprise or intra-enterprise decision-making process. To achieve this objective, Web@IDSS exploits the functionality of the information and knowledge integration module of the logic-based framework located at @IRRI layer. This module helps the Web@IDSS to transform the reasoning chain into a standard format i.e. AIF and publish it over the enterprise’s intranet or the Internet. This process involves the following two steps:

  • Modeling of reasoning chains as an AIF argument network

          The elements of a reasoning chain i.e. arguments and the relationships between them, are modelled as an AIF argument network.

  • Semantic annotation and serialization of a reasoning chain

          The modeling of a reasoning chain as an AIF argument network is realized by annotating the elements of a reasoning chain with the concepts and relationships defined in the AIF core ontology.¹ The semantic annotation is an automated process and once completed, the annotated reasoning chain is in OWL/RDF format and is published over the enterprise’s intranet or the Internet.

• 2. Enterprise knowledge integration

        Once the reasoning chains have been published, Web@KIDSS needs to import and integrate them, generate a graphical representation of the integrated reasoning chains to assist the decision maker in the decision making process of the inter-enterprise or intra-enterprise. To achieve this objective, Web@KIDSS exploits the functionalities of the information and knowledge integration module and the argumentative reasoning module of the logic-based framework located at @IRRI layer. This process involves the following three steps:

  • Import and transform the published reasoning chains

          This steps involves importing the published reasoning chains followed by their transformation into DeLP format (i.e. DeLP rules and DeLP facts) and saves them in the knowledge base.

  • Valuation of the reasoning chains

          This starts with the reconstruction of reasoning chains from the knowledge base and their modeling in the form of an argument using the Toulmin model for the argument’s structure. The next step is to define and apply an integration scheme on the modelled reasoning chains. This is to identify and consider only those reasoning chains for the next step that adhere to the decision maker’s required criteria. This process is called the ‘valuation of the reasoning chains’. The reasoning chains that pass the valuation process are called valued reasoning chains and are saved in the valued recommendations set. The valuation of the reasoning chains involves the following steps:

    • Re-construct the reasoning chains. As discussed in Sect. 5.5.1, this involves the compilation of the production rules (DeLP rules) in the rule base as a Rete network and the DeLP facts in the working memory are passed through the Rete network. This results in the construction of arguments. The arguments are then linked in the form of reasoning chains. The reasoning chains are then modelled as an argument by using the Toulmin model for the argument’s structure.

    • Define an integration scheme that specifies the decision-maker’s criteria in the form of pre-requisites which the reasoning chain must satisfy in order for it to be considered for further processing.

    • Apply the integration scheme over the reasoning chains that resulted in the creation of the valued recommendations set.

    • Display the valued reasoning chains to the decision maker.

  • Generation of the integrated recommendations space

          Once the valued recommendations set has been generated, the next step is to perform argumentative reasoning to identify and resolve conflicts between them, and identify the unique conclusions supported by the valued reasoning chains followed by their integration. Such integration of the valued reasoning chains results in the creation of the integrated recommendations space, involving the following steps:

    • Perform argumentative reasoning which involves the identification of conflicts between arguments belonging to different valued reasoning chains in a valued recommendations set. Once the conflicts have been identified, the automated resolution of conflicts between arguments takes place by computing either static or dynamic defeat. Once the conflicts between the arguments in the valued recommendations set have been resolved, the construction of new arguments takes place by combining the premises of those arguments that support the same claim.

    • Identify the unique conclusion supported by underlying valued reasoning chains.

    • Build the reasoning chains (as defined in Sect. 5.6.1 ), each of which support a unique conclusion. Such integration of information is called an integrated recommendations space.

• 3. Graphical representation of results to support intelligent decision making

        Once the integrated recommendations space has been created, Web@KIDSS exploits the functionality of the information and knowledge integration module of the logic-based framework located at @IRRI layer to provide a graphical representation of the integrated recommendations space and assist the decision maker to make the final decision. This process involves the following steps:

  • Graphical representation of the integrated recommendations space

          Once the integrated recommendations space has been created, Web@KIDSS provides the decision maker with a graphical representation to assist him in the intra-enterprise or inter-enterprise decision-making process. Such an integrated recommendation space represents the different viewpoints in the underlying information and the support for each.

  • Functionality to query the knowledge base

          The Web@KIDSS provides an interface to query the knowledge base if the decision maker needs an explanation of the results returned by the system.

In the next sections, each of these steps will be discussed in detail.

6.4 Publication of Enterprise Integrated Information (EII) in a Standard Format

As discussed in Chap. 5, a Web@IDSS represents, reasons and integrates potentially incomplete and\or contradictory information that exists both within the enterprise and/or in other enterprises to assist the decision maker in the decision-making process. For EKI, a reasoning chain produced by a Web@IDSS needs to be shared with other Web-based DSS which may be either within the enterprise and/or in other enterprises. The current representation of reasoning chains is Web@IDSS specific and it cannot be consumed directly by other Semantic Web applications. The proposed framework addresses this drawback with the help of the information and knowledge integration module of the logic-based framework located at @IRRI layer. This module helps the Web@IDSS transform and publish the reasoning chain in AIF format. Figure 6.6 describes the following steps involved in the transformation of a reasoning chain in AIF format and its publication over an enterprise’s intranet or the Internet:

• (1) Modeling of a reasoning chain as an AIF argument network

        AIF is an effort to provide a standard representation of a set of arguments and the relationships between them to ensure the argument network is understandable by different applications. As discussed in Sect. 5.6.1, a reasoning chain is composed of a set of arguments and the relationships between them. In order to model the reasoning chain as an AIF argument network, an argumentative production system is defined as an AIF network of arguments in Sect. 6.3.1.2, where the elements of a reasoning chain are mapped to the elements of an AIF.

• (2) Semantic annotation and serialization of a reasoning chain

        Once the reasoning chain has been modelled as an AIF argument network, the next step is the realization (implementation) of a reasoning chain as an AIF argument network. Using the mapping defined in Sect. 6.3.1.2, the reasoning chain is annotated with the ArgDF ontology that provides AIF reification² in OWL/RDF format. As a result of semantic annotation, the resulting reasoning chain is serialized in OWL/RDF format and published over the enterprise’s intranet or the Internet.

Fig. 6.6

Flowchart illustrating steps performed by Web@KIDSS for publication of the reasoning chains

In the next-subsections, these two steps are discussed in detail.

6.4.1 Modeling of a Reasoning Chain as an AIF Argument Network

The Argument Interchange Format (AIF) is an international effort to develop a representational mechanism for exchanging argument resources between research groups, tools, and domains, using a semantically rich language (Chesnevar et al. 2006; Iyad Rahwan 2009; Rahwan et al. 2007). AIF was developed as a commonly agreed upon core ontology i.e. AIF core ontology, that specifies the basic concepts used to express arguments and the relationship between arguments. The AIF core ontology, as depicted in Fig. 6.7, is composed of the following two ontologies:

• Upper Ontology

        The Upper Ontology defines the basic building blocks of AIF argument graphs, and the types of nodes and edges. There are two types of argument nodes:

  • information nodes (I-Nodes) which capture information in the form of a premise, conclusion, exception or presumption, and

  • scheme nodes (S-nodes) which provide the relationship between two I-Nodes and are further classified as:

    • rule application nodes (RA-Node) which correspond to inferences from premises to claims;

    • conflict nodes (CA-Node) which correspond to conflicts between two nodes;

    • preference application nodes (PA-node) which correspond to preference ordering between contradictory nodes.

• Forms Ontology

        The Forms Ontology allows for the conceptual definition of the elements of AIF graphs, such as premises, inference schemes and exceptions. Inference schemes are similar to the rules of inference in logic such as a deductive or defeasible inference.

Fig. 6.7

The upper and forms ontology of the AIF ontology (Bex et al. 2010)

Based on the definition of the AIF argument network (defined in Sect. 6.3.1.1), an argumentative production system is defined as a network argument (defined in Sect. 6.3.1.2) where the elements of a reasoning chain are mapped to the elements of the AIF argument network as follows:

• A strict argument consists of a set of premises and a conclusion. The premises and conclusion are linked with the help of a strict inference. During mapping, each premise and a conclusion is represented as an I-Node and the strict inference is represented as an S-Node using the deductive scheme.

  $\mathcal { N}^{I}_{i},......,\mathcal {N}^{I}_{j} \;\mathop {\longrightarrow }\limits ^{Uses(RA,deductiveScheme)}\mathcal {N}^{I}_{k}$

• A strict defeasible argument also consists of a set of premises and a conclusion. The premises and conclusion are linked with the help of a defeasible inference. During mapping, each premise and conclusion is represented as an I-Node and the defeasible inference is represented as an S-Node using the defeasible scheme.

  $\mathcal {N}^{I}_{m},......,\mathcal {N}^{I}_{n} \mathop {\dashrightarrow }\limits ^{Uses(RA,defeasibleScheme)}\mathcal {N}^{I}_{o}$

The binary relations between arguments in a reasoning chain are mapped to an AIF argument network as follows:

• The counter-argument relation involves two arguments which are in conflict with each other. The claims of the argument and its counter-argument are mapped as an I-Node and a CA-Node is used to represent the relationship between them.

  $\mathcal {N}^{I}_{i} \mathop {\dashrightarrow }\limits ^{Uses(CA{\text{- }}Node)}\sim \mathcal {N}^{I}_{j}$ such that $\mathcal {N}^{I}_{i}$ is a counter-argument $\mathcal {N}^{I}_{j}$

• Static defeat and dynamic defeat are two types of defeats that are used by an argumentative production system to resolve conflicts between an argument and its counter-argument that results in the establishment of preferences between them. During mapping, this relationship is represented as a PA-Node between the claims of arguments that are represented as an I-Node.

  $\mathcal {N}^{I}_{i} \mathop {\dashrightarrow }\limits ^{Uses(PA{\text{- }}Node)}\mathcal {N}^{I}_{j}$ such that $\mathcal {N}^{I}_{i}$ is has priority over $\mathcal {N}^{I}_{j}$

• For representation of the sub-argument relationship in AIF format, a blank-node is added into the argument network i.e. $\mathcal {N}^{I}_{i} \mathop {\dashrightarrow }\limits ^{Uses(Blank{\text{- }}Node)}\mathcal {N}^{I}_{j}$ such that $\mathcal {N}^{I}_{i}$ (claim of an argument) is a sub-argument of $\mathcal {N}^{I}_{j}$ (premise of an argument).

• The I-Node i.e. $\mathcal {N}^{I}_{i}$ with no successor and with predecessor nodes is called the ‘result’ of the reasoning chain. The remaining nodes are known as ‘support’ for the result.

To explain the modeling of a reasoning chain with an example, consider the case study discussed in Sect. 6.2 where the recommendation from the IT department about choosing the relocation service provider XYZ are shown in illustration 6.1.

The Fig. 6.8 provides the graphical representation of the recommendations in form a reasoning chain constructed from set of arguments shown in illustration 6.1 by using the approach proposed in Sect. 5.6.1.

Figure 6.9 depicts the pictorial representation of a reasoning chain modeled as an AIF argument network where the premises and the conclusion are represented as I-Nodes and defeasible/strict inference is represented as RA-nodes that use defeasible/strict modus ponens to reach a conclusion. The directed arrows are simply to emulate the edge from an S-Node to a I-Node and bold-text I-Nodes are used represent the claim of an argument for better readability. Similarly, an I-Node such as $[rc1.a.it.d8]recommendService(xyz)$ that has no successor and has predecessor nodes represents the ‘result’ of a reasoning chain and the remaining nodes represent the ‘support’ for the result. The AIF argument does not provide a node to represent the sub-argument relationship, therefore, to capture the sub-argument relationship, the sub-argument i.e. $[rc1.x.s1] normalDiscount(xyz)$ is linked to the argument i.e.$[rc1.a.it.d5] goodrelationService(xyz),$ with a blank node.

Fig. 6.8

Pictorial representation of the recommendation forwarded by IT department

Fig. 6.9

Pictorial representation a reasoning chain as an AIF argument network

6.4.2 Semantic Annotation and Serialization of a Reasoning Chain

Once the reasoning chain has been modelled as an AIF argument network, the next step is the realization (implementation) of a reasoning chain as an AIF argument network. To achieve this objective, the reasoning chain is annotated with an ArgDF ontology that provides AIF reification.³ In Sect. 6.3.1.2, the mapping between the elements of a reasoning chain and the elements of an AIF argument network is defined. Using this mapping, the concepts and relationships defined in the ArgDF ontology are used to annotate the reasoning chain and the resulting reasoning chain is serialized in OWL/RDF format.

To explain the semantic annotation and serialization of a reasoning chain with an example, consider a reasoning chain that comes from the arguments shown in Fig. 6.8. The semantic annotation is an automated process and the resulting reasoning chain is saved in OWL/RDF format. Figure 6.10 depicts the serialization of a reasoning chain built from the arguments shown in Fig. 6.8.

Fig. 6.10

Serialization of AIF compliant reasoning chain in turtle format

Fig. 6.11

Flowchart illustrating steps performed by Web@KIDSS for knowledge integration

6.5 Enterprise Knowledge Integration (EKI)

Once the reasoning chains have been published, the next step is EKI i.e. the integration of published reasoning chains and the provision of a graphical representation of integration information to assist the decision maker for the intra-enterprise or inter-enterprise decision-making process. To achieve this objective, Web@KIDSS exploits the functionalities of the information and knowledge integration module and the argumentative reasoning module of the logic-based framework located at @IRRI layer. This module helps the Web@KIDSS to import and transform the published reasoning chains, perform hybrid reasoning over them and integrate them in a format that can assist the decision maker in an enterprise-wide decision making process. Figure 6.11 presents the flowchart of enterprise knowledge integration. Enterprise knowledge integration involves the following three steps:

• Import and transform the published reasoning chains

        During this step, the published reasoning chains in AIF format are imported by Web@KIDSS, transformed into DeLP format (i.e. DeLP rules and DelP facts) and saved in the knowledge base. During transformation of AIF argument network nodes to the elements of a reasoning chain, the transformation rules considered are as follows:

  • I-Nodes are transformed to premises and the conclusion of an argument.

  • RA-Nodes are used to determine the types of argument. The RA-Nodes that use strict modus ponens are realized as strict arguments and RA-Nodes that use defeasible modus poenens are realized as defeasible arguments.

  • CA-nodes do not need any transformation because Web@KIDSS can identify the contradictory arguments using the argumentative reasoning module.

  • PA nodes are transformed to the preferences relationship between contradictory arguments.

• Valuation of the reasoning chains

        During this process, the following steps are performed:

  • Re-construction of the reasoning chains. As discussed in Sect. 5.5.1, this involves compilation of the production rules (DeLP rules in the rule base) as a Rete network and facts (DeLP facts in the working memory) are passed through the Rete network. This results in the construction of arguments. The arguments are then linked in the form of reasoning chains. The reasoning chains are then modelled using the Toulmin model for an argument’s structure.

  • Define an integration scheme that specifies the decision maker’s criteria in the form of pre-requisites for a reasoning chain to satisfy in order for it to be considered for further processing.

  • Application of an integration scheme over the reasoning chains. The reasoning chains that pass the valuation are called valued reasoning chains. The collection of valued reasoning chains is called the valued recommendations set.

  • Display the valued reasoning chains to the decision maker.

• Generation of integrated recommendations space

        Once the valuation of the reasoning chains is accomplished and the valued recommendations set is produced, the next step is to integrate the reasoning chains in the valued recommendations set to form an integrated recommendations space. To achieve this objective, the following steps are performed:

  • Perform argumentative reasoning which involves the identification of conflicts between arguments belonging to different valued reasoning chains in a valued recommendations set. Once conflicts have been identified, the automated resolution of conflicts between arguments occurs, with the help of computing either static or dynamic defeat. Once the conflicts have been resolved between the arguments in the valued recommendations set, the construction of new arguments takes place by combining the premises of these arguments that support the same claim.

  • Identify the unique conclusion supported by underlying valued reasoning chains.

  • Build integrated reasoning chains, each of which support a unique conclusion. Such integration of information is called the integrated recommendation space.

In the following sub-sections, I will explain each of these steps in detail.

6.5.1 Import and Transform the Published Reasoning Chains

The reasoning chains published on the enterprise’s intranet or the Internet by different Web@IDSS in AIF format are imported by the Web@KIDSS. It understands and consumes these reasoning chains in AIF format (serialized in OWL/RDF format) and translates them to DeLP constructs as follows:

• The information nodes are translated as either the premise of an argument or claim, whereas the scheme nodes are used to build the types of arguments and the relationship between arguments. For example, if there is an RA-node (defeasible or strict inference), the predecessor of the scheme nodes will be the premise and the successor of the RA-node and will be the claim of the argument.

• Similarly, CA-nodes and PA-nodes are translated into counter-arguments and defeat the relationship between the arguments, respectively. The blank-nodes are translated as the sub-argument relationship between arguments.

To explain with an example, consider the AIF representation of reasoning chains shown in Fig. 6.9. The steps involved in the translation of AIF elements of a reasoning chain to DeLP format by Web@KIDSS are as follows:

• Strict inference

        If the RA-Nodes use strict modus ponens (represented in Fig. 6.12 ), all the incoming edges to the RA-Node are considered premises and the successor node is considered as the claim of a strict argument.

• Defeasible inference

        If the RA-Nodes use defeasible modus ponens (as represented in Fig. 6.13), all the incoming edges to the RA-Node are considered premises and the successor node is considered the claim of the defeasible argument.

• CA-node

        No translation for the CA-node (as represented in Fig. 6.14) as the proposed Web@KIDSS has a built-in mechanism to identify contradictory arguments.

• PA-node

        If the PA-nodes (as represented in Fig. 6.15) exit between an argument and its counter-argument, then the argument having an incoming edges from the PA-Node has low priority than its counter-argument.

Fig. 6.12

AIF representation of a strict argument

Fig. 6.13

AIF representation of a defeasible argument

After translation of a reasoning chain, the arguments are transformed to production rules (DeLP rules) and saved in the knowledge base. During the process, new variables and DeLP facts are generated. Ground predicates such as shopper(david), are transformed to a predicate with attribute variables such as shopper(X). Such transformation of a reasoning chain allows the hybrid reasoning engine to save them in the knowledge base and perform hybrid reasoning over it. A similar procedure is performed for all of the premises of a production rule. Additionally, the premises of the argument (except those that represent incomplete information and start with ‘not’) are saved as DeLP facts in the working memory. Figure 6.16 represents the pictorial representation of the procedure that transforms an argument into production rules and saves the resulting DeLP facts and DeLP rules in the working memory and rule base, respectively.

Fig. 6.14

AIF representation of a CA-Node

Fig. 6.15

AIF representation of PA node

Fig. 6.16

Pictorial representation of the transformation of an argument to a production rule

To explain the importation and transformation of reasoning chains, consider the case study discussed Sect. 6.2, where enterprise ABC considers the reasoning chains published by its departments. The collection of these reasoning chains is called recommendations space. The recommendation space for enterprise ABC is depicted in Fig. 6.17 and can be mathematically represented as follows:

$$\begin{aligned} \Theta = \left\{ [rc1]\lambda _{(d7,recommend)},[rc2]\lambda _{(d4,\sim recommend)},[rc3]\lambda _{(d6,\sim recommend)}\right\} \end{aligned}$$

(6.10)

where

• $[rc1]\lambda _{(d7,recommend)}$ represents the recommendation from the IT department identified as ‘rc1’ in the form of a reasoning chain as shown in illustration 6.1.

• Similarly, $[rc2]\lambda _{(d6,\sim recommend)}$ is a recommendation from the Mark department identified as ‘rc2’ as shown in illustration 6.2, and $[rc3]\lambda _{(d4,\sim recommend)}$ is a recommendation from the HR department identified as ‘rc3’ as shown in illustration 6.3.

6.5.2 Valuation of the Reasoning Chains

The valuation of a reasoning chain consists of the following steps:

Fig. 6.17

Pictorial representation of the recommendations space for an enterprise ABC

• (a) Modeling of reasoning chains w.r.t the Toulmin model of an argument’s structure

        The Web@KIDSS first models the reasoning chain by identifying its basic elements as determined by Toulmin (2003). Such modeling of a reasoning chain helps to obtain a better understanding of the reasoning process and the importance of each element of a reasoning chain in the entire process. A reasoning chain is modelled as follows:

  • Back-up evidence: The initial working memory describes the current situation, from which the argumentative reasoner starts its derivation activity. In a reasoning chain, these nodes have no incoming edge (no predecessor nodes) and only an outer edge, or successor nodes, are considered back-up evidence.

  • Claim: The conclusion/result of the reasoning chain corresponds to the claim.

  • Warrant: The support for the result of a reasoning chain is called a ‘warrant’. It is a set of arguments linked to form a reasoning chain link as back-up evidence for a claim.

  Such modeling of a reasoning chain has significant relevance for correctly modeling a practical argumentation activity and helps to categorize the various ways by which arguments can be analysed and defeated; therefore, the following strategies could have significant value as identified by Baroni et al. (1998).

  • If conflict exists between a critical question and data, the entire conclusion drawn from them is undermined.

  • It could help to point out flaws in the reasoning chain that relate data to the conclusion.

  • If conflict exists between the claim and critical question, the decision maker has to see the warrant and data in order to defeat the claim.

  To explain the modeling of a reasoning chain by following the Toulmin model, consider the case study discussed in Sect. 6.2 where the IT department forwards its recommendation to the business manager. Figure 6.18 provides the pictorial representation of a reasoning chain model using the Toulmin model for the argument structure.

• (b) Definition and application of an integration scheme on the reasoning chains

  Once the modeling of the reasoning chains is completed, the next step is to define and apply the integration scheme. The integration scheme, derived from the concept of the argumentation scheme, corresponds to our daily life pattern of reasoning. The application scope of parameters, defined in the integration scheme, ranges from the valuation of reasoning chains and their integration during the decision-making process. In the proposed framework, the DeLP language is used to create an integration scheme using the following steps:

  • Name the integration scheme.

  • Define the set of premises.

  • Define the set of critical questions. The critical questions are queries to be executed on a reasoning chain. The critical questions are further categorised as follows:

    • Set of assumptions

    • Set of exceptions

  • Set conflict handling variant i.e. conflict blocking either true or false. The scope of conflict handling can be defined at the valuation of reasoning chains or their integration or at both levels.

    • During the valuation of a reasoning chain, if any conflicts exist between a critical question and the premise, in the case of the conflict blocking variant being true, the reasoning chain is not considered suitable for knowledge integration and vice versa.

    • During enterprise knowledge integration, if a conflict exists between two arguments from different reasoning chains, in the case of the conflict blocking variant being true, these arguments are not considered in the final decision-making process and vice versa.

    Once the Integration scheme has been defined, the next step is to apply it on the reasoning chains. This process involves the generation of DeLP queries from the integration schemes and their execution on the selected reasoning chain. During this process, if any conflict exists either between the data and premise, or between the critical question and the warrant, the Web@KIDSS stores these results and depending upon the conflict blocking variable value, the reasoning chain will be considered for the next phase. The Web@KIDSS also displays the results to the decision maker.

Fig. 6.18

Pictorial representation of a modelled reasoning chain using Toulmin model

Algorithm 6.1 provides the working of the valuation process over a valued recommendations set. It takes into account a set of AIF compliant reasoning chains and sets their valuation flag to false.

Then, it applies the integration scheme to each of the reasoning chains one-by-one by calling Algorithm 6.2 for the valuation of each reasoning chain. During the valuation of a reasoning chain, the decision maker’s queries defined in the form an integration scheme are executed on the reasoning chain. If the execution of the query on the reasoning chain returns false (i.e. the reasoning chain does not adhere to the decision-maker’s criteria), this is captured as a conflict between the reasoning chain and the integration scheme. Once the valuation of the reasoning chain is completed, if a conflict exists between the reasoning chain and the integration scheme and the variant flag is set to false (i.e. the reasoning chains is not considered for further processing), the reasoning chain is removed from the valued recommendations set.

To explain the integration scheme with help of an example, consider the case study discussed in Sect. 6.2 where the business manager has a set of recommendations in the form of reasoning chains and he wants to consider only those reasoning chains for enterprise knowledge integration which satisfy certain specific criteria. For example, the business manager specifies the criteria that the recommendation must be for relocation service provider XYZ. Therefore, only recommendations for XYZ are considered for the final decision-making process, as shown in Fig. 6.19.

To achieve this objective, they define the features in the integration scheme as follows:

• Premise

        The business manager wants to define a criteria that the recommendation is against relocation service provider XYZ. This is done by defining an execute function that takes a predicate as input as follows: $executeQuery(relocationService(xyz))$. The premise is a query over the knowledge base that contains the reasoning chain from the IT department. If the query returns yes, then this demonstrates that the backup evidence contains information that the relocation service provider is XYZ.

• Critical questions

        The business manager wants to know whether or not in the underlying reasoning chain XYZ is good at formalising the clients’ criteria and how it is supported by the reasoning chain (i.e. warrant). This is accomplished by defining an execute function that takes a predicate as input such as: $executeQuery(relocationService(xyz)).$

• Variant

        If the business manager wants to consider only those reasoning chains which passed the tests defined in the integration scheme and qualify for EKI, he sets the boolean variable to true. Otherwise, he can set it to false in order to include the reasoning chain even if it does not qualify for EKI. Figure 6.20 shows a Web-based form depicting the valued reasoning chain initially forwarded by the IT department of enterprise ABC.

Fig. 6.19

Web-based from of Web@KIDSS to define integration scheme

Fig. 6.20

Web-based form of Web@KIDSS that shows the valuation of a reasoning chain

6.5.3 Generation of Integrated Recommendations Space

Once the valued recommendation set has been generated, the next step is to perform argumentative reasoning to identify and resolve conflicts between them, identify the unique conclusions supported by the valued reasoning chains followed by their integration. Such integration of valued reasoning chains is called integrated recommendations space and involves the following steps:

• (a) Argumentative reasoning between reasoning chains

        During this process the following steps are performed:

  • The identification of conflicts between arguments belonging to different valued reasoning chains in a valued recommendations set. The conflict operator $(\oslash )$ is a binary operator defined in Sect. 6.3.1.10, which when applied on the valued reasoning chains (e.g. rc[i] $\oslash$ rc[j]) returns a set of arguments that are in conflict.

  • Once the contradictory arguments have been identified, the Generalize Specificity conflict resolution strategy is used by computing either static or dynamic defeat to resolve conflicts between arguments. In the case of blocking arguments (where the dialectical trees of both the arguments and their counter-arguments are undefeated), then Web@KIDSS needs human intervention to resolve the conflict between them. Further discussion on this is given in Chap. 7.

  • After conflict resolution, the construction of new arguments is started. If two arguments from a valued recommendations set have the same claim, the premises of these arguments are combined to produce a new argument. The focus operator $(\otimes )$ is a binary operator defined in Sect. 6.3.1.7, which when applied to valued reasoning chains (e.g. e.g. rc[i] $\otimes$ rc[j]), returns the set of arguments that share the same claim. The merge operator ($\boxplus$) is a binary operator defined in Sect. 6.3.1.8, and when applied to a set of arguments, results in the construction of a new argument that replaces the old arguments which support the same claim.

• (b) Identification of the unique conclusion supported by underlying reasoning chains

        Once the argumentative reasoning over the valued recommendations set is completed, the next step is to identify the unique conclusions from it. The unique operator $(\odot )$ is a binary operator defined in Sect. 6.3.1.9, which when applied to valued reasoning chains (e.g. rc[i] $\odot$ rc[j]) returns the set of arguments that support the unique claim.

• (c) Building integrated reasoning chains

        Once the unique conclusions have been identified, the last step is to build the reasoning chains. The methodology proposed for the construction of reasoning chains in Sect. 5.6.1 is used for the construction of the integrated recommendation space.

Algorithm 6.3 shows the process of generating the integrated recommendation space. It first loops through a set of reasoning chains and compares the results of a reasoning chain with the results of the remaining reasoning chains; if the results match, then these reasoning chains are integrated. Four kinds of operators are used during this integration process. With the help of focus $(\otimes )$ and merge ($\boxplus$) operators , the new arguments are constructed and then loaded into a valued recommendation set. With the help of a unique operator $(\odot ),$ unique arguments from both reasoning chains are loaded into an valued recommendation set. With the help of the conflict operator $(\oslash )$, contradictory arguments are taken into account for conflict resolution. If the conflict blocking flag for knowledge integration is false, then Web@KIDSS tries to resolve conflicts with the help of static or dynamic defeat. Otherwise, Web@KIDSS provides an interface for the decision maker to establish the preference between the contradictory arguments. Finally, it invokes Algorithm 5.4 (defined in Chap. 5) in order to build a reasoning chain from the arguments in the valued recommendations set. The important thing to note here is that conflicts may exist in a valued recommendation set if the conflict blocking flag is true.

To explain enterprise knowledge integration with an example, consider the case study discussed in Sect. 6.2 where each department needs to formulate and forward its recommendations about relocation service provider XYZ to the business manager. During this process, each department, with the help of Web@IDSS, produces recommendations in the form of a reasoning chain. Consider the recommendation forwarded by the manager of the IT department shown in Fig. 6.6 where he recommends that although the relocation service provider is not convenient and is not good at formalising criteria, he assumes it to be a good relocation service provider and recommends it for relocation purposes (i.e. $[rc1.a.it.d8] goodRelocationService(xyz), not\; convienent(xyz), not\; clearCriteria(xyz) \dashrightarrow recommendService(xyz)$ ). However, other departments have a different opinion as shown in Fig. 6.17. It is important to note here that the recommendations produced by each department contain valuable information about relocation service supplier XYZ which could help the business manager make the final decision i.e. whether or not to select relocation service provider XYZ for the relocation of the enterprise. Figure 6.21 shows the pictorial representation of the integrated recommendation space. The double-circled arguments are newly constructed arguments during argumentative reasoning for enterprise knowledge integration.

Fig. 6.21

Pictorial representation of integrated recommendations space

6.6 Graphical Representation of Results to Support Intelligent Decision Making

The last functionality performed by the information and knowledge integration module of the logic-based framework is the graphical representation of the integrated recommendations space and to provide query support to answer the questions of the decision maker and assist them in the decision-making process. This process involves the following steps:

• 1. Graphical representation of the integrated recommendation space

        Once the generation of the integrated recommendation is completed, the next step is its graphical representation for the decision maker in order to assist him in the decision-making process. To explain with the help of an example, consider Fig. 6.22 which represents the graphical representation of the integrated recommendations space depicted in Fig. 6.21. The important features of graphical representation of a reasoning chain are as follows:

  • The reasoning chain is represented as a tree. Each reasoning chain supports a unique conclusion.

  • An argument is represented in short form e.g. $[s1]normalDiscount(david)$ where [s1] is the label of the argument and $normalDiscount(david)$ is the claim of the argument.

  • The arguments are depicted with an rectangle shape, defeasible inference is depicted with a dotted arrow and strict inference with a straight arrow.

  Such graphical representation helps the business manager of enterprise ABC to understand the whole reasoning process which can result in two recommendations: either recommend XYZ or not. He can identify the reasons for the recommendations as follows:

  • (a) Recommend Service provider XYZ

          The manager of the IT department recommends service provider XYZ for the relocation of enterprise ABC. His recommendation is based on the following information:

    • XYZ considers an enterprise ABC eligible for a discount. In light of the current available information for decision making, he will offer a normal discount to enterprise ABC.

    • Although XYZ may be inconvenient and not able to capture the enterprise’s criteria, the supplier is reliable and will likely provide safe delivery of the enterprise’s goods.

    • XYZ has been used previously by the IT department and the manager is happy with their service and wants to reuse them for the relocation of the department.

  • (b) Not recommend service provider XYZ

          The managers of the HR and Marketing departments do not recommend XYZ for the relocation of the departments of enterprise ABC. Their recommendations are based on the following information:

    • XYZ has been used for relocation services before and the marketing department was not happy with their service.

    • XYZ may not provide safe delivery.

    • Both departments consider XYZ to be a bad relocation service provider.

• 2. Query the knowledge base

        Once the integrated recommendation space has been generated and displayed to the decision maker in a graphical format, he may query the knowledge base to obtain an explanation of the results. In Sect. 6.3.1.13, the definition of a query is provided. The execution of a query on the knowledge base may result in one of the following conclusions:

  • If the answer is ‘yes’, the result will be an undefeated dialectical tree. Mathematically, it is represented as follows:

    $$\begin{aligned} \Sigma _{U}(\mathcal {A}, h) = executeQuery(q\,)\ldots \ldots \ldots \ldots \ldots \ldots \ldots \ldots \ldots (24) \end{aligned}$$

  • If the answer is ‘no’, the result will be a defeated dialectical tree. Mathematically, it is represented as follows:

    $$\begin{aligned} \Sigma _{D}(\mathcal {A}, h) = executeQuery(q).\ldots \ldots \ldots \ldots \ldots \ldots \ldots \ldots \ldots (25) \end{aligned}$$

  • If the answer is ‘undecided’, the result will be a blocked dialectical tree. Mathematically, it is represented as follows:

    $$\begin{aligned} \Sigma _{B} (\mathcal {A}, h) = executeQuery(q\,).\ldots \ldots \ldots \ldots \ldots \ldots \ldots \ldots \ldots (26) \end{aligned}$$

  • Unknown, if the predicate in the query is not in the language of the program. Mathematically, it is presented as follows:

    $$\begin{aligned} unknown = executeQuery(q\, ).\ldots \ldots \ldots \ldots \ldots \ldots \ldots \ldots \ldots (27) \end{aligned}$$

  To explain the query on the knowledge base with help of an example, consider that the decision maker wants to know whether XYZ is a good relocation service provider. To accomplish his objective, the query $goodRelocationService(xyz)$ is executed on the knowledge base and results in a defeated dialectical tree. This is because the argument that states that XYZ is a good relocation service provider has been defeated by the set of arguments that state that XYZ is not a good relocation service provider. The decision maker uses this representation which considers all the recommendations from the different stakeholders and resolves the conflicts between them to assist him in taking an informed decision.

Fig. 6.22

Web-based form of Web@KIDSS presenting integrated knowledge to assist the decision maker in decision making process

6.7 Conclusion

In this chapter, a solution for EKI was presented in order to assist the decision maker in enterprise-wide decision making. It was pointed out that the Web@IDSS (discussed in Chap. 5) addressed the issues of information integration to assist in the decision-making process, but does not address the issue of sharing and integrating information for the intra-enterprise or inter-enterprise decision-making process. To overcome this problem, the Web@IDSS was extended to make its results shareable in AIF format. Additionally, a framework for argumentation-enabled Web-based IDSS for enterprise knowledge integration (Web@KIDSS) was proposed. The Web@KIDSS import transforms standard reasoning chains to DeLP format, evaluates them against the decision maker’s defined criteria defined as an integration scheme followed by their integration using argumentative reasoning. The major contributions of this chapter are as follows:

• 1. The extension of Web@IDSS to share its reasoning results in a standard AIF format.

• 2. The formalization of syntax and semantics for enterprise knowledge integration in an enterprise.

• 3. The proposal of a framework for representing, reasoning and integrating potentially incomplete and/or contradictory reasoning chains to support the intra-enterprise or inter-enterprise decision-making process.

• 4. The graphical representation of the integrated results and the provision of query support for decision makers.