上周，我概述了在哈佛图书馆创新实验室进行研究的目标。 tl; dr —尝试将判例法数据连接到更广泛的网络。 本周将探讨使用整个伊利诺伊州判例法语料库作为测试平台的一些第一步。
判例法数据以METS格式存储，它包含大量记录数字资产的技术元数据，并包含PREMIS事件。 METS文档的一部分包含带有判例法元数据内容的嵌入式XML文件。
这是一种非常有趣的方法，我不知道它有多普遍，但是它允许技术和内容元数据存在于同一文件中。 就我的目的而言，我现在只关心判例法的内容，而不是技术性元数据。 因此，我编写了一个解析器，提取了我感兴趣的所有数据，并将其编译为JSON新行分隔文件。 这使我可以对元素进行一些重新排列，使事情更容易访问，而不是打开数十万个xml文件，而可以流式传输一个JSON文件。 XML胜过JSON的一个地方是嵌套的标记元素。 在这种情况下，脚注例如：
共同承运人-他们有责任在自己的范围之外运输货物。 承运人接收到要运送到某个特定地点的货物时，根据标记或方向的默示协议，他有义务在该地点运载和交付货物，尽管该地点不在其自己的运输范围之内。 footnotemark> *
表示用于将其连接到另一个元素中的脚注的符号：
*参见疾病。 RR Co.诉Cowles，32岁，120岁。
实际上，用JSON表示起来并不容易，将XML转换为JSON结构的工具只会使诸如之类的嵌入式标签变平。 为了解决这个问题，我对脚注进行了一些预处理，并从中生成了一个混合元素，其中包括脚注及其引用的上下文：
{
注意：[{
pgmap：'389'，
id：“ b389-19”，
值：'*参见疾病。 RR Co.诉Cowles，32岁，120。
}]，
标记：“ *”，
情境：'5。 普通承运人-他们有责任在自己的范围之外运输货物。 当承运人接收到要运送到某个特定地点的货物时，根据该商标或方向的默示协议，他有义务在该placo处进行运送和交付，尽管该运送地点不在其自己的运输范围内。* '，
订购：29
}
比较XML和JSON时，这是一个有趣的用例。
然后，此工具将我想要的数据输出为可以快速使用的格式，花了大约20分钟的时间才将18万个伊利诺伊州xml文件转换为3GB JSON文件。
下一步是解析数据，以这种格式，只需一个简单的脚本即可访问所有记录。 虽然数据库要快得多，但我可以在不到一分钟的时间内遍历+ 180K案例数据。 例如，该脚本记录案件类型需要45秒才能运行：
{
伊利诺伊州最高法院：49694，
伊利诺伊州上诉法院：122678，
“伊利诺伊州法院主张”：10195，
伊利诺伊州巡回法院：199
}
现在我们得到有趣的数据！ 大多数案件来自上诉法院，其次是最高法院。 如果要开始将这些案例意见与外部数据联系起来，我们需要一些联系。 我决定从法官的角度出发，因为已经有了一些数据，而且这是一开始的最低成果。
我们需要有法官姓名的主管部门开始说这个意见是由X法官发表的。 通常在意见书中只会有法官的姓氏，因此我们需要一个索引才能说出这个姓氏“ Koerner”实际上是1885年在伊利诺伊州任职的特定法官。
我们需要从多个来源构建这些索引，然后尝试将它们连接在一起。 试图获得历史（从1800年代初至今）国家最高法院法官的名单并不容易，但是比找到历史上的上诉法官要简单得多。 我使用的是三个来源，伊利诺伊州政府网站，维基百科/ Wikidata列表，Courtlistener，最后是JFC（用于巡回法庭数据）。 所有来源都有其优点和缺点，例如Courtlistener具有非常好的结构化数据，但没有19世纪的超老历史法官。 GOV网站非常完整，但是HTML字母汤。
这项工作存在于自己的资料库中，到目前为止，我只在伊利诺伊州最高法院/政府/维基百科/法院侦探人员之间建立链接（带有图片！），但这足以在下周开始处理伊利诺伊州最高法院的意见。 即使是这种简单的链接也可以开辟一些有趣的发现途径，例如，您可以从Wikidata（通过Wikipedia ID）或Courtlistener中获取数据，并找出每个法官的政治隶属关系，以便按十年查看政党的观点。
下周，我将开始对这些索引的意见中找到的法官姓名进行调和，这是经典的链接数据问题，是事物的字符串。
