九乡新闻网贼王1995任达华:Keven's Notes on Digital Libraries
来源：百度文库 编辑：九乡新闻网 时间：2024/07/08 17:47:11
DC-2011 征文通告
都柏林核心元数据应用国际会议
元数据协同：超越语言进行描述
原文参见：http://dcevents.dublincore.org/index.php/IntConf/dc-2011/schedConf/cfp
本届都柏林核心元数据年会将于2011年9月21日-23日在荷兰海牙召开。
“当今的网络环境下, 元数据正日益成为大规模分布式资源管理的核心工具。近年来,由于跨领域合作交流的驱使,原先相对孤立的元数据社区之间的联系日益密切。但元数据标准尚无法满足各类机构社团间的互操作性需求。元数据协同（Metadata Harmonization）被定义为支持多个元数据规范进行组合的互操作问题，它已成为未来网络资源元数据应用的核心问题.”［1］理解元数据应用纲要的关键在于元数据协同，虽然对于这一点人们有所了解，但是如何设计描述语言却依旧挑战巨大。DC-2011将基于不同元数据方案的交融交汇，重点探讨描述语言设计的理论和实践问题，进行探讨不同的元数据方案之间的相互融合需要解决语言的问题。
截稿及重要时间安排:
- 投稿截止:2011年4月16日
- 录用通知:2011年6月18日
- 定稿提交:2011年7月23日
大会除上述主题外，也欢迎任何其它元数据主题的论文、报告和海报等形式的投稿，如：
- 元数据制定原则、指南和最佳实践
- 元数据质量（方法、工具和实践）
- 概念模型和框架(例如，RDF，DCAM，OAIS)
- 应用纲要
- 元数据生成（方法、工具和实践）
- 跨领域、语言、时间、结构和规模的元数据互操作
- 跨领域的元数据应用（例如记录留存、永久保存、保管(curation)、机构库、出版）
- 领域元数据 (例如，企业、文化记忆机构、 教育、 政府及科研领域）
- 作为语义网词汇的书目标准（例如，RDA、FRBR、主题词表）
- 可获得性元数据
- 科学数据、e-Science和网格应用方面的元数据
- 社会化标注和元数据构建中的用户参与
- 使用情况数据（paradata/attention元数据）
- 知识组织系统(例如：本体、分类法、规范档、大众分类法和叙词表）和SKOS(简单知识组织系统)
- 本体的设计与开发
- 元数据与本体的整合
- 搜索引擎和元数据
- 关联数据和语义网（元数据及应用）
- 词汇表注册及注册服务
投稿
- 所有提交的论文、报告、挂图摘要，和社团工作组、分会场会议必须经过DCMI的同行评议系统（链接在页面底部）。
- 作者需进入同行评议系统进行注册，在“作者信息”的链接下有相关提交流程的介绍。
- .所有的投稿必须用英文撰写。
- 所有投稿都将由国际性的学术委员会进行专家评审。
出版
- 经审核通过的论文、项目报告和挂图摘要将在此次会议的官方文集上发表，见http://dcpapers.dublincore.org/ojs/pubs。
- 分会场会议和社团工作组的文摘将在在线会会议议程上发表
- 论文、研究报告和挂图摘要必须符合DCMI同行评议系统的格式模板要求。
- 若无特殊安排，被录用的论文、项目报告和挂图应该至少由其中一位作者在海牙会议上宣读。
- 为了稿件能够顺利接收与出版，所有的投稿者需提供自己的基本资料，包括目前的专业职务和联系方式等。
稿件的种类
论文（8-10 页） 论文既可以详细描述创新性的工作，也可以对前述的一些领域性重要进展或者最佳实践进行介绍评议。
论文评判标准如下：
- 实现方法的创新性
- 所做贡献的质量
- 呈现结果的重要性
- 表达的明确性
项目报告 （4-5 页） 项目报告应该简明扼要地介绍一个特定的模型、应用或者活动。 项目报告的评判标准如下：
- 技术描述的精确性和完整性
- 对其他潜在用户技术指导的可用性
- 表达的明确性
挂图 (1-2页) 挂图是关于正在进行中的项目或课题研究的展示，或者已完成项目、课题研究的最新结果的展示。挂图建议应当包括一个长为一到两页的摘要。
挂图的评判标准如下：
- 精确陈述研究项目的目标和里程碑事件
- 研究课题或者项目的重要性
- 陈述主要的难点和进一步的研究
- 陈述结果和取得的主要成果
- 表达的明确性
会议现场将会安排一个或多个分会场来展示和讨论这些挂图。在会议网站上将会有关于如何准备挂图展示的指导和说明。除非另有安排，已录用的挂图必须至少由其中一位作者在海牙会议上宣读。根据前期安排，挂图的摘要可能被收入在此次会议的论文集中，并通过4-10分钟的视频进行展示，同时根据提交挂图摘要的URL地址将该视频上传到YouTube网站。
分会场会议 & DCMI社团工作组会议 分会场会议和社团工作组会议的提案应控制在800-1200字内，并含35-50字的用于宣传会议的摘要。会议提案必须明确一下内容：
- 会议召集人
- 假如可能，请给出参与者的类型
- 会议：
- 目的
- 议程
- 活动 (包括任何技术要求)
- 周密而完善的会议日程安排（包括会后总结报告）
- 工作小组会议的提案必须明确具体的DCMI社团（请参见http://www.dublincore.org/groups/#communities）
分会场召集人在会议申请审核通过后需就会议的完善、日程安排和会议的召开与会议主席密切合作。工作组主席经与会议委员会磋商，将会审查分会场会议的提案。工作组主席与DCMI相关社团的主席或联席主席进行磋商后，可以审核社团工作组的提案。会议提案的评估标准如下：
- 内容的质量和组织结构
- 选择该格式的理由
- 调动互动和参与的方法的证据
- 参与的包容性和多样性
- 要有吸引一般参会者的可能性，对于工作组会议，则还要吸引社团的兴趣。(包括除会场以外任何必需的技术如Skype)
[1] Nilsson, Mikael. (2010). 元数据标准化从互操作到统一：为元数据的统一设计一个可发展的框架.论文.瑞典皇家理工学院计算机科学和通信专业。斯德哥尔摩，瑞典.http://kmr.nada.kth.se/papers/SemanticWeb/FromInteropToHarm-MikaelsThesis.pdf
作者指南 所有经审核通过后的论文、项目报告和挂图都将收录到DC-2010会议论文集。根据提交文档的类别确定适当的模板格式：
- 全文和项目报告
- 挂图
为了确保可读性和文面的一致性，作者应该使用模板来规范投稿格式。
每个类别稿件的最大长度和评判标准都罗列在http://dcevents.dublincore.org/index.php/IntConf/dc-2011/schedConf/cfp的论文要求中。
DCMI坚持以盲审方式进行同行评审，这样作者不知道评审者的方式。但不采用双盲审的方式，因此，评审者可以知道作者的身份。
投稿可以点击下列链接：
投稿流程第一步……
(本中文文档由上海图书馆张晓雯、徐奕宁和王晓樱翻译，张春景、Keven审校，欢迎批评指正。)
Popularity: 15% [?]
Tags: DC, DC Metadata, DC年会, 元数据Related posts
谁在乎关联数据？
雨师布置作业，让我“从宏观上系统阐述关联数据对图书馆事业发展的意义和价值”，特别希望“能够对图书馆馆长们解释关联数据战略”。这显然是个不可能任务。对于关联数据，以及任何将能够动摇图书馆根基的信息技术，俺一向缺乏雨师的认识高度和深度，更没有那种责任感。但这的确是一个很有意义的课题。技术酒徒不能只埋头拉车，不抬头看路。否则总会被人抽了鞭子又当枪使吧。这不禁让我想到，谁最在乎关联数据？以及关联数据能够给我们带来什么？推动科技进步的不外是两种因素：好奇心和利益回报。以此观之，最在乎关联数据的首先是我们这些空想主义者，其次是商人，馆长会不会关心？如果有，也很少，这恐怕有赖于我们动之以情晓之以理，让他们看到关联数据的利益所在。那么关联数据究竟能带来什么呢？- 大量的规范数据；
- 新的资源组织架构；
- 新的业务和服务模式；
- 对网络信息基础设施的改进；以及
- 由以上四点构成的新的图书馆行业凤凰涅槃。
那么谁又是利益相关者呢？
- 国家图书馆及国家文献标准化组织
- 各类图书馆联盟
- 大型地区性图书情报机构
- 各类数字图书馆建设主体
- 民间网络团体和商业公司
Popularity: 22% [?]
Tags: 专业评论, 关联数据, 用处, 需求Related posts
关联数据URI的参引
语义Web（关联数据）用URI来标识大千世界的各类“对象”，称这类资源为“非信息资源”；而对这些对象进行描述的网页文件、RDF文件以及各类图像、 音视频等特殊编码的文件等，才称为“信息资源”。尽管URI负责标识（命名）和定位对象，但具体描述、说明和承担起交流作用的，还是各类作为信息资源的文 件，因此如何通过URI获取与其相关的“信息资源”就成了关联数据在实现时必须解决的问题。
上述“对象”、URI和说明文件的关系，可用上图（来自这里）的三角形关系来表示。左下的真实对象一只黑猫，被认识为一个概念（三角形顶角）而可以用URI进行标识，这个概念可以以多种符号或方式进行描述（右下角，指代HTML网页、图片、RDF文件等）。这个关系构成了语义Web（关联数据）表达真实世界的认识论基础。
那么具体在Web上怎么实现上述模型的语义表达和传递功能呢？关键在于保证URI在作为非信息资源标识功能的同时，能够起到对描述该对象的信息资源（各类文件）的定位作用。关联数据给出的方案如下：
1、对于来自客户端的任何非信息资源所有URI请求（称为dereference，这里翻译成参引），均采用HTTP协议中的“内容协商”规则，返回其所请求的信息资源描 述文件（对于非信息资源的请求是无法返回具体实物对象的，只能以描述该对象的代码文件代替）。一般信息资源描述文件有两类：即如果请求来自于普通浏览器 （头信息中包含text/html请求，其它MIME文件类型，如图像文件、音视频文件等，可归入此类），则返回HTML文件的网页；如果请求为 application/rdf+xml，则返回负责该对象语义描述的RDF文件。
2、具体的“内容协商”方式，通常有两种方案达成：
1） 采用HTTP协议的303指令重定向功能（如下图所示）。客户端（浏览器）的URI请求由于不存在“东西”（非信息资源），服务器就会发送一个303 See Other给客户端，再由客户端根据重定向规则发送请求，具体根据客户端是HTML浏览器还是支持RDF的浏览器，决定HTTP文件头请求何种类型的文件 （HTML或者RDF）。
该过程的具体流程如下图所示：
URI重定向通常采用以下惯例：
(1)
http://www.kevenlw.name/kevenliu (ID)
http://www.kevenlw.name/kevenliu.html
http://www.kevenlw.name/kevenliu.rdf
(2)
http://www.kevenlw.name/resource/kevenliu (ID)
http://www.kevenlw.name/page/kevenliu
http://www.kevenlw.name/data/kevenliu
(3)
http://id.kevenlw.name/kevenliu
http://page.kevenlw.name/kevenliu
http://data.kevenlw.name/kevenliu2） 采用带井号“#”（hash）的URI方式（如下图所示）。其井号前面的URI能够便于浏览器进行解析定位，而与后面带#号的片段标识符共同用来标识非信 息资源，该片段标识符同时起到了类似于重定向的功能，允许支持RDF的浏览器参引到信息资源文件（在这里是静态的RDF文件）的所需位置。这种方式要求该 片段标识符必须在RDF文件中是唯一的，且整个RDF文件不可过大，否则非常影响查询效率。
采用hash井号方式作为URI的例子如：
http://www.library.sh.cn/people.rdf#kevenliu
http://www.library.sh.cn/people.rdf#leonzhao
注：这里的“参引”（dereference），意指“为了获取引用资源的相关信息，在万维网上查找URI的过程。”
参考文献：
Best Practice Recipes for Publishing RDF Vocabularies. 见http://www.w3.org/TR/swbp-vocab-pub/
Popularity: 23% [?]
Tags: URI, 关联数据, 内容协商, 语义技术, 重定向Related posts
URI简要说明
作为对前一篇博文的补充，感到有必要把URI的概念再炒炒冷饭。
任何独立存在的事物都需要有一个标识来表明它的存在，不论这个标识是有意义的还是无意义的，抽象的还是具体的，文字的还是符号或图示的，或者是编码的。
最常用的标识是由语言文字来表达的名字。名字的作用是为了标识，并且有区分的功能，名字的重复和指代对象的不明确对于人脑来说并不构成很大的问题，人通常可 以通过上下文语境或者概念之间的关联，准确判断所指代的对象，但是对于计算机而言就必须明确区分，ID必须具有唯一性，不同的ID一定是不同的东西，即便 可以给它们建立相等的关系，它们也不是一个东西。
当然，这个唯一性是有一定范围的，不是无限的。例如开放的因特网世界，有命名域规则保证名称的惟一性，而封闭的内联网世界，其名称只需要在其内部具有惟一性即可。
远洋师让我介绍一些网络ID，我就介绍一些，不知道符不符合要求，请远洋师和各位同仁批评指正。
其实用两幅图就可以完整介绍因特网上能用到的几乎所有ID。
图一：说明了URI主要分URL和URN两种，其中URL虽然是一种标识，但同时作为可以直接定位的地址，而URN需要局域解析规则进行定位。
如下图二就说明了URI的基本语法（下图来自网络）
有了上面两张图示，就可以明白关联数据所推荐采用的标识是HTTP URI的子集，即CoolURI。HTTP URI其实就等于URL。CoolURI在上一个帖子中介绍过了。另外，OpenURL等地址规范也都符合URI规范。
Popularity: 23% [?]
Tags: URI, 语义Web, 语义技术Related posts
文档的Web和“东西”的Web
两年来一直想做一些关联数据的普及工作，总有一种无从下手的感觉。这个话题越来越热，有远洋师和雨师等的号召和书社会众社员的积极响应，感觉似乎时机成熟了，于是先放出风去，给自己一点不得不做的压力。
关联数据的概念想法其实很简单，但同时又很难让人理解，这是个很有意思的现象。是不是可以拿刘谦的魔术来类比，不知道的看不懂，知道了其实都是业内常见的trick。
前面的博文写了关联数据的n种定义，还没有完成远洋师的要求，远洋师希望解释两个问题：
1. 关联数据是Web of Data（数据的Web）的一种实现，而不再是Web of Documents（文档的Web）；
2.实现关联数据的两种方式：采用HTTP303转向和采用hash（即井号#），各有什么优缺点。
要解释清楚这两个问题，一方面我还要加紧学习，另外对于书社会的广大社员来说也需要学习，因为要听懂对这个问题的解释，听众至少要达到前述定义中的第四级用户——Web应用开发人员——的水平，而且还要假设这类开发人员对于HTTP协议有一定的了解，而不是只利用现成的工具进行开发。我相信这样的用户太少了。为了使1-3级用户也能有所收获，就让我多打比方，慢慢道来吧。
上过网的朋友都知道，通过在浏览器的网址栏键入网址（即URL），就能传回网页。如键入这个URL：“http://www.kevenlw.name/about/index.php”，服务器接收到这个URL，以HTTP（超文本传输）协议来响应这个请求（之前还有DNS域名解析的过程，把域名转化为ip地址，略过不表），将about目录下的index.php文件传输给浏览器，并显示出来。
这个过程，涉及到Web技术的三个主要内容：HTTP、URL和HTML。
- HTTP是服务器操作的指令，规定了遇到各种请求（如GET/PUT/POST/DELETE)服务器如何响应，怎么处理；
- HTML是存储在服务器端的网页文件，将根据请求传送给浏览器，HTML的标准规定了文件的结构，允许包含丰富的超文本链接，并能嵌套各类其它文件格式，如果浏览器一端有相应的资源或程序就能够调用或运行。正是由于HTML，使整个万维网上布满了相互链接的文件，成为一个巨大的、不断膨胀的文件宇宙，这就是Web of Documents的来历。
- URL本来是作为在这个文件宇宙中定位具体的文件而用的，后来演变成兼具名称作用，从而被URI连同URN一起收入麾下，让URI一统江湖了。
一个由方案（scheme，或译为主题）、域名和路径组成的URI标识，从仅仅标识文档，到用来标识“任何东西”，看似简单的变化，其背后却是思考范式的变化，是哲学认识论层面的变化。(一个最重要的trick就在这里）。这个变化使得我们可以把大千世界的任何东西，都“投影”到万维网上，每个东西都有URI，都有对这件东西的描述（元数据）以及用数据表达的这件东西，这样，万维网就变成了一个数据的世界，其实构成了一个波普尔所称的第三世界（在我看来，这个概念和URI体系可以应用到物联网）。
可以看到，URI同时解决了命名问题和定位问题，然而在具体实现URI命名和定位时，该名称还有永久性和易实现的要求，路径作为某个“东西”的名称的一部分，就不能允许轻易发生改变，并且不同的软硬件平台和技术环境下都能够正确编码，这就是CoolURI的由来。
同时对于同一个对象，必须允许有不同的描述与表达方式，例如对于上面kevenlw的描述，既要有html文件（php可以认为是动态生成的html文件），通过浏览器显示给人看，又要有rdf文件描述kevenlw的各种性状属性以便机器获取相关元数据信息，如foaf文件：http://www.kevenlw.name/kevenfoaf.rdf。这两个文件其实描述的是同一个“东西”，因此不应该有不同的ID标识（注意：在这里是两个不同的URI，这是不规范的），必须在一个URI中区分这两类数据，同时让服务器有一种机制，能够自动地根据请求方的不同，传送不同格式的数据。
（下一篇再讲采用303转向和hash“#”两种实现方案各自的特点）。
Popularity: 26% [?]
Tags: URI, 关联数据, 文档的Web, 语义Web, 语义技术Related posts
什么是“关联数据”（定义进阶）？
以下针对不同知识背景的读者，分别给出了不同详略程度和专业程度的解释，供参考（并请提出意见）：
1、普通网民（知道如何上网，希望对一些网络知识做一般性的了解）
关联数据是一种由国际互联网协会（W3C）推荐的数据规范，用来联接和发布各类数据、信息和知识，使互联网上的服务器能够基于内容进行检索而不是简单的全文检索（文字相同但含义不一定一样，会检出很多不准确不相关内容），从而更准确地分享和关联信息。
2、普通图书馆员（非IT相关专业大专或本科毕业，能利用网络查找信息或为读者提供服务，懂得MARC是一种元数据）。
关联数据是按照一定方法发布的数据，它直接以每个数据的网址作为它的名称（即其中只包含字母数字和左斜杠），并且数据不是一般的网页文件，而是由字段组成的元数据记录，字段描述中通常包含到其它数据的链接。
3、资深编目员或中级职称以上自动化系统管理员（长期从事编目工作或ILS维护工作，了解国际编目规范和图书馆相关技术的最新进展，参加过元数据相关知识培训或从事过相关研究）。
关联数据是按照一定方法发布的数据，它直接以每个数据的网址作为它的名称标识（即名称中只包含字母数字和左斜杠），并且包含以RDF/XML格式描述的元数据信息。由于RDF数据里包含了指向其它RDF数据的链接，因此能形成富含元数据信息的数据关联。
4、Web应用开发人员（具有IT知识背景，熟知最新Web技术，参与过Web应用的开发）
关 联数据是任何资源在万维网上发布的一种方式，以HTTP URI方式链接到一个以RDF/XML编码的数据对象，而不是一个其它任何格式的文档。其中URI决定了数据的唯一性和“可关联”性，RDF确立了数据的 语义和链接的实体。RDF文件中应该包含更多的由URI所标识的其它资源，即尽可能不使用“空节点（blank nodes）”少使用“普通文字（literal）”，并且包含以RDF/XML格式描述的、规范格式的元数据信息。空白节点(Blank node)是指没有全局ID的本地资源(没有定义命名域的URI,如ISBN, DOI)，文字(Literal)指一个字串值(可以有类型以及语言属性)
5、语义Web研究者（熟知语义Web技术，有志于为互联网带来图书馆的知识服务）
关 联数据是由Web的发明人Tim Berners-Lee提出的一个概念，定义了一种URI规范，使得人们可以通过HTTP/URI机制，直接获得数字资源(Thing)，从而实现一种 Web上的富链接机制。从本质上看，关联数据是将超文本链接（即文件之间的链接）转变为超数据链接（事物Thing之间的链接）。
TBL认为关联数据是实现Data Web的关键技术，应符合四个原则：
- 使用URI作为任何事物的标识名称，不仅是标识文档；
- 使用HTTP URI，使任何人都可以参引(dereference)这一全局唯一的名称；
- 当有人访问名称时，以RDF形式提供有用的信息；
- 尽可能提供链接，指向其它的URI，以使人们发现更多的相关信息。
Popularity: 27% [?]
Tags: linked data, 关联数据, 定义, 数字图书馆, 语义技术