元数据设计、实现和最佳实践的创新

论都柏林元数据记录中的信息保理

创造者: 迈克尔Sperberg-McQueen
发行日期: 1996-04-17
最新版本: //www.voudr.com/specifications/dublin-core/info-factoring/
发布历史: //www.voudr.com/specifications/dublin-core/info-factoring/release_history/
描述: 本文档描述了在解释包含重复字段、重复字段组或引用其他元数据记录的元数据记录时应注意的一些问题。使用句子逻辑描述重复字段和组(以及对其他元数据记录的引用)的语义,并建议使用对应逻辑表达式的析取标准形式指定重复组的解释。从这个提议中,导出了分组元素和继承的需求。所涉及的语义原则可能具有更广泛的适用性,但所有的例子都来自所谓的“都柏林核心”元数据元素,由Stuart Weibel、Jean Godby、Eric Miller和Ron Daniel在OCLC/NCSA元数据研讨会报告中描述,该报告可在万维网http://www.oclc.org:5046/conferences/metadata/dublin_core_report.html上找到。

都柏林核心™架构工作组:讨论说明

本文件的状态

该文档首次发布于1996年,作为都柏林核心™讨论说明的一部分,作为DC-Architecture工作组努力将都柏林核心™的XML/RDF表示正规化的一部分。虽然该文档已经有5年的历史了,但是根据RDF和XML的后续工作,其中的许多问题和观察结果值得重新考虑。当前形式的DC Note是未发表的正在进行一些小的编辑准备在www.voudr.com网站上发表。联系Dan Brickley(dc-architecture联席主席),如果您对这个过程有任何疑问。

除了为XHTML验证做了少量编辑外,本文档的其余部分未作任何更改。


c . m . Sperberg-McQueen

1996年4月17日


表的内容

  • 1的问题
  • 2语义模型
    • 2.1句子的逻辑
    • 2.2存在量词
  • 3标记的解决方案
    • 3.1组
    • 3.2隐式定和定
    • 3.3继承
  • 4结论

本文档描述了在解释包含重复字段、重复字段组或引用其他元数据记录的元数据记录时应注意的一些问题。使用句子逻辑描述重复字段和组(以及对其他元数据记录的引用)的语义,并建议使用对应逻辑表达式的析取标准形式指定重复组的解释。从这个提议中,导出了分组元素和继承的需求。所涉及的语义原则可能具有更广泛的适用性,但所有的例子都来自论文中描述的所谓的“都柏林核心”元数据元素OCLC/NCSA元数据研讨会报告,由斯图尔特·韦贝尔、吉恩·戈德比、埃里克·米勒和罗恩·丹尼尔所著,可在万维网上浏览http://www.oclc.org:5046/conferences/metadata/dublin_core_report.html

1的问题

“都柏林核心”为元数据记录定义的数据元素都是可选的,都是可重复的,没有规定的顺序。有些(如作者、标题)与对象的智力内容有关工作),而其他(如形式)则与智力内容的特定实现或实例化有关。有些(例如标识符、条款和条件)可能适用于特定项目所采用的所有表单,或只适用于某些表单而不适用于其他表单。

例如,考虑TEI LiteSGML标记集。作为一个作品,它可以用以下元数据来描述:

标题
TEI Lite:用于交换的文本编码简介
Author
Lou Burnard
Author
m . Sperberg-McQueen < / dd > < / dl >

然而,它有三种不同的url实现,一个用于TEI版本:

形式

TEI Lite
标识符(URL)
http://www-tei.uic.edu/orgs/tei/intros/teiu5.tei

两个用于两个不同的HTML版本:

形式

HTML
标识符(URL)
http://www-tei.uic.edu/orgs/tei/intros/teiu5.html
标识符(URL)
http://www-tei.uic.edu/orgs/tei/intros/teiu5.split.html

这些项目的元数据应该、可以或必须如何表示?

在沃里克会议上,丹·拉利伯特(Dan LaLiberte)认为,在都柏林,一个给定的元数据记录应该只描述一个智能对象的单一实现;这将有助于确保元数据记录是明确的。我在都柏林会议的报告中没有看到这一点,但那份报告确实明确提到了多个版本五月需要多个记录。冗余可以通过将公共信息(例如与工作相关的信息)分解到单独的记录中,并在记录中“继承”它以实现特定的实现来控制。在这个视图中,TEI Lite文档的三个实例化都需要一个单独的元数据记录。

