在多模态数据库中实现链接艺术以进行跨馆藏发现

导言

在2018年至2023年之间，耶鲁大学设计，实施并发布了一个新颖的跨馆藏和跨域发现应用程序，以实现对其博物馆，图书馆，档案和特殊收藏。这个应用程序，叫做LUX，是使用链接的开放可用数据 (LOUD) (Raemy，2024年;Sanderson, 2018)。基本范例是确保以连接和连贯的方式呈现集合，而不仅仅是汇总记录。建立了原型并进行了评估，以找到围绕数据，技术以及系统与人员之间交互的最合适的解决方案-无论是最终用户，数据和软件工程师还是内容提供商。由此产生的应用程序正在积极使用的教师，员工，学生和公众，谁用它来发现和参与由大学持有的集合。该代码也可以通过GitHub平台获得。

本文报告了为评估文化遗产发现系统的链接数据的整体效用和可用性而进行的实施和分析。我们表明，通过遵循强调可用性而不是语义完整性的设计原则，实现可以更丰富，并为用户提供慷慨的接口。它根据三个核心工作领域分为几个部分: 数据，使用的技术和前端应用程序的设计。

链接的艺术数据

对于将提供对多个集合的访问的跨域发现系统，要考虑的第一个方面是可用性、质量、以及将来自系统的所有现有数据建模为一个连贯和连接的整体的可行性。由此产生的聚合需要作为一个单一的平台与之交互的用户可以理解，而不是一个弗兰肯斯坦式的恐怖与脱节的部分大致缝合在一起。本节讨论了链接的艺术数据模型的历史，要求以及由此产生的选择和自定义，以用作LUX应用程序的主干。

背景

从2009年开始，耶鲁大学开始了一个跨馆藏发现平台 (Bellinger, 2011) 为其博物馆藏品使用当时可用的技术，如Solr (阿帕奇，2024年) 、XML (W3C, 2008) 和oai-pmh (OAI, 2015)。由于各种原因，该项目没有得到维护，但它确实是LUX开发项目考虑的起点和实验。LUX的最初原型使用了这些相同的技术，但其目的是将数据扩展到包括图书馆和档案馆，并协调对人员，组织，地点的引用，通过使用学生的努力和自动化来实现整个集合的概念。这个原型展示了技术堆栈和数据结构的局限性，很快就被记录中引用的每个实体的标识符的使用所淹没。此外，它无法为交叉记录搜索或协调的上下文实体作为单独页面的呈现提供所需的交互。这导致建立了一套基本要求，用于评估数据结构和支持它们的技术。

要求

考虑到现有数据和项目过程中协调集合和数据集之间的参考文献的估计能力，产生了对数据的初始要求，以评估所需交互的可行性。这一实际的、结果驱动的目标非常有价值，因为它避免了许多关于元数据标准的跨域讨论: 与其将标准A与标准B进行比较，两者都是独立且相对客观地与同一组要求进行比较的。

核心初始要求及其包含的意图摘要如下:

数据必须描述所有收集项目，以及他们引用的人员和组织，地点和主题，以提供项目的上下文。

每个项目和引用的实体都必须有一个标准化的记录，以便将来自各个集合的信息汇集在一起，并在用户界面中提供一个 “中心” 页面，通过它，用户可以发现相关项目。

用户必须能够在项目页面和中心页面之间无缝导航，了解项目和中心页面实体之间的关系，但每个页面必须是独立可理解的。

基础源记录的所有重要字段必须在共享数据结构中以清晰的方式表示，尊重不同域的唯一性和价值，连贯的接口，以确保所有集合都得到很好的表示。

用户必须能够使用关于集合项目和它们的相关实体的信息来搜索集合项目，以允许查询的精确定向并且扩展在各个集合的发现系统内已经可用的功能。

尽管不是绝对的要求，但人们欣然承认，如果数据结构易于软件工程师理解和使用，然后，将有更多的时间来处理LUX本身，因为了解神秘或不一致的规范所需的投资会更少。

这些要求，加上使用耶鲁英国艺术中心数据集构建的原型 (YCBA，2024年) 和开源拱门平台 (Farallon，2024年)，证明了知识图范式的重要性，并促进了从自定义XML模式到链接的Art元数据应用程序配置文件的过渡。

链接的艺术数据模型

链接艺术数据模型最初是为梅隆资助的美国艺术合作组织 (AAC, 2017) 项目，随后由JPaul Getty Trust作为他们关联数据工作的基础。然后在Kress基金会和英国艺术与人文研究委员会资助的项目的支持下，将其带回社区进行讨论和参与。

它是作为CIDOC概念参考模型 (cidoc-crm) 的元数据应用程序配置文件构建的 (CIDOC，2024年) 加上最少的扩展，旨在减少开发人员需要做出的选择数量，以提高易用性、理解和互操作性。通过使用cidoc-crm，它继承了经过充分讨论和标准化的概念模型以及类和关系的本体，因此，链接艺术的发展侧重于使该模型与现实世界的实践，数据和用例保持一致。在转向其对产品的适当性以及它如何满足规定的要求之前，有必要简要概述模型的特征。

类

