# Everything Is Connected
**作者**: 𝗿𝗮𝗺𝗮𝗸𝗿𝘂𝘀𝗵𝗻𝗮— 𝗲/𝗮𝗰𝗰
**日期**: 2026-04-11T11:52:58.000Z
**来源**: [https://x.com/techwith_ram/status/2042933925832724538](https://x.com/techwith_ram/status/2042933925832724538)
---
I think the title is a bit philosophical. Isn't it?
Don't worry, you will get it at the end. So, imagine a scene: you are standing in a bookshop. You pick up a novel. On the cover it says the author's name. You happen to know that author also teaches at a university in your city. That university is located near a park where there is a statue of a poet who was a contemporary of a character in the very novel you are holding.
You made five connections in a few seconds, entirely without effort. This is how human knowledge actually works. It does not live in isolated boxes. It is a dense, tangled network of associations, and our brains are extraordinarily good at navigating it.
The question is, how do we teach a computer to do the same thing?
Why do traditional databases fall short?
Traditional relational databases organize information into tables: rows and columns. A library database might have a Books table, an Authors table, and a Publishers table. To connect them, you write a JOIN query; you tell the system, "Match the author_id in Books with the id in Authors."
This works wonderfully for a fixed, predictable set of relationships. But it breaks down when:
- Relationships vary per entity: A book has an author. But a scientific paper has co-authors, an institution, a funding body, and a dataset. These cannot all live comfortably in the same table structure.
- The schema changes constantly: In a traditional database, adding a new type of relationship often requires restructuring the entire schema. In a graph, you simply add a new edge type.
- Traversing many hops is expensive: Finding "all books written by authors who studied under professors who won the same prize" requires multiple nested joins. In a graph, this is a natural path traversal.
## What is a knowledge graph?
It is a structured representation of real-world entities & the relationships between them, stored as a network (or graph) rather than a table.
It consists of:
- Nodes (also called vertices or entities) These represent things: a person, a city, a concept, a product, a chemical compound. Each node has a unique identity.
- Edges (also called relationships or predicates) These connect two nodes and describe the nature of their connection. Edges are always directed and always labeled. "Marie Curie BORN_IN Warsaw" is a different fact from "Warsaw BORN_IN Marie Curie"—direction matters.
- Properties (also called attributes or literals) Both nodes and edges can carry additional data: a person node might have a birth year property; a "WORKED_AT" edge might carry a start and end date.
Designed by author: @techwith_ram
## The triple: the smallest unit of knowledge
The fundamental building block of a knowledge graph is the triple: a statement made of three parts.
Designed by author: @techwith.ram
Three sentences. Eleven words. And from them, a machine can already infer that Marie Curie was born in the capital of a European country. That kind of chained reasoning is the superpower of the knowledge graph.
## Building a Knowledge Graph
A real-world example: a city neighbourhood
Let us build a small knowledge graph together. Imagine we want to represent the knowledge contained in this single paragraph:
> The Blue Door is a cafe on Elm Street. It is owned by Ramakrushna, who also owns the bakery next door called Morning Light. The Blue Door is known for its Ethiopian coffee, which is sourced from the Yirgacheffe region. Morning Light supplies pastries to three local hotels, including the Grand Elm.
Designed by Author: @techwith_ram
Notice something important: once this graph exists, questions that were never explicitly answered in the original text become answerable. For example: "Is Ramakrushna connected to the Grand Elm Hotel?" The text never says so directly, but the graph reveals the path: Ramakrushna owns Morning Light, and Morning Light supplies the Grand Elm. Two hops. One answer.
## Ontology: the grammar of your graph
A knowledge graph without an ontology is like a library without a cataloguing system. Ontology is the formal description of what kinds of things exist in your domain and what kinds of relationships are possible between them.
Think of it as the rules of the game. An ontology might say, "In our graph, a Person can OWN a Business, but a City cannot." This prevents nonsense from entering your data.
## Classes and instances
In an ontology, we distinguish between classes (categories of things) and instances (specific things). "Person" is a class. "Marie Curie" is an instance of that class. "City" is a class. "Warsaw" is an instance. This distinction lets us write rules at the class level that apply to every instance automatically.
Adding context with named graphs:
Sometimes a single fact is not enough. You need to say when something was true, or according to whom. This is done using named graphs essentially, a wrapper around a set of triples that adds provenance and temporal context.
> APJ Abdul Kalam President of India.
... is only valid from 2002 to 2007. The context provides the time range.
Without this temporal layer, your graph would assert things that are no longer true, with no way to distinguish current facts from historical ones.
## Querying the Graph
The real power of a knowledge graph emerges when you query it. Instead of asking, "Give me row 47 from this table," you ask questions that follow chains of relationships. Questions like:
"Find all scientists who were born in Europe and won a Nobel Prize in a natural science discipline." This traverses BORN_IN, LOCATED_IN, WON, and FIELD_OF edges in a single query.
Which products are manufactured by companies owned by someone who also serves on the board of our company? ". This is a 4-hop traversal that would require multiple joins in SQL but is natural in a graph query language like SPARQL or Cypher.
Designed by author: @techwith_ram
Path query: Shakespeare -- [2 hops] -- Academy Award
Perhaps the most intellectually satisfying feature of knowledge graphs is inference: the ability to derive new facts that were never explicitly stored, purely by applying logical rules to what is already there.
A simple example
Suppose your graph contains these two facts:
Anna is parent of Ben
Ben is parent of Clara
You have also defined an ontology rule: "If X is parent of Y, and Y is parent of Z, then X is grandparent of Z."
The graph can now be derived without you explicitly adding it:
Anna is the grandparent of Clara
Scale this idea to millions of facts and hundreds of rules, and you have a system that can surface knowledge that no human explicitly put there.
I'm someone who works in the healthcare sector; let me give you an example from there:
> A medical knowledge graph might store "Drug A inhibits Enzyme B" and "Enzyme B is required for the synthesis of Protein C, which is overexpressed in Cancer D." From these two facts, inference can automatically suggest that Drug A may be a candidate treatment for Cancer D, even if no researcher has yet made that explicit connection.
## Knowledge Graphs vs Other Data Models
AI Generated by @techwith_ram
When should you choose a knowledge graph?
KG is not always the right tool. It shines in specific situations. Here is a simple rule: if the relationships between your data are as important as the data itself, consider a knowledge graph.
Use a knowledge graph when ::: Your data comes from many heterogeneous sources. Your schema evolves frequently. You need to traverse chains of relationships. You want to derive new facts by reasoning over existing ones.
Stick with a relational database when ::: Your data is highly tabular and stable. Your queries are simple lookups or aggregations. You need transactional guarantees (ACID) above all else. Your team is SQL-proficient, and your data fits the table model cleanly.
So have you heard about Google Knowledge Graph?
Google Knowledge Graph
The most famous knowledge graph in the world is the one built by Google. Launched in 2012, it powers the information boxes you see on the right side of search results, those cards that tell you who a person is, what they are known for, where they were born, and what other entities are related to them.
When you search for "Albert Einstein," Google does not just find web pages containing that string. It retrieves a structured entity, a node in a graph that carries facts about Einstein and links him to other entities: his theories, his university, his colleagues, his era.
I mean, if you will hear the scale of it, you will be shocked.
It is estimated to contain tens of billions of facts across hundreds of millions of entities. It underpins not just search results, but also Google Assistant, Google Maps, and an increasing number of AI features.
Some of the most consequential knowledge graphs are invisible to the public. In biomedical research, knowledge graphs are used to integrate data from:
- Drug databases: Chemical structures, mechanisms of action, side effects, interactions.
- Genomic databases: Gene-disease associations, protein functions, pathways.
- Clinical literature Published research on treatment outcomes and case studies.
By connecting these sources in a single graph, researchers can identify unexpected drug repurposing opportunities, predict adverse drug interactions, and understand disease mechanisms that span multiple biological layers.
How Does an Enterprise Knowledge Graph Work?
AI Generated by @techwith_ram
Final Thought
Knowledge graphs are powerful, but they are not magic. Understanding their limitations is as important as understanding their strengths.
No knowledge graph is complete. Wikidata, one of the largest public knowledge graphs, has millions of entities but enormous gaps; most people, places, and events in history are not represented or are represented incompletely.
More dangerously, knowledge graphs can contain incorrect facts. If the data source was wrong, or if the extraction process misread a piece of text, the graph will confidently assert something false. And because inference can propagate that error through the graph, one bad fact can corrupt many derived conclusions.
Hope you like the article; comment on what you feel or if you want to share something.
Follow @techwith_ram for more such posts.
## 相关链接
- [𝗿𝗮𝗺𝗮𝗸𝗿𝘂𝘀𝗵𝗻𝗮— 𝗲/𝗮𝗰𝗰](https://x.com/techwith_ram)
- [@techwith_ram](https://x.com/techwith_ram)
- [17K](https://x.com/techwith_ram/status/2042933925832724538/analytics)
- [@techwith_ram](https://x.com/@techwith_ram)
- [@techwith](https://x.com/@techwith)
- [@techwith_ram](https://x.com/@techwith_ram)
- [@techwith_ram](https://x.com/@techwith_ram)
- [@techwith_ram](https://x.com/@techwith_ram)
- [@techwith_ram](https://x.com/@techwith_ram)
- [@techwith_ram](https://x.com/@techwith_ram)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [7:52 PM · Apr 11, 2026](https://x.com/techwith_ram/status/2042933925832724538)
- [17.9K Views](https://x.com/techwith_ram/status/2042933925832724538/analytics)
- [View quotes](https://x.com/techwith_ram/status/2042933925832724538/quotes)
---
*导出时间: 2026/4/12 22:37:59*
---
## 中文翻译
# 万物互联
**作者**: 𝗿𝗮𝗺𝗮𝗸𝗿𝘂𝘀𝗵𝗻𝗮— 𝗲/𝗮𝗰𝗰
**日期**: 2026-04-11T11:52:58.000Z
**来源**: [https://x.com/techwith_ram/status/2042933925832724538](https://x.com/techwith_ram/status/2042933925832724538)
---
我觉得这个标题有点哲学意味，不是吗？
别担心，读到最后你就明白了。那么，想象一个场景：你正站在一家书店里。你拿起一本小说，封面上印着作者的名字。你恰好知道这位作者在你所在城市的一所大学任教。那所大学位于一个公园附近，公园里有一座诗人的雕像，而这位诗人与 你手中这本小说里的某个人物是同时代的人。
你在几秒钟内建立了五个连接，完全不费吹灰之力。这就是人类知识真正的运作方式。它并不是存在于一个个孤立的盒子里，而是一张密集、缠绕的关联网络，而我们的大脑极其擅长在其中穿行。
问题是，我们如何教会计算机做同样的事情？
为什么传统数据库力有不逮？
传统的关系型数据库将信息组织成表格：行与列。一个图书馆数据库可能包含一个 Books（图书）表、一个 Authors（作者）表和一个 Publishers（出版社）表。要把它们连接起来，你需要编写一个 JOIN 查询；你要告诉系统：“把 Books 表中的 author_id 与 Authors 表中的 id 进行匹配。”
这在关系固定、可预测的情况下效果很好。但在以下情况下就会出问题：
- 每个实体的关系各不相同：一本书有一个作者。但一篇科学论文有多位合著者、一个所属机构、一个资助方和一个数据集。这些无法都舒适地放进同一张表结构中。
- 模式（schema）不断变化：在传统数据库中，添加一种新的关系类型往往需要重构整个模式。而在图中，你只需添加一种新的边类型。
- 多跳遍历的代价高昂：查找“所有其作者曾师从获得过同一奖项的教授的图书”需要多层嵌套连接。而在图中，这只是一次自然的路径遍历。
## 什么是知识图谱？
它是对现实世界实体及其实体之间关系的结构化表示，以网络（或图）而非表格的形式存储。
它由以下部分组成：
- 节点（也称为顶点或实体）：这些代表事物：一个人、一座城市、一个概念、一件产品、一种化合物。每个节点都有唯一的身份标识。
- 边（也称为关系或谓词）：这些连接两个节点，并描述它们之间联系的性质。边总是有方向的，且总是带标签的。“居里夫人 BORN_IN 华沙”与“华沙 BORN_IN 居里夫人”是两个不同的事实——方向很重要。
- 属性（也称为特性或字面量）：节点和边都可以携带额外的数据：一个人物节点可能有出生年份属性；一条 "WORKED_AT"（任职于）边可能带有开始和结束日期。
由作者设计：@techwith_ram
## 三元组：知识的最小单元
知识图谱的基本构建单元是三元组：由三部分组成的陈述。
由作者设计：@techwith.ram
三个句子。十一个词。仅凭这些，机器已经可以推断出居里夫人出生于一个欧洲国家的首都。这种链式推理正是知识图谱的超级能力。
## 构建知识图谱
一个现实世界的例子：一个城市街区
让我们一起构建一个小型知识图谱。假设我们想用图来表示下面这段话所包含的知识：
> Blue Door 是榆树街上的一家咖啡馆。它由 Ramakrushna 拥有，Ramakrushna 还拥有隔壁一家名为 Morning Light 的面包店。Blue Door 以其埃塞俄比亚咖啡而闻名，这些咖啡产自耶加雪菲地区。Morning Light 向包括 Grand Elm 在内的三家本地酒店供应糕点。
由作者设计：@techwith_ram
请注意一个重要的点：一旦这个图存在了，那些在原文中从未被明确回答的问题就变得可以回答了。例如：“Ramakrushna 与 Grand Elm 酒店有联系吗？”原文从未直接说明，但图揭示了路径：Ramakrushna 拥有 Morning Light，而 Morning Light 向 Grand Elm 供应货物。两跳。一个答案。
## 本体：你的图的语法
没有本体的知识图谱就像没有编目系统的图书馆。本体是对你的领域中存在哪些类型的事物，以及它们之间可能存在哪些类型的关系的形式化描述。
把它想象成游戏规则。一个本体可能会规定：“在我们的图中，一个人（Person）可以拥有（OWN）一家企业（Business），但一座城市（City）不行。”这可以防止无意义的内容进入你的数据。
## 类与实例
在本体中，我们区分类（事物的类别）和实例（具体的事物）。“人（Person）”是一个类。“居里夫人”是该类的一个实例。“城市（City）”是一个类。“华沙”是一个实例。这种区分让我们可以在类的层面编写规则，这些规则会自动应用于每一个实例。
使用命名图添加上下文：
有时单一的事实还不够。你需要说明某事在何时为真，或者依据谁的说法。这可以通过命名图来实现——本质上，它是对一组三元组的封装，用于添加来源和时间上下文。
> APJ Abdul Kalam 印度总统。
……仅在 2002 年至 2007 年间有效。上下文提供了时间范围。
如果没有这个时间层，你的图会断言一些已经不再为真的内容，而无法区分当前事实与历史事实。
## 查询图
知识图谱的真正威力在你查询它时才会显现。你不再问“给我这张表的第 47 行”，而是提出沿着关系链进行的问题。例如：
“查找所有出生于欧洲并在自然科学学科中获得过诺贝尔奖的科学家。”这一查询在一次查询中遍历了 BORN_IN、LOCATED_IN、WON 和 FIELD_OF 这些边。
哪些产品是由那些同时在我们公司董事会任职的人所拥有的公司制造的？"。这是一个4跳遍历，在SQL中需要多个连接（join）才能实现，但在SPARQL或Cypher这类图查询语言中却很自然。
作者设计：@techwith_ram
路径查询：莎士比亚 -- [2跳] -- 奥斯卡金像奖
知识图谱在智力上最令人着迷的特性或许就是推理：仅通过将逻辑规则应用于已有的事实，就能推导出从未被显式存储的新事实。
一个简单的例子
假设你的图中包含这两个事实：
安娜是本的父母
本是克拉拉的父母
你还定义了一条本体规则："如果X是Y的父母，且Y是Z的父母，那么X是Z的祖父母。"
现在，无需你显式添加，图就可以推导出：
安娜是克拉拉的祖父母
将这个思路扩展到数百万条事实和数百条规则，你就拥有了一个能够揭示任何人类都未曾显式录入的知识体系。
我是医疗健康行业的从业者，让我给你举一个该领域的例子：
> 医学知识图谱可能存储了"药物A抑制酶B"以及"酶B是蛋白质C合成所必需的，而蛋白质C在癌症D中过度表达"。从这两个事实出发，推理可以自动提示药物A可能是癌症D的候选治疗方案，即使还没有研究人员明确建立这种关联。
## 知识图谱与其他数据模型的对比
AI生成 @techwith_ram
什么时候应该选择知识图谱？
知识图谱并不总是正确的工具。它在特定场景下才大放异彩。这里有一条简单的规则：如果数据之间的关系与数据本身同等重要，就考虑使用知识图谱。
使用知识图谱的情形 ::: 你的数据来自许多异构数据源。你的模式频繁演进。你需要遍历关系链条。你希望通过在已有事实之上推理来推导新事实。
坚持使用关系型数据库的情形 ::: 你的数据高度表格化且稳定。你的查询是简单的查找或聚合。你最需要的是事务保证（ACID）。你的团队精通SQL，且数据能很好地契合表模型。
那么，你听说过谷歌知识图谱吗？
谷歌知识图谱
世界上最著名的知识图谱就是谷歌构建的那个。它于2012年推出，为你在搜索结果右侧看到的信息框提供支持，那些卡片告诉你一个人是谁、以什么闻名、出生于哪里，以及哪些其他实体与之相关。
当你搜索"阿尔伯特·爱因斯坦"时，谷歌不只是找到包含这个字符串的网页。它会检索出一个结构化实体——图中的一个节点，该节点承载着关于爱因斯坦的事实，并将他与许多其他实体关联起来：他的理论、他的大学、他的同事、他的时代。
我是说，如果你了解一下它的规模，你会大吃一惊。
据估计，它包含数百亿条事实，覆盖数亿个实体。它不仅支撑着搜索结果，还支撑着Google Assistant、Google地图以及越来越多的AI功能。
一些最重要的知识图谱是公众看不见的。在生物医学研究中，知识图谱被用于整合来自以下来源的数据：
- 药物数据库：化学结构、作用机制、副作用、相互作用。
- 基因组数据库：基因-疾病关联、蛋白质功能、通路。
- 临床文献：关于治疗结果和病例研究的已发表研究。
通过在单一图谱中连接这些来源，研究人员可以发现意想不到的药物重定位机会、预测药物间的不良相互作用，并理解跨越多个生物层面的疾病机制。
企业知识图谱是如何工作的？
AI生成 @techwith_ram
最后的思考
知识图谱很强大，但并非魔法。理解它们的局限性与理解它们的优势同等重要。
没有任何知识图谱是完备的。Wikidata作为最大的公共知识图谱之一，拥有数百万个实体，但存在巨大的缺口；历史上大多数人、地点和事件都没有被收录，或者收录得不完整。
更危险的是，知识图谱可能包含错误的事实。如果数据源有误，或者提取过程误读了一段文本，图谱就会言之凿凿地断言某些错误内容。而且由于推理会将这种错误在图中传播，一条错误的事实可能破坏许多推导出的结论。
希望你喜欢这篇文章；欢迎在评论中分享你的感受或想说的话。
关注@techwith_ram获取更多此类帖子。
## 相关链接
- [𝗿𝗮𝗺𝗮𝗸𝗿𝘂𝘀𝗵𝗻𝗮— 𝗲/𝗮𝗰𝗰](https://x.com/techwith_ram)
- [@techwith_ram](https://x.com/techwith_ram)
- [17K](https://x.com/techwith_ram/status/2042933925832724538/analytics)
- [@techwith_ram](https://x.com/@techwith_ram)
- [@techwith](https://x.com/@techwith)
- [@techwith_ram](https://x.com/@techwith_ram)
- [@techwith_ram](https://x.com/@techwith_ram)
- [@techwith_ram](https://x.com/@techwith_ram)
- [@techwith_ram](https://x.com/@techwith_ram)
- [@techwith_ram](https://x.com/@techwith_ram)
- [升级至高级版](https://x.com/i/premium_sign_up)
- [2026年4月11日 下午7:52](https://x.com/techwith_ram/status/2042933925832724538)
- [17.9K 次浏览](https://x.com/techwith_ram/status/2042933925832724538/analytics)
- [查看引用](https://x.com/techwith_ram/status/2042933925832724538/quotes)
---
*导出时间: 2026/4/12 22:37:59*
