网络采用的平台是W3C的IRC实时文本+电话会议方式，平台有两个机器人（Zakim和RRSAgent）可以掌控发言角色，安排顺序，最重要的是能自动生成会议记录，并发布在W3C的网站上。比如这次会议的记录会后马上就经过整理，发布在此：http://www.w3.org/2011/04/28-lld-minutes.html （IRC的记录：http://www.w3.org/2011/04/28-lld-irc）。

因为不舍得拨打国际长途，我通过曾老师用Skype转播参与了会议全过程，通过IRC的文字交谈功能算是参加了讨论和互动。会议时间控制得很好，原计划一个小时，基本上到点就结束了。参加会议的成员来自世界各地，美洲的正值午夜，亚洲的正午，欧洲的还在凌晨。会前大家都必须做好准备，用这种形式推动课题进展，效率极高。

Tom Baker作为DCMI技术应用方向的实际领路人，一直很看重W3C，很有W3C情结。近十年来DCMI的元数据运动离图书馆行业越走越远，随着万维网由技术导向向内容导向的转变，DCMI越来越走向万维网，成为Web语义化和知识化的核心内容之一。这个方向我认为是完全正确的，也是图书馆界的专业知识贡献于网络社会，在万维网上寻求类似定位的必由之路。老Tom在W3C中仍然要扛起图书馆大旗，于去年5月21日牵头成立图书馆关联数据应用的孵化小组（LLD：http://www.w3.org/2005/Incubator/lld/），联合图书馆、博物馆、档案馆等相关领域的关联数据先锋，共同探讨关联数据应用的可能性和巨大潜力，并努力为人们指明方向。。

这个小组凝聚了相关业界（图情博档）的技术精英，然而大家其实都是志愿者，每人都有自己的工作，平时相隔万里，托信息技术和网络社会的恩赐，把大家紧密联系在一起。据曾蕾老师说，基本上每周都召开课题组会议，所有计划、过程、进展、内容、成果都以一定方式在网上公布，其采用的技术工具也并非十分先进，甚至可以看成是网络应用的古董，不外是邮件列表、IRC、电话会议、wiki之类，我们上次召开上图学会第二届图书馆前沿技术论坛（关联数据）还用了非常先进的Cisco公司的WebEx会议系统，这类人士通常只把注意力集中在要做的事情上，对工具的选择有一些基本原则，例如一定要是开源（免得有知识产权等相关法律问题）、足够简单（方便绝大多数人使用）、功能够用并以提高效率为主要目的（额外工作例如后续加工工作尽可能用程序来完成）等等，对于花拳绣腿的功能一般都很漠视。

看起来这个小组的各项研究任务正按计划进行，已经取得了不少进展，然而距离其雄心勃勃的目标，看来还是有相当的挑战。根据其目前的研究框架（下述），点到为止是基本上没有问题的，但是能不能非常准确地拿捏到位，深浅适度且带来共识，还要看最后的结果。但是无论如何，这应该是图书馆相关领域技术应用前沿近年来最重要的进展了，希望不久的将来能够看到其成果集成应用到相应的解决方案中去。

目前的研究框架大致如下：

1. 界定本课题的涉猎范围和主要内容，主要对一些基本概念进行界定，例如什么是本研究中所称的“图书馆”。对每一项研究而言概念界定往往是基础工作，是最重要的，尤其要在参与研究的成员之间达成共识，这样才能避免大家自说自话，最后再回头调整，出来的东西以其昏昏使人昭昭。
2. 阐述应用关联数据技术能够带来的好处（主要向业界同行和“利益相关者”宣示），因为技术的隔阂和对于行业的职能作用及其未来前景的认识的不同。现在看起来这部分很难写，是最具有挑战性的。目前的做法似乎是从几个角度同时展开，从应用领域（图书馆、档案馆、博物馆、网络资源等）、用户角色（研究人员、教授、学生、开发者、机构、客户等）、技术方面的进步以及从用例中总结出来的好处。
3. 现有的词表和数据集。曾蕾老师就主要牵头这部分内容。现在看来好像就这部分内容还比较成熟和确定，梳理得较为完整，但内容和很庞杂，看起来博大精深，选择和介绍到什么程度是个问题。目前似乎分两部分：属性（关系）元素所成的各类模式（元数据集），以及各类取值词表（包括领域模型中的各类实体），前者可以编码为OWL本体，后者可以以SKOS形式发布。
4. 相关实现技术。这也是个挑战，因为关联数据本身是一个Web架构的问题，不是任何具体的技术问题，要实现这个架构可以有多种方式，实现的程度也不一样。具体而言，涉及到数据的转换、重新发布、与内容管理平台的结合、链接的管理维护、OWL等各类编码的实现、与关系数据库的关系、海量三元组存储库的管理、效率问题、SPARQL端点的实现、嵌入HTML（RDFa）的方式和工具等等，这部分目前看起来还很初级，但这部分内容涉及对技术方案的总结和梳理，提到了很多目前普遍采用的工具或方法（如D2RQ），值得尝试。

