- From: Adrian Paschke <adrian.paschke@biotec.tu-dresden.de>
- Date: Fri, 15 Feb 2008 18:39:48 +0100
- To: <public-rif-wg@w3.org>
- Message-Id: <20080215173944.3B5B970000F6@mailserver.biotec.tu-dresden.de>
Hi All, Here the first part of the PRD review - Part 1 Syntax of PRD Condition Language. Reviews for the other parts will follow. The comments are organized by section numbers. Best, Adrian 1. Does RIF-PRD extend RIF-BLD condition language or partially adopt and specialize it to the needs of production rules representation? 1.2.2. dialects extending RIF-BLD --> dialects extending RIF-PRD 1.3.1. BNF syntax for PRD and BLD should be consistent (as well as for any other "future" dialects) 2. In 1.2. we state that we "extend" RIF BLD condition language; in chapter 2 we state RIF Core; if RIF Core would be a subset common to both RIF BLD and RIF PRD we would strictly extend it. 2.1. There are several new constructs introduced, such as ExTerm, Aggregation (see discussion later) 2.1.1.1. we need to refer explicitly (e.g. by a link) to all things which we adopt from BLD and which are defined there, e.g. we don't define LITERAL since it is adopted from and defined in BLD. 2.1.1.1. we exclude Uniterm and introduce ExTerm; why do we need a new construct here? we can reuse Uniterm also to define procedural attachments 2.1.1.2. as for constants we should introduce a type attribute for variables, so that only objects (individuals/constants) of the appropriate type can be bound to the variable. An extra Subclass construct is inappropriate for this since (1) it unnecessarily blows up the XML code if you want it for type checks and more importantly (2) since it is not implicitly associated with a variable it is dependent on the order where you place the Subclass construct in a rule (i.e. the outcome differs accordingly and it is impossible to ensure correctness). 2.1.1.2. In the informal semantics we only allow variable bindings to values and individuals (btw we are not consistent in the use of the term individual vs. value vs. constant), but variable bandings in the sense of an explicitly defined variable renaming are need in certain applications (e.g. for large classes of rule-based machine learning approaches). 2.1.1.3. Most modern logic derivation rule engines support some kind of procedural attachments to call external functionalities, so we should discuss if a construct such as ExTerm (note: I'm not discussion the name of such a construct here - we could e.g. reuse Uniterm) would also make sense or even would be necessary for the "logic RIF" (but that would probably not be "Core" - so what would be the relations?) 2.1.1.3. we state that ExTerms on the level of TERM are interpreted as evaluated functions (as opposed to evaluated relations under ATOMIC); in general I agree with this statement, but depending on the data model and type system of the externally called system this might be ambiguous (note e.g. the distinction of matching two Java instances (objects) of the Java class Boolean returned by a Java function as compared to truth-valued relations). We should add some further clarification here. 2.1.1.3. in the presentation syntax we introduce "APPLY" 2.1.1.3. we need to handle exceptions of function calls in PRD and explicitly describe that 2.1.1.4. in the informal semantics we mention procedural attachments; maybe we should add a short explanation what this is, e.g. a footnote. 2.1.2.1. The distinction in PRD between ExTerm and Uniterm seems to me unnecessary, since Uniterm as the name indicates was introduced to cover both relations and functions on the level of "ATOMIC" and "TERM" 2.1.2.2. see 2.1.2.1 2.1.2.1. we say that we exclude named arguments. There is a huge class of production rule systems, e.g. all CLIPS derivates, which support something like named arguments. Since for an implementer of RIF PRD named arguments would mean nearly no implementation overhead I think we should adopt them from BLD. It is very easy to implement a default strategy for named arguments where you introduce incremented "arg 1, 2, 3, ., x slot" in your translator, when your rule engine does not support named arguments and does not use the slots. This is very easy to implement, even in XSLT - so really no overhead for implementers of PRD. But on the other hand to implement an extension for named arguments for a PRD version without named arguments is not easy; you would need to understand the complete PRD schema, make extensions wherever necessary, validate all and publicly deploy the extended schema somewhere - so a huge implementation overhead for those how would like to use PRD and need named arguments. Note: My Prova engine does not support named arguments, so I don't need them, but since the implementation of an translator supporting a default strategy for named arguments, as explained above, is so easy to implement, I don't see why we should put the burden on the others (they are already punished by the inefficiency of their systems ;-) - just kidding) 2.1.2.3 in the last RIF telecon we decided for BLD to use Equal also for assignment of objects (e.g. returned by function calls) to variables. This much more declarative then having an extra Assign construct for assignment and one for Equality testing. For instance, if a variable used as first argument in Equal is bound it would be an equality testing comparing both objects, if the variable in the first argument is free it would be an assignment of the second argument to the variable (including also variable renaming assignments). 2.1.2.4. There is a need for an explicit Member and Subclass construct so we should keep them - but as I have written in the discussion of variables these constructs are not adequate for type checking 2.1.2.6. The definition of Frames should be common for both, BLD and PRD 2.1.3. I agree negation as failure is needed to have a sufficiently expressive rule language to describe real-life problem (btw: I also see the need to the logic BLD). But when it comes to Naf things get much more complicated and we need to give semantics for that (will discuss this later in the semantics part) 2.1.3.2. We say that a CONDITION can be a conjunction of zero or more statements. What would be the meaning of an empty condition? What benefit do we get to allow empty Conditions if there is not extra information it would carry, e.g. in an attribute field? 2.3.3.3. similar to And 2.1.3.4. If we introduce Naf, which I think we should do, we need to give a good semantics to it (discussion later) 2.1.4. If we exclude Forall in the condition language of PRD we only address the very standard production rule systems, but there are also hybrid systems on the market including systems mixing forward-directed production rules and backward-reasoning (and many other using e.g. magic sets, compilation approaches, .) and when it comes to event-based systems we can not easily build on PRD (but that's a foresight). 2.1.4.1. Aggregation is newly introduced in PRD (as compared to BLD); Aggregations are important, but not only for PRD; at least as a kind of "findall" (as in Prolog derivates) is urgently needed to really work with logical lists and also quite often in meta programming. So we should start a discussion about that. And I don't see why we need a new extra construct for aggregations - why not using built-ins within Uniterm (keeping the syntax minimal)
Received on Friday, 15 February 2008 17:40:08 UTC