"just" is doing a lot of work in this construction. Regardless what a person's constellation of privileges is, it always takes an incredible amount of grinding and that's pretty damn cool / laudable / praiseworthy all by itself.
love graph or hate it, you can't really be a well-rounded dev without some knowledge of how graphs work. Forget even databases, it's one of the basic data structures all the way back from the beginnings of computer science and math courses. They're a pretty elegant way of thinking of and working with data.
> “Easier” is completely subjective, no way you can demonstrate that.
I agree it's subjective. While there's no exact measurement for this sort of thing, the proxy measure people usually use is adoption; and if you look into for example Cypher vs. SPARQL adoption, Neo4j vs. RDF store adoption, people are basically voting with their feet.
From my personal experiences developing software with both, I've found property graphs much simpler and a better map for how people think of data.
It's true that RDF tries to solve data interchange on the web scale. That's what it was designed for. But the original design vision, in my view, hasn't come to fruition. There are bits and pieces that have been adopted to great effect (things like RDF microformats for tagging HTML docs) but nothing like what the vision was.
> Can you name a property graph use case that cannot be solved with RDFS and SPARQL?
No - that's not the point. Of course you can do it with RDFS + SPARQL. For that matter you could do it with redis. Fully beside the point.
What's important is what the more fluent and easy way to do things is. People vote with their feet, and property graphs are demonstrably easier to work with for most use cases.
Linked Data tends to live in a semantic web world that has a lot of open world assumptions. While there are a few systems like this out there, there aren't many. More practically focused systems collapse this worldview down into a much simpler model, and property graphs suit just fine.
There's nothing wrong with enabling linked data use cases, but you don't need RDF+SPARQL+OWL and the like to do that.
The "semantic web stack" I think has been shown by time and implementation experience to be an elegant set of standards and solutions for problems that very few real world systems want to tackle. In the intervening 2 full generations of tech development that have happened since a lot of those standards were born, some of the underlying stuff too (most particularly XML and XML-NS) went from indispensable to just plain irritating.
SPARQL is purpose built for the RDF world where you're mixing and matching a zillion different vocabularies, all of which have to be painstakingly declared and name spaced every time.
For most of us working not on the "semantic web", we typically only have 1-2 vocabularies, which is our data model, and SPARQL is super clunky to use.
Why would you want to imprint this stuff into your long term memory? Google is an extra brain with effectively infinite free space, why would I want to use mine?
This answer is not correct. MITRE is not a staffing agency, but a special purpose entity called a Federally Funded Research and Development Center (FFRDC). The other answer in this thread is better -- a key thing MITRE gets pushback from other entities about is whether or not it is ideally suited to fill some government need, or whether it's just an anticompetitive way of awarding a contract to one body instead of letting it out as the government would normally do.
Those pressures tend to focus and specialize MITRE on issues which require objectivity and high levels of expertise in systems engineering sub-areas. They are most definitely not a staffing agency, although the government can (and sometimes does) misuse them to this effect.
> What's stopping you from having one table that contains A and what A points to? So you only have 2 tables?
So you can do that. Suppose you denormalize the graph into a single table. Either your denormalizing, and to connect A to many B's you have to duplicate A's data in the table, or you have the constraint that the A -> B link can only have a cardinality of 1.
This would be not a good choice for nodes with many relationships to other things, say for example "Person friended Person". It might work if the cardinality was somewhat capped, like say for example "Customer ordered Product" (a common denormalization).
For a real application, you're not going to have 1 of these. You're going to end up with 20+.
> I'm yet to be convinced that a problem can't be reshaped and mapped on a traditional RDMS and yet remain performant.
Any problem can be re-shaped to any database formalism. For that matter we can re-shape everything we're discussing for a straight K/V store like Redis. The expressive power of a database isn't at issue, because any database can store any dataset. Period.
More relevant questions are about performance and about conceptual fit for the problem. First on performance, have a look at the performance growth graph here:
If you reason from the computer science of how these systems work, this result makes sense.
From the conceptual simplicity standpoint, that's kind of a matter of personal taste and application. Can you do it all with an RDBMS? Sure. But all of these different tech niches exist because sometimes you want more than one kind of tool for the wide variety of jobs you need to accomplish.
I'd argue that it's conceptually simpler to think of your graph as nodes and relationships, rather than to remember each time which node/rel set was denormalized into one table, which node label was split out into its own separate table, what that join table was, how the key naming differed between tables, etc. etc. etc. (Because once you have a non-trivial sized graph, you'll have a lot of these, and maybe you made different decisions at different spots).
The prize if you do remember all of that is that you get to write quite complex SQL to join together the datastructures for non-trivial traversals, because substantial graph use cases that you can answer on the basis of a single denormalized table are going to be rare.
In terms of conceptual simplicity, compare a recursive join SQL query to a cypher snippet like "MATCH (user:User {login:'bob'})-[:KNOWS*..5]->(foaf)". The equivalent SQL is...difficult.
It's just a "use the right tool for the job" situation at its core.
Many of us who have worked in the graph database space have been tempted to use the graph abstractions on top of a relational database. It's a reasonable first step. Tables are nodes, join tables are relationships and so forth.
It's also however a bit of a dead end once you go beyond the basics. The costs of joins get worse the deeper you go, and "hundreds of milliseconds" is at least an order of magnitude slower than what Neo4j would do for you.
Once you take that major performance penalty, and then layer it into more complex graph algorithms or analytics, it gets really, really painful quickly. Granted, you might not notice this if you never needed to go further than 2-3 hops in a graph. But once you start working with graphs you're not going to want to stick to such basics.
More technical detail on the difference between a graph abstraction on top of another database, and a native graph database, can be found here:
$100M is likely a placeholder amount. They're filing to go public and can adjust that figure later, it's not that strange to do so. I don't think $100M means much there, and relative to their overall valuation if $100M is all they wanted they'd likely have other options.
Can you expand on major points of how this will make the content different, (for example, Wikipedia is curated and non-notable people pages get thrown out, so if you're reading all of the web, presumably you'd know about non-notable people) -- and why it's better?
Wanna thread other known attempts at this? Maybe someone will jump in with extra detail about how these approaches are different, or what extra value we'd expect.
That anchor effect of being slow is what I meant by "installment payments". Financially, if you have enough debt you can make $300k a year and still live in a crappy apartment, because all of your income (in this weird metaphor, that's your available dev hours) are being spent on debt (fixing things that wouldn't have occurred had you not had the debt)
No, I wouldn't put it that way. It's not a problem to be embraced, it's just another variable to manage.
Just as there is the trilemma of "better, faster, cheaper: pick 2" there are others as well. Speed and tech debt are balanced against one another. It's not that I think we should embrace tech debt. I actually rather hate it. But sometimes I'm willing to trade to get to a business objective that is not related to technical elegance.
In terms of how to pay it off, it may sound like a cop-out but it just depends. The core problem is that things are always changing and we can't predict the future. So staying supple and flexible I think is the way to go. Pay off as much of it as you can when you can, but I think the main point for me is to keep the eyes on some business objective (where tech debt appears as only one variable in the equation) -- the main point is not to keep your eyes on the tech debt all the time.
A lot of those java built-in libraries personally, I think they make easy things easy. Will it Just Work™ Out Of The Box™?
Hey we're engineers right? We know that the right answer to every question, bar none is "it depends on what you're trying to do" right? ;)