Hi Miguel,
I found this hard to follow.
There shouldn't be any problem embedding SPARQL queries into forward
rules so that they can see the deduced data. The hard issue is that the
forward engine has no support for primitives that return streams of
bindings.
To embed a SPARQL query in forward rules in the simple case then I would
recommend doing so as a built-in. This could:
- inject the variable bindings from the rule environment into the
SPARQL query (no need for funny SPARQL syntax, just inject them all),
- run the query over the (dynamic) union of the base data and the
deductions model,
- take the variable bindings from the first row of the result set and
bind the corresponding rule variables
- possibly raise an error if there is more than one result row
(unclear whether that's the right thing to do or not)
This would be sufficient, for example, to handle the "count all triples"
case raised in the user list recently.
As we've discussed before, to restructure the rule engine to allow for
builtns generating streams of bindings would be massively more work. It
is possible but, as also mentioned, it might be better to start over
with a fresh engine in that case.
Dave
On 08/08/14 11:23, Miguel Bento Alves wrote:
Hi All,
I couldn't implement the hook between a Sparql command and rules terms. In my
opinion, only make sense hook a Sparql command and rules terms if in the sparql
command we can invoke variables from rules terms. Something like:
(?x <eg:p> ?y),
(\\\sparql Select ?z where {&y <eg:p> ?z .} \\\Sparql)
->
(?x <eg:p1> ?z) .
(remarks: 1 -> the variable &y in Sparql means the value of ?y in rule
terms. If will be implemented in the future, the correct syntax must be discussed. 2
-> is only an example. Don't try to find any sense in the rule).
If we consider that sparql command cannot invoke variables from rules terms, it
is not necessary to hook Sparql commands with rules terms.
The rule:
(?x <eg:p> ?y),
(\\\sparql Select ?y ?z where {?y <eg:p> ?z .} \\\Sparql)
->
(?x <eg:p1> ?z) .
can be transformed in :
(?x <eg:p> ?y),
(?x <eg:p2> ?z)
->
(?x <eg:p1> ?z) .
(\\\sparql Select ?y ?z where {?y <eg:p> ?z .} \\\Sparql) -> (?x
<eg:p2> ?z)
In my opinion, the forwardRETE engine mode is not appropriate to have a sparql
command hooked with rule terms because in this mode the engine fires triples an
evaluate if the rules are successful. The drawback of the backward mode is that
we cannot have more than one conclusion (only allows one term in the head).
My question: is acceptable allow sparql commands with rule terms but only
guarantee the results of the asserted data? Is the behaviour in Jena of OWL
constraints, where we cannot reasoner over dynamic data. The main problem is if
a Sparql command makes reference to rules and produce new data that will be
used by the rules to produce more new data. This flow control carries some
issues that is not easy to implement.
Miguel
