Logical fusion rules for merging structured news reports.
Structured text is a general concept that is implicit in a variety of approaches in handling information. Syntactically, an item of structured text is a number of grammatically simple phrases together with a semantic label for each phrase. Items of structured text may be nested within larger items of structured text. Much information is potentially available as structured text including tagged text in XML, text in relational and object-oriented databases, and the output from information extraction systems in the form of instantiated templates. In previous papers, we have presented a logic-based framework for merging items of potentially inconsistent structured text [Data Knowledge Eng. 34 (2000) 305-332, Data Knowledge Eng. 2002 (in press)]. In this paper, we present fusion rules as a way of implementing logic-based fusion. Fusion rules are a form of scripting language that define how structured news reports should be merged. The antecedent of a fusion rule is a call to investigate the information in the structured news reports and the background knowledge, and the consequent of a fusion rule is a formula specifying an action to be undertaken to form a merged report. It is expected that a set of fusion rules is defined for any given application. We give the syntax and mode of execution for fusion rules, and explain how the resulting actions give a merged report. We illustrate the presentation with examples of fusion rules for an application for merging weather reports.
Introduction
Syntactically, an item of structured text is a data structure containing a number of grammatically
simple phrases together with a semantic label for each phrase. The set of semantic labels in a
structured text is meant to parameterize a stereotypical situation, and so a particular item of
structured text is an instance of that stereotypical situation. Using appropriate semantic labels,
we can regard an item of structured text as an abstraction of an item of free text.
For example, news reports on corporate acquisitions can be represented as items of structured text
using semantic labels including buyer, seller, acquisition, value, and date. Each semantic
label provides semantic information, and so an item of structured text is intended to have some
semantic coherence. Each phrase in structured text is very simple - such as a proper noun, a
date, or a number with unit of measure, or a word or phrase from a prescribed lexicon. For an
France Telecomi
hheadquarters
hheadquarters

Figure

