semantic web - Graph Database: TinkerPop/Blueprints vs W3C Linked data -


looking infrastructure network analysis heterogeneous (multiple node types (multi-mode), multiple edge type (multi-relation) , multiple descriptive features (multi-featured)) networks, i've noticed there 2 standard stacks in graph database world:

on 1 hand have thinkpop/blueprint property graph model. supported neo4j, orientdb graphdb, dex, titan, infinitegraph, etc.

the tinkerpop stack includes blueprint property graph model interface, gremlin graph traversal language, , furnace graph algorithms package.

on other hand have w3c's linked data technology stack, supported allegrograph, 4store, oracle database semantic technologies, owlim, systap bigdata, etc.

semantic data represented using rdf/rdfs/owl, , can queried using sparql on top offers rules , reasoning capabilities.

now, suppose want represent heterogeneous data in graph database, , analyse such data (statistics, relations discovery, structure, evolution, etc.) (i know these terms wide , vague) - what relative strengths of each model various types of network analysis tasks? these 2 models complement each other?

couple things, exemplars of linked data stacks triple stores. start building linked data application first getting triple store set up, calling database linked data stack incorrect imo. that's incomplete list of triple stores, there sesame, jena, mulgara, , stardog. sesame , jena kind of pull double duty, they're 2 de-facto standard java apis semantic web, both provide triple stores come bundled apis. know both cray , ibm working on triple stores, don't know either @ point. know stardog works tinkerpop stack , it's drop in , start writing gremlin queries against rdf.

i think strengths of rdf/owl 1) real query language 2) they're w3c standards , 3) reasoning, if triple store supports it, free (more or less -- still have write ontology).

with rdf/owl/sparql being standards, makes quite easy pick , move new triple store different feature set should need to, data in common format understands , application logic encoded queries portable. , in cases, you'd writing against either sesame or jena apis, or working on sparql protocol, might need change config/init. think that's big win in prototyping phases.

i think rdf/owl combined w/ reasoning , kinds of complex sparql queries can create new sparql 1.1 suit building complicated analytic applications. also, think impression people have rdf triple stores don't scale no longer correct. triple stores @ point scale billions of triples , have competitive throughput numbers well.

so based on think might doing, think semweb might better bet you. did similar project few years using rdf & rdfs backend fronted simple pylons based webapp , happy results.


Comments

Popular posts from this blog

c# - SVN Error : "svnadmin: E205000: Too many arguments" -

c# - Copy ObservableCollection to another ObservableCollection -

All overlapping substrings matching a java regex -