[exception of exception]

[monica.palmirani <monica.palmirani@unibo.it>]

This is an extract of the skype chat of June 1st about mainly two topics:
a) <Mutex>
b) exception of exception

Two more proposals:
PROPOSAL#1: use Rule instead of Implies like in Reaction Rule.
PROPOSAL#2: use idReq and idOpt for identifying the nodes and to permit
idRef validation.

EXAMPLE:
A person commits an offense if he intentionally or knowingly causes the
death of an individual.
A person who causes an offense in self-defence does not act unlawfully.
A person who exceeds the self-defence commits an offense.

mp
-----------------------------------
@Monica - could we copy this entire chat into an email so we have a
separate archive? It doesn't really belong in the minutes of the
telecon, I think.

@Adam - yes that is what I meant: the defeasibility is "on top of" the
ACE representation, so the expression of defeasibility does not need to
be stated in ACE, just the clauses. I would also be interested to see
the example Monica mentions.
[31/05/2012 16:30:40 | Edited 16:30:58] mp: You mean <logop> example?
[31/05/2012 16:32:06] Tara Athan: I mean the example of exception of
exception.
[31/05/2012 16:32:42] mp: yes modification of modification it also a
case, repeal of repeal
[31/05/2012 16:32:47] mp: ok
[31/05/2012 17:34:57 | Edited 17:35:32] Tara Athan: I have a separate
question about how to specify conflicting rules in defeasible logic. I
am thinking about a general case of imposing a fine for, say, a parking
ticket. It would be a general principle that there should be exactly one
fine per ticket, but an individual may have multiple tickets, so it
would not necessarily be a conflict that one indiviual should be obliged
to pay multiple fines. This is the sort of situation where it seems to
be to be useful to explicitly represent a variable when referencing a rule

something like

