读斯坦福七步法本体构建
前言
本文是本人读斯坦福发布的七步法构建本体的的基本笔记记录,里面的内容大多为翻译内容通过本人的理解进行了记录,有部分截图直接使用原文中的截图。
斯坦福的本体构建ppt讲解构建过程和本体概念等的介绍
第一章 什么是本体
介绍
-
本体是对领域的显式描述*:概念、概念的属性和属性、属性和属性的约 束、个人(经常,但不总是)
-
对于一个本体的定义:通用的词汇表、共享的理解本体的例子:
网络分类:雅虎(类别)
网购目录:亚马逊(产品目录) -
特定领域的标准术语:统一医学语言系统(UMLS)、UNSPSC -产品和服务术语
-
本体工程的定义-定义领域中的术语及其之间的关系的工程技术:
定义领域(类)中的概念
在层次结构中安排概念(子类-超类层次结构)
定义哪些属性和属性(插槽)类可以具有及其值上的约束
定义个体并填充槽值
第二章 为什么要开发本体
- 共享对信息结构的共同理解
人与人之间
软件代理之间 - 使得领域知识能够重用
避免“重复发明轮子”
引入允许互操作性的标准 - 为了让领域假设明显
更容易更改领域假设(考虑遗传学知识库)
更容易理解和更新遗留数据 - 将领域知识从操作知识中分离出来
分别重用领域知识和操作知识(例如,基于约束的配置) - 本体仅仅是一个开始,接下来基于本体的事情很多
提供一个领域的描述:Software agents、Problem-solving methods、Domain-independent applications
声明一个结构:Databases、Knowledge bases
构建实例(葡萄酒和葡萄酒厂)
第三章 一步一步地开发一个本体
本体开发过程
本教程:确定范围->考虑重用->列举条款->定义类->定义属性->定义约束条件->创建实例
现实:确定范围->考虑重用->列举条款->考虑重用->定义类->列举条款->定义类->定义属性->定义类->定义属性->创建实例->定义类->创建实例->考虑重用->定义属性->定义约束条件->创建实例···········
实际上,我们所进行的创建工作应该是一个不断迭代的过程,此教程将其简化为七步法。
本体工程与面向对象建模
本体
反映了世界的结构
通常是关于概念的结构
实际的物理表示不是问题
某个类结构
反映数据和代码的结构
通常是关于行为(方法)
描述数据的物理表示形式(long int、char等)。
工具
Protégé(是一个图形本体开发工具,支持丰富的知识模型,是开源的,免费可用的(http://protege.stanford.edu)。)
Ontolingua and Chimaera
OntoEdit
OilEd
本教程基于Protégé
确定领域和范围
本体将涉及什么领域?
我们要用本体论做什么?
本体中的信息应该为哪些类型的问题提供答案(Competency Questions:开放式问题)?
这些问题的答案可能在生命周期中发生变化?
Competency Questions(以葡萄酒为例考虑问题)
选择葡萄酒时,我应该考虑哪些特点?
波尔多是红葡萄酒还是白葡萄酒?
赤霞珠和海鲜搭配好吗?
什么酒最适合搭配烤肉?
葡萄酒的哪些特性会影响它适合做一道菜?
葡萄酒的味道或酒体是否会随着年份的变化而变化?
纳帕仙粉黛的好年份是什么?
考虑重用
为什么重用其他本体?
为了节省精力
与使用其他本体的工具进行交互
使用通过在应用程序中使用而验证的本体
如何重用?
本体库
DAML本体库(www.daml.org/ontologies)
Ontolingua本体库(www.ksl.stanford.edu/software/ontolingua/)
Protege本体库(protege.stanford.edu/plugins.html)
上层本体
IEEE标准上层本体(suo.ieee.org)
赛克(www.cyc.com)
通用本体
DMOZ (www.dmoz.org)
WordNet www.cogsci.princeton.edu/~wn/))
特定领域的本体
UMLS语义网
GO(基因本体论)(www.geneontology.org)
列举重要术语
我们需要讨论哪些术语?
这些项的性质是什么?
关于这些项我们想说什么?
列举术语——葡萄酒本体
葡萄酒,葡萄,酒厂,地点,葡萄酒的颜色,葡萄酒的酒体,葡萄酒的风味,含糖量白葡萄酒,红葡萄酒,波尔多葡萄酒食品,海鲜,鱼类,肉类,蔬菜,奶酪
定义类和类层次结构
类是域中的一个概念
一类葡萄酒
一类酿酒厂
一种红葡萄酒
类是具有类似属性的元素的集合
类的实例
你午餐要喝一杯加利福尼亚葡萄酒
类继承
类通常构成一个分类层次结构(子类-超类层次结构)
类层次结构通常是一个IS-A层次结构:子类的实例是超类的实例
如果您将类看作一组元素,那么子类就是一个子集
类继承实例
苹果是水果的一个子类 -----> 每个苹果都是一个水果
红葡萄酒是葡萄酒的一个子类 -----> 每一种红酒都是一种红酒
基安蒂葡萄酒是红葡萄酒的一个子类 -----> 每一瓶基安蒂葡萄酒都是红葡萄酒
层次结构中的级别
层次结构的传递性
is-a关系是可传递的:
B是a的子类
C是B的一个子类
C是a的子类
类的直接超类是类的“最近的”超类
设计开发模式
自顶向下——首先定义最一般的概念,然后专门化它们
自底向上——定义最具体的概念,然后在更一般的类中组织它们
组合——首先定义更突出的概念,然后对它们进行概括和专门化
必备资料
类(和槽)通常有文档
用自然语言描述类
列出与类定义相关的域假设
清单同义词
记录类和槽与记录计算机代码一样重要!
定义类插槽的属性
类定义中的插槽描述类实例的属性以及与其他实例的关系
每种酒都有颜色、含糖量、生产者等。
属性(槽)
类型的属性
“内在”特性:葡萄酒的风味和颜色
“外在”属性:葡萄酒的名称和价格
零件:一道菜中的配料
与其他对象的关系:葡萄酒生产者(酒厂)
简单和复杂属性
简单属性(属性):包含基本值(字符串、数字)
复杂属性:包含(或指向)其他对象(例如,一个酒厂实例)
红酒类的槽位
槽和类继承
子类从超类继承所有插槽
如果葡萄酒有名字和味道,红葡萄酒也有名字和味道
如果一个类有多个超类,它将从所有超类中继承插槽
波特酒既是一种甜点酒,也是一种红葡萄酒。它继承了前者的“含糖量高”和后者的“颜色红”
属性约束
属性约束(facet)描述或限制槽的可能值集
葡萄酒的名字是一串
葡萄酒生产者就是酿酒厂的一个例子
酿酒厂只有一个位置
公共特征
槽基数——槽中值的数量
槽值类型——槽值的类型
最小值和最大值——数值槽的值范围
默认值——除非显式指定,否则插槽具有的值
公共特征:槽基数
基数
基数N意味着槽必须有N个值
最低基数
最小基数1意味着槽必须有一个值(required)
最小基数0表示插槽值是可选的
最大基数
最大基数1意味着插槽最多可以有一个值(单值插槽)
最大基数大于1意味着插槽可以有多个值(多值插槽)
公共特征:值类型
字符串 | 一串字符(“Château Lafite”) |
数字 | 整数或浮点数(15,4.5) |
布尔值 | 真/假标志 |
枚举类型 | 允许值的列表(高、中、低) |
复杂类型 | 另一个类的实例 |
指定实例所属的类 | Wine类是Wine类中的slot“produces”的值类型 |
槽的域和范围
槽的域——具有槽的类(或多个类)
更精确地说:类(或多个类)实例可以具有插槽
槽值的范围——槽值所属的类
特征和类的继承
子类从超类继承所有插槽
子类可以覆盖facet以“缩小”允许值的列表
使基数范围更小
用子类替换范围内的类
创建实例
创建类的实例
类成为实例的直接类型
direct类型的任何超类都是实例的类型
为实例帧分配插槽值
槽值应该符合facet约束
知识获取工具经常检查这一点
例子
第四章 更进一步-常见的问题和解决办法
深度优先覆盖
广度优先覆盖
定义类和类层次结构
需要记住的事情:
没有单一正确的类层次结构
但也有一些指导方针
要问的问题是:
“子类的每个实例都是它的超类的实例吗?”
多重继承
一个类可以有多个超类(superclass)
子类继承所有父类的插槽和方面限制
不同的系统以不同的方式解决冲突
不交类(DISJOINT CLASSES)
如果类不能具有公共实例,则它们是不相交的
不相交类也不能有任何公共子类
红葡萄酒、白葡萄酒、玫瑰葡萄酒是互不相干的
甜酒和红葡萄酒并不是分开的
避免类循环
多重继承的危险:类层次结构中的循环
类A、B和C具有等价的实例集
根据许多定义,A、B和C是等价的
类层次结构中的兄弟
类层次结构中的所有同级必须具有相同的通用性
与书中的章节相比较
完美的类家庭
如果一个类只有一个子类,则可能存在建模问题
如果Red Burgundy 仅有的子类是Côtes d’Or,那为什么要引入子层次结构呢?
与项目符号列表中的项目符号进行比较。
如果一个类有12个以上的子类,则可能需要额外的子类别
但是,如果不存在自然分类,那么长列表可能更自然
单一类名和复数类名
“wine”不是一种“wines”
wine是Wines类的一个实例
类名应该是
所有单数
所有复数
类及其名称
类表示域中的概念,而不是它们的名称
类名可以更改,但它仍然引用相同的概念
相同概念的同义词名称并不是不同的类
许多系统允许将同义词列表作为类定义的一部分
完整的葡萄酒家族
域和范围
当为槽定义域或范围时,查找最通用的类
考虑口味槽
域名:红酒,白酒,玫瑰酒
域:酒
考虑酒厂的生产槽:
适用范围:红葡萄酒、白葡萄酒、玫瑰葡萄酒
范围:酒
定义域和范围
类和超类——用超类替换
类的所有子类——用超类替换
类的大多数子类——考虑用超类替换
Inverse Slots
Maker andProducer
are inverse slots
反槽包含冗余信息,但是
允许在任何方向获取信息
使额外的验证
允许在两个方向上显示信息
实际实现因系统而异
两个值都存储了吗?
什么时候填反数值?
如果我们把连杆换成逆槽会发生什么?
默认值
默认值——当创建一个实例时,slot获得的值
可以更改默认值
默认值是槽的公共值,但不是必需值
例如,wine body的默认值可以是FULL
限制范围
本体不应该包含关于领域的所有可能信息
不需要专门化或泛化应用程序所需的内容
不需要包含类的所有可能属性
只有最显著的性质
只有应用程序需要的属性
本体论的葡萄酒,食品,以及他们的配对可能不会包括
瓶子的大小
标签的颜色
我最喜欢的食物和葡萄酒
生物实验本体将包含
生物有机体
实验者
实验员是生物有机体的一个子类吗?
第五章 语义Web语言中的本体
本体和SW语言
大多数语义Web语言都是为表示本体而显式设计的
RDF Schema
DAML+OIL
SHOE
XOL
XML Schema
SW语言
这些语言各有不同
语法(syntax)
这里我们不关心它——本体是概念表示
术语(terminology)
Class-concept
实例对象
Slot-property
善于表达(expressivity)
我们能用一些语言表达的东西,我们不能用其他语言表达
语义(semantics)
相同的语句在不同的语言中可能意味着不同的东西
RDF和RDF模式类
RDF Schema Specification 1.0 (http://www.w3.org/TR/2000/CR-rdf-schema-20000327/)
RDF(S) Terminology and Semantics
类和类层次结构
所有类都是rdfs:Class的实例
类层次结构由rdfs:subClassOf定义
类的实例
定义rdf: type
属性
属性是全球性的:
一个地方的属性名与另一个地方的属性名相同(假设名称空间相同)
属性也形成层次结构(rdfs:subPropertyOf)
RDF(S)中的属性约束
基数约束
没有显式基数约束
任何属性都可以有多个值
属性的范围属性只能有一个范围
属性的域一个属性可以有多个域(可以附加到多个类)
没有默认值
DAML+OIL:类和类层次结构
类
每个类都是daml: class的一个实例
类层次结构
定义的rdfs: subClassOf
指定类组织的更多方法
剥离(daml: disjointWith)
等价(daml: sameClassAs)
类层次结构可以从类的属性计算出来
在DAML+OIL中定义类的更多方法
联盟的类
A class Person 是男性和女性类的集合
限制属性
类红色的东西是带有颜色的东西的集合:红色
十字路口的类
一个红葡萄酒类是葡萄酒和红色事物的交集
Complement of a class
食肉动物都不是食草动物
元素的枚举
葡萄酒颜色类包含以下实例:红、白、玫瑰
DAML+OIL中的属性约束
基数
最小,最大,准确的基数
属性范围
属性范围可以包含多个类:属性的值必须是每个类的一个实例
如果需要不同的语义,可以指定显式的类联合吗
属性的域-与范围相同
没有默认值
第六章 本体工程的研究现状
本体工程的研究课题
Content generation
Analysis and evaluation
Maintenance
Ontology languages
Tool development
内容: Top-Level Ontologies
“顶级”是什么意思?
对象:有形的,无形的
流程、事件、参与者、角色
代理,组织
空间、边界、位置
时间
IEEE标准上层本体工作
目标:设计单个上层本体
流程:合并现有本体的上层
内容:知识获取(Knowledge Acquisition)
知识获取是一个瓶颈
共享和重用可以缓解这个问题
但我们需要自动化的知识获取技术
语言技巧:从文本中获取本体
机器学习:从结构化文档(例如,XML文档)生成本体
利用Web结构:通过爬虫结构化Web站点生成本体
知识获取模板:专家只指定所需知识的一部分
分析
分析:语义一致性
违反财产限制
类层次结构中的循环
使用但未定义的术语
产生空区间的区间限制(最小>最大值)
分析:风格
只有一个子类的类
没有定义的类和槽
没有约束的槽(值类型、基数)
自动化分析工具
嵌合体(斯坦福KSL)
DAML验证器
评估
本体设计中最困难的问题之一
本体设计是主观的
本体论正确(客观地)意味着什么?
最好的测试是设计本体的应用程序
本体维护
本体合并
拥有两个或多个重叠的本体,创建一个新的本体
本体映射
创建本体之间的映射
版本控制和演化
同一本体的不同版本之间的兼容性
本体和实例数据版本之间的兼容性
本体语言
What is the “right” level of expressiveness?
What is the “right” semantics?
When does the language make “too many” assumptions?
本体工具开发
支持各种本体语言(知识交换)
Expressivity
可用性
越来越多的领域专家参与本体开发
多个括号和变量将不再适用
下一步该走向何处
教程
Natalya F. Noy and Deborah L. McGuinness (2001) “Ontology Development 101: A Guide to Creating Your First Ontology” http://protege.stanford.edu/publications/ontology_development/ontology101.html
Farquhar, A. (1997). Ontolingua tutorial. http://ksl-web.stanford.edu/people/axf/tutorial.pdf
We borrowed some ideas from this tutorial
方法论
Gómez-Pérez, A. (1998). Knowledge sharing and reuse. Handbook of Applied Expert Systems. Liebowitz, editor, CRC Press.
Uschold, M. and Gruninger, M. (1996). Ontologies: Principles, Methods and Applications. Knowledge Engineering Review 11(2)