你也许在其他地方听过SoLiD（Social Linked Data），它是诸多对现有万维网不满的改进项目之一。Solid之所以特别，其中一个重要因素在于它是由万维网的发明者Tim Berners-Lee提出的——因为他不满意于时下万维网及因特网的强烈中心化现状，希望从技术层面改变这一趋势，并给用户以更多控制权。

Solid的特别之处并不只是它的愿景，还在于它的技术和它的生态结构。由于中文互联网上对Solid特点、相关技术以及如何使用或搭建Solid这些话题资料较少，本文尝试对它们进行介绍，以协助潜在感兴趣的读者了解Solid生态及更广泛的Linked Data（链接数据，简称LD） / 语义网（络）的生态或技术链。

由于Solid仍在发展，LD及语义网也是仍在推进的研究方向，本文不会也无法对它们进行「全面」的展开。但本文会尽量选取其中最重要的部分进行介绍，并简单提及相关其他技术。感兴趣的读者可以自行搜索了解更多知识。也是由于仍在发展，Solid生态主要是英文。感兴趣的读者可以考虑贡献翻译——假如它们支持翻译的话。

下面一节将会简要但更加深入地对Solid的设计（及其相关技术选取）进行介绍；第二节会介绍如何使用Solid；第三节介绍如何自己搭建一个Solid实例（以Solid Community Server为例）。

Solid的相关设计

Solid的愿景和它的提出者是很有意义的背景信息，但这不足以支撑Solid的独特或优秀之处。在本节，我会简单介绍Solid在技术和设计上的特点。

Solid所基于的技术

Solid所基于的技术是它之所以不同于其他项目的一大重要之处：Linked Data （LD）。LD可以被认为是语义网（络）的新名字，也可以被认为是语义网相关技术的衍生产物。它的最主要用处是描述数据以及描述数据之间的关联，也就是语义网的核心。它也沿用了语义网的相关技术，如RDF （Resource Description Framework）、OWL（Web Ontology Language）等。

在当下这个时代，语义网经常不被提起，但实际上它仍然广泛存在。尤其是其相关技术，如RDF、OWL等，在计算机及计算机以外的各领域的使用在逐步增加。如果一定要对它定性，与其说这是最后的余晖，不如说是黎明前的黑暗。

LD之所以重要，是因为它在描述数据的同时（或其后）也描述了数据之间的关联（正如其名称所预示的那样）。这样，所有数据成了有机的互相关联的整体，且这是机器可读的形式，这大大方便了更广泛的数据获取、挖掘等事。

这里多说一下：LD是一种理念，而它的具体表示则使用了RDF的一系列技术；而RDF也是一种概念，其具体表示可以使用多种序列化方案，且它们理论上均等价。最常见的序列化形式是三种：RDF/XML、Turtle和JSON-LD。如名称所示，RDF/XML（.xml或.rdf）是一种使用XML来序列化RDF的方案，而JSON-LD（.jsonld或.json）是使用JSON来序列化RDF或者说LD的方案。Turtle（.ttl）是一种广为使用，精炼且人类可读性更好的序列化形式，也是Solid中最常用的数据存储形式。

Solid生态及Solid App（应用）

Solid的生态结构也是它的一个特点。它完全颠覆了现下流行的万维网或因特网生态结构。

现下流行的万维网及因特网生态结构中，数据和计算/服务均是由同一厂商/平台提供的，用户手中的仅有客户端。各个互联网公司的软件（尤其是手机软件）都是如此。这样，该厂商/平台拥有对数据的生杀大权，经常以此来胁迫用户；而用户对此无法有效反抗——唯一手段是放弃自己现有的所有数据，换一个厂商/平台。这也是各个公司都在搞「云端数据存储」的原因。一些法律法规试图改进该现状，如GDPR要求所有厂商/平台必须允许用户将自己在该平台上的所有数据导出为机器可读格式，但它们只是对此打补丁，并不能从源头解决问题。

在Solid中，Solid服务器仅存储用户数据（及数据相关信息，如访问权限），并提供数据的访问接口；Solid App（应用）提供计算、用户界面等业务。这样，用户只要拥有自己的Solid服务器，就可以轻易「转换」（而不是「迁移」）计算业务提供方（也就是App）。当然，用户也可以选择使用公开的可信的Solid服务器。

于是，一个用户的Solid账号对应了他的Solid pod，也就是数据存储（后文均称为pod）。这个pod存储了用户的所有数据，以及他的ID信息（在Solid中就是WebID）。而Solid App需要从用户的pod中存取数据。对用户来说，最直观的感受有两点：

1. 只需要一个Solid账号（或者说pod，或者说WebID）就可以了，不需要为每一个App注册一个账号。

2. Solid的使用就是围绕App展开的：想要什么功能，就寻找并打开对应的App，在其中登录上自己的Solid账号。

官方网站有一个App列表。我们也可以自己去其他地方寻找Solid App。

在下一节，我会围绕Solid平台体验进行介绍。其中一个有意思的地方在于：这些Solid服务的默认网页界面其本质也是一个Solid App（该App有时候也被称为SolidOS），其背后本质上是一个叫做Mashlib的软件/库。

Solid平台简单体验

对于不知道自己是否会喜欢Solid的人，可以先找一个公开的Solid平台，在其上注册一个账号体验一下。

Solid官方网站的这里提供了一些开放的Solid服务平台，以供选用。该页面也提到了可以自己搭建，感兴趣的读者可以参考下一篇博文。

本文假设读者在 https://solidcommunity.net 注册了账号，且用户名为YOUR-NAME。

注册账号的过程很普通，这里就不再赘述。在之后体验Solid App时，你需要登录你的账号——所以记住你的pod的提供商/网站是必要的。