Linked Art使用cidoc-crm中的少量类，并为开发人员在数据中使用它们提供了更令人难忘的名称-而不需要记忆任意数字。如果可以获得更具体的信息，例如区分绘画和雕塑，则将此信息作为词汇级别的分类进行传达，而不是作为本体级别的类。这些类别很好地符合LUX的要求，并保持 “item” 和 “hub” 实体所需的分离。

集合项目是使用类HumanMadeObject的物理对象，或者是用类DigitalObject表示的数字文件。人们和组织分别使用班级Person和Group，并且地理位置被地方班级很好地容纳。概念或主题具有更广泛的类，基于概念实体的性质，并依赖于语言，材料和测量单元的特定类，与用于一般科目的更广泛的类类型。这满足了基线要求; 然而，在评估中，与作品分开的对象 (或图书馆术语中的 “持有”) 的书目概念变得很重要，以及使用收藏项目发生的事件，如展览。

为了区分特定文本的多个物理或数字副本而不重复每个记录中的信息，以及类似地区分特定视觉内容的多个副本，链接艺术具有智力作品的概念，其方式与现有的书目本体和模型相同，例如国会图书馆的BibFrame (LOC，2024年)，或IFLA的LRM或FRBR (IFLA, 2018)。与那些更复杂的系统不同，链接艺术仅使用两类: 主要基于语言并打算阅读的作品的语言对象，和VisualItem用于主要基于图像并旨在被看到的作品。语言对象的单个实例，例如哲学书籍的文本，可以由多个物理和/或数字对象承载，从而允许将藏书和书目信息连接起来。这同样适用于视觉内容，例如雕塑的多个模型或照片的印刷品。

为了处理展览和其他活动，例如出处，链接艺术具有广泛的活动类别。然后，可以对所描述的活动进行更具体的分类，并将所使用的项目，参与活动的人员和组织，进行活动的地点，以及发生的时间或日期。

所需的最后一类是处理档案收藏，部门或机构收藏以及展览中使用的物品集。底层的cidoc-crm本体不具备同时包含物理和数字项目的能力，更不用说概念作品或其他类了，因此，链接的艺术元数据应用简档具有定义称为Set的类的小扩展。此类表示可以具有不同类型成员的数学集。

例如，这幅画 “吉弗尼的艺术家花园” (勒克斯，2024年) 是人类制造的物体，由克劳德·莫奈制作。它被归类为一种特殊类型: 一幅画，并由以下材料制成: 油画。它显示了一个可视化项目，它反过来描绘了类型: 鲜花和地点: 吉维尼。它有一个主页，在耶鲁大学美术馆的家博物馆中以数字对象的形式表示。它是代表画廊欧洲艺术收藏品的一组对象的成员，而画廊又由代表欧洲艺术部门的小组进行的活动进行策划。

为了区分特定文本的多个物理或数字副本而不重复每个记录中的信息，以及类似地区分特定视觉内容的多个副本，链接艺术具有智力作品的概念，其方式与现有的书目本体和模型相同，例如国会图书馆的BibFrame (LOC，2024年)，或IFLA的LRM或FRBR (IFLA, 2018)。与那些更复杂的系统不同，链接艺术仅使用两类: 主要基于语言并打算阅读的作品的语言对象，和VisualItem用于主要基于图像并旨在被看到的作品。语言对象的单个实例，例如哲学书籍的文本，可以由多个物理和/或数字对象承载，从而允许将藏书和书目信息连接起来。这同样适用于视觉内容，例如雕塑的多个模型或照片的印刷品。

为了处理展览和其他活动，例如出处，链接艺术具有广泛的活动类别。然后，可以对所描述的活动进行更具体的分类，并将所使用的项目，参与活动的人员和组织，进行活动的地点，以及发生的时间或日期。

所需的最后一类是处理档案收藏，部门或机构收藏以及展览中使用的物品集。底层的cidoc-crm本体不具备同时包含物理和数字项目的能力，更不用说概念作品或其他类了，因此，链接的艺术元数据应用简档具有定义称为Set的类的小扩展。此类表示可以具有不同类型成员的数学集。

例如，这幅画 “吉弗尼的艺术家花园” (勒克斯，2024年) 是人类制造的物体，由克劳德·莫奈制作。它被归类为一种特殊类型: 一幅画，并由以下材料制成: 油画。它显示了一个可视化项目，它反过来描绘了类型: 鲜花和地点: 吉维尼。它有一个主页，在耶鲁大学美术馆的家博物馆中以数字对象的形式表示。它是代表画廊欧洲艺术收藏品的一组对象的成员，而画廊又由代表欧洲艺术部门的小组进行的活动进行策划。

通过在基础和概念模型中表达数据，这些类不仅仅满足了基线要求，还有助于澄清跨域的理解; 而不是试图在特定于领域的模型之间交叉行走，这是整个信息科学史上许多项目的失败。

关系

核心类之间的关系更广泛，并且在图中表达了许多知识，但仍然很少，足以容易理解和使用。

任何类的实例都可以是集合的member_of，也可以是classified_as类型，分别包括集合和类型的实例。Place实例可以是较大Place的一部分，允许描述空间层次结构，但在其他方面与其他类没有关系。类似地，类型实例和其他概念可以具有更广泛的类型，并且通过活动被构想成存在，该活动可以由人或组、took_place_at地点、并且可以是任何类的实体的influenced_by，但在其他方面没有其他关系。Person和Group的实例是由嵌入在其记录中的事件产生或形成的，该事件又在某个位置产生或形成。他们也可以在一个地方有一个住所，并且可以是一个组的成员。这使得核心关系由感兴趣的主要实体承载: 收藏项目和智力作品。

