29 ms·

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

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.

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.