Re: [TED] SPARQL, data sources and blackboxes [was (Re: [UCR] ISSUE-12 and ACTION6198)] --> QLs in BR languages?

Thanks Paul, excellent points, I withdraw the SQL analogy as not being 
useful.

I guess one difference here is that SQL requires knowledge of the 
database layout which tends to be system specific whereas SPARQL 
doesn't. Well the equivalent is that you need to know the ontology of 
the data but part of the point of using an ontology in the first place 
is to aid portability. SPARQL queries are expected to be portable even 
though the mapping into your local datastore may be specialized.

Dave

Paul Vincent wrote:
> 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 09:51:28 UTC