HumanMadeObject实例可以携带LinguisticObject或show VisualItem，同时DigitalObject可以digitally_carry LinguisticObject或digitally_show VisualItem。数字集合项目由嵌入的活动创建，物理项目使用produced_by关系。虽然有一个项目的销毁关系，但它将不再存在于集合中，因此我们在耶鲁用例中不需要这个。通过查找而不是创建来进入文化记录的对象使用了conventered_by关系。物理对象可以是材料的made_of，并且还具有个人或组的current_owner和地点的current_location。

LinguisticObject的实例也可以通过使用与活动的created_by关系而存在，并通过被用于发布活动而被发布。两者都可以是关于任何其他类的实例，以使用关于关系描述其主题，并且VisualItem可以具有引用图像直接描绘的任何其他类的表示属性。LinguisticObject实例是指通过Language属性编写它们的语言。这些类和关系总结。

数据模式

上面描述的关系是主要类之间的路径; 然而，也有几种模式，它们用于记录中的所有类，以便直接表达有关它们 (属性) 的信息，而不是记录之间的关系。这些模式包括重要信息，如名称、标识符、描述和数据外部的外部链接。与其详细介绍它们的内部结构，不如列举它们; 以证明可以满足所有核心数据建模要求。

使用的模式是:

名称或标题，通过identified_by属性，它可以使用classified_as具有内容、语言和分类。

标识符，也通过identified_by属性，具有内容和classified_as，但没有语言。标识符还用于描述实体的地址或contact_point。

任何类型的描述或语句，通过referred_to_by属性，镜像名称结构，但具有较长的文本内容。

Dimensions，通过dimension属性，具有数值、MeasurementUnit实例和分类 (如height或width)。

通过subject_of属性对外部网站、图像、api或其他数字资源的引用，包括名称、分类和用于检索它们的access_point URI。

也描述同一实体的外部资源通过等效属性链接。

最后，日期和时间嵌入在活动中 (在记录中或单独)，使用记录最早可能开始，最晚可能结束的TimeSpan结构，和人类可读的时间形式。

我们现在可以根据需求、数据、软件工程师的可用性和核心用例来评估模型。

评价

从上面的描述中可以清楚地看出，链接的Art模型满足了大多数要求。需要进一步讨论的方面是: 它如何处理艺术博物馆收藏目标之外的领域，在不同的收藏管理系统中管理的现实数据，以及没有艺术史或图书馆学背景的软件工程师的可用性。

跨域建模与数据

链接艺术很容易捕获两个艺术博物馆的收藏管理系统管理的绝大多数信息。少数场景无法捕获为结构化数据，因为它们已被链接的艺术社区确定为与值相比过于复杂，例如明确地知道艺术家是一个人或另一个人，但不是两者，以及对归属不确定性的其他详细描述。其他边缘情况包括博物馆希望在应用程序中使用特定的标签或演示文稿，但该信息不是由元数据携带的，并且无法在所有数据集上推广。其中一些后来通过与部分记录相关的附加陈述得到解决，例如，可以在要渲染的语句中更详细地描述特定制造商在对象生产中的角色，而对人和活动类型的引用可以与描述性内容一起表示为结构化数据。

有关耶鲁皮博迪博物馆自然历史收藏的信息 (YPM，2024年) 可能是离艺术和文化遗产领域最远的领域，它关注的是从全球收集的动物、植物和矿物标本。皮博迪也是其他物品的管家，包括巴比伦石碑和科学史上的收藏品，这些物品更干净地落入美术馆的案例中。标本的主要区别在于它们不进行智力工作，因为它们不是由具有创造性意图的人生产的。将对象的物理性与智力工作完全分开是数据模型的优势，可以准确描述不带有创意作品名称的博物馆对象。为了数据的一致性、可用性和标准一致性而做出的妥协是，即使样本不是由人类制作的，系统仍然会使用HumanMadeObject作为类。部分理由是，一些标本确实是人类制造的物体，因为它们是随着时间的推移由保护者积极修复、重建或制造的。另一种方法是有一个单独的PhysicalObject类，仅用于标本; 增益将是纯粹的语义而不是实际的。

类型类很容易处理分类学层次结构，并且组和活动的区别意味着可以将远征区分为谁去 (组) 从他们去的地方和时间 (活动)。最难建模的区域是地层学，它通过分析岩石层 (或地层) 来同时描述地质时间和空间位置。以及它们相对于彼此的位置。这个细节是正在进行的工作的主题，最初的模型引入了一个新的类来处理洞穴，拱门，地层和自然世界的其他不可分割的特征。

