- From: Ed Barkmeyer <edbark@nist.gov>
- Date: Wed, 08 Feb 2006 10:27:00 -0500
- To: public-rif-wg@w3.org
Uli has it right, I think. Uli Sattler wrote: >> Peter has been right to state the following, I think: >> >> a. RIF should have a formal syntax. >> b. RIF should have a formal semantics. > > what is formal? Why not "well-defined" in the sense "If you give me a > set of rules, I can see what you meant by them, This is the requirement. Now we will surely argue about the form of a "well-defined semantics". I like model theories, but even the theorists agree that it is hard for anyone to read them. The reason for the hard mathematics, however, is that it resolves *all* the cases, and does not leave all the pathological cases to the reader's (or engine's) way of thinking. So perhaps, like OWL, we need both a true model theory, and a more conventional (and perhaps somewhat less well-defined) explication for the software builders. > eg, which are its "consequences" -- Hmm. Well, depending on how one interprets that word, this may be exactly the sticking point for rules languages. > what I do with them is, of course, up to me. For > example, I can use them with a different semantics. I would have said: I can convert the ruleset in such a way as to convey the known-to-be-intended semantics to my reasoning tools. Or I can convert them with known semantic "gains" or "losses" (which I believe will be irrelevant to the conclusions I draw and the actions I take, although I may be wrong). >> IMO, the following can be added: >> >> 1. RIF's formal semantics might, and may be should, be more abstract >> than those of existing processable rule languages. Eg making it >> possible to express "negation as failure" without choosing between >> Stable Model and Well-Founded semsntics. > > but this choice will make a difference, and thus not explicating it > might lead to confusion! E.g., if I have a set of rules which reflect > some piece of knowledge, and I want to "sell" it to you, you need to > know how to read these rules: otherwise, you might draw conclusions > that should not be drawn or you might not draw conclusions that should > be drawn... Exactly. >> 2. RIF could allow for rules the processing of which goes beyond what >> currently is widespread. Eg rules with disjunctive conclusions. > > I agree Here, milady, we part company. I could agree with the example, but not with the principle that Francois expresses. I agree with Dieter that we should not go out of our way to support expressiveness that is beyond the power of available tools to work with. We will have enough on our plate to deal with commercial rules engine expressiveness, SWRL, OWL and RDF. We should leave the next generation of Ph.D. research to the universities. If the choice is supporting disjunctive consequents and having a RIF model theory in 6 months that we can all accept, I'll take the latter. And I don't want extra syntax for expressions that a rules author would be ill-advised to use if s/he expects any automated interpretation. But I don't mind it if the syntax and extended interpretation fall out of a consistent and complete language and semantics for the target "rulespace", and we simply place "dialect" restrictions for use by certain kinds of engines. (This is the OWL view and the CL view.) >> 3. One reason for not delivering RIF with (the specification of) a >> processor is that a same rule can be used in different manners, each >> requiring different processors. Eg a rule stating that "all members >> in the RIF WG speak English" can be used for deriving that I speak >> English, ie been used as a deduction/derivation rule, or for checking >> if the requirement is enmfoprced, ie been unsed as an integrity >> constraint. In many practical cases, it makes very much sense to >> import, say deduction/derivation rules from a context/ application A, >> and to use them as integrity constrainbts in a context/application B. > > I partly agree - but still, it would be useful to be able to describe > the "intended" reading of (a set of) rules -- even though we can then > use them in an un-intended way. Uli has it right. I must be able to know exactly what you mean. How I make use of that information is not your concern. > My conclusion: > > Let us design a RIF with a well-defined syntax and semantics which > allows us to describe the intended reading (ie, its consequences) of a > rule set -- whilst being open for re-interpretation. To be more comfortable agreeing, I would edit this slightly: Let us design a RIF with a well-defined syntax and semantics which allows us to *communicate* the intended reading of a rule set -- whilst allowing for "extended" interpretation, e.g., into a larger knowledge base with a possibly different class of inference engine. > Please note that > "describing the intended reading" does not mean that we need to specify > a processor: to describe the reading of "\models" in first order logic, > we don't need to specify a theorem prover... Unfortunately, to define the semantics of some LP languages, we end up specifying the processing algorithm. But I agree that RIF should strive to rise above that, as the creators of OWL (ultimately) did. The trick, and it is not easy, is to specify WHAT is enabled by the HOW that is dear to the engine builder. -Ed -- 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 February 2006 15:27:27 UTC