Schema.org 后台是如何运作的，以及为什么开发者应该关注它
你有没有想过，为什么 Google 能知道一个页面包含的是真正的苹果派食谱，而不仅仅是配料文字？或者邮件客户端是如何把“确认预订”按钮直接拉到邮件列表里的？答案始终如一——Schema.org。但在我们熟悉的 ItemProp 和 JSON-LD 标签背后，隐藏着一个庞大的 GitHub 仓库，它按照自己独特的、有时甚至非常奇怪的规则运作。
我决定深入研究这个项目的源代码。结果发现，它不仅仅是一套参考指南，而是一个完整的软件环境，有自己的逻辑、测试，甚至还有一种“有益的混乱”的理念。
这个项目到底是什么
通常我们把 Schema.org 看作文档网站。你去那里，复制你需要的数据类型，粘贴到你的代码里。但 schemaorg/schemaorg 仓库才是这个网站本身的构建来源。它包含所有实体定义、数百个标记示例，以及将分散的文件转换为搜索引擎和浏览器能够理解的结构的 Python 软件。
这个项目由 W3C 监管，参与讨论的有 Google、Microsoft、Yahoo 和 Pinterest 的人员。这是少数几个行业巨头就通用语言达成一致的案例，这样他们就不必在互联网的每个角落都重新发明轮子。
里面不仅仅是文本
如果你查看 data/ 文件夹，你会看到这个标准实际上是如何“呼吸”的。核心模式以 Turtle 格式（.ttl）存储。这是 RDF 的一个子集，看起来像一组关于世界的陈述。
有趣的是，开发者们故意拒绝了“美观”的架构。在 README 中他们明确表示：我们不追求本体论的纯粹性或优雅。如果要在严格逻辑和让网站管理员更容易实现代码之间做选择，他们会选择简单性。例如，他们可能会为了标记的便利性而添加一个没有属性的数据类型，即使对于形式建模的爱好者来说这听起来像是异端邪说。
仓库的主要特点
- 务实演进。 项目团队对大规模重构持怀疑态度。如果你建议重新设计事件层级结构，因为“这样更正确”，他们很可能会礼貌地倾听然后关闭工单。他们关心的是这些变更是否被主要数据消费者（搜索引擎或云服务）实际使用。
- 本地测试。 仓库包含的软件可以让你在本地部署一份 Schema.org 的副本。如果你想提出一个新的数据类型并想看看它如何融入整体结构，这会很有用。
- 文本文件中的示例。 项目价值的很大一部分在于
examples.txt文件。那里收集了成千上万个案例：从如何标记公交时刻表到描述复杂的医疗程序。
技术层面
这个项目基于 Python 运行（需要 3.6+ 版本）。要在本地运行这个网站，如果你使用 Windows，则需要 Linux 或 WSL2。
这个过程大致如下：
- 安装依赖项。
- 运行构建脚本。
- 在 8080 端口获得本地服务器。
所有软件都是为创建网站的静态副本而定制的。基础设施看起来有点保守（使用 Google App Engine、特定的 Python 脚本），但它已经运行多年，消化了来自社区的大量编辑。
为什么开发者应该深入研究这个
当有一个方便的网站时，克隆仓库似乎没有必要。但在某些场景下它确实很有帮助。
首先，当标准文档看起来不完整时。在 data/ 文件夹的源代码中，你经常会找到注释和草稿（在 Pending 部分），这些还没有发布到主页，但已经被主要参与者实现了。
其次，如果你正在构建自己的数据解析或验证工具。使用 schema.ttl 作为主要来源比尝试抓取网站页面要可靠得多。这是干净的数据，可以直接用于机器处理。
第三，这是一个很好的学校，教你如何管理一个企业利益和普通开发者利益冲突的大型开源项目。看看 Issue #1——那里已经进行了多年的发布规划，这是一个如何控制混乱的例子。
谁应该订阅更新
如果你从事 SEO、搜索引擎开发，或者只是想让你的网络数据具有结构，这个仓库应该在你的书签里。
不要期待这里有花哨的框架或完美的代码。这个项目关乎内容、协议和务实。有时候，看到即使是世界级的标准也不是建立在完美公式之上，而是建立在妥协和数百万人的真实经验之上，是很有用的。
要开始，只需看看 data/examples.txt 文件夹。相信我，那里有很多关于结构化互联网应该是什么样子有趣的东西。
相关项目