Technical Note: 2.1Defeasibility.002
Author: Guido Governatori, Monica Palmirani
Date: April 18, 2012
Contributors: Tara Athan, Harold Boley
Defeasibility
According to Legal Theory scholars [1]sartor2005 norms can be represented by rules with the form
if A_1,...,A_n then B
where A_1,...,A_n are the pre-conditions of the norm, B is the effect of the norm, and if ... then
... is a normative conditional.
One of the aims of the LegalRuleML Specifications is to propose a representation for such rules.
Again, it is well understood in Legal Theory [1]sartor2005 that, typically, there are different types of
“normative conditionals”, but in general normative conditionals are defeasible. There are several uses of
defeasibility.
The first use of defeasible rules is to capture conflicting rules/norms without making the resulting set of
rules inconsistent. Thus, given the rules (with -expression we mean the negation of expression)
body_1 => head
body_2 => -head
where the two rules would conclude the negation of each other, without defeasibility, in a situation where
both bodies applies we would conclude a contradiction, i.e., head and -head. Defeasible reasoning, on
the contrary, is sceptical: in case of a conflict it refrains from taking any of the two conclusions, unless
there are mechanisms to solve the conflict (see the section of Superiority relation below).
Notice that an application of this is to model exceptions. Exceptions limit the applicability of basic
norms/rules, for example
body => head
body, exception_condition => -head
In this case, the second rule is more specific than the first, and thus it forms an exception to the first, i.e., a
case where there are extra conditions in the rule encoding the exception, blocking the conclusion of the first
rule.
Often, exceptions, in defeasible reasoning can be simply encoded as
body => head exception_condition => -head
Going back to the definition above (i.e., pre-conditions/effect), we can see a rule as a binary relationship
between the pre-conditions (or body) of the rule, and the (legal) effect (head) of the rule. Formally, a rule
can be defined by the following signature
body ⨉ head
We can then investigate the nature of such a relationship. Given two sets we have the following seven
possible relationships describing the “strength” of the connections between the body and the head of a
rule:
body
body
body
body
body
body
body
always head
sometimes head
not complement head
no relationship head
always complement head
sometimes complement head
not head
In defeasible logic we can represent the following relationships using the following rules (rule types)
body
body
body
body
body
body
->
=>
~>
->
=>
~>
head
head
head
-head
-head
-head
The seventh case is when there are no rules between the body and the head.
Rules of the form body -> head are known as strict rules, rules of the form body => head are
known as defeasible rules, and rules of the form body ~> head are known as defeaters.
The meaning of the different types of rules is as follows:
Strict rules
body -> head
Every time the body holds then the head holds.
Defeasible rules
body => head
When the body holds, then, typically, the head holds. Alternatively we can say that the head holds when
the body does unless there are reasons to assert that the head does not hold. This captures that it is
possible to have exceptions to the rule/norm, and it is possible to have prescriptions for the opposite
conclusion.
Defeaters
body ~> head
Defeaters are rules that cannot establish that the head holds. Instead they can be use to specify that the
opposite conclusion does not hold. In argumentation two types of defeaters are recognized: undercutting
defeaters and rebutting defeaters. Undercutting defeaters are used in situations where there is an argument
attacking the preconditions of a rule (or an argument), while the use of rebutting defeaters is to say that
there is no relationship between the premises of an argument (preconditions of a rule or body) and the
conclusion of the argument (effect of the rule or head).
Superiority relation
Given the possibility to have conflicting rules, i.e., rules with opposite or contradictory heads, for example
body1 => head
body2 => -head
Systems for defeasible reasoning include mechanisms to solve such conflicts. Different methods to solve
conflicts have been proposed: specificity, salience and preference relation. According to specificity, in case
of a conflict between two rules, the most specific rule prevails over the less specific one, where a rule is
more specific if its body subsumes the body of the other rule. For salience each rule has attached to it its
salience or weight, and in case of a conflict between two rules, the one with the greatest salience or weight
prevails over the other. Finally, a preference relation (also known as superiority relation) defines a binary
relation over rule, where an element of the relation states the relative strength between two rules. Thus, in
case of a conflict between two rules, if the preference relation is defined over such rules, the strongest of
the two rules wins over the other.
Specificity corresponds to the well know legal principle of lex specialis. [2]prator argue the specificity is
not always appropriate for legal reasoning and that there are other well understood legal principles such as
lex superior and lex posterior and there are cases where several of them apply, and the lex specialis
principle might not the one used to solve the conflict, for example a more specific article from a local
council regulation might not override a less specific constitutional norm. [2]prator propose to use a
dynamic preference relation to handle conflicting rules. The preference relation is dynamic in the sense that
it is possible to argue about which instances of the relation hold and under which circumstances. [3]grigoris
proposes that instances of the superiority relation appear in the head of rules, namely:
body => superiority
where superiority is a statement with the form
r1 > r2
where r1 and r2 are rule identifiers.
[4]carneades proposes Carneades as a rule based argumentation system suitable for legal reasoning where
they use weights attached to the arguments (rules) to solve conflicts and to define proof standards. [5]icail
shows how to use the weights to generate an equivalent preference relation, and, consequently, how to
capture the proposed proof standards. In addition [5]icail shows that there are situations where a preference
relation cannot be captured by weight on the rules.
XML representation
Based on the discussion above it seems that the starting point for an XML representation of rules for norms
is, for example, for a defeasible rule
<Defeasible node="#ruleID">
<if>
Body
</if>
<then>
Head
</then>
</Defeasible>
The above representation is appropriate for when either we ignore or we have resolved the temporal,
provenance (source, authorship, jurisdiction, …) aspects. Thus a more appropriate representation could be
<Implies dfs:strenght="/ontology/defeasible.owl#defeasible"
node="#ruleID">
<if>
Body
</if>
<then>
Head
</then>
</Implies>
for Body => Head.
To represent Body => -Head, we also need the strong negation element <Neg>:
<Implies dfs:strenght="/ontology/defeasible.owl#defeasible"
node="#ruleID">
<if>
Body
</if>
<then>
<Atom>
<Neg>
head content
</Neg>
</Atom>
</then>
</Implies>
Notice that <Neg> is used inside the representation of the head, thus the external structure of a rule Body
=> -Head is the same as that of a rule Body => Head.
All other rule strenghts can be represented with the existing RuleML 1.0 customization of implication plus
(strong/classical) negation <Neg>.
Syntactic shortcuts could also be used, e.g., for example a defeater Body ~> -Head can be represented
<Implies dfs:strenght="/ontology/defeasible.owl#defeater"
node="#ruleID">
<if>
Body
</if>
<then>
-Head
</then>
</Implies >
On the Representation of Rules
At the basic level a rule is a binary relationship between the body of the rule and the head. However, in
the legal domain we have to capture several other aspects, for example:


