Why Young Developers Don’t Get Knowledge Graphs | Hacker News Reader

Why Young Developers Don’t Get Knowledge Graphs

datanami.com

25 pointsgibsonf115 comments

> And there’s not a single young programmer that cares about that. Seriously. You’re young, you want to do a fun project, your managers are saying, in three months I need this thing done. You do whatever you want to do. Well, they get it done. And then you have new a data silo.

Ironically in this one quote that is the basis for the entire article and headline claim, it’s not even the young programmer at fault. It’s the manager. They set a tight deadline, they want it done in three months, you do what you have to do, etc. It’s the manager’s responsibility in this case to specify they want it hooked up to some kind of data mesh.

I’ll directly refute the whole article by saying that in my experience as a young developer, I try to suggest doing projects in a more “strategic” “long-term” way even at the expense of requiring a bit more time to refactor and complete, and my grizzled 40-year old manager shuts me down.

Because he’s being judged by upper management on how many features he ships and how much the product has advanced, and not on the level of crust or techdebt in the stack. It would look bad for his release velocity.

But I guess that’s why I’ve never heard of AllegroGraph. Because they’re busy selling to 40-year-olds who are set in their ways and don’t want to rock the boat, instead of new talent that is still adaptable and searching for new ideas.

I was going to comment on the same part of the article, but you’ve summarized my thoughts perfectly.

Especially being a manager (the CEO), you’d think he’d be more self-aware of the problem while spelling it out so clearly.

The less experienced a person is, the shorter their deadlines should be and the narrower their scope.

to what ends? to milking every drop of productivity out of them? to snubbing their agency & crushing their soul?

wrestling with big things, bringing stuff together, toil, is not for everyone, whatever level of experience. but our industry guards constantly against anything but the safe path, actively obstructs good & interesting efforts, relies on charisma & personality to get permissiom to step beyond the safe & apparent paths. most companies indeed don't really need or benefit from truly exceptional work, from harder battles being engaged in & fought, so I'm sympathetic. but it's no less of a waste of potential, and this industry lacks good testing grounds for us worker's real mettle.

I’m not sure what you think I’m saying.

In general it takes more experience and internal organization skills to do larger, broader, longer timeline, less well defined projects and finish them.

In my experience, the best way to get there is to start smaller, and get feedback sooner.

This is true with everything: writing, music, film, home improvement ... you don’t learn to surf on 10 ft waves.

Edit: I’ve seen far more people be discouraged and burned out by incompletable (for them) projects that are unsuccessful than from doing small and well defined tasks that aren’t creative enough.

>The problem with younger developers, he explains, is that they’re usually..

This article reeks of ageism.

RDF and other semantic tools died (sort of) because of very pragmatic reasons: it's extremely expensive and semantic data are hard to collect and validate.

AI that make “almost right” predictions and costs much less is enough almost for all.

Are there any Open Source, free-to-use Graph Databases that young developers can access and play and learn with?

Are there standards on how a graph database can be queried or interfaced with, that all/most implementations adhere to?

IMHO, SQL took off primarily for those reasons. Widespread use, common standards, and implementations that were easy to approach cemented SQL as the standard used and understood by old and new developers alike.

Wikidata[0] is a freely available knowledge graph. You can even query it online [1]

[0] https://www.wikidata.org/wiki/Wikidata:Main_Page

[1] https://query.wikidata.org/

I started using https://github.com/athensresearch/athens I quickly fill with lot of information, I miss code feauteres like markdown github fencing ```, but so far is great, searh is fast, adding new data is good, refereces links and back links really adds to the information, and the daily page is useful. I just would like to have more features about code

It has a developer mode, where you can run clojuru to query the nodes, I'm starting to use it to create code references between nodes, nothing useeful, but you definitevely can start playing with it

3 of the top 5 graph databases on db-engines are open-source.

https://db-engines.com/en/ranking/graph+dbms

As for standards, absolutely. Gremlin and TinkerPop are both common ways to interface with Graph Databases that work across many different vendors.

That said, IMHO graph databases are pretty niche. SQL took off because the ability to normalize data when you store it and then relate it as needed when you query while still getting great performance for large-ish data (thanks to indices and query optimizers) is really powerful.

I think the best open-source graphdb, also used for Amazon Neptune, is blazegraph [1]

For true data interoperability, as opposed to the silo data models required for property graph databases, the RDF w3c standard with SPARQL [2] is the industry standard. The new global API made possible with the Solid project [3] by Tim Berners-lee uses RDF

[1] https://blazegraph.com/ [2] https://en.wikipedia.org/wiki/SPARQL and https://www.w3.org/TR/sparql11-query/ [3] https://solidproject.org/

I've not heard of SPARQL, after digging around the wiki page it looks like it's a good idea which hasn't caught on much (of the top graph 5 databases [0] only Virtuoso supports it). What I find particularly interesting is it appears to be a universal query language, to replace SQL and XQuery too.. so we should be seeing it used everywhere.

With respect to graph databases, the industry standard is Tinkerpop-Gremlin. Of the top 5 graph databases 4 support it, coincidentally the only one not to support it is Virtuoso. It's not like any other query language I've used, there's quite a bit of learning involved and the docs[1] sometimes lack sufficient detail, there's multiple ways of achieving the same result and unfortunately, some implementations don't provide the full language (eg Cosmos Graph [2] doesn't support the Match step or lambdas). But slowly with handy resources like (Practical Gremlin)[3] and trial and error, you can do some very sophisticated things.

[0]: https://db-engines.com/en/ranking/graph+dbms [1]: https://tinkerpop.apache.org/docs/3.5.1/reference/ [2]: https://docs.microsoft.com/en-us/azure/cosmos-db/gremlin-sup... [3]: http://www.kelvinlawrence.net/book/PracticalGremlin.html

The issue is that yes, property graphs are very popular. And also yes, they create yet another data silo just as the old sql databases do as you make a custom data model each time.

SPARQL and RDF are powering the new decentralized web with a global interoperable api in the form of Solid (by the inventor of the web) - you'll likely be hearing a lot more about this as it rolls out commercially in the coming months

didn't amazon buy out blazegraph? eg no more active open source effort?

Reply on news.ycombinator.com