要把诺大一个网络当成一台计算机进行资源共享，网格所涉及的内容实在博大精深。浏览完这本书后，我对网格已经失去了兴趣。与我们的领域相距太远。就像我们已经开始关注网上冲浪的体验，而他们却还在讨论穿孔纸带容易断裂的问题。

当然这个领域的进展还是相当快的。自从英国的E-Science计划开始以来，综合了各类相关技术，网格是其中的重要平台技术。而E-Science一开始便立足于应用（按照我们现在的话语体系应该叫做立足“人文”），立即提出了“Semantic Grid”的设想。这就是利用网格这样一种基础设施进行面向服务和面向应用的设计，结合最新的Semantic Web 和Web Services的进展，直奔主题——语义。

这本书有三个章节是与我们最相关的，即第17章开放网格服务体系结构（如果对网格的基础结构如沙漏层次模型感兴趣，还应该加上第4章），第22章 数据访问、集成和管理和第23章 运用知识和语义增强服务与应用。本来以为第18章“资源和服务管理”应该是密切相关的，然而这个资源非信息资源，是指底层的网络基础设施所提供的可资利用的各类设施，资源管理是指对这些设施的操作，所以不属于“高层语义互操作”的范围。

第十七章

网格已经明确地采用了W3C的Web Services和Semantic Web技术，这才确立了其标准化和走向成熟的地位。集中表现在OGSA开放网格体系架构（Open Grid Services Architecture）的提出和完善上。只有采用了标准化的技术，网格才有可能成为一套标准的建构平台，才能/才敢在其上开发各种具有基本互操作、可移植、可重用组件和应用。OGSA也是采用WSDL作为其接口定义语言，定义了一套Web服务的接口、约定、扩展和改进规范，称为OGSI（Open Grid Services Infrastructure，这个词与OGSA似乎存在混淆，I理应是A的基础，比A更宽广博大），从这个意义上就将网格看成了一组特殊的Web Services，或者说符合OGSI标准的Web服务就是网格服务（当然有些“网格联盟”之外的成员可能不赞成这种说法）。

OGSA首先是一种面向服务的架构（SOA）。这里的服务是指“一种通过信息交换来提供各种能力的实体”，可以包括底层的资源管理功能（例如存储服务）、数据传输服务、以及高层的系统监控和故障处理等功能。SOA支持服务的虚拟化，能够使用户专注于其业务流程，而不必关注诸如服务定位、调用、管理、存储、安全、冗余备份过程等细节。

书中提到了采用WSDL定义的OGSI在四个方面简化了服务的控制和管理：

1. 服务发现。分布式计算中最重要的功能，SOA体系能够容易地穿件包含可用服务接口信息的注册库，供用户/代理查询和使用。但是我感到目前在注册库的实现机制方面可以标准化的东西还很多，要做到一个全域的注册体系需要很多技术的支持，其自身就可能使一套Web服务体系。

2. 服务合成。能够使代码重用并从简单的基本构件组合成复杂的应用，并能支持多种协议邦定。

3. 专业化。指不同平台上采用不同服务接口的实现。对资源无缝集成和虚拟集成非常重要。例如同样代码生成不同中间件环境、网络环境和操作系统环境的应用，就像MDA所要求的那样。

4. 接口扩展。对已有标准扩展性的一种支持。标准接口往往遵循“最小公分母”法则，缺乏对特性的支持，因而需要在接口语言中支持个性化定义。

OGSA随着Globus新版的推出，应该已经处于“可用”状态，然而其具体应用需要扩展的地方应该还有许多：

1、 目前扩展的重点放在安全、资源管理、数据和知识管理（我们最重视的地方）、仪器和故障处理以及工作流。

2、 一套体系适合所有应用，还未经过大量实例的检验。可能这样一种复杂的体系结构会一直留于“研究”领域，出成果的可能会是一些轻量级的、简单易行的“杀手”应用。当然作为考虑非常周全的OGSA，可能在需要高性能分布式计算的科学研究领域能够得到全面的应用。

3、 语义的不充分。OGSI的接口定义语言据说“还没有用来表示单个服务行为的形式化机制”，服务合成后行为的分析和推理机制也需要进一步规范语义。

4、 扩展性问题。永远是个问题。

第22、23章的内容与“语义结构”有关，放到以后再说。

Ian Foster, Carl Kesselman著 金海，袁平鹏，石柯译 《网格计算（第二版）》 电子工业出版社，2005年2月

目录

