SPARQL与中世纪手稿的知识图谱革命

导言

SPARQL是与根据万维网联盟的链接开放数据 (LOD) 标准构建的知识图一起使用的查询语言。这些知识图谱由关于实体及其属性的类似句子的语句 (RDF三元组) 组成 (形式为: 主语-谓语-宾语)，根据一个或多个声明的本体和词汇表定义。这些图代表了一个复杂的互联知识体，需要一种相对复杂的方法来查询和探索它们，这正是SPARQL旨在提供的。

有各种其他方式来构建这种知识，从关系数据库到其他类型的图形数据库，文档数据库和键值数据库。与其他这些方法相比，RDF三重存储的优缺点已被广泛讨论。这里的假设是，RDF和SPARQL提供了一种复杂而有价值的方式来表示和查询有关中世纪和文艺复兴时期手稿的数据，可以用来回答有关手稿历史和出处的复杂研究问题。映射手稿迁移项目，下面更详细地讨论，发现SPARQL查询可以比基于关系数据库或TEI编码文档的接口更有效，更全面地回答一组特定的研究问题。

SPARQL可以以几种不同的方式部署。它可以使用第三方Web服务 (如Yasgui) 对SPARQL端点运行。它也可以使用到端点的本机查询接口运行，就像Wikidata和其他Wikibase实现一样。鉴于构造这些类型的查询所需的相对复杂性和专业知识，还开发了其他方法。一种是将SPARQL查询嵌入到其他形式的软件中，例如用于映射手稿迁移服务的sampo-ui。还尝试开发用于构建SPARQL查询的可视界面。还进行了一些初步实验，让像ChatGPT这样的AI聊天机器人编写SPARQL查询。

近年来，有关中世纪和文艺复兴时期手稿的数据知识图已发布到Web上，它们使用链接的开放数据和RDF框架。其中最值得注意的是采用独立的RDF三元组存储和图形数据库的形式，并带有一个SPARQL端点。映射手稿迁移项目是这种方法的最完整的专用示例，下面将更详细地讨论。Schoenberg手稿数据库是一个自定义的关系数据库，它还将其数据转换为RDF，并通过公共SPARQL端点使其可用。手稿来源数据的Bibale数据库也将其数据转换为RDF，但不提供SPARQL端点。Biblissima服务包含一个独立的三元组存储，但其SPARQL端点仅供内部使用，尚未公开提供。

还进行了各种努力来创建某些特定类型手稿内容的链接开放数据知识图，包括公证档案，旧英语文本，小时书和音乐手稿。沿着这些路线的项目包括Searobend，Sphaera,穆斯克，和NotaryPedia。除了MusicKG，他们没有使公共端点可用于SPARQL查询。

映射手稿迁移

映射手稿迁移 (MMM) 项目聚合了从Schoenberg Database, Bibale,和牛津图书馆的中世纪手稿。它们被转换为RDF三元组，并映射到MMM数据模型，该模型基于FRBROO和cidoc-crm本体的组合，以及一些附加的实体类和属性。聚合的数据包含超过90，0000个来源事件和超过2000万个RDF三元组，可以通过SPARQL端点以及浏览和过滤界面。

该界面使用芬兰阿尔图大学开发的sampo-ui软件。它利用MMM数据模型中的关系来实现广泛的过滤器组合。这些可能包括寻找圣奥古斯丁的手稿De civitate Dei在1200年之前在法国生产，最后在北美录制。结果可以显示为列表，并以基于地图的生产场所、最后已知位置以及它们之间的移动的可视化形式显示。Sampo-ui基于嵌入式SPARQL查询构建，这些查询最初对用户不可见。但是，可以检查底层查询以及修改它们并直接重新运行它们。

