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