第一部分.    概论
第1章    网格背景
1.    历史经验
2.    飞速发展的网格
3.    从网络到网格
4.    谁将使用网格
5.    小结
第2章    科学需求
1.    科学探索新模式
2.    虚拟社区科学
3.    新基础设施的投资
4.    小结
第3章    工业需求
1.    技术演变：阶段
2.    技术演变：阶段2
3.    信息技术
4.    .集成
5.    效率
6.    网格和服务质量
7.    新模型：按需计算
第二部分        框架结构
第4章    概念和体系结构
1.    虚拟组织和网格
2.    网格体系结构
3.    网格体系结构的实现
4.    网格社区
5.    未来发展方向
6.    小结
第三部分        应用
第5章    可预测的维护：分布式飞行器引擎诊断
1.    故障诊断网格服务
2.    飞行器引擎的诊断和预报问题
3.    运行和使用DME网格服务
4.    未来发展方向
第6章    分布式遥现：地震工程学与NEESgrid的协作
1.    地震工程中的协作
2.    NEESgrid系统概况
3.    小结
第7章    科学数据联盟：全球天文望远镜
1.    虚拟天文台
2.    Web服务：使用分布的数据
3.    层次结构
4.    虚拟天文台和网格
5.    用虚拟天文台实现超越
6.    小结
第8章    医学数据联盟：生物医学信息学科研网
1.    神经成像推动着BIRN的发展
2.    BIRN实验平台
3.    BIRN网格
4.    信息协调
5.    推动网格技术的发展
第9章    知识集成：生物信息学中的In Silico实验
1.    动机：生物信息学中的In Silico实验
2.    myGrid体系结构和技术
3.    小结
第10章    分布式数据分析：用于高能物理的联合计算
1.    实现
2.    正式运行
3.    小结
第11章    大规模分布式计算：基于桌面计算机网格的虚拟筛选
1.    药物发现的计算需求
2.    网格技术的作用和必要条件
3.    桌面计算机网格的分子匹配计算
4.    小结
第12章    企业资源管理：科研和工业中的应用
1.    GlobeXplorer：数字图像摄取和分析
2.    休斯顿大学校园网格
3.    白玫瑰网格
4.    小结
第13章    可扩展的互动性：多人游戏基础设施
1.    Butterfly网格的设计
2.    GLOBUS工具集和BUTTERFLY网格
第14章    服务虚拟化：基础设施和应用
1.    .应用及基础设施技术发展的趋势
2.    虚拟化的三个层次
3.    一个虚拟化实例
4.    小结
第15章    群体协作：访问网格协作系统
1.    当前进展
2.    访问网格展望
3.    虚拟场所服务
4.    安全性
5.    工作空间对接
6.    节点管理
7.    异步协作
8.    小结
第16章    协作式科学：天体物理学需求与经验
1.    数值相对论和天体物理学
2.    CACTUS：一种网格应用框架
3.    虚拟组织内的资源共享
4.    与网格作业的交互
5.    分布式计算
6.    数据管理
7.    小结
第四部分体系结构
第17章    开放网格服务体系结构
1.    面向服务体系结构
2.    面向服务的网格体系结构
3.    一个例子
4.    Web服务
5.    开放网格服务基础结构
6.    OGSA服务和模式
7.    例子回顾
8.    其他问题
9.    OGSA实现
10.    未来发展方向
11.    小结
第18章    资源和服务管理
1.    网格中的资源管理
2.    需求
3.    通用资源管理结构
4.    网格资源管理系统
5.    服务协商和获取协议
6.    未来发展方向
第19章    构建可靠的客户端和服务
1.    可靠系统的基本原则
2.    可靠的远程执行
3.    工作管理
4.    网格计算的层次
5.    可靠输出
6.    未来发展方向
7.    小结
第20章    检测和监控
1.    监控数据的使用者
2.    检测
3.    传感器及其管理
4.    信息和监控事件数据发布
5.    监控事件数据归档
6.    数据分析
7.    实例研究
8.    小结
第21章    虚拟组织安全：联合信任和策略域
1.    网格安全需求
2.    新兴的安全技术
3.    Web服务安全
4.    GSI：OGSA安全参考标准的实现
5.    小结
第五部分    数据与知识
第22章    数据访问、集成和管理
1.    数据密集型应用
2.    结构化数据的类型和来源
3.    数据管理的挑战
4.    体系结构方法
5.    数据源服务
6.    聚合数据管理服务
7.    联盟服务
8.    实例研究：地球系统网格
9.    小结
第23章    运用知识和语义增强服务与应用
1.    面向网格的知识和网格中的知识
2.    知识环境
3.    面向知识网格的体系结构
4.    知识表达
5.    处理知识
6.    面向知识网格
7.    面向知识网格实例研究
8.    小结
第六部分    工具
第24章    应用层工具
1.    需求
2.    网格编程模型
3.    网格应用执行环境
4.    网格远程过程调用案例研究
5.    卫星检查系统案例研究
6.    MPIH-G2案例研究
7.    APST案例研究
8.    小结
第25章    语言.编译器和运行系统
1.    网格计算挑战
2.    并行计算的经验
3.    当前的网格编程工具
4.    .GrADS方法
5.    构件技术
6.    小结
第26章    应用调试和适应
1.    资源和性能的变化
2.    性能合同和可适应控制
3.    自动性能测试工具
4.    执行签名
5.    模糊逻辑控制
6.    自适应控制实例
7.    小结
第七部分        基础设施
第27章    生产部署：经验和建议
1.    构建大规模网格
2.    网格软件
3.    网格上下文
4.    生产网格的相关问题
5.    构建多站点网格
6.    小结
第28章    计算单元
1.    基本单元
2.    简单组合单元：本地网格
3.    小结
第29章    对等计算技术
1.    简要历史回顾
2.    应用
3.    特性与问题
4.    未来发展方向
5.    小结
第30章    网络基础设施
1.    过去（1969～1988）
2.    现在（1988～2005）
3.    未来（2005～）
4.    挑战
5.    小结
词汇表
参考文献
特别致谢
索引

遗憾的是我这里登不上ACM的Digital Library，但是我想找到狐狸先生的这篇大作不难，狐狸先生的5S理论不知法了多少SCI收录的文章，毕业了多少硕士博士了，每回JCDL/ICADL，只要狐狸先生参加，就肯定要作5S的tutorial。我的电脑里有好几篇类似的论文和ppt了。

前一阵写了篇博文“Fox先生的数字图书馆5S模型”，堆砌了一些资料，后来受老槐的鼓励和启发，还是写成了文章的一部分，今天雨僧提及，就顺便发在这里吧，与上次重复的东西（例如图表）就尽量略过了。

Fox博士的数字图书馆“五行”学说

从技术角度，数字图书馆常常被看作Web上的一种信息资源组织体系，应该具有共性的应用需求和体系架构。不论具体资源内容和服务对象是什么，这种应用需求和体系架构应该可以被抽象出来，作为一种“模型”或“方法论体系”而能够得到重用，从而大大简化数字图书馆的开发过程，促进数字图书馆的建设。

然而要实现这种想法难就难在数字图书馆作为一个应用领域并没有固定的模式，其“共性”是非常难以提取和把握的，因而建立公认的模型几乎是不可能的。

Fox博士抛开“数字图书馆”概念之争，另辟蹊径，从哲学味很浓的数字图书馆存在和运行的各项“要素”入手，经过十多年的潜心研究，提出了一套数字图书馆的体系模型，并开发出相应的实现方法，以及软件工具，几乎已经到达成功的彼岸。

Edward Fox博士是Virginia Tech大学计算机系教授，一直参与美国NSF资助的数字图书馆项目，曾被1998年的一项德尔斐法研究报告称为美国十大数字图书馆专家之一。Fox博士认为，数字图书馆是具有以下五项要素的复杂系统：

• 能够满足人们的信息需求（社会性要素Societies）

• 提供相应的信息服务（情境性要素Scenarios）

• 以有用的方式组织信息（结构性要素Structures）

• 以有用的方式展示信息（空间性要素Spaces）

• 与用户交流信息communicate info with users（流体性要素Streams）

不知道Fox博士最初的想法源自何处，是如何想到这5要素的。据说这种认识刚出炉时曾被朋友调侃为古代中国对于世界根本性认识的“金木水火土”五行学说。让人大跌眼镜的是这个看似玄学的“基本理论”结合了计算机科学的理念和工具，居然能够发展成一套甚至可以进行“演算”和推导的模型。

