Good enough is not good enough

Mike's Notes

This gem from Roberto Di Cosmo, Director of Software Heritage, explains much of the web's history and the current swarm of AI crawlers.

"The "good enough" trap: Why the web keeps breaking itself

Every day, swarms of AI crawlers storm the web like "digital locusts," repeatedly re-downloading entire websites just to discover what changed. It's wildly inefficient, drives up massive infrastructure costs, and is actively forcing the open web to lock its doors behind bot filters and API paywalls.

The most frustrating part? We solved this decades ago. In his new series, Roberto Di Cosmo, Director of Software Heritage, traces how our digital infrastructure keeps falling into the "good enough" trap: local decisions that work fine for individual actors, but compound into an aggregate disaster for everyone else.

Back in 1998, long before Google dominated search and decades before LLMs arrived, Di Cosmo co-authored an IETF Internet-Draft proposing a simple, push-based alternative called the Remote Update Protocol (RUP). A web server knows when its data changes, so by broadcasting updates directly, it spares crawlers the endless need to ask, “Anything new?"

Despite being technically sound and independently re-invented by others, the protocol quietly expired. It lacked a dedicated institution to champion, maintain, and deploy it. Fast-forward to today, and everyone pays the price for relying on "good enough" brute-force scraping.

The mission of Software Heritage is to address this directly by archiving public source code once so the world doesn't have to collect it over and over. 

Di Cosmo’s series isn't just a historical autopsy—it’s a warning. Without collective, sustained investment in shared digital infrastructure, the open web will continue to disappear into proprietary silos." - Software Heritage

Resources

References

  • Consent in Crisis: The Rapid Decline of the AI Data Commons, Data Provenance Initiative, July 2024 (arXiv:2407.14933).
  • R. Di Cosmo and P. E. Martínez López, “Distributed Robots: a Technology for Fast Web Indexing”, written January 1998.
  • Hijacking the World: the dark side of Microsoft, October 1998.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Software Heritage
  • Home > Handbook > 

Last Updated

28/08/2026

Good enough is not good enough

By: Roberto Di Cosmo
Roberto Di Cosmo: 08/2026

An alumnus of the Scuola Normale Superiore di Pisa, with a PhD in Computer Science from the University of Pisa, Roberto Di Cosmo was associate professor for almost a decade at Ecole Normale Supérieure in Paris. In 1999, he became a Computer Science full professor at University Paris Diderot, where he was head of doctoral studies for Computer Science from 2004 to 2009. President of the board of trustees and scientific advisory board of the IMDEA Software institute and chair of the Software chapter of the National Committee for Open Science in France, he is currently on leave at Inria.

His research activity spans theoretical computing, functional programming, parallel and distributed programming, the semantics of programming languages, type systems, rewriting and linear logic, and, more recently, the new scientific problems posed by the general adoption of Free Software, with a particular focus on static analysis of large software collections. He has published over 20 international journals articles and 50 international conference articles.

In 2008, he has created and coordinated the european research project Mancoosi, that had a budget of 4.4Me and brought together 10 partners to improve the quality of package-based open source software systems.

Following the evolution of our society under the impact of IT with great interest, he is a long term Free Software advocate, contributing to its adoption since 1998 with the best-seller Hijacking the world, seminars, articles and software. He created in October 2007 the Free Software thematic group of Systematic, that helped fund over 50 Open Source research and development collaborative projects for a consolidated budget of over 200Me. From 2010 to 2018, he was director of IRILL, a research structure dedicated to Free and Open Source Software quality.

He created in 2015, and now directs Software Heritage, an initiative to build the universal archive of all the source code publicly available, in partnership with UNESCO.

...

A series about why the open web is collected so badly, why that has survived thirty years of everyone knowing better, what it is now costing all of us, and what is needed to go from “good enough” to “doing things right”.

What this is

The series runs on LinkedIn. This page is where it lives afterwards: every post in order, and under each one the sources for every claim it makes — dates, references, links, commit identifiers, intended to make it possible for you to check the facts directly.

It is also here for a more practical reason. What follows is partly about things quietly disappearing from the web, and about what it costs to depend on a single platform. Leaving the only copy inside somebody else's feed would have made the point rather too well.

The posts

  • 01 The wasteful sentence 4 Aug
  • 02 The alternative was written down 11 Aug
  • 03 How good enough wins 18 Aug
  • next: The mechanism: an externality, not a villain

The series

POST 01 The wasteful sentence 4 August 2026

The words "This way of collecting data is very wasteful", quoted from David Senecal, principal product architect for fraud and abuse at Akamai, Business Insider, 19 September 2024.

This way of collecting data is very wasteful.

That is how an Akamai specialist described the way many AI crawlers gather material from the web.[1] The report around the quotation gives the concrete mechanism: some botnets revisit an entire site every day merely to discover what changed, transferring the same material again and again. This is not new: search engines have been doing it for decades, in the very same wasteful way, but the scale of "scraping" is now such that what we have known as the "open web" is now closing down, an API at a time[2], a "bot filter" at a time[3], effectively reducing the global value for everybody, while increasing the waste of resources.

The striking part is not that the method is wasteful. Everybody running a sizeable website knows that by now. The striking part is that we speak as though this were a law of nature.

It is not. We knew how to avoid most of this waste in the 1990s, and it turns out I actively tried to push forward a concrete solution, when the problem was still manageable. We'll get back to this.

For nearly three decades, I have repeatedly encountered the same pattern: a system that works well enough for every actor taken separately, while imposing a growing cost on everybody taken together. Each local decision is reasonable. Their aggregate result is damaging. Since nobody owns the aggregate problem, the better solution remains nobody's job.

It is time to call out this state of affairs, and act upon it... again: I personally tried many times, and now I can build on that experience. The first step is to clearly understand what is happening and why: which actor does what and why, who gains, who loses. In the coming weeks I will reconstruct one instance of the pattern from dated documents. It begins with web crawlers and ends with the institutions we build—or fail to build—for shared digital infrastructure.

Let me point at the destination from the outset: I direct Software Heritage, a non-profit organisation that collects public source code once so that others do not all have to collect it again. This is my latest effort to contribute to systematically address this long standing problem.

It is a problem that starts with two simple words: good enough.

POST 02 The alternative was written down 11 August 2026

A record card for the Internet-Draft "Distributed Robots: a Technology for Fast Web Indexing", by Di Cosmo and Martinez Lopez, recorded 4 March 1998, the document printing "EXPIRES SEPT 1998" with no day given. Beneath the card, a caption reads: "What today's AI crawlers do, answered on paper in 1998."

One of my first encounters with the "good enough" curse came in the mid-nineties, during the ferocious battle to control the rapidly expanding cyberspace.

WebCrawler, AltaVista, Alexa, Yahoo… Google, the eventual winner, had not even been born yet.

