moxious

they say good technology makes "easy things easy, and hard things possible".

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? ;)

"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.

The secret sauce has never been secret

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.

> Still a more grounded GQL will allow Neo4j competitors to gain on them.

Can you expand on this? What do you mean?

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?

Hi! I'm the original author of this post. Happy to field any questions if there are any.

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.