一、理论：面临的主要问题和对策
1、文本的识别
针对竖排古籍文本的文字识别目前找不到较好的解决方法。许多支持竖排古籍文本识别的网站都有资源的配额限制，难以在较短时间内对大量的文本进行文字识别。因此我使用了百度智能云的OCR功能，经过简单的测试，发现文本识别的准确率可以达到90%左右。通过自动识别和对文本的手动处理，可以较好地实现对文本提取。
图 一 文本识别流程
2、资料的导入
当我们将提取出来的人物信息导入进CBDB之中时，需要对数据库中文本的内容进行更改。这时由于资料的内容，往往会出现以下几种情况：
1) CBDB未收录人物
2) CBDB已收录但信息不全
3) CBDB已收录但信息冲突
对于这三种不同的情况，我们选择三种不同的方法。对第1种情况，我们将其追加在表格中，同时为其创建新的人物代码；对于第2种情况，需要在核对人物身份之后，将其追加在相对应实体之中；对于第三种情况，我们需要通过其他资料的实证来分辨是否为讹误，在确定属实之后，我们可以通过更新表来实现对CBDB中数据的改正。（如下图示意）
图 二资料的导入的三种情况及其查询设计的对策
3.对数据库结构的再认识
如果想要将以获取的数据导入至CBDB数据库中并且可查询，那么前提是弄清楚CBDB数据库中的逻辑。由于CBDB收录的数据十分庞大，导致单个表格无法包含所有信息，因此在CBDB的数据库中将各种信息记录在不同的表格之中，
以下参考网络资料和帮助文档列出CBDB中的表格构成。在关系型数据库中有三种基本的表格：[①]
1、描述基本实体的表格
这些实体代表了前近代中国社会的基本要素。每一要素都有着复杂的历史和结构（这些都在另外的附属表格中）。CBDB在次级表中记录了人们与其生活诸层面的相互作用。
表 1 CBDB数据库中描述基本实体的表格
|
表格名称 |
注释 |
|
ADDR_CODES |
中国行政地理单位 |
|
ADDRESSES |
显示等级便于参考的表格 |
|
ASSOC_CODES |
非亲属社会关系 |
|
BIOG_MAIN |
收录的人物信息 |
|
ENTRY_CODES |
入仕的方式 |
|
EVENT_CODES |
重大事件 |
|
KINSHIP_CODES |
收录的人物的亲属类别 |
|
OFFICE_CODES |
政府的官僚机构单位 |
|
PLACE_ID |
带有经纬度的标准单位的地点 |
|
STATUS_CODES |
人们取得社会区分的方式 |
|
TEXT_CODES |
收录著述的汇编+重要的研究著作 |
2、描述基本实体之间关系的表格
表 2 CBDB数据库中描述基本实体之间关系的表格
|
表格名称 |
注释 |
|
ALTNAME_DATA |
为人所知的其他称呼 |
|
ASSOC_DATA |
人们之间的非亲属关系 |
|
BIOG_ADDR_DATA |
人与行政地理之间的关系 |
|
ENTRY_DATA |
人与机构之间最初的关系 |
|
EVENTS_ADDR |
人、事件与地址的关系 |
|
EVENTS_DATA |
人和事件的关系 |
|
KIN_DATA |
连结人们的亲属关系 |
|
OFFICE_DATA |
官僚机构的等级结构 |
|
POSSESSION_ADDR |
人名、财产和地址的关系 |
|
POSSESSION_DATA |
目前可表述的“财产”状况 |
|
POSTED_TO_ADDR |
人、职官和地址的关系 |
|
POSTING_DATA |
除授的集合表：人与职官的连结 |
|
POSTED_TO_OFFICE_DATA |
人与职官关系的细节 |
|
STATUS_DATA |
在社会声望的体系中人所处的位置的数据 |
|
TEXT_DATA |
人与著述的关系 |
|
BIOG_INST_DATA |
人们与社会机构的关系 |
|
BIOG_SOURCE_DATA |
用于定义个人CBDB资料的系列出处 |
3、描述实体之间关系类型的表格
表 3 CBDB数据库中描述实体之间关系类型的表格
|
表格名称 |
注释 |
|
BIOG_ADDR_CODES |
人和地址关系的类别 |
|
ALTNAME_CODES |
为人所知的各种别名类别 |
|
APPOINTMENT_TYPE_CODES |
除授类别：正授、权，等等 |
|
ASSOC_TYPES |
宽泛的社会关系类别，将多种亲属关系代码编组 |
|
ASSUME_OFFICE_CODES |
表示个人是否赴任 |
|
ENTRY TYPE |
表示入仕代码 |
|
EXTANT_CODES |
表示资料的存佚情况 |
|
GENRE TYPES |
文本的目录学归类 |
|
GENRE_CODES |
宽泛的目录学分类 |
|
LITERARYGENRE_CODES |
文学作品的形式 |
|
OCCASION_CODES |
人们参与的事件 |
|
OFFICE TYPES |
职官类别 |
|
POSSESSION_ACT_CODES |
人与物品之间的关系类别 |
|
SCHOLARLYTOPICS_CODES |
学术主题类别 |
|
SOCIAL_INSTITUTION_TYPE S |
社会机构分类 |
|
STATUS_TYPE |
社会区分分类 |
|
TEXT_ROLE_CODES |
人与文本关系类别 |
|
YEAR_RANGE_CODES |
日期的相对准确度 |
|
BIOG_INST_CODES |
与机构关系中个人的角色 |
|
SOCIAL_INSTITUTION_ADD R_TYPES |
用于机构的网址类别型 |
由于本次作业以人物（《大吏传》）为案例，因此也以人物作为切入口，了解CBDB的数据库机制。在BIOG_MAIN表格中，包含人物的人物ID、姓名（包括中文和英文）以及出生年、死亡年和指数年等数据。而关于人物的籍贯、职务、亲属、重大事件等等数据则是通过人物ID（c_personid）实现的链接。一般来说，为了尽可能降低数据库的大小，在CBDB中尽可能保证每个数据只被记录一次，例如在查询人物籍贯时，我们只需要c_addr_name这一个字段，而不需要其他内容。而c_addr_nam的内容则存储在ADDR_CODES表格中，因此如果我们需要查询人物的籍贯，那么我们需要通过BIOG_ADDR_DATA表格，BIOG_ADDR_DATA表格将人物的代码c_personid和所需要的c_addr_nam一一对应，只需要查询人物的代码可以知道其籍贯所在。由于BIOG_ADDR_DATA表格中存储的数据是来自于ADDR_CODES表格中，也可以避免数据的重复存储，可以大大减小数据库的大小。这就是所谓的“标准化表格”
但是，与此同时，也出现另一个问题，也就是速度问题。由于在查询时，需要查询多种数据。如果通过实体表格链接的话，就会加大计算机工作的任务量，同时复杂的表链接也不方便查询的编写。因此就出现了“非标准化表格”。所谓“非标准化表格”是相对于“标准化表格”而言的，也即在表格中加入其他信息（大多数是文本字符串， 包括人物姓名、地址、官职等等）这些信息的加入可以方便查询和编写查询程序，而作为用户，我们实际简单的查询也是通过这些“非标准化表格”来进行的。在图三中，笔者简单通过查询人物籍贯和人物的官职两种查询来解释所谓CBDB是如何利用“非标准化表格”进行便捷快速的查询的。
表 4 CBDB数据库中非标准化的表格
|
表格名称 |
注释 |
|
ZZZ_ALL_BIOG_ADDR |
加入了指数地的表格 |
|
ZZZ_ALT_NAME_DATA |
加入了别名类型 |
|
ZZZ_BIOG_ADDR_DATA |
加入了地址和地址类型 |
|
ZZZ_BIOG_MAIN |
加入了年号、民族 |
|
ZZZ_ENTRY_DATA |
加入了人物姓名、入仕方式 |
|
ZZZ_KIN_BIOG_ADDR |
亲属关系表，同时包括指数地 |
|
ZZZ_NONKIN_BIOG_ADDR |
社会关系表，同时包括指数地 |
|
ZZZ_POSTED_TO_ADDR_DATA |
加入了人物姓名、任官官职名称、地址信息 |
|
ZZZ_POSTED_TO_OFFICE_DATA |
加入了人物姓名和任官信息 |
|
ZZZ_STATUS_DATA |
加入了人物姓名和社会区分 |
|
ZZZ_TEXT_DATA |
加入了人物姓名、人物角色和文本信息 |
在查询人物籍贯时，我们要查询c_addr_name这一个字段。ZZZ_BIOG_ADDR_DATA表格中在BIOG_ADDR_DATA表格（人与行政地理之间的关系）的基础上加入了地址和地址类型。使得我们可查询的内容更多。通过ZZZ_BIOG_ADDR_DATA表格将人物的代码c_personid和所需要的c_addr_nam一一对应，可以得到籍贯所在。
在查询人物的官职相关信息时，我们就需要去要询c_office_chn这一个字段。ZZZ_POSTED_TO_OFFICE_DATA表格中在POSTING_DATA表格（官职的除授表：人与职官的连结）的基础上加入了人物姓名和任官信息。通过ZZZ_POSTED_TO_OFFICE_DATA表格将人物的代码c_personid和所需要的c_office_chn相互对应，可以查询到人物的官职。
图 三CBDB对人物各要素的查询机制
通过上图，我们不难了解到CBDB数据库查询功能程序设计的逻辑。因此，如果我们需要将做得到的数据导入进CBDB并且可查询的话，只需要对CBDB中的“非标准化表格”进行更新或追加即可。[②]
二、实践
1、文字识别和人工校对
略
2、文本标注和结构化——以徐达为例
利用识别后生成的文本资料，我们可以通过MARKUS进行文本的标注和结构化的处理。将识别并经过人工校对的文本转成MARKUS支持的UTF-8格式的txt文本文件，并且上传至MARKUS的平台。
该平台支持依据CBDB、CHGIS、TWGIS等系统数据进行自动标记，也支持手动标记和新建关键词进行标注。但由于MARKUS暂时不支持自定义中文标签，因此会给标注的过程带来一定的不便。
通过对文本进行标注，可以帮助我们快速地实现文本的结构化处理。如对徐达传进行的文本标注就通过在自动标注的基础之上进行手动的标注，将文本赋予不同的属性含义。
图 四对《甘肃全省新通志》徐达部分的文本标记案例
在对文本进行了初步处理之后，需要对文本的数据进行进一步的清洗和处理，将直接表示徐达的官职、年代、地理信息、事件和人物关系等加以分类，并通过MARKUS的平台导出成为XLSX表格。
图 五 基于《甘肃全省新通志》徐达部分的文本标记导出的结果
3、文本的导入
如果要将MARKUS的平台导出的XLSX表格导入至Biog_main表格中，需要首先了解掌握Biog_main表格格式设置的内容，通过将徐达的XLSX表格根据Biog_main中的字段进行再结构化，我们可以得到符合Biog_main表格格式的徐达数据。如果想要将徐达的人物信息导入Biog_main可以先将符合Biog_main表格格式的徐达数据导入到CBDB数据库中，再通过查询设计对Biog_main进行追加或更新。到但是由于CBDB数据库中已经收录了徐达的信息，因此简单地导入徐达的信息，可能会导致CBDB数据库中徐达的原有信息被删减或是覆盖。因此在正式导入人物的数据之前，我们需要对原始资料和CBDB所记录的人物资料进行对比，在此基础之上选择导入的方式。基于前文中所提到的三种不同的要求，我们选择分别选择三个不同的人物进行信息的导入。
（1）CBDB未收录人物
在CBDB中存在部分未收录的人物，在老师所提供的文本中（《甘肃全省新通志》24页-56页），粗略统计有89个人物，其中有“葉琪、毛議、孟凖、杨一淸、颜頤、許澶、蘇志舉、張鶴、刑雲路、襲輝、王聘賢、杨守禮、白謚、瘳逢節、喻時河、豫其學、李蓁河、汪尙甯、王以族、龐尙鵬”20个人物在CBDB中缺乏记录，占比达到22%。
表 5初步统计的89个人物
|
人物一览表 |
|||||
|
秦鋐 |
路迎 |
王汝 |
劉彭年 |
郭汝 |
李向陽 |
|
葉琪 |
景佐 |
張瑞 |
襲輝 |
白謚 |
於惟一 |
|
毛議 |
颜頤 |
趙錦 |
陳儒 |
瘳逢節 |
豫其學 |
|
孫逢 |
張泰 |
詹榮 |
葉夢熊 |
吳椿 |
李蓁河 |
|
羅明 |
叢蘭 |
謝孟金 |
王聘賢 |
趙蘭 |
汪尙甯 |
|
柯忠 |
許銘 |
俞智 |
郭宗賢 |
蕭文奎 |
王以族 |
|
李旻 |
李璋 |
王維賢 |
荆州俊 |
李維禎 |
張鐸 |
|
許進 |
燕忠 |
范瑟 |
杜詩 |
劉伯燮 |
朱用 |
|
杨一淸 |
許澶 |
宋徵 |
董某 |
董汝漢 |
孟養性 |
|
孟凖 |
張蘭 |
蘇志舉 |
李汶 |
紀常 |
栗永祿 |
|
郭紳 |
陳九疇 |
李冕 |
劉敏寬 |
賈應春 |
石茂華 |
|
王雲鳳 |
唐澤 |
呂時中 |
王任 |
王夢弼 |
朱笈 |
|
胡經 |
易瓚 |
張鶴 |
董定策 |
魏謙吉 |
龐尙鵬 |
|
王寅 |
王瓊 |
張文魁 |
杨守禮 |
喻時河 |
侯東萊 |
|
張檄 |
王昊 |
刑雲路 |
沈沂 |
王崇 |
|
针对CBDB中缺少的人物代码，我们需要通过查询设计——追加表的操作对Biog_main中缺少的人物进行追加。
图 六 导入Biog_main表后的未收录人物（红色方框内为添加的人物）
（2) CBDB已收录但信息不全
实际上，通过我们的对比，发现在CBDB中除了缺少人物，关于人物的大量数据都是处于空白状态。此处，以徐达为例，在CBDB中，按人查询时，我们发现徐达的职官一栏中为空，这是由于CBDB未收录徐达的职官信息，因此也就无法显示。
图 七 CBDB中未记录徐达的职官信息
但在《甘肃全省新通志》中：
明徐達字天德濠人洪武元年以征虏大將軍右丞相將二十五萬人北伐克燕京
给出徐达的职官信息：“征虏大將軍”“右丞相”，在查询OFFICE_CODES表格中发现没有记录“征虏大將軍”的职官内容，但记录了“右丞相”这一内容，因此，如果不向OFFICE_CODES内添加“征虏大將軍”的相关内容，是无法通过更改ZZZ_POSTED_TO_OFFICE_DATA中的数据以实现可查询。
通过查询窗体的代码，我绘制出查询人物的职官信息的基本流程，并且根据该流程实现了数据导入后的可查询。如下图所示，在CBDB的主页面（CBDB Browser）的数据来源于窗体POSTING_DATA Subform，而窗体POSTING_DATA Subform的数据则来源于表格POSTING_DATA但是由于需要显示人物的c_office_id、c_office_chn等字段，因此也需要对ZZZ_POSTED_TO_OFFICE_DATA表格进行更改。我们通过“为徐达添加一条‘右丞相’的职官记录为例”，介绍如何向CBDB中添加可查询的数据记录。
首先，查询得到徐达的人物ID：66290，在POSTING_DATA表格中为徐达添加一条授官记录，加入人物ID之后赋予新的c_posting_id，这就为徐达增加了一次授官的事件，这样在CBDB Browser查询徐达的职官情况时候通过窗体POSTING_DATA Subform可以得知徐达有一条授官的记录，但是由于没有添加具体授官的官职名称，因此，在结果中不会显示。为了让授官的事件附加有具体的职官等信息，我们还需要从表格OFFICE_CODES中找到“右丞相”的c_office_id等信息并将c_personid、c_posting_id、c_office_id、c_office_chn等字段输入ZZZ_POSTED_TO_OFFICE_DATA表格中。这样在查询的时候，既可以让电脑知道徐达曾被授官这一事件，还可以知道徐达被授予职官的具体信息。
图 八 为徐达添加可供查询的人物信息过程
图 九 为CBDB添加徐达的职官信息之后的查询结果
（3）CBDB已收录但信息冲突
此处内容由于需要对文献进行考证和查找，耗费精力甚大，限于时间和能力，未能展现，但处理方法和（2）类似，在此不作赘述。
三、思考
1、关于地方志对于完善CBDB数据库的作用
基于对以上的思考，我们发现地方县志对于完善CBDB数据库内的信息有着重要的作用。通过查阅表格BIOG_SOURCE_DATA内的信息，我们可以发现收录进CBDB数据库内的记录，来源于传记资料索引的虽然占了很大的一定比例，但是依然有不少的记录来源于地方县志。中国历史时期尤其是明清以来的地方志汗牛充栋浩如星海，可以帮助完善数据库的人物、职官、地理等等记录。
2、关于如何高效将上述过程实现自动化处理
面对繁多的地方志数据，目前我所操作的方法依然是依托大量手动操作的，这就导致对文本的提取和结构化以及导入CBDB的效率较低。如果不能将海量的文本进行自动化的识别提取结构化并且可以依据所要导入的数据类型不同而对CBDB的不同表格、窗体进行更改以实现对CBDB数据的完善，那么那些地方志依然只是一个沉睡的宝藏等待我们挖掘。
3、要关注碑刻文献
CBDB数据库中所记录的人物大多为宋代及宋代之后的人物，这也限制了CBDB的应用场景，这是由于CBDB数据库的记录较为依赖于文本文字的记载。但最近新出土的碑刻文本如墓志铭等文献也可以作为CBDB数据库资料的重要来源。
[①]关于CBDB中的表格的含义和分类主要参考了以下资料
中国历代人物传记资料库. 中国历代人物传记资料库用户指南[EB/OL]. [2022-7-15]. https://projects.iq.harvard.edu/files/cbdb/files/cbdb_users_guide_ch_20210322.pdf.
引得数字人文平台. 一文读懂，中国历代人物传记资料库（CBDB)中的表格[EB/OL]. [2022-7-15]. https://zhuanlan.zhihu.com/p/511725480.
[②] 部分参考以下资料
彭文谦、程卉、陈诗沛《從全文到表格：地方志職官資料的擷取》；
Chen, S., & Wang, H. (2022). China Biographical Database (CBDB): A Relational Database for Prosopographical Research of Pre-Modern China. Journal of Open Humanities Data, 8, 4. DOI: http://doi.org/10.5334/johd.68
TRANSLATE with