图 1：电子表格中的数据输入。 ©研究项目›特伦托会议后的普世教会政府‹ 2018。
图 1：电子表格中的数据输入。 ©研究项目›特伦托会议后的普世教会政府‹ 2018。
然而，研究兴趣和科学问题主要不是与这些档案或它们的组织本身有关，而是与其中记录的历史过程有关。 Van Ruymbeke 等人提出“历史”或“现象”维度与“信息”维度之间的区分，也就是说，可观察到的现象与关于它们的论述之间的区分。[8]同样，在这个第一个层面上，我们首先关注历史现象：请愿者（在图中以橙色突出显示），提出请愿书的教区或受问题影响的教区（黄色），特伦托会议要求对此事进行解释的决定（绿色），以及参与审议的枢机主教（深蓝色），最后是日期（浅蓝色）和他们决定的摘要（红色）。
因此，记录背后甚至是档案条目背后的“案件”的历史（和真正的法律）背景是历史现象建模的核心实体，然后将会议日期分配给它。咨询会议的会议记录是根据相应会议上处理的不同案件编写的，这一事实证实了这一直觉，而其他项目和研究也进一步证实了这一直觉，这些项目和研究模拟了可比的司法或类似法院的程序，并将“案件”置于中心。[9]现在，案件中添加了更多信息，部分作为案件的属性，部分作为与之相关的其他实体：案件由某人向教会提出请愿书并请求解释特利腾会议的决议而开启。这体现在将人建模为独立实体，然后使用合格的 n:m 关系（“请愿者”）将他们与案件联系起来。因此，申请人与自然人的角色区别于 个人与关系属性的单独标记。某个人可能在几个案件中充当申请人，而在其他案件中又扮演不同的角色，反之，一个案件可能有多个申请人。[10]同样，有关公会的决议也以“事项”的形式记录，并附有会议、法令或教规的通常指示。这同样适用于参与诉讼的其他人员、作出的决定、审议有时涉及的其他案件以及单独的听证日期。图 2提供了这些关系的初步概念。
图2：历史现象层次的数据模型。 ©研究项目›特伦托会议后的普世教会政府‹ 2018。
图2：历史现象层次的数据模型。 ©研究项目›特伦托会议后的普世教会政府‹ 2018。
数据模型，即实体类型、它们的属性和关系（暂时还包括关系的属性），首先基于多年来经过区分和验证的数据收集直观地制定，然后在无模式图数据库 Neo4j 中实现。稍后将评估向 CIDOC CRM 或 RDF 等更标准化模型的映射。[11]尽管这种映射在任何情况下都是作为导出接口而设计的，但目前也可以想象，项目中的数据集将仅在当前构建的（可能进一步开发的）图形数据库框架内进行研究，并且例如，在数据导出中将省去 SPARQL 接口。
2.2.书面资料：Positiones
如上所述，历史案例都记录在报告（即所谓的“Positiones”）中，可以在档案中找到。在此背景下，例如，可以记录负责记录的秘书以及有关印章和羊皮纸属性的信息。首先，在这个层面上，协议报告（指代第一层现象的理想实体）与书面文件（一种象征性表达）相联系，而这又与物质载体相联系，而物质载体又被归类到特定的档案环境中（媒体单元、书架、收藏、建筑物、地址）。这个级别也为反映数据库中提到的一些不确定性提供了重要的机会。除了一般的案件与报告关系外，还从姓名或位置上的符号、字符串中读取历史事件层面的人物及其关系的具体条目。因此理想情况下，我们希望明确记录两件事：首先，在文档中的字符串中，有一个我们已经识别为归属的字符串；其次，我们认为这个命名指的是一个特定的历史人物。严格来说，历史人物只是通过文献中的名字与案件联系起来。
当前的数据收集中，因此无法为我们提供在此级别进行建模的足够指导。然而，上面使用的理想实体、符号表达和物质载体等概念表明，我们应该以 CIDOC CRM 标准（及其扩展 FRBRoo 和 CRMtex）[12]为基础。因此，在第一次尝试中，我们使用来自该上下文的此级别的实体和关系类型的名称，如图3所示：[13]该职位本质上是一个 CIDOC CRM »E31_Document«，用于记录案例（»P70_documents«）。具体来说，文档（»P165_incorporates«）包含一个符号表达，更准确地说：演员的命名（»E82_Actor_Appellation«，»E41_Appellation« 的子类或»E90_Symbolic_Object«）。这种归属在源中以字形链（»TX7_Written_Text_Fragment«）的形式物理呈现，并且它在历史级别 1 中识别（»P131_identifies«）参与者（»E39_Actor«，可以是单个»E21_Person«或整个»E74_Group«）。
图 3：档案源级别的数据模型。 ©研究项目›特伦托会 英国电报数据 议后的普世教会政府‹ 2018。
图 3：档案源级别的数据模型。 ©研究项目›特伦托会议后的普世教会政府‹ 2018。
在目前的发展阶段，这些信息将如何与历史过程和实体第一层的各个角色的各个方面相结合仍不清楚。一方面，它不仅仅是指名与案件有关的人，而且还指名该人在案件中扮演的特定角色，另一方面，该人通常不以个人姓名来命名，而是以社会角色来命名（例如“阿西西大教堂教规”），因此命名（»E82_Actor_Appellation«）最初并不识别任何特定的人。第一种方法基于马丁·多尔 (Martin Doerr) 的提议[14]，尝试使用属性的属性来映射这一点 (»P14.1_in_the_role_of« 作为 »P14_performed« 的属性)。然而，这会迫使我们将活动建模到数据模型中，通过该模型可以将上述属性与人联系起来。此外，这种构造是否可以轻松实现并在之后导出到 RDF 也值得怀疑。另一种可能性是将请愿者、顾问枢机主教等角色划分为独立的实体。通过这种方式，它们就可以成为进一步关系的端点，例如提及姓名。但这种策略并非没有问题：与上面提出的原始直觉以及[15]中的建议相反 ，我们会以一种不优雅的方式增加实体，这最终使查询变得更加复杂；提到名字（或提到社会角色，例如“阿西西大教堂章节”）本身与“请愿者”的角色无关；最后，以后与 CIDOC CRM 的集成可能会变得更加困难。简而言之，目前对此问题的审议尚未结束。