在对 “档案” 的性质做出初步决定之后，使用链接艺术对档案进行建模相对容易。档案传统将访问对象的智力安排及其物理位置的描述合并为一个层次结构，以方便基于非图形的描述性格式，例如XML。因此，有必要确定档案是位置上事物的物理和/或空间层次结构，还是以特定方式排列对象的人类创造力的产物。通过将位置与安排分开，我们可以确定档案集合是其他集合 (安排内的进一步划分) 的集合 (作为概念实体)。或HumanMadeObject或DigitalObject (项目本身) 的实例。其中一些项目在空间中具有已知位置 (地点) 或包含在其他humanmadeobject中，例如文件夹中的字母。然后，链接的艺术界讨论了这种分析，因为许多美术馆都有相关的档案。

绝大多数记录来自耶鲁大学图书馆馆藏 (YUL，2024年)，总计约1300万件作品，包括3000多万条个人相关艺术记录。对象和作品之间的划分对于此讨论也很重要，因为某些对象带有多个作品 (例如包含不同作者的几个不同文本的手稿)，并且许多作品由多个对象 (例如同一教科书的多个副本) 承载。同样，MARC中管理的绝大多数信息都很容易映射到链接的Art模型中。没有认真尝试协调工作，因为现有数据库中没有足够的信息以引入比错误更多的价值的方式进行; 但是，如果可能的话，数据模型将支持它。

关于图书馆数据的挑战不是建模，而是以前所未有的方式从MARC格式中提取知识，从而暴露了将记录解释为知识的重大问题，而不是它的渲染为HTML。一个有趣的错误是，当一个物体的条形码被错误地输入到一个人的子字段中时，导致它看起来像是这个人在未来数万亿年的死亡日期。虽然这是一个简单的解决方案，但一个持续存在的问题是使用了不正确的主题标题子字段，导致国家成为城市的一部分，而世界两端的国家被嵌入其中。

总体而言，虽然有些领域需要最少的补充，但少数情况无法建模。但是，Linked Art很容易满足使用连贯，连接且相对完整的数据模型描述这四个不同领域的所有要求。

可用性

模型的第二个测试是数据和软件工程师容易产生和消费符合模型的记录的程度。在LUX中，有三个不同的领域需要工程努力: 从收集单元内的软件工程师处理的收集记录中创建链接的艺术记录，与策展人或馆藏经理等主题专家合作; 整合，由数据工程师集中协调和丰富这些记录到单个连贯的数据集; 以及使用结果数据为最终用户生成直观且功能强大的发现系统，由软件工程师和用户体验设计师。

直接与数据模型交互的第一批项目参与者是各个收集单元内的收集系统经理和软件工程师。对于每个单元，这需要大约六到十个小时的讨论，以生成从记录系统到数据模型的映射，然后进行迭代工作以在代码中实现该映射。这包括艺术，自然历史，档案收藏和书目记录四个不同的领域，跨越五个收藏管理系统。每个收集单元根据其数据的性质和可用软件工程师的技能设计并实现了不同的转换过程。这些转换很快就完成了，除了图书馆的数据，由于该集合的规模-大约1300万个项目。对于从现有记录系统进行映射和转换，这表明跨域图数据模型不是障碍。这随后导致其他收藏被映射和转换，包括音乐学院的乐器收藏，大学直接拥有的校园艺术收藏，文化遗产保护研究所的保护相关藏品，以及英国保罗·梅隆中心的藏品，这样就可以将它们添加到LUX中。

然后收集记录，如在下一节中讨论的，并进一步操作以生成单个相干数据集。用于此目的的可用性评估存在严重偏见，因为中央数据工程是由作者和具有多年模型经验的数据工程师执行的。考虑到这一点，模型的功能使自己能够熟练地执行要执行的任务，特别是对于内部记录与描述相同实体的外部数据集的对齐，以及随后将多达十几个记录合并为单个丰富的描述。通过强大的概念模型和一致的数据结构，比较来自非常不同的域和系统的记录比处理本机格式的信息要容易得多。

第三，一旦建立了数据集，软件和UX工程师就会参与数据模型，以设计和实现一个可理解且有用的发现环境。这需要理解抽象模型，以便设计用于搜索和链接的记录之间的交互，以及json-ld的细节 (W3C, 2020) 格式，以便适当地提取、索引和呈现不同的字段。软件工程师对文化遗产领域的接触有限，而主要的前端工程师刚开始时只有两年的学位后经验，然而，他们能够快速理解并有效地使用这些数据。这种端到端的工作流程，包括各种经验，工具和平台，已经证明了链接的艺术很容易实现，使用各种环境，由相对初级的技术人员组成。

和解与充实

除了内部数据源，在撰写本文时，还使用了20多个外部数据源来协调和丰富有关人员，组织，地点和主题记录的知识。这些来源由数据工程团队映射和转换，作为转换管道的一部分，包括文化遗产管理局的数据，如盖蒂，国会图书馆和OCLC词汇表，大型国际数据集，如法国、西班牙、德国、日本和瑞典将提供更多的国际视角，以及更通用的数据集，如维基数据。这进一步测试了数据模型，并提供了重要的知识，以确保实体具有足够的描述和关系，从而对整个知识图做出积极贡献。

拥有目标的核心好处通用语言对于知识图谱来说，处理和合并记录，无论它们来自哪里，与必须处理所有系统的本机表示相比，都相对容易。来自内部和外部来源的同一实体的等效uri的可用性意味着这些可以快速匹配以创建有关实体的信息云。高度确信记录确实描述了同一件事。对于人员，组织和地点而言，这比主题和其他更理论的概念更为成功; 但是，通过该过程增加的价值大大超过了它所引入的错误。虽然在本文中讨论协调和丰富管道的确切算法和挑战超出了范围，但如果没有将此功能内置到体系结构中，则该项目将无法实现。数据模型直接促进了处理。

