Registry: 将 iDigBio 集合导入 GrSciColl

创建于 2020-02-05  ·  12评论  ·  资料来源: gbif/registry

目标

在实际导入之前需要发生什么

当然,我们可以按不同的顺序进行这些操作。

1. 链接 iDigBio 和 GrSciColl 条目

由于 iDigBio 描述了集合,我们可能应该:

  1. 将 iDigBio 条目与GrSciColl 集合匹配(基于标题、代码等)
  2. 如果在馆藏中找不到匹配的,我们应该尝试在 GrSciColl 中查找相应的 iDigBio 机构是否可用。
  3. 如果我们在 GrSciColl 馆藏和机构中找不到任何匹配项,我认为我们应该同时创建一个机构和一个附属于它的馆藏(类似于我们在 Index Herbariorum 的情况下所讨论的:https://github.com/gbif /registry/issues/167)。 是否有意义?

一旦我们有了匹配列表,我们就可以将标识符添加到 GrSciColl 条目以处理导入(类似于我们在 IH 的情况下所做的)。

谁应该做匹配:iDigBio 或 GBIF?

每个人都可能对如何进行有一个想法,但为了跟踪正在发生的事情,我在这里写下匹配过程的步骤:

  • [x] 从 iDigBio 获取数据(来自这里:http://idigbio.github.io/idb-us-collections/collections.json)
  • [x] 从 GrSciColl 获取数据(很可能使用集合 API
  • [x] 清理数据(例如使用OpenRefine
  • [x] 使用您喜欢的算法将数据与相关字段匹配。
  • [x] 手动检查模糊/可疑匹配。

现在谁来做什么?

2.同意iDigBio和GrSciColl字段的映射

iDigBio 和 GrSciColl 之间的模型看起来非常相似。 以下是我们建议如何映射字段。 如果您有任何意见,您能不能再过一遍,让我们知道?

iDiBio | GrSciColl
-- | --
机构 | 映射到集合实体中的“机构”,如果使用创建机构,则映射到“名称”
收藏 | 科尔的名字
记录集 | 在 coll 中设置为 MachineTag(因为它是供内部使用的)
记录集查询 | 科尔的机器标签
机构代码 | 映射到机构中的“代码”
收藏代码 | 映射到集合中的“代码”
集合 Uuid | 添加为标识符
集合 Lsid | 添加为标识符
收藏网址 | 科尔的主页
收藏目录网址 | Coll 中的目录 URL
说明 | Coll中的描述
描述专家 | 连接到 Coll 中的描述(或新字段?)
编目样本 | Coll中的样本数量
KnownToContainTypes | 丢弃? (现场使用次数少于100次)内部使用有必要吗? 在这种情况下,我们可以将其添加为 machineTag。
分类覆盖 | Coll中的分类覆盖
地理范围 | 科尔的地理覆盖范围
收藏范围 | 丢弃? (在大多数情况下,它似乎包含一个与 catalogueedSpecimens 具有相同值的字符串)
联系方式 | 映射到员工姓名
联系角色 | 映射到员工职位
联系邮箱 | 映射到员工电子邮件
邮寄地址 | 科尔的邮寄地址
邮寄城市 | 科尔的邮寄城市
邮寄状态 | Coll中的邮寄状态
邮寄邮编 | 在科尔邮寄邮政编码
实际地址 | Coll中的物理地址
实体城市 | 科尔的实体城市
物理状态 | Coll中的物理状态
物理邮编 | 科尔的物理邮政编码
唯一名称UUID | 在 inst 中作为标识符添加
署名LogoURL | 新领域?
ProviderManagedID | 添加为标识符
派生自 | 如果供内部使用,则添加为 MachineTag?
同为 | 添加为标识符
标志 | 添加为 MachineTag
门户显示 | 添加为 MachineTag
纬度 | 机构纬度
朗 | 机构经度

3. 决定当 IH 和 iDigBio 有重叠时该怎么做

如前所述,我们正在努力同步 Index Herbariorum 和 GrSciColl (https://github.com/gbif/registry/issues/167)。 iDigBio 和 IH 之间存在部分重叠。

在这些情况下我们应该怎么做?
我建议覆盖 IH 提供的字段信息(IH 值覆盖 iDigBio 或 GrSciColl 值)并仅保留来自 iDigBio 的字段。
如果 iDigBio 记录是最新的,我们将创建一个 GitHub 问题,然后将最新更新发送到 IH。
这样可以吗?

GRSciColl

最有用的评论

@asturcon我们从 Audubon Core 中选择了这个字段,但我们同意您可以丢弃该字段,因为我们没有对它做任何事情。

所有12条评论

关于第 1 部分:

至于谁来执行这项工作,我恭敬地认为,如果 GBIF 能够花时间来做这件事,那将是最好和最有利的。 iDigBio/ACIS IT 仍然缺少 1 名团队成员,尽管我们认为由此产生的产品对每个人都会更好地工作,但我认为我们不能保证我们能够很快承诺。

以下是本期第 1 节的一些其他说明:

  • 列表中的 1-3 是有意义的,包括 3 中的建议解决方案,如果找不到匹配项
  • 对于匹配,可能会从 GBIF 的机构代码匹配到 collections.json 机构代码

  • 根据 collections.json 的现有文档(在 repo 自述文件中),如果找到,则institution_lsid映射到“机构 LSID 的 GRBio LSID 或coolURI”,否则为空白

  • 其他匹配可能需要基于字符串的匹配算法。 对匹配/验证目的可能有用的注释是 collections.json 中的记录集 uuid 将匹配我们 API 提供的记录集 uuid。

第2部分:
iDigBio 的 collections.json 中的个人记录是机构收集记录。 GBIF 正确地将机构和收藏品拆分为单独的实体。 有关预期层次结构,请参见附图。

unnamed

注:自述文件中有字段定义: https ://github.com/iDigBio/idb-us-collections

对个别映射的评论:

“UniqueNameUUID 添加为标识符” - 这似乎是 iDigBio 记录层次结构中的“机构”UUID,但似乎尚未实施。 作为标识符保存在 GBIF 系统中。

记录集查询:这会生成指向 iDigBio 记录集的链接(即 https://www.idigbio.org/portal/recordsets/ea12da76-1b2e-4944-8709-1de3af1c65e2)。 如果您以另一种方式生成到记录集的链接,则可以丢弃此字段。

Recordsets - 提醒:这是我们系统中单个记录的父对象

KnownToContainTypes:这似乎可以丢弃。

Collectionextent:可以复制到 CatalogedSpecimens 中,其中 CatalogedSpecimens 为空白,但不需要保留为单独的字段(丢弃)。

“attributionLogoURL、providerManagedID、derivedFrom” - 请注意,这些是奥杜邦核心术语

关于第 3 部分:

我们对整合 IH 和 iDigBio 数据的建议方法没有意见。 为了帮助确定最近的记录是谁,IH 或 iDigBio,您可以使用 iDigBio 存储库中单个文件的提交日期作为添加/修改日期。

存储库的工作方式是人类创建/更新一个名为 ./collections/{collection_uuid}.json 的 json 块并提交。 然后,软件工作流程运行测试并将该 json 块聚合到完整的 collections.json 中。 一个示例单个 json 文件将是:

https://github.com/iDigBio/idb-us-collections/blob/master/collections/001c5234-048b-11e5-b0ee-002315492bbc

重要说明:实际加载和使用的collections.json文件是从json-indexgh-pages分支(它被推送到两者)而不是 master 分支提供的。 例如:

https://raw.githubusercontent.com/iDigBio/idb-us-collections/json-index/collections.json

或者

http://idigbio.github.io/idb-us-collections/collections.json

我希望所有这些都会有所帮助。 如有其他问题或澄清,请随时@我们。

@roncanepa @nrejack我正在检查映射,看起来AttributionLogoURL是我们注册表中唯一缺少的 iDigBio 字段。 但我检查了collections.json文件并注意到该字段始终为空。 我们还应该将它添加到我们的注册表中吗? 或者我们也可以丢弃它?

@asturcon我们从 Audubon Core 中选择了这个字段,但我们同意您可以丢弃该字段,因为我们没有对它做任何事情。

非常感谢@roncanepa@nrejack的回复!
在这种情况下,我们将从 [ 1. 链接 iDigBio 和 GrSciColl 条目] 开始。 我们将尽可能自动地向您和 Cat 发送一些可能需要人工检查的东西,您可以吗?

对我好,送走! 非常感谢大家!!

@CatChapman ,Morten 一直在努力匹配 iDigBio 和 GrSciColl 条目: https ://github.com/gbif/registry/issues/187
事实证明,首先将所有内容与 GrSCiColl 机构匹配更有意义,因为这些条目我们有更多的详细信息和标识符。 然后,一旦我们获得了机构的匹配项,我们就可以查看这些收藏品并匹配它们。

Morten 描述了他在上面链接的问题上的整个匹配过程和结果,但这里是重点:

  1. 根据 IRN 匹配 iDigBio 条目
  2. 根据其他标识符匹配左侧 iDigBio 条目
  3. 根据标题和代码匹配左侧 iDigBio 条目(注意标题已被处理以方便匹配)
  4. 根据城市和代码匹配左侧 iDigBio 条目
  5. 当没有 iDigBio 机构代码时,仅匹配基于标题的左侧 iDigBio 条目
  6. 匹配基于标题的左侧 iDigBio 条目(尽管代码冲突)
  7. 手动匹配左侧 iDigBio 条目

这留下了 235 个 iDigBio 条目不匹配,我们将在 GrSciColl 中为其创建新条目。
现在我们需要您的帮助来检查匹配! 你能过去https://github.com/gbif/registry/issues/187看看匹配结果吗? (如果更方便,我们也可以为您提供电子表格)。

请注意,我们可能在开始时有一些重复的集合,因为某些集合标题在 GrSciColl 中可能有点模糊,而且我们并不总是有可靠的代码。 不用担心,我们希望稍后再解决它们。

Morten 还记录了我们希望如何在此处进行合并: https ://github.com/gbif/registry/issues/188

@ManonGros哇! 这很棒。 你们摇滚,太棒了。

电子表格会很棒 - 我刚刚给你发了电子邮件,所以请随时将其发送到那里,或在此处链接到它(如果它是 Google 表格等)。

现在将看看#188。

伟大的! 我正在为匹配添加制表符分隔的 CSV 文件:
iDigBio_GrSciColl_matches_march2020.tsv.zip

如果能以机器可读的格式取回您的支票,那就太好了。 我们建议在此文件中添加一个列,为每个匹配项添加一个 true/false 列,以及一个潜在的“更正”列,其中包含您认为为 true 的相应匹配项。

Morten 的 JSON 文件使用来自 CAT 的输入进行了更新:
iDigBio_Morten_matches_AND_Cat_addition.json.zip

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

MortenHofft picture MortenHofft  ·  24评论

MortenHofft picture MortenHofft  ·  5评论

timrobertson100 picture timrobertson100  ·  17评论

timrobertson100 picture timrobertson100  ·  9评论

rukayaj picture rukayaj  ·  9评论