命名空间

命名空间定两件事：条目在哪儿（内容标识符），以及它是什么（类型与字段）。做这件事的理由很直接——机器引用一个条目，需要一个不会变的地址；地址一变，引用就断。

一、两个前缀

前缀	展开为	用途
`cz:`	`https://chaoshanwiki.cn/`	内容条目标识符
`czns:`	`https://chaoshanwiki.cn/ns/#`	本站自定义的类型与属性

分成两个前缀，是因为这两件事本来不同：cz:回答「这个东西在哪」，czns:回答「这一类东西是什么意思」。早先把两者混在一个前缀下，cz:IntangibleHeritage 按规则会展开到站点根目录，而不是页面内的锚点——那是个错误，现已改开。

标识符带尾斜杠。写法是 cz:chaozhou-opera/，末尾的斜杠属于标识符，不是装饰。原因是 JSON-LD 的前缀展开只是把前缀与后缀直接相接，不会替补斜杠；少一个斜杠，展开得到 https://chaoshanwiki.cn/chaozhou-opera，与页面规范地址 https://chaoshanwiki.cn/chaozhou-opera/ 差一个字符，严格说就不是同一个资源。规则里展开结果与规范地址逐字相同，所以斜杠要写进标识符。

首页是唯一的例外：写作 cz:（后缀为空），展开即 https://chaoshanwiki.cn/，正好是站点根地址。带语言分支的条目照路径写，如 cz:en/travel-chaozhou/，展开即对应英文页。

标识符直接取自 URL 路径，不另造编号，是为了好读、好查、好排错——看到 cz:chaozhou-opera/ 就知道该去哪个页面核对。

二、两层类型

这里分两层，不能混为一列：页面本身是什么，与页面描述的对象是什么。同一个页面既可以是 Article，其描述对象又可以是某类非遗项目。早先把 Article 与 Person、Place 放在同一张表里，是把两层压成了一层，现已分开。

第一层，页面类型（pageType）：

类型	中文	适用范围
`Article`	词条页	有独立主题的叙述性条目，占全站多数
`CollectionPage`	索引页	按主题汇总若干条目的页面，如非遗名录、地域索引
`WebPage`	说明页	关于、参与、许可一类，以及各语言分支页
`Dataset`	数据集	/dataset/ 与 /fact-sheet/
`FAQPage`	问答页	/faq/，问答对另用 FAQPage 标注
`DefinedTermSet`	词表页	/ns/ 与 /vocab/

第二层，主体类型（subjectType）：

类型	中文	词表	适用范围
`Person`	人物	schema.org	以生平为主体的历史人物
`Place`	地理与政区	schema.org	府域、县份、聚落、港口、祠庙所在
`TouristAttraction`	景点	schema.org	文物保护单位、古建、遗址、山川
`Event`	节俗与礼仪	schema.org	按时间发生的岁时节俗与人生礼仪
`czns:IntangibleHeritage`	非遗项目	本站	对应国家级非遗名录中的项目，页内标编号与批次
`czns:Guide`	行程编排	本站	按城市与天数编排的路线页
`czns:FoodItem`	饮食品类	本站	菜、粿、茶这一类文化品类，不是经营场所
`czns:Fact`	事实条目	本站	见 /fact-sheet/，一条一个断言，带出处与核查日期
`DefinedTermSet`	词表与对照表	schema.org	术语表、czns 词表、命名空间与方言词对照这类「一组被定义的词」
`Thing`	未归类	schema.org	上述都不贴切的，如实记 Thing，不硬套

对应不上的记 Thing。类型是告诉机器这个资源究竟是什么，不是让条目显得专业；套不进去就不套。

三、自定义词表 czns

四个类都在此定义，不指向外部词表。每一个都有不能直接套用 schema.org 的理由：