关联数据技术

计算机上的数据没有价值，没有软件来管理和提供给目标受众；作者使用链接数据工具的长期经验是，它们要么是不可用的缓慢，不直观，令人难以置信的复杂，非常昂贵，而且经常是所有上述情况。对于耶鲁大学来说，要实施链接艺术，需要一种解决方案，使所有人都能轻松获得知识，而又不会破坏银行或工程团队的思想。

虽然在耶鲁大学的馆藏中使用了各种各样的经验和系统，但在构建LUX的项目之前，链接的开放数据只是一个有趣的概念。需要有效和可用的技术，这些技术不能取代记录系统，而是可以增强对记录系统的访问。需要研究哪些技术平台可以满足项目的需求，并且在更广泛的背景下进行考虑是有价值的，因为这是一个艰难的决定，各机构在自己的实施道路上必须面对。

要求

为了确保系统和体系结构的公平比较，在研究开始之前建立了30个要求，标题为: 数据，搜索和查询功能，性能和开发人员的幸福感。在四个月的时间里，对七个不同的系统进行了评估，然后选择了两个功能强大的竞争者。

候选技术的初步选择是基于几个核心 “必须具备” 的要求，其中最有区别的是，最终的系统必须能够执行两种图形搜索，以利用数据和文本关键字查询中的关系，这些查询将信息视为更传统的JSON记录(因此熟悉和直观) 时尚。其次，它必须具有足够的性能来生成跨大型结果集的方面，包括使用通过图中的以下关系获得的值。

要求清单还包括易于摄取，索引，转换，保护和检索记录; 支持标记化和多语言文本的提取，分配和自定义相关性分数，地理空间数据，和面的生成; 支持布尔、实地、范围 (例如g.,日期或数字)和分层查询; 支持地理空间和图形查询; 使用标准，api和代码库，以及产品的文档和供应商支持的现成可用性。

在评估市场时，很明显，有两类系统都需要大量的时间和资源投入，做出错误的决定对项目来说将是灾难性的，除非它被足够早地发现并迅速改变方

多模态解决方案vs系统集成

第一类是一个单一的多模态系统，可以同时处理图形和文档样式的查询。很明显，在这一类别中没有开源选项，只有极少数供应商提供现实的解决方案。另一种方法是找到最有能力的产品集来管理记录、文档搜索和图形搜索，然后将这些工具集成到更分布式的体系结构中，如图2。第二类有大量的开源或基于云的工具; 然而，集成所需的时间将减少可应用于发现平台的工作量。

通过评估过程，亚马逊云科技工具的组合 (亚马逊，2024年)，例如Neptune，Elastic和DynamoDB，并考虑了更多公开可用的产品。在这两种情况下，甚至试图让一个性能足以满足基线要求的集成查询所需的工作量是如此之大，以至于它们被排除在考虑之外。在还丢弃了声称具有高性能多模式功能但实际上无法处理数据的产品之后，最终选择归结为两种产品: 真正的多模式系统，以及外部构建的高性能图形引擎与Solr文本索引系统的集成。

在对实际数据进行大规模的广泛测试之后，考虑到许可和硬件要求，这两种产品都具有很高的能力，并且总体拥有成本大致相同。决定性因素是所涉及公司的寿命 (一个是初创公司，另一个是成熟的公司)，支持和文档的可用性以及平台现有用户的推荐。另一个考虑是，选定的系统也可以仅作为一个文件数据库，因此，如果图形功能在可用的实现时间内太复杂或太慢，则为项目提供一个回退路径。这些次要因素以其他非常平衡的比例倾斜，有利于MarkLogic (进步，2024年)。

解决方案体系结构

获取，处理和加载数据的整体架构需要一个单一的系统来管理信息，这将需要加载最终记录，而不是能够从三重存储库中即时构建它们。

为了与分布式记录系统中的更改保持同步，每个参与单位都实现了IIIF更改发现API (IIIF，2021年)，这反过来又建立在W3C的Activity Streams 2.0规范 (W3C, 2017)。选择此模式是因为图像内容已经可以通过更完善的IIIF规范获得，因此从同一套件中采用另一个API在技术上和政治上都很容易。Change Discovery API按时间顺序描述记录发生的更新事件，这样，收割机可以从最近的变化向后走，直到它最后一次处理流的点，通过web检索新的和更新的记录，并删除应该不再存在的记录。这些单元还会生成包含所有记录的大型转储文件，以避免在初始加载时出现数百万个HTTP请求。这些不是从活动流中引用的，但是此功能的值将作为对规范的反馈提供给IIIF联盟，以考虑将其包含在将来的版本中。

外部数据源不为其内容提供更改发现API，Getty词汇表除外; 相反，它们将作为转储文件下载 (如果可用)。并将其批量加载到记录缓存基础架构中，以便于访问，或者在后续处理过程中需要时下载。转储文件是非常可取的，以避免数以百万计的请求通过网络从世界各地检索个人记录，即使只有一小部分的数据集被使用。然后将这些记录映射并转换为链接的Art，如上一节所述。