从计算机软件工程的角度和所支持的应用的体系架构来看，Fox博士的5S数字图书馆模型可以看成MDA（模型驱动架构）的一个实例，虽然Fox先生没有在任何地方提到MDA，也确实没有在任何地方应用MDA的具体方法（除了UML），但是思想方法却如出一辙：一套模型架构（5S）、形式化方法（包括本体关系）、建模语言（5SL）、建模工具（5SGraph）、生成工具（5SGen，能支持开放数字图书馆ODL架构的实现）。当然其抽象层次没有MDA那么高，体系没有MDA那么复杂。

乍一看5S试图穷尽数字图书馆存在的各种环境因素，实体关系非常复杂，这完全是由于进行一般化抽象的需要，每一个S考虑的内容就那么一些，实体之间的关系也抽象出了不多的几种。既然成为一个模型，就应该自成体系，不能有重大遗漏。但是仔细分析就会发现，这种抽象的理论实际上是对数字图书馆的一种简化，同时使人们在考虑数字图书馆建设时能够全面把握，不至于顾此失彼。数字图书馆领域可以参考的类似模型还有很多，例如OAIS模型、FRBR模型等，它们彼此之间角度不同，成熟度不同，解决的问题不同，应用方法也不同。

由于计算机处理有进行形式化的需要，5S理论定义了一整套符号体系用于数字图书馆建模，并将数字图书馆的各类服务详细地列举出来（如表），表示为函数形式以便机器操作。

5S理论提供了一整套建模和代码生成工具，包括5SL、5SGraph、5SGen等。

5SL是该模型提出的一种基于XML的数字图书馆建模语言（主要采用了MIME类型, XML Schema, UML notation等），作为特殊领域的建模语言提供一套符号系统，表达该领域各类实体及其相互关系，以及对问题进行抽象表述。对于领域知识分析、表达、程序管理、可视化、测试、维护、建模、以及快速建立原型等都非常有用。

5SGraph是该模型提出的数字图书馆建模工具，能够帮助用户利用5SL建立自己特殊的数字图书馆模型实例。简单的建模过程能够方便快捷地创建数字图书馆。5SGraph将元模型装载于一个结构化的工具箱中，其提供的结构编辑器能够提供自顶向下可视化数图设计环境，并根据可视化模型提供5SL文件的语法检查等功能。5SGraph具有灵活的可扩展结构、模型的重用、装载、存储、修改一般（子）模型、视图同步以及强化语义约束等初步功能。

5SGen第一版应用于MARIAN项目，支持基于语义网络的知识表达和包含行为的节点/链接描述，第二版将结构性/空间性要素（主要指关系表、索引等）封装于组件中，并更强调情景性/社会性要素的实现，从而能够支持组件化的ODL（开放数字图书馆）。5SGen第二版已经在CITIDEL、VIADUCT、NDLTD Union Catalog以及BDBComp等项目/系统建立原型过程中得到应用并发展完善。

总而言之，5S理论是目前为数不多的对数字图书馆体系结构和建设方法的系统、完整的认识，并不断有实际的应用对这套体系进行发展完善。虽然目前还只有Virginia Tech等少数大学在继续研发和使用，其方便性也不如FEDORA、DSPACE、Green Stone等开源软件，但在模型建设方面有它的特色，对于系统的可移植性、扩展性和互操作性有着其它软件不可比拟的优越性。

据说到2002年6月网格界开过“遵义会议”、提出OGSA（开放网格服务基础架构）草案之后才使网格“走上了正确的道路”，然而——

“近一两年的实践证明，OGSI存在明显的不足。其过分强调网格服务和Web服务的差别，导致了两者之间不能更好地融合在一起。由于OGSI单个规范中的内容太多，所有接口和操作都与服务数据有关，缺乏通用性，而且OGSI规范没有对资源和服务进行区分。OGSI使用目前的Web服务和XML工具不能良好工作，其过于采用XML模式，比如xsd:any基本用法、属性等，这种性质可能造成移植性差的问题。” [1]。

然而这时候问题也还没有完全解决，直到据说最近要推出的包含WSRF的WGSA2.0，才算与W3C完全彻底地同流合污，（当然今年年初发布的网格操作系统Globus Toolkit 4（GT4）已经完全支持WSRF了，ChinaGrid的对应中间件产品是CGSP，具有国际一流水平[2] ，呵呵）。现在看起来，宏观上网格成了Web服务的一种特例，微观上网格对于Web服务的许多规范进行了进一步定义，以适应分布环境下各类资源的分配与调度、存储管理、支持工作流和安全特性等等功能细节，也是一套标准规范以及符合这些标准规范的应用软件。可以看到网格实际上也为数字图书馆的建设提供了更进一步的标准化环境，支持网格的数字图书馆解决方案可以直接将应用建立在相应的网格平台上，可以省去许多标准规范定义和中间件开发之苦。这就像生产汽车一样，如果你自己定义各类组建标准，你可以生产各种怪模怪样的外星汽车，然而你如果符合一套汽车行业标准规范，可能只能生产小汽车了，虽然想象力大大受限，但是由于组建的标准化，具有了更大的灵活性和巨大的成本优势。

网格命运多桀，不用精通技术就能知道，受技术界的误导，人们对网格的期待过于理想化了。最新一期《信息周刊》中[3]有这样的文字：

“当网格计算3年前从美国国家研究实验室推广到商业计算领域时，它给人的印象是无所不能。它向人们描绘了一系列令人兴奋的功能，比如让桌面电脑变得也像超级计算机那样强劲；让用户摆脱他们部门的技术局限；通过采用了Globus Toolkit的网格计算，就能在互联网上找到最佳的电脑和数据库来解决复杂计算问题。……比尔•盖茨（Bill Gates）曾这样表示：网格计算代表了“计算机科学的圣杯”。

“但是，网格计算在开拓企业市场过程中却遇到了尴尬。惠普公司、IBM公司、微软公司以及其他一些企业曾经希望采用Globus软件，将客户 的计算机、磁盘驱动器、数据库和操作系统等组织成一个强大的网络，突破计算能力的企业边界。然而，到目前为止，还没有一家企业在现实中采用Globus软件。”

如果还要进一步的证明，中国计算机报去年就登了一篇许多人视而不见、或者充耳不闻的文章：规避网格泡沫[4]，写得太好了，使偶不得不超出版权限制，摘登字数达到原作的90%以上（如果被判侵权，请诸位为我募捐赔偿啊，呵呵）。摘要附于文后。

我国的网格研发方兴未艾，有五朵金花（见下），耗资该上亿了吧，工程应该没有粒子加速器那样庞大，所以也就没有杨振宁似的科学家谏言劝阻。网格本来可以做一个应用项目来做的，但是我国的这五大网格却搞成试验田了，看一看他们的论文就知道了，(这里有一篇国内号称最牛的牛人的文章，介绍知识网格，使人雾里看花，仿佛科幻小说，又不知所云)。许多东西八字没有一撇就吹得神乎其神，顶多给SCI收录一把，毕业一批硕士博士，给国外培养些人才，说到应用，将来还得引进别人的产品。

