[
https://issues.apache.org/jira/browse/TINKERPOP-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-881.
--------------------------------------
Resolution: Later
> [Proposal] A Process-Based Graph Reasoner
> -----------------------------------------
>
> Key: TINKERPOP-881
> URL: https://issues.apache.org/jira/browse/TINKERPOP-881
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.2-incubating
> Reporter: Marko A. Rodriguez
> Priority: Major
>
> This would be a big initiative, so its more than "just a ticket," but it
> would be a neat idea.
> A reasoner allows someone to express implicit edges/properties in the graph.
> For instance, it is possible to say that {{ancestor}} is transitive. If there
> was an explicit graph structure like:
> {code}
> marko--ancestor-->jose--ancestor-->fernando--ancestor-->someSpanishDude
> {code}
> Then when you did the following query:
> {code}
> gremlin> g.V.has('name','marko').out('ancestor').name
> ==>jose
> ==>fernando
> ==>someSpanishDude
> {code}
> That is, because it is declared the {{ancestor}} is transitive, the implicit
> {{marko--ancestor-->someSpanishDude}} is generated. Now, there are two types
> of reasoners: structure and process.
> A *structure reasoner* will infer all the entailments of the schema when the
> graph is modified (added to or deleted from). Thus, what is implicit is made
> explicit and put into the graph. With this model, your data set has more data
> than what was explicitly put into it.
> A *process reasoner* will infer all the entailments of the schema as it
> pertains to the current query being executed. Thus, what is implicit is made
> explicit at query runtime. With this model, you data set contains only what
> was explicitly inserted.
> These two models either make a sacrifice of space or time.
> If we wanted just a *process reasoner*, then this could be a
> {{ReasoningStrategy extends DecorationStrategy}}. Where the above
> {{ancestor}} query would be rewritten as:
> {code}
> g.V.has('name','marko').repeat(out('ancestor')).emit().name
> {code}
> In essence, "transitive" means {{repeat(...).until(false).emit()}} (loop
> until you can loop no more).
> I prefer the *process reasoner* model as its less cumbersome and potentially
> damaging to the integrity of the underlying data set. Moreover, it can be
> "easily" implemented as a {{TraversalStrategy}}.
> The next question is, how is the reasoning schema (ontology) specified?
> Perhaps via a builder?
> {code}
> ReasoningStrategy.build().
> .transitive("ancestor")
> .subEdge("hasPet","likes") // if I have a pet dog, I like dogs.
> .symmetric("friend") // a.friend.b implies b.friend.c
> .functional("marriedTo") // a.marriedTo.b, c.marriedTo.b ==> a=c
> ...other stuff
> .create();
> {code}
> Here are some links to study:
> * https://jena.apache.org/documentation/inference/#the-owl-reasoner
> * http://owl.man.ac.uk/2003/why/latest/
> In my experience, you can do a lot with support for the basics: transitive,
> symmetric, etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
