6 ms·

There are two kinds of graph databases, property graph and rdf semantic graph. Neo 4J is the former, which I don't think is that useful in primarily only showi

There are two kinds of graph databases, property graph and rdf semantic graph. Neo 4J is the former, which I don't think is that useful in primarily only showing some kind of relation between things. The rdf semantic graph approach, however, captures the semantics of the relationship allowing inference and queries not normally possible with rdbms. It's an easier cultural change in thinking from rdbms to property graph, but also not a huge improvement in terms of what you can do vs an rdbms. Going with a full semantic graph where the relationship is also represented by a node with unlimited relationships, and moving and thinking in hierarchies and inference, is a complete cultural change with an impressive productivity and capability improvement not possible with rdbms. Allegrograph is a good example of a semantic graph which can handle trillions of triples.

castlecrasher2 8y ago
Do you have a good example of when an RDF is superior? My looking into RDF's was summarized as "way too complex for little gain" but I admittedly was looking at it through my SQL/Neo4j lens.
- 131012 8y ago
  I'm working on a project with old school RDF & semantic web, and I tend to concur with you. I often miss my usual RDBMS. Maybe it's the way my data is structured, but any complex display of data quickly becomes a weird maze of async calls. I'd be happy to be proven wrong, I love graphs!
  - gibsonf1 8y ago
    You have to think completely differently from rdbms to use graph well. It's a hard cultural change to make.
    - technige 8y ago
      True, but a very worthwhile one. Before getting into Neo4j (and later joining the company), I'd worked with SQL databases a lot and, at one point, as a DBA. I spent the first few months trying to draw direct analogies between graphs and tables but after a while realised that I needed to "unlearn" a load of what I thought I already knew. It's now pretty refreshing to be able to look from a higher vantage point at the different types of data store available, and work out which is the right one for each job. It turns out that the graph is actually the best solution more often than you'd think!
  - segmondy 8y ago
    Consider using the correct tool too http://www.swi-prolog.org/pldoc/man?section=semweb-scalability http://www.swi-prolog.org/pldoc/man?section=semweb-scalabili... https://franz.com/agraph/support/documentation/current/lisp-quickstart.html https://franz.com/agraph/support/documentation/current/lisp-...
- gibsonf1 8y ago
  Any time you're working with information, which tends to have hierarchical relationships and classification schemes. And usually a particular type of thing can belong to many different hierarchies, so you can find a type, and then traverse the graph among all hierarchies that type belongs to to find results. So you can easily take something, find it's type, indicate what target type things you want to understand it's related to, and get a result. And this can all be done on the fly. Doing this with the incredible number of joins you would have to use with rdbms would be unfeasible with changing hierarchies. The other REALLY big advantage, the data model never changes! I literally let the graph, to a certain extent, write the code (that is, code is generated based on graph relationships on the fly) And finally, you can have everything in the "same" location, you are always working with an "information" lake - no need to have many many different tables.
  - castlecrasher2 8y ago
    I appreciate your response, and forgive me for asking the same question, but do you have a more tangible example? I'm particularly interested in understanding more by seeing something like the disaster SQL for traversing hierarchies and comparing it to an RDF implementation.
liminal 8y ago
Which RDF semantic graph databases do you recommend for production?
- lolive 8y ago
  Virtuoso. Or Stardog if you want advanced inference. (GraphDB is also in the field).
hobofan 8y ago
I'm not sure that this is a necessary distinction. I don't see anything about a semantic graph database that would prevent it from being built on top of a graph database like Neo4j (and we are doing kind of that at my current company).
JPKab 8y ago
I've worked extensively with RDF triple stores of various types in the past. Not impressed. Too academic, too expensive, bad performance. SPARQL is one of the worst query languages I've seen. We can thank the W3C for that. Using it for a few weeks makes it clear that it was born in an ivory tower committee rather than engineering experience.

castlecrasher2 8y ago

Do you have a good example of when an RDF is superior? My looking into RDF's was summarized as "way too complex for little gain" but I admittedly was looking at it through my SQL/Neo4j lens.

131012 8y ago
I'm working on a project with old school RDF & semantic web, and I tend to concur with you. I often miss my usual RDBMS. Maybe it's the way my data is structured, but any complex display of data quickly becomes a weird maze of async calls. I'd be happy to be proven wrong, I love graphs!
- gibsonf1 8y ago
  You have to think completely differently from rdbms to use graph well. It's a hard cultural change to make.
  - technige 8y ago
    True, but a very worthwhile one. Before getting into Neo4j (and later joining the company), I'd worked with SQL databases a lot and, at one point, as a DBA. I spent the first few months trying to draw direct analogies between graphs and tables but after a while realised that I needed to "unlearn" a load of what I thought I already knew. It's now pretty refreshing to be able to look from a higher vantage point at the different types of data store available, and work out which is the right one for each job. It turns out that the graph is actually the best solution more often than you'd think!
- segmondy 8y ago
  Consider using the correct tool too http://www.swi-prolog.org/pldoc/man?section=semweb-scalability http://www.swi-prolog.org/pldoc/man?section=semweb-scalabili... https://franz.com/agraph/support/documentation/current/lisp-quickstart.html https://franz.com/agraph/support/documentation/current/lisp-...
gibsonf1 8y ago
Any time you're working with information, which tends to have hierarchical relationships and classification schemes. And usually a particular type of thing can belong to many different hierarchies, so you can find a type, and then traverse the graph among all hierarchies that type belongs to to find results. So you can easily take something, find it's type, indicate what target type things you want to understand it's related to, and get a result. And this can all be done on the fly. Doing this with the incredible number of joins you would have to use with rdbms would be unfeasible with changing hierarchies. The other REALLY big advantage, the data model never changes! I literally let the graph, to a certain extent, write the code (that is, code is generated based on graph relationships on the fly) And finally, you can have everything in the "same" location, you are always working with an "information" lake - no need to have many many different tables.
- castlecrasher2 8y ago
  I appreciate your response, and forgive me for asking the same question, but do you have a more tangible example? I'm particularly interested in understanding more by seeing something like the disaster SQL for traversing hierarchies and comparing it to an RDF implementation.

liminal 8y ago

Which RDF semantic graph databases do you recommend for production?

lolive 8y ago
Virtuoso. Or Stardog if you want advanced inference. (GraphDB is also in the field).

hobofan 8y ago

I'm not sure that this is a necessary distinction. I don't see anything about a semantic graph database that would prevent it from being built on top of a graph database like Neo4j (and we are doing kind of that at my current company).

JPKab 8y ago

I've worked extensively with RDF triple stores of various types in the past. Not impressed. Too academic, too expensive, bad performance. SPARQL is one of the worst query languages I've seen. We can thank the W3C for that. Using it for a few weeks makes it clear that it was born in an ivory tower committee rather than engineering experience.