RDF finally has its long awaited Generic Client!

[Kingsley Idehen]

Hi Everyone,

It’s been a while!

Something important is happening right now, thanks to the emergence of LLMs as the long-awaited generic RDF client (the so-called “killer app”). We all know how Mosaic → Mozilla/Netscape made HTML and HTTP globally usable by end-users and developers alike. Well, the very same thing is finally happening with RDF—albeit some 20+ years later than expected.

Here’s a post I recently published on LinkedIn about this critical development:

https://www.linkedin.com/pulse/large-language-models-llms-powerful-generic-rdf-clients-idehen-xwhfe

-- 
Regards,

Kingsley Idehen	      
Founder & CEO 
OpenLink Software   
Home Page: http://www.openlinksw.com
Community Support: https://community.openlinksw.com

Social Media:
LinkedIn: http://www.linkedin.com/in/kidehen
Twitter : https://twitter.com/kidehen

[Alex Shkotin]

Hi Kingsley,

A good article about using RDF and user interface functionality. But I believe that any information generated by LLM should be marked "May contain errors."

So all those beautiful tables, diagrams, and documents should display this sign prominently.

For me, user interface functionality that reflects the power of RDF is more important.

Best regards,

Alex

пн, 29 сент. 2025 г. в 19:48, 'Kingsley Idehen' via ontolog-forum <ontolo...@googlegroups.com>:

--
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or
unsubscribe to the forum, see http://ontologforum.org/info
---
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/9501caa2-29b1-4092-8866-db47c0c23cc1%40openlinksw.com.

[Kingsley Idehen]

Hi Alex,

On 9/30/25 4:36 AM, Alex Shkotin wrote:

Hi Kingsley,

A good article about using RDF and user interface functionality. But I believe that any information generated by LLM should be marked "May contain errors."

Yes, but that’s an optional behavioral configuration. For instance, in my examples, an LLM was part of the production pipeline that produced the reference documents—that is, I have the domain expertise to verify accuracy prior to publication.

If it were a direct-from-LLM pipeline, as I’ve demonstrated in the past, a disclaimer would be attached to anything generated 100% by the LLM. This is a fundamental pattern for managing a probabilistic tool like an LLM.

So all those beautiful tables, diagrams, and documents should display this sign prominently.

See comment above.

For me, user interface functionality that reflects the power of RDF is more important.

Extremely. The point of my article is that LLMs are powerful, generic RDF clients that free both developers and end-users from the prior distractions of RDF esoterica (e.g., HttpRange-14, preferred syntaxes, notations, and formats, 303 vs hash re entity denotation etc..).

Kingsley

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CAFxxROTh%2BPnqTjb0hpJj2-ruW1SaeC0B6kZYw0g%3D%3DhKAkhP9cg%40mail.gmail.com.

[John F Sowa]

Alex,

Wolfram and others make an important check to avoid those errors.

Wolfram translates questions or commands in ordinary English to their precise formal notation.  Then  before they execute the formal version, they translate it back to a precise statement in Controlled English.  

The CE text looks like English, and it can be read as English.    But it has a precise, formally defined translation to and from Wolfram's formal notation.

Many systems, including our Permion Inc. systems do that.  They either provide an exactly correct answer, or they carry on a dialog to help the human user specify a request that can be processed by exact formal methods.

The final answer is exactly correct reply to the formally defined Controlled English.  

Errors are still possible, but they are the fault of the human user who may not understand the CE reply.  That can be corrected by giving the users more options for asking further questions before making a commitment to one particular answer.

John

 

---

From: "Alex Shkotin" <alex.s...@gmail.com>

Hi Kingsley,

A good article about using RDF and user interface functionality. But I believe that any information generated by LLM should be marked "May contain errors."

So all those beautiful tables, diagrams, and documents should display this sign prominently.

For me, user interface functionality that reflects the power of RDF is more important.

Best regards,

Alex

[Alex Shkotin]

John,

I agree. Formalization is absolutely crucial, as we're moving toward mathematical methods of knowledge processing, where the differences aren't very large and mostly lie outside the realm of finite models and algorithms.

