[#]: subject: "Friend of a Friend: The Facebook That Could Have Been" [#]: via: "https://twobithistory.org/2020/01/05/foaf.html" [#]: author: "Two-Bit History https://twobithistory.org" [#]: collector: "lujun9972" [#]: translator: "aREversez" [#]: reviewer: "wxy" [#]: publisher: "wxy" [#]: url: "https://linux.cn/article-15334-1.html" FOAF：本可以成为 Facebook ====== ![][0] > 我把自己的社交网络写进 FOAF 文件，这就是变革之始。—— 互联网之父蒂姆·伯纳斯·李（2007） FOAF 标准（朋友的朋友Friend of a Friend），是一个可以追溯到本世纪初的网络标准，目前它基本上已经不再使用了，或者说被人们忘记了，亦或者说已经被取代了 [^1]。它暗示了，假如 Facebook 没有征服世界的话，FOAF 将会定义我们今天所用的社交网络。不过在开始探讨这一网络标准之前，我想先来谈一谈纽约地铁。 目前，纽约地铁的唯一管理机构是 大都会运输署Metropolitan Transportation Agency（简称 MTA）。MTA 垄断了纽约市的地铁交通。在纽约乘地铁必须先从 MTA 购买车票，否则属于非法行为。也就是说，MTA 在地铁行业没有任何竞争对手。 不过，以前可不是这样。说起来可能有些让人吃惊，纽约市的地铁交通曾由两家企业相互竞争，共同运营。跨区捷运公司Inter-borough Rapid Transit Company（IRT）的势力范围是穿过曼哈顿的线路，布鲁克林-曼哈顿运输股份有限公司Brooklyn-Manhattan Transit Corporation（BMT）管理的则是布鲁克林区内的线路，其中也有部分线路延伸到了曼哈顿。1932 年，纽约市开通使用了自己的服务，称为独立地铁系统，与 IRT 和 BMT 展开竞争，所以当时纽约共有三家不同公司控制着市内地铁交通。 可能会有人觉得这样的地铁运营效率不高。事实上也确是如此。由于 IRT 和 BMT 投入使用的列车宽度不同，所以在不同的运营系统之间建造换乘站十分困难。此外，乘客换乘时还需向不同的运营商支付费用，这就意味着在换乘站至少要设置两个不同的检票区域。后来，纽约市于 1940 年接管了 IRT 和 BMT，将整个纽约市的地铁交通置于一家运营商的管理之下，不过由于此前分而治之而造成的效率低下问题时至今日依然存在：能在 BMT 的线路上（如 A、C、E 号线）运行的列车无法在 IRT 的线路上（如 1、2、3 号线）运行，因为 IRT 的线路隧道比较窄。因此，MTA 不得不同时管理这两种互不兼容的列车系统，由此带来的支出可能远比世界上其他单一隧道宽度的地铁系统要多得多。 IRT 和 BMT 之间的竞争所造成的历史遗留问题告诉我们，地铁系统本身就趋向于垄断经营。相比较于两家运营商相互竞争，只有一家运营商更能解决问题。乘客们虽然失去了选择的余地，但再也不用担心带了一张地铁卡却忘记了另一张的问题。 那么，地铁和社交网络又有什么关系呢？我在想，Facebook 是否和 MTA 一样都有自然垄断的属性呢？事实上，无论是自然垄断还是非自然垄断，Facebook 貌似确有垄断能力。当然它垄断的不是社交媒体本身（我在 Twitter 上面花的时间更多），而是垄断了与现实中认识的人之间的线上联系。Facebook 能够垄断所谓的“社交图谱”；如果我不用担心会失去与别人的联系方式，那我明天就会卸载 Facebook。我对 Facebook 对我身上的这种垄断权力感到非常气愤。不过，我却不会生 MTA 的气，即便从字面上和隐喻上来讲，纽约市地铁都是一堆焚烧着的、火舌乱窜的垃圾。说到底，我愤怒是因为我觉得不同于 MTA 的自然垄断，Facebook 的垄断属于非自然垄断。 我的意思是，如今 Facebook 之所以能拥有所有人的社交数据，因为它碰巧是第一个做大做强、确立巨头地位的社交平台，而不是因为其他社交平台难以或者无法与之竞争。不过，难道真是因为这样吗？许多事实告诉我们，原因并非如此。Facebook 仅仅是先入为主，还是它提供的服务真的比其他社交平台要好？如果你想联系老朋友，只有 Facebook 这一个平台的话，不会方便许多吗？在一个有几个 “Facebook” 相互竞争的情况下，如果你和你男朋友 Facebook 上面的感情状态都显示“交往中”，但是他始终没来得及更新他在 VisageBook 上的感情状态，那上面现在还显示着他和他大学前任的关系，那么这种情况意味着什么呢？人们信任的又是哪个社交网站呢？如果社交网站有很多，难道在填写信息上面不会很耗时间吗？ 过去几年，由于中心化社交网络的缺陷暴露出来，许多人尝试构建去中心化的平台。基于开放标准，去中心化平台有望建立互通的社交网络生态（比如 [Fediverse][2]）。可惜的是，其中没有一个平台能够取代主流社交网络。一个比较明显的原因是 网络效应network effects的力量：既然每个人都在用 Facebook，那么任何想要放弃 Facebook 的人都将会付出巨大的代价。有人会说，这一点恰恰证明了社交网络属于自然垄断行业。但我想说，Facebook、Twitter 等平台是自己选择封闭起来的。此外，鉴于人们已经设想出社交网络的互通性，并且付诸实践，那么封闭的社交平台引发的网络效应就无法证明社交网络具有自然垄断属性。 因此，在我看来，真正的问题是：之所以 Facebook 等平台到现在仍是主流社交网络，仅仅是因为网络效应，还是说与只有一家运营商的地铁系统一样，单一的主流社交网络效率更高？ 最后，这些问题让我想起了 FOAF。尽管人们似乎已经忘记了 FOAF 标准，但是早在 Facebook 出现之前，人们就尝试使用 FOAF 建立开放的、去中心化的社交网络。如果过去有哪个去中心化社交网络有机会早于 Facebook 占领如今它驻守的阵地，那只可能是 FOAF。考虑到世界上大部分人都有 Facebook 账号，而且了解 FOAF 的人相对较少，我们是否可以得到如下结论：同地铁一样，社交网络也有中心化和自然垄断的性质；亦或者，FOAF 项目说明，尽管去中心化社交网络可行，但由于其他原因，无法获得人们的广泛支持。 ### 早期社交媒体的未来 FOAF 项目诞生于 2000 年，旨在建立一套表示个人身份以及人与人之间关系的通用标准。在今天看来，这一雄心勃勃的项目可能会让人感到惊讶，但是在上世纪末本世纪初，这样的想法再寻常不过了。当时网络Web（当时人们仍然这样称呼它）刚刚击败了 美国在线America Online 与 [Prodigy][3] 等封闭系统。这让人很自然地想到，计算机领域的创新发展必须要保持开放、基于标准，而且这也正是网络的特点。 许多人认为，网络下一场重头戏会是 语义网Semantic Web。我有篇文章介绍了关于语义网概念与运行原理的设想，所以这里不再赘述。但是我会简单谈谈推动人们研究语义网技术的愿景，因为 FOAF 标准正是这一愿景在社交网络方面的应用。 一篇题为 《[谷歌如何击败亚马逊和易贝，朝着语义网进军][5]How Google beat Amazon and Ebay to the Semantic Web》 的文章很好地描绘了语义网这一崇高理想。文章写于 2002 年，作者是 Paul Ford。这篇文章设想了 2002 年至 2009 年的情景：通过使用语义网，谷歌取代了亚马逊和易贝，成为电商平台主导者。文章指出，在未来，如果你想买东西，比如说一把二手的马丁吉他，可以在谷歌中输入 `buy:martin guitar`。根据你的邮编，谷歌会告诉你附近哪些人在卖马丁吉他。谷歌之所以可以获取卖家及其吉他的信息，是因为它可以读取资源描述框架标记语言（RDF），该语言是语义网的核心技术，用于描述资源之间的关系。人们可以将 RDF 内容嵌入网页，能实现很多用途，比如给要卖的东西打广告。Ford 预测，随着使用这种方式搜索和售卖商品的人数增加，亚马逊和易贝将失去它们在电商领域近乎垄断的地位。如果可以搜索全网，又有谁会执着于某个封闭的数据库呢？Ford 写道，即便是谷歌，最终也会失势。因为理论上，任何一个人都可以检索网络，查阅 RDF，提供类似于谷歌的搜索功能。起码，如果谷歌打算对语义网上的每笔交易按一定比例收取费用，以此盈利，那么以后随着相关竞争越来越激烈，谷歌的抽成比例很有可能会被迫降低。 Ford 所设想的未来是将 RDF 应用于电商领域，不过 RDF 更振奋人心的地方在于，它或许可以应用于各个领域。RDF 标准以及一系列相关标准，一旦得到广泛应用，被认为可以掀开基于数据库的软件服务的发展，如同 HTML 为文档出版带来新的发展契机一般。 RDF 以及其他语义网技术似乎准备立刻接管的另一个领域是社交网络。FOAF 项目最初的名字是“RDF 网络环RDF Web Ring”，是语义网发展的产物，旨在实现语义网的设想。FOAF 自诞生之初就被人们看好，有人甚至认为，FOAF 必定会淘汰掉其他社交网站。2004 年《卫报》的一篇文章这样介绍该项目： > 最初是 1996 年，SixDegrees 开始运营；接着是去年，出现了 Friendster；上周是 Orkut；下周 Flickr 也会登上舞台。这些网站不胜枚举，都是为了建立社交网络。如今，它们处在互联网发展的最前沿。但是，如果它们无法提供更实质性的好处，在 FOAF 标准得到广泛应用之后，它们就会很难存活下去。[^2] 文章继续指出，社交网络面临的最大问题就是社交网站数量过多。这就需要一种能够将所有这些网站连接起来的手段。可行方案就是 FOAF ，它终将变革整个社交网络。 根据该文章，FOAF 可将不同的社交网站紧密连接起来，实现途径有三个要点： * FOAF 将创建机器可读的社交数据格式，可为各个社交网站识别读取，避免让用户在不同的网站上重复输入信息。 * FOAF 标准下，联系人Contacts（个人信息管理程序）可生成上述格式的文件，供用户在各社交网站使用。 * FOAF 标准下，这种机器可读的文件可寄放在个人主页上，可为各社交网站读取。这样一来，用户只需将修改过的信息推到自己的主页，其他平台就会同步更新。 在今天可能难以想象，但在 2004 年，至少在熟悉技术的网民和技术专栏记者看来，当时社交网络并不算少，但是每个网络的用户群体都很小。考虑到这个问题，虽然对现在的我们来说很陌生，我们就会明白为什么需要建立单一标准是有意义的，这个标准可以使网络的激增不再是一个负担。 ### FOAF 规范 根据 FOAF 项目官网现有的介绍，FOAF 是“一种计算机语言，用于生成与人相关的各种条目的字典，条目以结构化数据的形式储存”。2000 年，FOAF 的创始人 Dan Brickley 和 Libby Miller 发表了一份关于该项目目标的文件，给出了不同的解释，强调了 FOAF 的最终目标：作为工具，FOAF 可让计算机像人类一样读取用户主页的个人信息 [^3]。FOAF 将会“帮助网络提供当前只有中心化平台才能提供的服务”[^4]。通过为个人以及人际关系定义一个标准词汇，FOAF 可以理解用户输入的内容，比如“找找今天推荐的医院医疗人员”，或者“找找曾与我合作撰写过文件的人最近发表的文章”。 由于 FOAF 是标准化的词汇表，所以该项目最重要的成果莫过于 FOAF 规范。FOAF 规范规定了 RDF 类 和 RDF 属性（这里我不再解释什么是 RDF，如果感兴趣可查阅 [我关于语义网的文章][4]）。RDF 的类由 FOAF 规范规定，表示要描述的对象，比如人（`Person` 类）和组织（`Organization` 类）。RDF 属性由 FOAF 规范规定，表示针对不同对象所做的逻辑声明。例如，一个人可以有一个名字（`givenName` 属性）、一个姓氏（`familyName` 属性），可能还有人格类型（`myersBriggs` 属性）以及与他人的距离或者位置信息（`based_near` 属性）。FOAF 规范的思想是，这些类和属性要足以表示人们在个人主页上显示的身份信息和朋友信息。（LCTT 译注：Myers–Briggs 即迈尔斯布里格斯类型指标，是一种人格类型理论模型。） FOAF 规范给出了一份 FOAF 文档的范例。该实例的格式是 XML，不过也可以使用 JSON 等格式进行编写： ``` Dan Brickley ``` 这份 FOAF 文件对一个人进行了描述，他的名字叫做 Dan Brickley（该规范的作者之一），他的主页在 `http://danbri.org`，他还有个叫做“open ID”的东西，还有一张图片在 `/images/me.jpg` —— 估计是 Brickley 的主页地址的相对链接。FOAF 的元素名称都会有 `foaf:` 前缀，表示它们是 FOAF 命名空间的一部分。相应地，RDF 的元素名称前面也都会有 `rdf:`。 为了说明 FOAF 不限于 XML 格式，这里从维基百科摘取了一个相似的例子，格式为 JSON-LD [^5]： ``` { "@context": { "name": "http://xmlns.com/foaf/0.1/name", "homepage": { "@id": "http://xmlns.com/foaf/0.1/workplaceHomepage", "@type": "@id" }, "Person": "http://xmlns.com/foaf/0.1/Person" }, "@id": "https://me.example.com", "@type": "Person", "name": "John Smith", "homepage": "https://www.example.com/" } ``` 上面这份 FOAF 文件也描述了一个人，他的名字叫 John Smith，他的主页在 `www.example.com`。 理解 FOAF 原理的最好方法可能就是体验一下 [FOAF-a-matic][10]，一个在线生成 FOAF 文档的工具。你可以在工具页面的表单里输入自己的相关信息，创建表示自己的 FOAF 文档（XML 格式）。FOAF-a-matic 说明了 FOAF 是如何避免在注册不同社交网站账号时重复输入社交信息的麻烦：如果每个社交网站都可以读取 FOAF，你只需要在没有注册过帐号的网站上引用你在 FOAF-a-matic 生成的 FOAF 文档，就可以注册一个新帐号了。 下面这个实例是我用 FOAF-a-matic 生成的稍微复杂一些的例子，表示我自己： ``` Sinclair Target Sinclair Target John Smith ``` 本例中，主要信息之前有很多其他内容，用于设置文档使用的各种 XML 命名空间。其中就有文档生成工具的信息，这样用户就能明白出了问题要向谁进行反馈。`foaf:Person` 元素给出了我的名字、电子邮箱和主页。其中嵌套了 `foaf:knows` 元素，说明我有个叫 John Smith 的朋友。 该例还体现了 FOAF 文档的另外一个重要功能：相互关联。还记得之前 John Smith 的例子吗？他的主页在 `www.example.com`。在我的这个例子中，我将 John Smith 列在了 `foaf:person` 元素里，上一级元素是 `foaf:knows`，表示我认识的人。此外，我还加入了 `rdfs:seeAlso` 元素，放了 John Smith 主页的 FOAF 文档链接。由于加入了这一链接，程序在读取我的 FOAF 文档时，就能根据该链接读取他的 FOAF 文档，查找到更多关于 John Smith 的信息。在之前 John Smith 的 FOAF 文档里，John 并没有提供任何有关朋友的信息（包括我在内），这意味着程序无法确定我们两人之间的朋友关系。但如果他加入了朋友信息，程序在读取我的文档之后，不仅会发现我，也会发现 John、他的朋友、他的朋友的朋友，以此类推，直到程序穷尽我和 John 各自的社交图谱。 对于使用过 Facebook 的人来说这似乎很熟悉，也就是说，这个功能对你来说也应该很熟悉。FOAF 没有 `foaf:wall` 属性和 `foaf:poke` 属性，无法完美复制 Facebook 的功能。很明显，FOAF 也没有漂亮的蓝色界面，无法为用户提供可视化的 FOAF 社交网络，它只是一个词汇表。不过，Facebook 的核心功能（我认为这正是 Facebook 垄断能力的关键）在这里是以分布式的方式提供的。在 FOAF 标准下，好友可以将 FOAF 文档上传至个人主页，数字化展示他们真实的社交图谱，用户无需将个人数据的控制权交给 Facebook 这样一个中心化的数据库。要知道，由于对用户个人数据管理不当，扎克伯格大多数时间都在国会委员会前在向公众道歉。 ### 暂时搁置的 FOAF 浏览 FOAF 项目主页，你会发现在页面的右上角，有一张喜剧动画《飞出个未来Futurama》主角弗莱躺在休眠舱内的图片。这张图片是《飞出个未来》试播剧集的剧照，讲的是弗莱在 1999 年不小心跌进了低温休眠舱，直到 2999 年才再次苏醒过来的故事。我曾和 Brickley 在 Twitter 上简短地聊了一下，他告诉我，挂这张图片是为了告诉人们，未来 FOAF 项目目前“处于停滞状态”，尽管他希望将来有机会恢复这个项目，继续探索 21 世纪初关于网络运作方式的设想。 FOAF 从未像《卫报》期望的那般彻底改变社交网络。一些社交网站选择支持 FOAF 标准，比如 LiveJournal 和 MyOpera [^6]。FOAF 甚至还在 2004 年霍华德·迪恩Howard Dean竞选总统时发挥了一定作用：一群博主和程序员合力搭建起了一个将网站连接起来的网络，称其为“迪恩空间DeanSpace”，帮助迪恩竞选，并在网站上使用 FOAF 记录迪恩的支持者和帮助迪恩竞选的志愿者[^7]。不过，今天人们了解到 FOAF 主要还是因为它是 RDF 应用最为广泛的词汇表之一，而 RDF 正是现代网络的一个重要标准。如果在今天还能用到 FOAF 的话，可能就是谷歌“知识面板knowledge panels”所用技术的原型。知识面板是在用谷歌搜索时，出现在搜索结果右侧的一小块内容，会提供搜索关键词的基本信息。谷歌为推行其知识面板，使用了语义网项目的“后继者” schema.org 项目发布的词汇表[^8]。schema.org 用来描述人物的词汇表似乎有着 FOAF 的影子，两者的目的大多也是相同的。 那么，为什么 FOAF 还是失败了呢？为什么人们都在用 Facebook 呢？且不提 FOAF 只是一个简单的标准，没有 Facebook 那么丰富的功能，如果 FOAF 发展势头保持下去，很有可能就会出现相关软件和应用，带来像 Facebook 那样的体验。问题是，在 Facebook 还未发展到能与之分庭抗礼之时，FOAF 这股分布式社交网络的新生力量为什么没能得到广泛应用呢？ 恐怕这个问题可能没有唯一的答案，不过非要我说的话，我觉得最关键的一点是，只有在每个人都有个人网站的情况下，FOAF 才有意义。在上世纪末本世纪初，人们理所当然地觉得网络最终会出现这种情况，因为就我所知，互联网的早期用户多是高产的博客写手、参政的技术专家，他们都希望能有个自己的平台。但是，现实情况却是，普通用户并不愿意学习怎么搭建和运营网站。FOAF 允许你掌控自己的社交信息并将其推送到各类社交网络上，省去了到处注册账号的麻烦。如果你已经有了储存社交信息的个人网站，那么这个想法应该很诱人。但实际上，相比较于买域名、折腾 XML 文档，大多数人觉得填写信息、注册 Facebook 账号来得更容易些。 那么，这与我最初的问题（Facebook 是否属于自然垄断）有什么相关呢？我不得不承认，FOAF 的案例说明，社交网络 _的确_ 拥有自然垄断属性。 其实，关于用户不愿管理自己的数据这一问题，本身并没有那么重要，因为通过让普通用户在熟悉技术的用户所设置的节点上储存个人信息，[Mastodon][14] 等现代分布式社交网络已经解决了这个问题。这也表明，人们多么不愿意折腾复杂的东西。对去中心化社交网络来说，这无疑是个坏消息，因为相较于中心化网络，去中心化网络更为复杂，用户对此再清楚不过了。 对于 FOAF：如果我要写一个能读取个人网站上 FOAF 数据的程序，假设 Sally 的 FOAF 文档提到了 John Smith，说他的主页是 `example.com`；Sue 的 FOAF 文档也提到了 John Smith，说他的主页是 `example.net`。在这种情况下，我应该怎么办呢？到底是只有一个 John Smith 而他正好有两个主页呢，还是这两个 John Smith 是不同的人呢？如果两个 FOAF 文档中 John Smith 的邮箱都是 `johnsmith@gmail.com`，又该怎么办呢？这种身份问题是 FOAF 的软肋。在一封 2003 年的邮件里，Brickley 写道，由于不存在而且可能也不应该存在一个“全球性的身份识别系统”，FOAF 采取的方法只能是“多元的”[^9]。FOAF 用户的邮件地址和主页地址等部分属性具有特殊性，因为邮件地址和主页地址都是独一无二的。因此，这些内容不可能相同的属性可以将人们的多个 FOAF 文档合并起来（用 Libby Miller 的话来说，“挤”在一起）。不过这些特殊属性不存在所谓优先级的说法，所以前面 John Smith 的问题还是不好解决。换句话说，是该相信主页，判定他们不是同一个人呢？还是要相信邮件地址，判定他们是同一个人呢？我真的能够在不干扰到用户的前提下，写出一个程序，解决这类问题吗？ Facebook 拥有单一的数据库，不用顾虑政治性问题，有条件创建“全球性的身份识别系统”，给每个人发行独一无二的身份 ID，于是问题就迎刃而解了。 如果人们真的在乎对自己数据的持有权和掌控权，单是因为复杂难解应该不足以导致分布式社交网络的失败。但是 FOAF 的失败表明，人们从未重视过对自己数据的掌控权。正如一位博主所说，“所谓‘用户想要拥有自己的数据’只不过是一个想法，和实际应用没有关系”[^10]。如果用户对控制的重视程度不足以承受额外的复杂性，如果中心化系统比去中心化系统更为简单易用，如果中心化系统有发展为封闭系统的趋向，借此取得成功，从而享受网络效应带来的巨大效益，那么社交网络确实属于自然垄断。 即便如此，我认为地铁系统的案例和社交网络的案例仍存在不同之处。我可以欣然接受 MTA 对地铁交通的垄断，因为我希望地铁系统本身就应该是长期垄断行业。如果纽约地铁只有一家运营商，那么它只能是政府，至少在名义上，政府比没有竞争对手的私企更加负责。但是我却不希望社交网络属于自然垄断。地铁建好了基本上就是一成不变的，但数字世界却在不断演变发展。在今天，分布式社交网络也许比中心化网络更加复杂，就好比带两张地铁卡总是比只带一张要麻烦的多。不过，在未来，互联网会发生根本性变革，那时分布式技术将会更易于使用。 如果未来果真如此，FOAF 可能会作为建立分布式社交网络的第一次尝试为人们记住。在企业大型数据库所驱动的中心化网络时代结束之后，分布式网络将会得到人们的长期青睐。 _如果你喜欢这篇文章，欢迎关注推特 [@TwoBitHistory][28]，也可通过 [RSS 馈送][29] 订阅，获取更多最新文章。_ [^1]: 请注意，这里我没有用“消亡”一词。 [^2]: Jack Schofield, “Let’s be Friendsters,” The Guardian, February 19, 2004, accessed January 5, 2020, .  [^3]: Dan Brickley and Libby Miller, “Introducing FOAF,” FOAF Project, 2008, accessed January 5, 2020, .  [^4]: 同上。 [^5]: Wikipedia contributors, “JSON-LD,” Wikipedia: The Free Encyclopedia, December 13, 2019, accessed January 5, 2020, .  [^6]: “Data Sources,” FOAF Project Wiki, December 11 2009, accessed January 5, 2020, .  [^7]: Aldon Hynes, “What is Dean Space?”, Extreme Democracy, accessed January 5, 2020, .  [^8]: “Understand how structured data works,” Google Developer Portal, accessed January 5, 2020, .  [^9]: tef, “Why your distributed network will not work,” Progamming is Terrible, January 2, 2013, .  [^10]: Dan Brickley, “Identifying things in FOAF,” rdfweb-dev Mailing List, July 10, 2003, accessed on January 5, 2020, .  -------------------------------------------------------------------------------- via: https://twobithistory.org/2020/01/05/foaf.html 作者：[Two-Bit History][a] 选题：[lujun9972][b] 译者：[aREversez](https://github.com/aREversez) 校对：[wxy](https://github.com/wxy) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 [a]: https://twobithistory.org [b]: https://github.com/lujun9972 [1]: tmp.mJHAgyVHGr#fn:1 [2]: https://en.wikipedia.org/wiki/Fediverse [3]: https://en.wikipedia.org/wiki/Prodigy_(online_service) [4]: https://twobithistory.org/2018/05/27/semantic-web.html [5]: https://www.ftrain.com/google_takes_all [6]: tmp.mJHAgyVHGr#fn:2 [7]: tmp.mJHAgyVHGr#fn:3 [8]: tmp.mJHAgyVHGr#fn:4 [9]: tmp.mJHAgyVHGr#fn:5 [10]: http://www.ldodds.com/foaf/foaf-a-matic [11]: tmp.mJHAgyVHGr#fn:6 [12]: tmp.mJHAgyVHGr#fn:7 [13]: tmp.mJHAgyVHGr#fn:8 [14]: https://en.wikipedia.org/wiki/Mastodon_(software) [15]: tmp.mJHAgyVHGr#fn:9 [16]: tmp.mJHAgyVHGr#fn:10 [17]: https://twitter.com/TwoBitHistory [18]: https://twobithistory.org/feed.xml [19]: https://twitter.com/TwoBitHistory/status/1192196764239093760?ref_src=twsrc%5Etfw [20]: tmp.mJHAgyVHGr#fnref:1 [21]: tmp.mJHAgyVHGr#fnref:2 [22]: tmp.mJHAgyVHGr#fnref:3 [23]: tmp.mJHAgyVHGr#fnref:4 [24]: tmp.mJHAgyVHGr#fnref:5 [25]: tmp.mJHAgyVHGr#fnref:6 [26]: tmp.mJHAgyVHGr#fnref:7 [27]: tmp.mJHAgyVHGr#fnref:8 [28]: tmp.mJHAgyVHGr#fnref:9 [29]: tmp.mJHAgyVHGr#fnref:10 [0]: https://img.linux.net.cn/data/attachment/album/202212/10/112053vbi9icvy6xxuv6h9.jpg