What stunned me was that all of them did essentially the same thing: download the Web again and again to discover what had changed.

Sounds familiar? It should: it is exactly what AI crawlers do now.

The Web was much smaller then, but bandwidth, compute and storage were scarcer too, so the waste was already real.

And there was an obvious alternative.

In January 1998, with Pablo E. Martínez López — aka Fidel — I wrote Distributed Robots: a Technology for Fast Web Indexing. It entered the IETF record as an individual Internet-Draft on 4 March 1998,[4] carrying the wonderfully explicit line: "EXPIRES SEPT 1998."

The idea was elementary, familiar to any systems programmer: interrupt-driven beats busy-wait.

A web server knows, cheaply, when its files change. Let it say so, and let crawlers fetch only what is new — instead of asking every server, over and over, "Anything changed?"

In May 1998 an IETF Area Director sent us a generous, detailed critique. By then I had moved on: that March I had put Piège dans le Cyberespace online — CyberSnare in English — which went viral, started thirty years of work on free and open source software, and became a book with Dominique Nora.[5]

It took me seven months to answer point by point. I first asked what he thought of the revised structure.

The answer was an automatic out-of-office message. The thread ended there.

We produced the revised draft anyway, dated 20 April 1999, incorporating the review.[6] Fidel sent it to the RFC Editor. No answer came.

But the problem had not disappeared. In 2001 the IETF's own WEBI group independently produced Requirements for a Resource Update Protocol.

That expired too.[7]

Years later, looking at my web server logs, I found that in 2009 Googlebot had fetched one unchanged page twenty-four times.[8]

Students of mine implemented the Remote Update Protocol twice, in Java and OCaml.[9] The technical idea was not the hard part.

And this is the point: a better technical solution does not deploy itself.

Someone must maintain it, persuade others to adopt it, integrate it into existing systems, and keep pushing after the prototype works. Advocacy on the side of a full-time job is not an institution.

The alternative was written down almost thirty years ago, then rediscovered independently inside the IETF.

It was not defeated by a better idea.

It was not shown to be technically impossible.

It simply never acquired enough organised support to become infrastructure.

Meanwhile, the "good enough" solution kept scaling.

Why?

POST 03 How good enough wins 18 August 2026

A French sentence, "le systeme actuel fonctionne assez bien", above its footnote, "Good enough, comme on dit chez nos amis anglosaxons." From an article revised into 2011, written up from a talk at Inria in December 2007.

So why did it survive?

Not because anyone defended it. Because it was made liveable, one patch at a time.

Let's be precise about what "good enough" means: it does not mean bad. A good enough system does not do the right thing, but it does get the thing done. It is a hack, a wooden leg that gets you across the room… And because it gets you across the room, you stop looking for a better leg.

Downloading the whole web to find out what changed was never sensible. It was patched until it was bearable.

In 1994 Martijn Koster proposed robots.txt, so a site could say: not this, not here. It worked well enough that nobody standardised it until 2022.[10]

In 2006 came sitemaps, so a site could say: here is what I have, and here is when it last changed.

Read the specification closely. The freshness field is "a hint and not a command", and crawlers may ignore it.[11] So a site can say exactly what changed, and you are free not to believe it and download everything anyway. Which is what happened.

Then the crawlers got cleverer about where to spend. Google's own documentation says it plainly: "URLs that are more popular on the Internet tend to be crawled more often."[12] And if your server struggles, the crawler backs off.

Add it up and you have a system that works. Big sites get visited often, small sites rarely, a struggling server gets a break. Nobody is delighted, but nobody is ruined.

That is what good enough looks like from the inside: not a catastrophe, but a tolerable arrangement everyone has adapted to.

And then the second thing happens, which is worse: it becomes normal.

You are almost certainly reading this on a QWERTY keyboard. Nobody chose it this morning. Everybody knows it, every keyboard has it, and whoever switches first pays the whole cost alone. So it stays: not because anyone re-decided it, but because it is installed.

That is where web crawling ended up. Installed. It always worked like this.

In December 2007 I gave a talk at Inria's fortieth anniversary in Lille, written up as an article I revised into 2011. I wrote that the current system was working « assez bien ».[13] French had no phrase for what I meant, so I borrowed one, in a footnote: « Good enough, comme on dit chez nos amis anglosaxons. »

I was not complaining. I was describing. It was accurate.

Lock-in is harmless when the stakes are low. Nobody is much hurt by a keyboard layout.

Repeated crawling is not. It spends bandwidth, electricity and machine time on a planetary scale to fetch what has not changed.

Thirty years on from robots.txt, the patches are not holding, and everyone can see it.

So the question is not why nobody noticed the waste. Everybody noticed.

The question is why a cost that large stays invisible to the people who could act on it, until it is too late to act easily.

That is not a technical question. Economists have a name for it, and it is the whole point that we need to delve into.

References

Every source for every claim, numbered in the order the posts cite them. Each one carries a way back to the place it was cited from.

[1] post 01 Darius Rafieyan, “Like digital locusts, OpenAI and Anthropic AI bots cause havoc and raise costs for websites”, Business Insider, 19 September 2024. Archived copy: annex.softwareheritage.org. The speaker is David Senecal, principal product architect for fraud and abuse at Akamai. The sentence in full: “This way of collecting data is very wasteful,” he said, “but until the mindset on data sharing changes and a more evolved and mature way to share data exists, scraping will remain the status quo.” The sentence that follows in the post — botnets crawling a whole site daily — is the reporter’s prose summarising him, not a quotation, and is given as reported speech for that reason. ↩ back to the text

[2] post 01 GitHub tightened its limits on unauthenticated access on 8 May 2025, citing “an increase in scraping activity targeting our API”. Smaller operators went further: SourceHut placed a proof-of-work challenge in front of its web interface after a week-long crawler incident in March 2025, and GNOME, KDE, Fedora and Codeberg have each done some version of the same. ↩ back to the text

[3] post 01 Longpre et al., Consent in Crisis: The Rapid Decline of the AI Data Commons, Data Provenance Initiative, July 2024 (arXiv:2407.14933) — an audit of ~14,000 web domains behind three widely used AI training corpora, finding a sharp rise in crawl restrictions across a single year. ↩ back to the text

[4] post 02 R. Di Cosmo and P. E. Martínez López, “Distributed Robots: a Technology for Fast Web Indexing”, written January 1998. Record: datatracker.ietf.org. Full text, with everything that followed it: dicosmo.org/RUP/. The document prints “EXPIRES SEPT 1998” and gives no day, so none is claimed here. ↩ back to the text

