On Fri, Mar 14, 2014 at 5:11 AM, Miguel Bento Alves <[email protected]> wrote: > > Yes, you are right I made a mistake with the grammar. The rule is on the > body, not in the head, sorry. > > “...body? I also don't see what the problem would be with your r5: > > [r5: (?x exa:sportPartner ?y), > (?x rdf:type exa:SeaMan), > (?y rdf:type exa:SeaMan) -> > (?x exa:seaPartner3 ?y)] > “ > > The problem is that doesn´t work, because the rule is in the body of the > forward rule.
My point here is that I don't see where in r5 you're claiming that there's a rule in the body. The rule r5 has three terms in the body: (?x exa:sportPartner ?y), and (?x rdf:type exa:SeaMan), and (?y rdf:type exa:SeaMan). It has one term in the head: (?x exa:seaPartner3 ?y). I understand that rules aren't allowed as body terms, but even if they were, it would look something like [ (x y z), # body term that's a triple [(a b c) -> (d e f)], # body term that's a rule (e f g) # another triple body term -> (t u v)] # head term That won't work, of course, but I can see how it "has a rule as a body term". I don't see anything about r5 that is an attempt to have a rule as a body term. > My problem is: I want to associate a certainty factor to a > conclusion. So, my approach was to create a blank node with the triple > plus the certainty factor: > > (r1 is a 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). > > This rule doesn’t work because I have a rule in the body. However, if I > materialize r1 then everything is ok. I'm still not sure what this would mean. I presume that by "(r1 is a rule)" you mean that there's a rule [r1: ... -> ...] somewhere. What would a pattern (?f r1 ?e) mean, even if the r1 used in a predicate position did refer to the rule somehow? Rules aren't thing that relate two resources; they are things that get fired when certain triples exist and other conditions are met, and that can produce some more triples. If you're trying to produce a reified triple that has an associated certainty factor, be aware that there's nothing the matter with creating this data: _:x rdf:subject <subject> _:x rdf:predicate <predicate> _:x rdf:object <object> _:x ex:certainty <certainty> However, be aware that is is four triples in the graph. Most importantly, the triple <subject> <predicate> <object> is _not_ in the graph, so other rules that are expecting it won't find it. If you want to match this data and get the certainty, you'll need to use a pattern like (?x rdf:subject ?s) (?x rdf:predicate ?p) (?x rdf:object ?o) (?x ex:certainty ?c) As a working example to demonstrate that you can create these kinds of triples, suppose you have this data: """ @prefix : <urn:ex:> . :individual1 a :someType . :individual2 a :someType . """ and this rule: """ [r1: (?x rdf:type ?z) (?y rdf:type ?z) notEqual(?x,?y) makeTemp(?b) -> (?b rdf:subject ?x) (?b rdf:predicate <urn:ex:similarTo>) (?b rdf:object ?y) (?b <urn:ex:certainty> 0.9)] """ then this is what you get out of an inference graph: """ @prefix : <urn:ex:> . [] <http://www.w3.org/1999/02/22-rdf-syntax-ns#object> <urn:ex:individual1> ; <http://www.w3.org/1999/02/22-rdf-syntax-ns#predicate> <urn:ex:similarTo> ; <http://www.w3.org/1999/02/22-rdf-syntax-ns#subject> <urn:ex:individual2> ; <urn:ex:certainty> "0.9"^^<http://www.w3.org/2001/XMLSchema#float> . <urn:ex:individual1> a <urn:ex:someType> . <urn:ex:individual2> a <urn:ex:someType> . [] <http://www.w3.org/1999/02/22-rdf-syntax-ns#object> <urn:ex:individual2> ; <http://www.w3.org/1999/02/22-rdf-syntax-ns#predicate> <urn:ex:similarTo> ; <http://www.w3.org/1999/02/22-rdf-syntax-ns#subject> <urn:ex:individual1> ; <urn:ex:certainty> "0.9"^^<http://www.w3.org/2001/XMLSchema#float> . """ > But I can’t get the values outside the rules, with the Sparql for > instance. With this approach, you'll be able to get values out with SPARQL. A query like this: prefix : <urn:ex:> prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> select ?s ?p ?o ?c where { [ rdf:subject ?s ; rdf:predicate ?p ; rdf:object ?o ; :certainty ?c ] } produces these results: | <urn:ex:individual2> | <urn:ex:similarTo> | <urn:ex:individual1> | "0.9"^^xsd:float | | <urn:ex:individual1> | <urn:ex:similarTo> | <urn:ex:individual2> | "0.9"^^xsd:float | Here's the code: import java.io.ByteArrayInputStream; import com.hp.hpl.jena.query.QueryExecutionFactory; import com.hp.hpl.jena.query.ResultSet; import com.hp.hpl.jena.query.ResultSetFormatter; import com.hp.hpl.jena.rdf.model.InfModel; import com.hp.hpl.jena.rdf.model.Model; import com.hp.hpl.jena.rdf.model.ModelFactory; import com.hp.hpl.jena.reasoner.Reasoner; import com.hp.hpl.jena.reasoner.rulesys.GenericRuleReasoner; import com.hp.hpl.jena.reasoner.rulesys.Rule; import com.hp.hpl.jena.vocabulary.RDF; public class RuleExample { public final static String DATA = "" + "@prefix : <urn:ex:> .\n" + "\n" + ":individual1 a :someType .\n" + ":individual2 a :someType .\n" + ""; public final static String RULES = "" + "[r1:\n" + " (?x rdf:type ?z)\n" + " (?y rdf:type ?z)\n" + " notEqual(?x,?y)\n" + " makeTemp(?b)\n" + " ->\n" + " (?b rdf:subject ?x)\n" + " (?b rdf:predicate <urn:ex:similarTo>)\n" + " (?b rdf:object ?y)\n" + " (?b <urn:ex:certainty> 0.9)]\n" + ""; public final static String QUERY = "" + "prefix : <urn:ex:>\n" + "prefix rdf: <"+RDF.getURI()+">\n" + "\n" + "select ?s ?p ?o ?c where {\n" + " [ rdf:subject ?s ;\n" + " rdf:predicate ?p ;\n" + " rdf:object ?o ;\n" + " :certainty ?c ]\n" + "}\n" + ""; public static void main(String[] args) { Model model = ModelFactory.createDefaultModel(); model.read( new ByteArrayInputStream( DATA.getBytes() ), null, "TTL" ); Reasoner reasoner = new GenericRuleReasoner( Rule.parseRules( RULES )); InfModel iModel = ModelFactory.createInfModel( reasoner, model ); System.out.println( DATA ); System.out.println( RULES ); iModel.write( System.out, "TTL" ); System.out.println( QUERY ); ResultSet results = QueryExecutionFactory.create( QUERY, iModel ).execSelect(); ResultSetFormatter.out( results ); } } -- Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