But constructing the most accurate formalization is a rather delicate matter. And here, the formal language used, while important, is only an auxiliary tool. The knowledge being formalized itself must be a well-structured theory. And that's quite challenging.

Therefore, it's proposed to store theoretical knowledge, along with its various formalizations, in frameworks specifically designed for knowledge concentration [1]. Such theoretical repositories with an emphasis on formalization exist spontaneously in Isabelle, Coq, and other provers.

Despite the enormous accumulation of theoretical knowledge in science and technology, I believe its volume, in a systematic and refined form, would be several terabytes.

The key is to create concentrators of such verified and formalized theoretical knowledge.

Alex

[1] (PDF) Theory framework - knowledge hub message #1  рус

"Storing the theory of a particular subject area in one place and maintaining it (including formalization) through collective efforts is easily possible with the modern development of technology. The concentration and verification of knowledge achieved in this case should give a powerful ordering of theoretical knowledge, which will facilitate their formalization, i.e. mathematical notation, and therefore algorithmic processing in many cases, up to the semi-automatic proof of various kinds of consequences, for example, theorems. This message describes what the framework of the theory is, intended for unified storage and collective accumulation of its results."

вт, 30 сент. 2025 г. в 23:02, John F Sowa <so...@bestweb.net>:

--

All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or
unsubscribe to the forum, see http://ontologforum.org/info
---
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/c6fff330733e409ab403d68c30a52e46%409d7e08195564407192034ca99241e3fa.

[Alex Shkotin]

Hi Milton,

What do you think about representation of our theoretical knowledge as axiomatic theories?

Alex

ср, 1 окт. 2025 г. в 18:10, Milton Ponson <rwic...@gmail.com>:

As a mathematician I cannot suppress a chuckle here. The problem here is the implicit discussion about knowledge,  knowledge representation and formal knowledge representation

These are three distinct layers and because we still not have a firm grip on the first, which is inextricably linked to consciousness,  knowledge representation remains a difficult task to accomplish, and consequently formal knowledge representation, which we are seeking will remain elusive. 

Large language models ignore the first layer and assume we can use token based systems to create knowledge representation emulation systems that can capture all formal knowledge representation systems.

If one looks at the groundbreaking paper MIP*=RE, https://arxiv.org/abs/2001.04383, and what it states about the Connes embedding conjecture being false, this should ring a bell.

Because we cannot in all cases assume that a finite matrix in a very high dimensional space can approximate a simulation of an infinite dimensional space.

Which means that no matter how high we make the dimension and consequently the number of parameters used, in some cases the simulations will never even get close to approximate a finite accurate model of infinite space.

Which means generative LLMs are are a mathematical dead end, and will be the reason why the AI bubble riding on generative LLMs will burst.

Milton Ponson

Rainbow Warriors Core Foundation

CIAMSD Institute-ICT4D Program

+2977459312

PO Box 1154, Oranjestad

Aruba, Dutch Caribbean

[John F Sowa]

Alex,

I totally agree with Milton.  

MP:  The problem here is the implicit discussion about knowledge,  knowledge representation and formal knowledge representation.  These are three distinct layers and because we still do not have a firm grip on the first, which is inextricably linked to consciousness . . . . .  

I have been saying something very similar to this point again, and again, and again.

I'll repeat once more, starting with Milton's point above. For any kind of knowledge representation, there is a continuous infinity of possible starting points and levels of detail or scope.  Every attempt at formalization must make a choice among an infinitely of options.

Therefore, the probability that your choice of what to formalize is correct for anybody else is 1 divided by the total number of options -- in other words, 1 divided by infinity.

That value is very, very close to ZERO.   Therefore, your project of formalization is WORTHLESS.

So DON'T do it.

John

   

 

---

From: "Alex Shkotin" <alex.s...@gmail.com>

[Alex Shkotin]

John,

