Home » forums » LtU Forum

Detected contradictions in large information systems

With respect to detected contradictions in large information system, according to [Russo, Nuseibeh, and Easterbrook 2000]:

"The choice of an inconsistency handling strategy depends on the context and the impact it has on other aspects of the development process. Resolving the inconsistency may be as simple as adding or deleting information from a software description. However, it often relies on resolving fundamental conflicts, or taking important design decisions. In such cases, immediate resolution is not the best option, and a number of choices are available:

Ignore - it is sometimes the case that the effort of fixing
an inconsistency is too great relative to the (low) risk that the
inconsistency will have any adverse consequences. In such cases,
developers may choose to ignore the existence of the inconsistency in
their descriptions. Good practice dictates that such decisions should be
revisited as a project progresses or as a system evolves.

Defer - this may provide developers with more time to elicit
further information to facilitate resolution or to render the
inconsistency unimportant. In such cases, it is important to flag the
parts of the descriptions that are affected, as development will continue
while the inconsistency is tolerated.

Circumvent - in some cases, what appears to be an
inconsistency according to the consistency rules is not regarded as such
by the software developers. This may be because the rule is wrong, or
because the inconsistency represents an exception to the rule that had
not been captured. In these cases, the inconsistency can be circumvented
by modifying the rule, or by disabling it for a specific context.

Ameliorate - it may be more cost-effective to ‘improve’ a
description containing inconsistencies without necessarily resolving them
all. This may include adding information to the description that
alleviates some adverse effects of an inconsistency and/or resolves other
inconsistencies as a side effect. In such cases, amelioration can be a
useful inconsistency handling strategy in that it moves the development
process in a ‘desirable’ direction in which inconsistencies and their
adverse impact are reduced.

By Hewitt at 2014-04-10 20:20 | LtU Forum | previous forum topic | next forum topic | other blogs | 3588 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

"Correctness" vs. Ignore, Defer, Circumvent, & Ameliorate

One theory is that it is necessary to achieve "correctness" in large software systems. In practice, we need to make a science of ignoring, deferring, circumventing, and ameliorating.

See Inconsistency Robustness 2014

By Hewitt at Sun, 2014-04-20 13:39 | login or register to post comments

Different is different!

It is tempting to try to say a lot about this, but that would spoil the inconsistency. Inconsistent things are different things. We need differences! Difference is not inconsistent, it is just different.

By Hank Thediek at Mon, 2014-04-21 09:56 | login or register to post comments

A contradiction is P and ¬P; even if said by different speakers

A contradiction is P and ¬P; even if said by different speakers.

By Hewitt at Mon, 2014-04-21 11:32 | login or register to post comments

That is only the case if 'P'

That is only the case if 'P' is not context sensitive to the speaker. If Alice says "it is sunny" and Bob says "it is not sunny", there is only a contradiction of information if Alice and Bob are at the same location.

People standing at even slightly different locations can, for example, hear sound in different orders (due to non-instantaneous propagation of sound). This doesn't inherently cause contradiction, much less inconsistency. Inconsistency can only be asserted with respect to a model. If our model tracks context - e.g. who, where, when something is said - then there is no inherent inconsistency from contradiction.

By dmbarbour at Mon, 2014-04-21 12:47 | login or register to post comments

Annihilation:

But this is the problem Binary value judgments are how we evaluate things not haw we define them. Two different situations are two things. If there are two things they deserve separate evaluations, There is no mandate to conflate them. Conflation leads to annihilation.

By Hank Thediek at Mon, 2014-04-21 12:47 | login or register to post comments

Contradictions do not mean "annihilation."

Contradictions do not mean "annihilation" provided that we are not restricted to using classical logic.

Instead, we can using inconsistency-robust reasoning. See Formalizing common sense for scalable inconsistency-robust information integration using Direct Logic reasoning and the Actor Model.

By Hewitt at Tue, 2014-04-22 11:45 | login or register to post comments