Rya Query Inference
Overview Rya Inference Capabilities Backwards chaining inference Other inference strategies
Rya Inference Capabilities Rya supports backwards chaining inference for the following constructs: Owl:sameAs, rdfs:subclassOf, rdfs:subPropertyOf, symmetric properties, transitive properties, inverse properties Inference is initiated by initializing a inference engine The inference engine loads model information into memory (client side) This model information is refreshed on a regular basis (default is five minutes) by a concurrent thread running client side The inference engine is used at query time to expand queries
Backwards Chaining Inference Query is expanded at query execution time to include inferred triples Example: Original Query: SELECT ?person WHERE { ?person rdf:type <urn:Person>. } Expanded Query: {?person rdf:type <urn:Person>. } UNION { {?person rdf:type ?dummy. ?dummy rdf:subclassOf <urn:Person>. } }
Backwards Chaining Inference in Rya Inference is implemented as a set of visitors All of the visitors are in mvm.rya.rdftriplestore.inference package In general, visitor: Looks for a specific statement pattern type (keys off of a predicate) Expands the query to include a dummy join (InferJoin) Substitutes a “FixedStatementPattern” statement pattern for the left side of the dummy join Substitutes a “DoNotExpandStatementPattern” statement pattern for the right side of the dummy join
Backward Chaining Example: Original Query SELECT ?person { ?person rdf:type <urn:person>. ?person <urn:name> “Jane”.} ?person rdf:type <urn:Person>. ?person <urn:name> “Jane”.
Backward Chaining Example: Expanded Query Infer Join ?person <urn:name> “Jane”. Fixed Do Not Expand ?dummyClass = <urn:Mother>, <urn:Father>, <urn:HappyPerson>, <urn:SadPerson>, <urn:Person>. ?person rdf:type ?dummyClass.
Code Example: MongoRyaDirectExample
Other inference strategies Materializing inferred statements Instead of expanding the query, materialize inferred triples and add them to Rya (forward chaining reasoning) Scalability concerns Consistency concerns Keep model information in a specific index Materialize inferred statements model definition statements in a separate index rather than with the explicitly asserted data Removes the need to load it client side (which may have scalability issues for large models)