元数据设计、实施和最佳实践方面的创新

都柏林核心的名字

创造者: 黛安娜Hillmann
发行日期: 1998-10-27
最新版本: //www.voudr.com/specifications/dublin-core/names-in-dc/
发布历史: //www.voudr.com/specifications/dublin-core/names-in-dc/release_history/
描述: 似乎有一种不可抗拒的倾向,将与名称相关的信息纳入都柏林核心元素中,这些名称可能对元数据记录的用户有用。我想建议我们采用在图书馆中运行了几十年的通用命名策略。

似乎有一种不可抗拒的倾向,就是将与元数据记录的用户可能有用的名称相关的信息合并到Dublin Core™元素中。我想建议我们采用在图书馆中运行了几十年的通用命名策略。图书馆只在图书馆资源的元数据记录中存储授权形式的名称——关于名称的任何其他信息驻留在名称本身的单独记录中。这避免了只是我们一直为之奋斗的那种混乱与直流数据模型中,让我们发现自己无休止地争论是否子元素修改“真正的”资源或一个名字(也可能是一个资源本身,但主要还是一个名称在“真正的”资源的上下文)。幸运的是,RDF支持这种结构,因此我们不需要发明一些额外的框来实现我们的目标。

在RDF上下文中,有许多方法可以将名称信息从资源信息中“分解”出来。理想情况下,我们可以链接到VCard或LCNAF等外部资源,从而完全避免在DC数据中维护名称信息的开销。或者,我们可以使用来自其他名称专门化的名称空间的限定符将名称信息嵌入到DC记录中,并配置搜索以识别这些名称空间约定。通过使用这些方法,我们可以利用他人所做的工作,不屈服于重复发明轮子的诱惑,并允许根据我们的需要在各种可用的名称来源中进行选择。它的缺点

链接选项是目前还没有明确的路径来完成任务,但嵌入选项可能会帮助我们实现这一转变。

采用这样的战略以多种方式帮助我们:

  • 使用其他现有标准可以为我们提供无法轻易复制的功能(名称、联系信息的替代形式)
  • RDF允许我们链接到最相关的名称记录,无论是VCard还是LCNAF(或其他东西),对于特定类型的元数据,每种记录都有其优缺点
  • 链接,而不是重新创造,让我们不必在一段时间内维护重复和不稳定的数据
  • 通过始终提供RDF:值字符串,我们还可以适应哑应用程序,而对DC的开销很小
  • 提供链接和嵌入记录中选定的数据可能会让提供者有一种方式从基于文本的搜索过渡到充分利用链接信息。

如果我们采用这样的结构模型,我们可以潜在地将它用于各种可能需要“权威”记录的情况。个人或组织的名称、事件(无论是命名的会议,目前也在LCNAF中处理,或其他类型,如演出)。人们还可以为地理名称(其中覆盖数据可以存储一次并在需要时引用)或主题设想这种方法,在主题中可能需要访问分类编号以及主题字符串和替代术语。

个人/企业难题

在与姓名有关的领域,似乎是一个持续的问题来源,即识别姓名的相关类别,无论是个人、公司或其他类别。名称信息的一些可能来源通常包括该信息,要么作为内部编码(LCNAF)的一部分,要么作为字段数据(可能是VCard)。如果需要此信息,但不能作为所选名称空间的一部分使用,则提供程序可以选择将此信息作为特定于域的名称空间的一部分,或者寻找包含所需分类的外部名称资源。

在rdf做它很好

在为数据模型组(通俗地称为“查尔斯之书”3.4 XML命名空间)撰写的一篇论文中,Charles Wickstead建议“Dublin Core™的用户不应对本文档中未定义的属性类型使用DCQ命名空间。这样的扩展应该使用与定义扩展的人员或组织相关联的名称空间,即使它们是与Dublin Core™元素一起使用的。”在我看来,这是完全正确的,应该有助于我们避免在讨论中经常出现的混乱。

Charles提供了以下这种方法的示例:

(资源)——直流:创造者——> [# node001]

[#node001] - + - rdf:值----> [#node002]

+ - - - XX:创造者。重要性——>“小”

[# node002] - + - VC: FN ---------> " 约翰先生问:公共,先生。”

+ - - - VC: N -----------> " 公众;约翰•昆兰,先生,先生。”

+ - VC:电子邮件- >”[电子邮件受保护]

一个等价的例子,使用LCNAF,看起来像这样:

(资源)——直流:创造者——> [# node001]

[#node001] - + - rdf:值----> [#node002]

+ - - - XX:创造者。重要性——>“小”

(# node002)——+ LCNAF: 100 ---------> " 公共,约翰(约翰·昆兰),1933 -“

+——LCNAF: 400 ---------> " 公共的,约翰•昆兰1933 -“

+- LCNAF:400--------->“不满的选民”

+——LCNAF: 010 ---------> " n 89099111”

注意,通过采用USMARC编码约定(100 =授权表单,个人姓名),表单和姓名类别的信息(“个人”)被保留了。

大概还可以这样做:

(资源)——直流:创造者——> [# node001]

[#node001] - + - rdf:值----> [#node002]

+ - - - XX:创造者。重要性——>“小”

(# node002)——+ LCNAF: 100 ---------> " 公共,约翰(约翰·昆兰),1933 -“

+——LCNAF: URL ---------> " http://www.loc.gov/naf/n 89099111”

[注:毫无疑问,有一个更好的方式直接通过URL链接,但我不知道如何正确地做它-我的重点是,在这个例子中存在一个直接链接到LCNAF记录*和*文本字符串。]

一些问题:

  • 在当前的“简化规则”思维中,这将如何发挥作用?如果我们对名称空间使用显式编码(如果我们希望保留功能的话,这是很好的选择),那么在这个过程中可能会丢失清晰的RDF:value路径。

  • 我们是否关心一些名字会以“姓氏,名”的形式出现,而其他名字则是直接按顺序排列的?显然,这两个“推荐”选项中名称的不同形式并不是特别兼容,尽管一个复杂的应用程序可能能够有效地将它们联系起来。其他名称源可能遵循这样或那样的约定。(注:简单DC的指导方针建议“姓氏,名称”顺序——我们还想继续这样建议吗?)

“授权”的方法

对于主题术语和分类系统也可以采用类似的方法。特别是在分类的情况下,数字或字母数字字符串可能为浏览提供有用的条目,但不一定是选择的搜索词,通过结构化链接访问这两种内容可能会非常有帮助。

《查理书》讨论了主题和主题方案,使用LCSH作为示例方案:

(资源)——直流:创造者——> [# node001]

[# node001]——+ RDF:价值——>“饼干”

+ - DCQ:计划——>“LCSH”

一个人也可能造成同样的事情:

(资源)——直流:创造者——> [# node001]

[#node001] - + - rdf:值----> [#node002]

+ - DCQ:计划——>“LCSH”

(# node002)——+ LCSH: 150 ---------> " 饼干”

+——LCSH: URL --------> " http://www.loc.gov/lcsh/sh 82556900”

这种特殊的结构可以使链接到DDC的更好方式成为可能,因为分类号和标题字符串可能是同等权重的:

(资源)——直流:创造者——> [# node001]

[#node001] - + - rdf:值----> [#node002]

+ - DCQ:计划——>“监护”

(# node002)——+监护系统:153 ---------> " 306.36”

+—DDC:153j---------->“劳动制度”

+ - DDC:URL ---------->“>”http://www.loc.gov/ddc/2348766“

[注意:查尔斯的书在第3.3节“堕落到不合格的都柏林核心”第33节中建议,这是第一个例子将取消到不合格的版本:

(资源)——>直流:主题——>“LCSH饼干”

我强烈反对这种解释。在我看来,它应该被降级为:

(资源)——>直流:主题——>“饼干”

就像类型A限定符不作为文本字符串的一部分用于“简化”浏览,也不应该在类似的情况下使用类型B限定符。

地理名称的“授权”方法

使用相同的链接机制可能会为希望通过Dublin Core™访问GIS数据的用户提供一些功能。由于覆盖率信息目前是合格的DC真正头疼的问题之一,因此考虑如何连接到外部GIS系统来承担DC名称空间的一些负担可能会有所帮助。

一些可能的地理名称系统是盖蒂地理名称辞典和美国地质调查局地理名称信息系统(美国名称)。这两者都提供纬度和经度、变体名称和类别(似乎还没有标准化)。

来自Getty TGN的一个例子:

[资源] ----- DC:覆盖范围-----> [#node001]

[#node001] - + - rdf:值----> [#node002]

+ - - - XX:覆盖>“空间”

[#node002] - + - TGN:地方--------->“塔林”

+——TGN:Lat------------>“59 26 N”

+——TGN:Long---------> "024 43 E"

+, TGN:讲师——>“居住的地方”

+, TGN:讲师——>“城”

+, TGN:讲师——>“首都”

+ - URL - > http://www.ahip.getty.edu/tgn_browser/file=7006629

和美国地质调查局/ gni:

[资源] ----- DC:覆盖范围-----> [#node001]

[#node001] - + - rdf:值----> [#node002]

+ - - - XX:覆盖>“空间”

[# node002]——+ gni:地方 ---------> " 特伦顿”

+ - - - gni:纬度 ------------> " 401301 n”

+——gni:长 ---------> " 0744436 w”

+ - GNIS:国家--------->“新泽西州”

+ - gni: FeatureType——>“密集的地方”

+ - gni: NameVar——>“特伦特镇”

+ - URL - > http://mapping.usgs.gov: 8888 / gni / owa / id = 884540