将所有记录同步到单个虚拟机后，将并行处理它们; 该算法一次仅使用单个记录中的信息，因此，遇到记录的顺序并不重要。虽然这带来了挑战，但对账和浓缩管道的可扩展性很重要，因为结果系统中有4100万条记录，一次使用单个进程需要一个多月的处理时间。

处理管道仅使用开源产品，包括PostgreSQL，用于缓存记录的收获，中间和最终表示形式，以及Redis，用于极快地访问键/值存储，对于管理所涉及的1亿多个uri之间的一致性是必要的。处理是用Python实现的，作为数据工程师熟悉的语言，拥有丰富的现有库和工具。它有三个核心阶段

通过最初考虑被声明为标识相同实体的uri (例如，两个不同的授权系统中的相同概念之间的等价性) 来协调记录。如果没有提供或发现任何这样的uri，它会尝试将记录的名称与最近的域和实体类型机构完全匹配。例如，来自图书馆记录的人将首先与国会图书馆名称授权文件进行匹配，然后如果不匹配，则前进到其他来源。然后以相同的方式处理匹配的记录，以通过链接的开放数据网络收集越来越多的等价物。一旦协调并建立了标识符集，所有记录都将其标识符和到其他记录的出站链接更新为LUX使用的内部URI。最后，合并具有相同内部URI的所有记录，执行一些最终整理，并将数据集导出以加载到MarkLogic中，以供使用。

系统优化

在实现的早期阶段，处理管道将json-ld记录中的所有RDF三元组具体化为Marklogic，以确保所有信息都可用于图形查询。很快就变得很明显，在LUX的数据规模上，我们需要优化我们知道必要的交互的索引，而不是在三元组中索引所有内容的更传统的方法。

第一个更改是在数据处理管道中创建用于索引目的的人工三元组。例如，对象和创建它的人之间的关系可以通过三个三元组 (对象created_by/part/carried_out_by person) 而不是一个，这意味着系统需要跨大型中间结果集执行不必要的连接。为了缓解这种情况，我们添加了额外的 “快捷方式” 三元组，以防止需要连接，在本例中是lux:agentOfProduction。这也使我们能够优雅地处理略有不同的数据结构，包括该人是作为整体还是仅部分进行生产。

一旦我们建立了查询集，我们还为三元组构建了一个自定义生成器，而不是依赖于json-ld扩展算法。这被证明快了很多倍，让我们只实现我们需要的三元组来支持搜索，将数据集在磁盘上的大小减少了大约一半。虽然不必要的三元组在运行时不会影响性能，但它们需要大量时间来生成和加载，然后需要磁盘空间来存储。相同数据集的外部使用不会受到影响，因为每个三元组都存在于公开可用的json-ld记录中，因此我们在需要时具有语义精度，和我们的应用程序的性能。

查询最初是使用SPARQL (W3C, 2013); 但是，通过性能测试，我们发现称为CTS的MarkLogic查询语言的执行速度要快很多倍。通过将用于基于记录的搜索的文档标识符与图查询中使用的文档中描述的实体的URI对齐，我们可以非常有效地将图和文档查询连接在一起。这使我们能够使用正确的工具来完成这项工作: 文档搜索相关性和文本查询，以及图形搜索数据集中实体之间的连接。MarkLogic还有另一个名为Optic的API; 但是，在实现时，它在我们的用例中不如CTS那样高性能。

评价

通过在SPARQL和triplestores的传统链接数据框之外进行思考，并在文档和图形方面使用正确的工具来完成工作，我们能够创建一个高度可扩展和高性能的系统。此外，通过采用价格合理的商业产品，我们可以将有限的开发人员资源集中在理解和解决我们的具体问题上，而不是构建需要持续维护的集成架构。我们认为，链接数据技术已为当今的文化遗产部门做好了准备，非常适合处理链接艺术数据模型; 但是，必须注意做出适合项目或产品的选择。

跨集合发现

最好的数据模型，最干净和最精确的数据，以及最复杂的技术平台，如果没有直观和可用的web应用程序来允许用户与系统维护的知识进行交互，都将毫无价值。在图形之上而不是传统的关系或基于文档的系统之上构建发现平台，使我们能够重新思考围绕实现和用户体验模式的接收智慧，以产生创新的东西。本节将不直接处理LUX用户体验或界面设计，而是将重点放在从这项工作中学到的总体经验教训上。

用户体验范式

到目前为止，讨论一直以搜索和查询的技术术语进行; 但是，正如Roy Tennant所说的那样，“只有图书馆员喜欢搜索，其他人都喜欢查找” (Tennant 2001)。考虑到链接数据的使用，用户体验范例可以很容易地转变为查找或发现，而不是重复搜索。这可以通过采用单个适当的概念模型来跨集合进行管理，该模型用于一致地公开实体之间的关系，而不是仅仅在用户界面中将实体的名称显示为不可操作的字符串，或者将其视为搜索项，并将用户带到另一个结果列表。通过提供有关实体的记录，例如上面引用的Roy Tennant的人员记录，并在图3,用户可以以介导和受控的方式探索知识图。用户界面呈现关于该人的信息，以及与集合中的项目的关系 (例如，该人写的作品) 和其他实体 (例如其国籍或出生地及其职业)。此外，可以利用该图来通过确定频繁的共同作者、作者通常撰写的主题或者他们撰写或发表的地点来发现隐藏的关系。这允许用户容易地专注于他们正在寻找的东西，并且同时获得关于文化遗产景观中的人、地点、事件和概念的更多上下文信息。