国内网格五朵金花：

• 863中国国家网格China National Grid
• 国家自然科学基金委China Science Grid
• 973语义网格China Semantic Grid
• 中国教育科研网格ChinaGrid
• 上海网格ShanghaiGrid

国内鼓吹网格者众，各有各的目标和利益，因特上的网格资源也很多，w3china网站上的一个帖子中报道了下面这些资源：

http://www.semanticgrid.org/
http://www.mygrid.org.uk/ myGrid项目主页
http://www-106.ibm.com/developerworks/grid/
http://www.gridforum.org/ Global Grid Forum(GGF)官方主页
http://www.globus.org/
http://www.rcuk.ac.uk/escience/ e-Science计划
http://www.gridcomputingplanet.com/ 工业界的Grid新闻网站
http://people.cs.uchicago.edu/~foster/ Ian Foster个人主页
http://www.neresc.ac.uk/ws-gaf/ WS-GAF

国内网站
------------------
http://kg.ict.ac.cn/ 中科院的Knowledge Grid主页
http://www.gridhome.com/ 中国网格信息中转站，国内最早、最大的Grid主题网站，基本上相当于刘鹏的个人网站，有大量的资料可以下载。

http://bbs.w3china.org/list.asp?boardid=57 W3CHINA Grid版

“中国语义网格”http://www.semgrid.net/（与知识网格http://kg.ict.ac.cn同宗，属诸葛海）；下一代WEB服务联合研究中心Joint Centre of Excellence on Web Services Computing http://www.cs.cityu.edu.hk/~csqli/research-projects/WfView_B2B/content.htm；

计算机及网络设施、软件和信息资源，是网格应用的三条腿，（当然还有一种说法，把“人”也网进去，作为网格应用的起点和终点）。长期以来网格只重视硬件资源的调度和共享，目前已开始重视相应的软件和应用系统[5]，然而对于第三条腿“信息资源”，国外还有一个Semantic Grid，（国外从E-Science到Cyberinfrastructure等与网格相关的研究开发无不把信息资源的利用共享、满足用户的信息需求放在首位，此所谓老槐的“人文性”吧），而我们虽然也有“知识网格”、“中国语义网格”，然而看看其中的研究内容你就会发现，还是计算机科学家们玩的把戏，实验室里的东东。这第三只腿怎么办？按我的认识甚至可以把这第三只腿看成是需要前两只腿支起的整个身子，这身子就是具体应用中的大量的信息资源内容（当然各类应用中的信息资源有时也只是过程手段而不是目的，例如电子商务中的信息流），这整个语义内容架构就是我们应该关心的，目前这方面的研究还太少，刚刚起步，数字图书馆的研究对象和内容就是解决这个问题的，网格也与Web或者Semantic Web（Sowa建议Semantic Web改名为Syntactic Web，因为他认为SW一点都不语义）一样只是一个知识的平台而已，数字图书馆才是其上真正有价值的东西。

附：规避网格泡沫

特约作者 任洁

参见http://www.ccnews.com.cn/04.01/product_wangge.htm，未经授权，多有冒犯。

(网格) 像个小姑娘 被别人随意打扮

　 　网格确切的概念到目前为止，在学术界还没有得到统一。网格到底是什么，不是什么，网格应该是什么样的，有什么标准，到目前还没有定论。至少从目前的很多专家口中说出来还都是不一样的。每一个人的出发点是不一样的，每一个人的利益也是不同的，因此在现实中，网格到现在还没有一个权威的、统一的定义。
　 　有人说网格是一种标准，有人说网格是一种方法，最早从事网格项目，目前在网格界最有影响力的是Ian foster,他为网格制定了三个标准，(1) 在非集中控制的环境中协同使用资源；(2)使用标准的、开放的和通用的协议和接口（Ian Foster 认为目前只有Globus 才算得上标准协议）；(3) 提供非平凡的服务。这个标准虽然是权威口中说出来的，但是并没有得到广泛的认同。
……

　　虽然将网 格比作电网，已经得到人们认同，但是这个概念并不能指导人们现在的工作和科研。就现实情况看，可以把网格和网格技术分开来，网格技术是一种概念和思想，它的本质是资源和信息共享以及协同。一切符合这个思想概念，能够完成过去传统技术不能完成的工作的技术都可以称为网格技术。网格一般来说是个基础设施，因为 要建立在资源和信息充分共享的基础上，所以网格要整合很多异构的资源和不同的信息系统，就需要依赖公共标准。网格标准需要是开放的，它不能被控制在某个企业手中。对于网格的用户来说，他们面对网格的接口需要是非常简单的，用户不必关心网格底层到底有多么复杂，他们所看到的网格是一个统一整体，完成的是一个 统一的功能。

　　在IT业界，在大公司的口中，网格其实是被用作广告的噱头。通过他们的口中，公众实际上了解到的是，网格是一种高新技术，是下一代Internet，是下一个信息技术浪潮。如果用户不跟上这个浪潮就会落伍。但是网格到底是什么，到底怎么应用，网格给公众，给企业到底带来的是什么，实际上各家有各家的说法，甚至有的还没有说清楚。

　　IT厂商好似一个纯熟的画匠，给用户画了一幅看起来特别美的油画，但是到底画的是什么，模模糊糊，搞不明白。这已经是IT公司惯用的伎俩，也是他们培养任何一个产业都需要吹的泡泡，相信IT业界已经习惯了公司吹出来的各式各样的泡泡了。

网格年轻的心 并非足够坚强