[5] post 02 « Piège dans le Cyberespace », and the book that came out of it. The essay appeared in Multimédium (Canada) on 17 March 1998. It is online free and complete, in five languages, at dicosmo.org/Piege/cybersnare/ — French, English as CyberSnare, German as Falle im Cyberspace, Italian as Trappola nel Cyberspazio, Spanish as Trampa en el Cyberespacio — with a Chinese version at PiegeCN.html. The book is Le Hold-up planétaire : la face cachée de Microsoft, with Dominique Nora, Calmann-Lévy 1998, ISBN 2-7021-2923-4; Kirk McElhearn’s English translation, Hijacking the World: the dark side of Microsoft, followed in October 1998. When the publisher stopped reprinting in July 2006 the two authors recovered their rights and put the book out under Creative Commons Attribution-NonCommercial-NoDerivs. dicosmo.org/HoldUp/ carries the French, English and Spanish texts in full — the Spanish, El Asalto Planetario, never having had a print edition at all. ↩ back to the text

[6] post 02 The review, the resubmission, and the silence. On 10 May 1998 an IETF Applications Area Director reviewed the draft in the IESG and asked that the objects be defined as MIME types and distinguished from the FIND working group’s CIP and SOIF and from the W3C’s RDF. The point-by-point answer went back on 8 December 1998, accepting the MIME and SOIF encapsulation and asking one question before resubmitting; the reply, ten seconds later, was an automatic out-of-office, and no further correspondence followed. draft-RUP-01.txt, The Remote Update Protocol (RUP). Part I: RUP Architecture, is dated 20 April 1999 and does what the review asked. It was submitted: Martínez López sent it to the RFC Editor on 16 April 1999, with the file attached, describing it as “an update for the internet-draft <draft-rfced-exp-cosmo-00.txt>”. No reply ever came — the same address had answered the 1998 submission twice within hours — and six days later he wrote asking whether to chase them or wait a little longer. No IETF record of draft-RUP-01 exists. Nobody behaved badly: a volunteer reviewer was away for a fortnight, the answer had taken seven months, and after that carrying it forward was nobody’s job. The correspondence is in the author’s own archive. ↩ back to the text

[7] post 02 Twenty-four Googlebot fetches of one unchanged page across 2009, twelve of them answered 304 Not Modified. The log is reproduced in full on page 9 of the Inria anniversary article, which is now online with the talk it came from: dicosmo.org/Inria40/. ↩ back to the text

[8] post 02 “Requirements for a Resource Update Protocol”, draft-ietf-webi-rup-reqs, IETF WEBI (Web Intermediaries) working group. The first revision is M. Hamilton (JANET Web Cache Service) and I. Cooper (Equinix), 22 February 2001; Dawn Li and Mike Dahlin joined later; the last revision is dated 4 March 2002, and it expired. Its consumers are caching proxies and surrogates, not crawlers — a different protocol for a different audience. What is shared is the diagnosis, in its own abstract’s words: such a protocol is needed where “periodic revalidation is unacceptable in terms of performance and/or cache consistency”. There is no evidence the two efforts knew of each other, and none is claimed: the point is that the same conclusion was reached twice, independently, and expired twice. ↩ back to the text

[9] post 02 Both implementations were student projects at Paris 7 — Travaux d’Étude et de Recherche on the subject “indexation rapide du Web”, which Roberto set for two years running. The RUP 1.0 Java servlet, by Yerom-David Bromberg, is at dicosmo.org/RUP/RupJava/. OCamlRup — a RUP client, a generic RUP server and an Apache CGI server, with rupinfo.txt parsing and robots.txt integration — was written in 2001 by Samuel Lasry and Xavier Patourel and is archived at ocamlrup-0.1.tar.gz. Copyright remains the authors’; no licence was ever attached and none is asserted — it is published as an archival record, with attribution. ↩ back to the text

[10] post 03 robots.txt. The Robots Exclusion Protocol was, in the words of the RFC that eventually specified it, “originally defined by Martijn Koster in 1994 for service owners to control how content served by their services may be accessed”. It became an IETF standards-track document only in September 2022: RFC 9309, by Koster with G. Illyes, H. Zeller and L. Sassman. Twenty-eight years of running on a convention. ↩ back to the text

[11] post 03 Sitemaps, and the word “hint”. The Sitemap protocol 0.9 says of changefreq: “Please note that the value of this tag is considered a hint and not a command.” It goes on: crawlers “may crawl pages marked ‘hourly’ less frequently” than stated. The protocol lets a site describe its own freshness; it obliges no one to act on the description. That asymmetry is the whole of this post. ↩ back to the text

[12] post 03 Crawlers spending where it pays. Google’s own documentation on managing crawl budget: “URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” And on backing off: if a site “slows down … or responds with server errors … the limit goes down and Google crawls less.” Adaptation, not repair — the polling continues, more politely. ↩ back to the text

[13] post 03 From a talk given at Inria’s fortieth anniversary, Lille, December 2007, written up as an article revised into 2011: « le système actuel fonctionne assez bien », with the footnote “Good enough, comme on dit chez nos amis anglosaxons.” Both are now online at dicosmo.org/Inria40/ — the slides as the audience saw them, and the article, which was never finished; the footnote is on page 10. The article is cited as talk December 2007, article revised into 2011; no span of years is computed from it anywhere in this series. ↩ back to the text

Corrections

Every correction made after publication is logged here, with its date and what changed. Nothing is silently edited. If you find an error, the fastest way to have it fixed is to tell me.

— nothing logged yet —

www.dicosmo.org/good-enough/ — the version of record
Roberto Di Cosmo · dicosmo.org
Text licensed CC BY 4.0. Quoted material remains its authors'.
This page loads nothing from any other host: no fonts, no scripts, no analytics.

SemiAnalysis: Compare Realistic Agentic Inference Perf

Mike's Notes

Useful source for inference benchmarking. For future reference.

The first part of the article is copied below. You can read the rest by following the link in the resources below.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > SemiAnalysis
  • Home > Handbook > 

Last Updated

27/08/2026

Compare Realistic Agentic Inference Perf

By: Cam Quilici, Bryan Shan, Alec Ibarra, Daniel Nishball, Zane Fong, Kimbo Chen, Dylan Patel
SemiAnalysis: 23/08/2026

.

Since the Claude Code inflection point in November 2025, long-context, multi-turn agentic workloads have grown rapidly. They now dominate traffic for production inferencing. In April 2026, OpenAI’s Enterprise agentic spending overtook ChatGPT spending.

Agentic workflows have decisively taken the baton. Today, we announce AgentX 1.0 - the world’s first fully open source, multi-turn agentic coding inference benchmark at 1 million context, released under Apache 2.0. Our full dashboard is available here.

Source: SemiAnalysis

In the past most measured performance based on fixed sequence length prefill and decode workloads, but this is an inaccurate way to measure workloads. Reality is multi-turn, long context, high prefill reuse, with sub agent bursts, KVCache offload, and numerous tool calls. As such we aimed to build the correct way for the industry to measure AI hardware and software performance.

