Hi Miguel,
The difference between forward and backward rules, in the case of Jena
Rules at least, is simply to do with performance tradeoffs. Generally
whatever you can do with one you can do with the other. There's no
connection between backward rules and particular shapes of triple
pattern. None of your examples have rules within rules, and don't need them.
I would strongly advise you to use either forward rules or backward
rules but not to mix them unless you are really really sure that's what
you need to do and are clear on the consequences.
On 15/03/14 11:43, Miguel Bento Alves wrote:
Hi Joshua,
I wasn't very clear in my example. I have my rule r1 which defines ?s p
?o. However, I can't define that the property p of ?s is ?o with the
traditional mechanisms of inference of OWL or OWL2. Thus, I have a rule
that defines:
(?s p ?o) <- c1, ... .
Which could equally well be a forward rule:
c1, ... -> (?s p ?o) .
However, I need to produce a reified triple that has an associated
certainty factor:
(?f p ?e),
(?f p1 ?p),
(?e p2 ?p),
makeTemp(?bn) ->
(?bn rdf:subject ?f),
(?bn rdf:predicate p3),
(?bn rdf:object ?e),
(?bn exa:certainty "0.9"^^xsd:decimal).
I'm not having a good understanding what rules are for?
There's certainly some underlying confusion here somewhere.
Taking your example, why not:
(?s rdf:type ?superclass),
c1 ->
t1, t2.
(and the previous example doesn't work as a rule, only works as OWL
inference mechanisms).
?? That would work fine as a rule (depending on what precisely c1, t1
and t2 are).
Though your use of the variable name ?superclass is worrying, you might
have been trying to create an example more like:
(?s rdf:type ?type) (?type rdfs:subClassOf ?superclass) ... -> ... .
Don't know what you mean by "only works as OWL inference mechanism".
The built in Jena OWL reasoners are just rule systems (which implement
incomplete but useful fragments of OWL full).
Or why not:
(?f rdf:type ?superclass),
(?f p1 ?p),
(?e p2 ?p),
makeTemp(?bn) ->
(?bn rdf:subject ?f),
(?bn rdf:predicate p3),
(?bn rdf:object ?e),
(?bn exa:certainty "0.9"^^xsd:decimal).
Sure.
One thing common in your examples which may or may not be part of the
problem is that you seem to assert only the reification. Just because
there is a reified triple in a graph doesn't mean that the triple itself
is there. If you want to also assert the triple (so that it can trigger
other rules or be queries) then you would have a pattern more like:
(?f p ?e),
(?f p1 ?p),
(?e p2 ?p),
makeTemp(?bn) ->
(?f p3 ?e),
(?bn rdf:subject ?f),
(?bn rdf:predicate p3),
(?bn rdf:object ?e),
(?bn exa:certainty "0.9"^^xsd:decimal).
Dave
Miguel
On 15/03/14 01:45, "Joshua TAYLOR" <[email protected]> wrote:
On Fri, Mar 14, 2014 at 4:23 PM, Miguel Bento Alves
<[email protected]> wrote:
Hi Joshua,
r1 is a backward rule [r1: Š <- Š]. In my understanding, backward rules
are things that relate two resources, overcoming the limitations of OWL
and OWL2.
A backward rule doesn't relate two resources. A backward rule
provides a pattern for a triple as the head, and some conditions under
which the triple can be inferred. E.g.,
[r: (?s rdf:type ?superclass) <-
(?s rdf:type ?subclass)
(?subclass rdfs:subClassOf ?superclass)]
When the reasoner tries to infer a triple of the form (?s rdf:type
?superclass), it will try to use this rule by checking whether matches
for the body can be found. It doesn't make sense to say that the rule
r relates two resources; that's not what a rule is. A rule is a
basis for for inferring triples from existing data and other
conditions.
Thus, I think that the example that I gave make sense:
(r1 is a backward rule)
(?f r1 ?e),
(?f p1 ?p),
(?e p2 ?p),
makeTemp(?bn) ->
(?bn rdf:subject ?f),
(?bn rdf:predicate p3),
(?bn rdf:object ?e),
(?bn exa:certainty "0.9"^^xsd:decimal).
Again, I'm not sure what (?f r1 ?e) is supposed to mean. In the rule
syntax, it's just a triple with variables as the subject and object,
and a URI r1 as the predicate. In the example rule r that I gave,
what would you expect (?s r ?o) to mean?
Moreover, this rule works well if I materialize r1.
Construct {
(?f r1 ?e)
}
Where {
(?f r1 ?e)
}
(of course, if I materialize a rule I remove from ruleset).
I'm not sure what this is supposed to mean. If you construct the data
that matched a triple pattern, then you'll get the same data that
matched the triple pattern. I'm not sure how this is "a
materialization of r1".
Do you think that this understanding of what is a (backward) rule is not
correct?
I think it's not correct, but I'm still not sure what you think it
would mean to have a backward rule [r: ... <- ...] and then write a
triple pattern (?s r ?o). Rules aren't predicates, so it doesn't
make sense to me to try to use them as predicates.
//JT
--
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