I can try to figure out what Milton means if he answers questions (It's always interesting to be Socrates). You've chosen the one closest to yours from "a continuous infinity of possible starting points."

I write here from time to time that the most commonly used knowledge, presented as theories in various textbooks, articles, and lectures, is selected for formalization. You can say: don't formalize the Geometry of Hilbert, Euclid, or Tarski. And so on for physical theories, and then say the same to every computer scientist and ontologist formalizing in RDF, OWL2, CL(🤝), Isabelle, Coq, or Lean.

A strange proposition for our community of practice.

Formalization is not the creation of new knowledge. It is the formalization of existing, human-verified knowledge for reliable processing by computers.

It should be added that we formalize (some would say, crudely, "cram" them into a computer) not only theories, but also their models and methods for solving problems about the properties of these models [1]. We spend our entire lives constructing theories and their models, and testing them in practice by solving various problems: Close your eyes and solve the problem of taking a sip from your cup of tea.

LLMs show that knowledge can be concentrated, but who better than you to know that it can be concentrated in a much more compact and reliable way, without any brute force.

Alex

[1] Specific tasks of Ugraphia on a particular structure (formulations, solutions, placement in the framework)

"This document describes a specific framework of specific tasks about a particular structure posed and solved GNaA Fig.1.1 within the framework of a specific theory, namely Ugraphia, the theory of undirected graphs, with little involvement of the theory of binary relations, Binria. The task framework stores the formulation and solution of tasks in a structured form and is intended for use by everyone in the world (be it the world of a research group or Humanity): having set a task on the structure before solving it on their own, a person can look into the task framework and see: perhaps it has already been solved. The structure and tasks about it are described in the first paragraph of the first chapter of [GSiA]."

ср, 1 окт. 2025 г. в 21:00, John F Sowa <so...@bestweb.net>:

--
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or
unsubscribe to the forum, see http://ontologforum.org/info
---
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/14bb3912000a477f820480fbdd414cbd%40af128af903a246abbaa42dc2aef387a1.

[John F Sowa]

Alex,

Everything on a digital computer is 100% formal.  It is impossible to program anything on a digital computer that is not formalized.   Every programming language, including the raw machine instructions themselves are absolutely precise and 100% formalized.  No computer program can ever be informal.

But it is true that many programs are so badly described that the descriptions in English, Russian, or French are not 100% accurate statements of what the program actually does.  In that sense, you're talking about errors in the specification.

Alex:  You can say: don't formalize the Geometry of Hilbert, Euclid, or Tarski. 

The geometry of Hilbert, Euclid, and Tarski was 100% formalized.  Euclid set the standard for formalization for over two thousand years.  Hilbert and Tarski were very precise and accurate in their formalization.  [

Euclid's Book 1 was the most accurate in his formal statements.  But he made many mistakes in his later chapters.   However, Euclid set the standard for precision, and many of the mathematicians who followed detected and corrected his errors.   Hilbert and Tarski were much more careful and precise,  We have to make a clear distinction between formalization and clarifying and correcting the formalism by further analysis.  That may involve a translation to a different notation that is equally formal, but perhaps more readable.

[Chris Partridge]

There has been a revival of interest in Euclid in the last few decades, See e.g.
[12] F. Arntzenius et al., “Calculus as Geometry.” in Space, Time, and Stuff. Oxford University Press (UK) (2014).  
[13] I. Grattan-Guinness, “Numbers, Magnitudes, Ratios, and Proportions in Euclid’s Elements: How Did He Handle Them?” Historia mathematica. vol. 23, pp. 355–75 (1996).
I found this work useful and quoted it in
Partridge, C., Mitchell, A., Loneragan, M., Atkinson, H., de Cesare, S., & Khan, M. (2019). Coordinate Systems: Level Ascending Ontological Options. 2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C), 78–87. https://www.academia.edu/40354620
There is also the historical work of Netz - see e.g Netz, R. (1999). The Shaping of Deduction in Greek Mathematics: A Study in Cognitive History. https://doi.org/10.1017/CBO9780511543296

As these show, there is more to Euclid that has been assumed in some recent history.

--
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or
unsubscribe to the forum, see http://ontologforum.org/info
---
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/9cde0daa77f24f1faef6d03e9f9d0a57%40d7ab6ea98f1d4a3cab929e93d5732f60.

[John F Sowa]

Chris,

I certainly agree.  There is much more in Euclid than most people learned in high-school geometry.   Archimedes and others added a huge amount.  The Chinese, Hindus, and Arabs also added a lot.  

One reason why C. S. Peirce was so innovative in mathematics is that he had gathered the largest collection of medieval manuscripts on logic in the Boston-Cambridge area. A lot of mathematics had been forgotten or ignored during the Renaissance. 

John

 

---

From: "Chris Partridge" <partri...@gmail.com>

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CAMWD8MputGE0nxZvdmUFMfuL7MgRggvmxO2Hrk4aCp7XNtXxhw%40mail.gmail.com.

[Alex Shkotin]

John,

Euclid's exposition [1] is completely informal, but the idea of axioms, definitions, theorems, and proofs is used extensively.

Hilbert wrote out all the primary terms and axioms. This is a major step forward, but his exposition is informal [2]. In doing so, he laid the foundation for the formal notation of theorems and their proofs.

An example of a formal text for geometry can be found here [3]. The beginning of the definitions section is given.

To make such formal texts publicly accessible and collaboratively developed, a theoretical knowledge framework is proposed: (PDF) Theory framework - knowledge hub message #1.

Alex

[1] http://aleph0.clarku.edu/~djoyce/elements/elements.html 

[2] https://en.wikipedia.org/wiki/Hilbert%27s_axioms 

[3] https://github.com/ivashkev/math-formalizations/blob/master/07_EuclideanGeometry.v

Class Definitions `(dc : Declarations) :=

{

  Convergent (x y : Line) : Prop

    := (x <> y) /\ (exists A : Point, [ A @ x, y ]);

  Parallel (x y : Line) : Prop

    := (~ Convergent x y);

  SameRay (O : Point)(A B : Point) : Prop

    := O <> A /\ O <> B /\ [ A, O, B ] /\ ~ [ A # O # B ];

  OppositeSide (x : Line)(A B : Point) : Prop

    := ~ [ A @ x ] /\ ~ [ B @ x ] /\ (exists O, [ O @ x ] /\ [ A # O # B ]);

  SameSide (x : Line)(A B : Point) : Prop

    := ~ [ A @ x ] /\ ~ [ B @ x ] /\ ~ (exists O, [ O @ x ] /\ [ A # O # B ]);

  SameHalfplane (O A B C : Point) : Prop

    := O <> A /\ exists x : Line, [ O @ x ] /\ [ A @ x ] /\ SameSide x B C;

  OppositeHalfplane (O A B C : Point) : Prop

    := O <> A /\ exists x : Line, [ O @ x ] /\ [ A @ x ] /\ OppositeSide x B C;

  Segment

    := @Duo Point;

  BuildSegment

    := @BuildDuo Point;

  Triangle

    := @Triple Point (fun A B C => ~ [ A, B, C ]);

  BuildTriangle

    := @BuildTriple Point (fun A B C => ~ [ A, B, C ]);

  Ray

    := @Duple Point (fun A B => A <> B);

  BuildRay

    := @BuildDuple Point (fun A B => A <> B);

  EqRays (a b : Ray) : Prop

    := (da a = da b) /\ SameRay (da a)(db a)(db b);

  OpRays (a b : Ray) : Prop

    := (da a = da b) /\ [ db a # da a # db b ];

  Sector

    := @Duple Ray (fun a b => da a = da b);

  BuildSector

    := @BuildDuple Ray (fun a b => da a = da b);

чт, 2 окт. 2025 г. в 14:01, John F Sowa <so...@bestweb.net>:

--
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or
unsubscribe to the forum, see http://ontologforum.org/info
---
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/9cde0daa77f24f1faef6d03e9f9d0a57%40d7ab6ea98f1d4a3cab929e93d5732f60.