We have spent more than $3M building this dataset. Today, we open source everything. InferenceXv3 implements AgentX, a new realistic scenario in addition to the existing “fixed sequence length” scenarios (8k1k, 1k1k, 1k8k). It improves the benchmark scenarios by using agentic coding traffic instead of the previous single-turn traffic of 8k input and 1k output tokens.

The full matrix runs on ~2MW of continuously operated compute across over 1000 chips spanning a wide range of SKUs, featuring the MI355X, GB300 NVL72, GB200 NVL72, B300, B200, MI325, MI300X, H200, and RTX Pro Servers. Rubin arrives later this month, and TPUs and Mi455X UALoE72 arrive later this year. Please drop a star if you found our free open source work valuable.

It is great to see amazing performance from both NVIDIA and AMD on agentic workloads. NVIDIA does very good on a lot of frontier models while AMD also does well on some frontier models for specific comparsions.

Source: SemiAnalysis GitHub

The most valuable thing AgentX produced in its first months was not the initial results. It was the massive industry impact the benchmark is already having. Over 70+ upstream PRs for optimizing real world production agentic workloads across vLLM, SGLang, TensorRT-LLM, ATOM, AITER, Dynamo, LMCache, and Mooncake, uses AgentX as the north star benchmark proxy. Most of these optimization improvements are transferable to production traffic. We deep dive into each of these optimizations later in the article.

Source: SemiAnalysis

Open source is a core principle for InferenceX and thus, we open more of the stack than most people who use that word. That includes an open frontend, a public database served through an easily consumable REST API that multiple tier 1 AI lab’s capacity planning teams already consume, public GitHub Actions CI provenance, logs, and accuracy validation on every single point. Crucially, our benchmark configs mainly track recipes.vllm.ai and SGLang cookbook on upstream images such that we are measuring the performance actual customers are experiencing instead of measuring benchmax’ed images.

In three to four weeks, we will release an AgentX update article. It will cover further optimizations to agentic workloads, plus updated performance results from AMD and Nvidia. It is important to understand that the profile of agentic workloads is updating fast. InferenceX will continue to move swiftly to benchmark the relevant workloads.

InferenceX is 100% committed to being open-source - this would not be possible without the contributions and support from our OSS partners. We would like to thank the following people that have made massive contributions to the AgentX 1.0 release:

  • Inferact/vLLM: Roger Wang, Yifan Qiao, Simon Mo, Jeff Ma, and many others
  • RedHat/llm-d: Michael Goin, Robert Shaw, Tyler Michael Smith
  • RadixArk/SGLang: Baizhou Zhang, Yuwei An, Mingyi Lu, and many others
  • LMCache/TensorMesh: Samuel Shen
  • Weka: Callan Fox, ValB
  • MoonCake Maintainers: Teng Ma, Xu Wenjie, Ke Yang
  • AMD: Thomas Wang, HaiShaw, Andy Luo, Seungrok Jung, Chun Fang, Parth Panchal, Bill He, Theresa Shan, Hongxia, Fangzhou, Gilbert Lei, Yanfei Wang, Duyi Wang, Peng Sun, Lingpeng Jin, Simon Danielsson, Xiaohu Guo, Haichen Zhang, Chang Liu, Doug Lehr, Poovaiah Palangappa, and many others in the AMD Shanghai Development Centre
  • Nvidia: Xin Li, Anthony Casagrande, Kedar Potdar, Ankur Singh, Ishani Dhanani, Nick Comly, Nvidia Shanghai TensorRT-LLM team, and many others
  • Anthropic staff, for promptly fixing multiple bugs that made implementing AgentX possible
  • GitHub: Austen Stone for helping with reliability of GitHub Actions that AgentX uses
  • And many others
In addition, we are thankful to all who support our open source InferenceX initiative, including Meta, Microsoft, Oracle, OpenAI, MiniMax, Moonshot Kimi, Alibaba Qwen, and Zhipu GLM.

Source: InferenceX

... See the original article for the rest.

10 Pioneers Who Changed Our Understanding of Nature

Mike's Notes

I agree, it's not your formal qualifications that matter; it's your contributions. Many self-taught people, or "amateurs," have made great discoveries. I discovered this article via a Knowable Magazine article about Narwhal tusks and who was figuring them out. In this case, a dentist with a side passion.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Knowable Magazine
  • Home > Handbook > 

Last Updated

26/08/2026

10 Pioneers Who Changed Our Understanding of Nature

By: .
Narwhal Research: 06/02/2025

Nweeia, whose dental surgery practice is based in Sharon, Connecticut, lectures at Harvard’s School of Dental Medicine and holds a global fellow position at the Polar Institute at the Wilson Center. He is also a research associate at the Arctic Studies Center of the Smithsonian Institution and at the Canadian Museum of Nature, and a member of the Zoonomia Consortium of Harvard/MIT.

...

Great Amateurs in Science

Dr. Nweeia joins a pantheon of discoverers, many of whom had no formal scientific training, who have made extraordinary scientific contributions. 

Often overlooked by the experts in their fields, they made contributions recognized sometimes long after they were gone. Who are they? They are amateur scientists who excel in other fields — people like Thomas Jefferson, Michael Faraday, and Arthur C. Clarke— whose groundbreaking work occasionally leaves their professional counterparts envious. Against the odds, they’ve carved out a remarkable legacy in the history of science.

1. Gregor Johann Mendel

Regarded as the father of genetics, Gregor Mendel, an Austrian monk, conducted groundbreaking experiments on pea plants, discovering the fundamental laws of inheritance. Despite publishing his work in 1865, his findings remained unnoticed for decades. Mendel’s meticulous research laid the foundation for modern genetics, influencing evolutionary biology and agriculture.

2. David Levy

David Levy, a Canadian amateur astronomer, is renowned for co-discovering the comet Shoemaker-Levy 9, which dramatically collided with Jupiter in 1994. With no formal training in astronomy, Levy’s passion for stargazing led to the discovery of multiple comets, establishing his place in celestial history alongside the Shoemaker team.

3. Henrietta Swan Leavitt

Henrietta Leavitt, an American astronomer, unlocked the key to measuring cosmic distances by discovering the relationship between a Cepheid star’s brightness and its pulsation period. Her groundbreaking work allowed astronomers to determine the scale of the universe, leading to Edwin Hubble’s later discovery of galaxies beyond the Milky Way.

4. Joseph Priestley

Joseph Priestley, an 18th-century English polymath, is best known for discovering oxygen. His scientific contributions spanned chemistry, electricity, and photosynthesis, yet he was also a prominent theologian and political thinker. His work in chemistry laid foundational knowledge for future discoveries, including modern gas chemistry and the invention of soda water.

