On a somewhat lower level aspect than what Jans discussed, one the fundamental differences between property graphs and RDF stores is the way data is stored. Most RDF graphs are persisted as a string table containing URIs and literals and a single quad table of string table IDs, along with a variety of indices that make lookups in the quad table efficient. Bases on this structure, SPARQL engines optimize for efficient joins and maximum performance on wide-ranging graph patterns. On the other hand, the fundamental storage unit of most property graphs is the node, and nodes store their adjacency lists, which optimizes for a query pattern that starts with a small set of nodes and follows a set of consecutive edges to find a solution. Any sort of path calculations, which are central to property graph queries, cannot be expressed in SPARQL without the use of non-standard syntax (magic predicates or something like Stardog's PATH queries). This fundamental difference can be a driver for the adoption of specific approach (RDF vs LPG).
Issue #1: Construction of an ontology/taxonomy vs. solving the problem at hand. Obvious solution: have a well developed ontology before developing any solution to a problem. Better solution: decouple the ontology development from the solving of problems. [i.e. categorical schema mapping] It would have been nice if the interview with Ryan Wisnesky could have covered how the application of their technology can be applied to the decoupling of ontology development from rapid development. (Essentially rapid development discovers domain specific structures and its attendant ontology.)
On a somewhat lower level aspect than what Jans discussed, one the fundamental differences between property graphs and RDF stores is the way data is stored. Most RDF graphs are persisted as a string table containing URIs and literals and a single quad table of string table IDs, along with a variety of indices that make lookups in the quad table efficient. Bases on this structure, SPARQL engines optimize for efficient joins and maximum performance on wide-ranging graph patterns. On the other hand, the fundamental storage unit of most property graphs is the node, and nodes store their adjacency lists, which optimizes for a query pattern that starts with a small set of nodes and follows a set of consecutive edges to find a solution. Any sort of path calculations, which are central to property graph queries, cannot be expressed in SPARQL without the use of non-standard syntax (magic predicates or something like Stardog's PATH queries). This fundamental difference can be a driver for the adoption of specific approach (RDF vs LPG).
Issue #1: Construction of an ontology/taxonomy vs. solving the problem at hand.
Obvious solution: have a well developed ontology before developing any solution to a problem.
Better solution: decouple the ontology development from the solving of problems. [i.e. categorical schema mapping]
It would have been nice if the interview with Ryan Wisnesky could have covered how the application of their technology can be applied to the decoupling of ontology development from rapid development. (Essentially rapid development discovers domain specific structures and its attendant ontology.)