gremlin-node integration?

[Marketcentric]

Wow. Nice work so far. It would be great to add another level of abstraction such as that provided by Gremlin (https://github.com/tinkerpop/gremlin/wiki) and the very nice node implementation of gremlin (https://github.com/entrendipity/gremlin-node) either via the BluePrints api or a direct implementation.

If you have not been watching Gremlin's recent activity, it is emerging as the most popular method querying/traversing/pattern matching most of the leading graph databases - for good reason. Marko Rodriguez, Gremlin's author is very approachable and helpful (http://thinkaurelius.com/team/).

Perhaps borrowing some of the pieces from gremlin-node would make this effort easier (although they interface directly to Java(!) libraries from node). Maybe they would be interested in a collaboration.

Adopting the Gremlin approach to graph traversal would enhance the awesomeness of Levelgraph as a performant backend for Node. My assessment of graphDB alternatives for Node is that there are few high speed options (i.e., those not accessing the graphdb via REST). Levelgraph could fill this void.

[mcollina]

I have looked at https://github.com/entrendipity/gremlin-node and I did not like the code, and how it has been written: it's full of *Sync stuff.
Node.js needs a different API, with a pure-async approach.
That's why It's really impossible to follow Gremlin closely in node.js.
I am trying to follow a similar approach though, look at #4.
I am looking for feedback in this area, if things became nice, we can look for standardizing it in its own package.

There is one more little problem: Gremlin treats "vertexes" as special entities, while in LevelGraph they do cannot exists on their own: Vertexes are only part of a graph.

Adopting the Gremlin approach to graph traversal would enhance the awesomeness of Levelgraph as a performant backend for Node. My assessment of graphDB alternatives for Node is that there are few high speed options (i.e., those not accessing the graphdb via REST). Levelgraph could fill this void.

That's the problem I am trying to solve :).

[Marketcentric]

yes, their Java (sync) mentality is a problem - but would be great to overcome with an async streaming approach (which is what you are working toward). It is a tough problem to implement Gremlin in an async world. The ability to have vertex and edge attributes can be problematic - maybe a clever solution could be developed.

Another possible alternative might be cypher (neo4j). They are about to roll out "labeling" (another layer of indexing) which I believe will be very useful in the practical graph world: http://blog.neo4j.org/2013/04/nodes-are-people-too.html http://bambuser.com/v/3461834

The cypher syntax (Neo4j) is focused on getting data rather how to get data (like Gremlin) and is pretty powerful. Maybe this would be better approach (and a more straightforward async implementation)...

[mcollina]

@Marketcentric exactly.

Could you please take some time to review #4?

Moreover, what are the most used features of Gremlin that I should port here?

[Marketcentric]

ahh, sorry I did not look at it in detail (and sorry for closing this too ... I have not left a comment before).

This looks great. I like the suggestions in the thread.

One of the most important features I think in gremlin is pattern matching (http://markorodriguez.com/2011/06/15/graph-pattern-matching-with-gremlin-1-1/) . I think your inclusion of variables in the fluent chain is a step in the right direction to achieving this. Some of Marko's pattern matching examples should be easy to implement - while others may be more difficult (i.e., recursion). I am not sure what is important here and what is not - I will have to think about it.

[Marketcentric]

I have a couple of examples written in iGraph (python) that I can port to use as examples here - when ready

[mcollina]

That can me super-nice. Chek out the latest changes in the fluent API pull-request, and let me know if you need something more.

It's still a work in progress, though.

[Marketcentric]

yes, good stuff! How can we do the "table" interim storage in Gremlin?

[mcollina]

It's not that hard. I hope I'll work on it this evening :).

[Marketcentric]

Great!

[mcollina]

Hi @Marketcentric, the 'gremlin style' API is published on NPM.
Let me know how your experiments go.

[Marketcentric]

Great. Will do. I look forward to it.

[Marketcentric]

Hi @mcollina, have you given some thought to how properties might be assigned, used or queried such as commonly found in Directed Property Graphs? or should every vertex property be made into a separate node? Also, I find edge properties to be very useful. Any clever thoughts?

[mcollina]

There is no storage of a 'node' in LevelGraph, it knows only about triples. So, in order to create some properties you have to define them through triples. However, it should also be possible to store the properties directly in the key-value store.

As for other methods, what do you need? Grouping? Counting? If you can make some example, I'll try to add the support for them.

[Marketcentric]

yes, my thoughts are that using a clever approach, the properties could be represented as triples pointing to the vertex, such as "member_of" predicate. I we can then use them in queries where the "member_of" properties are handled in the background. Something to think about.

Grouping, counting...not sure yet. "Neighbors" would be handy (for a given vertex return a list of connected vertices). "Incident" is also handy (all the edges for a given vertex) - in a triple these two would most likely be the same. FYI - here is a list of methods I use with iGraph (http://igraph.sourceforge.net/doc/python/igraph.GraphBase-class.html) - 99% are specialized but interesting none the less.

[Marketcentric]

fyi - http://tm.durusau.net/?p=41113

[mcollina]

yes, my thoughts are that using a clever approach, the properties could be represented as triples pointing to the vertex, such as "member_of" predicate. I we can then use them in queries where the "member_of" properties are handled in the background. Something to think about.

Yes, but for me it's another lib.
It should be feasible to implement an ORM-like library on top of LevelGraph.

Grouping, counting...not sure yet. "Neighbors" would be handy (for a given vertex return a list of connected vertices). "Incident" is also handy (all the edges for a given vertex) - in a triple these two would most likely be the same. FYI - here is a list of methods I use with iGraph (http://igraph.sourceforge.net/doc/python/igraph.GraphBase-class.html) - 99% are specialized but interesting none the less.

You can easily get the 'Neighbors' and "Incident" using a basic get:

db.get({ subject: "myvertext" }, function (err, results) { .... });
db.get({ object: "myvertext" }, function (err, results) { .... });

I think all the basic operators are there, but a nicer and better-documented API is needed.

[Marketcentric]

Thanks for the .get -> neighbors relationship (I should have thought more about this before asking)

[mcollina]

I am closing this as there is not much more discussion on this issue.

@Marketcentric if you have more question, feel free to reopen!