authorship / jurisdiction …
temporal aspects, for example, the time when a norm has been enacted, and when the norm
entered into force.
Consider the following statement
At time t1, according to source S, the reading of article A at time t2 was body => head
This suggests that rules are better captured, by objects with the following signature [6]igpl
rule: author ⨉ time ⟼ (time ⟼ body ⨉ type ⨉ head)
A rule is function from an author/authority at a time to the content and type of the rule at a time.
According to the above discussion a better solution is to separate the qualification of the rule from its
representation, in order to avoid redundancy of the same rule only for capturing a different status
(defeasible, strict, defeater).
RuleML Version 1.0 can represent such meta-knowledge with “internal” or “external” facts:
“Internal:”
<Implies node="#rule1">
<meta>
<Atom node="#ruleInfo1">
<Rel iri="&ruleml;Implies"/>
<slot>
<Ind iri="&legalruleml;source"/>
<Ind iri="#sourceBlock"/>
</slot>
<slot>
<Ind iri="&dfs;strenght"/>
<Ind iri="/ontology/defeasible.owl#defeasible"/>
</slot>
<slot>
<Ind iri="&legalruleml;jurisdiction"/>
<Ind iri="/ontology/europe.owl#europe"/>
</slot>
<slot>
<Ind iri = "&dc;Creator"/>
<Data>Monica Palmirani</Data>
</slot>
<slot>
<Ind iri = "&dcterms;Creator"/>
<Ind iri = "#aut2"/>
</slot>
<slot>
<Ind iri = "&dc;Creator"/>
<Data>Tara Athan</Data>
</slot>
<slot>
<Ind iri = "&dcterms;Creator"/>
<Ind iri = "#aut3"/>
</slot>
<slot>
<Ind iri = "&dcterms;created"/>
<Data xsi:type="date">2012-03-30</Data>
</slot>
<slot>
<Ind iri = "&legalruleml;authority"/>
<Ind iri = "/ontology/ministyOfJustice.owl#justice"/>
</slot>
</Atom>
</meta>
<if>
<Atom node="#body1">…</Atom>
</if>
<then>
<Atom node="#head1">…</Atom>
</then>
</Implies
"External:"
<Atom>
<oid><Ind iri = "#body1"></oid>
<Rel iri = "&ruleml;Atom"/>
<slot>
<Ind iri="&legalruleml;source"/>
<Ind iri="#sourceBlock"/>
</slot>
<slot>
<Ind iri="&legalruleml;jurisdiction"/>
<Ind iri="/ontology/europe.owl#europe"/>
</slot>
<slot>
<Ind iri = "&dc;Creator"/>
<Data>Monica Palmirani</Data>
</slot>
<slot>
<Ind iri = "&dcterms;Creator"/>
<Ind iri = "#aut2"/>
</slot>
<slot>
<Ind iri = "&dc;Creator"/>
<Data>Tara Athan</Data>
</slot>
<slot>
<Ind iri = "&dcterms;Creator"/>
<Ind iri = "#aut3"/>
</slot>
<slot>
<Ind iri = "&dcterms;created”/>
<Data xsi:type="date">2012-04-01<Data>
</slot>
<slot>
<Ind iri = "&legalruleml;authority"/>
<Ind iri = "/ontology/ministyOfJustice.owl#justice"/>
</slot>
</Atom>
and similarly for annotations of the conclusion of the rule.
Because the meta-knowledge is represented as RuleML facts, it can itself be annotated with meta-metaknowledge. For example, the meta-knowledge could have a limited time period of applicability. Multiple
<meta> children may appear within a single rule or fact, allowing for more flexibility in the metadata and
its annotation.
For standardized meta-data annotations, XML structured data could be used to more compactly and
consistently represent such facts.
“Internal with Structured Data”
<Implies node="#rule1">
<meta>
<Atom node="#ruleInfo1">
<Rel iri="&ruleml;Implies"/>
<Data xsi:type="legalruleml:rulemetadata">
<legalruleml:source iri="#sourceBlock"/>
<dfs:strenght iri="/ontology/defeasible.owl#defeasible"/>
<legalruleml:jurisdiction iri="/ontology/europe.owl#europe"/>
<dc:Creator">Monica Palmirani</dc:Creator>
<dcterms:Creator" iri = "#aut2"/>
<dc:Creator">Tara Athan</dc:Creator>
<dcterms:Creator" iri = "#aut3"/>
<dcterms:created>2012-03-30</dcterms:created>
<legalruleml:authority
iri="/ontology/ministyOfJustice.owl#justice"/>
</Data>
</Atom>
</meta>
<if>
<Atom node="#body1">…</Atom>
</if>
<then>
<Atom node="#head1">…</Atom>
</then>
</Implies>
The above representation uses standard RuleML syntax, encapsulating the LegalRuleML structured
metadata in a <Data> element. The most compact element-based representation can be achieved with a
LegalRuleML extension to the RuleML syntax.
“Compact”
<Implies node="#rule1">
<legalruleml:metadata>
<Data node="#ruleInfo1" xsi:type="legalruleml:rulemetadata">
<legalruleml:source iri="#sourceBlock"/>
<dfs:strenght iri="/ontology/defeasible.owl#defeasible"/>
<legalruleml:jurisdiction iri="/ontology/europe.owl#europe"/>
<dc:Creator">Monica Palmirani</dc:Creator>
<dcterms:Creator" iri = "#aut2"/>
<dc:Creator">Tara Athan</dc:Creator>
<dcterms:Creator" iri = "#aut3"/>
<dcterms:created>2012-03-30</dcterms:created>
<legalruleml:authority
iri="/ontology/ministyOfJustice.owl#justice"/>
</Data>
</legalruleml:metadata>
<if>
<Atom node="#body1">…</Atom>
</if>
<then>
<Atom node="#head1">…</Atom>
</then>
</Implies>
A characteristic of the LegalRuleML compact form of meta-knowledge representation is that the addition
of new kinds of meta-knowledge requires (minor) modification of the LegalRuleML schema, while the
non-compact version in RuleML syntax is extensible without schema modification. Depending on the
situation, this may be considered an advantage or a disadvantage.
An attribute-centric “embedded” LegalRuleML syntax is an alternate form to the element-centric
“compact” representation above. Properties that can take on multiple values must be represented by
delimited lists:
“Embedded”
<Implies node="#rule1" legalruleml:metanode="#ruleInfo1"
legalruleml:source="#sourceBlock"
dfs:strenght="/ontology/defeasible.owl#defeasible"
legalruleml:jurisdiction ="/ontology/europe.owl#europe"
dc:Creator="Monica Palmirani;Tara Athan"
dcterms:Creator = "#aut2 #aut3"
dcterms:created = "2012-03-30"
legalruleml:authority="/ontology/ministyOfJustice.owl#justice">
<if>
<Atom node="#body1">…</Atom>
</if>
<then>
<Atom node="#head1">…</Atom>
</then>
</Implies>
An additional limitation of the embedded syntax is that only one metadata set can be embedded in the rule.
Modifications of the metadata must be represented using one of the other representations.
External in Metadata block
Another method for representing the metadata of the rules is introduced
for to separate the assertions on the legal rules (legal
interpretation)in a separate block <meta>. This method permits:
a) to make assertions on the rules in a unique place in the XML file
in order to be able a possible separation or deletion or
modification. It is also useful for applying the digital signature
to different block of XML. In legal domain is quite important to
b)
c)
d)
e)
sign a block of XML (e.g. legal expert) and to maintain the
metadata under the responsibility of another person (e.g. engineer
or legal system);
to minimize redundancy: e.g. “Monica Palmirani” is a person and it
is declared only one time in the <meta> block and this entity is
used in the rules using an URI;
to permit multiple annotations about the same rule without to
markup again the body (if) and the head (then). It permits the
change management over the time of the rules and also of the
metadata;
to permit the inheritance of the metadata to all the rules by
default and to specify in place the exceptions: e.g. jurisdiction
is defined in the metadata block (e.g. Europe) for all the rules,
and in case of exceptions we can use the embedded syntax (e.g.
Europe and Turkey);
to permit the N:M relationships among a rule and its metadata. A
classical example is the <source>. A rule could be the summary of
different sources (art. 1, art. 4, art. 5) and a source (art. 14)
could embed different rules.
Multiple sources for the same rule1
Rule1:body (source:art.1 , art. 4) -->head (source:art. 5)
Multiple rules for the same source (art. 14).
Rule2:body (source: art.14) -->head(source: art.4)
Rule3: body (source: art. 14) --> head (source: art. 5)
<meta>
<ruleInfo id=”ruleInfo1”>
<source value=”#sourceBlock”/>
<ruleType value="defeasible"
refersTo="/ontology/defeasible.owl"/>
<jurisdiction value=”europe”
refersTo="/ontology/europe.owl"/>
<author value=”palmirani” refersTo="#aut2"/>
<times value=”#t1”/>
<authority value=”justice”
referstTo=”/ontology/ministyOfJustice.owl”/>
</ruleInfo>
</meta>
<Implies node="#rule1" metadata=”#ruleInfo1”>
<if>
<Atom node="#body1">…</Atom>
</if>
<then>
<Atom node="#head1">…</Atom>
</then>
</Implies>
Note: the metadata block now is simplified for discussing the main
approach. It needs a more specifications in classes as defined in the
paper: Monica Palmirani, Guido Governatori, Antonino Rotolo, Said Tabet,
Harold Boley, Adrian Paschke: LegalRuleML: XML-Based Rules and Norms.
298-312, RuleML 2011-BRF, Springer 2011, ISBN 978-3-642-24907-5
Based on this paper the intention is to model five classes of legal
metadata: identification (authors, authorities, organization, people),
sources, events and timesInfo, type of rule (defeasible, etc.),
jurisdiction.
With this approach we have a twofold advantage.
SCENARIO A: two rules with the same metadata that points out to the same
<ruleInfo1> block. We can minimize the annotation, reduce the errors,
make the maintenance easy.
<meta>
<ruleInfo id=”ruleInfo1”>
<source value=”#sourceBlock”/>
<ruleType value="defeasible"
refersTo="/ontology/defeasible.owl"/>
<jurisdiction value=”europe”
refersTo="/ontology/europe.owl"/>
<author value=”palmirani” refersTo="#aut2"/>
<times value=”#t1”/>
<authority value=”justice”
referstTo=”/ontology/ministyOfJustice.owl”/>
</ruleInfo>
</meta>
<Implies node="#rule1" metadata=”#ruleInfo1”>
<if>
<Atom node="#body1">…</Atom>
</if>
<then>
<Atom node="#head1">…</Atom>
</then>
</Implies>
<Implies node="#rule2" metadata=”#ruleInfo1”>
<if>
<Atom node="#body1">…</Atom>
</if>
<then>
<Atom node="#head1">…</Atom>
</then>
</Implies>
SCENARIO B: the same rule that changes over the time only in the
metadata. It is the case of modification of the text only in the
jurisdiction part or in the source (e.g. art. 13 bis become art. 14).
In the following example the modification affects the jurisdiction, to
the rule is applicable since t2 to the enlarged Europe (e.g. with
Serbia, Turkey, Albany, etc.)
<meta>
<ruleInfo id=”ruleInfo1”>
<source value=”#sourceBlock”/>
<ruleType value="defeasible"
refersTo="/ontology/defeasible.owl"/>
<jurisdiction value=”europe”
refersTo="/ontology/europe.owl"/>
<author value=”palmirani” refersTo="#aut2"/>
<times value=”#t1”/>
<authority value=”justice”
referstTo=”/ontology/ministyOfJustice.owl”/>
</ruleInfo>
<!—new metadata in the time t2 due to a modification of the text-->
<ruleInfo id=”ruleInfo2”>
<source value=”#sourceBlock@Version2”/>
<ruleType value="defeasible"
refersTo="/ontology/defeasible.owl"/>
<jurisdiction value=”enlargedEurope”
refersTo="/ontology/enlargedEurope.owl"/>
<author value=”palmirani” refersTo="#aut2"/>
<times value=”#t2”/>
<authority value=”justice”
referstTo=”/ontology/ministyOfJustice.owl”/>
</ruleInfo>
</meta>
<Implies node="#rule1" metadata=”#ruleInfo1”>
<if>
<Atom node="#body1">…</Atom>
</if>
<then>
<Atom node="#head1">…</Atom>
</then>
</Implies>
Superiority Relation
It has been argued [7]grosof and [8]Governatori2005 that the preference relation does not need any specific
construct in RuleML, and it can be captured by a simple Atom / Rel element:
<Atom>
<Rel>override</Rel>
<Ind iri="#r1"/>
<Ind iri="#r2"/>
</Atom>
Nevertheless the override relation is not semantically codified in the standard and different authors
could use different predicates for expressing the same concept (e.g., hierarchy, rank, etc.). However,
referencing an overrides relation as an IRI allows it to be semantically codified in the standard:
<Atom node="#overrides1">
<Rel iri = "&dfs;Override/>
<Ind iri="#r1"/>
<Ind iri="#r2"/>
</Atom>
The following slotted fact
<Atom node="#overrides1">
<oid><Ind iri="#r1"/></oid>
<Rel iri="&ruleml;Implies"/>
<slot>
<Ind iri = "&dfs;Override/>
<Ind iri="#r2"/>
</slot>
</Atom>
illustrates how rule precedence can be expressed in the same way as other (meta-)knowledge: internal,
external, compact, or embedded.
Like other facts, a rule precedence fact can be itself annotated. For example, any of these representations
permit also to specify the author and the temporal attributes pertaining to the override statement.
<Atom dcterms:Creator="#aut2" dcterms:created="2012-03-30">
<Rel iri="&dfs;Override"/>
<Ind iri="#r1"/>
<Ind iri="#r2"/>
</Atom>
Disclaimer
Currently, the XML syntax is under development, and the XML snippets above may not be representative
of the final LegalRuleML Specifications.
History
This version is the consolidation of the comments provided by Tara Athan and Harold Boley (001.001) to
version 001, as discussed in the TC meeting of April 4, 2012.
References
1.
2.
3.
4.
5.
6.
7.
8.
Giovanni Sartor. Legal Reasoning: A Cognitive Approach to the Law. Vol. 5. Treatise on Legal
Philosophy and General Jurisprudence. Berlin: Springer, 2005.
Henry Prakken and Giovanni Sartor. Argument-based extended logic programming with
defeasible priorities. Journal of Applied Non-Classical Logics 7 (1997): 25–75.
Grigoris Antoniou. Defeasible logic with dynamic priorities. International Journal of Intelligent
Systems 19 (2004): 463–472.
Thomas Gordon and Doug Walton. Proof burdens and standards. In I. Rahwan and G. Simari,
editors, Argumentation in Artificial Intelligence, pages 239–260. Springer, 2009.
Guido Governatori. On the relationship between Carneades and defeasible logic. In T. van Engers,
editor, Proceedings of the 13th International Conference on Artificial Intelligence and Law
(ICAIL 2011), pages 31–40. ACM Press, 2011.
Guido Governatori and Antonino Rotolo. Changing legal systems: legal abrogations and
annulments in defeasible logic. Logic Journal of IGPL 18 (2009): 157–194.
Benjamin N. Grosof and Terrence C. Poon:. SweetDeal: representing agent contracts with
exceptions using XML rules, ontologies, and process descriptions. In WWW 2003, pages 340–349.
ACM Press, 2003.
Guido Governatori. Representing Business Contracts in RuleML. International Journal of
Cooperative Information Systems 14 (2005): 181–216.
9.
Harold Boley, Adrian Paschke and O. Shafiq. 2010. RuleML 1.0: The Overarching Specification
of Web Rules. In: M. Dean, J. Hall, A. Rotolo and S. Tabet, eds. Semantic Web Rules. Springer
Berlin / Heidelberg, pp.162-178.
10. Harold Boley, Tara Athan, Adrian Paschke, Said Tabet, Benjamin Grosof, Nick Bassiliades,
Guido Governatori, Frank Olken, David Hirtle. Schema Specification of RuleML Version 1.0,
2012-04-01, http://ruleml.org/1.0 .