不算进一步的问题：DC的抽象模型

[迷图]

好几天没上网...

我上次提出的问题是：
DC的抽象模型是DC普及最急迫的一件事情吗？它想解决什么问题？已经解决了什么问题？——还是，（把简单问题复杂化？）又增加了什么“新”问题？

我把近几天来各位老师意见集中一下：
K师：
1、抽象模型要做的事情，是...：如何描述世界，通过使机器能够准确、恰当地“理解”，而达到更广泛的、自动的、不会因人、因事和因时而改变的一致性。
2、这个事情之所以困难和痛苦，是因为人本身其实是根本说不清楚他/她的所思所想所见所闻的。语言是主要媒介，然而人与人能够达成交流绝对不是仅仅依靠语言，还依靠其它感官，以及大脑的引申判断。但是对于计算机来说，只能依靠语言。因而需要把所需表达的所有东西，都用一种语言框架进行规范和约束。
3、研究并建立抽象模型并不影响你现在的编码。...
4、抽象模型有它的目的和任务...一般而言抽象模型所建立的描述体系，是属于网络世界“公益性”数字图书馆所应该遵循和具备的。...

远洋老师：
1，DC模型所用的单元和术语与RDF是一致的...，而且是triples的表现方式。
2，元数据不只考虑描述书目和信息资源，而这种模型使我们能[以机器可以处理的形式]描述和联系任何资源。
3，具体数据库和仓储中，不再以'元数据记录(record)为最基本单元，而是以statement为单元，这样在收割数据后还可以做很多加值处理，比如说，可以对某种statement集中处理。...

雨僧师：
...通过建立这个抽象模型， DC才能和RDF从逻辑层面完美地结合起来。抽象模型对DC的应用也是很重要的，DC最重要的应用模式是建立Application profile，抽象模型就是AP的骨架。

Leon师：
何况DCMI这些人（偶们老K就是其中一分子啊），原本就不是实用主义的主儿，编码规则不是不搞，而是搞了多少年，也不见得为大家所满意。他们从来就没拿这个当回事，而是一直拿这个拿那个做推荐，所以，你爱用哪个就哪个（老K是DCMI的人，所以，你看，他就是这么讲的）。而DC真正的应用编码规则，体现在OAI中，体现在各种各样的应用DC的AP中。比如，DCMI现在正儿八经地推的编码推荐方案，就来自于JISC的EPrints项目SWAP（算是直接来自于遵循抽象模型的结构与句法了，从这个实例来看，也算回答了迷图对抽象模型干啥用的回答）。
至于DCMI的抽象模型，完全可以一言以蔽之，它就是RDF。或者说是将RDF逻辑模型在DC中的具体应用，我没有看到抽象模型中与RDF在逻辑上有不同之处的。弄这样一个抽象模型对于DC今后的扩展以及应用寻求理论基础与指导还是很有用处的。比如它现在就基于这个整出DSP来，基于DSP又整出编码规则了（推荐方案）。
补充一句，如果一定要说清楚DC抽象模型与RDF的区别，可以将DC抽象模型看成是RDF在DC领域中的应用模型。DC抽象模型是一个domain specific logic model based on RDF.

归纳起来，DC抽象模型是“domain specific logic model based on RDF”（Leon师）。它的意义在于（也就是“它想解决什么问题”）“使我们能[以机器可以处理的形式]描述和联系任何资源”（远洋师），而这种描述能够被机器“准确、恰当地‘理解’，而达到更广泛的、自动的、不会因人、因事和因时而改变的一致性”（K师）。

是否可以更进一步地说，它的意义在于为了实现机器对于元数据的一致的、准确的理解。

不知上述归纳是否准确？

我的不算进一步的问题是：“机器理解问题”是否是DC普及最迫切的问题？DC抽象模型对这一问题解决得怎样呢？是彻底解决了？还是部分解决了？如果是部分解决，还遗留了什么样的问题未能解决？解决问题的过程中有没有带来什么“新”的其他的问题呢？

[雨僧]

机器理解的问题较为复杂，但起码要能够做到机器能识别，只有机器能识别才可能进行机器推理，达到完整意义上的机器理解。在信息领域，机器理解应该有两部分组成，第一部分是信息组织，将信息组成是机器可识别的信息空间。现在的知识表达研究正是在为实现这个目标努力。第二部分是具有逻辑推理能力的知识发现。这两者是分开的两个层。

[雨僧]

我对DC脱离图书馆界跑到语义网络世界的说法持反对态度。不是DC要进入SW，而是整个图书馆界都要进入SW. 如果图书馆界还抱着老一套孤芳自赏，最终会变成信息孤岛。

[远洋过客]