　 　网格是一个还未长大成人的孩童，可塑性太强。总体上看，网格技术目前还处在初级阶段，对于大多数应用领域，尤其是在商业应用，网格都不是成熟到能够达到实用的地步。目前，网格计算领域已被具体划分成计算网格、数据网格、信息网格、服务网格、语义网格等等。其中，计算网格相对研究的最早，目前已经有了一些 现实工作。美国建立了他们的计算网格，中国也建立了国家高性能计算环境，而且目前也正在进一步完善这个计算网格的功能。
　　计算网格应用的工作还处在探索阶段，网格的力量还不能像很多人想象的那样，即把全国巨型机和高性能集群用高速网络连接起来，就可以组成一个相当于所有巨型机计算能力之和的一个具有庞大计算能力的超级计算机。……目前针对一个计算任务，联合调度多个计算资源服 务的技术问题，已经进行了很多研究，但还只适用于某些通讯需求很少的应用，对于绝大多数应用都还没有超过在单台高性能巨型机上运行的效果。计算网格中下一步要解决的都是比较艰巨的问题，不是短期内能够完善达到所提出的高吞吐率，联合调度，资源预约，鲁棒性等目标要求。
　　数据网格在国外，针对其应用的研究已经取得了阶段性成果，主要是面向高能物理，化学等领域。这些项目目标明确，特点分明，虽然数据网格的实现技术可以借鉴，但是不具有通用性。通用的数据网格产品有SRB,AVAKI等。目前已经有比较稳定的基本功能实现，但是还没有见到典型的、成功的应用实例，特别是针对商业应用。……数据网格的现状是 有一些阶段性成果和产品，正在积极的寻找应用。处在结合和发展阶段。
　　信息网格的前景被很多IT厂商和专家看好。政府，军队，大公司都有强烈的需求。但是专家和技术人员，现今还处于初步讨论阶段，并没有任何有实际意义的原型和产品出现。而实际上，开发原形产品是一项极其艰难的任务。为了实现软件的互通互操作，在中间件领域已经进行了长期的研究，各大公司投入巨资进行标准定义，软件开发，并且已经形成了一个中间件产业。而对于信息网格来说，这仅仅是一个基本的要求。信息网格不仅需要软件能够互通互操作，而且需要在此基础上提炼所有有用信息，并把用户最关心的内容及时的、准确的、经过智能的分析整理，并用最终用户容易理解的方式，送到用户手中，为政府官员，军队指挥官，公司经理的决策提供依据。对于这个目标，信息网格技术大概在２０２０年内可以实现并支持这样的体系。
　　服务网格核心思想是各行各业把相关业务实现成Web Services（网络服务）的形式，让用户能够通过网络获得服务，或者是让其它的业务软件能够调用。公司对外提供服务，当然是收费或者靠业务获得利益，政府机构，事业单位也可以用这种方式提高工作效率，节省大量的成本。

……

像一个框 什么都来装

　 　就因为网格技术可大可小，可通用，可具体。现实中，很多围绕网格话题的科研课题的研究方向非常前沿，内容十分复杂。全球研究机构重点研究方向集中在，如何在超大规模、组成极其复杂的情况下，实现网格技术，例如我国863计划正在实行的“中国国家网格”，教育部实施的“教育科研网格”，欧洲的Data Grid项目和UniCore。研究一种通用建设网格的方法，往往是一个长期的目标，不是短时间内就可以把所有问题都解决。
　　当前很多公司，政府机构，学校，某些行业都确确实实感觉到了网格的必要性，他们大多是对底层组织机构中资源分散，彼此相互孤立的现状感到不满。他们对网格技术的需求是比较旺盛的，只是现有的IT技术，还达不到他们的要求。
　 　如何协同社会各个行业，各个部门的功能，来共同解决复杂的问题，这是当今网格标准制定的方向。例如在一个交通网格中，一个交通服务公司来为所有驾驶员提供选择交通路线的服务，这些服务应包含气象服务、GPS定位服务、道路建设部门服务。为了达到这种全社会网格（或者称为服务网格）的目标，各个行业就需要把本行业对外的业务电子化，信息化，Web Services（网络服务）化。这个过程大概是在５年以后才会陆续出现，并且会不断的发展壮大，并在１０年后或者更长的时间内达到成熟。在这之前很多企业和部门就需要为这样的业务运行方式进行技术上的准备。

商业应用 永远利字当头

　　商业都是要盈利的，而网格的普及，在很多情况下强调 的是一种基础设施，就象水电、桥梁道路、internet一样，各种应用是要在这样的基础设施上运行的。建设这样的基础设施很大程度上需要政府来介入，比 如说，美国建设了计算网格，用高速网络联系了多个超级计算中心，各个超级计算中心或者说整个计算网格的运行基本上是靠国家补贴来维持，并不能靠出售计算能力来达到收支平衡。
　　国家提供的高性能计算力来解决各种应用问题，带来的是国家整体利益的增加，而不是网格自身的盈利。对于存储网格，数据网格，数据库网格等，是完全可以靠IT公司的摸索来实现。其模式是为其它企业提供非常专业的存储服务，数据库服务等。
　 　建设存储网格，数据网格，数据库网格，是可以盈利的，但是其前期投入和维护的成本都会很高。鉴于在网格平台之上应用苦乏，网格技术还不成熟，相关法律还不健全的情况下，建设这样的基础设施很可能亏本，包括成为这样的网格客户都是要冒风险的，其网格客户群体需要一个长期的培养过程。

CIO慎看网格

　 　网格是一项值得关注的技术，它是符合技术发展潮流的，但是其发展是需要比较长的时间。如果是大企业中的CIO，企业自身有比较强的经济实力，现在就可以 积极研究网格技术在本企业的应用，如果能够领先其它企业早一步实现，无疑可以在企业的竞争中占据比较有利的位置。小公司、小企业，可以在网格这种基础设施建设好的情况下，积极利用各种网格平台带来的低成本，低风险，高效率的好处，把主要精力放在主要的盈利业务上去。
　　对于政府部门CIO来说，目前就需要制定中长期的建设计划，比如，卫生部门，如果希望在十年内能够实现一个卫生系统的网格，或者为社会服务网格提供相应的卫生系统的服务。那么就需要整合各个医院的信息系统，实现信息的互通或者能够在上面进行信息集成。

]]> 2397584@http://meta.bokee.com/ 读书笔记 2005-07-26T23:06:59Z http://meta.bokee.com/2397584.htmlhttp://jcst.ict.ac.cn/downloads/xsqy/qy1301.pdf http://feedproxy.google.com/~r/diglib/~3/I3DUz8by3TY/2386122.html
在这里贴出我们常用的一个评分表，供大家参考，如果有高见也请指出，在此谢过了！


（数图）软件开发项目专家评分表

序号	标书要求	评分					条件	权值
		5好	4较好	3中等	2较差	1很差
