- From: Gary Hallmark <gary.hallmark@Oracle.com>
- Date: Mon, 26 Feb 2007 09:36:57 -0800
- To: Paul Vincent <pvincent@tibco.com>
- CC: Michael Kifer <kifer@cs.sunysb.edu>, "Rule Interchange Format (RIF) Working Group WG" <public-rif-wg@w3.org>
it's required for JSR-94. I probably should have said, "all PR systems that support JSR-94 have a way to filter working memory after the rules have run" Paul Vincent wrote: ><< all PR systems have a way to filter working memory after >the rules have run>> > >That's an interesting supposition. Care to elaborate? > >Paul Vincent >TIBCO - ETG/Business Rules > > > >-----Original Message----- >From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] >On Behalf Of Gary Hallmark >Sent: 22 February 2007 22:14 >To: Michael Kifer >Cc: Rule Interchange Format (RIF) Working Group WG >Subject: Re: ISSUE-28: Recursion in the RIF Core > > >Yes, I think all PR systems have a way to filter working memory after >the rules have run, so you could *filter* for "ancestor(John, ?x)". >More complex queries may be more challenging, e.g. ancestor(John, ?x) & >married(?x, Sally). >Perhaps such a query could be rewritten by the PR-RIF translation >software as a rule "IF ancestor(John, ?x) & married(?x, Sally) THEN >answer(?x)". This rule would be merged with the RIF ruleset(s). >Answers can then be collected using simple filtering. > >Michael Kifer wrote: > > > >>Gary, >>A query is still a query. If you are asking for ancestors of John, you >> >> >should > > >>receive them in PR as well. It is just that PR will first compute the >> >> >whole > > >>thing first. Does Oracle's rule language have such postprocessing >>filtering capabilities? >> >> >> --michael >> >> >> >> >> >> >>>My take-away from the email discussion on this issue is that PR can >>>express recursive rules just as well as Horn. >>>The real issue is how the rules are "executed". >>> >>>With Horn (prolog), one "queries the KB" to execute rules. The cool >>>thing about queries is that they can (optionally) pass in bound >>>variables to terminate the recursion. E.g., with a simple factorial >>>ruleset, the queries "factorial(?x, 24)" and "factorial(4, ?y)" >>>terminate, whereas factorial(?x, ?y) does not. >>> >>>With PR, there is no query in the prolog sense. One executes rules by >>> >>> > > > >>>giving a run(n) command, where n is the number of rules to fire. If n >>> >>> > > > >>>is not specified, the PR system runs until no more rules fire. >>>Essentially, the run command is like a query with all variables >>> >>> >unbound, > > >>>but instead of the "answer" being returned as a set of variable >>>bindings, the "answer" is left as a bunch of factorial tuples in >>> >>> >working > > >>>memory. >>> >>>So, I would withdraw the PR-recursion issue and raise a PR-query >>> >>> >issue. > > >>>Per the charter, >>> >>>The core rule engine functionality is to load zero or more rulesets >>> >>> >(or > > >>>datasets) and then answer zero or more queries against the merged >>>contents. This functionality is largely independent of engine >>>implementation strategies. (In particular, it works with both forward >>>chaining <http://en.wikipedia.org/wiki/Forward_chaining> and backward >>>chaining <http://en.wikipedia.org/wiki/Backward_chaining>.) >>> >>>We will have to be very careful about how to define a query against a >>> >>> >PR > > >>>system. >>> >>>Nichols, Deborah L. wrote: >>> >>> >>> >>> >>> >>>>First, my apologies for a late posting of the recursion issue to the >>>>Issues board. Sponsor work has increased, and I haven't kept up to >>>>date properly. That said, however, I still want to record the issue >>>>officially and clarify some aspects before stating the resolution. >>>> >>>>Axel's generalization of the issue makes an important point IMO. If >>>>the RIF Core allows "degrees of freedom" that not all rule languages >>>>can express or implement, then should those features be restricted >>>> >>>> >(by > > >>>>putting them out of the Core) or restrictable (e.g., by profiles)? >>>> >>>>(Profiles is the next issue to be - finally - posted.) >>>> >>>>If we say that the Core should not be limited by what PR language can >>>>handle (vs. what PR implementations can handle) - Paul's point - and >>>> >>>> >we > > >>>>leave recursion in, then will a difficulty arise when compliance is >>>>defined? >>>> >>>>If we can come to a resolution by email, it isn't necessary to spend >>>>meeting time on discussion. >>>> >>>>Regards, >>>>Deborah >>>> >>>>-----Original Message----- >>>>From: public-rif-wg-request@w3.org >>>>[mailto:public-rif-wg-request@w3.org] On Behalf Of Paul Vincent >>>>Sent: Tuesday, February 20, 2007 6:39 AM >>>>To: Rule Interchange Format (RIF) Working Group WG >>>>Subject: RE: ISSUE-28: Recursion in the RIF Core >>>>Importance: Low >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> I thought that we did sort out this issue. Namely, that >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>recursive >>>> >>>> >>>> >>>> >>>> >>>> >>>>> clauses can be expressed by PR. I am also confused why did this >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>issue >>>> >>>> >>>> >>>> >>>> >>>> >>>>> came back. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Gary suggested a scheme whereby it would be possible to map a >>>> >>>> >recursive > > >>>>PROLOG-type rule into a PR language (by effectively simulating bwd >>>>chaining). And of course procedural extensions to PR languages can >>>>certainly handle recursion (albeit not as "PR rules" per se). >>>> >>>>But saying >>>>"PR language implementations can handle recursion" >>>>...does not equal >>>>"PR can handle recursion" >>>>(for me anyway). So this makes RIF Core "PR possible" rather than "PR >>>>friendly". Hence, I assume, the "outstanding issue" for RIF. >>>> >>>>But is it worth debating further? That would be my question. >>>> >>>>[Conjecture:] >>>>Of course, the counterargument is that without recursion, RIF Core is >>>>"meaningless" (as a rule language or maybe as a rule representation). >>>> >>>> > > > >>>>And of course, a countercounterargument is that RIF Core probably >>>>*cannot* be a core subset covering all rule language semantics and >>>>still >>>>be a useful language in its own right (eg RIF Horn profile), and >>>> >>>> >indeed > > >>>>this should not be its goal: at best it should represent some common >>>>expression representation scheme and/or a generalized rule metamodel >>>>and/or rule classification scheme. >>>> >>>>Just my 2 eurocents... >>>> >>>>Paul Vincent >>>>TIBCO - ETG/Business Rules >>>> >>>> >>>>-----Original Message----- >>>>From: public-rif-wg-request@w3.org >>>>[mailto:public-rif-wg-request@w3.org] >>>>On Behalf Of Michael Kifer >>>>Sent: 20 February 2007 09:51 >>>>To: axel@polleres.net >>>>Cc: Rule Interchange Format (RIF) Working Group WG >>>>Subject: Re: ISSUE-28: Recursion in the RIF Core >>>> >>>> >>>> >>>>I thought that we did sort out this issue. Namely, that recursive >>>>clauses >>>>can be expressed by PR. I am also confused why did this issue came >>>>back. >>>> >>>> >>>> --michael >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Now I am a bit confused about that, to be honest, if I think it a >>>>> >>>>> >bit > > >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>>>further: >>>>> >>>>>if we assume that RIF core should be common to ALL rules languages >>>>>around, would we also need to cut down other degrees of freedom >>>>> >>>>> >which > > >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>>>Core allows: e.g. that we do not differentiate between the symbols >>>>>allowed for constants and function symbols, which some >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>systems/languages >>>> >>>> >>>> >>>> >>>> >>>> >>>>>do, that we allow the same symbol to be used with different arities, >>>>>which some systems don't allow. >>>>>Next, there are languages which e.g. restrict the allowed arity of >>>>>predicates and thus would neither cover all of RIF Core, e.g. SWRL >>>>>only allows unary and binary preds in Horn rules. >>>>> >>>>>Would these then also be issues? >>>>> >>>>>I don't think we need to go that far. If we define the core really >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>only >>>> >>>> >>>> >>>> >>>> >>>> >>>>>as "what is expressible by any implemented rules system" then we'd >>>>>probably end up with propositional nonrecursive horn-rules with one >>>>>proposition in the antecedent? >>>>> >>>>>Probably I got this wrong, but it would be good if we define where >>>>> >>>>> >to > > >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>>>draw the line, right? >>>>> >>>>>just my 2 cents, >>>>>Axel >>>>> >>>>>Rule Interchange Format (RIF) Working Group Issue Tracker wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>ISSUE-28: Recursion in the RIF Core >>>>>> >>>>>>http://www.w3.org/2005/rules/wg/track/issues/28 >>>>>> >>>>>>Raised by: Deborah Nichols >>>>>>On product: Technical Design >>>>>> >>>>>>Issue: Recursion in the RIF Core >>>>>>Opened by Deborah Nichols [on behalf of RIF Chairs] >>>>>> >>>>>>This issue concerns whether or not to include recursion in the >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>specification >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>of the RIF Core. >>>>>> >>>>>>Summary of an argument for exclusion: >>>>>>Assuming >>>>>>(1) that the RIF Core consists of positive Horn clauses and >>>>>>(2) that the RIF Core should be "common to" (i.e., translatable >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>into) all RIF >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>dialects, and >>>>>>(3) since positive Horn includes recursive formulas, >>>>>>then (4) if Production Rules cannot support recursion, >>>>>>the conclusion is (5) that would be no "compliant" PR dialect of >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>the >>>>RIF >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>Core. >>>>>>But it isn't acceptable not to have a PR dialect of RIF; >>>>>>therefore, (6) recursion should be "removed" from the Core. >>>>>>(One method of "removal" would be to use profiles; see related >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>Issue.) >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>Background and discussion: >>>>>> >>>>>>At F2F4, Gary Hallmark took an action [#188] to address the >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>question >>>>whether >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>recursive rules should be included in the RIF Core. Of particular >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>concern was >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>the handling of recursion for Production Rule (PR) systems. Gary >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>presented >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>the issue in email on 12 Dec 2006 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>(http://lists.w3.org/Archives/Public/public- >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>rif-wg/2006Dec/0035.html), questioning whether production-rule (PR) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>systems >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>can support recursion and could implement a Core that included it. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>>>>"The current proposal for a RIF Core is positive Horn clauses. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>Such >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>clauses may be recursive, meaning that the relation name in the >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>head >>>>of >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>a rule also occurs (directly or indirectly) in the body of that >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>rule. >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>Because the semantics of a set of positive Horn clauses can be >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>defined >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>without reference to an evaluation strategy, an implementation is >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>free >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>to use something other than forward chaining. In fact, most prolog >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>>>>implementations use backward chaining. >>>>>> >>>>>>"The issue here is: is there a general strategy to evaluate >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>recursive >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>positive Horn rules using forward chaining, so that every ruleset >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>in >>>>RIF >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>Core can be translated to production rules? I don't really know >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>for >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>sure, but I suspect the answer is "no". Here is a simple example >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>to >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>illustrate the problem ....[factorial example follows]" >>>>>> >>>>>>The implication for the RIF Core, as Gary stated later in the >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>thread, is that: >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>"As I understand it, RIF Core should be common to *all* RIF >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>dialects, >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>including a production rule dialect. Now, it's clear that there >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>are >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>aspects of production rules that probably won't translate to Core >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>(e.g. >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>priority, retract). That may be ok if we can add them to the >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>dialect >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>without breaking the Core semantics. On the other hand, it is >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>critical >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>that *everything* in Core can be translated to PR, otherwise we >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>have >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>dialects of Core itself, which means it really isn't a Core. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>Therefore, >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>if Core supports recursive rules, then so should PR. If we don't >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>think >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>it's practical to support recursive rules in PR, then we should >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>remove >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>this feature from Core." >>>>>> >>>>>>This issue is related to the "profiles" issue: If RIF supports >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>profiles, then >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>recursion may be the most obvious feature to make "optional". >>>>>> >>>>>>The recursion issue also has implications for defining conformance >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>to the RIF >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>Core. See Dave Reynolds' explanation >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>(http://lists.w3.org/Archives/Public/public-rif-wg/2007Jan/0079.html) >>>> >>>> >: > > >>>> >>>> >>>> >>>> >>>>>>"The specific issue that triggered a lot of this is the extent to >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>which >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>existing production rule engines can implement recursive Horn rules >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>and >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>so whether RIF Core should be RIF-Horn-without-recursion. Given a >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>target >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>query pattern (or some other context of use information) then a PR >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>RIF >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>translator can implement recursive horn rules but may be >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>non-terminating >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>for unrestricted queries. So either RIF has to convey that context >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>of >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>use, or the issue of ruleset termination is outside of RIF >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>conformance, >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>or we need some other notion of RIF Core." >>>>>> >>>>>>Chris Welty summarized the discussion of the nature of the Core, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>from the 16 >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>>>>Dec telcon >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>(http://lists.w3.org/Archives/Public/public-rif-wg/2007Jan/0093): >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>"We then went on discussing the nature of the CORE. The discussion >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>centered >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>on whether or not all languages were required to be able to >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>translate >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>FROM "all" of the CORE to be conformant. Some continue to feel >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>this >>>>is >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>unrealistic, however we lack examples that demonstrate it. Several >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>expressed >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>support for a very limited notion of profiles for the CORE. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>Profiles would >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>specify features that we may consider "optional" or that may >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>determine the >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>degree of conformance of a translation. Examples of features in a >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>possible >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>CORE profile were: recursion, decidability, complexity bounds, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>functions. >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>"There seemed to be consensus that there is one core dialect with >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>the >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>expressivity of about Horn and that we should move forward with the >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>>>>specification of that dialect, independently of other >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>considerations. If >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>there is a notion of profiles it should be extremely restricted so >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>that >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>the "CORE is still a core". At the moment, we do not have any >>>>>>specific "features" of the CORE that anyone has objected to, except >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>possibly >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>recursive rules, so it is still not clear that we need profiles for >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>the CORE. >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>"We discussed whether RIF dialects must include and extend the >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>CORE. >>>>The >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>possibility of profiles opens the door for some dialects to >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>eliminate certain >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>features (again, from a very restricted set). In other words, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>profiles may >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>allow some dialects to extend a subset of the CORE." >>>>>> >>>>>>Links to related email threads concerning PR and recursion: >>>>>>http://lists.w3.org/Archives/Public/public-rif-wg/2006Dec/0035 >>>>>>http://lists.w3.org/Archives/Public/public-rif-wg/2006Dec/0127 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>contains >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>discussion following on Gary's factorial example. >>>>>>http://lists.w3.org/Archives/Public/public-rif-wg/2006Mar/0202 >>>>>>http://lists.w3.org/Archives/Public/public-rif-wg/2006Dec/0047.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>questions >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>whether recursion should be included in a PR system. >>>>>> >>>>>>Related threads on "recursive rules" vs. "recursive terms": >>>>>>http://lists.w3.org/Archives/Public/public-rif-wg/2006Dec/0114 >>>>>>http://lists.w3.org/Archives/Public/public-rif-wg/2006Dec/0103 >>>>>> >>>>>>An earlier (March 2006) discussion of recursion: >>>>>>http://lists.w3.org/Archives/Public/public-rif-wg/2006Mar/0106.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>-- >>>>>Dr. Axel Polleres >>>>>email: axel@polleres.net url: http://www.polleres.net/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> >> > > >
Received on Monday, 26 February 2007 17:35:44 UTC