As a brief overview, Apache TinkerPop is a graph abstraction for different graph databases and graph processors. With respect to graph databases, it is implemented by just about every major graph database provider - both open source and commercial - to include IBM Graph, Neo4j, OrientDB, DataStax Enterprise Graph, and others. For graph processors there are implementations over spark, hadoop, and giraph. The point of all the abstraction is that all of your code is just the Gremlin Graph Traversal Language. The same line of Gremlin will traverse a graph in an OLTP style over Neo4j as it will in OrientDB. Similarly, that same line of Gremlin could also be executed using Spark as it's engine to execute a traversal over a multi-billion edge graph in parallel. It's all just Gremlin!
There's lots of examples of Gremlin in our documentation but a simple traversal basically looks like this:
gremlin> marko = g.V().has('name','marko').next() // find me a person named "marko"
==>v[1]
gremlin> g.V(marko).out('knows').values('name') // get me the names of people "marko" knows
==>vadas
==>josh
It's worth noting that Gremlin has both imperative and declarative aspects. You've seen the imperative style above, but for declarative traversals, you can use match(). The following traversal answers the question: "Who created a project named 'lop' that was also created by someone who is 29 years old? Return the two creators.":
gremlin> g.V().match(
__.as('a').out('created').as('b'),
__.as('b').has('name', 'lop'),
__.as('b').in('created').as('c'),
__.as('c').has('age', 29)).
select('a','c').by('name')
==>[a:marko,c:marko]
==>[a:josh,c:marko]
==>[a:peter,c:marko]
We've also started expanding Gremlin to other languages beyond Java and currently have a pure Python representation as well, with javascript and other languages to hopefully follow.
TinkerPop doesn't really build "algorithms", though it has a few as reference implementations and certainly has the ability for users to develop their own which you can read about here:
I only briefly studied the graph code in foundry but an immediate use case that came into mind was for foundry to implement the Graph API interfaces so that a user could use our subgraph step:
to pop off a subgraph from a traversal into foundry at which point they could then run foundry's algorithms on it. Since you're talking about foundry scaling to graphs in the millions of vertices analysis over some local subgraph might be a nice fit.I'm not sure if there's other value to integration, but that's the first one that came to mind. Of course, if you implement the Graph API interfaces, you then get the ability to execute arbitrary Gremlin traversals over your "FoundryGraph" - you basically get a dynamic query language for free plus everything else the TinkerPop stack has. Note that implementing the Graph API is not a massive load of work - we've seen these interfaces implemented in several days worth of effort - you can read more about this here:
Anyway, I've probably provided plenty for you to digest at this point. Look forward to hearing if you have any further thoughts on the matter.
Take care,
Stephen