方案总体情况
1.	方案是否完整						方案中是否包含投标建设方案要求中提到的所有内容	1
2.	任务目标						项目需求分析和目标定位是否准确	1
设计方案
3.	系统架构设计是否合理						是否紧扣应用需求，日后运行、维护成本如何	1.5
4.	应用功能是否完整						是否包含所有标书所提到的所有应用功能要求	1.5
5.	应用框架是否合理、实用						总体应用框架是否符合业务要求；	1.5
6.	是否充分了解具体应用						比如是否对需求变动、元数据方案的修改有较好的支持能力	1.5
7.	系统硬件配置要求是否有依据						结合应用，适度超前	1
设计原则的体现
8.	先进性						设计思路与技术路线	1
9.	实用性						应用、系统管理	1.5
10.	标准化						业务规范、技术标准、示范效应	1.5
11.	扩展性						系统配置、应用扩展	1.5
投标公司
12.	公司质量管理水平与开发能力							1.5
13.	公司人力资源与后续支撑能力							1.5
投资预算
14.	报价项目是否清晰明确合理						是否与设计方案吻合	1
15.	报价						价格是否合理	1.5
其他
16.							参评人员认为其他值得加分的指标，请给出指标名称。	1

]]> 2386122@http://meta.bokee.com/ 数图建设 2005-07-25T23:23:07Z http://meta.bokee.com/2386122.html http://feedproxy.google.com/~r/diglib/~3/YweE02cJzMA/2357643.html 看到Pete给Partrick的一封信中讨论了一些我们一直在争论和困惑的问题，引申出一些思考，写在这里留存。

1 资源集合的类型标注Type

1.1 资源集合由多种类型的资源对象（Item）组成；（目前采用dc:type cldtype:collectionText等来编码，有建议增加属性cld:itemType）

1.2 资源集合的类型采用类型词表专指度不够，如何扩展？（Pete例举了一种自定义subtypes/subclasses）

1.3 资源集合内的资源对象，既有数字对象，又有非数字对象，如何描述（见Pete的举例）？

1.4 资源集合内的资源对象，有些有对象级元数据，有些没有，如何描述？（Pete提到RDFS具有更强的表达能力，但是存在不规范的危险。现在DCMI还没有提供基于RDFS的BestPractice）。

Partrick:

We would like to convey two kinds of information:

1. This IS a collection of (retro-)digitized material (all of our collections are of that same type).

2. This is a collection of certain item types (newspapers, encyclopedias, pamphlets, journals).

At first glance, cld:CLDType seems to be appropriate for 1. But then we would have to use dc:type cldtype:collectionText, and that's too generic for our purpose. We would like to be able to distinguish collections of "born digital texts" from those containing "digitized texts". I believe Issue 2 would be covered by cld:itemType I think.

Pete：

Just to clarify, the property cld:itemType was being suggested as an alternative approach to the current use of dc:type i.e. rather than saying

collection:C dc:type colltype:CollectionText . ("Collection C is a member of the class of collections with items of type Text")

we might say

collection:C cld:itemType dcmitype:Text . ("Collection C has items of type Text")

In both cases, I think it would be possible to define a "local" type vocabulary to specify a subtypes/subclasses of digitised textual items or "born digital" textual items

collection:C dc:type yourcolltype:CollectionDigitizedText . ("Collection C is a member of the class of collections with items of type Digitized Text")

or

collection:C cld:itemType yourtype:DigitizedText . ("Collection C has items of type DigitizedText")

where you define yourcolltype:CollectionDigitizedText as a subclass of colltype:CollectionText or yourtype:DigitizedText as a subclass of dcmitype:Text

It may be stretching the use of dc:type slightly, but I think it could work.

Depending on whether you make information about that subclass relationship available in machine-readable form (e.g. using RDF Schema) then you might choose to include one of the first pair of statements in your description as well, or you might choose to omit it and work on the basis that consuming applications will infer it from your RDFS data.

Given that many DC applications - at the moment at least ? are relatively "unintelligent" and may not act on RDFS data to derive the additional statements, I think the former is probably a safer course of action at the moment.

Partrick:

2) institution responsible

Should be dc:creator.

I guess it depends exactly what you mean by "institution responsible" ;-)

The DC CD AP defines "An entity who gathers (or gathered) the items in a collection together." A basic question for us is: Does "collection" in DC CD AP (in our case) mean:

a) the collection of items (prints), or

b) the collection of digitized items (digitalia, metadata ON items)

Pete:

As you suggest, there are (at least) two different collections here, and I think it depends on the requirements of your application whether you need to describe them both e.g. if the services you provide make use of the collection of digitized items in part at least to highlight the existence of the collection of physical items, then you may wish to describe that second collection too. If on the other hand, your aim is to faciliate the discovery of the digitized collection, then it may not be necessary to describe the physical collection at all - having said that, information about the physical collection might assist the user of the digital collection in interpreting items within that collection.

The DC CD AP does not provide any means of expressing the relationship between these two collections (other than that they are related in some unspecified way, using dc:relation).

Again, depending on the requirements of you application, you may also wish to create a collection description for the catalogue (collection of metadata records) that describes your digital collection.

Partrick:

If b), then the creator is the institution which conducted the digitization project? Not the collector of the physical items, nor the digitization service provider, but the one who defined the collection as a collection of records on other things?

Pete:

Note that the DC CD AP uses the property dc:creator to indicate the "collector" of a collection. That may or may not be the agent that carried out the digitization (because I imagine those digital items might be grouped into other collections after their digitization) ? but in your case it sounds like the collector is the digitizer. And, yes, as you say, the collector of the physical collection and the collector of the digital collection are probably different agents.

Partrick:

3) location

gen:isLocatedAt. Which location is meant: Location of the physical collection? Location of the server? Location of the institution which hosts the (digital) collection? Location of the institution which created (cf: dc:creator) the (digital) collection?

Pete:

We still have an outstanding task (the major task outstanding, I think) to clarify the distinction between the Location and Service entities and the isLocatedIn and isAccessedVia relations/properties.

For some notes on the problems see

http://www.ukoln.ac.uk/metadata/dcmi/collection-model/

Partrick:

4) cooperation partners

Pete

Again, it depends exactly what this means. What is the relationship between the collection and this agent/these agents?

Partrick:

dc:contributor isn't mentioned in DC CD AP. Why?

Pete:

I think my answer to this is similar to the point I was trying to make in the discussion about dc:format: our task is not to work out how to apply the properties defined by DCMI to the description of a collection, but rather to identify what pieces of information about a collection we wish to represent in order to meet the "functional requirements" we set ourselves, and to specify how to to represent that information within the framework provided by the Dublin Core Abstract Model.

AFAIK, so far no-one has expressed a requirement to represent some information that we would use the dc:contributor property for. But if there is a requirement that isn't covered, then we can consider whether we need to include it (and how it should be represented).

Partrick:

Should therefore dc:creator be used? With specific attributes (type, role)? Are there practical examples for the use of attributes in this case?

Pete:

The DCMI Abstract Model doesn't include a concept of "attribute", at least, I think, not in the sense you mean (something like contributor role="editor"?). The model is based on simple statements that express relationships between two resources.

The DC Usage Board has been working with the Library of Congress to define a set of properties that can be used to represent the sort of information which in MARC is represented by the MARC Relator Codes ? and for example we already reference one of these properties to express the collection-owner relation.

In theory, other such collection-agent relations could be represented, but, beraing in mind that the intent is that DC CD AP is a simple, "core" set of properties, personally I'm hesitant to go too far in this direction.

Also I think it's worth bearing in mind that our work is rooted in (a subset of) the model defined by Mike Heaney. We have diverged from that in some relatively small aspects, I think, but I'd be a bit uneasy about introducing a lot of new collection-agent relationships that don't appear in the Heaney model.

Partrick:

5) funding

Are funding bodies to be mentioned as another dc:creator entry (maybe with a role attribute)? As dc:contributor?

Pete:

There is no specific provision in the DC CD AP to describe funding bodies (unless they are the owner of the collection).

Partrick

6) Period in which the project was realized, date of publication

DC CD AP defines dcterms:created: "The range of dates over which the collection was accumulated." Same basic question as in 2). If dcterms:created means the collection as a collection of digitized data and metadata there would be no problem with using dcterms:created for describing the dates of the project.

Pete:

OK.

Partrick:

There is the same problem with cld:dateContentsCreated (def. "The range of dates over which the individual items within the collection were created.") - what is the item in the collection? A print or metadata / digital representatives of that print?

Again, it depends which collection of items you are describing. The digital collection was (probably) not gathered together over the same period as the physical collection.

If the latter: what is the difference between dcterms:created and cld:dateContentsCreated?

It may well be that the values for both are the same for some classes of collection.

To pick up a thread from the last few days: if a collection is a conceptual entity, isn't the creation of an item the same thing as the accumulation of the collection? At least in our case?

Pete

That may be the case for that particular class of collections, but it isn't necessarily true for all collections, and for some collections both properties may be significant for resource discovery.

Partrick:

Collections of digitized prints are accumulated by creating digital content!

7) logos (branding images)

Just a question of common practice. Should the content of cld:logo rather be a name of a resource or an URL?

Again, I think we have to bear in mind that descriptions will be constructed within the framework of the DCMI Abstract Model, so ? given the current content of the DC CD AP - the use of either a value string or a value URI is possible. Though I think in that particular case, a value URI would make more sense. I mentioned this issue in a message at

http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0504&L=dc-collections&P=1125

一、 与叙词表相比，Ｏ的语义表示功能改进有多大？

二、 Ｏ能实现完全的自然语言标引吗？

三、 Ｏ的成熟能带来自动标引的实现吗？（这一问题与第二个问题有关联）

四、 Ｏ方法能成为未来网络信息检索的发展方向吗？

五、 Ｏ理论能为知识组织理论带来革命性变化吗？

一、

1、 即使在计算机领域，Ontology（本体）也有许多涵义，如软件工程与人工智能中的Ontology就很有些区别。现在公认的Gruber的定义（formal, explicit specification of a shared conceptualisation）也可以有多种实现途径，W3C的OWL可以看成是一种实现，Topic Maps也是一种实现。在我看来，本体就是对事物的某种认识，这种认识可以以各种方式表达出来（即explicit外在性，被认为是知识学习、共享、交换、利用的必需），最简单最直接的方式就是以概念体系来表达，然而现在一般认为仅仅是词表及其简单的关系构成的概念体系是不够的，领域知识虽然无法穷尽表达（任何领域知识都不是一个闭包），然而本体应该能够提供一种方式，使人们能够关联、推演、判断这些知识，于是本体希望能够表达人类知识的各个方面，例如函数关系、逻辑推理等等，而现在人们使用的本体表达工具（包括传统的给人用的分类法、叙词表，以及现在给计算机用的OWL等）都具有不同的应用范围和表达能力。

2、 现在人们开发和使用的所有本体语言或表达工具，就语义表示（知识表达）来说实际上没有任何新的东西，现在所做的只是采用另一种形式对前些年的人工智能成果进行表示或“重现”，都是早已有的东西，例如现在比较多的是采用基于概念的一阶谓词逻辑，用框架逻辑（如Protege）或描述逻辑（如OWL）的形式来表达和演算，等等。但是发展到一定阶段，是否会有所突破就很难预料了，有时使用的工具和形式会决定学科的发展方向以及是否能够取得成果。

3、 就OWL来说，其作用体现在形式化之后能够提供完全的计算机处理方面（即formal，形式化的要求），在语义表示能力方面也没有什么突破，但是就目前它的能力已经能做很多事情了。近年来本体之所以如此热门，主要还在于计算机能够通过它来管理大量的“形式化后的”知识，别小看这一点点的进步，应用于无所不在的互联网连接起来的海量知识能产生巨大的效果。

二、三、

目前我还看不出使用本体会对自然语言标引带来怎么大的帮助，是否自然语言标引之后，能够应用本体工具处理一下，马上就规范了？就像随便什么螃蟹在阳澄湖水里浸一下，就变成阳澄湖大闸蟹了，立刻可以身价数倍。

有了本体，如何实现本体的作用和功能，第一步就是Annotation，如何做，现在并没有比早就付诸应用的、利用工具实现“机助人工”更好的方法，但是计算机专家们一直没有放弃“自动”标注的幻想，希望在资源生成的时候，相应的语义元数据能够直接生成（这里涉及本体与元数据的关系，请参见本博客的其它相关文章1、文章2、文章3）。

另有一种认识：不要把本体看成是规范得不得了的东西。自然语言进行领域知识的标引，所形成的词表为什么不能是本体？照样可以应用本体工具实现一定的功能。一个信息系统经过用户大量使用之后许多概念能够自动归类、整序而成为可供别人使用的很好的本体，等等，本体的构建方法也可以是多种多样的。

本体的最大作用还在于机器与机器之间的达成的语义互操作，因而本体可以不是人用的，而纯粹是机器实现互操作功能的中间状态，例如以概率模型或向量模型表达的中间本体。

随着“全息”信息环境的建立和普及，人工“标引”的重要性和价值正在丧失。这种“全息”环境是指数字信息自从产生就带有作者背景、机构背景、内容/学科/领域背景（全文索引）、应用/用户背景等上下文信息（Context），这些信息不仅是人工标引难以企及的，而且是动态变化的。Google Pagerank用于排序的准确性几乎宣布了人工标引作用的彻底破产。当然这样一种“全息”环境还有赖于相关网络基础架构和信息生产/传播工具的支持和普及，其源头是人，其最终用户也是人，所以“人工”永远是最初的“肇始”和最终目的，本体等永远是工具，这一点到任何时候都是无法改变的。

