读书:Metadata Management for Information Control and Business Success

书名:Metadata Management for Information Control and Business Success
作者:Guy V. Tozer
出版社:Artech House, Inc.
出版年:1999
ISBN:0-89006-280-3

目录:

Part I  The Concept of Metadata

1.Background
2.The Challenges of Information Management
3.Establishing a Common Basic Metamodel

Part II Metadata in the Business

4.Managing the Metadata
5.The Role of Metadata in Application Development and Support
6.Metadata in Data Warehousing and Business Intelligence
7.The Role of Metadata on the Internet

Part III The Basics of Metamodeling

8.Design and Management of MetaData-bases
9.Interaction Between the Metamodels

Appendix A: Data Model Compatibility
Appendix B: The Data Management Metamodel
Appendix C: The Application Management Metamodel
Appendix D: The Activity Management Metamodel
Appendix E: The Infrastructure Management Metamodel

对于商务领域如何利用元数据进行信息组织,一直充满好奇。这是一个目的性非常明确、尤其强调实用的领域,科学性经常让位于实用性,考察这个领域的元数据应用,应该能给我们以“知识组织”立足的理性主义学派带来一些实用主义新风。

然而可能由于年代的关系(出版于1999年,metadata刚刚从数据库的襁褓中脱胎,浑身上下还插着各种芯片,捆绑着不少线缆,图情界和计算机界还无法和谐对话),这本书似乎还不足以让我们实现上述目的。作为从计算机技术角度审视元数据应用的著作,本书仅仅把元数据定位于系统管理的一种工具,而没有作为资源描述的基本方法(就是说更多的是关注元数据的“管理型功能”,而不是对于语义描述的“描述型功能”。同时,本书在技术细节“怎样做”方面论述也不多,大多是“是什么”。

值得一提的是,其对于元数据方案设计的思路却是我们这几年同样经历的,只不过该书的方法论局限于商业领域,可算是一个元数据的“领域应用”吧。例如,它更关注“元模型metamodel”的架构,实际上提供了一个商务系统运作的信息模型(角色、流程、相关实体、关系、作用等等)。

Popularity: 62% [?]

Tags: Metadata, 读书, 读书

Related posts

贴html的工具

谢涛老师花了一点时间编了一个html encoder小模块,在

http://dp2003.com/dp2portal/htmlencoder.aspx

使用方法:把html/xml代码paste到上方的textbox中,然后点“encode (nbsp)”按钮,下方textbox中就会出现encode以后的字符串,把它copy/paste到博克中,就没有问题了。

(encode按钮和encode (nbsp)按钮的功能区别,是在于前者没有encode空格,这样post到博克的文字就没有了原来缩进的效果了;而后者encode了空格,保持了缩进的效果)

Wordpress自带一个工具,当然只供能登录进来法帖子用的,留言无法用。下面的“代码示例2”就是这样贴出来滴(终于把远洋老师的第二个例子贴出来了,哈哈)。

Popularity: 57% [?]

Tags: html encoding, Metadata, wordpress, 元数据

Related posts

代码示例2:DCq编码实例

<?xml version=”1.0″?>

<!DOCTYPE rdf:RDF [

<!ENTITY rdfns 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>

<!ENTITY rdfsns 'http://www.w3.org/2000/01/rdf-schema#'>

<!ENTITY dcns 'http://purl.org/dc/elements/1.1/'>

<!ENTITY dctermsns 'http://purl.org/dc/terms/'>

<!ENTITY dctypens 'http://purl.org/dc/dcmitype/'>

]>

Read the rest of this entry »

Popularity: 68% [?]

Tags: DC Metadata, encoding, Metadata, RDF, 元数据

Related posts

近期关于元数据的一些讨论

精灵就远洋对于众多元数据相关标准的分类给了一个图示,如下:

我没能完全理解,但就我的理解发表了一些理解:

1、元数据元素集是描述资源各个方面的属性词表;
2、元数据取值如果规定只能从某些词表中选取,这些词表就属于受控的规范词表;这属于元素取值的domain和range;
3、元数据应用纲要是为了领域应用而制订的元数据方案的一种表达形式,目前正在成为规范的,叫做“DC元数据应用纲要”,核心是符合DC抽象模型的元数据形式化表述(也就是一种机读形式),通常可以以RDF形式表达;
4、应用模型(规定应用领域的各类实体及其相互关系)、著录规则等文档,也可以成为元数据应用纲要的组成部分;
5、元数据注册系统可以作为元数据元素的命名域管理体系而存在,但命名域并非一定需要注册系统进行管理;
6、元数据元素词表,包括规定元数据取值的规范词表,都可以看成是一种人工语言,每个术语都应该被赋予唯一的URI,都可以通过注册系统进行管理;
7、元数据形式化的表达必须采用基于XML的RDF或OWL等的Schema,著录工作单当然可以通过完整表达元数据方案各种关系和约束的schema来自动生成,并进行校验。当然这需要一定的环境和软件工具来实现;
……
至于这几种元数据标准的分类,感觉在概念上有交叉,是从应用角度来分类,并不具有严格的意义。

前两天针对图林茶的困惑,也发表了一些看法(问题的陈述只是大致):

问题1:目前针对具体应用领域制订的元数据方案,其描述对象究竟为何?

1a、任何具体的元数据方案所描述的实体,都可能是一个复合的实体,并在整个生命周期中具有不同的表现。完善的元数据方案应该首先有一个应用模型(如FRBR)进行清晰的表达,这样才有可能使得具体的描述符合1:1原则。
1b、应用系统在具体开发实现的时候,可能无法保证模型关系的完整体现,这已经在元数据方案所能考虑的范围之外了。好的实现,应该能够以较少的代价(例如一条记录),反应更多的内容(例如两种实体之间的关系)。

问题2:元数据方案不都是“描述”资源的吗?

2、元数据就是关于数据相关属性的描述,虽然有描述性元数据、结构性元数据、管理性元数据等说法,这里的“描述”取了狭义的“内容描述”的含义。纯粹玩弄词藻,就不多言了。然而属性的取舍是元数据方案的关键,不“困惑”这个,制定元数据方案就基本上没有可以困惑的了。

问题3:元数据的“元素”与XML的“元素”,究竟是不是一回事?

3、不要把元数据元素和XML中的元素混为一谈,虽然前者可以用为后者,当然,也可应用为后者的“属性”,这是编码的问题。元素与修饰词在元数据方案中都 是“术语”,都应该慎重,作为一种“元数据应用纲要”来说,复用原则是第一位的,自己添加的术语需要明确定义,并给出命名域(作为课题来说,要给出建 议),否则方案就是不完整的。

细究下去,还有许多进一步的理解,希望这次到深圳参加数图十年会议,能有机会能跟大家沟通一下,并得到大家的批评指正。

Popularity: 49% [?]

Tags: Metadata, 元数据, 元数据

Related posts

DC元素的中文翻译

最近参加了汪东波老师主持、业界许多知名单位派代表参加的“DC元数据元素集国标项目”,顺便把我们经营了多年的“DC中文网”(改版前在这里)更新一下。最主要的工作是对DCMES (Dublin Core Metadata Element Set,即DC的非限定版)的ISO和NISO版本,以及几个中文翻译版进行比较,记了一些笔记。发布在这里,以期引起更多人的讨论和批评指正,并供大家参考引用。

以下修订笔记,记录于2007年10月21日,作为备忘,并供讨论参考。

1、建立了各元素单独的参考编辑页面以便逐个进行讨论修订。同时也建立了一个15个元素的汇总页面

2、外链的标准规范文档需要在本地做镜像,以备网络或其他问题引起查考不便。

3、《都柏林核心元数据元素集(1.1版)》最新的中文翻译文档原文档(2006年12月18日)在元素的说明体例上并不完全一致,因为当时中文版网站缺乏版本管理(没有用Wiki)而保留了部分原有的体例(例如“术语类型”、“状态”和“发布日期”等)。

4、ISONISO标准和中科院基本元数据项目对于元素的排列都是按照重要性(title, creator…),而DCMI是按照字顺(contributor, coverage…),我们也将参照ISO、NISO的顺序对元素进行排列,而不是以字顺排列。

5、目前DCMI定义元素时,名称(Element Name)作为元素的标识(id),是给机器读的。而标签(Label)是给人读的。因此前者都用小写,后者首字母用大写。目前修订过的ANSI/NISO Z39.85:2007IETF RFC 5013都是这样,而中科院项目是把名称也翻译成了汉语,标签保留首字母可以大写。ISO 15836:2003还是名称和标签首字母都大写。

6、目前的文本在元素的定义和内容上尽可能与经过审核的最新的ANSI/NISO Z39.85:2007IETF RFC 5013Dublin Core Metadata Element Set, Version 1.1保持一致(经过核对,这三者是完全一致的)。DCMI中文网的文字上有与上述文档不一致的地方。

7、DCMES在修订过程中(如NISO Z39.85:2007),对于注释进行了简化,特别去除了具体的实例(例如identifier去掉了URI、DOI、ISBN举例)。考虑到GB需要添加实例,某些简化掉的内容可以添加到实例中。

8、由于目前在文本方面尽可能参考/采用新版的DCMES,有一些地方与ISO 15836:2003不尽一致,是否合适,需要项目组集体讨论。本人建议,因为ISO 15836:2003也即将面临Review,我们还是以尽可能反映最新的标准讨论成果为宜。

Popularity: 100% [?]

Tags: DC, DC Metadata, Metadata, 中文翻译, 元数据, 元数据, 标准规范, 笔记, 都柏林核心元数据

Related posts