从MARC开始用的词是‘机器可读 machine-readable‘，其实也能算‘可处理 machine-processible‘。machine-understable 比 machine-processible 要求要高一层，都是语义网这批人强调的吧？不知道应该追溯到什么时候。
雨师、K师、Leon师一起上，这次可以有清楚的解释了。其实我们很被动，DCMI任重道远，看换了什么人当头，什么人chair committees, 出来不同地抛新词，改自己的东西，他们在圆心转，我们在圆周转，很吃力的。例如推行了好一段的qualifier，等人家都qualify了，又改称encoding schemes， 然后把所有的这些都变成 terms -- 这是最难解释的一部分。哈，说来话太长了，只好打住。

[Leon]

是在semantic web的技术框架下机器可处理 ---- that is : “语义可处理”。哈哈。

[kevenlw]

leon发威了，厚厚。早该如此啦！
补充一点，对于“机器可处理”，不说“可理解”至少要说“语义可处理”吧，否则早就是可处理了。

[Leon]

我觉得迷图师各抽一句的总结非常正确，也很精彩（嘻嘻，其中有我的，自吹自擂一把）。
下面试着回答迷图师不算进一步的问题：
“机器理解问题”是否是DC普及最迫切的问题？
---- 首先普及是否是DCMI最迫切的问题？我个人觉得DC就象是一个元语言或实验室产品一样，就象我们2000年买的IBM DL解决方案一样，它不是卖给最终用户的，一定要通过第三方集成商进行集成开发才能最终应用的。DC似乎也是如此。所以DCMI比较迫切地要解决理论上、逻辑上正确的事情，这不但如老K所讲的，它急于要闯入semantic web的世界，同时也是对于第三方集成商这样的角色来讲，有抽象模型这样的理论与框架是非常重要的。对于“机器理解”我觉得可以看作是机器可处理，是在semantic web的技术框架下机器可处理，这个DCMI认为非常重要，是DC要闯入semantic web世界的基石。
DC抽象模型对这一问题解决得怎样呢？是彻底解决了？还是部分解决了？
---- 如果仅就抽象模型本身来讲，它很完整了。DC不复杂，也就这样一些内容。抽象模型就像我前面讲过的，是一个RDF的方言而已。但是基于抽象模型的具体应用它还没有解决，所以才出来DSP，才有基于这些逻辑所做的编码推荐方案。从这个层面来说，只能说部分解决。
如果是部分解决，还遗留了什么样的问题未能解决？解决问题的过程中有没有带来什么“新”的其他的问题呢？
---- 这些问题又回到迷图师最初的出发点。就是真正“用”的问题。所以才会出来基于抽象模型的基础上弄出来一个新加坡框架这样一个应用模型，试图解决真正用的时候所有方方面面的问题。但这样一个求大而全的框架，却带来许多“新”的问题，这个我们可以拭目以待，看看今年的年会上会有什么新的进展。

[雨僧]