那么具体在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/kevenliu

2） 采用带井号“#”（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/

任何独立存在的事物都需要有一个标识来表明它的存在，不论这个标识是有意义的还是无意义的，抽象的还是具体的，文字的还是符号或图示的，或者是编码的。

最常用的标识是由语言文字来表达的名字。名字的作用是为了标识，并且有区分的功能，名字的重复和指代对象的不明确对于人脑来说并不构成很大的问题，人通常可 以通过上下文语境或者概念之间的关联，准确判断所指代的对象，但是对于计算机而言就必须明确区分，ID必须具有唯一性，不同的ID一定是不同的东西，即便 可以给它们建立相等的关系，它们也不是一个东西。

当然，这个唯一性是有一定范围的，不是无限的。例如开放的因特网世界，有命名域规则保证名称的惟一性，而封闭的内联网世界，其名称只需要在其内部具有惟一性即可。

远洋师让我介绍一些网络ID，我就介绍一些，不知道符不符合要求，请远洋师和各位同仁批评指正。

其实用两幅图就可以完整介绍因特网上能用到的几乎所有ID。

图一：说明了URI主要分URL和URN两种，其中URL虽然是一种标识，但同时作为可以直接定位的地址，而URN需要局域解析规则进行定位。

如下图二就说明了URI的基本语法（下图来自网络）

有了上面两张图示，就可以明白关联数据所推荐采用的标识是HTTP URI的子集，即CoolURI。HTTP URI其实就等于URL。CoolURI在上一个帖子中介绍过了。另外，OpenURL等地址规范也都符合URI规范。

关联数据的概念想法其实很简单，但同时又很难让人理解，这是个很有意思的现象。是不是可以拿刘谦的魔术来类比，不知道的看不懂，知道了其实都是业内常见的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“#”两种实现方案各自的特点）。

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，以使人们发现更多的相关信息。

Cool URI是某一类URI的习惯叫法，不是正式名称。
最初是针对由CGI程序（包括关系数据库）动态发布在网上的数据地址而言的，由于其地址中通常包含程序调用参数的指示符（？&以及进程线程标识之类），很难保证URI的稳定性（即对于同样的数据，每次发布的地址都不一样）而制定的一种URI命名规范（最佳实践）。
它要求URI只包含0-9，a-z, /, 文件名最后可用#，并希望尽可能使用日期作为目录等等；同时数据名称不用后缀，交由Web服务器重定向。

今天开始，国际语义网大会（ISWC2010）在上海浦东国际会议中心召开，上海交大是东道主。这是继2008年北航主持了 第十七届国际万维网大会（WWW2008）之后，我国又一次召开的同类会议。当然会议的规模要小一些。是不是因为受金融危机影响，这些烧钱的贵族会议纷纷 移师东土，让我一展国威？就不得而知了。08年本想去参加WWW2008的，一打听注册费要一千七（是美刀），还是88了吧。ISWC的收费比WWW便宜 很多，而且有RMB报价：6600，想想还是舍不得一台高配的iPad，两天的培训还要2000元。没人赞助，就在网上看看资料吧。

本届语义万维网大会内容还是很吸引人的，图书馆人熟悉的名词有一大堆，如：本体、元数据、关联数据、应用模型等等，但不知为 什么却没多少图书馆人的身影。找到一个：张智雄，单位写着中科院（无“文献情报中心”或“国家科学图书馆”之类），是元数据委员会的成员。看来图书馆总的 来说还是穷啊！

