Dear Bijan, > Sorry, I missed the meeting. Are you arguing that RIF documents need > to be able to *specify* the intended reasoning method for those > documents? Yes, I do. > Is this distinct from declaring their intended semantics? Yes, it is. >> The following is a (sketch of an) application scenario illustrating >> different forms of reasoning with rulesets that, in my opinion, the >> RIF should support. > > What is the nature of that support? I mean, pragmatically speaking, > what needs to be done to enable such support? To make it possible to distinguish between different fragment of RIF: 1. declatratibe RIF rules, themselvbes distinguished into 1.1 deduction rules and 1.2 normative rules 2. reactive rules > > [snip] >> A rule like the previous one is similar to a database view (also >> called deduction rule): it gives rise to (deterministically) derive >> new information from information explicitely stated. Simple and >> efficient reasoning techniques (referred to as 'constructive >> reasoning') are sufficient for this, especially no excluded middle or >> refutation are needed. > > Isn't resolution a refutation technique? Did you mean something stronger? REsolution (including SL resolution) are refuytartion methods. SLD resolution is not - in spite of a common belief. > Aren't you just saying that there is a subset of the RIF for which > there are known efficient techniques? Yes, I do. > I guess I'm still confused by the impact of these points on the spec. In my opinion, there is a requirement that obne can explicitely state what RIF fragment is used (cf. above). > >> Note that existing OWL reasoners only address 2 above. They can >> perform 1 but at unnecessary costs. > > Er...not necessarily. KAON2? Actually, regular tableaux based > reasoners can do pretty well, depending. (Granted, they do not > typically use secondary storage, but they can do quite well.) I am not saying they do not "do well". I am sayinmg, they do other things than those mentioned in the scenario. Regards, FrancoisReceived on Monday, 6 March 2006 11:38:52 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:27 GMT