5. Michael Faraday

Michael Faraday, an English scientist, revolutionized the fields of electromagnetism and electrochemistry. Despite limited formal education, his discovery of electromagnetic induction led to the invention of the electric generator. Faraday’s pioneering experiments and contributions to the understanding of electricity earned him recognition as one of history’s greatest experimentalists.

6. Grote Reber

Grote Reber, an American radio engineer, built the world’s first radio telescope in his backyard in 1937. His innovative work in radio astronomy revealed radio emissions from the Milky Way, transforming the field. Reber’s telescope and research paved the way for large-scale radio observatories, advancing our understanding of the universe.

7. Arthur C. Clarke

Arthur C. Clarke, a visionary science-fiction writer and futurist, revolutionized global communication by proposing the concept of geostationary satellites in 1945. Best known for his science fiction, including 2001: A Space Odyssey, Clarke’s contributions to satellite technology transformed broadcasting and laid the groundwork for modern telecommunications.

8. Thomas Jefferson

Thomas Jefferson, third U.S. president and principal author of the Declaration of Independence, was also a pioneering archaeologist. In 1784, his methodical excavation of an Indian burial mound introduced modern archaeological techniques. Jefferson’s interdisciplinary genius spanned architecture, zoology, and botany, and he remains a towering figure in American history.

9. Susan Hendrickson

Susan Hendrickson, an American paleontologist and self-taught explorer, unearthed the largest and most complete Tyrannosaurus rex skeleton in South Dakota in 1990. Known as "Sue," this extraordinary find is a centerpiece at Chicago’s Field Museum. Hendrickson’s discoveries, spanning fossils and marine life, have left a lasting impact on paleontology.

10. Felix d'Herelle

Felix d’Herelle, a French-Canadian bacteriologist, discovered bacteriophages—viruses that attack bacteria—while researching dysentery in 1916. His work in phage therapy offered potential solutions for bacterial diseases, influencing genetic research and DNA studies. D’Herelle’s discovery paved the way for modern virology, particularly as antibiotic resistance becomes an increasing concern.

What I’ve learned writing for billions of users

Mike's Notes

I came across this gem in Smashing Magazine.

"What are the takeaways from writing for billions of users across dozens of languages, time zones, and cultures? Nick DiLallo has summarized everything he has learned writing for products used by a meaningful percentage of the world’s population. The result is a list of 70 valuable lessons learned that you can apply to your own writing right away." - Smashing Magazine

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Smashing Magazine
  • Home > Handbook > 

Last Updated

25/08/2026

What I’ve learned writing for billions of users

By: Nick DiLallo
Medium: 03/08/2026

Nick DiLallo is a writer based in Brooklyn. Past clients include Apple, Airbnb, Etsy, and Google. He currently leads UX writing at Clay.

...

Insights from products that grow and grow.

...

A few years ago, after running a complex global product launch, I wrote down everything I learned. To track my own ideas. To make sense of things. I’ve kept adding to it ever since.

I’ve worked on products used by a handful of people and products used by a meaningful percentage of the planet. The second kind taught me things the first never could.

This is what I’ve picked up along the way, writing for billions of users across dozens of languages, time zones, and cultures. Some of these lessons are about words. All of them are about people.

...

01: Most interfaces are mostly words. Take away all the text and screens stop making sense.

02: When you have a giant user base, people will interact with your product in ways you never intended. You’ll be shocked. You’ll also learn from them.

03: Good interfaces don’t need instructions. If you need to write things like “look for the arrow” or “scroll right,” the UI needs fixing. Words shouldn’t explain the design.

04: Naming features is hard. Renaming them is nearly impossible, especially if millions of people have already started using the product. You get one chance to get it right.

05: The typeface matters as much as the writing.

06: People have high expectations for software, and that includes the writing. World-class products don’t have mistakes, typos, or clunky phrasing.

07: Saying one thing is better than saying two or three things.

08: Fixing the writing can fix the entire company. Support tickets go down by the thousands. Conversion goes up. Users stay longer. There’s a reason the world’s best companies hire and value talented writers.

09: A shorter sentence is almost always a better sentence.

10: It’s always a good idea to fix things. You don’t need a rigorous business case for it. Don’t waste time trying to calculate the ROI of spelling “Connecticut” correctly.

11: People won’t read everything you put in the interface. They’ll skim and scan and scroll to what they want. You need to write for those people.

12: Rewrite everything twice. Rewrite important things twelve times.

13: Our relationship with technology changes. Writing can shape that change. Remember, we used to be afraid of using our real names online or entering our credit card.

14: Good writing just feels different. This can be hard to explain to non-writers. There’s a certain kind of click that happens in your head. Revise until you get there. You’ll know it when it happens. Developing this instinct takes a long time.

15: With a giant user base, you can get stuck trying to write “for everyone.” Try writing for one specific user. An Olympic athlete struggling to set a new record. A first-time mom who’s using your product at 4am. A surfer on their honeymoon in Tahiti. Choose one person and write.

16: Longer writing needs to be worth it. We expect more from a paragraph than a headline. Make everything the right length.

17: Users will read what you wrote, then do the exact opposite. It’s okay.

18: Details matter. The best teams spend time arguing over formatting and punctuation. Is it $45 or $45.00 or 45 (USD)? Do we say “July 5th” or “Next Tuesday”? Is it Settings or Preferences? You need to decide.

19: More opinions can sharpen your work.

20: Sometimes the last thing you need is more opinions.

21: A perfect error message is still an error message. Try to fix the root cause. Smarter inputs, clearer phrasing. An error is a last resort.

22: Words can’t do everything in an interface. Understand where other forms of information can help. A great description of a hotel room is no match for a photograph. A street address doesn’t show the same context as a full map.

23: Writing quality signals product quality. Users make judgments based on the writing. You can’t ask someone to trust you with their private data if they can’t trust you with your commas.

24: Small wins add up. A clearer headline here. A shorter error message there. A more direct call to action somewhere else. Fix enough little things and the product will completely transform.

25: Actions matter more than words. You can’t write one thing and do another. Don’t call it a “free trial” and then require a credit card. Don’t say chats are private if they aren’t. If you’re using writing to hide features or “convince” users, that’s a problem.

26: Most brand voice guidelines aren’t very helpful. Because most don’t say anything interesting or unique. Calling your brand voice “human” is not enough.

27: It’s usually a good idea to trust writers with writing. I’ve seen products fail because the wrong person was making decisions about words.

28: Grammar should be internalized. Learn the rules and break them when it feels right. But don’t talk about grammar too much. Using the phrase “past participle” in a meeting won’t get anyone excited. It’ll make them think of high school English class.

29: It’s hard to scale your product with a vague, meaningless value prop.