鉴于可用的新功能，决定尝试使用户界面尽可能干净和熟悉，以使习惯于使用博物馆，档案或图书馆搜索系统的人们。这也有助于弥合领域之间的概念差距-搜索自然历史标本通常不会以与搜索书籍，绘画或档案层次结构相同的方式执行，然而，所有这些都包含在交叉集合数据集内。这意味着前端应用程序需要大量的设计工作，持续的实施和改进工作，并且已经过各种用户的测试。

在链接数据上构建应用程序

通过开发与链接数据直接交互的前端应用程序，可以学到两个主要经验教训。这些是将记录作为一种构造的必要性，并且web缓存基础结构可以支持相互链接的记录的负担，而无需在这些记录中复制信息，从而利用web的体系结构。链接数据爱好者的趋势之一是强调不再需要记录，并且所有知识只有一个图表。然而，没有什么可以进一步从可用性要求的事实，每个人，从内容经理到数据和软件工程师到最终用户，根据记录或至少根据不同的实体来思考，这些实体也可以表示为记录。为了在合理的时间内构建应用程序，合理的预算，并且不会将软件工程师送回大学获得图形查询优化的研究生学位，维护记录结构至关重要。此外，重复构建向最终用户呈现信息或计算结果集上的方面的计数所需的相同子图的计算成本是压倒性的。一种解决方案是为那些计算的子图引入缓存，将它们具体化为离散的、序列化的json-ld块，其在功能上等同于预先构造的记录。

web应用程序和知识图之间交互的架构设计也阐明了软件工程师直观地认为可行的内容，结果在实践中效果很好。人们非常希望通过定制的API将所有且仅必要的信息从数据集传递到前端，理由是，提供有关特定实体的所有信息太慢，对于前端应用程序来说，从深度嵌套的记录结构中提取信息太难了。然而，先前决定使用React (一个开发库，创建一个单页应用程序加载一次，然后通过javascript调用检索信息以呈现)与多层web缓存的使用相结合，意味着性能始终在预先建立的可接受的范围内，在一秒内渲染布局，在三秒内渲染细节。web缓存易于维护和优化，因为搜索是以系统的方式构建的，并且与数据的交互是通过静态json-ld表示，而不是动态构建的响应。由于React和浏览器也维护内部缓存，因此应用程序可以提取所需的记录方面，而无需请求其他表示。例如，相同的缓存响应将用于在一个页面中生成链接的名称、结果列表中的条目以及如果用户点击它的全记录视图。由于图是丰富连接的，相同的记录可能在单个用户会话中被多次使用。因此，用户的体验通过这种面向REST的范例得到改善，并且不会以任何方式降级。

通过在知识图的数据结构中进行有意的设计，使前端应用程序的实现变得更加容易。特别是，如第2节所述，在数据中一致使用模式允许构建提取、解释和呈现模式的javascript组件。然后将这些组合成更高级别的组件，并重复使用以产生不同的页面布局。数据的这种一致性和严谨性在开发时间，维护，无需完全重构即可更改应用程序的能力方面具有下游优势，以及前端与后端数据集或查询引擎的相对独立性。随着时间的推移，这大大降低了总体拥有成本，同时允许轻松重用数据或代码。例如，我们在一个完全静态的站点上使用了相同的前端应用程序，根本没有查询功能，而它 (当然) 依赖于从链接开始并遵循图中的关系，代码不需要更改以呈现有用的界面。我们还使用了相同的前端应用程序代码，并进行了一些非常小的外观更改，以创建用于发现研究数据集的用户界面，在MarkLogic后端中使用相同的数据结构进行管理。因此，相同的系统在没有后端功能的情况下会正常降级，并且可以在不重构新域的情况下重用，从而提供了高度可持续的代码库的有力证据。

超媒体API

如果一切都与其他事物相关联，那么 “跟随你的鼻子” 的知识发现方法就会很有效。然而，在像LUX这样的高度连接的知识图中，双向保持每个关系将是巨大的开销。例如，“书籍” 的概念需要对图书馆中数百万本书中的每一本都有明确的引用，并且添加任何新记录都需要更新它引用相应的反向链接的每个记录。相反，LUX遵循链接艺术API的建议，即从孩子链接到父母，或从多到少。这一建议意味着在 “书” 或 “标本” 案例中不会有成千上万甚至数百万个链接的记录，但是，数百万本书和标本中的每一本都与各自的概念链接一次。例如，具有100个页面的相册 (每个页面被单独描述) 将是来自这些页面的链接的目标，而不是直接链接到它们。但是，当您在相册页面，艺术家页面或状态页面上时，用户需要能够发现这些引用记录，而无需等待超过可接受的页面加载时间。

