[RuleML-all] Questions regarding RuleML status

Thu Apr 6 10:54:54 ADT 2006

Hi Bart, Harold and All,

The Rule Based Service Level Agreement (RBSLA) comprises several extensions
to RuleML such as reactive ECA rules, Event Calculus, Deontic Norms,
Procedural attachments, Defeasible rules, Modules/Imports of other
knowledge/files which we need to represent SLAs. The RBSLA language is
translated via XSLT into the ContractLog representation, which is an
expressive and efficient KR.

The reason why we use Cterms to represent deontic norms is, that they might
be nested - relating to reification -, e.g. used as fluent terms (changeable
properties) within Event Calculus (EC) rules, i.e. the norms are
initiated/terminated by events/actions within EC rules. The Cterm
representation you mentioned is used to stay fully compliant with the
current RuleML version, but RBSLA also supports a shorter notation, where
the norms are encoded with shorter tags such as <Oblige>, <Permit>,
<Forbid>.

Example:
<Initiates>
  <event>
     ...
  <event>
  <fluent>
      <Oblige>
        <Ind>Subject</Ind>
        <Ind>Object</Ind>
        <action>
           <Cterm>
              <Ctor>obliged action</Ctor>
              ...
           </Cterm>
         </action>
       <Oblige>
  </fluent>
  <time>
     ...
   </time>
</Initiates

The rule states that an event described between the role tags <event>
initiates a fluent <fluent> which here is an obligation for a subject to
perform an action <action> on a object. As in RuleML role tags such as
<event>, <action> can be skipped. Cterms are also used to represent complex
actions/events and procedural attachments (extended content model
Cterm((Ctor | Attachment), ...)), i.e. an action might be a call to an
external "procedural" function/method. This syntax is much more compact and
readable than the "reified" long Cterm syntax, but the XSLT stylesheet can
translate both.

RBSLA (and ContractLog) also supports defeasible rules by a @variety
attribute: <Implies variety="strict"> or <Implies variety="defeasible">
(default is "strict").

I have attached a picture of the complete RBSLA structure, describing the
layers and the modules. 

Cheers,

Adrian

-----Ursprüngliche Nachricht-----
Von: ruleml-all-bounces at ruleml.org [mailto:ruleml-all-bounces at ruleml.org] Im
Auftrag von Boley, Harold
Gesendet: Mittwoch, 5. April 2006 16:37
An: Bart Orriens
Cc: ruleml-all at ruleml.org
Betreff: [RuleML-all] RE: [Jdrew-all] Questions regarding RuleML status

Hi Bart and All,

Thanks for your persistence!
Also, please accept my apologies here if/when I'm slow at times.

RuleML doesn't have an official notation for defeasible rules yet.
See also Benjamin Grosof's work on non-monotonic rules.

> I was thinking more along more generic lines where e.g. an <oblige>
tag encloses an <atom> statement > to indicate that whatever is
contained in the atom is an obligation.

Short answer: I like such enclosed <Atom> elements, but, well,
'oblige' and the many other (natural-language inspired) modal
operators should not be tags but 'between the tags' using
"generic" markup (http://www.ai.sri.com/~pkarp/xol/xol.html),
as always in RuleML.

Long answer:

It would be good, esp. for newbies, if we could always use an
XML pretty-print layout (I normally use 2-space indentations).

Modal operators could carry an attribute such as modal="yes"
so that <oblige> would become <Rel modal="yes">oblige</Rel>
(modal="no" would be the default).

Using a Cterm encoding ('reification') on the top-level, as in

<Cterm>
  <Ctor>oblige</Ctor>
  <Ind>John</Ind>
  <Ind>Mary</Ind>
  <Ind>dosomething</Ind>
</Cterm>

is not really necessary, but we could try to encode the
"embedded proposition" <Ind>dosomething</Ind> as a Cterm
(from now on I'm also "stripe-skipping" any <op>):

<Atom>
  <Rel>oblige</Rel>
  <Ind>John</Ind>
  <Ind>Mary</Ind>
  <Cterm>
    <Ctor>do</Ctor>
    <Ind>something</Ind>
  </Cterm>
</Atom>

But here <Rel>oblige</Rel> still isn't really a modal operator,
since the 'proposition-encoding' Cterm cannot be distinguished
from a normal 'data' Cterm.

Hence, what I suggested with the analogous 'believes' modal example
(http://mail.ruleml.org/pipermail/ruleml-all/2006-April/000072.html),
except that I neglected the modal="yes" attribute on the outer Rel,
was to then replace this inner Cterm by another Atom that uses
an un*in*terpreted relation symbol, with <Rel in="no">, thus:

<Atom>
  <Rel modal="yes">oblige</Rel>
  <Ind>John</Ind>
  <Ind>Mary</Ind>
  <Atom>
    <Rel in="no">do</Rel>
    <Ind>something</Ind>
  </Atom>
</Atom>

This better reflects the nature of an 'opaque proposition',
and makes the transition from

<Atom>
  <Rel modal="yes">knows</Rel>
  <Ind>Mary</Ind>
  <Atom>
    <Rel in="no">made of</Rel>
    <Ind>moon</Ind>
    <Ind>rock</Ind>
  </Atom>
</Atom>

to

<Atom>
  <Rel in="yes">made of</Rel>
  <Ind>moon</Ind>
  <Ind>rock</Ind>
</Atom>

or (assuming in="yes" as the default for Rel's)

<Atom>
  <Rel>made of</Rel>
  <Ind>moon</Ind>
  <Ind>rock</Ind>
</Atom>

easier.

Best,
Harold

-----Original Message-----
From: Bart Orriens [mailto:B.Orriens at uvt.nl] 
Sent: April 5, 2006 6:04 AM
To: Boley, Harold
Cc: ruleml-all at ruleml.org
Subject: Re: RE: [Jdrew-all] Questions regarding RuleML status

Hello Harold, SianLun and everybody,

first many thanks for your quick answers which greatly helped clarify
things. As is often the case though answers lead to new questions, most
importantly concerning modality. I found some papers proposing to extend
ruleml to accommodate this in the RBSLA language by Paschke and
Diettrich (citation below). They propose to accommodate modalities via
cterms, like:

<Cterm>
<Ctor>oblige</Ctor>
<Ind>John</Ind>
<Ind>Mary</Ind>
<Ind>dosomething</Ind>

is this how you envision how RuleML will include modalities? I was
thinking more along more generic lines where e.g. an <oblige> tag
encloses an <atom> statement to indicate that whatever is contained in
the atom is an obligation. I am very much interested as to everybody's
thoughts on this, as I am a mere novice in this area.

Another matter which I forgot to address is that of defeasible rules. I
came across a paper entitled "
A System for Nonmonotonic Rules on the Web" by
Antoniou, Bikakis, and Wagner about this. Does RuleML have an official
notation already for logically non-monotonic rules?

As always any help is very much appreciated,
Kind regards,
Bart
=======================================
Drs. Bart Orriens          
B704, Tilburg University 	
PO Box 90153, 5000 LE Tilburg, 	 
The Netherlands
Phone : +31 13 4662779 
Fax   : +31 13 4663069                 
Email : b.orriens at uvt.nl
Web   : http://infolab.uvt.nl/~borriens   
=======================================
_______________________________________________
RuleML-all mailing list
RuleML-all at ruleml.org
http://mail.ruleml.org/mailman/listinfo/ruleml-all