30: Tell the truth. I’ve seen a single vague sentence generate more support tickets than an actual outage. If something will take nine minutes, say it will take nine minutes.

31: Don’t invent words when you don’t need to. Digital products have a shared vocabulary that users already understand. Stick with common words and phrases. Log in. Save. Delete. Update. Edit.

32: Be careful about overwriting. This was something I saw lots of products doing for a long time, adding too much personality and too much text. Making a product “conversational” can sometimes just make it annoying to use.

33: A great onboarding will solve much more than an endless help center. First-time users who get confused don’t file tickets. They just leave.

34: You can’t evaluate writing in a spreadsheet or doc. Put the words in the interface and see how they read. Read them in the prototype. Read them on the device you’ll be using. Get as close to the real experience as possible.

35: Language is always changing. It happens faster than you think, and it’s the job of a writer to keep up. Look at the way people younger than you communicate, or the way your parents email. Nobody’s right or wrong. Language just moves.

36: Write without My or Your. Don’t call it My Photos or Your Photos. Just call it Photos. If you don’t, you’ll be chasing this down forever and confusing everyone along the way.

37: Writers who understand how products are built make better decisions. Learn as much as you can about strategy, technology, and business. A writer should understand how a company makes money and what their long-term vision is. Get as close to the decision-makers as possible.

38: Come back and read it tomorrow. Time away always helps.

39: If someone is using your product, they’ve already decided. Don’t market to them. You might talk them out of it.

40: Pick a word for something and use it everywhere, across every screen, for every user. Don’t call it a “folder” on one screen and a “workspace” on another.

41: Trust your own instinct as much as you trust your user research.

42: Users don’t know — or care about — your org chart. Your brand should have a single voice. It doesn’t matter if your emails, notifications, and support documentation come from different teams. Get everyone aligned.

43: Be careful with playfulness. A button that says “Pay” is clearer than one that says “Ka-chingggg.”

44: Word and image should work together. Give users context.

45: The things we build often reflect who we are. Selfish people build selfish products. Kind people build kind ones. To build the best product, build the best team and hire the right people.

46: Remember that translating for global products is a lot more complicated than swapping out text. Different languages reflect different cultures — and sometimes entirely different ways of thinking.

47: Be careful about making too many decks. You’ll start thinking in keynotes and bullet points, not UX and interface decisions.

48: Language has power. Writing makes people laugh and sob and get angry and feel joy and connect with other humans. A gradient can’t do that. A date picker or corner radius can’t do that.

49: Sometimes words can convey multiple meanings. “New” can mean exciting, but also unproven. Calling a transaction “safe” might make the user worry. Think about every word and what else it might be saying.

50: Not everything needs a login or account. Let people use your product. If they like it, they’ll stick around.

51: Not everything needs to be a subscription, either.

52: You get better by writing more. There’s really no shortcut to this one.

53: Know that your tools as a writer will keep changing. You’ll be working differently and using new software in 5 years. Maybe sooner.

54: One of the biggest challenges you’ll face is translating your product into right-to-left languages like Arabic or Hebrew. The entire UI starts to break. Icons, progress bars, and indicators might appear backwards. Build a writing system that can flex across all layouts and languages.

55: Never, ever mess around with money. There is no faster way to lose trust or infuriate a giant user base. Tell people what things cost. Don’t add “convenience fees” at checkout. Keep auto-renew off by default.

56: Good writing can’t fix a bad product. But it can reveal problems faster.

57: Get the first draft done. A bad draft is better than a blank screen.

58: Bringing writers in early is always a good idea. You can tell when a writer was added to the team the week before launch.

59: Delete as much as you can.

60: Good writing is not enough. You also need good layout, hierarchy, and typography.

61: The legal team will ask you to add words. Rewrite them so they make sense to regular people.

62: Laws are different everywhere. Required disclosures in Australia are different from those in California or the EU. Create different versions of the same screen if you need to. Don’t try to create one “hero version” that appeases everyone. It will end up being the clunkiest option.

63: Avoid the word “content.” It devalues everything it tries to describe. A film is not “content.” Writing is not “content.”

64: Users aren’t stupid. But they’re sometimes busy or distracted or tired.

65: Your writing will teach people how to think about your product. Clear language creates clear thinking. Vague or inconsistent language does the opposite.

66: Deliver bad news quickly and clearly.

67: Write for the user, not the press release or launch video. Too many companies get this wrong. They start with the marketing assets and then try to build the product around it. It usually doesn’t go well. Designing a screen for a keynote is different than designing it for a user, and great marketing won’t ever be able to fix usability issues.

68: It’s better to write something well the first time. A ten-second fix, multiplied across a billion sessions, is measured in years, not minutes.

69: If you’re making changes but things aren’t getting better, try fixing something other than the words. Use different components. Add animation. Adjust the navigation. Keep trying new ways to make the UI better. Don’t just rewrite. Rethink.

70: Accessibility can’t be layered on top of good writing. Turn on a screen reader and listen to your own writing. Use your product with different settings. You need to understand how people actually use your product, then write for them. All of them.

71: Build writing guidelines and documentation in the tools your team actually uses. Don’t make a PDF that never gets opened.

72: Users notice inconsistency before they notice almost anything else.

73: If you’re stuck, close your laptop and go outside.

Enterprise Knowledge Representation: Conceptual Graphs, ISO Common Logic, and SAP Graph Foundations

Mike's Notes

This is part of a series of thoughtful opinions about using Ontology in software information systems.

