On 08/08/14 15:27, Miguel Bento Alves wrote:
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.
Sure, like I say you can't generate a binding stream but you could have
a SPARQL builtin that filters and extends the binding set.
So for example, I think you could have something like:
(?artist yago:hasMusicalRole ?something)
sparql('SELECT (?count as count(?y))
WHERE {?artist yago:hasMusicalRole ?y .}', ?count)
->
(?artist ex:numInstruments ?count)
So the rule fires on artist with musical rules, the ?artist variable is
injected in the SPARQL query, the SPARQL result is bound to the ?count
variable for use in the rest of the rule.
Not sure how useful this is, if other rules add musical roles then you
will get multiple counts asserted, but I think it could be made to work
and there is at least one user out there who might want to use it.
Furthermore, in RETEforward mode the built-in functions are not triggered in
response of triples fired.
I think that's the same point, or if not then I don't understand it.
Adding triples fire rules based on the RETE pattern matching, a fired
rule will run its builtins which in turn can block the firing or add
additional bindings to the rule's binding set. So indeed you can't have
a useful rule with just a builtin on the LHS but you can have a builtin
that will guard a rule or bind derived values.
<snip>
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?
Sorry, I don't understand the question. The issue you are raising
seems to be about when the SPARQL triggers not what it queries over. You
can certainly query over the deduced model as well. That does introduce
non-monotonicity, it would be like the noValue builtin on steroids in
terms of its ability to confuse people :)
OWL reasoning only works with asserted data.
No.
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.
As explained in the docs [1] is not to do with working only over
asserted data, it is due to the layering of forward and backward
inference - the default OWL ruleset uses hybrid rules.
In answer to my question, if we consider that is acceptable I can work right
now on that,
Sorry, I don't think I'm able to answer the question.
To me the first step in combining SPARQL with rules is to work out what
you want that combination to do - what's the goal, what use case are to
be addressed, what's the semantics of the combination that could meet
those use cases.
Without knowing those it's hard to comment properly.
However, if I was forced to guess then I suspect most users, like you,
would expect such a combination to be able to run "generative" SPARQL
queries. So that you could have just a query on the LHS and generate
some results. In which case, as I've said several times now, that's hard
to do within the confines of the existing forward engine. Not impossible
but hard enough to question if its better to start over.
It is possible to introduce a SPARQL builtin (without or without a nice
syntax) which can be used in sufficiently controlled cases like the
above. That might be useful or it might cause more confusion than
benefit, hard to judge.
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.
Understood, a new engine is too ambitious for a summer project,
especially at this late stage.
Dave
[1] https://jena.apache.org/documentation/inference/#RDFSPlusRules
Miguel
On 08 Aug 2014, at 13:47, Dave Reynolds <[email protected]> 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
