kennybastani

Great post!

The benchmarks really depend on the classifier used. The explanation in this blog post is more about the natural language parsing model. I thought that part up based on books I read from thought leaders (Gleick, Kurzweil, J. Hawkins). The value I'm hoping to provide is less in my own research and more on the use of a graph database. I'll leave the research part to fine people like you.

As for benchmarks, I've seen differences at different sample sizes during training. The model seems to do better with more training examples. Though that increases the number of features and the dimension of the vectors when calculating cosine similarity. I'm really hoping to attract more input like this as Graphify grows as an open source project. Please feel free to get in touch with me. Skype is kenny.bastani.

I'll post benchmarks in the next blog post.

Great question. To be honest, I used deep learning algorithms as a metaphor into Neo4j's property graph data model. Graph databases like Neo4j store data as a graph, which is a similar data structure to a neural network. I store weights in the relationships based on the frequency that a feature has been matched from the low-level representations near the bottom of the tree, to higher-level representations.

So there are two parts, there is building a natural language parsing model and then there is a Vector Space Model classifier that uses TF-IDF weights as vectors to calculate the cosine similarity between inputs.

I explain more about the high-level idea here: http://bit.ly/1lMjSm5

Let it be known that I've arrived at most of this stuff by means of intuition and graph data modeling in Neo4j. I'm a hobbyist when it comes to the machine learning stuff. My goal is to show how amazing a combined application/persistency solution, like a Neo4j extension, is for solving these kind of machine learning problems.

People smarter than me should take a look at it to solve similar problems.

Neo4j is an open source graph database. The community and enterprise editions can be used in production without a license (including HA clustering). Licensing is required when you choose not to open source your code that uses Neo4j. When you have a commercial application of Neo4j, the price for the license is well justified so your customers are not impacted when an issue arises in your implementation. Most resolutions are a matter of creating an unmanaged extension that runs code embedded in the JVM.

1. Adding nodes and relationships in Neo4j does not have to be slow. It really depends on how you are loading that data in. Neo4j provides many options for data import and a transactional endpoint over HTTP for batching transactions and decreasing disk write overhead.

2. The reason Neo4j is the only database that allows you to query a path is the same reason that setting up clustering or sharding is difficult. If your graph is complex then the problem is "How do I split up these subgraphs into shards so that traversals don't have to traverse across shards?" -- Building a giant adjacency list and using that as a traversal index is a clever idea, I must admit. :)

From your post: "The biggest issue was that we had data in the graph, that just didn’t feel right in the graph instead of a relational DB." -- What exactly was the problem other than managing complexity? I read through your posts and I didn't see any mention to some of the technical aspects of your issues with Neo4j. Was your data just so large that going the relational table route gave you a better understanding of this complexity?