然而,在Warwick会议(1996年4月)上来自都柏林核心用户的报告明确指出,在实践中,非常希望将给定工作的元数据放在单个记录中,使用一些机制,例如重复组来描述多个实现。例如,本文可能用重复组来表示(我使用Eric Miller论文中描述的DTDHTML文档描述的问题,可以在http://www.oclc.org:5046/~emiller/tmp/paper.html)。:

C.  TEI Lite:用于交换的文本编码简介
 Lou Burnard M. Sperberg-McQueen 
TEI Lite
http://www-tei.uic.edu/orgs/tei/intros/teiu5.tei
HTML
http://www-tei.uic.edu/orgs/tei/intros/teiu5.html http://www-tei.uic.edu/orgs/tei/intros/teiu5.split.html

这种方法的唯一问题是,它需要元数据的读者或用户具有很高的智能来解释多次出现的字段的含义。人们可能很容易意识到第一种形式(TEI Lite)只适用于第一个标识符,而第二和第三个标识符是针对第二种形式(HTML)的对象;只有在适当的指示下,软件才会实现它。一个人会意识到,甚至可能没有意识到,这两个 元素同时应用于论文的所有实例化,因为论文有两个作者,而两个

每个元素都与本文的独立和不同的实例有关。在没有帮助的情况下,软件不可能意识到这一关键差异。

控件可以显式地实现表单和标识符信息的关联 Eric Miller的DTD元素:

C.  TEI Lite:用于交换的文本编码简介
 Lou Burnard M. Sperberg-McQueen  TEI Lite  http://www-tei.uic.edu/orgs/tei/intros/teiu5.tei    
HTML
http://www-tei.uic.edu/orgs/tei/intros/teiu5.html http://www-tei.uic.edu/orgs/tei/intros/teiu5.split.html
这是一个改进,但不是一个完整的解决方案(注意,目前两个HTML标识符仍然需要不同于两个_ _元素)。

如果公共信息被分解到其他记录中,我们可能能够避免这些逻辑上的困难,但是我们需要清楚地解释本地记录中的信息和从外部记录导入的继承信息是如何关联的:它们总是相加的吗,即使在两个记录中出现相同的字段?或者本地字段是否“覆盖”该字段的继承值?

2语义模型

如果我们运用形式逻辑的一些原则,我们就能更好地理解这个问题。在我看来,形式化都柏林元数据记录语义的最简单方法是使用句子逻辑。也可以使用存在量词,我简要地描述了这种可能性,足以说服自己更复杂的形式主义不需要更复杂的元数据记录语法。这两种方法都允许我们首先更清楚地表达由重复字段或组产生的歧义类型,然后查看哪些类型的机制可能足以消除歧义。

2.1句子的逻辑

让我们首先考虑一下,为什么像下面这样的简单记录似乎比上面给出的例子问题更少:

<引文> <标题>《清晨的脉搏》<作者>玛雅·安杰洛<出版商>弗吉尼亚大学图书馆电子文本中心由弗吉尼亚大学电子文本中心抄写<日期>1993 <对象>诗<形式>1 ASCII文件<来源>报纸故事和比尔·克林顿总统就职典礼上的文本口语表演<语言>英语

我认为,关键的区别在于所有此记录中的元数据的所有时间都明确地应用,而前一个记录的某些元素只与某些其他元素一起应用。

如果我们将每个元素表示为一个逻辑命题,那么简单记录就具有相应的简单逻辑形式。为了方便起见,我们给每个命题取一个简短的名字:

  • T = "该项目有标题《早晨的脉搏."
  • A =“这篇文章是玛雅·安杰洛写的。”
  • P =“该项目由弗吉尼亚大学图书馆电子文本中心出版。”
  • D =“该项目于1993年出版。”
  • 等。然后,元数据记录可以作为一个整体公式化地表示:(T & A & P & D & OA & Ob & F & S & L),或者“物品有标题。《早晨的脉搏这篇文章的作者是玛雅·安杰洛,还有……”

更复杂的记录具有更复杂的逻辑结构。如果我们这样命名命题:

  • 而且是卢·伯纳德写的
  • 而且它也是由c.m.斯珀伯格-麦昆写的
  • 而且它是
  • 要么在TEI Lite中作为…/teiu5.tei
  • 在HTML中
  • 要么为…/ teiu5.html
  • 为…/ teiu5.split.html。

每个实例都可以用一个简单的元数据记录来描述(正如Dan LaLiberte所指出的那样),它可以转化为一个简单的公式:

  • T & a1 & a2 & f1 & i1
  • T & a1 & a2 & f2 & i2
  • T & a1 & a2 & f2 & i3即。
  • TEI Lite,由LB及CMSMcQ印制,以TEI Lite格式印制,网址为…/ teiu5.tei
  • TEI Lite,由LB及CMSMcQ印制,HTML格式,载于…/ teiu5.html
  • TEI Lite,由LB及CMSMcQ印制,HTML格式,载于…/ teiu5.split.html

我相信这种简单的表达形式,在其中唯一的连接器是而且,对应于无歧义且易于解释的元数据记录的类别。解释复杂元数据记录(具有重复字段或组的元数据记录)的问题可以这样解释:我们如何派生一组简单的元数据记录而且-表达式的逻辑表达式表示一个复杂的元数据记录?

幸运的是,答案很简单。

如果我们把这三个简单的表达式组合成一个公式,我们就得到了元数据记录作为一个整体的释义:

((t & a1 & a2 & f1 & i1) | (t & a1 & a2 & f2 & i2) | (t & a1 & a2 & f2 & i3))
大致可以这样解释:>(如果你手头有一个由此元数据记录描述的项目,那么以下三种情况之一是正确的:)
  • 要么标题是TEI Lite……而且作者是LB而且CMSMcQ而且表单是TEI Lite, URL是…/teiu5.tei
  • 标题是TEI Lite……而且作者是LB而且CMSMcQ而且表单是HTML, URL是…/teiu5.html
  • 标题是TEI Lite……而且作者是LB而且CMSMcQ而且表单是HTML, URL是…/teiu5.split.html

突出的一点(也是整篇论文中唯一有趣或新的主张)是,这个表达式在逻辑上等同于这个例子的原始公式,但与这个表达式的原始公式不同析取范式幸运的是,生成任意逻辑表达式的析取正常形式并不难,特别是当(如这里)唯一允许的操作符是而且而且

然后我们可以这样描述元数据记录的语义:

  • 元数据记录中的每个元素表示一个逻辑谓词。
  • 一个简单的记录被解释为而且-将其子元素组合在一起(结合)。
  • 一个复杂的记录被解释为几个简单记录的-ing合在一起(分离),每个记录用复记录析取范式中的一项表示。

然而,我们确实需要一种方法,使公式( 还有公式中哪些命题是由哪个命题连接起来的而且(&)和由(|)。因此,我们可以看到,调用单个分组元素的建议(如Eric Miller在前面提到的论文中提出的建议,或我自己在非正式的DTD草图中提出的建议)将不足以解决问题。我们需要的不是一种而是两种截然不同的群体。米勒的 元素已经用作而且组,因为简单的引用被解释为而且-将它们的元素结合在一起(正式地说,结合)。但是,如果我们想处理所有共享元数据的情况,它必须能够递归嵌套。我们还需要第二个分组元素,作为集团。有关示例,请参阅下面的组一节。

2.2存在的

量词< / >

一些读者可能会反对使用句子逻辑作为表示元数据记录一般意义的形式主义,因为的意义

 On the pulse of morning
 
一般来说,不只是“标题是?的脉搏
但更像是“(有一个对象,由这个记录描述,和)标题(由这个记录描述的对象_)是On the pulse of morning。”也就是说,在元数据记录的存在中有一个隐含的存在量词,每个元数据元素都有一个隐含的参数,被视为一个逻辑函数。

在这个细节级别上转述记录将更容易更清楚地捕获工作和实现的语义。用一阶谓词演算表示,我们的例子可能是这样的:

(E w)(E lb)(E cmsmcq)(E i1)(E i2)(E i3)(工作(w) &标题(w,"TEI Lite…")&名称(lb,"Lou Burnard") &名称(cmsmcq,"C。m . Sperberg-McQueen”)和作者(w,磅)和作者(w, cmsmcq) &实例(w, i1)和形式(i1, teilite)和url (i1,“…/ teiu5.tei”)&实例(w, i2)和形式(i2、html)和url (i2…/ teiu5.html) &实例(w, i3)和形式(i3、html)和url (i3,“…/ teiu5.html”)& (i1 ! = i2) & (i1 ! = i3))
我们可以这样解释:
  • 有对象wcmsmcqi1i2,i3,这样
  • w是一个工作
  • 的标题wTEI Lite……
  • 的全称卢Burnard
  • 的全称cmsmcqc . m . Sperberg-McQueen
  • (一)》一书的作者w
  • (一)》一书的作者wcmsmcq
  • i1w
  • 的格式i1teilite
  • 的URLi1…/ teiu5.tei
  • i2w
  • 的格式i2teilite
  • 的URLi2…/ teiu5.tei
  • i3w
  • 的格式i3teilite
  • 的URLi3…/ teiu5.tei
  • i1而且i2不是同一个物体吗
  • i1而且i3不是同一个物体吗

顺便注意一下,从元素,我们可以推断第一个实例化与第二个或第三个实例化不相同,但第二个和第三个实例化(都在HTML中)可能是相同的。因此,没有人声称(i2 ! = i3)

如果我们愿意假设不同的实例是唯一可能的原因-组的元数据记录,那么我们可能相信(a)复杂的元数据记录都可以用一个而且-group,如果实例化被指定了标识符(例如i1i2i3)和标识符用于关联应用于每个实例化的元数据元素,以及(b) Eric Miller的 毕竟,元素就足够了,因为所有实例都是隐式的,其他的都不会引起组。

我不愿意接受这种逻辑,首先是因为尽管许多(所有?)元数据记录中逻辑复杂性的例子确实涉及多个实例化,但我肯定没有看到任何论证证明这是逻辑上的必要性。第二,尽管这个论点很诱人,但我仍然不知道如何从元数据记录本身系统地推导出刚刚给出的公式。公式有三个实例化,三个形式()谓词,而元数据记录本身有三个谓词 元素,但只有两个 元素,只有两个元素。

3标记的解决方案

3.1组

我们前面看到,当我们使用句子逻辑来说明元数据记录的含义时,我们既需要分组元素的含义而且和一个意思.的-我们必须发明的群体。现在,我们称它为 .的而且-组,在引用元素。唯一的缺点是这个术语引用似乎暗示它的内容构成了一个完整的引用,这并不总是如此。因此,为了便于说明,让我们发明第二个新的分组元素称为

如果我们扩大埃里克·米勒的DTD 而且 ,我们的示例记录看起来像这样(我增加 而且 元素带有标识符,所以我可以在后面的讨论中引用它们):

C.  TEI Lite:用于交换的文本编码简介
 Lou Burnard M. Sperberg-McQueen   
TEI Lite
http://www-tei.uic.edu/orgs/tei/intros/teiu5.tei
HTML
http://www-tei.uic.edu/orgs/tei/intros/teiu5.html http://www-tei.uic.edu/orgs/tei/intros/teiu5.split.html

3.2隐定和

打鼾< / >

有人可能会说(我自己在这些笔记的初稿中也提过)我们其实并不需要 元素在它出现的任何地方。写下来就足够清楚了

 
HTML
http://www-tei.uic.edu/orgs/tei/intros/teiu5.html http://www-tei.uic.edu/orgs/tei/intros/teiu5.split.html
因为URL是实现的一个特征,而不是作品,而且一般来说,同一个方案中的两个标识符总是指不同的实现。因此,它们也可以被看作是形成一种自动的、隐含的‘或’群。

在这个视图中,有些元素是隐式的而且当它们重复时,-ed放在一起:例如,author。有些元素(如标识符、形式)在本质上是无法存在的而且-ed在一起从而形成implicit团体。有些元素可以是两种情况:多个标题都可以适用,或者它们可能分别适用于作品的一个特定实例(法语标题适用于法语版本,英语标题适用于欧洲法规的英语版本,这可能需要在法律上被视为单个作品,因为所有国家语言版本具有同等的权威)。

总的来说,情况似乎好多了尽管这可能是一个有用的启发式的合理性检查。因为有些元素可以向任何方向发展,我们需要 而且 (或者更确切地说,它们的逻辑对等物:我在这里并没有提出实际的元素,只是指出需要具有连接和析取意义的元素),而且显式地使用这些元素似乎比将如此多的智能硬连接到软件中更简单,更不容易混淆。

还值得指出的是,本节的初始前提是错误的:两个url可能非常容易指向同一个对象,并且很容易想象描述格式的方法,这些方法允许将多个名称应用于同一格式(就像在某些编程语言中可以用多个名称引用同一数据类型一样)。

3.3继承

有三种方法处理来自其他记录的元数据的继承。我们可以坚持继承的元数据永远不包含与本地存在的相同的元素,或者可以指定本地指定的元素覆盖同名的继承元素,或者可以尝试指定一些合并两个记录的方法,以便保留两个记录的所有信息而且ing或-ing对应的元素在一起。在第一种情况下,用“继承”来形容也许有些言过其实;在后者中,我们可能会重新引入重复组的所有问题。

如果我们采用第一种或第二种方法(甚至第三种方法,只要我们提供一个简单的规则,例如“所有继承的数据而且-ed和本地数据一起使用”),我们将能够相当严格地解释对外部元数据的引用:

  • 用引用记录的内容(或者,用没有被本地规范覆盖的被引用记录的那些部分)替换引用(虚拟地)。
  • 如果本地记录和引用的记录都是简单的(在上面给出的意义上),那么结果也保证简单。
  • 如果本地或引用的记录是复杂的那么,对于其他复杂的记录,必须适用同样的解释规则。

通过自由使用对其他记录的引用,我们可以不使用 而且 元素。我们可以通过给出一个转换记录的方法来证明这一点 而且 通过引用链接的记录集。对于源记录中的每个SGML元素,我们执行以下操作:

  • 如果SGML元素是类型 ,然后创建一个新的输出记录(成为“当前输出记录”):首先复制元素本身,然后复制它的每个子元素,遵循相同的规则
  • 如果元素是类型 ,然后
    • 不向当前输出记录复制任何内容
    • 的每一个子元素 ,创建一个新的输出记录,按照相同的规则将子元素复制到新的输出记录
    • 在每个子元素的输出记录的末尾,添加对当前输出记录的引用,关系类型为继承
  • 如果元素是类型 ,将元素本身复制到当前输出记录,并将其重命名为 元素;然后复制它的所有子节点,使用相同的规则
  • 否则,使用当前类型复制元素,然后使用相同的规则复制其所有子元素

或者这么说会更清楚:我们从复制整个开始 元素及其所有子元素生成一个新记录,然后对其进行如下处理:

  • 给新记录一个名称或URL;记住变量中的这个名字N
  • 如果有任何 元素作为根的子元素出现 元素,然后删除整个 元素并将其复制到一个新记录中。在新记录的第一个元素中添加对record的引用N.然后按照此过程中的描述处理新记录。(它有自己的名字,等等)
  • 如果有任何 元素作为根的子元素出现 元素的开始和结束标记 元素,从而将其子元素提升到文档树中的一个级别。

上一节中的样本记录将变成以下记录集:

这里需要做更多的工作,我认为,既要指定当同一元素在本地和引用的对象中出现时如何解释记录,又要指定是什么组成相同元素。

4结论

对于同一作品(智力内容)的多个版本(实现),适当的语法需要明确的语义解释,以避免无可救药的歧义。如果我们在语法中同时提供析取和连词分组的机制(而且组织和-groups),我们可以提供简单的规则,用析取范式解释复杂的记录。

还可以定义使用存在量词的更复杂的语义形式,但不需要比简单语义更复杂的语法。

笔记

句子逻辑中的一个公式在里面析取范式如果它是一个分离(或交替,或-group)的一个或多个项,如果每个项都是结合一个或多个原始句或它们的否定句。不允许嵌套表达式。关于形式逻辑的更全面的讨论,可以参考任何有关形式逻辑的书,但关于析取范式及其代数操作的最好的讨论可能在W.V.奎因的书中找到,逻辑的方法第四版(马萨诸塞州剑桥)。:哈佛大学出版社,1982)。(返回文本)