看了一下会议议程，今明两天的培训（http://iswc2010.semanticweb.org/node/48）除了语义网、OWL2、语义搜索等一般性技术规范的介绍之外，还包括如下主题：

• 本体匹配(OM2010)
• 非确定性推理(URSW2010)
• 使你的语义网应用吸引人的十个法则
• 语义传感网络(SSN)
• 语义网应用于来源管理（provenance）(SWPM)
• 开放关联服务（Linked Open Services: LOS）
• 机构语义库(SERES2010)
• 跨文化和跨语种的语义网(C3LSW2010)
• 如何利用（消费）关联数据
• 电子政府中的关联数据
• 将“数据的Web”与“文档的Web”融合起来（RDFa和Drupal7）
• Web退离规则：基础、应用与标准
• 可扩展的语义网知识库系统(SSWS2010)
• 本体动力学(IWOD-10)
• 网络中的社会性数据(SDoW2010)
• 语义技术的评价(IWEST2010)
• 本体模式(WOP2010)
• 万维网中的资源检索与服务匹配(SMR2)

主办单位：上海图书馆学会学术委员会
协办单位：上海市普陀区图书馆
活动主题：关联数据：技术实现和应用前景
费用：无
会议时间：2010年8月23日13:00-18:00pm
会议地点：普陀区图书馆 大渡河路1800号（铜川路口）12楼多功能会议室

会议日程（执行）：
13:00-13:10 上海市图书馆学会学术委员会主任范并思致辞，普陀区图书馆馆长司颖致辞
13:10-13:40 曾蕾教授远程发言(ppt)
13:40-14:20 林海青 关联数据的功能需求及其实现(ppt)
14:20-15:00 刘  炜 关联数据ABC及近两年来的应用进展(ppt)
15:00-15:40 胡小菁 RDA与关联数据(ppt)
15:40-15:50 休息
15:50-16:15 黄田青 关联数据:语义万维网的新坐标 (ppt)
16:15-16:45 夏翠娟 应用开源内容管理软件Drupal发布关联数据的探索(ppt)
16:45-17:10 张春景 关联数据开放的有关法律问题(ppt)
17:10-17:40 白海燕 基于关联数据的信息组织深度序化初探(ppt)
17:40-18:05 赵  亮 主持远程参会者发言及讨论
18:05-18:06 范并思 会议总结并宣布闭幕

群组资料在此：http://sns.libspace.org/space-mtag-tagid-38.html
会议通知在此：https://docs.google.com/ 或pdf格式：http://sns.libspace.org/

2010图书馆前沿技术论坛：关联数据与书目数据的未来

作者: （美） 亨德勒 / （美） 阿利芒ISBN: 9787115193841 页数: 330定 价: 59出版社: 人民邮电出版社装 帧: 平装出版年: 2009-2-1

本章开始是我真正感兴趣的所在了：本 体建模和本体编码。渐入佳境。

（一）

