W3C home > Mailing lists > Public > public-rule-workshop-discuss@w3.org > August 2005

RE: Merging Rulesets

From: Anthony Finkelstein <anthony@systemwire.com>
Date: Wed, 31 Aug 2005 16:13:48 +0100
Message-Id: <p06210214bf3b78adcf1b@[192.168.181.53]>
To: "Gerd Wagner" <wagnerg@tu-cottbus.de>, "'Sandro Hawke'" <sandro@w3.org>
Cc: <public-rule-workshop-discuss@w3.org>

You may find the approach in my paper below of interest. We take 
rules (expressed in FOL) and statically identify the set of repairs 
that can be made when inconsistencies are identified. When the rules 
are applied we specifically instantiate these. We have heuristics for 
which of the repair actions should be applied.

C. Nentwich, W. Emmerich and A. Finkelstein, "Consistency Management 
with Repair Actions," presented at Proc. of the 25th Int. Conference 
on Software Engineering, Portland, Oregon, 2003.

http://www.cs.ucl.ac.uk/staff/A.Finkelstein/papers/repairactions.pdf



Anthony


At 11:28 pm +0200 29/8/05, Gerd Wagner wrote:
>  > Can you give me a simple example of where you can't merge FOL like
>>  this, to help me understand the problem (and explain it to others)?
>>  It seems obvious that FOL merges (I guess it follows from
>>  And-Introduction [1]), although perhaps there's a subtlety that I'm
>>  missing?
>>
>>  Maybe you can phrase it in terms of scenario #2, where several
>>  organizations are publishing knowledge about drug interactions.  Each
>>  of them publishes a view of their KB, using a shared ontology.  It
>>  seems to me that the only time adding another source would cast doubt
>>  on conclusions derived from conjoining previous sources would be if a
>>  contradiction arose when the new KB was conjoined.  Does the seeming
>>  need for non-monotonicity perhaps parallel the need for dealing with
>>  such possible logical inconsistencies? 
>
>Yes, indeed, handling/resolving inconsistencies does typically
>create non-monotonicity when you merge knowledge items such as
>rules. Notice that in classical FOL this issue is simply avoided
>by the unrealistic principle "ex contradictione sequitur quodlibet"
>(or "Law of the Excluded Contradiction"), according to which the
>entire KB is meaningless as soon as a single contradiction arises
>somewhere in it (which is OK for mathematical logic but not for
>practical knowledge systems).
>
>When you merge rule sets from different (cognitive agent) sources
>you must take into account that there may be inconsistencies in
>the merge result, but they do not invalidate all rules in the merge
>set. Only when you merge rule sets from the same agent, you may
>assume that this agent is sensible enough to avoid any inconsistency.
>So, the requiremement for merging rule sets implies nonmonotonicity.
>
>Notice that in an empirical domain such as the "Validating
>Prescriptions" scenario of the charter draft, you will typically
>have to reason with positive and negative evidence. And you are
>not only interested in drawing 100% safe/monotonic conclusions
>(which may mean no conclusion at all in certain cases) but you
>are rather interested in drawing informed (but possibly
>unsafe/nonmonotonic) conclusions that allow you to act
>rationally, simply because not acting at all may also kill
>people.
>
>Coming back to your scenario, I think it's realistic to
>have the following kinds of rules:
>
>a) pimozide is contraindicated with macrolides according to a
>    1996 FDA bulletin
>
>b) pimozide is safe in conjunction with macrolides for men
>    over 60 according to a 1999 FDA bulletin
>
>Then b would logically contradict a, and we would need
>a nonmonotonic conflict resolution procedure such as
>giving higher priority to more specific and/or more
>recent pieces of knowledge.
>
>-Gerd


-- 
_________________________________________________________________________

Anthony Finkelstein
Systemwire
Director of Strategy

TEL: +44 (0)20 7679 7293 (Direct Dial)
MOB: +44 (0)7771 813981
EMAIL: anthony@systemwire.com
WEB: http://www.systemwire.com

_________________________________________________________________________
Received on Wednesday, 31 August 2005 15:13:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:16:23 GMT