Re: [UCR] RIF needs different reasoning methods

François,

you wrote:

> Bijan Parsia wrote:
> 
>>When you say, "have the same declarative semantics", I read, "has the
>>same semantics", and thus, "justifies the same answers to queries".

This is also the interpretation I made.  I understand that you are making a 
distinction between "declarative semantics" -- what the rule means in terms of 
allowable models -- and "pragmatic semantics" -- what kind of processing the 
rule requires of my engine.  Like Ian, I think we can distinguish 
"expressiveness" in the "declarative semantics" -- what you are permitted to 
say/ask, which may define what kind of processing *ability* the rule requires 
of my engine -- but I don't think any other distinction will be visible to 
anyone except the guy who wrote the code for the engine in question.  For RIF 
purposes, your engine either can or cannot process this ruleset -- we don't 
care how it does it.

> This is not quite so, I think, because the queries have to be specified.
> Assume some rules specify how much taxes one should pay. One query can
> be: "how much taxes should Annsa pay?". Another query could be: "does
> Anna pay as much taxes as she should?". This difference in usage
> (pragmatics) leads to different rule processing methods.

What I see here is a richer and more confusing version of your 
deductive/normative difference:  the distinction is between "compute the 
value" and "prove that this given value results".  The former query asks for 
the RDF triples:  (should-pay-tax, Anna, ?amount).  According to the semantics 
you gave for the deductive rules, if the ruleset can prove some set of triples 
of this form, the result will be (the materialization of) zero or more of 
those triples.  One view of the second query is that it asks whether 
(should-pay-tax, Anna, 5000euros) is in that set.  An alternative view is that 
it asks the reasoner to prove or disprove (should-pay-tax, Anna, 5000euros) 
directly.  So, from outside, I can't tell what approach your engine takes.

Now I can get zero or 1 triples as answers to the first, and I can get True or 
Unknown as answers to the second, and which answers I get depends on the 
capabilities of your engine, but it doesn't depend on what the ruleset means 
or what the query means.  And it may be that which answers I get out of your 
engine, and how soon, depends on the settings of critical control parameters 
-- that is the "pragmatics" element.  But to deal with that, I have to know I 
am instructing your engine, rather than an arbitrary recipient of the ruleset. 
  (That was one of Bijan's points.)

If we can all agree a priori that a particular ruleset requires a particular 
reasoning capability in order to produce any useful result, we would hope that 
that capability requirement can be characterized by some expressiveness 
element of the rules language.  But it may not be the case.  And then we are 
stuck with ?'s Corollary to the Goedel Principle:
"You can't get everything you want without allowing things you don't want."

-Ed

P.S. I am not averse to the idea that a ruleset could have a standard XML tag 
for "reasoner-specific annotations", where the content of that element is not 
standardized.  This would allow an exporting engine to capture any parametric 
guidance with the ruleset, so that when the recipient is another copy of the 
same engine, it can profit from it, while any other engine can safely ignore 
it.  (But the XML schema for that can get really messy.)

-- 
Edward J. Barkmeyer                        Email: edbark@nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4482

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."

Received on Wednesday, 8 March 2006 19:30:50 UTC