当然,我们可以按不同的顺序进行这些操作。
由于 iDigBio 描述了集合,我们可能应该:
一旦我们有了匹配列表,我们就可以将标识符添加到 GrSciColl 条目以处理导入(类似于我们在 IH 的情况下所做的)。
每个人都可能对如何进行有一个想法,但为了跟踪正在发生的事情,我在这里写下匹配过程的步骤:
现在谁来做什么?
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
纬度 | 机构纬度
朗 | 机构经度
如前所述,我们正在努力同步 Index Herbariorum 和 GrSciColl (https://github.com/gbif/registry/issues/167)。 iDigBio 和 IH 之间存在部分重叠。
在这些情况下我们应该怎么做?
我建议覆盖 IH 提供的字段信息(IH 值覆盖 iDigBio 或 GrSciColl 值)并仅保留来自 iDigBio 的字段。
如果 iDigBio 记录是最新的,我们将创建一个 GitHub 问题,然后将最新更新发送到 IH。
这样可以吗?
关于第 1 部分:
至于谁来执行这项工作,我恭敬地认为,如果 GBIF 能够花时间来做这件事,那将是最好和最有利的。 iDigBio/ACIS IT 仍然缺少 1 名团队成员,尽管我们认为由此产生的产品对每个人都会更好地工作,但我认为我们不能保证我们能够很快承诺。
以下是本期第 1 节的一些其他说明:
对于匹配,可能会从 GBIF 的机构代码匹配到 collections.json 机构代码
根据 collections.json 的现有文档(在 repo 自述文件中),如果找到,则institution_lsid
映射到“机构 LSID 的 GRBio LSID 或coolURI”,否则为空白
其他匹配可能需要基于字符串的匹配算法。 对匹配/验证目的可能有用的注释是 collections.json 中的记录集 uuid 将匹配我们 API 提供的记录集 uuid。
第2部分:
iDigBio 的 collections.json 中的个人记录是机构收集记录。 GBIF 正确地将机构和收藏品拆分为单独的实体。 有关预期层次结构,请参见附图。
注:自述文件中有字段定义: 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 文件将是:
重要说明:实际加载和使用的collections.json
文件是从json-index
或gh-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 描述了他在上面链接的问题上的整个匹配过程和结果,但这里是重点:
这留下了 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
最有用的评论
@asturcon我们从 Audubon Core 中选择了这个字段,但我们同意您可以丢弃该字段,因为我们没有对它做任何事情。