采用的解决方案是搜索引用当前记录的记录。给定引用的索引，如后端产品的triprestore方面所维护的，这是非常快的，并且几乎不会为系统增加直接关系的开销。然后，该页面呈现搜索的前几个结果和到完整搜索结果页面的链接，以便用户在记录和引用它的记录集之间转换。最初，这是通过将查询写入页面来完成的; 但是，面对不断变化的后端查询语法，不断变化的数据模型，或其他迭代工作。如上一节所述，应用程序和数据分离的大部分影响通过查询再次紧密耦合它们而消除。为了在保持功能的同时再次将系统拆开，我们使用超文本应用程序语言 (HAL) (凯利，2023年)，以提供前端可以遵循并接收标准化响应的命名搜索链接，而不必自己构造该链接。使用standard-defined_links属性将链接与语义知识分开。链接在请求时由中间层系统添加，该中间层系统测试是否至少有一个匹配的记录，因此如果前端在响应中看到链接，它知道检索表示将提供附加信息。由于这是响应的一部分，因此查询链接会被缓存，因此执行这些测试的一次性成本会迅速降低。

这种通过命名链接的间接方式提供了几个好处。首先，它将后端查询技术与前端分离，从而使两个系统解耦。相同的代码将以完全相同的方式使用完全不同的查询语言，因为前端不需要构造或操作它，只需遵循提供的链接。它还将数据模型细节与前端分开，允许两者更独立地迭代。我们可以更改特定查询的语义定义以包括更多的情况，并且前端代码永远不会注意到更改。最后，它在前端和后端工程师之间创建了更好的技能划分。与前端工程师创建查询相比，负责提供搜索索引的数据和软件工程师可以更轻松地配置和命名查询，尤其是面对不断变化的后端功能和数据模式。这种分离也是有效的，因为响应遵循W3C Activity Streams标准中的分页收集模式。该规范定义了合并为页面的项目集合，这些页面通过下一个和上一个链接进行双重链接，从而允许消费应用程序向前或向后遍历整个集合的方便大小的子集。它很容易实现搜索结果，方面的结果和更复杂的相关列表响应，也有特定的标签为每个结果。这为生产和消费实现提供了一个标准结构，而不需要为不同的用途重新实现特定于技术的格式。

评价

建立的模式和解决方案已经在实践意义上进行了测试，通过不断努力改善LUX，并在耶鲁大学的其他领域重新应用范式。使用链接艺术作为基线的不同数据集，建立一个新的系统来管理和呈现这些数据不到一个人一天的工程努力，包括几个新的索引和功能。这是由相对初级的软件工程师通过重用具有一些新配置的标签的现有组件并添加一些新的HAL链接来实现的。在添加HAL链接以将搜索范围 (例如，对象与人) 从查询参数移动到URI之后，查询结构发生了变化。前端应用程序根本不需要更新记录页面，尽管使用了十几个或更多的查询，因为它只是遵循新的HAL链接。

通过积极使用web缓存，提高了系统的性能，确保请求只有在上周真正没有完成的事情时才会一直到达数据库。没有缓存的系统的性能测试允许150个并发查询，但在常规操作中，我们从来没有接近这个数字，因为绝大多数是由不同的缓存层处理的。这种方法依赖于记录的一致标识和使用它们的单个静态表示，而不是构造应用程序特定结构的动态查询。虽然目前只有一个前端应用程序，但在不久的将来，将会有更多使用完全相同的后端基础架构，这也将证明 (或反驳) 一致性的价值。

结论

我们努力证明了一种方法的可行性和价值，该方法在使用链接艺术，IIIF，活动流，超文本应用程序语言等。特别是，链接艺术的基础本体设计使自然和文化遗产中的多个领域能够愉快地共存并相互关联，而无需进行大量工作来重新描述原始资料。链接艺术作为一致和连贯的数据模型以及易于理解和实施的API的可用性对于LUX的成功至关重要。数据的一致性实现了产生、转换和与所得到的知识图交互的实现中的一致性和简单性。基于记录的API结构也是必不可少的，因为它减轻了实现的负担，并允许使用标准技术和工具在计算上易于处理刻面等功能。使用同时支持基于图形和基于记录的搜索的多模态数据库，可以将正确的工具用于所需功能的不同方面。最后，web缓存基础设施的使用和HAL链接为命名搜索提供的间接帮助确保前端是高性能的，易于构建和调整，和廉价的维护和重用。

耶鲁希望通过采用开放标准并将LUX代码库作为开源软件发布，使用并为可能跨越机构和领域的实用和可持续的文化遗产知识图做出贡献。如果其他组织也要根据链接的Art发布他们的数据，并通过IIIF的Change Discovery API进行收集，然后，希望集成和重用该知识的组织可以通过遵循耶鲁大学对LUX的相同方法来实现。这将产生有价值的知识网络，而不需要单一的、集中的和最终不可持续的数据库; 参与网络的动机是具有本地交叉集合发现平台。保持这个本地发现平台更新准确的信息，然后增加网络作为一个生态系统的价值，并允许其他组织选择使用哪些系统来丰富自己的记录，而不是被迫使用自称的权限系统。鉴于LUX的经验，这个既接近又光明的未来有望提供前所未有的访问世界博物馆，图书馆和档案馆的藏品。

备注

可在https://lux.collections.yale.edu /。⮭可在https://github.com /项目-lux/。⮭

致谢

所描述的工作部分由Andrew W资助。梅隆基金会资助耶鲁大学。

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