OASIS LegalRuleML TC

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 ~pin 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.