1. 数据表达（也是一种知识表达）可以基于多种模型，每 种模型可以有多种方法来表达，每种方法也可能有多种编码模式（Schema，如XML模式，数据库模式等）。模式告诉我们所有数据需要传递和表达的信息 （包括结构和语义）。就RDF来说，也有多种等效的方法，但虽然等效，处理方式可能大相径庭，不同的处理方法可能带来不同的“计算”能力（对于语义Web 来说，也是一种推理能力），以及对应于不同的数学运算方式。
2. 例如RDF三元组表达，其本质上是图像（节点-连线图），但RDFS更适合 于用集合来表达。点线图的计算和集合的运算是非常不同的，这两种方法可以看成是模型表达的不同。相对说来，集合运算在数学上是非常成熟的。
3. RDFS 可以看成是领域模型表达成RDF的形式化语言，就是说领域模型中的各类实体关系，都用RDF三元组来表达，写成RDF模式的序列化形式。当然数据实例，也 都是RDF三元组。这一方面降低了RDFS的应用难度（RDF标准在设计时吸取了XMLS的经验），同时却常常使初学者感到迷惑。好在这个迷惑的过程不会 很长。
4. 所谓推理，在这里实际上只是比“检索”前进了一步，即不仅能检索出已经明确表达的知识，而且能够根据规则，判断出没有“显式”表 达出来的知识。应 用到RDF模式，就是不仅能对Asserted Triples进行查询，也能够对Inferenced Triples进行查询。这本来就是RDFS设计的初衷，当然没有问题。当然，如果RDFS本身的表达有问题，有矛盾，通过工具应该是能够检验出来 的，XML模式也可以进行Validation的检查，RDFS当然也行。
5. 传统的描述数据的“模式”都不是存在于模式中，或者以模式的 编码方式存 在。例如关系数据库的“模式”，通常是附注文本，或单独的文件，面向对象的对象模型的“模式”也不是以对象的方式进行描述，早期XML文本描述的DTD定 义，也不是合法的XML文件。目前很多数据格式的定义模式一般都采用与数据格式相同的方式，例如通用Lisp的元对象以及Java对象模型的API自定义 表达都是采用自身相同的语言定义模式，XML Stylesheet，以及XML模式，也采用XML方式进行定义。
6. RDFS引入更多的 “资源”来定义资源和资源之间的关系，定义的这些资源其实只是一个“约定”，本来任何人都可以这样定义，只是W3C作为一个约定，写入了“标准”中去了而 已。
   例如rdf:type只能定义实例的类型，例如《红楼梦》是一本小说：
   [1] ex:红楼梦 rdf:type ex:小说
   其中ex表示定义“红楼梦”和“小说”的命名域。
   如果要定义“小说”（类名）是一种“文学作品”（类名）， 就没有相应的rdf资源元素，W3C扩展了一个rdfs:subClassOf，以及rdfs:superClassOf，可以这样定义：
   [2] ex:小说 rdfs:subClassOf ex:文学作品
   或者：
   [3] ex:文学作品 rdfs:superClassOf ex:小说
7. 当然，要使计算机理解 rdfs:subClassOf和rdfs:superClassOf之间的关系，还需要进一步用到本体定义语言OWL扩展的一个元 素：owl:inverseOf。实际上OWL也是一套对RDF进行扩展的词表，丰富了RDF的语义表达能力。
   继续上面的例子。由[1]和 [2]，就可以推出：
   [4] ex:红楼梦 rdf:type ex:文学作品
   其中 rdf:type，rdfs:subClassOf两个资源之间的语义关系是RDF标准中定义（预设）好的（包括与rdf:superClassOf，以 及这两个资源元素与owl:inverseOf之间的关系），因此机器才能自动做出上述推论。
   这样的推理，类似于编程语言中IF/THEN表达的 语句。
   这其实才是RDF推理。

（二）

除了rdfs:subClassOf之外，RDFS还扩展了许多元素，rdfs:subPropertyOf是其中最重要的一个。
类有子类，也有 属性。属性有子属性。
[5]
ex:著 rdfs:subPropretyOf ex:创作
由：
[6] ex:曹雪芹 ex:著 ex:红楼梦
可以得到：
[7] ex:曹雪芹 ex:创作 ex:红楼梦

建模举例：
某图书馆的工作 人员中有职业的图书馆员，外聘的信息技术人员、外包公司的技术人员以及自由职业者，如果要建立他们与图书馆之间的各类用工关系，该如何做？
首先析 出需要描述的关系：合同关系contractsTo，自由职业freeLancesTo，外包公司indirectlyContractsTo，直接聘用 isEmplyedBy，以及笼统的用工关系worksFor。
所有职员与公司之间的这些关系，其实都是“属性”关系，应该用 rdfs.subPrepertyOf建立起联系。
上述五种属性之间的关系，用工关系包括合同用工和直接聘用，合同用工又包括自由职业者合同和外 包公司合同（用词在这里不一定符合中国法律，但语义就是这个意思）。可以作如下表达：
[8]
ex:isEmplyedBy rdfs:subPropertyOf ex:worksFor
ex:contractsTo rdfs:subPropertyOf ex:worksFor
ex:freeLancesTo rdfs:subPropertyOf ex:contractsTo
ex:indirectlyContractsTo rdfs:subPropertyOf ex:contractsTo