MMM项目还针对其SPARQL端点测试了直接查询的功能，与sampo-ui界面相比，并与三个源数据集的本机浏览和查询界面。特别是，SPARQL端点支持更多的定量和纵向查询，这无法通过sampo-ui界面完成，更不用说在原始数据库中了。这些查询包括追踪几个世纪以来不同类型的礼仪手稿的物理尺寸的变化，这表明高度和宽度之间的比率在小时书中变化最大，这种变化随着时间的推移而增加。缩写和missal在布局上更加一致和统一。另一个查询测量了20世纪英国手稿交易商的库存保留率，表明古董书商Bernard Quaritch Ltd. 平均而言，手稿库存的时间要长得多，与詹姆斯·特雷加斯基斯拥有的竞争对手伦敦公司相比，他们的广告频率更低。

针对MMM SPARQL端点运行的查询也使用Wikidata的上下文数据进行了扩展，以显示19世纪英国手稿收集者的职业和出生地。出生地在地图上可视化，以显示来自西北工业中心而不是伦敦和东南部的收藏家的数量。这些查询的可视化依赖于所使用的SPARQL查询工具; MMM项目使用Yasgui工具来生成图表、图形和气泡图以及时间线。结果也可以导出到可以产生基于地图和网络可视化的界面。MMM项目测试了将SPARQL查询数据导出到ResearchSpace和nodegoat等软件; 后者的环境包括一个时间滑块，可以显示随时间的变化，sampo-ui或Yasgui中不可用的功能。

MMM项目使用SPARQL经验的一个重要方面是产生这些结果所需的时间和培训。在SPARQL专家的指导下，项目团队成员在每周一次的在线研讨会上进行了为期18个月的研究。相关输出包括基于MMM数据的SPARQL教程，以及SPARQL查询本身的已发布版本以及结果集。

维基数据

Wikidata是世界上最大的公共知识图表之一，拥有超过1.24亿个项目和超过14.4亿个语句或三元组。Wikidata查询服务是最活跃的SPARQL端点之一，截至2021年4月，每天有超过1000万个查询。它的手稿覆盖范围仍然相对有限，尽管一些机构-特别是Bodleian图书馆，荷兰的Koninklijke Bibliotheek (KB)，和威尔士国家图书馆-一直在运行上传手稿记录的项目 (分别约1，300、1，260和590)。KB还创建了大约490的Wikidata记录阿尔巴amicorum(“友谊书”)。手稿记录的模式有些混乱和不一致，但最近的一个项目旨在改善这。无论如何，大多数现有记录远不是完整的目录记录; 它们的主要内容是库存编号 (包括货架标记) 、外部标识符和数字化版本的链接。

现有的记录语料库仅支持有限的基于SPARQL的深度语义探索和推理，尤其是定量的，因为记录的内容变化很大。例如，威尔士国家图书馆的大多数条目包括生产 (Wikidata术语中的 “inception”) 日期，语言，尺寸，页数，流派和主要主题。除生产日期和语言外，大多数Bodleian库条目都没有提供任何这些信息。一小部分Bodleian记录显示了以前的所有者，而威尔士手稿 (Carmarthen黑皮书) 中只有一份。知识库提供了一系列示例SPARQL查询，用于浏览其手稿条目，包括使用Histropedia的时间轴可视化。

结合其他SPARQL端点，可以查询Wikidata以获取与手稿相关的人员和组织的上下文数据，如上述MMM调查中所示，以及作品，文本，以及手稿携带的图像，以及它们的主题，主题和知识结构。Wikidata将与同一手稿相关的不同标识符汇集在一起的能力也可以在未来被利用来连接同一手稿的多个描述，该手稿的表示 (数字或物理)，以及与该手稿有关的出处证据和奖学金。

Wikibase

用于Wikidata的MediaWiki软件已通过开源下载以及德国Wikimedia社区托管的Wikibase云服务提供。每个Wikibase包括一个SPARQL端点和一个查询接口。尝试使用Wikibase云服务的小组包括大英图书馆的档案馆和手稿，Koninklijke Bibliotheek，中世纪采矿文本项目和地图手稿迁移项目。这些项目都没有超出创建属性列表和一些基本手稿记录的范围，尽管大多数项目都提供了一个或多个用于测试的示例SPARQL查询。

