RE: (TED] SPARQL, data sources and blackboxes [was (Re: [UCR] ISSUE-12 and ACTION6198)]

Some examples to consider that don't seem to have come up:

1.  What if the RIF compliant application is a custom "editor" designed
to create or publish a collection RIF rules?  Surely it need not be able
to execute them.

2.  What if the RIF compliant application is a broker that farms out
execution to a collection of rules engines?  Is knowledge that a
particular engine is capable of executing the collection of rules and
the ability to pass on the message enough to qualify?

3.  What about a A RIF formatter.

Stan Devitt
 

-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Christian de Sainte Marie
Sent: Tuesday, January 09, 2007 12:51 PM
To: Dave Reynolds
Cc: RIF WG
Subject: (TED] SPARQL, data sources and blackboxes [was (Re: [UCR]
ISSUE-12 and ACTION6198)]


Dave Reynolds wrote:
> 
> [...]
> 
> Let us pick one of the boundary cases to ground the discussion. What 
> about the set of builtins/functions such as one for access to an 
> external SPARQL data source.
> 
> Technically there is nothing stopping us defining such a thing but 
> where would that go? It can't go in RIF Core [*] because lots of rule 
> vendors won't want to support such a thing.

I do not think that the vendors are the main issue, here. Suppose we
have good reasons to put such buildins in RIF Core: we would require
compliant implementations to *understand* a RIF rule that contains a
SPARQL query. But could we require that they (more precisely, the
applications that use the retrieve rules) be able to *execute* the
query, that is, not only to implement SPARQL, but also to have a
SPARQL-able data source?

The intuitive answer seems to be 'no' (and that applies to SQL queries
etc, as well); at least not in RIF Core.

Received on Tuesday, 9 January 2007 12:47:43 UTC