Openlibrary: 将 LCC 转换为 LCC 类名的方法

创建于 2020-04-23  ·  5评论  ·  资料来源: internetarchive/openlibrary

LCC 可以显示为分类树中的 ~path。 这些提供了我们想要向用户显示的有用信息。 为了做到这一点，我们需要能够将 LCC 解码为类。 （这个问题从 #3290 中分离出来）

描述你想解决的问题

希望能够以编程方式获取右侧的数据：

| 来自真实书籍的示例 LCC | 预期结果 |
| -- | -- |
| F1047 .C95 | [
(《美洲史》, ( F )),
（“英裔美国人（包括加拿大）”， （F1001，F1145.2） ），
(《英美》, (F1001, F1145.2) ),
（“加拿大”， （F1001，F1145.2） ），
（“海上省份”， （F1035.8） ），
(《爱德华王子岛》, (F1046, F1049.7) ),
] |
| NC760 .B2813 2004 | [
（“视觉艺术”， （N） ），
（“绘图。设计。插图”， （NC） ），
（“专题”， （NC760，NC825） ），
] |
| QH81 .C3525 1996 | [
（“科学”， （Q） ），
（“自然史 - 生物学”， （QH） ），
（《自然史（一般）》， （QH1，QH278.5） ），
] |
| RF290 .E73 2009 | [
（“医学”， （R） ），
（“耳鼻喉科”， （RF） ），
（“耳科。耳部疾病”， （RF110，RF320） ），
] |
| NB699.N4 B4 1969b | [
（“视觉艺术”， （N） ），
（“雕塑”， （NB） ），
（“历史”， （NB60，NB1115） ），
] |

有关更多示例，请参阅https://github.com/internetarchive/openlibrary/issues/3290 ； 不是那里的表缺少第一个 LCC 类。

提案和约束

  • [ ] 需要给出一个字符串的函数，从开放库中人工输入的 LCC，返回 LCC 类的列表
  • [ ] 每个类还应包括一系列 LCC 或 LCC 前缀（参见上面的示例）

笔记：

  • 在这个阶段，虽然 LCC 提供了第一个数字以外的信息（例如 NB699.A14），但一旦 LCC 的等级达到但不包括第一个刀具编号（即不包括“A14”），则此功能将被视为完整在“NB699.A14”中）。 这是我们可以在未来的问题中进行的扩展。
  • 可选扩展（不需要关闭这个问题；可以在未来的问题中完成）：应该通过 i18n 传递 LCC 类名。
  • 以上示例是使用https://www.loc.gov/catdir/cpso/lcco/生成的。 结果不必与上面的_相同_，但应该非常相似。

附加上下文

  • LCC 细分： https :
  • 速成课程 LCC： https :
  • LCC 的深度细分： https :

利益相关者

@克劳斯 @BrittanyBunk

Librarians @cclauss 2 Identifiers Feature Request
资料来源
picture cdrini

最有用的评论

下一步是一旦@cclauss有了他认为准备好的方法，他或我就可以将它添加到 UI 中，并将其放在 dev.openlibrary.org 上进行测试:) 这看起来正确吗@cclauss ？

picture cdrini 于 2020-04-23
👍2 🚀1

所有5条评论

@cdrini有两个大纲，LCCO 和时间表大纲。 @cclauss使用的是时间表大纲： https : //www.loc.gov/aba/cataloging/classification/ 。 如果@clauss的工作基于时间表，我们应该使用 LCCO 吗？

BrittanyBunk picture BrittanyBunk 于 2020-04-23

虽然不完整，但 LCCO 更容易使用，因为时间表将有子类，其中缩进是向前和向后的，并且知道如何以观众和编码人员的方式对其进行可视化或编程。 LCCO 只向前缩进，所以类总是一个接一个地出现（不是前后两个）。

一个例子是它在时间表中看起来像这样：
------子类 1
子类 2
------子类3

就像如何轻松表示？ 它不能。 但是，LCCO 可以，因为它看起来像这样：
子类 1
----子类2
-------子类3

这很容易代表。 LCCO 的唯一问题是它不是完整的类和子类列表，它是不完整的。 时间表是完整的。

这就是我目前的困境，需要牺牲一些东西：1）完整性，2）表示的准确性。

这取决于您和您选择的@clauss 。 我认为由于完整性和官方性，时间表是最好的选择 - 因为我们总能找到一种方式来表示信息，但我们不能轻易得到我们遗漏的东西。

BrittanyBunk picture BrittanyBunk 于 2020-04-23

我相信@cclauss正在使用来自 https://github.com/thisismattmiller/lcc-pdf-to-json 的转储。 我认为使用这些似乎是最好的，因为我们可以让一些东西工作并对其进行试验以了解它的“感觉”：+1：我们选择的任何东西都不是一成不变的。 如果我们发现需要，我们总是可以调整它以处理更多的复杂性:)

一个运行的复杂系统总是被发现是从一个运行的简单系统演变而来的。 相反的命题似乎也是正确的：从头开始设计的复杂系统永远不会起作用，也不能使其起作用。 您必须重新开始，从一个可以工作的简单系统开始。 - 约翰·加尔

cdrini picture cdrini 于 2020-04-23
👍1

@cdrini同意。 在进行更多操作之前，让我们先了解一下已经在使用的东西 :) 话虽如此，下一步是什么？

BrittanyBunk picture BrittanyBunk 于 2020-04-23

下一步是一旦@cclauss有了他认为准备好的方法，他或我就可以将它添加到 UI 中，并将其放在 dev.openlibrary.org 上进行测试:) 这看起来正确吗@cclauss ？

cdrini picture cdrini 于 2020-04-23
👍2 🚀1
此页面是否有帮助？
0 / 5 - 0 等级

相关问题

BrittanyBunk picture BrittanyBunk  ·  16评论
mekarpeles picture mekarpeles  ·  24评论
seabelis picture seabelis  ·  17评论
mekarpeles picture mekarpeles  ·  16评论
mikemaehr picture mikemaehr  ·  20评论