(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.

On the other hand, if requiring an implementation to understand a query 
means that they must be able to translate it into a query that makes 
sens against their own data sources (or their own access to the 
specified data sources), why include it as a SPARQL query? Shouldn't it 
rather be included in a data-source neutral form? That would place the 
burden of tranformation on the publisher rather than on the receiver, 
which might have some inconvenience (like, making roundtrips more 
complex), but it would keep RIF Core simpler (specialised dialects would 
then add specialised buildins ad libitum).

But it may not be that simple, e.g., what if the rules I publish are 
supposed to access my data source, even when you use them - something we 
could have in UC6, e.g. if pharmaceutical companies published their 
drugs notices in the form of rulesets? Allowing RIF to include 
blackboxes could be a solution for that UC (something like: if the rules 
I retrieve from you include a blackbox, I can return the blackbox (*) to 
you along with some specified instance data, and you have to return me 
the appropriate answer), but what of other use cases? If any?

Which brings back the question of the identification of and access to 
data sources (remember action-120?)... And blackboxes as well, by the 
way (that is, issue-16; was dubbed phase 2, but if we need a generic 
mechanism in RIF Core, we might want to do that in phsae 1).

> Unless we start a 
> semantic-web-friendly dialect there is no dialect to put it in. We could 
> put it in the proposed library of reusable components so that future 
> definers of semantic-web-friendly dialects might reuse the same one. 

My hypothesis was rather that it (the reusable component library) would 
work the other way round: if we or some future definers of dialects need 
to specify such buildins, we or they will put them in the library of 
reusable components. I think that it would be dangerous to allow the 
addition in the library of components that are not used in a dialect 
(under the motto: "make sure that a component is usable before thinking 
of re-use" :-)

Christian

(*) Meaning: I do not have to understand it nor be able to translate it 
in anything but a call to you.

Received on Tuesday, 9 January 2007 11:49:53 UTC