<Conflicting>
<Expr>
<Fun iri="fine_x"/>
<Var>ticket-id</Var>
</Expr>
<Expr>
<Fun iri="fine_y"/>
<Var>ticket-id</Var>
</Expr>
</Conflicting>
[31/05/2012 20:02:47] Harold Boley: This seems to be a 'mutual
exclusion' (often dubbed <Mutex>), a special kind of integrity constraint.
Benjamin Grosof had used it in Courtecous LP and we had it in some
version of RuleML 0.x
[31/05/2012 20:14:47 | Edited 20:22:36] Tara Athan: <Mutex> in 0.89 does
seem to play this role (http://ruleml.org/0.89/xsd/modules/mutex_module.xsd)

It was merged with <Integrity> in 0.9
(http://ruleml.org/0.9/glossary/#gloss-Integrity)

<Integrity> was dropped in 0.91 in favor of an <Entails> statement in an
<Assert> (http://ruleml.org/0.91/#Changes)

However, violation of integrity constraint indicates inconsisstency, if
I understand this correctly, while the presence of conflicting
defeasible rules in a rulebase does not indicate inconsistency.
[31/05/2012 20:29:03] Harold Boley: Recalling the 'hard-constraint'/
'soft-constraint' distinction, we could have 'soft-constraint'-like
integrity constraints which can be overriden like defeasible rules can
override others: such a merger of integrity constraints and defeasible
logic might become the topic of a paper (but Google may show someone
already published about this).
[01/06/2012 03:13:24 | Edited 03:13:47] Guido Governatori: Indeed
<Mutex> was proposed by Grosof in CLP , which is a variant of Defeasible
Logic, and I have used in my 2005 paper on representing contracts in RuleML.
[01/06/2012 03:15:36] Guido Governatori: if A and B are in a "mutex"
relationship they cannot be true at the same time. So it is a for of
intergrity constraint.
[01/06/2012 03:19:08 | Edited 03:20:30] Guido Governatori: hard/sof
constraints are not related to defeasibility. That A is a defeasible
conclsuion of a knowledge base (rule set + facts) means that A might not
be a conclusion if we have more information (in the sense of facts).
[01/06/2012 03:21:49 | Edited 03:22:27] Guido Governatori: There are two
ways to handle conflictings conclusions in defeasible reasoning. The
first is by explicity defining mutex
[01/06/2012 03:24:19] Guido Governatori: the second is to use the
closure under strict rules of a conclusion. Then two rules are
conflicting, if the closures under strict rules of the conclusion of the
two rules are inconsistent.
[01/06/2012 03:27:42] Tara Athan: Presumably it is ok to mix these two
methods, so rules that naturally conflict, such as complementary heads,
are not required to have a mutex statement?
[01/06/2012 03:29:35] Guido Governatori: The closrue method immediately
identifies conflicts when the conclusion of one rule is the complement
of the conclusion another rule
[01/06/2012 03:30:44 | Edited 03:32:23] Guido Governatori: In my 2005
paper I defined ~p\in Mutex(p) (~p being the complement of p)
[01/06/2012 03:32:03] Guido Governatori: where mutex maps a ground
literal to a set of ground literals.
[01/06/2012 03:36:38] Tara Athan: Are you refering to coala.pdf? I can't
find Mutex in the XML representation.
[01/06/2012 03:37:41] Tara Athan: Oh I see, you use <Ic> instead.
[01/06/2012 03:38:36] Guido Governatori: yes
[01/06/2012 03:41:59] Tara Athan: So in your example

<Iclabel=’price’>
<And>
<Atom>
<Rel>Price</Rel>
<Var>Good</Var>
<Var>X</Var>
</Atom>
<Atom>
<Rel>Price</Rel>
<Var>Good</Var>
<Var>Y</Var>
</Atom>
<Atom>
<not>
<eq>
<Var>X</Var>
<Var>Y</Var>
</eq>
</not>
</Atom>
</And>
</Ic>

the free variable <Var>Good</Var> is the same in these two literals.

The difference in the LegalRuleML example is that we refer to the
literals by reference to their identifiers. When we do that, I believe
we must make the free variables explicit, using the <Expr>.
[01/06/2012 03:46:13] Guido Governatori: Yes, <Var>Good</Var> is the same
[01/06/2012 03:46:21] Guido Governatori: snd so are X and Y
[01/06/2012 03:47:17 | Edited 03:47:57] Guido Governatori: given that
the variables are free in the formula (And), standard logic rules apply
[01/06/2012 04:50:09] Tara Athan: Sorry for the following long example,
I got a little carried away:
[01/06/2012 04:50:13] Tara Athan: <!-- Exception of an exception ? -->

<Implies strength="defeasible">
<!-- the scope of the variables
<Var>Date</Var>
<Var>Price-for-Monday</Var>
<Var>Good</Var>
is limited to this <Implies> element
-->
<if>
<!-- Every Monday -->
<And>
<Equal>
<Expr>
<Fun>DayOfWeek</Fun>
<Var>Date</Var>
</Expr>
<Data>Monday</Data>
</Equal>
<Equal>
<Var>Price-for-Monday</Var>
<Data>$1</Data>
</Equal>
</And>
<then>
<!-- all prices are $1 -->
<Atom id="a1">
<Rel>Price</Rel>
<Var>Good</Var>
<Var>Price-for-Monday</Var>
<Var>Date</Var>
</Atom>
</then>
</Implies>

<Implies strength="defeasible">
<!-- the scope of the variables
<Var>date</Var>
<Var>good</Var>
<Var>price-for-15th</Var>
is limited to this <Implies> element.

Assuming a different author for this second rule,
so there is no consistent naming convention between the
two rules.
-->
<if>
<!-- On the 15th of the month -->
<And>
<Equal>
<Expr>
<Fun>DayOfMonth</Fun>
<Var>date</Var>
</Expr>
<Data>15</Data>
</Equal>
<Equal>
<Var>price-for-15th</Var>
<Data>$2</Data>
</Equal>
</And>
<then>
<!-- all prices are $2 -->
<Atom id="a2">
<Rel>Price</Rel>
<Var>good</Var>
<Var>price-for-15th</Var>
<Var>date</Var>
</Atom>
</then>
</Implies>

<Implies closure="universal">
<!-- On a given date, the price of a good is unique -->
<if>
<Neg>
<Equal>
<Var>X</Var>
<Var>Y</Var>
</Equal>
</Neg>
</if>
<then>
<Conflict>
<Expr>
<Fun idref="a1"/>
<Var>DATE</Var>
<Var>GOOD</Var>
<Var>X</Var>
</Expr>
<Expr>
<Fun idref="a2"/>
<Var>DATE</Var>
<Var>GOOD</Var>
<Var>Y</Var>
</Expr>
</Conflict>
</then>
</Implies>


<Implies strength="defeasible">
<!-- If the 15th of some month is a Monday,
then the pricing policy for the 15th of the month
takes precedence, -->
<if>
<And/>
</if>
</then>
<Overrides>
<Expr>
<Fun idref="a2"/>
<repo><Var>S</Var></repo>
</Expr>
<Expr>
<Fun idref="a1"/>
<repo><Var>T</Var></repo>
</Expr>
</Overrides>
</then>
<Implies>

<Implies strength="strict">
<!-- except in February, when the pricing policy
for Mondays takes precedence. -->
<if>
<Equal>
<Expr>
<Fun>Month</Fun>
<Var>date</Var>
</Expr>
<Data>February</Data>
</Equal>
</if>
</then>
<Overrides>
<Expr>
<Fun idref="a1"/>
<Var>date</Var>
<repo><Var>U</Var></repo>
</Expr>
<Expr>
<Fun idref="a2"/>
<Var>date</Var>
<repo><Var>V</Var></repo>
</Expr>
</Overrides>
</then>
<Implies>
[01/06/2012 08:34:05] Guido Governatori: The idea is that. A simpler
example is
[01/06/2012 08:34:59 | Edited 08:35:50] Guido Governatori: if A causes
damages to another person, then A is responsible for the damages
[01/06/2012 08:36:23] Guido Governatori: if somebody acts in
self-defence, then he/she is not reposible for damages caused to
anotther person
[01/06/2012 08:36:57] Guido Governatori: if somebody exceeds in
self-defence then he/she is responsible
[01/06/2012 08:37:11] Guido Governatori: the second rule overrides the first
[01/06/2012 08:37:20] Guido Governatori: and the third rule overrides
the second
[01/06/2012 15:03:40] Adrian Paschke: [giovedì 31 maggio 2012 00:01]
Harold Boley:

<<< @Adrian? Do you want to join a 'task force' on deontic legal
operators with guido, adrian, harold? See surrounding chat.Yes, I worked
on temporal/interval-based denotic norms in the Rule Based SLA (RBSLA)
language based on RuleML
[01/06/2012 15:29:13] mp: The temporal issue for now is the next topic
after the deontic.
[01/06/2012 15:33:13] mp: Concerning the new modality of discussion via
skype: Guido and I are organizing some mails with the main topics and
the track in annex. Tara has send now the first fragment. We are
readjusting for the rest.
[01/06/2012 15:35:34] Adrian Paschke: in the RBSLA language I used
integrity constraints to explicitly define the constraints for the
conclusions:
1. Not-constraints: express that none of the stated conclusions should
be drawn: integrity( not( p1(…), .. , pn(…))).
2. Xor-constraints: express that the stated conclusions are mutual
exclusive, i.e. should not be drawn at the
same time: integrity(xor(p1(…),..,pn(…))).
3. Or-constraints: express that at least one of the stated conclusions
should be drawn: integrity(or(p1(…),..,pn(…))).
4. And-constraints: express that all of the stated conclusion should be
drawn: integrity (and(p1(…), .. , pn(…))).
[01/06/2012 15:36:00] Adrian Paschke: the Xor constraints are similar to
"Mutex"
[01/06/2012 15:37:29] Adrian Paschke: these constraints can be used in
the post conditional checks (integrity checks) on the state/effects
after the execution of actions in reaction rules (reaction ruleml post
condition)

LA RICERCA C’È E SI VEDE:
5 per mille all'Università di Bologna - C.F.: 80007010376
http://www.unibo.it/5permille

Questa informativa è inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell’ente.