Web时代的“元数据方法”(四)
Web上的所有东西，可以看成文本（或数据流），也可以看成是一个个独立的的“资源（resource)”，或者看成这两者的混合（本来就是）。
标 识符是“资源”是否具有独立性的基础，是核心，决定了“资源”的归属、身份、获得途径，等等。标识符体系包括了解析体系。在这个体系里，国家不分大小，一 律平等。国家 内部可以有不同的制度，无论多复杂，都可以交给ORE来负责（听说最近牛排正在研究这个，赞一个！）。目前的技术架构，URI已成主宰，各类Handle 方式基 本上以URI为依托，虽说无奈，倒也无伤大雅，好在DOI等Handle系统也是独立的，离了URI，只要有另外的体系能够取代URI，也能存活。记得 DC的创始人Stu Weibel曾有一阵专门研究取代URI的体系，现在也不知下文了。这些理论问题就不多言了。
因此，有没有URI 是“是不是资源”的 充分必要条件。
至此我们接受了这样一种世界观：网络上的东西，除了有URI的“资源”，就是没有URI的文本字串（literal或string），无 它。（在此我们不讨论“网络上的资源是现实中事物的指代”这样一个哲学跨越，以及由此带来的认识论问题。）
- 任何一个描述，都要明确，描述的对象是什么。无论是什么，都应该是一个网络存在，都有URI。（此乃描述的“资源模型”）
- 任何一个描述，都要明确，描述的是什么。即如果描述颜色，就说“颜色”或“color”，描述作者，就说“作者”、“创建者”或“creator”…
- 任何一个描述，其属性取值可以是互联网上的任何东西，自然就包括有URI的资源和没有URI的文本字串。是“资源”当然也可以像上述属性词一样进行规 范，包括取值体系规范（例如年代的表示规范）和值域规范（从值的列表中选取，例如国家列表、各类复分表，以及大量的KOS词表等）。当然，文本字串是最常见的“值”。（这里涉及 “词表模型”）
上述三个成份，构成描述的基本单元：一个RDF表达，也叫陈述（statement）。
- 一条资源描述可以由多个陈述（statement)组成，即多个属性和属性值对描述一个URI所标识的资源；
- 多条相关的资源描述构成一个描述集（Description Set）。
可以看到，一个陈述可以是资源和资源之间关系的表达式（通过也是资源的属性词表达主体资源和客体资源的关系），每一个作为资源的成份又都可以被其它陈述所描述，具有这种关联关系的描述通常组合成描述集，构成“元数据记录”。Web其实就是各种资源纠结在一起的网状结构，Web这时就从众多服务器构成的网络而转变为无数“资源”连接在一起的网状结构（意义非凡啊！）。联结的末梢常常就是那些字串——字串是无法被描述的，其语义需 要人来解读。
(updated:)与传统的资源描述模型最大的不同，在于明确强调了以下两点：
- 描述的原子性。即每一个陈述必须是由“资源-属性-值(可以是另一个资源)”构成。例如作者是图书的属性，而作者单位是作者的属性，这两者应该用两个RDF语句来陈述。
- 描述的专指性。即属性一定是所描述资源的属性，而不是其任何相关资源的属性。如“作者单位”的属性不能用来描述“图书”资源。
上面所说的，就是DCAM: DC抽象模型的大概。
推荐阅读：宋文等“CDOI规范及其在国家图书馆的应用”《现代图书情报技术》2008.10.1-5，虽然好像国图还没有用，但是这个方案不错。
Popularity: 49% [?]
Tags: DCAM, 元数据抽象模型, 元数据描述, 知识组织, 语义技术Related posts
Web时代的“元数据方法”(二)
感谢雨师对上文的反馈：“高屋建瓴”。我可能总是把屋建得太高，让我慢慢落下来吧…
同样的世界，以不同的方法和角度去看，会呈现出完全不同的样子，不仅如此，甚至会看到完全不同的东西。由于计算机处理能力的提高和认识与技术的进步，人们越来越倾向于按照事物的本来面目去描述事物，只要能认识到这种“面目”。其中，面向对象(”搞对象“？）的方法被认为跟接近大千世界的本原（就不说“本体”了哈），也是当前计算机认识世界的主流方法，以前我们把万物仅仅看成是数字或文字，而世间万物都是相互独立而又普遍联系的，我们为什么不能在Web上建立真实世界的一种”面向对象”的虚拟镜像涅？
都柏林核心元数据抽象模型（DCAM ）就提供了这样一种“面向对象”看待世界的方法。它是为了向计算机描述我们这个世界而提出的，你可以设想向一群外星人解释我们这个世界，你应该如何向他们描述才能让他们理解呢？亚里士多德把世界看成是几种元素，我们到达不了那个境界（深度），只能说：世界都是由“东西”组成的，每个东西都是独立的，东西和东西之间又都是有联系的，认识东西就是认识它的特点（属性），不同的人可能看到不同的特点，把特点说出来就是描述……。然后，外星人就懂了，说：“噢，我们那里也是这样的…”
DCAM是完全基于语义Web的基础RDF模型的，因此可以认为它是语义Web描述这个世界的一种基本方式。
当然，向外星人解释这个世界不应该要求所有人都能干，这样的话”数字图书馆员“也就没有“核心竞争力”了。所以现在DCMI这一帮人（以及爱好者，如本人和平台江 等），以及SW（SemanticWeb）的一大帮人都在日夜奋战，希望能够提供许多方便的工具、平台或环境，使得同志们在按照惯常的方式工作的同时，规范的、外星人能够看懂的语义 描述能够“自动”建立起来。让大量的人文烟鬼继续并且更好地坑蒙拐骗、欺压百姓。
上述的目标距离实现尚有很长的路要走。现在的重点工作，是基于DCAM，建立一整套面向应用的规范体系和架构。
新加坡框架 就是这样提出来的。其目的是为“元数据方案”（DCAP: Dublin Core Application Profile）提供一套理论：一套完整的描述应该包括哪些内容？分别的作用是什么？哪些是定理（例如”用户永远正确“），哪些可以通融…等等。其中最重要的，是有关DSP（Discription Set Profile:描述集方案）的定义和规定。
都柏林核心元数据(DCM)现在是什么东西呢？它以15个基本元素著名，但它早已不是那个东西了，它已经成为一套体系，包括一个模型 （DCAM：Dublin Core Abstract Model，包括）和一套词表（Vocabulary：其中除了元素，又包括子元素——针对属性词来说的；修饰词——针对取值来说的，修饰词还有编码体系修饰词和“取值”修饰词），以及诸多 正在完善中的规定（新加坡框架及其编码）。
欲知后事，且听下文。
Popularity: 53% [?]
Tags: DCAM, 元数据, 新加坡框架, 语义技术Related posts
Web时代的“元数据方法”(一)
描述一类资源，首先需要明确为什么要描述，也就是明确需求。需求决定了那些实体需要析出，分别有哪些属性应该被描述，以及实体之间、属性之间的关系是什么。
我们现在的”元数据方案”一般就管到这一步，成果是ER图和属性表，基本方法论就是实体-关系分析。基本功能交给关系数据库来实现。
上面几乎和数据库系统的开发如出一辙。所不同的，我们的目的是建立标准化的、供行业（领域）或更大范围使用的”元数据规范“。即我们希望提供的属性表以及编码方案应该是可被大家共同遵守的、可共享和重用的。
但是上面这种思考方法（“思考范式”），到了Web时代，虽然引入和“神秘的配方”——元数据，也还是不够用的。
1、 Web是一个开放的环境，其功能需求考虑的不光是”自己”的需求，这里的”自己”是指的是本地系统的”相关用户”，借用术语来说：”传统的需求定义只考虑了企业级应用范围内的各类代理（agent）的需求”，Web用户访问特定应用的目的和方式常常会超出系统设定的情境，并且Web用户是不接受”培训” 的，他们会有更多的”替代”选择，甚至你系统的look and feel不好，他们都会走人。因此一个优秀的Web应用，必须能够具有更好的可用性和更强的功能性，必须把更多的可能性置于你的”控制”之下，即便不直接开放，也要提供开放的可能性。
2、这就是为什么很多数字图书馆的Web应用，不能仅仅以”实现需求”为目标，而要深层挖掘”为什么”的原因。特别是现在Web2.0概念引入，需求分析、设计、实现诸多流程合一，用户常常不仅要提出需求，还要介入设计，并且关心如何实现。大多数软件公司希望你明确定义需求，而采用什么平台技术架构来实现，不需要你来关心。这样开发出来的数字图书馆或2.0应用，虽然能够实现功能，但是几乎肯定不是一个“好的应用”。你可以责怪用户没有充分明确需求，很多隐含的需求没有提出来，但系统不好就是不好，谁都有责任。
3、当然这个困境应该是由于软件工程还没有发展出相应的分析方法和设计工具，以及经验流程性的东西能够支撑Web级的数字图书馆或Web2.0应用的开发而造成，也并非任何一方的责任。
4、 Web级的应用对于资源描述的需求可能就常常包含在那些未被提出的”隐含的需求”中，例如Web范围内的语义互操作、数据共享、代码(方案)可重用、永久保存的需要，以及相关技术标准和协议的支持和遵循等等。这些规范的研讨和制定，实际上也是为了将来省事：你只要遵循了我的这些标准规范，许多可能的”隐含需求”就自然而然能够的到满足，即便你的行为是无意识的，好处是奉送的。
因此目前的”元数据方法“（全称应该是”Web资源描述的元数据方法”），已经超越了仅仅提出一套（不管是普适的，例如DC，还是领域的，例如IEEE- LOM或者DCAP）元素集的阶段，因为光是属性元素集是远远不够的。目前DCMI所做的，希望在思想方法上进行一定的统一，即：基于”我们如何看待这个世界”建立描述世间万物的一般方法，而建立起一个一致的思考模型（”抽象模型”）；并且基于这个抽象模型，提出一整套的描述体系和元数据方案。语义Web技术可以提供这种方法的技术基础。可以说，我们正在向语义描述的”统一场论”进发。
Popularity: 54% [?]
Tags: DCAM, 元数据, 抽象模型, 数图统一场, 语义技术Related posts
近期关于元数据编码的讨论
警告：慎入！这个帖子会很长，主要涉及元数据编码细节的讨论。
承蒙谢涛和江汇泉两位技术大拿与远洋老师在我的博客上发起了热烈的讨论，所涉及的问题实在是在实践中非常重要，却很难武断地进行“推荐”。这里只能就我对DCMI编码的理解，夹叙加议，谈一点看法，希望国内这个领域的有识之士，例如参加过张晓林大组长标准规范课题的（像Leon、郑锡惠、徐周亚），以及CALIS国科图清华北大中科院等做过实践的，参与讨论。
本想在http://www.dublincore.cn/上讨论，但那是一个wiki，格式上不方便，这里讨论的结果将放到那边汇总。
需要说明的是，目前的“DC元数据XML编码指南”正在修订更新，将推出一个完全符合DCAM的规范，进行中情况请参见Expressing Dublin Core metadata using XML，以及DCMI Architecture Wiki 中的讨论(那里有大量的例子)。
摘要：
1、目前DCMI推荐的所有编码方案，均是尽可能遵循DCMI元数据抽象模型(DCAM)，DCAM是独立于编码、却为编码提供统一方案的数据模型。
2、目前争议的焦点实际上在于对这个模型没有透彻理解，以及对于基于XML、进而RDF的数据模型没有透彻理解。
3、XML的数据封装不能脱离XML模式（XML Schema或XMLS）或者DTD，也就是说所有包含XML实例序列化的数据原则上都需要XMLS或DTD才能让计算机读懂。而目前我们XML举例时通常直白地直接列出元素，似乎无需XMLS进行元素及结构的解析。这是不严格的。
4、因此DC元数据的XML表达（包括RDF表达）从数据上看起来是平面的，但是其结构和语义是用XMLS来约束的（如果是RDF，扩展的元素用RDF Schema进行定义），因此不能认为它是平面的。
5、这也就是说，DC元数据的形式化描述中，dc:alternative看起来与dc:title处于一样的地位，但实际上是完全不一样的，在XML文件的根元素指向格式解析模式中（通常是一个形式化的元数据应用纲要），可以明确它们的上下位关系，通常在如下的文件中规定格式：
<xsi:schemaLocation=”http://example.org/mydiglibapp/ http://example.org/mydiglibapp/schema.xsd”>6、应用系统在实现功能时，不应脱离XMLS去读XML文件。
7、拼音的编码方法：按照以前的做法（目前并不推荐），可采用修饰词的方式在XML中编码，如<title.transcription>bo po mo fo</title.transcription>。Akira在文章中给出了抽象模型的表示：
Statement (
PropertyURI(dc:title)
ValueString(汉字表示)
)
Statement(
PropertyURI(dc:title)
ValueString(Bo Po Mo Fo)
)
……根据目前DCMI同行的做法，我猜想应该采用重复元素（字段），对属性值扩展Scheme词表的形式来说明，如扩展书写方式scheme为包含pinyin, hana, hanja, kanji…等编码的词表：<dc:title Scheme=”yournamespece:pinyin”>Bo Po Mo Fo</dc:title>（如果词表有名称并需要标注的话，则编码稍微复杂些）。在正在酝酿的新推荐方案中，规定了封装的容器，弄得很复杂。
8、RDF编码的意义（完成中…）。
以上是我的理解和解释的大概。
以下是谢涛和江汇泉两位老师在我上一个帖子后的留言，干脆移到这里，并加上我的粗斜体议论（不断增加中）。（由于原文中许多代码含有<和>，拷贝粘贴时被浏览器吃掉了，我这里恢复的不一定正确，如有误请更正）
江老师留言1：
Read the rest of this entry »
Popularity: 86% [?]
Tags: DC Metadata, DCAM, 专业评论, 元数据, 元数据, 编码, 语义技术