四、

本体作为一种方法刚刚兴起，因此将会有一个发展、成熟、高潮时期，这个时期会随着语义Web的发展而逐渐强势。我本人十分看好本体方法，一个很强烈的理由是它有数学理论的支持（一阶谓词逻辑及其扩展）。当然如果最后证明语义Web也是一个与人工智能一样的大泡泡，本体方法当然也会沉寂下去。

本体是否作为未来信息检索的发展方向，不好说，它只是实现信息检索功能的一种工具，有特定的应用场合（就像倒排档对于信息检索的作用仅限于索引，当然这个例子比较狭隘，本体应该有更为广泛的应用空间）。将来的信息检索在信息系统的组织、提问式的处理、检索结果的呈现等方面将大量采用本体，这一点在我看来应该是毫无疑问的。

五、

知识组织如果说有理论的话，还是一种应用性的理论，如知识分类理论我并不觉得有多少理论性。本体对于知识组织的作用还是工具性的，而且这种工具是依附于计算机和网络的，是由于计算机技术的发展和网络规模的发展而带来的，可能对于未来的知识组织实践会产生一个根本性的改观，成为将来知识组织不能不考虑的一种方法，将来的教材也会不厌其烦地讨论本体方法及其实现，但是这是革命性的吗？我好像看不出。本体，本来就在那里的实体，爪哇国人向不食螃蟹，有朋自中国来，大啖螃蟹，味美之，于是食螃蟹。有何稀奇？

CNRI（Corporation for National Research Initiatives）的总裁兼CEO，2004年图灵奖获得者，号称因特网的三位发明人之一，也是这份杂志的大老板的Robert E. Kahn在本期的刊首词中回顾了Dlib杂志的历史，但是更多的篇幅用在了介绍这本杂志的财政支持方面，及其考虑的原则、宗旨、模式等。记得几年前Dlib开始寻求经费支持，让我们觉得颇不可思议，这么多业界大腕（Kahn、Arms等等）、这么广泛的关系网，居然会为了生计而发愁。这就是美国的运行方式。在十周年纪念的这期发刊词中，Kahn又平和地提到了寻求经费支持的问题。

整个这期刊物都是对数字图书馆的回顾，不仅是对这本杂志的回顾。而且因为作者都是这个领域的Key Player，颇具可看性。另外本期还有对今年JCDL会议的总结文章。

A Tenth Anniversary for D-Lib Magazine
by Bonita Wilson and Allison L. Powell, Corporation for National Research Initiatives
doi:10.1045/july2005-wilson

Really 10 Years Old?
by Amy Friedlander, Shinkuro, Inc.
doi:10.1045/july2005-friedlander

Whence Leadership?
by Ronald L. Larsen, University of Pittsburgh
doi:10.1045/july2005-larsen

Funding for Digital Libraries Research: Past and Present
by Stephen M. Griffin, National Science Foundation
doi:10.1045/july2005-griffin

Digital Libraries: Challenges and Influential Work
by William H. Mischo, University of Illinois, Urbana-Champaign
doi:10.1045/july2005-mischo

Where Do We Go From Here? The Next Decade for Digital Libraries
by Clifford Lynch, Coalition for Networked Information
doi:10.1045/july2005-lynch

A Viewpoint Analysis of the Digital Library
by William Y. Arms, Cornell University
doi:10.1045/july2005-arms

Dewey Meets Turing: Librarians, Computer Scientists, and the Digital Libraries Initiative
by Andreas Paepcke, Hector Garcia-Molina, and Rebecca Wesley, Stanford University
doi:10.1045/july2005-paepcke

Border Crossings: Reflections on a Decade of Metadata Consensus Building
by Stuart L. Weibel, OCLC Research
doi:10.1045/july2005-weibel

CONFERENCE REPORTS
Report on the Fifth ACM/IEEE Joint Conference on Digital Libraries: Cyberinfrastructure for Research and Education
by Tamara Sumner, University of Colorado at Boulder
doi:10.1045/july2005-sumner

· Data Dictionary for Preservation Metadata: Final Report of the PREMIS Working Group [PDF:3.2MB / 237p.]

· PREMIS schemas

· PREMIS Working Group Home Page [OCLC]

· PREMIS Implementation Survey [PDF: 1.24MB / 66p.]

这套方案应该会对图书馆界的数字图书馆项目产生重大影响。然而这套方案与DC有很大的不同，一是比DC详细得多，二是并没有以DC作为核心集（它自己到提出一个核心集的概念），当然PREMIS到DC的映射也是很好做的，三是它的元素是有层次结构的（现在看起来最多到四层）。我的感觉它是把OAIS模型具体化和规范化了，对OAIS涉及到的各方面属性元素都进行了定义，定义的基础又不是从DC的扩展，因而与国图提出的《中文元数据方案》有很大区别。

其中有很多思想值得借鉴。例如对于数字对象关系的分类，对于Event资源类型的属性集的提出，对四类实体的Schema定义等等。在相关的讨论组里还讨论了数据元素嵌入METS应用的问题。

一些重要的介绍信息如下：
Both the earlier Framework and the PREMIS Data Dictionary build on the Open Archival Information System (OAIS) reference model (ISO14721).3 The OAIS information model provides a conceptual foundation by providing a taxonomy of information objects and packages for archived objects and the structure of their associated metadata. The Framework can be viewed as an elaboration of the OAIS information model, explicated through the mapping of preservation metadata to that conceptual structure. The PREMIS work can be viewed as a translation of the Framework into a set of implementable semantic units in the Data Dictionary.

However, it should be noted that PREMIS and OAIS use some terminology differently, as noted in the Glossary. Differences usually reflect the fact that PREMIS semantic units require more specificity than the OAIS definitions provide, which is to be expected when moving from a conceptual framework to an implementation.

The PREMIS maintenance activity is responsible for maintaining, supporting, and coordinating future revisions to the PREMIS data dictionary. The Preservation Metadata: Implementation Strategies Working Group, convened by OCLC and RLG, initially developed the PREMIS data dictionary as a specification with the goal of creating an implementable set of "core" preservation metadata elements, with broad applicability within the digital preservation community. Supporting XML schemas allow for implementation of the core metadata element set and are maintained in the Network Development and MARC Standards Office of the Library of Congress.

As of May 2005 the PREMIS data dictionary and schemas will begin a period of trial use. It is expected that they will remain stable for at least a year, after which revisions may be made based on results of experimentation.