- From: Paul Vincent <pvincent@tibco.com>
- Date: Wed, 10 Jan 2007 23:40:08 -0800
- To: "Dave Reynolds" <der@hplb.hpl.hp.com>, "Christian de Sainte Marie" <csma@ilog.fr>
- Cc: "RIF WG" <public-rif-wg@w3.org>
Dave: assuming "business rule language" refers commercial production rule engine languages (as opposed to SBVR-type natural language business statements): Yes, many rule engine languages provide extensions to allow "system rules" to be defined that extract data from database (eg via embedded SQL) or indeed other sources, eg during a transaction. I use the term "system rules" as they are rarely anything to do with business policy or practice, but are entirely to do with IT implementation practice. However, as such system rules are (almost by definition) system-specific (ie installation specific in many cases), they are not likely to be of interest to interchange. In addition, the sorts of rulesets that are optimized for execution (eg by splitting filters across DB accesses and then rule conditions as optimally as possible) are not going to be good candidates for "interchange" - just as if I want to translate from Java to C#, I don't bother with looking at the JITted/optimized bytecode representation... Cheers 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 Dave Reynolds Sent: 09 January 2007 22:41 To: Christian de Sainte Marie Cc: RIF WG Subject: Re: [TED] SPARQL, data sources and blackboxes [was (Re: [UCR] ISSUE-12 and ACTION6198)] ... I guess there is an analogy with SQL here. I'm sure many business rule languages allow you to embed SQL queries. You could have a simpler tuple-access primitive and do the joins in the rule engine instead of the database but that would often be horribly inefficient so I bet people put effort into partitioning the processing nicely between the database and the rule engine. Practical interchange of rules via RIF would probably require a preservation of the SQL/rule partitioning. SPARQL seems analogous. ...
Received on Thursday, 11 January 2007 07:44:27 UTC