Hi, So I would tend to say that it's best to store everything as > (node)-[edge]->[node] relationship, i.e., which perfectly aligns with the > basic structure of an RDF statement (simple subject-predicate-object > sentence). Then it doesn't matter, whether you are querying for statements > with literal values or statements with resource values. Moreover, you have > the opportunity to (better) deal with metadata (external context, ...) > about statements, since you have the opportunity to also add properties at > the edges (relationships), i.e., you can do, .e.g., statement-based > versioning, clustering/partitioning (e.g. รก la Named Graphs) or introduce > qualified attributes for ordering or simply add a unique identifier for the > statement itself. So you can design a (graph) data model with more > comprehensive capabilities then RDF ;) (because of the flexibility of the > property graph model). Finally, you can create indices as necessary, e.g., > for resource (nodes), for statements (relationships) or for literals to > speed up the queries. >
As far as I understood, that is exactly how the "Sail Ouplementation <https://github.com/tinkerpop/blueprints/wiki/Sail-Ouplementation>" from the Blueprints project that I used in the extension maps the RDF data. The problem in general is, that once you decided which RDF properties go as edges and which go into properties of nodes it is very complicated to return correct SPARQL results. The problem with the "(node)-[edge]->[node]" approach seems to be the resulting graph size. Regards, Niclas -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