这样，如果：
Keven isEmplyedBy TheLibrary
机器可以得到以下推理：
Keven worksFor TheLibrary

如果：
Marcia freeLancesTo TheLibrary
Raizen indirectlyContractsTo TheLibrary
机 器就可以自动做出下面的推理：
Marcia contractsTo TheLibrary
Raizen contractsTo TheLibrary

属性之间的这种关系定义，在面向对象的编程中是没有对应规定的，这一点需要注意。

（三）

RDFS另外有两个重要扩展：rdfs:domain 和rdfs:range，它们也跟“属性（Property）”元素有关：rdfs:domain关乎属性的主语的取值，rdfs:range关乎属性的 宾语（对象）的取值，都是一种约束（限定），或者说提供了对三元组当属性词（谓语）确定之后，用来描述主语和宾语的限定的扩展元素。

举例说明如下：

[9]
如果属性P的值域（domain）为D，x的P属性是y，那么x的类 型一定是D。可以写为：
IF
P rdfs:domain D
and
x P y
THEN
x rdf:type D

[10]
如果属性P的范围（range）为R，x的P属性是y，那么y的类型一定是R。可以写为：
IF
P rdfs:range R
and
x P y
THEN
y rdf:type R

有 了这两个元素，就能够对于取值范围进行约束，从而可以采用规范词表之类的方法进行取值的规范控制。但是RDFS不能描述某一个实例不属于某个类（这在 OWL中得到了扩展），当定义了P的domain和range之后，如果有“x’ P y’”，不论x’或y’取何值，系统都必然地把它们归入预定的domain和range，加入预设的domain和range（例如规范词表或分类法）中 没有x’或y’的实例，就会发生矛盾，需要另外解决。

进一步，结合rdfs:subClassOf，可以有一些更有意思的推理：
如 果某个属性P有值域D，而值域D是D’的子类，则D’也是P的值域。表示如下：
[11]
IF
P rdfs:domain D
and
D rdfs:subClassOf D’
THEN
P rdfs:domain D’
具体举例：网页（D）是网络资源（D’）的子 类，具有URL的HTML页面（P）是网页（属于值域D），那么也一定是网络资源（属于值域D’）。
这里与面向对象的分析和设计似乎相反，类的属 性不是被子类继承，反而被超类获得。这是Web的特性决定的：属性自身就是资源，不专属于特定的类。

属性交集的例子：
[12]
如 果：
属性P ⊆ R ⋂ S
x P y （x的P属性值为y）
则：
x R y （x的R属性值为y）；
x S y （x的S属性值为y）。

（四）

例子：
甲图书馆用 Lib1:borrows表示外借图书，乙图书馆用Lib2:checkedOut来表示，一个Web应用要将他们的外借数据合并，可以采用以下方法等同 这两个属性：
Lib1:borrows rdfs:subPropertyOf Lib2:checkedOut
Lib2:checkedOut rdfs:subPropertyOf Lib1:borrows
然后，让这两个属性共同作为一个属性的子属性：
Lib1:borrows rdfs:subPropertyOf ex:hasPossession
Lib2:checkedOut rdfs:subPropertyOf ex:hasPossession
这样，使用ex:hasPossession就可以获取所有两个图书馆 外借图书的数据了。

这种方法可以用来整合多个不同的元数据方案。例如，用DC元数据元素作为“核心集”时，MARC等不同元数据方案中的 诸如ex:author，ex:editor之类的元素，都可以 subPreportyOf dc:creator，就可以支持DC标准作为统一查询的元数据标准了。

不用作推理的RDFS元素还有如下一 些：rdfs:label（给定一个显示 名），rdfs:seeAlso（交叉参考），rdfs:isDefinedBy（定义主体），rdfs:comment（注释）等等。

总结一下：

RDFS是用来描述RDF的模式语言，主要提供了定义类（class）、类与类之间的关系（subClass）、属性 （property）、属性之间关系（subProperty）的方法，并规定了简单的、基于集合理论的类继承规则，以及属性继承规则。可以看出RDFS 对RDF的上述扩展，也是完全基于RDF的（全都是三元组），这也保证了RDFS可以像RDF一样，具有同样的开放性，任何人都可以用来定义任何RDF模 式。

