It postulates that semantic models delivered in areas where SQL couldn't, that what hinders their broader adoption is the user-interface/querying layer (i.e. too few people adopting SPARQL), and suggests that a new dialect of SQL could solve that, especially because LLMs are so good at producing SQL.
> Knowledge graphs and semantic models promised something enterprises desperately needed: governed meaning, reusable business logic, and explicit relationships across complex data landscapes. And technically, they delivered.
For me that's the main argument: what is the value proposition for knowledge graphs and semantic models when you already have an established relational datamodel? Some argue that the graph's fluid schema brings flexibility benefits, but looking at the problem in its entirety (considering the effort to define and formalise the model, the effort to store content, the effort to retrieve it, deliberately keeping the dev/sysops and tooling out of the way), what you spare at formalisation/insertion stages, you pay back at retrieval (or, if you don't validate or constrain your inputs, expect surprises as an output).
That's where I stand right now:
- convince me that relational models can't express as powerful constructs and concepts as semantic ones
- convince me that "fluidity" in the model don't come with more troubles down the road than benefits
> Knowledge graphs exist. […] And almost nobody queries them directly. Not because the models are wrong. Not because the semantics aren’t useful. But because accessing them requires SPARQL
Or, guess what, a similar outcome can be explained differently: perhaps it's not SPARQL that's too difficult to grasp. Perhaps the alleged benefits of semantic models just do not materialise in practice, and there is no point to engage with SPARQL to begin with because there's no payoff at the end of it. I think the data processing ecosystem is sufficiently vivid and diverse to demonstrate that users have no problem embracing new technologies and languages as the need arise (sed/grep/…, hadoop/spark, pandas/polars/duckdb, decades of ETLs in graphical/textual forms, …)
Then the article is full of weird takes, especially within the "Hidden Cost" section, that I don't feel like commenting. Nor why their "SQL with semantic ontologies" is just syntactic sugar to save your editor from writing joins on your behalf?
Also as someone doing my own implementation at the moment, I expect that there is a big relational database backing the MELT store, just the graph aspect is functionally a big RAG interface on top of it acting as a search cache, not itself the data store.