例外是重新开发的数字脚本库，这是北美图书馆中中世纪和文艺复兴时期手稿的联合目录。用于此项目的数据模型是以对象为中心的 (而不是像映射手稿迁移那样以事件为中心)，并且侧重于手稿元数据记录。作为评估此服务原型的一部分，开发并运行了一组24个SPARQL查询。这些旨在模仿搜索和浏览，通过查找具有给定元数据元素 (名称，位置，主题等) 的特定值的手稿记录，或者通过查找具有该元素的任何值的所有手稿记录。用于此原型测试的SPARQL查询已通过GitHub存储库提供。

SPARQL查询的可视化界面

随着可用的链接开放数据量的增加以及SPARQL端点数量的增加，对跨这些知识图进行搜索和浏览的高级方法的需求也在不断增长。只有这样，才能充分发挥数据模型的丰富性和复杂性。对于SPARQL查询的未来改进和改进的两个发展在这里具有重要意义。第一个涉及可视化界面，第二个侧重于基于AI的查询制定方法。其中，前者更为先进，而后者则是自2022年11月ChatGPT公开发布以来才真正出现的。

在这种情况下，术语 “可视界面” 是指用于构建和概念化SPARQL查询的可视方法，这与通过诸如sampo-ui之类的软件对知识图的可视表示不同。这些接口中的大多数专门用于Wikidata SPARQL端点。Wikidata本身提供了一个查询帮助程序，它提供了一种使用下拉菜单创建查询的方法，以查找和组合属性和实体类。最近，它还添加了一个查询生成器，用于通过组合下拉菜单中的属性来创建简单的SPARQL查询。

2023年11月，两家领先的语义网络公司 -- metaphacts和Ontotext -- 联合推出了一个免费的Wikidata knowledge graph公共界面，结合了各自的metaphactory和GraphDB产品。从特定实体或类的关键字搜索开始，然后可以逐步以图形方式探索各种连接。虽然可以显示的连接数有限制，并且熟悉Wikidata实体和属性模式非常有帮助，此服务确实提供了一种有用的可视化方法来研究手稿收藏 (只要它们在Wikidata中记录)。例如，您可以为个人手稿和收藏建立来源跟踪，并探索手稿所有者与其相关组织成员之间的重叠联系。结果也可以显示为列表或使用 “pathfinder” 功能探索直接连接。

该产品与ResearchSpace软件有些相似之处，该软件最初是由metaphact斯与大英博物馆联合开发的。ResearchSpace专为使用cidoc-crm本体而设计，通过在图形的每个步骤中提示用户可用的属性，还可以从实体或类直观地构建查询。映射手稿迁移项目试验了一个版本的ResearchSpace，导入所有MMM数据，设置一些基本的查询路径，并产生一些可视化。ResearchSpace社区主要与博物馆收藏有关，尽管有几个与手稿相关的项目。

为SPARQL开发可视化查询构建器，有时作为研究项目，有时用于特定机构或集合。图书馆界最近一个有趣的例子是SPARNATURAL，其中包括法国国家图书馆和法国国家档案馆的示威者。界面的外观最终源自ResearchSpace，但可以将其配置为与各种数据模型和端点一起使用。一个有用的功能是能够显示实际的SPARQL查询。

使用AI进行SPARQL查询

从2022年11月的ChatGPT开始，基于大型语言模型 (llm) 的聊天机器人的公开发布引发了大量的讨论和实验，围绕它们对构建和探索知识图谱的影响。由于这些人工智能服务已经被推广为执行复杂而复杂的人类任务的一种手段，如写作、作曲和图像制作，对于聊天机器人来说，允许非专家用户构建SPARQL查询也是可行的，没有从头开始创建此类查询所需的知识程度。在ChatGPT “概述” 页面上给出的示例之一是 “编写SQL查询”，因此我们可能希望AI聊天机器人也可以处理SPARQL查询。

