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."