Re: [RIF] [UCR]: What is the RIF (revisited)

  On Feb 7, 2006, at 8:49 PM, Ginsberg, Allen wrote:

> Peter,
>
> Let's grant that the RIF is a rule language and that it is executABLE.

I don't understand this move. Peter said nothing about "executabilty"  
(which suggests to me having "as well a fully-worked-out procedural  
meaning" which Peter said was the contrary part of a contrary view :)).

The only other things he mentioned were having a formal syntax and  
semantics. I believe Peter things these are sufficient for well  
specifying the RIF.

> There are still two questions that need to be considered:
>
> 1) Does a RIF-representation ever need to be executED in order for the
> RIF to do any of its jobs, and

I think one has to analyze RIF-representations...which can involve  
various degrees of reasoning about or with them

> 2) If so, does the execution required for the RIF to do its job amount
> to the same thing as a rule language executing?

Does a rule language executing amount to determining (some) entailments  
of a rule set?

> Only if both of these questions are answered in the affirmitive would
> making the RIF an executable rule-language be an explicit design goal.

Perhaps I misunderstood the dialectic. Is this supposed to structure  
the decision to go for the additional feature of a "fully-worked-out  
procedural meaning"? Hmm. ok.

In that case I don't think no-answers to either question is sufficient  
to rule out that possibility. You might need to know details of the  
procedural semantics of a language to effect interchange (because, say,  
your application is sensitive, alas and alack, to some aspect of the  
specific execution behavior), but not need to "execute" the rules in  
order to exploit those details.

> For example, a UML representation of an application or system has a
> formal syntax and semantics, and might very well be exectuable, but it
> doesn't need to be executed in order for it to do its job, which is
> fundamentally to convey information about the application.

Maybe. But why is that? Is it because UML is primarily human  
documentation? Or is it that UML is primarily about specifying  
interfaces (as opposed to implementation)? In either case, there could  
be considerable utility in being able to reason, query, consistency  
check, transform, etc. UML...in which case, it would need a decent  
semantics. But once it had that, how would you prevent "direct"  
"execution"? I mean, you could cripple the language by leaving key bits  
unspecified (or abstracted in some sense), I guess.

> Right now I see the RIF as having two main "jobs": interchange and
> interoperability.  Interchange  involves 1) translating from some rule
> language into the RIF, and 2)taking the resulting RIF-representation
> and translating that into another rule language.  I don't see how
> executing a set of RIF-rules would necessarily be involved in that
> process.  Basically this is a compilation problem.

What is the difference between, let use say:

	WSML --compiledTo-->RIF--compiledTo-->Prolog

and

	RIF --compiledTo-->Prolog

Or
	RIF--compiledTo--->JavaBasedProlog--compiledTo-->JVM bytecode

and
	RIF--compiledTo-->JVM bytecode

or even
	RIF--compiledTo-->myNiftyRIFbytecode
?

(Now there *could* be some nasty differences, e.g., RIF could be like  
the intermediate form of many compilers which throw away tons of  
information and, really, can't be used for direct programming. RIF  
would then be some highly normalized form. But then it would suck for  
editors and (readable) rule conversion.)

> On the other hand, I can see that having an interpretable RIF rule
> language might enhance interoperability.  A set of rules might be
> written in one language and then translated into the RIF.  That
> RIF-representation could be used by a RIF-interpreter running on a
> server to answer queries coming in from various client processes
> running different rule-systems.  The client queries would have to be
> translated into a RIF-format and the answers would have to be
> translated back into the various rule languages of the client systems.
> If that scenario  makes sense in practice (as a use-case) then I would
> say that making the RIF an executable rule-language should be a design
> goal.

Interpretation and compilation are not so very different.  
(<http://www.freetechbooks.com/about57.html>)

And neither seems all that helpful a notion in the context of a KR  
language (IMHO) or interchange format. Even with programming languages  
(nowadays) the key is to specify the semantics.

> It seems to make sense on the face of it, but then again, so have other
> ideas...

About the only sense I can make of a "non-executabilty" requirement is  
that the RIF is so expressive that it isn't even semi-decidable and  
lacks a complete proof theory. But, er, why do that? :)

It is true that for semi-decision procedures systems might diverge in  
the answers they can give (though we expect they won't give  
*contradictory* answers), so there is merit in being more precise about  
the behavior of interoperating systems. (See the semantics  
specification of the Mercury language for one such attempt:
	<http://www.cs.mu.oz.au/research/mercury/information/doc-release/ 
mercury_ref/Semantics.html#Semantics>)

Cheers,
Bijan.

Received on Wednesday, 8 February 2006 02:45:12 UTC