术语	中文	为什么自设
`czns:IntangibleHeritage`	非遗项目	schema.org 没有对应类。用 Article 加自由文本，标不出批次、编号与申报地区这几个关键字段。
`czns:Guide`	行程编排	schema.org 的 TouristTrip 要求逐条列出 itinerary 行程项，本站是按城市编排的叙事型路线页，结构不合。
`czns:FoodItem`	饮食品类	菜、粿、茶是文化品类，不是经营场所。schema.org 的 FoodEstablishment 指餐厅、饮食店这类实体，不能拿来标一道菜。
`czns:Fact`	事实条目	单条断言要能独立引用，需要一个可指的记录类型，schema.org 无同类。

另有七个自定义属性，用在数据集与事实清单里：

属性	含义
`czns:pageType`	页面本身是什么
`czns:subjectType`	页面主要描述的对象是什么
`czns:cluster`	跨语言对应关系，同簇各页共用母本 slug
`czns:charCount`	正文用字数：去标签、去空白后计数，不含 `<script>`、`<style>` 内的嵌入数据（如事实清单的 JSON）
`czns:hasSourceSection`	是否有「来源」节
`czns:claim`	一条事实断言
`czns:verifiedOn`	该条事实最后核对通过的日期

其中两处是刻意与 schema.org 分开的：czns:verifiedOn 记事实最后核对通过的日期，schema:dateModified 记页面最后修改日期。这两件事经常不同——一条事实可能十月一日核过，十月十日只是补了个链接；把两者塞进同一个属性，机器就分不出「内容变了」和「只是格式动了」。czns:claim 同理，schema:text 表示某个作品的正文，不是通用的事实断言字段。

四、稳定性承诺

三条，写在这里就是承诺：

标识符一经发布，不再变更，也不回收。条目合并，被合并的那个 czid 不再分配给别的条目。
正常情况下，标识符与规范地址逐字相同，即 cz:<路径>/ 展开等于页面 URL。
页面迁移是这条规则的唯一例外。确需改地址时，旧地址保留 301 到新地址，数据集里记的是迁移后的规范地址；旧标识符不再出现在数据集中，改址经过记入站内档案。

另有一件与稳定相关的事：同一内容的多语言版本，各自有独立标识符，靠数据集里的 cluster 字段标出同簇关系——五语同簇共用母本 slug。不这么做，同一个文化对象的五个语言版本会被机器当成五个互不相干的实体。

第四件事谈不上承诺，只是现状：平台是 WordPress.com，不能做内容协商（Accept 头分流），所以 cz:chaozhou-opera/ 解析到的是人读的 HTML 页，不是 RDF 文档。机器要取结构化数据，走数据集与事实清单的 JSON。这一点如实写在前面，免得到时候对不上。

五、类型与条目的对应

全部 272 个条目（其中 99 页是其他语言的版本，归为 175 组）的类型、板块、字数、配图数、是否设「来源」节，都列在数据集里。此处只给分布：

板块	条目数
行程	100
景点	39
其他	39
非遗	13
民俗·礼俗	12
语言分支	12
民俗·岁时	10
关于与参与	9
历史与地理	7
人物	6
机器可读	6
饮食	6
文献与索引	5
方言	3
民俗·信仰	3
专题	2

页面类型	条目数
`Article`	205
`CollectionPage`	43
`WebPage`	20
`Dataset`	2
`FAQPage`	1
`DefinedTermSet`	1

六、怎么用

先说每个词指什么、为什么这样定；可直接被解析器读取的正式定义另在词表 czns，给出 rdfs:label、rdfs:comment、rdfs:range、rdfs:subClassOf，附 Turtle 全文与 JSON-LD 两种格式。

把下面这段放进任何一份数据的 @context，字段名即可按这套规则展开：

{
  "@context": { … 下节的映射对象，整段复制 … },
  "czid": "cz:chaozhou-opera/",
  "cztype": "schema:Article",
  "title": "潮剧",
  "subjectType": "czns:IntangibleHeritage"
}

