加载中…
个人资料
一问
一问
  • 博客等级:
  • 博客积分:0
  • 博客访问:12,280
  • 关注人气:27
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
谁看过这篇博文
加载中…
正文 字体大小:

听K一席话,胜读X年书

(2009-11-05 11:39:53)
标签:

keven

元数据

语义操作

rda

frbr

杂谈

分类: 图书馆学

听K一席话,胜读X年书

     对元数据、语义网一直是半懂不懂,要说对各个单列的概念,也算有点一知半解,但整体来说,这些东东能干啥?相互之间在实际应用中怎么关联起来?那是一点概念都没有。今天跟K兄吃了这顿饭,总算开窍了。
      不妨从一个应用来开始。这个应用是包含Ajax的客户端应用,开发者自然清楚客户端的页面有什么元素,因此也就能用Ajax构造出上下文敏感的动态URI资源请求,并能将这个请求生成的结果嵌入到客户页面中。
    好了,接下来的就是服务端的事了。关键是服务端可以接受什么类型的动态请求,或者说是这个请求指向的数据,是如何由保存于服务端的数据运算出来的。在URI和获取的结果之间,可以有数据表示的概念模型,这个概念模型既决定了URI请求翻译出来的语义,也决定服务端最终能提供多复杂的结果。这个模型可以表达成元数据标准。某个应用的元数据,实际上可以看成所存储数据的概念模型。有了这个概念模型,自然就可以通过预定义的、基于这些概念的公理运算,获得一些更复杂的结果。元数据的特性表现为“属性—值”对。公理的运算是在属性层面上的。对照关系数据库,属性大约可以看成就是域名或者列名。但数据库这个层面,只是数据的存取,是没有概念运算模型——也就是公理这回事的,随便写个sql就获取数据了。
      从这层用法上,可看出元数据虽然也可以看成是数据的模型,但却是比关系数据更抽象的、具有固定语义的概念模型。它的语义包含在属性的关系当中。比如说color,那是指Name指向的那个东东的color。从 “属性之间的关系是确定的”这个层面上来说,属性的值——也就是数据如何保存并不重要,只要这个值符合某属性的约束并被置入到“属性—值”对中,它的意义才是确定的。否则,那只是孤立的数据,不是可用于属性运算的值。
      接下来的问题,是元数据代表什么?从哪里来?理论意义上,一个元数据标准,可以对应一个应用领域所需要的资源描述。所以,很明白,元数据是领域应用的资源描述,从领域的应用中产生,是面向应用的。从这点出发,理解讲座中提到的DCAP、DCAM等等的关系,也就不中也不远了。这里头都两个问题了,一是what is resouce?二是元数据标准需要是强制标准么?K兄的意见是凡是可命名的都是资源,偶当时说凡是能相互作用的都是,后来改成有属性的都是,这其实等于说可知的都是。嗯,嗯,还是K兄说的直接。关于元数据标准是否需要强制标准的问题,下午K兄讲座时,有人提问,说偶们国家有无可能整合各种元数据的标准制定一个全面的标准。偶听了直想笑,人家是先有应用后有标准,偶们是没有应用先搞标准,这个弯没转过来,就是文化冲突了。由此也明白K兄曾说过的登记系统的重要性。那实际上是为元数据进化的提供一个现实的平台。DC制定政策来说,只是为了让DC标准的进化是可控的,而不是想一劳永逸。登记系统是这种可控性的必要设置。
     元数据既然是资源的描述,那就有个如何理解资源并组织对资源的理解的问题,这就是FRBR和RDA了。以前编目的方法很简单,一是辨识标目,二是把标目填入象MARC这类比较符合直接辨识直接记录习惯的格式即可。FRBR推出了一个资源的概念模型,把资源分为作品、责任者、知识控制三部分。偶把这个看成是试图用某种哲学来理解世界。当然,这个哲学模型是共识,不是图学闭门造成的造出来的。RDA在此基础上扩展了这个模型,增加了若干层次。这样,由于抽象的层次多,对编目员的抽象思维能力也就高多了。多想多错,从实用的角度看,RDA也就不是那么用户友好了。有个折中的办法,就是按MARC格式著录,通过一定的算法映射到RDA。这方面说有几个开源软件了。K兄的看法是如果纯RDA编目的话,需要流程控制标准和IDE的界面才能搞得掂,也就不是现在书商抓抓几个民工就能编的MARC,编目可真的成高门槛的专业了。FRBR模型的优点是能揭示作品中很复杂的关联,特别是文学艺术作品的流传、演变和各种不同的表现形式。但对学术著作则帮助不大,学术著作的揭示要靠知识控制那块。似乎现在曾蕾老师牵头搞的工作组,要解决的是知识控制那部分的概念模型问题?标准的话题基本这些。
      再回头说应用的事。元数据既然是概念集合,那么元数据的应用,就可以在概念的基础上进行集成,避免了建立一个应用要自己建立所有的数据,只要能获得这些元数据就可以了。但这是建立在有各种开放的API数据存取的基础上的。这样的话,元数据标准就成为了应用之间相互理解的基础。这个相互理解,就是元数据的互操作,这背后的推动力,实际上是数据开放API的存取。有数据又要开放,元数据才变得十足必要。不然只是在自己的小池塘里折腾而已。那数据为什么要开放呢?因为能赚钱。哦,专业点的叫利润增长点。象Amazon,先是在网上买书,再是什么都买。既卖之,自然要根据顾客的需要著录之,结果形成了史无前例的物品数据集,于是,想到开放API,让其他应用存取这些资源,量少随便用,日存取量达到一定数目可就要收钱了。这需要有个概念模型来归结资源的属性,这个模型就是很现实的元数据了。google也是如此。这个量少随便用真毒丫,搞得大家都在这些数据上开发,存取量大就收钱,好的应用就收编或者开发更好的。以后,应用越来越多,越来越好用,那些公司就成数据基础设施了。也因此这些公司总想左右元数据标准的制定,因为有数据才有话语权,搞得现在DC的影响还多在学术界内。
      so,现在图书馆的问题就是解决开放API的问题,毕竟图书馆带点公益的性质。然后就是看看这些数据可以和哪些开放数据同居生出小宝宝应用,来更方便的扩展图书馆的影响了。
      以前不知道元数据到底有啥大用,一顿饭从K兄那里挖出这么多东东,算是比较彻底的了解了元数据的前因后果过去未来原理应用了,以后该跟踪了解什么心理也大概有了个谱。饭吃完了。K兄坚持不让偶请客,提议的石头剪子布又输了,未能尽地主之谊,真是意犹未尽。回头要抓儿子多练练石头剪子布,下次好……哼哼     
     
             
     

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有