注册完账号之后，可以先查看你的WebID，即https://YOUR-NAME.solidcommunity.net/profile/card#me。从浏览器中直接访问这个URL（网址）会打开一个展示页面，其中显示了该文档中的主要信息。

上图是我在创建一个新用户后访问该页面后打开的效果。可以看到其中每一栏都是空的，因为新账户内没有填写任何信息。但可以看到，其中包含你的名称、头像、好友列表、个人简介等内容。鼠标光标移动至点击右上角的个人头像处，会出现新的菜单（如下图所示），其中有一项即是修改自己的用户资料。在那里，可以看到多种可以填写的信息。

也许你注意到了，URL中包含#me部分。如果你删掉这部分，那么打开的页面会是另一个样子——打开一个RDF文件。如果你有一些RDF知识，那么你应该意识到了，你的个人资料URL指向了你的pod中的一个文件（/profile/card）中的一个节点（#me）。这个/profile/card文件本质上是一个Turtle文件，感兴趣的话可以点击「代码」按钮（也即第四个按钮）打开看一下它的内容。

在直接进入你的pod时，或者在菜单中点击Your stuff后，你会看到一个较为完整的操作界面。在第一个面板/标签里，你可以创建各类该实例所配置的资料——我之所用「资料」而非「文件」、「数据」等词，是因为它们可能简单也可能复杂，但重点是它们代表的内容而非它们的存储本质。实际上，本质上它们一般都是Turtle文件——RDF表示的丰富和扩展性使得这样使用十分自如。如下图所示，其中有待办事项、联系人、记事本、聊天等多种类别。

额外说一句，通过浏览器访问的https://YOUR-NAME.solidcommunity.net网站时，打开的其实是一个集成的叫做Mashlib的Solid App。它也有独立的版本，可以从这里访问。因为它是Solid社区维护的一项核心入口，比较完善地集成了许多基础性功能（如图形界面/Web界面访问和修改个人WebID档案的内容，创建和修改其他资料），所以也经常被称为Solid OS。但如前文所说，它只是一个App，完全可以开发其他App来代替。

前面提到过，Solid官方网站有一个App列表，我们可以从中挑选一些App试用。这些App基本上都是运行在浏览器中的，所以可以直接打开使用——当然，需要连接到你的Solid pod上（当然也可以是别人的，只要你有对应的权限）。有的App可能没有提供在线样例，所以可能给出在本地执行的实例——一般都是三部分：1. 克隆仓库；2. 安装依赖；3. 启动。

Solid上的身份和跨实例交流

Solid既然秉持去中心化的理念，那么它的设计自然是不会将用户绑在某一个服务器也就是实例上的。这一理念在理解的人眼中理所当然，但在习惯了传统的平台的人那里则或许是需要更多解释的。

前面提到过，在创建了账号后，你会拥有一个WebID，也就是那个URL。这个URL是你的身份标识，其（对应的文件）中描述了你的身份信息（以及一些额外的配置信息）。

在使用Solid App时，你往往需要使用你的WebID去登录它们，否则你只能访问「所有人」都可以访问的内容。而Solid App会去读取你的pod内的信息，来决定它们的行为。

这样，我们可以很容易地得到一个结论：我的WebID所在的服务器不重要，我的WebID的内容以及我的pod中存储的信息才重要。这样，我们不会被控制在某个特定的服务器/平台上，因为任意服务器都是一样的，只要它们可以按照标准规定的协议提供相应的数据——而标准和协议是公开的。这样，我们可以随意选择一个自己信得过的服务器，或者是自己搭建服务器。

理论上说，我们可以任意迁移自己的WebID到其他服务器上。只要WebID内容一样，且pod的数据也一样，那么App的表现也会一样。但这里还有一些额外的需要注意的部分：其他人（如你的好友）可能需要更新他们对你的身份的识别；App需要保证它们没有在内部保存并使用你的pod数据而不是你的WebID URL来识别你。

但不考虑这些额外情况的时候，你可以任意切换你的身份提供方。额外地，Solid标准中支持使用owl:sameAs来标识多个文档刻划WebID身份，也有讨论如何支持多个身份页面，如这里。但Solid暂时还没有如同Hubzilla的nomadic identity一般容易使用的多服务器共享身份（参考我以前写的《互联社交网络》一文）。

同样地，使用WebID作为ID之后，服务器本身不再重要，重要的只是WebID对应的URL作为身份标识。于是在Solid中，「本服务器上的多个用户」和「不同服务器上的多个用户」没有本质不同。Solid的所有机制对跨服务器和不跨服务器一视同仁。

总的来看，Solid中选择服务器只需要考虑服务器的特性（容量、速度等），而不用考虑服务器会不会对你的使用造成影响。这比以前在《互联社交网络》中讲到的各联邦SNS服务提供了更大的自由度，因为我们是和App交互而不是和pod（在服务器上）交互，而App是独立于pod之外的。

结语

在本文中，我们介绍了Solid的基本特性，给出了体验Solid的指导并涉及了可能会遇到的一些障碍，以及简单讨论了Solid去中心化的身份设计。

Solid的特点当然不止于此，但本文不打算也没有办法全部介绍，就好像你无法完全介绍现在的整个万维网一样。我希望前面的内容可以给你一些基本的介绍，让你知道Solid的存在，以及越过最初的无所适从。如果你有兴趣，完全可以尝试更多的东西。

如果有时间，下一篇我会简单介绍一下如何建立自己的Solid实例。我将会以Solid Community Server为例——它是Solid社区最新近构建的Solid服务器实现，模块化更好，并且拥有更好的扩展和定制性。