Pipi has an existing BORO Engine (bor) (inspired by Chris Partridge's book "Business Objects: Re-engineering for Re-use"), but it runs in reverse: it imports triples to extract entities and relationships, then uses them to build reference relational databases for back-end industry workspaces.

Part seven: A post by Simon Polovina on the Ontolog Forum in response to the original post by  James Lee Stakelum.

A nicely formatted PDF of the same post is in the resources below.

Resources

References

  • Enterprise Knowledge Representation: Conceptual Graphs, ISO Common Logic, and SAP Graph Foundations, Simon Polovina. August 12, 2026

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Ontolog Forum
  • Home > Handbook > 

Last Updated

24/08/2026

Enterprise Knowledge Representation: Conceptual Graphs, ISO Common Logic, and SAP Graph Foundations

By: Simon Polovina
Ontolog Forum: 12/08/2026

I bring Computer Productivity to Business Creativity by engaging in roles that draw upon my leadership and expertise in Enterprise Architecture and Conceptual Structures, which harmonise computer productivity with human and business creativity. My experience draws on Knowledge Representation and Reasoning, Artificial Intelligence, The Intelligent Enterprise, User Experience (UX), Design Thinking, Cloud, Data Infrastructures, SAP, Web, Service-oriented Architecture (SOA), Object-oriented Analysis and Design, and more. As well as NextGen industrial practice and education, I've published widely, with over 110 learned publications to date.

Abstract

This document presents a comprehensive discussion of the theoretical and practical role of Conceptual Graphs (CGs) in enterprise architectures, their comparative expressivity relative to First-Order Logic (FOL), Description Logics (OWL), and RDF, and their alignment with the ISO/IEC 24707 Common Logic. Additionally, it highlights recent perspectives on trustworthy AI, open vs. closed predicate grammars, and evaluates the comparative landscape of SAP Graph, SAP HANA Knowledge Graph, and SAP Business Data Cloud (BDC) Knowledge Graph across CGIF and CLIF representations.

1 Introduction & Conceptual Graphs Overview

Conceptual Graphs (CGs), developed by John F. Sowa (Sowa 1984), bridge human-readable visual semantics with formal mathematical logic. As introduced in previous foundational work (Polovina 2007), CGs provide a versatile environment for knowledge representation and automated reasoning that directly aligns with enterprise object models.

Key structural advantages of CGs over alternative formalisms include:

  • Visual Syntax with FOL Rigour: CGs use an intuitive visual bipartite graph syntax (concepts and conceptual relations) while maintaining an exact mapping via the -operator to First-Order Logic.
  • Native -ary Relations: Unlike RDF triples (), CGs support -ary relations without artificial reification.
  • Nested Contexts: CGs support nested propositional contexts, allowing clean modal, temporal, and belief representations.
  • Graph-Based Reasoning: Operations such as graph projection, join, and restriction enable sound structural reasoning without requiring resolution theorem provers.

This paper evaluates these theoretical properties within modern enterprise architectures. Specifically, we analyse the trade-offs of RDF-based knowledge foundations in SAP Business Data Cloud (BDC) and demonstrate how ISO/IEC 24707 Common Logic representations (CGIF and CLIF) provide a more robust substrate for neuro-symbolic AI.

2 Trustworthy AI, Common Logic, and Closed Grammars

Recent discussions surrounding multi-agent systems and local-first AI architectures highlight the crucial distinction between open-predicate systems and closed relational grammars (Stakelum 2026). Unconstrained open predicates (found in RDF, OWL, and raw Common Logic) incur an  integration bottleneck (the “Babel Tax”) when federating across independent domains.

By leveraging standardised specifications under ISO/IEC 24707 Common Logic (ISO/IEC 2018), architectures can combine bounded relational primitives with rich, open concept lattices (e.g., via Formal Concept Analysis), enabling sound neuro-symbolic reasoning without hallucination.

3 Comparing SAP Graph Architectures

Enterprise data foundations often combine multiple distinct graph paradigms. Table 1 outlines three core SAP graph technologies.

Comparison of SAP Graph Technologies

Feature/Aspect SAP Graph SAP HANA Knowledge Graph SAP BDC Knowledge Graph
Primary Purpose Unified API graph for cross-SAP integration In-memory graph engine for HANA Cloud analytics Business-context-aware semantic graph for AI
Scope Cross-SAP application data Technical graph database Business processes, roles, and policies
Data Sources S/4HANA, SuccessFactors, etc. Relational, spatial, and vector data in HANA SAP and non-SAP data with embedded context
Deployment SAP BTP SAP HANA Cloud SAP BTP (BDC Architecture)
Query Languages SPARQL, SQL SPARQL, Cypher, SQL SPARQL, SQL
AI Enablement High Medium Very High

Among these paradigms, the SAP BDC Knowledge Graph represents the most context-aware layer for enterprise AI. However, as evaluated in the following section, its technical implementation on an RDF triple-store foundation introduces structural friction that could be mitigated by a Conceptual Graph architecture.

4 Replacing RDF with Conceptual Graphs in Enterprise Data Foundations

Replacing Resource Description Framework (RDF) with Conceptual Graphs (CGs) in enterprise data foundations—such as the SAP Knowledge Graph capability and its technical implementation in SAP Business Data Cloud (BDC)—would fundamentally transform how enterprise AI, multi-agent systems, and business process models interact with underlying ERP data.

While SAP chose RDF for the SAP Knowledge Graph engine in SAP BDC primarily to leverage established SPARQL standards and existing triple-store tech, opting for a Conceptual Graph foundation would have solved several structural challenges inherent to large-scale ERP semantic layers.

4.1         Architectural Impact: RDF vs. Conceptual Graphs in Enterprise Systems
4.1.1     Eliminating -ary Reification in Complex Business Transactions

The RDF Reality: Standard ERP business entities rarely fit neat binary triples (). An SAP purchase order line item involves a vendor, material, quantity, plant, currency, pricing condition, and tax code. In RDF, representing this -ary transaction requires extensive reification or artificial intermediate nodes, bloating the number of triples into the billions and degrading SPARQL join performance.

The CG Advantage: CGs natively support -ary relation nodes linked directly to  concept nodes. A multi-party sales order or supply chain movement remains a single, unfragmented hypergraph node. This drastically reduces graph size, avoids join overhead, and makes the schema mirror actual SAP business objects (BAPIs/IDocs) directly.

4.1.2     Built-in Modal Logic for SAP Business Contexts

The RDF Reality: Enterprise data is deeply contextual. A price isn’t just “100 EUR”; it is valid from date  to , under condition type , within company code , and subject to a pending workflow approval. RDF lacks a native concept of contexts, forcing developers to resort to Named Graphs or  annotations—which break standard triple semantics and fragment reasoning engines.

The CG Advantage: Conceptual Graphs feature nested contexts as a core primitive. A belief state, a temporal validity window, a hypothetical “what-if” planning scenario, or an unapproved workflow step can be cleanly enclosed within a context box. Reasoning rules apply precisely inside specified contexts without leaking state into the broader knowledge base.

4.1.3     Direct Neuro-Symbolic Grounding for AI Agents (Joule & LLM Orchestration)

The RDF Reality: Modern enterprise architectures (like SAP’s Business AI Hub and SAP Knowledge Graph) use Knowledge Graphs to ground LLM agents and prevent hallucinations. However, converting LLM outputs into SPARQL triple patterns is notoriously fragile due to predicate drift, URI matching issues, and rigid triple structures.

The CG Advantage: CGs support graph projection—a sound and complete mechanism for pattern matching. An LLM acting as an abductive engine can propose a tentative solution in Conceptual Graph Linear Form (CGLF/CGIF). The engine uses projection to test if the proposed structure is a valid specialisation of an existing business rule or schema. If the projection fails, the logic engine rejects the hypothesis or pinpoints the exact ungrounded concept.

4.1.4     Convergence with ISO Standards

While RDF is a W3C web recommendation optimised for web-scale linking, CGs align directly with ISO/IEC 24707 Common Logic (ISO/IEC 2018). In enterprise ERP systems where auditability, compliance, and deterministic business rules are non-negotiable, having an underlying representation that translates losslessly into First-Order Logic provides a stronger governance guarantee than triple-store heuristics.

Structural Dimension SAP Knowledge Graph on RDF (in BDC) Conceptual Graph Alternative
Transaction Modelling Fragmented into binary triples via reification Native -ary structures preserving event unity
Business Contexts & Rules Named Graphs / Annotations (Ad-hoc) First-class Nested Contexts
Reasoning Mechanism Tableau-based subsumption / RDFS rules Graph Projection, Join, and Restriction
Agent AI Grounding SPARQL translation (prone to join complexity) Structural graph projection & unification
Schema Complexity Quadratic expansion of edge types (Babel Tax risk) Compact type hierarchies mapped to business objects


4.2 Why Didn’t SAP Do It?

The barrier has never been theoretical superiority—it has been ecosystem momentum. The RDF/SPARQL stack offered off-the-shelf open-source parsers, mature triple-store database engines, and an established developer base familiar with Semantic Web tooling. Implementing CGs natively would have required SAP to build and maintain a commercial-grade ISO Common Logic graph engine from scratch.

However, as enterprise systems pivot toward neuro-symbolic AI and local multi-agent orchestration, the architectural overhead of triple stores is becoming a bottleneck. Systems designed around -ary events, nested contexts, and graph projection are proving far better suited for grounding autonomous agents than legacy triple stores.

5 Formal Logic Representations: CGIF and CLIF
5.1 Conceptual Graph Interchange Format (CGIF)

Below is the linear CG serialisation of the comparison among the three SAP technologies, adhering, through CGIF,  to ISO/IEC 24707 standards (ISO/IEC 2018).

[Comparison: Study_SAP_Graphs] -
   (compares)-> [Technology: SAP_Graph],
   (compares)-> [Technology: SAP_HANA_Knowledge_Graph],
   (compares)-> [Technology: SAP_BDC_Knowledge_Graph].

[Technology: SAP_Graph] -
   (primaryPurpose)-> [Purpose: "Unified graph service for cross-SAP application integration"],
   (scope)-> [Scope: "Cross-SAP application data integration"],
   (deployment)-> [Platform: "SAP BTP"],
   (aiEnablement)-> [Rating: "High"].

[Technology: SAP_HANA_Knowledge_Graph] -
   (primaryPurpose)-> [Purpose: "Graph engine for storing/querying connected data in SAP HANA Cloud"],
   (scope)-> [Scope: "Technical graph database in HANA Cloud"],
   (deployment)-> [Platform: "SAP HANA Cloud"],
   (aiEnablement)-> [Rating: "Medium"].

[Technology: SAP_BDC_Knowledge_Graph] -
   (primaryPurpose)-> [Purpose: "Business-context-aware graph for AI-driven process automation"],
   (scope)-> [Scope: "Business semantics, processes, and context"],
   (deployment)-> [Platform: "SAP BTP"],
   (aiEnablement)-> [Rating: "Very High"].

5.2         Common Logic Interchange Format (CLIF)

The corresponding ISO 24707 CLIF representation provides a direct Lisp-style S-expression syntax suitable for first-order logic provers.

(cl-text SAP_Graph_Comparison_Ontology

  (cl-comment "Root Comparison Structure")
  (Comparison Study_SAP_Graphs)
  (compares Study_SAP_Graphs SAP_Graph)
  (compares Study_SAP_Graphs SAP_HANA_Knowledge_Graph)
  (compares Study_SAP_Graphs SAP_BDC_Knowledge_Graph)

  (cl-comment "SAP Graph Assertions")
  (Technology SAP_Graph)
  (primaryPurpose SAP_Graph "Unified graph service for cross-SAP application integration")
  (deploymentEnvironment SAP_Graph SAP_BTP)
  (aiEnablementLevel SAP_Graph High)

  (cl-comment "SAP HANA Knowledge Graph Assertions")
  (Technology SAP_HANA_Knowledge_Graph)
  (primaryPurpose SAP_HANA_Knowledge_Graph "Graph engine for storing/querying connected data in SAP HANA Cloud")
  (deploymentEnvironment SAP_HANA_Knowledge_Graph SAP_HANA_Cloud)
  (aiEnablementLevel SAP_HANA_Knowledge_Graph Medium)

  (cl-comment "SAP BDC Knowledge Graph Assertions")
  (Technology SAP_BDC_Knowledge_Graph)
  (primaryPurpose SAP_BDC_Knowledge_Graph "Business-context-aware graph for AI-driven process automation")
  (deploymentEnvironment SAP_BDC_Knowledge_Graph SAP_BTP)
  (aiEnablementLevel SAP_BDC_Knowledge_Graph VeryHigh)

  (cl-comment "General Inference Rule")
  (forall (x)
    (if (and (Technology x)
             (deploymentEnvironment x SAP_BTP)
             (aiEnablementLevel x VeryHigh))
        (BusinessContextAware x)))
)

6 Conclusion

While modern enterprise platforms such as SAP Business Data Cloud have successfully adopted RDF triple stores to build context-aware Knowledge Graphs, standard binary triple models introduce significant overhead when representing complex -ary business transactions and nested modal contexts. As demonstrated in this analysis, adopting Conceptual Graphs (CGs) directly resolves these structural bottlenecks through native -ary relations, first-class nested contexts, and graph-projection reasoning.

Furthermore, grounding enterprise architectures in ISO/IEC 24707 Common Logic provides the deterministic First-Order Logic rigour required for trustworthy neuro-symbolic AI and autonomous agent orchestration. By formalising enterprise semantic layers in standardised serialisations like CGIF and CLIF, enterprise architectures can bypass the combinatorial integration challenges of unconstrained open predicates while guaranteeing verifiable, hallucination-free decision support across complex business domains.

References

  1. ISO/IEC. 2018. ISO/IEC 24707:2018 Information technology — Common Logic (CL): A framework for a family of logic-based languages. International Organization for Standardization.
  2. Polovina, Simon. 2007. “An Introduction to Conceptual Graphs.” In Conceptual Structures: Knowledge Architectures for Smart Applications. Proceedings of the 15th International Conference on Conceptual Structures (ICCS 2007), edited by Uta Priss, Simon Polovina, and Richard Hill, vol. 4604. Lecture Notes in Artificial Intelligence. Springer-Verlag. https://doi.org/10.1007/978-3-540-73681-3_1.
  3. Sowa, John F. 1984. Conceptual Structures: Information Processing in Mind and Machine. Addison-Wesley.
  4. Stakelum, James Lee. 2026. The Architecture That Makes AI Trustworthy Wasn’t Invented. It Was Discovered. Review of the Ontology Summit 2026 Presentation by Arun Majumdar and John F. Sowa.