Re: An unfortunate side-effect

This is a reasonable thing to do when all else fails. But the goal of many
participants here is to provide greater interoperability for well-known
sublanguages that are already in wide use and for which implementation
techniques are well-known. The roadmap that we presented goes a long way
towards that goal. I admit that the production rule part was fairly weak
there, but I am happy to leave that part to those who care about PRs more.


	--michael  


> 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 21:18:04 UTC