Re: An unfortunate side-effect

ok, let's assume we were following this approach.

In this case, we would need to

- decide on one syntax for the rules themselves (which shouldn't
   be too difficult, but who knows),
- come up with a set of labels to use as foo and bar in
   language="foo" variant="bar"...perhaps one per member of this  
working group?
- To enable true "mix and match" interchange, we would also need
    to specify what the language/variant of the combination of 2  
rulesets
    is, one from foo1/bar1, the other from foo2/bar2...

I can see the great potential of this solution, but I am not sure  
whether this will support rule interchange: I guess it all depends on  
(a) the number of foos and bars, and (b) the availability of a  
solution to the mixn'match problem...

Cheers, Uli


On 9 Mar 2006, at 19:18, Francis McCabe wrote:

>
> I believe that it was Michael Kifer who noted:
>
>> The implication of this is that RIF will have two completely disjoint
>> things: declarative rules and production rules, and that we should  
>> probably
>> split into two subgroups.
>
> I think that this misses the true import of my original comment.
>
> 1. My *real* issue was with the split between phase I and II;  
> particular wrt the way that PRs were going to be handled.
>
> 2. If you believe that the kinds of issues with mapping are  
> restricted between the extremes of PRs and predicate logic, then I  
> am afraid you are in for a disappointment. It seems to me that  
> there is at least as much potential for difficulty between  
> different flavors of logic as between logic and PRs. E.g., all the  
> different kinds of approximate reasoning, reasoning over sets of  
> theories, DL versus LP, not to mention all the negative kinds of  
> reasoning :)
>
> 3. I believe that there is a way of making progress that does not  
> involve YARL (yet another rule language). This is in the area of  
> marking up rule sets in a standardized way without trying to  
> standardize the rule languages themselves.
>
> As a straw man (YASM) one could imagine something like:
>
> <ruleset language="prolog" variant="ISO" topic="ancestor">
>   ancestor(X,Y) :- parent(X,Y).
>   ancestor(X,Z) :- parent(X,Y), ancestor(Y,Z).
> </ruleset>
>
> This would allow meta-tools to process rulesets and decide for  
> themselves whether to handle a given ruleset without trying to  
> actually parse the ruleset first. I think that this could be quite  
> useful in many cases of ruleset integration, but would not address  
> the semantic interoperability issues.
>
> One might choose to go on to have a standard abstract syntax, with  
> an associated XML concrete syntax, that any rule language could be  
> mapped to:
>
> <ruleset language="prolog" variant="ISO" topic="ancestor"  
> representation="RIF-XML">
>   <rule>
>     <head>
>       <predication>
>         <predicate name="ancestor"/>
>          etc. etc.
> </ruleset>
>
> This would have the (perhaps marginal) benefit of allowing  
> standardized processing of the syntax of different rule languages.
>
> Note that there is not necessarily much implied semantics in this.  
> No discussion about negation etc.
>
> A third level of defining a meta-notation for semantics, so that we  
> could construct the appropriate interpretation for a ruleset might  
> look like:
>
> <ruleset language="prolog" ...>
>   <rof>
>     <elimination="resolution"/>
>     <negation="clark"/>
>   </rof>
>   <rule>
>      ...
> </ruleset>
>
> This last phase, of course, would be the hardest to do. And perhaps  
> have the least payback given any given rule engine is going to have  
> a restricted pre-determined set of rules of inference that it  
> 'knows' about.
>
> Frank
>
>
>
>

Received on Thursday, 9 March 2006 19:36:12 UTC