企业官网建设流程全解析

• 知识图谱
• 数据

Schema.org 词汇表的演进离不开外部协作项目的贡献，其中 LRMI（Learning Resource Metadata Initiative，学习资源元数据倡议）就是典型的代表：它通过仓库中一份轻量的协作元数据文件（data/collab/LRMIClass.md）被登记为"来源贡献方"，并为 Schema.org 带来了AlignmentObject、EducationalAudience两个教育领域核心类。本文将以data/collab/LRMIClass.md为骨架，结合仓库内发布产物（data/releases/下的 TTL 文件）与解析软件（software/SchemaTerms/sdocollaborators.py）的源码实现，完整讲解协作方元数据的文件格式、解析管线、发布链路与最终在 schema 数据中呈现的形态，帮助读者理解并复用以同样机制扩展 Schema.org 词汇表。

一、协作方（collaborator）机制概述

Schema.org 是一个开放协作的词汇表项目，其data/collab/目录下存放着一批"协作方元数据文件"，每个文件对应一个为 Schema.org 贡献过术语的外部项目或工作组，例如ActionCollabClass.md、Automotive_Ontology_Working_Group.md、FIBO.md、GoodRelationsClass.md、QAStackExchange.md以及本文主角LRMIClass.md。

这些文件的核心作用有二：

1. 登记来源归属：声明某个 schema 类/属性"源自"哪个外部项目，形成可追溯的出处链；
2. 驱动页面渲染：在生成 schema.org 术语页面时，将协作方信息（标题、链接、描述、致谢文本）渲染进页面，并在页面上列出该协作方贡献的术语清单。

LRMIClass.md是这一机制的最小但完整的示例，全部内容如下（含前导元数据与两个内容区块）：

--- img: https://www.dublincore.org/specifications/lrmi/images/LRMI_400w.png title: LRMI project url: http://lrmi.net --- DescriptionText.md --- AcknowledgementText.md This class is based on the work of the LRMI project, see lrmi.net for details.

文件虽然只有 7 行，却完整覆盖了协作方文件格式的全部要素：元数据头、描述区块（此处留空）、致谢区块。围绕它，仓库内同时存在发行版 TTL 中的对应来源声明与两类 LRMI 贡献类，可展开的内容远比表面丰富。

二、LRMIClass.md 文件格式详解

2.1 前导元数据（front matter）

文件前三行是key: value形式的属性声明，用---与正文分隔。data/collab/下所有协作方文件统一采用该约定。LRMIClass.md声明了三个属性：

从源码看，这三个属性是解析器明确识别并消费的键：在software/SchemaTerms/sdocollaborators.py的_parseDesc方法中，self.url = attributes.get("url")、self.title = attributes.get("title")、self.img = attributes.get("img")，随后这三个键会从属性字典中移除（attributes.pop(...)）。如果文件中还出现其他未知属性键，解析器会输出警告日志Unknown attributes found in collaborator file ...（sdocollaborators.py）。这提示协作方文件维护者：目前只支持img、title、url三个元数据属性，不要自行添加新键。

2.2 内容区块（section）

元数据之后，用---加区块名的方式划分内容区块。LRMIClass.md声明了两个区块：

• --- DescriptionText.md：协作方描述文本，本文件中该区块为空（LRMIClass.md未提供独立描述，直接以致谢文本为主体）；
• --- AcknowledgementText.md：致谢/声明文本，内容为 "This class is based on the work of the LRMI project, see lrmi.net for details."（本类基于 LRMI 项目的工作成果，详见 lrmi.net）。

解析器通过正则INCLUDE_RE = re.compile(R"---\s+([^.]+)\.md")识别区块名（sdocollaborators.py），并把DescriptionText.md名下的行解析为description、AcknowledgementText.md名下的行解析为acknowledgement（sdocollaborators.py）。两个区块名之外的未知区块同样会触发警告日志。这些文本最终经由localmarkdown.Markdown.parseLines做本地 Markdown 解析后进入collaborator对象。

