Skip to content

Instantly share code, notes, and snippets.

@AlBaker

AlBaker/stardog-reasoning-explain.md

Last active June 18, 2017 21:14
Show Gist options
  • Save AlBaker/fef3a8dcb66b9a689b8082fb09cdea12 to your computer and use it in GitHub Desktop.
Save AlBaker/fef3a8dcb66b9a689b8082fb09cdea12 to your computer and use it in GitHub Desktop.
Download ZIP
Debugging with Stardog Reasoning Explain
Raw
stardog-reasoning-explain.md

What to do when you're knowledge graph seems to know something it shoulnd't? For example when subjects were coming back with a type relationship they shouldn't - stardog reasoning explain to the rescue:

$ stardog reasoning explain decomp "<https://example.org/id/1> a ns:MyType"
INFERRED <example.org/id/1> a ns:MyType
   ASSERTED ns1:linkedFrom rdfs:domain ns1:MyType
   INFERRED <https://example.org/id/1> ns1:linkedFrom i:1_1
      ASSERTED ns1:linkedFrom owl:inverseOf ns1:linkedRequirement
      ASSERTED i:1_1 ns1:linkedRequirement <https://example.org/id/1>

In this case, a property definition with a rdfs:Domain to the wrong class was used. So the reasoner infers that because linkedFrom goes to MyType that anything in the graph with that property between nodes, means that the node in that relationship is also a MyType.

The beauty of this is that it is a one line declarative data change. Not some custom business logic, not an entity bean, or biproduct of ETL. It's all just data in the knowledge graph, and Stardog understands graphs like no other.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment