Hello, as far as i understand RDF doesn't use object internal structure, so there is no schema,and modelling is based on vocabulary like english words. It seems natural and simple but why its not widely used? Its the many join perfomance cost? Or RDF adds complexity making modelling and quering hard?

There's a long history, and many reasons 🙂

To start with, when it was first released, the only formal serialization of RDF was RDF/XML. Consequently, a lot of people thought it was just a type of XML, and a complex one at that. They'd walk away from it before they understood it

n3 was around, but it wasn't an official spec. Eventually Turtle came along, which addressed some of those problems, but by then, a lot of people were already against RDF

Since then, what I've observed is that many people have never been exposed to graph models, and don't follow how to use graph query languages (it doesn't help that Facebook/Meta released "GraphQL" which is not a general purpose graph query language)

Not being exposed to it, people aren't interested in learning it. They're very resistant. I encounter a lot of this. Why? Well, it's just because they haven't heard of it, and it doesn't conform to what they know, and why invest all that time and effort into something that doesn't have a lot of market penetration?

They also can't see the immediate benefits. I have been mapping my organization's RDBMS data into a graph, and after taking initial steps, I sat down with the data architect of the original system. I showed him everything I'd done. His response was, "What does this offer that we don't already do?" I tried to explain that it was simpler, and the graph database was optimized for walking across the data, but he didn't see any benefits at all, and dismissed me. A few weeks later, I was working with a group who were talking about how they could cache transitive closure data that comes out of the database, and how best to do it. I was confused and asked them why they would not just query for it. They challenged me, "Well how long would that take?" I felt a bit defensive, and said that it was fast. (My experience on my notebook had been around 800ms, but if I asked for the entire dataset, then I'd seen it take up to 2 seconds). "How fast is fast though?" "Ummmm, well, it's taken up to..." "Is it less than an hour?" "A... AN HOUR?!??" "Yes, is it less than that? The existing system takes longer." "Ummm, it's usually less than a second"

So even though the benefit here was HUGE, people just weren't looking for it, and didn't understand it.

I recognize a lot in this story. Our senior data architect chose RDF for modeling our conceptual information models because it's easy to merge and split distributed models across the company, and crucial to be able to rely on the globally identifier IRIs for resources. But like @takis_ says, it's also much more simple. When modeling data it's a breeze to be able to operate in an Open World Assumption, and to simply state what I want to model, such as subproperties, or inverse relations. Also, it's easy to append facts that extend existing standards or models without changing anything to existing models. I'm completely sold, but many people only see challenges fail to see many of the benefits. Now to be fair, it can be quite an investment: finding people, changing technology stacks and processes. But I believe that the problems you'll solve will ultimately make up for that.

thank you for information and experience, i will try it and see, if its simple and useful sooner or later will be adopted i think

Side note - a schema and SQL is a bit like strict types, it’s a guard rail that many feel uncomfortable without. I think trying it out for a while is the only way, but many never take the time.

@takis_: I agree with the above answers; RDF/XML in particular has a lot to answer for! :rolling_on_the_floor_laughing: However, I also have another set of reasons… The main one is that I think there are significant differences between RDF, the semantic web, and linked data. All are of course highly related ideas; but they’re also separate, independent ideas, however most people, even practitioners in the field think they’re the same thing — i.e. that they’re all just synonyms for the same thing; and they’re really not. Basically in the early days, you had Timbl proselytising a vision for data on the web. Data on the web is then naturally a graph; so you have graph data, and URI’s are identifiers etc… so you basically get RDF; and if you put it on the web at the right places such that it dereferences you get linked data. There was also a lot of hand-wavy talk of agents using that data… e.g. stuff like software agents booking you a holiday… Then throw into the mix that you had the convergence of academics who had been doing research into description logics and KR coming out of the AI winter, looking for a new bandwagon to tie their interests too. I believe they also wanted a common DL that they could all use, so every research group didn’t need to invent their own one for their research projects. This effort became OWL, and they tied it and collectively sold it as the semantic web vision; and Timbl etc bought into it as it gave them some formal rigour, and a wider community etc. However that community of early adopters were heavily on the academic side; and academics are interested in papers; not practical “trivial problems” (which often turn out to be significant engineering challenges). Anyway, the Semantic Web had a lot of hype from this group; but it was heavily based on logic programming… Now logic programming is very cool; but it’s not suited to every problem; for example see the failure of Japan’s 5th generation computing project: https://en.wikipedia.org/wiki/Fifth_Generation_Computer_Systems ), the semantic web had many of these same problems, but also included distributed systems problems etc, so they made a hard problem even harder 🙂 Anyway in my view the problem was that the “Semantic Web” vision was never entirely realistic… it’s simply not suited to everyone; in the same sort of way the web is. So basically it under delivered on the promises; and much of the work was overly academic and complicated. Also in the standardisation processes back then there was a lot of design by committee without having proven parts of the value proposition. However we’re still left with lots of really good stuff — but sadly because the technologies and their pros and cons were heavily conflated, people don’t see the good bits… for example a lot of the value in RDF is in having an extensible, accretive data model. That is arguably a much bigger benefit for far more people than OWL will ever be; but very few people talk about it, so it gets ignored. IMHO there’s a huge amount of unexploited low hanging fruit in the worlds of RDF and Linked Data — it just needs packaged and marketed appropriately.

There are other dimensions to this too… for example triple stores have different performance properties to relational databases; and there are less options available, so you might not find one that fits your needs precisely, even though such a thing could exist.

thank you rick : ) i like all databases actually, sometime i will try graph databases also

i think important is to see the programming way, for example tables you program in relational way, tables with each column 1 value, documents you have arrays and hash-maps so you program in functional way more, in graphs you program in logic programming way. I think deciding the programming way you like matters, instead of thinking what is the best.

@rickmoynihan Thanks for a fantastic history briefing! Much appreciated 😀

I think we might be nearing a comeback for KR and some of the more “old fashioned” AI stuff now that deep learning is hitting the limits of what it can accomplish without folding in other approaches, which may mean a similar resurgence in RDF, knowledge graphs, and the like. I think it’s useful to compare and contrast two projects that Meta’a AI team released recently for an illustration of why. The first is https://arstechnica.com/information-technology/2022/11/after-controversy-meta-pulls-demo-of-ai-model-that-writes-scientific-papers, a supposedly “scientific AI” that was so adept at producing pseudoscience that they took it offline the week its public demo was released. That’s because it was just another https://dl.acm.org/doi/10.1145/3442188.3445922 doing probabilistic copy-and-paste, albeit one trained exclusively on scientific literature. It had no direct representation of truth, which to me is about as basic a requirement for science as you can possibly imagine. The second is https://arstechnica.com/information-technology/2022/11/meta-researchers-create-ai-that-masters-diplomacy-tricking-human-players/amp/, an AI able to compete with human players at Diplomacy, a strategy game that involves bluffing, subterfuge, and anticipating the plans and actions of other players - so not just modeling the truth but also what others believe to be the truth. According to Ernest Davis, the system required to make Cicero an effective player is substantially more complex than the “just throw more data and 60,000 TPUs at a specific neural network architecture” approach that has grabbed headlines recently. He https://garymarcus.substack.com/p/what-does-meta-ais-diplomacy-winning > Strikingly, and in opposition to much of the Zeitgeist, Cicero relies quite heavily on hand-crafting, both in the data sets, and in the architecture; in this sense it is in many ways more reminiscent of classical “Good Old Fashioned AI” than deep learning systems that tend to be less structured, and less customized to particular problems. There is far more innateness here than we have typically seen in recent AI systems. I think graph data and RDF are much more relevant to the second approach than the first, so there may be a lot of unexplored territory in “good old fashioned AI” now that computers are substantially faster than when the AI winter took hold.

@afoltzm: I certainly think there’s a role to play for GOFAI and KR in the future of AI — and I share your concerns around purely stochastic approaches. Infact arguably there are vanishingly few purely stochastic processes; for example an often neglected fact is the role of techniques like mini max in alpha go’s design. Alpha go didn’t learn minimax, it was engineered in by people. Then even if stochastic processes do win out; it’s hard to imagine them not essentially learning things like FOPL and set theory etc and then having to use it. Cicero is interesting; thanks for sharing I’ve not seen it before. About 20 years ago I worked at a defunct startup working with multi-agent systems. So there was lots of GOFAI. We used a defeasible reasoning engine we (by which I mean our CTO) had developed, and had an agent communication language with semantics based on mutual belief… and agents could then reason about what they believed other agents believed; and yes you could also get arbitrarily meta… reasoning about if they believe I believe X, but I believe Y then Z etc. It was all super cool stuff; but something perhaps better explored in academia rather than industry 🙂