[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalruleml] [Defeasibility] Complaint example
Hi Tara, Hi All,
I slightly modified your first example (ex2.1.1-complaint_v2.lrml) in order to show the use of Reaction RuleML's explicit definitions of <evaluation> semantics and <qualification> definitions for rulebases and single rules. This allows defining explicitly the semantic profiles which should be used for interpretation of the rulebase and rules.
For instancen, defeasible reasoning with backward reasoning semantics and superiority definitions as qualifying implementation for the conflict resolution strategy in the rulebase:
<Rulebase>
<evaluation>
<Profile type="ruleml;Defeasible" direction="backward" style=”reasoning”></Profile>
</evaluation>
<qualification>
<And>
<Overrides>
<Rule keyref="rule_2"/>
<Rule keyref="rule_1b"/>
</Overrides>
<Overrides>
<Rule keyref="rule_1b"/>
<Rule keyref="rule_1c"/>
</Overrides>
<And>
</qualification>
...
<And>
<Rule key="rule_2"> ... </Rule>
<Rule key="rule_1b"> ... </Rule>
</And>
</Rulebase>
This gives much more flexibility in terms of defining different semantic profiles for the interpretation and qualifications (e.g. other rule types need other conflict resolution strategies such as recency or refraction in production rules).
Also it allows combinations of semantic profiles e.g. combining an evaluation profile for defeasible reasoning with an entailment profile for ontological reasoning in typed logic programs.
<!-- the rule based with defeasible logic as evaluation semantics and OWL-direct entailment regime for its typed logic -->
<Rulebase>
<evaluation>
<And>
<Profile type="ruleml;Defeasible" direction="backward" style=”reasoning”></Profile>
<Profile type="owl;OWL-Direct"</Profile>
</And>
</evaluation>
...
</Rulebase>
and it allows defining alternative semantics to be used, possibly ordered by preference using an @index attribute:
<!-- this rules should be interpreted by well founded semantics or alternatively (with lower preference) by answer set semantics. -->
<Rule key="r1">
<evaluation index="1">
<!-- WFS semantic profile define in the metamodel -->
<Profile type="ruleml:Well-Founded-Semantics" direction="backward"/>
</evaluation>
<evaluation index="2">
<!-- alternative ASS semantic profile define in the metamodel -->
<Profile type="ruleml:Answer-Set-Semantics" direction="backward"/>
</evaluation>
</Rule>
Best,
Adrian
-----Original Message-----
From: legalruleml@lists.oasis-open.org [mailto:legalruleml@lists.oasis-open.org] On Behalf Of Tara Athan
Sent: Mittwoch, 27. Juni 2012 04:01
To: legalruleml@lists.oasis-open.org
Subject: [legalruleml] [Defeasibility] Complaint example
I have created some possible renderings of the defeasibility example submitted by Guido:
"Complaint means an expression of dissatisfaction made to a Supplier in relation to its Telecommunications Products or the complaints handling process itself, where a response or Resolution is explicitly or implicitly expected by the Consumer.
An initial call to a provider to request a service or information or to request support is not necessarily a Complaint.
An initial call to report a fault or service difficulty is not a Complaint.
However, if a Customer advises that they want this initial call treated as a Complaint, the Supplier will also treat this initial call as a Complaint.
If a Supplier is uncertain, a Supplier must ask a Customer if they wish to make a Complaint and must rely on the Customer’s response."
In the first case, ex2.1.1-complaint.lrml, attached, I aimed to have the minimum level of decomposition possible.
I used the Reaction RuleML element <Rule>, which in the latest revision has a @key or @keyref attribute to allow referencing for the Overrides statement.
The @key attribute is specified using <xsd:key> (or equivalent Schematron rules in the case of Relax NG schemas) to be unique over the node set of <Rule> elements. Also, to be valid, the @keyref attribute on a <Rule> element must reference a key defined by @key on a <Rule> element within the current document.
It was sufficient to quantify over a single variable for each rule, representing in each case the thing that we wish to classify as a Complaint or not.
However, there was a lot of duplication. Therefore I considered in ex2.1.1c-complaint.lrml, also attached, extending the key/keyref functionality to <Rel>s. In the manner that <xsd:key> is implemented, there can be independent sets of values, one set for <Rule>, one set for <Rel>, with existence and uniqueness checked independently among them.
This appears to work out alright at this level of decomposition, provided we do not examine the last sentence of the example. Once we look at that sentence, I think we will discover the need for a finer-level of decomposition of the others. But I think the minimal approach is OK for a pedagogical example.
Tara
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE RuleML [
<!ENTITY ruleml "http://ruleml.org/";>
<!ENTITY dfs "http://example.org/vocabulary/defeasible#";>
]>
<RuleML xmlns="&ruleml;spec"
xmlns:legalruleml="http://legalruleml.example.org";>
<legalruleml:metadata>
<!-- The metadata blocks go here ... -->
</legalruleml:metadata>
<Assert mapClosure="universal" mapMaterial="no">
<!-- Sentence 1 -->
<!--Original:
Complaint means an expression of dissatisfaction made to a Supplier in relation
to its Telecommunications Products or the complaints handling process itself,
where a response or Resolution is explicitly or implicitly expected by the Consumer.
-->
<!-- Paraphrase:
Rule 1a.
If X is a Complaint, then X is an expression of dissatisfaction made to a
Supplier in relation to its Telecommunications Products or the complaints
handling process itself, where a response or Resolution is explicitly or
implicitly expected by the Consumer.
Rule 1b.
If X is an expression of dissatisfaction made to a Supplier in relation to
its Telecommunications Products or the complaints handling process itself,
where a response or Resolution is explicitly or implicitly expected by the Consumer,
then X is a Complaint.
-->
<!-- Issues:
To be stated as defeasible rules, we must have the representation
as two defeasible rules, because one rule may be defeated while the other holds.
Isomorphism is not lost because there is still a fixed set of two rules that are affected
by changes in the text of the first sentence.
-->
<Rulebase>
<!-- defines the evaluation semantics to be used for this rulebase -->
<evaluation>
<!-- Defeasible semantic profile define in the metamodel -->
<Profile type="ruleml;Defeasible" direction="backward" style=?reasoning?></Profile>
</evaluation>
<!-- defines the qualifying properties such the conflict resolution strategy, here by using overrides superiority relation -->
<qualification>
<Overrides>
<!-- Issues: The individuals referenced here are non-ground rules with
different free variables. The rules are implicitly determined to be
in conflict if the logical closure of their heads is inconsistent.-->
<Rule keyref="rule_2"/>
<Rule keyref="rule_1b"/>
</Overrides>
</qualification>
<Rule legalruleml:strength="&dfs;defeasible"
key="rule_1a">
<if>
<Atom>
<Var>X</Var>
<Rel>is a Complaint</Rel>
</Atom>
</if>
<then>
<Atom>
<Var>X</Var>
<Rel>is an expression of dissatisfaction made to a Supplier in relation to its Telecommunications Products or the complaints handling process itself, where a response or Resolution is explicitly or implicitly expected by the Consumer</Rel>
</Atom>
</then>
</Rule>
<Rule legalruleml:strength="&dfs;defeasible"
key="rule_1b">
<if>
<Atom>
<Var>X</Var>
<Rel>is an expression of dissatisfaction made to a Supplier in relation to its Telecommunications Products or the complaints handling process itself, where a response or Resolution is explicitly or implicitly expected by the Consumer</Rel>
</Atom>
</if>
<then>
<Atom>
<Var>X</Var>
<Rel>is a Complaint</Rel>
</Atom>
</then>
</Rule>
</Rulebase>
<!-- Sentence 2 -->
<!--Original:
An initial call to a provider to request a service or information or to request support
is not necessarily a Complaint.
-->
<!-- Paraphrase:
If Y is an initial call to a provider to request a service or information or to
request support,
then it is not necessarily the case that Y is a complaint.
-->
<!-- Issues:
While <Neg> would normally be stated in controlled English as "is not the case that",
which is stronger than the original phrase " is not necessarily",
the sense of the original is captured by weakening the rule to a defeater.
-->
<Rulebase>
<Rule legalruleml:strength="&dfs;defeater" key="rule_2">
<if>
<Atom>
<Var>Y</Var>
<Rel>is an initial call to a provider to request a service or information or to request support</Rel>
</Atom>
</if>
<then>
<Neg>
<Atom>
<Var>Y</Var>
<Rel>is a Complaint</Rel>
</Atom>
</Neg>
</then>
</Rule>
</Rulebase>
<!-- Sentence 3 -->
<!--Original:
An initial call to report a fault or service difficulty is not a Complaint.
-->
<!-- Paraphrase:
If W is an initial call to report a fault or service difficulty,
then it is not the case that W is a complaint.
-->
<Rulebase>
<qualification>
<Overrides>
<!-- Issues: The individuals referenced here are non-ground rules with
different free variables. The rules are implicitly determined to be
in conflict if the logical closure of their consequents (then part) is inconsistent.-->
<Rule keyref="rule_3"/>
<Rule keyref="rule_1b"/>
</Overrides>
</qualification>
<Rule legalruleml:strength="&dfs;defeasible" key="rule_3">
<if>
<Atom>
<Var>W</Var>
<Rel>is an initial call to report a fault or service difficulty</Rel>
</Atom>
</if>
<then>
<Neg>
<Atom>
<Var>W</Var>
<Rel>is a Complaint</Rel>
</Atom>
</Neg>
</then>
</Rule>
</Rulebase>
<!-- Sentence 4 -->
<!--Original:
However, if a Customer advises that they want this initial call treated as a
Complaint, the Supplier will also treat this initial call as a Complaint.
-->
<!-- Paraphrase:
If Z is an initial call to a provider to request a service or information or to
request support and
Z is an initial call that the Customer advises they want treated as a Complaint,
then Z is a Complaint.
-->
<!-- Issues:
The original phrasing "the Supplier will also treat this initial call as a" has a deontic flavor
which is not fully captured by the conversion to "Z is a".
However, the legal effect of the paraphrase is completely equivalent to the original.
-->
<Rulebase>
<qualification>
<Overrides>
<Rule keyref="rule_4"/>
<Rule keyref="rule_3"/>
</Overrides>
</qualification>
<Rule legalruleml:strength="&dfs;defeasible" key="rule_4">
<if>
<And>
<Atom>
<Var>Z</Var>
<Rel>is an initial call to report a fault or service difficulty</Rel>
</Atom>
<Atom>
<Var>Z</Var>
<Rel>is an initial call that the Customer advises they want treated as a Complaint</Rel>
</Atom>
</And>
</if>
<then>
<Atom>
<Var>Z</Var>
<Rel>is a Complaint</Rel>
</Atom>
</then>
</Rule>
</Rulebase>
<!-- Sentence 5 -->
<!-- Original:
If a Supplier is uncertain, a Supplier must ask a Customer if they wish to make
a Complaint and must rely on the Customerâ??s response.
-->
<!-- This statement is not definitional, but is deontic.
It also requires a more detailed domain of discourse,
including at least the Supplier.
-->
</Assert>
</RuleML>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]