这些天关于 DCAM的讨论非常深入，也非常精彩，在讨论中有很多亮点，如将DC和METS 放在一起讨论就非常有意思，这两个东西可谓风马牛不相及，DC的功能是知识表达，目的是知识发现，而METS是元数据封装，目的是数字资源的交换和保存。但如果将这两个东西放在一起比较，的确会有很多有意思的感想。
这个讨论源自于迷图老师的一个问题：“DC的抽象模型是DC普及最急迫的一件事情吗？它想解决什么问题？已经解决了什么问题？——还是，（把简单问题复杂化？）又增加了什么“新”问题？”迷图老师需要一针见血的回答，当时我刺了一针，不见血；远洋老师打了一针，血太多；Keven老师刺了一针，见血了。K师微言大义：“抽象模型要做的事情，是一件非常困难而又痛苦的事情：如何描述世界，通过使机器能够准确、恰当地“理解”，而达到更广泛的、自动的、不会因人、因事和因时而改变的一致性。”准确地阐述了DCAM的精髓。K师的答案解决了迷图师的半个问题，于是迷师又重申了问题的第二个部分，那就是“机器理解问题”是否是DC普及最迫切的问题？DC抽象模型对这一问题解决得怎样呢？”这次，雨僧也学K师的样，试图一针见血地提出自己的陋见。
第一，“机器理解问题”是否是DC普及最迫切的问题？答曰：是的。因为所有元数据，包括DC的核心就是机器理解，它是一种机器语言，用来建立起人机的相互理解和机器与机器之间的相互理解的桥梁。如果元数据不是基于机器理解，我们为什么还要如此麻烦，兜圈子？比如说，你要告诉一个人说“这本书的题目是《元数据概论》”，那就直说，不要拐弯抹角用元数据表达：
245 00 元数据概论 （MARC），
或
元数据概论 。
这样是不是多此一举？所以，元数据主要是一种机器语言，机器理解问题是DC的核心问题。
第二，DC抽象模型对这一问题解决得怎样呢？为了回答这个问题，我们首先要解释一致性原则。众所周知，机器理解的第一步是要一致性地描述信息，需要建立起一个共同遵守的规范来表达信息。这个规范的核心原则就是一致性原则，即要求这个规范能够确保信息在传递过程中不能畸变，它包括两个方面：（1）语义表示的唯一性，不能引起歧义；（2）语法表达应该统一性，即语义表达应该遵循一个确定的语法标准。只有这样，才能确保语义信息的准确性，奠定机器理解的基础。为了实现这个一致性原则，我们需要建立一个模型来规定系统中元数据语义表达的基本方法，机器也可以根据这个模型来理解语义。这就是DC抽象模型的基本作用。
第三，我们来看看，DCAM是怎样来解释语义的。下让我们来看一个例子：
元数据概论
谢天谢地， DC用了助记的标识Label，所以我们知道这是什么，其实这是给机器看的，如果用一串代码来表示这个 label可能会减少很多误解。其实，对于机器而言，它并不知道Title 是什么，Title和2345在语义上没有什么区别，都是一种标识而已。所以如果我们不事先约定，这是关于一个资源的一个属性，上述这个表达式不能承载任何语义。这个事先约定就是 DCAM。
DCAM是基于一阶谓词逻辑（FOL），或者更具体地说是描述逻辑(DL)来建立模型的。这样就和RDF的逻辑一致起来了。在DCAM中，语义是通过一个关系来表达的，这个关系有三部分组成，资源、属性和值，可以用图表示为：
这个关系图是DCAM的精髓。它表达了这样几个约定：
一个资源可以用一个或多个（Property,Value）对来表示；
一个（Property,Value）对被定义为一个陈述（Statement ）
陈述、资源、属性和值之间遵循一对一原则：
（1）一个陈述由一个，并只能由一个属性和一个，并只能是一个值组成，这就是所谓的一对一原则。
（2）一个陈述只能对应一个资源。
这里，属性是用一个标识表征出来的。很多标识集合在一起，形成一个标识集，被称为vocabulary或Scheme。当我们计算机读到这个标识，就知道存在一个资源和一个属性，这个属性有唯一的一个值。目前机器能理解的就这些。
第三，我们来看抽象模型和AP。
我们以花生壳老师提出的问题为例来看看这个模型指导Application Profile的。首先，我们需要做一个陈述，那就是DCAM的作用是确保AP的一致性原则。花生老师的问题是：“比如我在“其他责任者”元素下设一个“责任方式””。那么怎样增加一个责任方式？增加这个元素的时候必须指明，这个元素描述的对象是什么？根据DCAM, 这个属性必须由一个，并只能有一个对象，并且只能有一个值与之对应。所以，在引入这个元素时必须明确这个元素描述的对象是什么，如果这个元素所表征的属性不是我们所描述的这个对象的属性，就不能直接引入。比如，对于作者的出生年月，我们不能像MARC21中的100 1 ‡a Liang, Qichao, ‡d 1873-1929.那样直接引入一个元素叫 Creador.date, 表示为（以HTML为例）


这样做就违反了DCAM 的原则，导致语义混淆：机器会认为1873-1929是资源的一个属性，而不是作者的一个属性。
意犹未尽，下次再讨论吧

[kevenlw]

“它的意义在于为了实现机器对于元数据的一致的、准确的理解”，太对了，我非常同意。
但是“元数据”是描述（一个系统中）多种复杂对象的，这里头还涉及系统所描述各类对象之间的关系模型，形式化这个模型通常并不是元数据的任务，而是（领域）本体的任务。详见拙作《基于本体的元数据应用》（这也是多年前的研究，现在来看可能会有一些模糊的地方）。
机器理解的问题之所以被DCMI排上了很重要的地位，是因为Leon所说的DCMI已经彻底去图书馆化了！OCLC的退出（Stu辞去主席，放手独立运作，经费困难而改变运作模式等）就很能说明问题。实际上DC也只有脱离图书馆界，完全投入Semantic Web等一帮技术派的怀抱，在我看来才是修成正果。
机器理解是一个长期的、宏观的、具有多个方面和丰富内容的问题，抽象模型只是其中的一环，可以说是语义描述中很重要的一环，但现在来看，并非所有和唯一，甚至并非主流（倒是并没有与DC抽象模型处于同一层次上的描述模型，有的都是散兵游勇——具体的应用系统的自定义方式，或者根本没有考虑描述的统一性问题，或者都只是些应用模型）。RDF人人可用，我们在1999年韩国亚洲数字图书馆会议上发表的论文（Leon前往宣读）就宣称上图数字图书馆采用了RDF，但只有诸如抽象模型这种描述模型才能保证认识论层面的统一，才能使RDF从机械的死的数据变成活生生的表示确定语义的信息。
DC抽象模型已经基本成形（可以说基本完成），没有完成的是符合抽象模型的具体描述方案，以及这个放案的标准化、工具化、应用推广。这个具体描述方案就是“新加坡框架”，涉及到大量的具体描述规定和编码细节，没有经过一定规模的详细讨论，应用实践、以及试错，这个方案则可能永远是beta版。
不知上面是否说清楚了，敬请批评指正。