Hi Dave,
“...I would recommend doing so as a built-in…”.
I did that and worked for some examples. However, I couldn’t generalise the
processing. In RETEforward the rules are triggered in response of triples
fired. When we have a rule with one one sparql command nothing trigger the
rule. Furthermore, in RETEforward mode the built-in functions are not triggered
in response of triples fired. So, new data, used by a SPARQL command, will not
triggered the built-in representing the SPARQL command.
First I try to hook sparql commands with terms rules without share variables.
Some of my approaches were:
transform the rule. For instance, the rule:
(?x ?p ?y) (\\\sparql Select ?y ?z where {?y <eg:p> ?z} \\\sparql) -> (?x
<eg:p1> ?z)
was transformed in:
(?x ?p ?y) ( Select ?y ?z where {?y <eg:p> ?z}) (?Ltmhp sprqlrules:p1Ltmhp ?y)
(?Ltmhp sprqlrules:p2Ltmhp ?z) NotSparqlPrefix(?p) -> (?x eg:p1 ?z)
The engine, every time that founds a SPARL command, runs the SPARQL commands.
The result was transformed in the follow form:
?rowNumber ?varID ?var
for example:
<sprqlrules:v1iQFL7> <sprqlrules:p1iQFL7> <eg:A>
<sprqlrules:v1iQFL7> <sprqlrules:p2iQFL7> <eg:C1>
<sprqlrules:v2iQFL7> <sprqlrules:p1iQFL7> <eg:A>
<sprqlrules:v2iQFL7> <sprqlrules:p2iQFL7> <eg:C>
and fired the triples to the engine.
other approach was to use a built-in function, to allow in future to pass
variables to the command as parameters.
(?x ?p ?y) ExecSparql() (?Ltmhp sprqlrules:p1Ltmhp ?y) (?Ltmhp
sprqlrules:p2Ltmhp ?z) NotSparqlPrefix(?p) -> (?x eg:p1 ?z)
In this approach, when the rules are compiled I attached the Sparql command to
the built-in function.
but the problem was that the built-in functions are not triggered in response
of triples fire.
I didn’t test other consequences of these approaches or even I discussed before
with the community because I wanted first find out a possible solution (even to
clear my mind about this problem) and after open to discussion.
"it might be better to start over with a fresh engine in that case.”
I hope to work on it, even after the end of my project.
can you give me your opinion in my question: is acceptable allow sparql
commands with rule terms but only guarantee the results of the asserted data?
OWL reasoning only works with asserted data. I can have an ObjectProperty p in
a OWL constraint and have a rule like ?x ?p ?y. However, the rule is not
evaluated when the OWL constraint is evaluated.
In answer to my question, if we consider that is acceptable I can work right
now on that, in a new engine only to deal with that kind of rules. Otherwise, I
foresee a massively more work and I will not have time for that in this
project.
Miguel
On 08 Aug 2014, at 13:47, Dave Reynolds <dave.e.reyno...@gmail.com> wrote:
> 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
>>
>