虽然RDFS引入了值域和范围，用来限定资源类的属性取值，增加了RDFS的复杂性，但RDFS仍然是非常简单的，没有多少内容。也因 为此，它的适用面和能力是非常强大的。当然如果要表达更为丰富的语义和推理关系，还需要从规则表达（如OWL和SKOS）和词表（如SKOS、FOAF、 DC等等）两方面进行扩展。任何元数据方案以及本体模式，都是组成语义网标准规范体系中的成员，都是对语义网的贡献。

作者: （美） 亨德勒 / （美） 阿利芒ISBN: 9787115193841 页数: 330定 价: 59出版社: 人民邮电出版社装 帧: 平装出版年: 2009-2-1

第 一章 什么是语义万维网

1. 这的确是一个很难向普通人解释的问题，我们来看看两位大师是怎么做的。
2. 首先他们介绍了 本书的主题：关于语义万维网 和本体建模。语义万维网顾名思义，肯定是关于万维网的，而且要表达语义。语义按照一般的解释，就是自然语言所表达的含义。本体建模为什么有必要谈呢，主要 是因为W3C固然搞了一大套东西，但不同的工匠做出的活儿肯定是不同的，本书是要教导你做出漂亮的活，而不是粗糙的、仅仅符合W3C那些定义的活。
3. 然 后解释了Web的伟大意义，即任何人可以在上面就任何话题说任何话，即AAA口号(Anybody can say Anything about Any topic)。这正是Web的魅力和价值所在。万维网的价值与它参与者的数量和资源数 量成正比，万维网的魅力就在于它是一个不断增长的有机体。那么语义Web又能做什么东东呢？作者举了两个Web应用例子（涉及到四个网站），一个是会议旅 馆信息不同步，一个是冥王星被驱逐出太阳系九大行星行列之后，一些网站的信息同步问题。作者在后文中还会用到这两个例子。
4. 通过这两个例 子，说明目前的Web是有很大缺陷的，同时说明，语义Web就是要解决这些个问题。作者称之为“聪明的Web和傻Web”的问题。
5. 接 着作者探讨了如何使Web变得聪明，在现有的Web架构中，你不可能提供一个集中式的管理方法，或者架构，使其“聪明”起来，任何这种企图在开放的、分布 式环境下都是不可能的，不仅是经济上不可能，操作上也不可能。所以作者对“聪明”的Web有一个定义，就是需要把数据在适当的时候，以适当的方式呈现出 来。语义Web的架构只要实现这个，就够了。
6. 然后作者又对“聪明的程度”作了探讨，聪明并不意味着绝对正确，不可能存在绝对真理，语义 网“容错”是一个关键问题，如何容错，如何继续允许AAA，同时建立自己的过滤和“权威”审定机制，也是这个架构设计中的重要方面。目前主要采用唯一的 URI命名来共存，以及采用RDFS标注来说明概念间的关系。

第二章 语义建模

1. 首先介绍了模型的概念：对事物的抽象，隐藏细节、反映概貌，以及模型的作用：沟通、解释预测以及协调不同意见。
2. 模 型描述用自然语言在人和人之间交流，比通过计算机交流，要容易得多。人类的交流通常隐含了很多前提条件（语境），例如知识、文化、科技、宗教背景。当然， 也会因此而造成理解程度的差异。
3. 整个一章基本上是围绕模型的三个功 能：communication，explanation/prediction，mediating来写，最后着重说明了如何表达异见、以及表达能力有 高有低等问题。

第三章 RDF－语义Web的基础