1: An example of a news report in the form of structured text.
application, the prescribed lexicon delineates the types of states, actions, and attributes, that could
be conveyed by the items of structured text. An example of structured text is given in Figure 1.
Much material is potentially available as structured text. This includes items of text structured
using XML tags, and the output from information extraction systems given in templates (see for
example [CL96, Gri97, ARP98]). The notion of structured text also overlaps with semi-structured
data (for reviews see [Abi97, Bun97]).
Whilst structured text is useful as a resource, there is a need to develop techniques to handle,
analyse, and reason with it. In particular, we are interested in merging potentially inconsistent
sets of news reports [Hun00a, Hun02b], and deriving inferences from potentially inconsistent sets
of news reports [Hun00b, Hun00c, BH01, Hun02a].
1.1 Our approach to fusion
In order to merge items of structured text, we need to take account of the contents of the structured
text. Different kinds of content need to be merged in different ways. To illustrate, consider
Examples 1.1 - 1.3 below.
Example 1.1 Consider the following two conflicting weather reports which are for the same day
and same city.
hweatherreport: hweatherreport:
hsource: TV1i hsource: TV3i
hdate: 19.5.1999i hdate: 19.5.1999i
htoday: suni htoday: suni
htomorrow: suni htomorrow: raini
We can merge them so that the source is TV1 and TV3, and the weather for today is sun, and
the weather for tomorrow is sun or rain.
hweatherreport:
hsource: TV1 and TV3i
hdate: 19.5.1999i
htoday: suni
htomorrow: sun or raini
An alternative way of merging these reports may be possible if we have a preference for one source
over the other. Suppose we have a preference for TV3 in the case of conflict, then the merged report
is:
hweatherreport:
hsource: TV1 and TV3i
hdate: 19.5.1999i
htoday: suni
htomorrow: raini
Example 1.2 Consider the following two structured reports which are for the same day but different
regions.
Here we may wish to take the union of the two regionalreport features in the merged report,
giving the following merged report,
Example 1.3 Consider the following two weather reports for the same day and same city.
hweatherreport: hweatherreport:
hsource: TV1i hsource: TV3i
hdate: 1.8.1999i hdate: 1.8.1999i
hmiddayweather: hmiddayweather:
hprecipitation: inclementi hprecipitation: showersi
htemperature: 20Ci htemperature: 18Ci
Here we may wish to take the conjunction of inclement and showers, and range of 18-20C in the
merged report.
hweatherreport:
hsource: TV1 and TV3i
hdate: 1.8.1999i
hmiddayweather:
hprecipitation: inclement and showersi
htemperature: 18C-20Ci
There are many further examples we could consider, each with particular features that indicate
how the merged report should be formed.
In our approach to merging items of structured text, in particular structured news reports, we
draw on domain knowledge to help produce merged reports. The approach is based on fusion rules
defined in a logical meta-language. These rules are of the form ff ) fi, where if ff holds, then fi is
made to hold. So we consider ff as a condition to check the information in the structured reports
and in the background information, and we consider fi as an action to undertake to construct the
merged report.
To merge a pair of structured news reports, we start with the background knowledge and the
information in the news reports to be merged, and apply the fusion rules to this information.
For a pair of structured news reports and a set of fusion rules, we repeatedly apply the fusion
rules until no more rules apply. The application of the fusion rules is then a monotonic process
that builds up a set of actions that define how the structured news report should be merged. The
information in this fixpoint is then used to construct a merged structured news report. In order
to merge more than two reports, we can repeat the merging process iteratively.
1.2 Other approaches to fusion
Our logic-based approach differs from other logic-based approaches for handling inconsistent information
such as belief revision theory (e.g. [Gar88, DP98, KM91, LS98]), knowledgebase merging
(e.g. [KP98, BKMS92]), and logical inference with inconsistent information (e.g. [MR70, Bre89,
These proposals are too simplistic in certain respects for handling
news reports. Each of them has one or more of the following weaknesses: (1) One-dimensional
preference ordering over sources of information - for news reports we require finer-grained preference
orderings; (2) Primacy of updates in belief revision - for news reports, the newest reports
are not necessarily the best reports; and (3) Weak merging based on a meet operator - this
causes unnecessary loss of information. Furthermore, none of these proposals incorporate actions
on inconsistency or context-dependent rules specifying the information that is to be incorporated
in the merged information, nor do they offer a route for specifying how merged reports should be
composed.
Other logic-based approaches to fusion of knowledge include the KRAFT system and the use
of Belnap's four-valued logic. The KRAFT system uses constraints to check whether information
from heterogeneous sources can be merged [PHG knowledge satisfies the constraints,
then the knowledge can be used. Failure to satisfy a constraint can be viewed as an inconsistency,
but there are no actions on inconsistency. In contrast, Belnap's four-valued logic uses the values
"true", "false", "unknown" and "inconsistent" to label logical combinations of information (see
for example [LSS00]). However, this approach does not provide actions in case of inconsistency.
Merging information is also an important topic in database systems. A number of proposals have
been made for approaches based in schema integration (e.g. [PM98]), the use of global schema
(e.g. [GM99]), and conceptual modelling for information integration based on description logics
These differ from our approach in that they
do not seek an automated approach that uses domain knowledge for identifying and acting on
inconsistencies. Heterogeneous and federated database systems also could be relevant in merging
multiple news reports, but they do not identify and act on inconsistency in a context-sensitive
way [SL90, Mot96, CM01], though there is increasing interest in bringing domain knowledge into
the process (e.g. [Cho98, SO99]).
Our approach also goes beyond other technologies for handling news reports. The approach of
wrappers offers a practical way of defining how heterogeneous information can be merged (see for
example [HGNY97, Coh98, SA99]). However, there is little consideration of problems of conflicts
arising between sources. Our approach therefore goes beyond these in terms of formalizing reasoning
with inconsistent information and using this to analyse the nature of the news report and for
formalizing how we can act on inconsistency.
1.3 The rest of the paper
In the rest of the paper, we develop the approach of logic-based fusion of news reports. In Section 2,
we review the definitions for formalizing structured text. This includes coverage of timestamps and
sourcestamps. It also includes coverage of some concepts for describing the structure of structured
text. In Section 3, we present the syntax for fusion including fusion rules and background knowl-
edge. Then, in Section 4, we define how a set of fusion rules together with background knowledge
can be executed to generate a set of actions that can be used to build a merged structured news
report. We explain how to use these actions to build a merged structured news report in Section
5. Then, in Section 6, we consider some properties of fusion systems based on fusion rules.
Formalizing structured text
In this section, we formalize the composition and structure of structured news reports.
2.1 Structured text
Here we adopt some basic definitions that should be easy to view as an adaptation of ideas in
a variety of fields in XML, relational and object-oriented databases, language engineering, and
knowledgebased systems.
Definition 2.1 A word is a string of alphanumeric characters, and a phrase is a string of one
or more words. A text entry is either a phrase or a null value. A semantic label is a phrase.
In this paper, we assume the set of semantic labels and the set of text entries are disjoint.
Example 2.1 Examples of words include John, France, drive, happy, 23, and 3i, and examples
of phrases include University of London, John, 23 April 1999, and warm and sunny.
Definition 2.2 If OE is a semantic label, and / is a text entry, then hOE : /i is an atomic feature.
The complex features are defined as follows: (1) if hOE : /i is an atomic feature, then hOE : /i
is a complex feature; and (2) if OE is a semantic label and oe 1 ; :::; oe n are complex features, then
is a complex feature. The type of a complex feature is the semantic label OE. An
item of structured text is just a complex feature.
Definition 2.3 Let be a complex feature. The sub function is defined as follows:
ng [
For complex features ff; fi, ff is a complex feature in fi iff ff 2 Sub(fi).
We can consider a complex feature as a tree where the semantic labels are non-leaf nodes and the
text entries are leaves.
be a complex feature. The semantic label OE is the parent
of the complex features oe 1 ; ::; oe n . The elements of are the offspring of OE.
The function Root is defined as: Root(hOE
Definition 2.5 The complex features, have the same
structure iff oe 1 and / 1 have the same structure, ., and oe n and /n have the same structure. The
atomic features have the same structure.
We assume that for an application, some complex features will be classified as structured re-
ports. These will be complex features with some minimum structure such as illustrated in Examples
1.1 - 1.3. We do not however assume any general conditions for classifying items of structured
text as structured reports.
2.2 Timestamps and sourcestamps
There are four types of timestamp that we will consider for structured reports, namely an atomic
pointbased timestamp, an atomic intervalbased timestamp, a complex pointbased timestamp, and
a complex intervalbased timestamp, and we define these below.
Definition 2.6 The set of temporal semantic labels is a subset of the set of semantic labels
used for structured news reports.
Example 2.2 The set of temporal semantic labels includes time, date, publicationdate, and
year.
Definition 2.7 The set of temporal text entries is a subset of the set of text entries used for
structured news reports. A temporal text entry may refer to a point or interval in a clock and/or
calendar. A temporal text entry is called a pointbased text entry if it refers to a point in a
clock. And a temporal text entry is called an intervalbased text entry if it refers to an interval
in a clock and/or calendar.
Example 2.3 Temporal text entries include 14.00hrs, 19 April 2000, and 19/4/00. Temporal
text entries may or may not include the units of time used. For example, both 14.00 and 14.00hrs
are temporal text entries.
We will look more closely at the nature of points and intervals in the following definitions.
Definition 2.8 An atomic pointbased timestamp is an atomic feature hff : fii where ff is a
temporal semantic label referring to a particular clock and/or a particular calendar and fi is a
pointbased text entry with a value denoting a point in that clock and/or calendar.
Example 2.4 Examples of atomic pointbased timestamps include:
We assume the background knowledge includes axioms that make different formats for temporal
text entries interchangeable, so that for example 19 April 2000 is equivalent to 19/4/2000.
Definition 2.9 An atomic intervalbased timestamp is an atomic feature hff : fii where ff is
a temporal semantic label referring to a particular clock and/or a particular calendar and fi is a
intervalbased text entry with a value denoting an interval in that clock and/or calendar.
We view time intervals as being either implicitly given as an interval with the start and end points
being inferred, or explicitly given in terms of a start point and an end point.
Definition 2.10 An explicit intervalbased text entry is of the form X-Y, where X and Y
denote points, and an implicit intervalbased text entry of the form X where X describes a
period of time without using explicit end points.
Example 2.5 Examples of atomic intervalbased timestamps with explicit intervalbased text entries
include:
Example 2.6 Examples of atomic intervalbased timestamps with implicit intervalbased text entries
include:
for 2004, the inferred start point in days is 1/1/2004 and the inferred endpoint in days is
It can appear difficult to distinguish some implicit intervalbased text entries from pointbased text
entries. We address the problem of handling implicit intervals by reducing each intervalbased text
entry to pointbased text entries. We assume that the background knowledge includes axioms for
this (as discussed in [Hun02b]).
Definition 2.11 A complex pointbased timestamp is either an atomic pointbased timestamp
or a complex feature h/ is a temporal semantic label refering to a particular
clock and/or a particular calendar and OE 1 ; ::; OE n are complex pointbased timestamps that describe
the point in that clock and/or calendar.
In this paper, we will assume atomic and complex pointbased timestamps should be interchangeable
by appropriate axioms in the background knowledge.
Example 2.7 An example of a complex pointbased timestamp is:
hdate:
hday:
hyear: 2000i;
So we can assume this complex pointbased timestamp is equivalent to hdate: 23 April 2000i.
Definition 2.12 A complex intervalbased timestamp is either an atomic intervalbased timestamp
or a complex feature h/ is a temporal semantic label refering to a
particular clock and/or a particular calendar and OE 1 ; ::; OE n are complex pointbased timestamps that
describe the interval in that clock and/or calendar.
Also, in this paper, we will assume atomic and complex intervalbased timestamps should be interchangeable
by appropriate axioms in the background knowledge.
Example 2.8 An example of a complex intervalbased timestamp is:
huniversity term:
hfirst day of term: 10/1/2000i;
hlast day of term: 29/3/2000i;
:university termi
So we assume this complex intervalbased timestamp is equivalent to
huniversity term: 10/1/2000-29/3/2000i
In the rest of this paper, we assume each news report may have a timestamp which has type date,
and may be pointbased or intervalbased, and complex or atomic. It may also have a sourcestamp
which is an atomic feature of type source and text entry that describes what the source of the news
report is. For example, for a weather report, we may have the atomic feature hsource : BBC TVi.
Whilst we take a restricted position on timestamps and sourcestamps in this paper, we believe that
the approach presented here can be extended to further types and combinations of timestamps and
sourcestamps in structured text. For more information on using temporal knowledge in structured
news reports see [Hun02b].
2.3 Structural information about structured news reports
In order to compare items of structured text on the basis of their structure, we will use the following
notion of a skeleton.
Definition 2.13 A skeleton is a tree (N; E; S) defined as follows: N is the set of nodes where
each node is a semantic label; E is a set of edges represented by pairs of nodes; and S is the set
of sibling neighbours represented by pairs of nodes such that (x; y) 2 S iff (i) x and y are siblings
(i.e. x and y have the same parent) and (ii) x is to the left of y.
According to Definition 2.13, the relative positions of siblings is important in a skeleton. So if x
and y are siblings in a skeleton T , such that x is left of y, then we can form a different skeleton
is left of x.
Since a skeleton is essentially a complex feature without the text entries, a skeleton can be formed
from an item by just removing the text entries. In other words, we use the semantic labels in a
item of structured text as the name of the nodes in the skeleton. We call each such name, the
simple name of the node. However, to obviate any problems arising from multiple occurrences of
a semantic label in a complex feature, and hence the same name being used for different nodes, we
can adopt the following definition for pedantic names for nodes. This definition uses the sequence
of semantic labels used on the path from the root to the particular occurrence of a semantic label
in a feature.
Definition 2.14 The pedantic name for any node in a structured news report is defined inductively
as follows: The pedantic name for the root of a structured news report is the semantic label
for the report. For a nested feature let the pedantic name for OE be ff=OE, then
the pedantic name for the root of each / i is ff=OE=Root(/ i ). (If there is more than one / i with the
same semantic label at the root, then the occurrences can be differentiated by adding a superscript
to the semantic label in the pedantic name.)
Example 2.9 The pedantic name for source in Figure 1 is bidreport/reportinfo/source.
Essentially, a pedantic name is like a unix file name that can be given by the path of directories
from the root. But where we do not have ambiguity, we will just use the simple name.
Definition 2.15 The skeleton function, denoted Skeleton, is applied to a complex feature ' and
returns the skeleton (N; E; S) for ', where the set of nodes N is the set of names (simple or
pedantic) formed from the semantic labels used in ', and E and S are defined as follows, where
are either the simple names or pedantic names (as required) for the
semantic labels OE, and the roots of / 1 ,.,/ n , respectively:
ng and i ! jg
So the skeleton function is defined to extract the tree structure of each item of structured text.
skeletons and let - be a preordering
over skeletons such
customer
\Gamma\Psi
name
@
@
@
@R
address
customer
\Gamma\Psi
name
age
@
@
@
@R address
@
@
@
@R
number street city

Figure

2: Assume T3 and T4 are both skeletons. Here, T3 - T4 holds.
then the set of edges in T i is a subset of the edges
in T j , and for all sibling nodes x; y in T i , if x is left of y in T i , then x is left of y in T j .
An example of a pre-ordering is given in Figure 2.
Definition 2.17 Let ' be a complex feature and let S be a skeleton. An instantiation of S by '
is defined as follows:
If Skeleton(') - S then ' is a partial instantiation of S
If Skeleton(') - S and S - Skeleton(') then ' is a full instantiation of S
If ' is an instantiation of S, this is denoted by S(').
With reference to Definition 2.5, structured reports ' 1 and ' 2 have the same structure iff
Definition 2.18 Let F and F' be features such that F 2 Sub(F') and let
A position of F in F' is a pedantic name for the root of F in Skeleton(N; E; S).
be a complex feature. The anchor for each complex feature
/ i is OE. So each of / 1 ; ::; /n is anchored at OE.
The anchor is the position from which one or more complex features hang. In this way, the anchor
gives the connection to the rest of structured text.
Example 2.10 Consider Figure 1. Here we can see hbid date: May 2000i is at position
bidreport/biddate and it is anchored at bidreport.
In this way, we are using the notions of nodes in skeletons and semantic labels in structured reports
interchangeably.
3 Syntax for fusion
In this section, we give the syntax for the fusion rules and associated background knowledge for
defining fusion systems. We assume fusion is undertaken on pairs of structured news reports, and
that these reports are represented as logical terms in the logical fusion rules.
Definition 3.1 Each complex feature is equivalent to a ground term called a feature term.
is a complex feature, and / 0
1 is a feature term that represents / 1 , .,
and / 0
is a feature term that represents /n , then OE(/ 0
) is a feature term that represents
is a complex feature, then OE(/) is a feature term that represents it.
Definition 3.2 Each text entry is equivalent to a constant symbol called a text entry constant. So
if T is a text entry, then T is a text entry constant.
Example 3.1 Consider the following item of structured text.
This can be represented by the feature term:
In defining fusion rules, we require three kinds of atom. These are structural atoms, background
atoms, and action atoms. The structural atoms capture information about the structure and
type of complex features, and the type and text entries for the atomic features, in individual
structured news reports, and between paris of structured news reports. The background atoms
relate information in individual structured news reports to the domain knowledge. Finally, action
atoms capture instructions for building merged structured news reports.
Definition 3.3 The structural atoms are atoms that include the following definitions:
1. FeatureType(F,T) where T is the type of feature F.
2. Report(R) where R is a structured news report.
3. TextEntry(A,E) where E is the text entry for the atomic feature A.
4. IncludeFeature(F,F') where F' is a feature in F, and so F' 2 Sub(F).
5. AtomicFeature(F,A) where A is an atomic feature in F.
6. Position(F,P,R) where P is a position of the feature F in the report R.
7. Anchor(F,P,R) where P is a position of an anchor of the feature F in the report R.
8. SameSkeleton(F,F') where the features F and F' are such that
9. SameTextEntry(A,A') where the atomic features A and A' have the same text entry.
10. NextSibling(P,P',R) where position P is an immediate sibling to the left of P' in report R.
We denote the set of structural atoms by S.
Example 3.2 To illustrate some of these atoms, consider the following:
Example 3.3 Consider Figure 1. Let this report be denoted R, and let hbid date: May 2000i
be denoted F. For this, we have
The structural atoms are evaluated by the underlying implementation for fusion. In other words,
for any pair of structured news reports, the set of ground structural atoms that hold is completely
determined. These atoms can be viewed as "built-in" predicates by analogy with Prolog.
We also require atoms that relate the contents of structured text to the background knowledge.
These are background atoms and a partial list is given below.
Definition 3.4 The background atoms are atoms that include the following definitions:
1. SameDate(F,F') where F and F' are timestamps that refer to the same time point.
2. SameSource(F,F') where F and F' are sourcestamps that refer to the same source.
3. SameCity(F,F') where F and F' are features that refer to the same city.
4. Source(R,F) where F is the sourcestamp in the report R.
5. Date(R,F) where F is the datestamp in the report R.
6. Coherent(F,F') where the features F and F' are coherent.
7. Prefer(F,F') where the feature F is preferred to the feature F'.
We denote the set of background atoms by B.
Example 3.4 To illustrate background atoms consider the following literals that may be included
in the background knowledge:
Background atoms like SameDate(F,F'), SameSource(F,F'), and SameLog(F,F') are useful to
determine when two features are equivalent and thereby indicate whether the features they come
from are on the same topic. For example, if we have two reports, we can use these atoms to
determine that the two reports have SameCity and SameDate holding, as a precondition before
merging. We will use them as conditions in fusion rules below for this purpose.
The coherent relation captures when two features are mutually consistent. The simplest form of
inconsistency is between a pair of atomic features. Consider two structured reports, ' 1 and ' 2 ,
where the atomic feature hff : OEi is in item ' 1 and the atomic feature hff : /i is in item ' 2 and
OE 6= /. For some semantic labels, this inequality would suggest an inconsistency with the domain
knowledge, as illustrated by Example 3.5. Obviously different text entries for the same semantic
label do not always suggest an inconsistency, as illustrated by Example 3.6.
Example 3.5 Let ' 1 and ' 2 be two structured reports. Suppose hweather : suni is an atomic
feature in ' 1 and hweather : raini is an atomic feature in ' 2 , and ' 1 and ' 2 are on the topic
"weather reports for London on 1 August 1999".
Example 3.6 Let ' 1 and ' 2 be two structured reports. Consider hcity : Londoni is an atomic
feature in ' 1 and hcity : Parisi is an atomic feature in ' 2 , and ' 1 and ' 2 are on the topic "weather
reports for 1 August 1999".
An example of a definition for the coherent relation is given below.
Example 3.7 Let us assume we have the following background knowledge for identifying pairwise
inconsistency in atomic features of type weather in weather reports:
This is likely to be only a partial list of literals required for this purpose. In addition, we will need
various further formulae to define Coherent for other types of atomic feature.
The background atoms are evaluated by querying background knowledge. In the simplest case,
the background knowledge may be just a set of ground background atoms that hold. However,
we would expect the background knowledge would include classical quantified formulae that can
be handled using automated reasoning. In any case, the background knowledge is defined by a
knowledge engineer building a fusion system for an application.
Definition 3.5 The set of check atoms, denoted C, is the union of the structural atoms and the
background atoms.
We now consider the syntax for action atoms, and this requires the definition for action functions.
Definition 3.6 The set of action functions include the following functions that can be used as
terms in the action atoms.
1. Interval(X,Y) where X and Y are text entries
and the function returns an interval X-Y.
2. Conjunction(X,Y) where X and Y are text entries
and the function returns a text entry X and Y.
3. Disjunction(X,Y) where X and Y are text entries
and the function returns a text entry X or Y.
We assume action functions are defined in the underlying implementation that uses the actions as
instructions to build a merged report.
Example 3.8 The following are examples of definitions for action functions:
We now consider a basic set of action atoms. In Section 6, we consider extending the set of action
atoms.
Definition 3.7 The action atoms are atoms that include the following definitions:
1. CreateSkeleton(R) where R is a report. The resulting action is to create the skeleton for
the merged report. The postcondition of this action is Skeleton(R) holding.
2. AddText(E,P) where E is a text entry, and P is a tree position. The resulting action is to
add the text entry to the tree in position P. The precondition of this action is that there is no
offspring, or text entry, for the semantic label at P. The postcondition of this action is that
E is the text entry for the semantic label at P.
3. ExtendFeature(F,P) where F is a feature and P is a position. The resulting action is to
extend the tree with F at position P. The preconditions for this are that the semantic label
for Root(F) should equal the semantic label at P and there is no offspring, or text entry, for
the semantic label at P. The postcondition of this action is that Root(F) is at P.
4. AddFeature(F,P) where F is a feature and P is a position. The resulting action is to add F
to the tree in position P. The precondition of this action is that there is no text entry for the
semantic label at P. The postcondition of this action is that the semantic label at position P
is the anchor for F.
5. Populate(F,P) where F is a feature and P is a position. If there is a Skeleton(F) attached
to position P in the tree, then the resulting action is to add the text entries in F to the
vacant slots in Skeleton(F) in the tree. The preconditions of this action are that there are
no text entries in the offspring of the semantic label at P and the skeleton rooted at P equals
Skeleton(F). The postcondition of this action is that Root(F) is at P.
We denote the set of action atoms by A.
Example 3.9 Let R be the report on the left below. Then Skeleton(R) gives the item on the right
below:
hweatherreport: hweatherreport:
hsource: TV1 and TV3i hsource: i
hdate: 19.5.1999i hdate: i
htoday: suni htoday: i
htomorrow: sun or raini htomorrow: i
Example 3.10 Consider AddText(BBC TV,weatherreport/source). This instruction applied to
the item below on the left gives the item below on the right.
hweatherreport: hweatherreport:
hdate:
Example 3.11 Consider the item on the left, and the feature F on the right:
hweatherreport: hweathertoday:
hdate: i htemp: 0Ci
The instruction ExtendFeature(F,weatherreport/weathertoday) when applied to the item on
the left above gives the following item:
hweatherreport:
hdate: i
hprecipitation: snowi
htemp: 0Ci
Implicit with the definition for ExtendFeature is the requirement to turn an atomic feature into
a complex feature. This is also possible with AddFeature though not necessarily.
Example 3.12 Consider the item on the left, and the feature F on the right:
hweatherreport: hprecipitation:
hdate: i hamount: 2cmi
Then the instruction AddFeature(F,weatherreport) gives the following item:
hweatherreport:
hdate: i
htype: snowi
Example 3.13 Consider the item on the left, and the feature F on the right.
hweatherreport: hweathertoday:
hdate: i htemp: 0Ci
Then the instruction Populate(F,weatherreport/weathertoday) gives the following
hweatherreport:
hdate: i
hprecipitation: snowi
htemp: 0Ci
The action atoms cause a structured news report to be constructed. They define the structure of
the report, and the text entries in the report. We will explain how this can be done in Section 5.
In the remainder of this section, we explain how we use these atoms in fusion rules.
Definition 3.8 The set of atoms is C [A. An atom is ground if each term in the atom is ground.
If an atom is not ground, then it is unground. The set of ground atoms is denoted G.
Definition 3.9 Let f:; -g be the set of classical logical connectives. The set of ground
formulae, denoted F , is the set of all classical formulae that can be formed from G and the set of
logical connectives using the usual inductive definition for classical logic.
We leave consideration of quantification to Definitions 3.11 and 3.12. So in the above definition,
if a formula contains an unground atom, then the formula will not be a well-formed formula of
classical logic, because the free variable(s) will be unbound.
Definition 3.10 A check formula is a formula composed from one or more check atoms and
zero or more classical logical connectives using the usual inductive definition for classical logic
formulae. An action formula is a formula composed from one or more action atoms and zero or
more classical logical connectives using the usual inductive definition for classical logic formulae.
In the following definition, we introduce a non-classical form of implication that is denoted by the
Definition 3.11 A fusion rule is a rule of the following form where ff is a check formula and fi
is an action formula.
We assume that each variable in each rule is implicitly universally quantified, with the universal
quantifiers outermost (i.e. if are the free variables in ff ) fi, then the explicitly quantified
version is
Normally, fi will be an atom or a conjunction of atoms. However, if it incorporates disjunction,
then it captures non-determinism in the intended actions, and if it incorporates negation, then the
negation captures a form of preclusion in the intended action.
Example 3.14 The following are four examples of fusion rules.
E)
The action formulae give a logical specification that we can reason with. So for example, if we
have an action :ff given by one fusion rule, and we have an action ff - fi given by another fusion
rule, then taking these together we are obliged to undertake the action fi.
Definition 3.12 The set of background formulae is formed from the check formulae and the
classical universal quantifier, denoted 8, so that any unbound variable is bound by universal quan-
tification. Any subset of the background formulae is called background knowledge.
Definition 3.13 A fusion system is a pair (\Delta; \Gamma) where \Gamma is a set of fusion rules and \Delta is
background knowledge.
We explain how to use a fusion system in the next section.
Executing fusion rules
In order to use a set of fusion rules, we need to be able to execute them. We need a fusion system
and a pair of structured news report to do this.
Definition 4.1 A fusion call is a triple (\Delta; \Gamma; fR1; R2g) where (\Delta; \Gamma) is a fusion system, and
and are structured news reports.
Suppose we want to merge the reports R1 and R2. To do this, we use the background knowledge
and the atoms Report(R1) and Report(R2), and then attempt to apply each of the fusion rules
by a form of modus ponens, adding the consequent of each applied rule to the current execution
state, until no more fusion rules apply.
Definition 4.2 An execution state is a subset of F .
An execution state lists the action formulae that hold at each point in an execution of a fusion
call.
Definition 4.3 The starting execution state for a fusion call (\Delta; \Gamma; fR1; R2g) is fg.
So at the start of an execution, all we know is the background knowledge, and the two reports.
An execution step for a fusion call takes an execution state and a fusion rule and creates a new
execution state. The new execution state is the old execution state plus a grounded version of the
consequent of one of the fusion rules. For this we need a form of substitution.
Definition 4.4 A substitution - for a fusion rule ff ) fi is an assignment - of ground terms
to variables in ff and fi such that -(ff) and -(fi) are ground formulae.
Example 4.1 Consider the first fusion rule in Example 3.14, where R1 and are grounded by
feature terms. A substitution - is
Definition 4.5 An execution step for a fusion call (\Delta; \Gamma; fR1; R2g) is a triple (X; ff
where X is an execution state, ff ) fi is a fusion rule, Y is an execution state, and the following
two conditions hold where - is a substitution for ff ) fi:
1.
2.
Each execution step can be regarded as an application of a form of modus ponens.
Definition 4.6 An execution sequence for a fusion call (\Delta; \Gamma; fR1; R2g) is a sequence of execution
states where the following conditions hold:
1.
2. for all
3. for all an execution step (X for the fusion call (\Delta; \Gamma; fR1; R2g)
4. there is no execution step for the fusion call (\Delta; \Gamma; fR1; R2g) such that
conditions 1 to 3 hold.
An execution sequence for a fusion call therefore ensures that: (1) the execution sequence has the
starting execution state in the first execution step; (2) each execution step results in an expanded
execution state; (3) each execution step follows from the previous step and uses a fusion rule
from the fusion system; and (4) the execution sequence is maximal in the sense that it cannot be
extended without violating the other conditions.
By definition, an execution sequence is a monotonically increasing sequence of sets. Each X i in
the sequence has one more action formula than the previous set X i\Gamma1 in the sequence.
Definition 4.7 An action sequence for an execution sequence hX is a sequence of
action g.
An action sequence in just the sequence of action formulae that are added to the execution state
by each execution step. The action sequence summarizes the actions to be taken to construct the
merged news report.
Example 4.2 Consider the following pair of reports.
hweatherreport: hweatherreport:
hsource: TV1i hsource: TV3i
hdate: 19.5.1999i hdate: 19.5.1999i
hweather: suni hweather: showersi
And a set of fusion rules that includes the following rules:
A fusion call with these fusion rules and news reports together with appropriate background knowledge
can give the following actions:
The complete action sequence is then given by:
In the next section, we consider how we can use an action sequence for constructing a merged
structured news report.
5 Acting on fusion rules
Since we are building a merged structured news report in a number of steps, we need to first clarify
the nature of the intermediate stages in the construction process. To help, we adopt the following
definition of a fusion tree.
Definition 5.1 A fusion tree is a tree of the form (N; is a skeleton,
T is a set of text entries, and B is a subset of N \Theta T . The set of nodes of the tree is N [ T and
the set of edges of the tree is E [ B.
contains the edges that attach the text entries in T to the skeleton. If a fusion tree
T; B) is a skeleton, then fg. If a fusion tree is an item of structured
text, then T is the set of text entries used in the structured text, and B specifies which
atomic features they instantiate. In any case, a fusion tree is a partial instantiation of a skeleton.
Definition 5.2 A construction sequence hT 1 ; ::; for an action sequence hA 1 ; ::; An i is a sequence
of fusion trees such that
1. If T
then
2. T 1 is the result of carrying out A 1 on the fusion tree (fg; fg; fg; fg; fg).
3. T i+1 is the result of carrying out A i+1 on T i .
So an action sequence is a sequence of instructions to build a merged structured news report by
acting incrementally on a fusion tree. To illustrate, consider the following example.
Example 5.1 Continuing example 4.2, we have the action sequence where the first instruction is
CreateSkeleton(R) which results in the following fusion tree.
hweatherreport:
hdate: i
The second instruction is AddText(Conjunction(TV1,TV3),weatherreport/source) which updates
the above fusion tree to give the following fusion tree.
hweatherreport:
hsource: TV1 and TV3i
hdate: i
The third instruction is AddText(19.5.99,weatherreport/date) which updates the above fusion
tree to give the following fusion tree.
hweatherreport:
hsource: TV1 and TV3i
hdate: 19.5.1999i
The fourth instruction is AddText(London,weatherreport/city) which updates the above fusion
tree to give the following fusion tree.
hweatherreport:
hsource: TV1 and TV3i
hdate: 19.5.1999i
The fifth instruction is AddText(sun,weatherreport/weather) which updates the above fusion
tree to give the following fusion tree.
hweatherreport:
hsource: TV1 and TV3i
hdate: 19.5.1999i
hweather: suni
The net result is a merged structured news report.
In Example 5.1, we start by constructing a skeleton, and then adding text entries. So for the fusion
tree (N; T; B), we start by defining (N; E; S), and then incrementally add to T and B until
we have a fusion tree that defines an item of structured text. In the next example, we form a
merged structured news report from some complex features.
Example 5.2 Consider R1 being the first report given in Example 1.2. Now consider the action
sequence
where
For the first instruction, CreateSkeleton(R1), we get the following fusion tree:
hdate :i
For the second instruction, AddText(5 Nov 99; weatherreport=date), we update the above fusion
tree to get the following:
hregion :i
For the third instruction, Populate(F1,weatherreport/regionalreport) we update the above
fusion tree to get the following:
For the fourth instruction, AddFeature(F2,weatherreport) we update the above fusion tree to
get the following:
If an action sequence is non-conflicting and complete, then the set of instructions can be used
to build a fusion tree and they leave no gaps in the text entries in the fusion tree. If the action
sequence is incomplete, then the fusion tree will have text entries missing, and if the action sequence
is conflicting then there will be instructions for putting more than one text entry into the same
position or instructions for putting both a text entry and a complex feature into the same position.
Before defining when an action sequence is complete and non-conflicting, we consider when an
action sequence is consistent.
Definition 5.3 An action sequence hA 1 ; ::; An i is consistent iff fA 1 ; ::; Ang 6' ?.
This definition takes a direct interpretation of consistent. It just means an action sequence is
consistent if there is not an instruction to do both an action ff and an action :ff. An action
sequence can be checked for consistency before an attempt to construct a merged report is made.
Since, an action sequence is a specification for a merged structured news report, we can determine
whether a particular structured news report meets the specification. We define this as follows:
Definition 5.4 The meets relation is a binary relation between items of structured text and
action sequences, and is defined as follows:
R meets . and R meets An
So by recursion, we need to consider the meets relation for action formulae. For action formulae
A i that are atoms, we require the following rules:
R meets AddText(E; P) if 9A s.t. TextEntry(A,E)- Position(A,P,R) holds
R meets AddFeature(F; P) if Anchor(F,P,R) holds
R meets ExtendFeature(F;P) if Position(F,P,R) holds
R meets Populate(F; P) if Position(F,P,R) holds
For action formulae A i that are not atoms, we require the following rules:
R meets ff - fi iff R meets ff or R meets fi
R meets ff - fi iff R meets ff and R meets fi
R meets :ff iff it is not the case that R meets ff
Definition 5.5 An action sequence hA 1 ; :::; An i is non-conflicting iff there is a construction
sequence
However, the meets relation is a little too relaxed in the sense that a report may meet an action
sequence but may also include extra information that has not been specified.
Definition 5.6 The matches relation is defined as follows where R is a structured news report
and is an action sequence.
R matches
iff
R meets
The matches relation identifies the minimal structured news report(s) that meet(s) the action
sequence. In other words, it identifies the news reports that do not include any superfluous information

Definition 5.7 An action sequence hA 1 ; :::; An i is unambiguous iff there is only one construction
sequence
If an action sequence hA 1 ; ::; An i is unambiguous, there is exactly one structured news report R
such that R matches
Definition 5.8 An action sequence hA 1 ; ::; An i is complete iff the construction sequence hT 1 ; ::;
for is such that Tn is a structured news report.
In other words, an action sequence is a complete if it is not the case that the fusion tree that
results has missing text entries.
6 Properties of fusion rules
We now consider a few properties of fusion rules to clarify the nature of the syntax and execution.
Proposition 6.1 Assuming the actions are only composed from the action atoms defined in Definition
3.7. An action sequence hA 1 ; ::; An i is non-conflicting implies the following conditions:
2. :9 P s.t.
3. :9 P s.t.
Proof: Consider condition 1. The result of AddText(E,P) is a fusion tree with E being the text
entry for the atomic feature at P. By the definition of atomic features, there can only be one text
entry at P. So it is not possible to have both E and E' at P when E . So there is no construction
sequence The cases for Conditions 2 and 3
are essentially the same.
A fusion call does not necessarily produce a unique action sequence. In other words, normally
there is some non-determinism in which fusion rules are applied.
Proposition 6.2 Let (\Delta; \Gamma; fR1; R2g) be a fusion call. It is not necessarily the case that there is
a unique action sequence hA 1 ; ::; An i that is generated.
Proof: Consider Example 4.2, in which the action sequence hA 1 ; ::; A 5 i is generated. This fusion
call could equally generate the following action sequence hA 0
There can also be some non-determinism in an action sequence.
Proposition 6.3 Let hA 1 ; ::; An i be an action sequence, and let A i be an action formula in that
sequence. If A i can be rewritten into disjunctive normal form, so A i is equivalent to a formula
there may be more than one structured news report R such that R matches
Proof: Consider a report R1 where and a report
for each A i , Now consider an A i of the form of ff - fi. Clearly
does not meet fi. Also suppose,
does not meet ff and
The length of an execution sequence, i.e. the number of execution steps undertaken for a fusion
call is constrained by the number of fusion rules, and the nature of the inferences from the domain
knowledge, and the size of the structured news reports. In order to get a useful boundary on the
length of an execution sequence, we adopt the following definition.
Definition 6.1 A fusion rule ff ) fi is capped iff the only possible substitutions - are such that
assigns feature terms to the free variables in fi.
All the fusion rules in this paper are capped.
Proposition 6.4 For any fusion call (\Delta; \Gamma; fR1; R2g), if j\Gammaj is finite, and each fusion rule is
capped, then the execution sequence
Proof: The constraints in Definition 4.6 ensure that there are no cycles in an execution sequence.
So there is no execution sequence such that there is an X i and X j where X
j. Hence, there is no sequence of execution steps where the same instantiated form of
a fusion rule is used twice. The only way that we can get an infinite sequence
there are infinitely many -(fi) generated for some rule ff ) fi 2 \Gamma. However, if each fusion rule
in \Gamma is capped, then there are only finitely many -(fi) that can be generated for each fusion rule,
since the only substitutions for the variables in fi come from the feature terms generated from the
structured news reports in the fusion call, and there are only finitely many feature terms that can
be generated from each fusion call. So it is not possible to generate an infinite execution sequence
The assumption that the fusion rules are capped seems quite reasonable if the aim of fusion is to
only include information from the original reports being merged. Indeed if we assume the rules
are capped, we can identify a tighter bound based directly on the size of the structured reports
being merged.
However, the computational viability of a fusion system depends on more than the number of
execution steps taken. Indeed there are a number of factors that need to be considered:
executing fusion rules
ffl reasoning with background knowledge
ffl acting on fusion rules
We can regard each of these activities being a form of classical logic inferencing, and hence the
computational viability is bounded by the computational viability of classical logic. Whilst in
general, reasoning with classical logic is difficult to automate, implementation based on Prolog is
feasible.
Another practical question is whether the syntax can express everything that we want or need to
express. This includes:
ffl Location completeness of structural atoms. This is the ability to describe any structural
relationship in a report in terms of the nesting and sequence of semantic labels and text
entries.
Comparison completeness of background atoms. This is the ability to compare any combination
of text entries with respect to the background knowledge. Clearly the background atoms
presented are only indicative of the possible atoms that may be defined for an application.
ffl Fusion completeness of action atoms. This is the ability to describe how any structured
news report can be constructed. In one sense, the current set of action atoms is sufficient
for this. However, further actions atoms would allow reports to be constructed with fewer
instructions. For example, currently the action atoms cannot directly specify the sequence
in which siblings occur.
The notion of structured news reports that we reviewed in Section 2 provides a rich structural
representation. The check and action atoms that we define in Section 3, do not draw on the full
expressivity of structured new report. However, it is straightforward to add further check and
action atoms to extend the basic fusion framework that we have presented here. To illustrate, we
could introduce the following actions.
Definition 6.2 Further action atoms include:
1. LeftAdd(F,P) where F is a feature and P is a position. The resulting action is to add F to
the fusion tree to the left of the existing feature at P.
2. RightAdd(F,P) where F is a feature and P is a position. The resulting action is to add F to
the fusion tree to the right of the existing feature at P.
To use these actions, we also introduce the following structural atoms.
Definition 6.3 Further structural atoms include:
1. LeftNeighbour(F',F,P,R) where F' and F are features with the anchor at position P in R
and F' is immediately to the left of F.
2. RightNeighbour(F,F',P,R) where F' and F are features with the anchor at position P in R
and F' is immediately to the right of F.
We illustrate the first of these structural atoms below.
Example 6.1 Let R be the news report given in Figure 1. Also consider the following:
For this report, LeftNeighbour(F',F,P,R) holds.
Now we illustrate the action atoms given in Definition 6.2.
Example 6.2 Consider the following fusion tree T.
Now consider the following instructions:
where
For the instruction, LeftAdd(F,weatherreport/regionalreport), applied to the fusion tree T,
we get the following:
But suppose we ignore the previous instruction, and return to the original state T of the fusion tree.
For the instruction RightAdd(F,weatherreport/regionalreport), applied to the fusion tree T,
we get the following:
It is straightforward to extend the framework that we have presented in this paper to accommodate
these atoms.
Clearly, we can greatly extend the set of background atoms depending on the application. Some
further discussion of formulae for the background knowledge including discussion of inconsistency,
temporal knowledge, and domain knowledge is given in [Hun00a, Hun02b], and for further discussion
of lexical and world knowledge see also [Hun01, HM99, Hun96]. Also of relevance are the
options of using ontologies for structured text (see for example [ES01]) and using comprehensive
semantic networks such as WordNet [Mil95]. More generally, it may be appropriate to harness
typed-feature structures [Car92] and machine readable dictionaries [WSG96] for representing and
reasoning with lexical knowledge.
Structured text is a general concept implicit in many approaches to handling textual information
in computing, including tagged text in XML, text in relational and object-oriented databases,
and output from information extraction systems. Structured text can be naturally viewed in logic.
Each item of structured text can be represented by a formula of classical logic. This means that
consistency checking and inferencing can be undertaken with structured text using domain knowledge

We have proposed fusion rules as a scripting language for defining how to merge news reports.
It may be appropriate to develop syntactic sugar and other notational conveniences to enhance
this proposal. This may include using symbols such as AND, OR, and NOT. It may also include
priority ordering over fusion rules to dictate the preferred ordering in which they should apply so
as to allow for simpler antecedents. Further assumptions could also be used about the process to
simplify the notation. For example, each rule has Report(R1) - Report(R2) in the antecedent, and
yet we may assume two reports which are always referred to as R1 and R2, and thereby not need
in the antecedent.
The definition for a fusion call suggests an implementation based on existing automated reasoning
technology and on XML programming technology. The most obvious route for representing each
structured news report is to represent it as an XML document. Once information is in the form of
XML documents, a number of technologies for managing and manipulating information in XML are
available [Bra00]. Possibilities for representing and reasoning with background knowledge include
relational databases, Datalog, and Prolog. Possibilities for implementing an inference engine for
executing fusion rules include a meta-level program in Prolog, or an implementation in a imperative
programming language such as Java. Another possibility is to present fusion rules in RuleML and
harness one of the Java rule engines that are currently being proposed 1 . Finally, an action engine
for acting on the instructions given by the fusion rules, could be implemented in an imperative
programming language such as Java that can manipulate XML. An action engine would need to
take each instruction in an action sequence and construct a construction sequence.
We have not formalized the relationship between the structural atoms and XML technology. How-
ever, there is clearly an overlap in functionality with technologies including the XPath language
and proposals for the XML Query Algebra 2 . However, the main points we want to stress in any
comparison is that: (1) fusion rules offer a logical bridge between logical reasoning with background
knowledge, structural information about news reports to be merged, and logical specifications of
the instructions for producing the merged report; and (2) fusion rules offer a higher-level scripting
language for handling structured text than available with XPath or XML Query Algebra, and so
fusion rules can be used on top of XML technology. In this sense, fusion rules and XML technology
are complementary.
Given that information extraction may be the technology for providing structured news reports
for merging, integration of a fusion system with information extraction technology may be ap-
propriate. The GATE System provides an implemented architecture for managing textual data
storage and exchange, visualization of textual data structures, and plug-in modularity of text processing
components 96]. The text processing components includes LaSIE which performs
information extraction tasks including named entity recognition, coreference resolution, template
element filling, and scenario template filling.



--R

Querying semi-structured data

Inconsistency management and prioritized syntax-based entailment
Semantic integration of heterogeneous information sources.
How to infer from inconsistent beliefs without revising.
A logic-based theory of deductive arguments
Combining knowledgebases of consisting of first-order theories
The XML Companion.
Preferred subtheories: An extended logical framework for default reasoning.
Semistructured data.
The Logic of Typed Feature Structures.
Description logic framework for information integration.
Source integration in data warehousing.
Reasoning with data provided by federated databases.
Information extraction.
Merging databases: Problems and examples.

Management of preferences in assumption based reasoning.
Handbook of Defeasible Resoning and Uncertainty Management Systems
How to structure and access XML documents with on- tologies
A data warehouse conceptual data model for multidimensional aggregation.
Knowledge in Flux.
GATE:an environment to support research and development in natural language engineering.
Tableau techniques for querying information sources through global schemas.
Information extraction techniques and challenges.
Developing finite domain constraints - a data model approach


Intelligent text handling using default logic.
Merging potentially inconsistent items of structured text.
Ramification analysis using causal mapping.
Reasoning with inconsistency in structured text.
A default logic-based framework for context-dependent reasoning with lexical knowledge
Hybrid argumentation systems for structured news reports.
Merging structured text using temporal knowledge.
On the difference between updating a knowledgebase and revising it.
On the logic of merging.

Integration of information in four-valued logics under non-uniform assumptions
A lexical database for English.
Cooperative database systems.
On inferences from inconsistent information.
The KRAFT architecture for knowledge fusion and transformation.
A general formal framework for schema transforma- tion
Query processing in the TAMBIS bioinformatics source integration system.
Building light-weight wrappers for legacy web data-sources using W4F
Federated database systems for managing distributed
Unpacking the semantics of source and usage to perform semantic reconciliation in large-scale information systems
Electric Words: Dictionaries
--TR
Federated database systems for managing distributed, heterogeneous, and autonomous databases
The logic of typed feature structures
WordNet
Electric words
Information extraction
Template-based wrappers in the TSIMMIS system
Semistructured data
A Web-based information system that reasons with structured collections of text
Reasoning About Data Provided By Federated Deductive Databases
A general formal framework for schema transformation
Unpacking the semantics of source and usage to perform semantic reconciliation in large-scale information systems
Ramification analysis using causal mapping
Merging potentially inconsistent items of structured text
A Default Logic Based Framework for Context-Dependent Reasoning with Lexical Knowledge
Semantic integration of heterogeneous information sources
How to structure and access XML documents with ontologies
A logic-based theory of deductive arguments
The XML Companion
Merging structured text using temporal knowledge
Arbitration (or How to Merge Knowledge Bases)
Querying Semi-Structured Data
Tableau Techniques for Querying Information Sources through Global Schemas
Management of Preferences in Assumption-Based Reasoning
Information Extraction
Building Light-Weight Wrappers for Legacy Web Data-Sources Using W4F
Developing Finite Domain Constraints - A Data Model Approach
Source Integration in Data Warehousing
Query Processing in the TAMBIS Bioinformatics Source Integration System
Intelligent Text Handling Using Default Logic
Integration of Information in Four-Valued Logics under Non-Uniform Assumptions

--CTR
Anthony Hunter, How to act on inconsistent news: ignore, resolve, or reject, Data & Knowledge Engineering, v.57 n.3, p.221-239, June 2006
Anthony Hunter , Weiru Liu, Merging uncertain information with semantic heterogeneity in XML, Knowledge and Information Systems, v.9 n.2, p.230-258, February 2006
Anthony Hunter , Rupert Summerton, Merging news reports that describe events, Data & Knowledge Engineering, v.59 n.1, p.1-24, October 2006
Emma Byrne , Anthony Hunter, Evaluating violations of expectations to find exceptional information, Data & Knowledge Engineering, v.54 n.2, p.97-120, August 2005
Emma Byrne , Anthony Hunter, Man bites dog: looking for interesting inconsistencies in structured news reports, Data & Knowledge Engineering, v.48 n.3, p.265-295, March 2004
Anthony Hunter , Weiru Liu, Fusion rules for merging uncertain information, Information Fusion, v.7 n.1, p.97-134, March, 2006
Anthony Hunter, Merging structured text using temporal knowledge, Data & Knowledge Engineering, v.41 n.1, p.29-66, April 2002
Carlos Ivn Chesevar , Ana Gabriela Maguitman , Guillermo Ricardo Simari, Argument-based critics and recommenders: a qualitative perspective on user support systems, Data & Knowledge Engineering, v.59 n.2, p.293-319, November 2006
conflict resolution;merging information;logic-based fusion;heterogenous information;logic-based inconsistency management;structured text;semi-structured text;inconsistency handling