The Future Is Big Graphs: A Community View on Graph Processing Systems
I have spent the last 7 years building ontologies (knowledge bases), small and large. Like with most tech articles, this one is pushing a very specific point of view that is relevant to megacorporations but certainly not to most companies that would benefit from the deployment of graph-structured knowledge bases.<p>Unless a company has tons of extra cash to burn using technologies like neo4j, Spark, etc., they are better off just building an ontology on top of their existing datastores.<p>The work on the semantic web in the 2000s added a lot of valuable ideas and I see a tendency to downplay these ideas in favor of new technologies. Storing relationships as RDF triples and building indices that are well-suited to your queries will be good enough for the majority of people who need an ontology.<p>I have found that graph-based systems don&#x27;t model time well. When you are building a knowledge base, you often need to understand how knowledge has changed over time. You may want to relate facts across time or understand what the state of knowledge was within a given period of time. This usually takes extra work.<p>Another thing that I have found these graph-based systems to do poorly is the management of storage classes for different types of data. If you are building a graph knowledge base, not all the information in your knowledge base will be consumed in the same way. If your knowledge base is sufficiently large, you will want to store less frequently accessed data on cheaper storage (e.g. HDD or even object storage like S3) and hotter data on more expensive storage (SSD or even maybe keep it in memory). I have always had to write this code by myself and haven&#x27;t found a tool that helps to manage this very importance concern in ontology building.<p>That turned into a bit of a ramble, but damn ontologies are cool. :)