GPT-4 (GPT系列中最复杂的版本，可在Microsoft的Copilot中的免费公共版本中获得)可以提示为Wikidata查询服务构建SPARQL查询。我要求GPT-4 “写一个Wikidata SPARQL查询，以查找19世纪成为Roxburghe俱乐部成员的人所拥有的手稿，并在可用的地方显示他们的姓名和会员日期”。在生成的SPARQL查询中，为Roxburghe俱乐部给出的实体引用 (Wikidata QID) 是错误的，其中一个属性也是错误的，查询要求的是出生日期而不是会员日期。相同的请求在Copilot/GPT-4中运行了四次，每次都返回不同的查询结构。即使在更正了实体引用和属性之后，这些查询都没有针对Wikidata查询服务成功运行。这个实验表明，虽然GPT-4对SPARQL和Wikidata有足够的了解，可以编写一个合理的查询，但它似乎在识别特定实体的qid以及Wikidata查询语法方面存在问题。生成的查询需要彻底的调试，这需要大量的SPARQL知识，并且不是SPARQL初学者可以简单地成功运行的。

尝试将GPT-4的SPARQL知识扩展到Wikidata以外的端点也被证明是有问题的。我要求Copilot “编写一个SPARQL查询以针对“ 映射手稿迁移 ”SPARQL端点运行，以查找Henry Yates thompson拥有的所有手稿 (表现单例)”。我还告诉它使用MMM模式中列出的类，属性和名称空间前缀。响应是一个SPARQL查询，未能定义其两个前缀 (ecrm和mmms)。添加这些定义后，查询仍然无法产生任何结果，部分原因是使用了错误的属性来链接所有者和手稿，部分原因是使用了错误的方法来指定Thompson作为所有者。

我还要求GPT-4编写一个SPARQL查询，以针对数字脚本库Wikibase运行，给它SPARQL端点的地址，并要求查询以查找宾夕法尼亚大学持有的所有手稿。我还将其引用到中列出的类，属性和命名空间前缀Koho等人，2023年查询语法。响应在各种方面都不令人满意，没有产生任何结果:

目前，虽然GPT-4可以为构建Wikidata SPARQL查询提供一个起点，但这些仍然需要仔细审查和调试。它似乎难以为其他SPARQL端点制定可行的查询。然而，这些只是基本的初步调查，通过先进的提示技术和定制，使用Mistral或Claude等其他LLMs很可能会获得更好的结果，或者通过针对特定任务微调LLMs，可能与SPARQL验证器结合使用。实施这些方法所涉及的技术知识水平可能超出了典型的人文研究人员或图书馆员的能力，并且可能需要由适当的专家进行调查。

鉴于将知识图纳入LLM训练是生成式AI研究中的一个热门话题，未来LLM的迭代极有可能能够更有效地响应此类任务。一个更直接有希望的发展似乎是将LLMs集成到像metapactory这样的软件中，这是一个用于构建和探索LOD知识图的商业解决方案。2023年10月，发布了一个用于beta测试的metaphactory应用程序，该应用程序将自然语言查询转换为SPARQL查询。虽然它为此目的使用了公共版本的ChatGPT，但翻译过程可以从隐喻软件中进行控制。

影响SPARQL有用性的问题

映射手稿迁移 (MMM) 的经验表明，与中世纪和文艺复兴时期手稿相关的数据和数据结构的不确定性如何影响SPARQL查询的有效性和有用性。手稿描述中存在许多固有的歧义: 例如，生产日期通常只是估计，而生产地点通常只能在区域或国家一级分配，有时涉及多种可能性。其他不确定性与来源证据链中的空白有关，例如手稿中仅记录姓名或家族波峰的标记。处理手稿片段是另一个挑战，随着时间的推移，手稿卷的拆分和合并也是挑战。