1. 首先提出，语义Web所涉及的语义，不同于符号语义学很复杂的东西，而仅仅是为所涉及的“资 源”给出了一个链 接，作为资源名（即URI）。实际上给出了语义Web一个基本假设：链接即语义。有了这样一个URI，任何指代的东西就有了根据，通过这样一个基本的三元 组的建立，使得认知三角形得以成立（实际上是这样一个认知模型），从而提供了逻辑的结构基础（砖块）：三元组构成的判断式，从而所有的推理运算可以在此基 础上展开（例如一元谓词逻辑的所有计算，最简单的等同计算，以及通过RDF建立关系链接能够表达的所有关系计算——超类，子类，以及通过OWL描述逻辑能 够进行的更复杂的计算，如“非”等等）。
2. 本章通过一个莎士比亚戏剧作品的年 表，展示了如何从关系数据库的表单结构表达的隐含语义，转化为分布式Web网络环境上可被获得的三元组链接。这也印证了人们对语义Web的一个通常的说 法：语义Web就是分布式环境下的关系数据库。介绍了表达三元组的技术细节（如说明了采用qname的URI由怎样的两部分组成）。本章的最后提了本书的 第一项“挑战”（Challenge，类似于作业或操练，不过紧跟着就提供了答案和讨论，非常有启发）：把一个关系表转化为RDF表达。这是很有特色的一 种写法。最后还讨论了高阶（逻辑）关系和三元组（RDF）的其它表达（序列化）形式：N-Triples, Notation 3(N3), RDF/XML, 空节点（Blank Nodes）

第四章 语义Web应用架构

1. 首先解释了在这样一本以“建模”为题的著作里，为什么要介绍“架构”（Architecture）， 因为这本书同时也 是for working ontologist，要具有实用性。为了解释如何使用，必须要介绍语义Web的高层架构、组成、内容（输入inputs）及来自何处、以及如何用到 RDF的优点、与其他架构的不同之处，等等。
2. 支持语义网应用的软件主要有以下几类：
   • RDF解析器 （Parser）/序列化工具（Serializer）；
   • RDF 库（Store，又称三元组库：Triple Store）；
   • RDF 查询引擎（Query Engine）；
   • 各种专门应用（Application），如后面介绍的转换器、刮擦器等等。
3. 目 前实现所有语义Web应用的底层技术还是以关系型数据库为基础的Web三层应用模式，只是其中增加了语义处理的内容，如查询部分需传递SPARQL语句， 处理和存储部分都需要支持RDF三元组数据，等等。
4. 本 章后面其实没讲什么“架构”，都讲各类语义应用/软件了，例如：转换器converter/刮擦器scraper（指从HTML网页或传统应用中获取语义 信息——通常是RDF数据——的工具，当然可以通过各类微格式或其他准标准文档格式进行“刮擦”，通常需要编写GRDDL来实现）；RDF库的互操作解决 方案；查询和提问标准及其与SQL的比较；基于RDF的门户等，最后对于跨库的数据合成（特别是动态合成，类似于Mashup）。

1. 上来就引述第一章讲到“傻瓜数据”时所举的例子：“傻瓜 数据如何基于更多的互联关系而使Web上的应用更聪明”（how a more connected Web infrastructure can result in behavior that lets smart applications perform to their potential）。其实当时也没怎么看懂，姑且继续往下看去。
2. 基 于RDF的数据整合最大的好处，是保证分布式环境中数据的一致性（consistency）。数据的整合视图可以通过整合数据和整合提问两种方式得到，整 合提问通常需要架构的支持，并且需要适当的提问构建工具/环境以方便构建整合视图。
3. 前文中“衣物和衬衫”的例子可以用规范词表的形式来 解决，如规定衣物是衬衫的上位概念，这样在查询衣物时，它的所有下位概念都会出来。这也是一种推理。
4. 著名的语义Web堆栈图已经充分说 明了提供推理支持的语义网架构，这个架构是基于RDF，以及以RDF为基础的描述模式的。
5. 推理引擎能够判断并未描述出来 的逻辑，不同的引擎判断的能力不同，RDFS和OWL的引擎就有所不同。
6. 对于RDF库来说，有两种方式支持推理：Asserted triples和Inferenced triples，其区别类似于实时索引和物理索引的区别，极端的情况是，要么把所有能够推理出的三元组全部都罗列出来，放入库中，要么能不放都不放，所有 的三元组查询都通过规则实时导出。前者利用空间节省时间和计算能力，后者利用计算能力而节省了空间却牺牲了时间。对这两种做法进行动态更新时会碰到不同的 问题，在实际应用中，很难说那种更好，一般都采取折中的做法。