"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.
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.
> 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.
Data integration is cost prohibitive. In n years time, the task is "Let's move all of these data silos into a data lake housed in our singular data warehouse; and then synchronize and also copy data around to efficiently query it in one form or another"
Linked data enables data integration from day one: enables the linking of tragically-silo'd records within disparate databases
There are very very many systems that share linked data. Some only label some of the properties with URIs in templates. Some enable federated online querying.
When you develop a schema for only one application implementation, you're tragically limiting the future value of the data.
> There's nothing wrong with enabling linked data use cases, but you don't need RDF+SPARQL+OWL and the like to do that.
Can you name a property graph use case that cannot be solved with RDFS and SPARQL?
> 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.
TBH, I think the problem is that people don't understand the value in linking our data silos through URIs; and so they don't take the time to learn RDFS or JSON-LD (which is pretty simple and useful for very important things like SEO: search engine result cards come from linked data embedded in HTML attributes (RDFa, Microdata) or JSON-LD)
The action buttons to 'RSVP', 'Track Package', anf 'View Issue' on Gmail emails are schema.org JSON-LD.
Applications can use linked data in any part of the stack: the database, the messages on the message queue, in the UI.
You might take a look at all of the use cases that SOLID solves for and realize how much unnecessary re-work has gone into indexing structs and forms validation. These are all the same app with UIs for interlinked subclasses of https://schema.org/Thing with unique inferred properties and aggregations thereof.
> 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.
Without XSD, for example, we have no portable way to share complex fractions.
There's a compact representation of JSON-LD that minimizes record schema overhead (which gzip or lzma generally handle anyway)
https://lod-cloud.net is not a trivial or insignificant amount of linked data: there's real value in structuring property graphs with standard semantics.
Are our brains URI-labeled graphs? Nope, and we spend a ton of time talking to share data. Eventually, it's "well let's just get a spreadsheet and define some columns" for these property graph objects. And then, the other teams' spreadsheets have very similar columns with different labels and no portable datatypes (instead of URIs)
> 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.
“Easier” is completely subjective, no way you can demonstrate that.
RDF solves a much larger problem than just graph data model and query. It addresses data interchange on the web scale, using URIs, zero-cost merge, Linked Data etc.
> “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.
There's extra work to build general purpose frameworks for Linked Data. It may have been hard for any firm with limited resources to justify doing it the harder way (for collective returns)
Dokieli (SOLID (LDP,), WebID, W3C Web Annotations,) is a pretty cool - if deceptively simple-looking - showcase of what's possible with Linked Data; it just needs some CSS and a revenue model to pay for moderation.
https://dokie.li/
> When an owl:inverseOf production rule is defined, the inverse property triple is inferred by the reasoner either when adding or updating the store, or when selecting from the store. This is a "materialized relation"
> Schema.org - an RDFS vocabulary - defines, for example, https://schema.org/isPartOf as the inverse property of hasPart. If both are specified, it's not necessary to run another graph pattern query to traverse a directed relation in the other direction. (:book1 schema:hasPart ?o), (?o schema:isPartOf :book1), (?s schema:hasPart :chapter2)
> It's certainly possible to use RDFS and OWL to describe schema for and within neo4j property graphs; but there's no reasoner to e.g. infer inverse properties or do schema validation.
> Is there any RDF graph that neo4j cannot store? RDF has datatypes and languages for objects: you'd need to reify properties where datatypes and/or languages are specified (and you'd be re-implementing well-defined semantics)
> Can every neo4j graph be represented with RDF? Yes.
> RDF is a representation for graphs for which there are very many store implementations that are optimized for various use cases like insert and query performance.
> Comparing neo4j to a particular triplestore (with reasoning support) might be a more useful comparison given that all neo4j graphs can be expressed as RDF.
Currently it is relatively difficult to move data from one (open)cypher implementation to an other. Also as support is uneven for all features it is not so simple to get started on Neo4J and then evaluate e.g. TigerGraph if you find that Neo4J is not ideal for your usecase.
If your application only uses GQL then you could start on Neo4J but after two years in production cheaply move to a competitor. By just switching your backend and run your test cases etc. your data did not change, your queries remain the same, so evaluation is relatively straightforward.
I see this quite often in the SPARQL world. First few years of a product is with engine A, then some annoyance in production show up. Engines B-D are evaluated and a different one is chosen. Or sometimes both are run at once for different query workloads on the same data. Which is relatively cheap in the SPARQL environment. But because of custom engineering in the property graph world to move from engine 1 to engine 2 it is much more expensive in engineering hours.
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.
I don't suppose you could give me an example that demonstrates the clunkiness? I have not worked with SPARQL myself, but I'm very curious as someone who's been leveraging a graph database (dgraph)
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.
No, Mitre is not an FFRDC. Mitre is the administrator of a number (about 6 or 7) of FFRDCs which are run as an identifiable separate operating unit of a parent organization pursuant section 35 of the FAR.
Further more, Mitre has several positions posted right now that have nothing to do with FFRDCs and are in fact, just providing personnel for government projects. Splitting hairs on the terminology is a great game to play on the internet, but what would the average person call a company that produces no products and provides administrative, research, and engineering personnel on a basis of awarded contracts? The fact that Mitre employees seem to continually conflate their work as engineering contractors and their roles as FFDR administrators is a large part of my "mixed" experience in working with them.
And frankly; by your definition Honeywell would be an FFRDC which I don't think anyone would argue.
It's not like an agency can just go to MITRE and say "Hey, do you have any geospatial analysts, I need a few."
They have to jump through a lot of hoops to get to that point. It needs to be part of some research program or development project that they've convinced the sponsoring agency fits within the FFRDC charter and convinced MITRE and the COR they need to assist with, and awarded the tasking (beating everyone else trying to use that vehicle). MITRE and the COR get to decide which programs/projects, and they propose the staffing they think will help.
Sure it's inconvenient. It's inconvenient to staff anyone in the government. If I could have ordered employees like pizza on any staffing vehicle, I would have staffed them regardless of nearly anything else and never looked back.
Right now I can go on Mitre's website and look at their hot jobs postings. Right there is PM support in the army acquisition core, COTS integration, and several software engineer postings supporting BMD and THAAD. These are not part of their FFRDC line up. A cursory look shows about 1/3rd of current Mitre posting appear unrelated to FFRDCs. These sorts of positions will place Mitre employees in government offices and labs doing the same work along side other contractors hired by other contracting vehicles and along side government engineers doing the same work. It's not wrong, it's just the truth of the matter. There should be more firewalls legally speaking but they often times get broken down just so work can get done. I think that trying to dress Mitre up is not very helpful to someone trying to understand it from the outside. Statements like, "Mitre benefits most when you establish an ever closer relationship with the government agency and people therein. The higher the governmant authority you report to, the more valuable you become within Mitre," sound downright dystopian.
Mitre fulfills multiple rolls. It runs several research centers and fills government positions based on current government contract awards. They treat their employees well and pay a little above average for defense work. Mitre is heavily focused on technical positions or systems engineering. Mitre is a non-profit corporation and does not produce a commercial product. They are prohibited from engaging in manufacturing without special permission from the government.
Largely agreed. The tit-for-tat that can happen where positions get filled on programs having little to do with the FFRDC they're staffed under is a problem and it makes MITRE a target for other contractors who will complain to congress about, etc. It's an existential issue for them.
I've noticed federal agencies twist themselves into knots to try to get MITRE to staff something, and jump through the hoops, and really stretch the FFRDC charter, precisely because staffing anyone in the government is a shit show. I think the percieved value is a good chance of someone who isn't useless in the role and some stability.
I don't know who's fault that is, but I know MITRE hammers the line into PMs heads, you know, you're not a body shop. R&D/prototype work only.
At the same time, portfolio managers would be rewarded for forging new partnerships and getting new projects awarded via the FFRDC, even if they were kind of BS beyond a nice slide deck. Having projects to staff those PhDs on and getting kudos from the sponsors is what matters for advancement so...
I think we are pretty much in agreement. It really doesn't help how much the government is willing to stretch the definitions of R&D and System Engineering either.
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? ;)