三、解析管线：sdocollaborators.py 源码解读

software/SchemaTerms/sdocollaborators.py是整个协作方机制的软件实现，核心类是collaborator（sdocollaborators.py）。其关键设计如下：

• 全局注册表：COLLABORATORS与CONTRIBUTORS两个类级字典，前者收录全部协作方，后者仅收录被 schema 数据确认为"贡献者"（contributor）的协作方。loadCollaborators()通过paths.DefaultInputLayout().domain_files(paths.Domain.DATA, "collab/*.md")扫描data/collab/*.md并逐个调用createCollaborator()加载（sdocollaborators.py），LRMIClass.md即在此扫描范围内。
• URI 规约：每个协作方对象的urirel形如/docs/collab/LRMIClass（os.path.join("/docs", "collab", ref)），uri则为schema.constants.HOMEPAGE + urirel。这意味着协作方在 schema 数据中拥有一个可解析的 URI 身份。
• 贡献者判定：loadContributors()使用 SPARQL 查询SELECT distinct ?val WHERE { [] schema:contributor ?val. }从 schema 图数据中找出所有schema:contributor指向的实体，再调用createContributor()把匹配的协作方标记为 contributor（sdocollaborators.py）。也就是说：一个协作方是否算"贡献者"，取决于 schema 本体中是否存在指向其 URI 的schema:contributor三元组。
• 术语反查：getTerms()调用sdotermsource.SdoTermSource.getAcknowledgedTerms(self.uri)，反查出所有在致谢（acknowledgement）中指向该 URI 的术语，用于在术语页面上生成"该协作方贡献了哪些词条"的清单（sdocollaborators.py）。

这套设计的直接推论是：修改或新增data/collab/*.md后，需要重新运行构建/发布流程，让解析结果与生成页面、TTL 产物保持一致。

四、LRMI 在 schema 本体中的落地：两类贡献

在发布产物data/releases/10.0/schema.ttl中，LRMI 的来源声明被序列化为一个Organization节点（schema.ttl）：

<http://www.w3.org/wiki/WebSchemas/SchemaDotOrgSources#source_LRMIClass> a :Organization ; rdfs:label "LRMIClass" ; rdfs:comment "This class is based on the work of the LRMI project, see lrmi.net for details." .

注意其rdfs:comment与LRMIClass.md的AcknowledgementText.md区块文本完全一致——这正是致谢文本从 collab 元数据流入发行版本体的直接证据。同样的声明早在data/releases/3.0/schema.ttl（schema.ttl）中就已存在，说明 LRMI 合作从早期版本延续至今。

4.1 AlignmentObject：学习资源与教育框架的对齐

AlignmentObject是 LRMI 贡献的核心类，定义于 schema.ttl：

:AlignmentObject a rdfs:Class ; rdfs:label "AlignmentObject" ; :source <http://www.w3.org/wiki/WebSchemas/SchemaDotOrgSources#source_LRMIClass> ; rdfs:comment """An intangible item that describes an alignment between a learning resource and a node in an educational framework. Should not be used where the nature of the alignment can be described using a simple property, for example to express that a resource [[teaches]] or [[assesses]] a competency.""" ; rdfs:subClassOf :Intangible .

关键信息点：

• 通过:source属性显式指向source_LRMIClass，即声明本类源自 LRMI 项目；
• 语义为"描述学习资源与教育框架中某个节点之间对齐关系的无形条目"，并给出明确的边界约束：若对齐关系可以用简单属性表达（如资源teaches（教授）或assesses（评估）某能力），则不应使用本类；
• 作为Intangible的子类，属于无形实体分支，通常需要配合alignmentType、educationalFramework、targetName、targetUrl等属性一起使用来具体化对齐信息。

4.2 EducationalAudience：教育受众类型

第二类 LRMI 贡献是EducationalAudience，定义于 schema.ttl：

:EducationalAudience a rdfs:Class ; rdfs:label "EducationalAudience" ; :source <http://www.w3.org/wiki/WebSchemas/SchemaDotOrgSources#source_LRMIClass> ; rdfs:comment "An EducationalAudience." ; rdfs:subClassOf :Audience .

它作为Audience（受众）的子类存在，用于标注内容面向的教育受众群体，同样带有source_LRMIClass来源声明。它与AlignmentObject共同构成了 LRMI 在教育元数据标注上的双支柱：一个描述"内容与课程框架的对应关系"，一个描述"内容的受教育对象"。

4.3 source 属性的全局传播

source关联不仅存在于上述两个类的定义处，还会随每次发布传播到所有格式产物中。例如在software/SchemaTerms/example-code/data/schemaorg-all-http.nt中可以看到source_LRMIClass以<http://schema.org/source>三元组形式出现的记录（对齐AlignmentObject与EducationalAudience两类的声明），与source_GoodRelationsClass、source_GoodRelationsTerms、FIBO等协作方来源并列。这意味着使用者可以从 NT/JSON-LD/RDF 等任一发布格式中反查某术语的出处。

五、协作机制在软件层面的完整闭环

LRMI 协作的完整生命周期贯穿了仓库的三个部分，可归纳为：

1. 元数据定义：data/collab/LRMIClass.md以伪 Markdown 格式登记协作方身份与致谢文本；
2. 解析与渲染：sdocollaborators.py将文件解析为collaborator对象，供页面模板（templates/下的相关 J2 模板）与构建脚本消费；术语对象SdoTerm也维护acknowledgements列表（sdoterm.py），并通过 protobuf 定义的acknowledgements字段对外输出（见 schematermsprotobuf.py）；
3. 发布物序列化：构建后，source_LRMIClass以rdfs:comment+:source形式固化进各版本schema.ttl及衍生格式中。

如果希望确认某个类是否由 LRMI 贡献，最快的方式是在发布 TTL 中搜索source_LRMIClass关键字，即能定位到AlignmentObject与EducationalAudience两条声明以及 LRMI 来源节点本身。

六、如何基于该机制新增/维护协作方

LRMIClass.md是最简洁的范本，新增一个协作方文件只需三步：

1. 在data/collab/下创建<名称>.md，文件名为协作方的ref（如FIBO.md、GLEIF.md）；
2. 头部按序声明img（可选）、title、url三个属性，并以---与正文分隔；
3. 正文按需声明--- DescriptionText.md与--- AcknowledgementText.md两个区块，在对应区块下写入描述与致谢文本；若两个区块都未提供内容，解析器会将其视为空字符串处理。

维护时需注意的约束：

• 属性键仅支持img、title、url，多余键会触发Unknown attributes警告；
• 区块名仅支持DescriptionText.md与AcknowledgementText.md，未知区块会触发Unknown sections警告；
• 若希望该协作方被计入CONTRIBUTORS（贡献者列表并展示其贡献术语），schema 数据中必须存在schema:contributor指向其 URI 的三元组；
• 修改文件后需重新构建发布产物，保证data/releases/下的 TTL/JSON-LD/NT 与页面保持一致。

结语

data/collab/LRMIClass.md虽只有寥寥数行，却是理解 Schema.org 外部协作机制的钥匙：它展示了协作方元数据的最小完备结构，其致谢文本被原样写入发行版本体，其来源标识source_LRMIClass关联着AlignmentObject与EducationalAudience两个教育领域的实际类定义。结合 sdocollaborators.py 的解析实现与 schema.ttl 的序列化产物，读者可以完整掌握"外部项目 → collab 元数据 → 软件解析 → 发布本体"的整条链路，并据此为 Schema.org 贡献新的协作方与术语。

• 知识图谱
• 数据