数据模型中的模糊性是另一个关键因素。的Schoenberg数据库记录销售和拍卖目录中手稿的外观，但通常不包括有关手稿是否出售或出售给谁的信息。这种固有的模糊性意味着cidoc-crm “转移保管” 事件类 (E10) 不能自动应用于这些事件。必须专门为这些事件创建通用的特定于MMM的实体类 “manuscriptactivity”; 这影响了MMM数据中大约三分之二的所有起源事件。同样，MMM设法从Bodleian图书馆的目录中提取了20，000多个出处陈述。但是只有TEI 元素可以映射到cidoc-crm本体中的特定事件类型: E12_Production。所有其他来源事件都必须映射到 “manuscriptactivity” 类。这极大地限制了牛津数据可以被分析和可视化的特异性程度。

在Wikidata的数据模型中，作者不应直接附加到手稿上，而应通过手稿中包含的作品间接链接。然而，这种方法并未得到一致采用。作品和作者之间的关系也是有问题的Schoenberg数据库,其中单个手稿中的多个作品中的每个作品都没有专门链接到作者，而是多个作者的列表仅位于作品列表旁边。这些方法使构建涉及手稿作者的SPARQL查询变得更加复杂。

有许多可能的方法可以通过SPARQL查询来提高手稿数据的价值以进行分析。为不同类型的起源事件使用合适的词汇将是有价值的，尽管cidoc-crm本体提供的类型学可能需要扩展到涵盖诸如 “出售”。将角色添加到出处陈述中的个人和组织的出现将支持更细粒度和细微差别的分析。对于cidoc-crm，可能需要添加一些内容来扩展其有限的属性集，目前包括 'P51_has_former_or_current_owner' 和 'P52_has_current_owner'。

其他改进可能包括使用日期范围 (1300-1325) 而不是基于文本的语句，例如 'circa 1310'，或者使用不确定性模型，例如CIDOC CRM的时间关系原语。从个人、组织和地点等实体的广泛使用的词汇表中嵌入统一资源标识符 (uri)-如VIAF、Wikidata和GeoNames-也可以丰富围绕作者的查询，收藏家和业主。发布中世纪和文艺复兴时期的人物，地点和作品的链接开放数据词汇表将对此有所帮助。分配手稿标识符的通用方法 (例如ISMI倡议提出的方法) 对于链接与特定手稿相关的不同数据至关重要。

结论

近年来，使用RDF三元组和链接的开放数据框架构建的知识图使有关中世纪和文艺复兴时期手稿的丰富而复杂的数据集得以开发。虽然这些数据集可能具有用于搜索和浏览的用户友好界面，但探索其全部潜力最终需要SPARQL端点和SPARQL查询语言。SPARQL查询可以探索数据中的复杂关系，并支持跨多个此类数据集的链接查询。然而，数据结构的复杂性可能需要复杂的查询，而SPARQL因其明显的难度而臭名昭著。建议进行大量培训，并获得专家建议。

一些项目 -- 尤其是映射手稿迁移和数字脚本库2.0 -- 已经成功地系统地使用SPARQL查询进行测试、探索和诊断。这些方法证明了SPARQL对手稿研究的潜在价值。通过开发可视化查询接口和将查询嵌入到其他软件环境中，正在采取各种举措来提高SPARQL的可用性。虽然像GPT-4这样的AI聊天机器人可能能够帮助编写SPARQL查询，但它们目前的能力非常有限。

Wikidata及其相关的Wikibase项目是目前最重要的开发领域，尽管相对有限的手稿数据目前仅支持相当基本的SPARQL查询。一旦手稿的Wikidata数据模型得到改进，并且更多的库开始提供数据，通过Wikidata查询服务及其Wikibase等效项进行复杂的SPARQL查询的潜力就很大。

致谢

绘图手稿迁移项目由跨大西洋伙伴关系在其挖掘数据 (第四轮) 计划下资助。该项目的合作伙伴是牛津大学，宾夕法尼亚大学，阿尔托大学与赫尔辛基大学 (HELDIG) 合作以及文本研究和历史研究所。资金由英国经济和社会研究理事会、博物馆和图书馆服务研究所、芬兰科学院和国家研究机构提供。

利益冲突 提交人没有要声明的竞争利益