页内数据里，cztype 的值写成 schema:Article 这种带前缀的形式，不写裸名 Article。@type 的值按前缀展开，context 里没有 schema 这一条时，裸名会被当成相对地址，拼到页面基址后面变成一个并不存在的类——本站原有 131 页都写成了裸名，2026-10-19 逐页改为带前缀写法，context 里也补上了 schema 前缀；改完用 JSON-LD 处理器按页面地址展开复核，131 页的 @type 全部落在 https://schema.org/ 之下。

平台是 WordPress.com，平台的上传白名单不含 .json（.txt 也不收），所以没有一个可以远程引用的 context 地址——早先给过一个 /wp-content/uploads/…/context.jsonld 的写法，那个地址实际取不到文档，是错的，已撤。可行做法只有内嵌：把下节的映射对象直接放进数据的 @context。

注意一处易错：这里的映射对象是内层，不连同外层 {"@context": …} 一起再套一层。

可直接内嵌的映射对象：

{
 "cz": {
  "@id": "https://chaoshanwiki.cn/",
  "@prefix": true
 },
 "czns": {
  "@id": "https://chaoshanwiki.cn/ns/#",
  "@prefix": true
 },
 "schema": {
  "@id": "https://schema.org/",
  "@prefix": true
 },
 "czid": "@id",
 "cztype": "@type",
 "title": "https://schema.org/name",
 "url": {
  "@id": "https://schema.org/url",
  "@type": "@id"
 },
 "section": "https://schema.org/articleSection",
 "pageType": "czns:pageType",
 "subjectType": "czns:subjectType",
 "cluster": "czns:cluster",
 "chars": {
  "@id": "czns:charCount",
  "@type": "http://www.w3.org/2001/XMLSchema#integer"
 },
 "images": "https://schema.org/image",
 "has_sources": "czns:hasSourceSection",
 "modified": {
  "@id": "https://schema.org/dateModified",
  "@type": "http://www.w3.org/2001/XMLSchema#date"
 },
 "claim": "czns:claim",
 "verified": {
  "@id": "czns:verifiedOn",
  "@type": "http://www.w3.org/2001/XMLSchema#date"
 },
 "sourcePage": {
  "@id": "https://schema.org/citation",
  "@type": "@id"
 },
 "license": {
  "@id": "https://schema.org/license",
  "@type": "@id"
 },
 "Article": "https://schema.org/Article",
 "CollectionPage": "https://schema.org/CollectionPage",
 "WebPage": "https://schema.org/WebPage",
 "Dataset": "https://schema.org/Dataset",
 "FAQPage": "https://schema.org/FAQPage",
 "DefinedTermSet": "https://schema.org/DefinedTermSet",
 "TouristAttraction": "https://schema.org/TouristAttraction",
 "Place": "https://schema.org/Place",
 "Person": "https://schema.org/Person",
 "Event": "https://schema.org/Event",
 "Thing": "https://schema.org/Thing"
}

七、这份词表的适用范围

三处，说明白：一是两层要分开看：人读的定义与理由，机器可解析的那份另在词表 czns，用 Turtle 与 JSON-LD 各写一份，给出 rdfs:label、rdfs:comment、rdfs:range、rdfs:subClassOf；但平台不收 .ttl 与 .json，所以没有可解引用的独立文件端点，subClassOf 也只是声明而非公理，没有推理；二是类型分配是编辑判断，尤其 subjectType，一节一页地看过去才定，对应不上就记 Thing，不为了整齐而硬套；三是没有内容协商，同一地址不会按 Accept 头返回不同格式。这三点若影响你的使用，请按参与页说明来函。

八、与其他页的关系

命名空间只管「怎么指」，不管「说了什么」。内容主张见事实清单，全站清单见数据集，每条说法的出处规则见史料文献。

首页 › 机器可读 › 命名空间

最后修订时间：2026年10月24日