Knowledge Graph知识图谱—9. Knowledge Modeling

2024-03-22 07:40

本文主要是介绍Knowledge Graph知识图谱—9. Knowledge Modeling,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

9. Knowledge Modeling & Ontology Engineering

How should the knowledge in a KG be modeled?
– Which classes of entities do we have?
– Which relations connect them?
– Which constraints hold for them?
→ these questions are defined in the ontology of the knowledge graph

How we have built ontologies so far
– Read the requirements
– Pick a starting point at random
– Start playing around in Protégé
– Trial and error driven

That was rather “Ontology Hacking” than “Ontology Engineering”

How to build ontologies?
Methodologies

How to build good ontologies?
– Best Practices
– Design Patterns
– Anti Patterns
– Top Level Ontologies

The SECI Model
Two type of knowledge
Tacit Knowledge
intuitive, hard to formalize
e.g., riding a bike, playing improvised music
Explicit knowledge
formalized
e.g., kinematics, music theory
Tacit knowledge is created from explicit knowledge and vice versa. Knowledge creation is usually a cooperative process
Knowledge creation
SECI 模型,也被称为知识转换模型,它描述了组织内知识创造和转换的过程。SECI 代表社会化(Socialization)、外部化(Externalization)、结合(Combination)、内部化(Internalization)。
社会化(Socialization):
这种模式涉及通过直接互动和共同经验分享隐性知识。隐性知识是个人的、难以形式化的,比如技能、洞察力和直觉。社会化发生在个体相互作用、观察和相互学习的过程中。这个模式强调通过社交活动(如导师制度、学徒制度和共同经验)进行学习。
外部化(Externalization):
外部化是将隐性知识表达成明确概念的过程。它涉及将个体的隐性知识转化为可以被传达和理解的共享概念和模型。这种模式通常采用叙述、隐喻或类比的方式,将内隐的知识转化为明确、可传达的形式。
结合(Combination):
在结合模式中,明确知识被组合和组织。这涉及对明确知识的系统收集、分类和重组。结合的目标是通过以有意义的方式组织现有的明确知识来创造新的知识。这个模式通常通过创建数据库、手册或其他结构化的知识库来实现。
内部化(Internalization):
内部化是将明确知识体现为隐性知识的过程。在这个模式中,个体获得明确知识并通过将其应用和整合到个人隐性知识中来内部化。这涉及通过实践、操作和获得个人经验来学习。内部化通过将明确知识重新转化为个体的隐性知识来完成循环。

9.1 Methodologies

方法论(Methodology)是指研究、学科或领域内,用于解决问题、推进研究或实施工作的一套原则、规范、程序、技术和方法的体系。它是一种系统性的、有组织的方法体系,用于引导人们在特定领域或活动中进行系统、科学、可重复的工作。

9.1.1 Grüninger & Fox’s Methodology

Grüninger & Fox’s Methodology 是一种用于本体建模的方法论,特别关注于描述和表示领域知识的形式化。
Grüninger & Fox’s Methodology

9.1.2 Methontology

Grüninger & Fox’s Methodology
Step by step from less to more formal ontologies
Stepping back is allowed
Documentation is produced along the way
Glossary: Terms, descriptions, synonyms, antonyms
Taxonomy: Sub class relations
Ad hoc binary relations: a.k.a. ObjectProperties
Concept dictionary contains: terms, descriptions, relations, instances (optional)

9.1.3 OntoClean

Methodology
A collection of analysis methods and tests
– Does my class hierarchy make sense?
Rule1: Rigidity
OntoClean distinguishes rigid and non-rigid classes
If an entity belongs to a rigid class, this holds once and for all, i.e.: if the entity does not belong to that class anymore, it ceases to exist
This does not hold for non-rigid classes
Examples for rigid classes: Person, mountain, company
Examples for non-rigid classes: Student, stock company, town, Caterpillar and butterfly

OntoClean rule: Rigid classes must not be subclasses of non-rigid classes

OntoClean1
OntoClean2

Other typical rigidity problems
PhysicalObject > Animal
An entity may die and thus be no longer an animal. If we consider “living” as necessary for animals. The physical object (i.e., the body), however, still exists.

Rule2: Identity
Identity1

Let us look at some instances
– :1h a :Duration . :2h a :Duration . …
– :Mo10-11 a :Interval . :Mo11-12 a :Interval . …
Obviously, there are more instances of Interval than there are instances of Duration [contradiction]

How do we know that two entities are the same?
Some classes have criteria for identity
• Immatriculation number of students
• Tax number for citizens and companies
• Country codes
• …

Identity2

Identity3

Identity4

Observation: The identity criteria are of the two classes are different

OntoClean rule: If p is a subclass of q, then p must not have any identity criteria that q does not have

Identity5

Identity6

Rule3: Unity
For some classes, entities can be decomposed into instances of the same class. We call them “anti unity classes
Examples:
An amount of water into two amounts of water
A group into two sub groups

Other classes only have “whole” instances → “unity classes”, e.g., people, cities
For “whole” individuals, there is always a functional relation unambiguosly relating a part to the whole
Examples:
relating a body part to a person
relating a district to a city
Unity1

Unity2

Unity3

OntoClean rule: Unity classes may only have unity classes as their subclasses. Anti unity classes may only have anti unity classes as their subclasses
In our example:
– OrganicMatter is an anti unity class
– Animal is a unity class

Unity4
Unity5

Summarizing OntoClean
A number of tests that can be carried out on ontologies
– Rigidity, Identity, Unity
– Reveal possible mismodeling issues
– Avoid nonsensical reasoning consequences

9.2 Ontology Design Patterns

Origin of the term “design pattern”
Architecture
– Recurring problems
– Standard solutions with certain degrees of freedom

Example
– Problem: rain falls into the building
– Solution: roof
• Degrees of freedom: shed roof, saddle roof, hip roof…

Types of Ontology Design Patterns

  • Presentation Patterns, e.g., naming conventions
  • Logical Patterns: Domain independent, Always specific to a language (e.g., OWL DL)
  • Content Patterns: Domain dependent and Language independent
  • Transformation Patterns (e.g., how to transform an ontology from one language to the other)

9.2.1 Presentation Patterns

Presentation Patterns

9.2.2 Logical Patterns

Logical Patterns

9.2.3 Content Pattern

Content Pattern

9.3 Anti-Patterns

Things that should not be done. But are often done and cause some problems.
Possible causes
– Not thought about each and every consequence
– Little/wrong understanding of RDF/OWL principles

Rampant Classism
Anti Pattern: Rampant Classism1
Anti Pattern: Rampant Classism2

How to distinguish classes and instances?
For every class, there must be (one or more) instance(s)
– What should be instances of Goethe?
– Are there any sentences like “X is a Goethe”?
Sub class relations must make sense
– Pattern: “Every X is a Y”
– “Every Goethe is a Writer”?
No, so Goethe is not a sub class of writer.

Exclusivity
Exclusivity1

Exclusivit2

What is happening here?
Ontology was built exclusively for a domain, e.g., cities. Breaks if used in another context (here: countries)

Semantic Web Principles
AAA (Anybody can say Anything about Anything) i.e., statements should work in different contexts

Another example:
Every person is married to at most one other person

Exclusivity3

9.4 Classification of Ontologies

Classification of Ontologies

9.4.1 Top Level Ontologies

Top Level Ontologies (Very general)

  • Domain independent
  • Task independent
    Goal
  • Reuse
  • Semantic clarity
  • Modeling guidance (i.e., avoid bad modeling)
  • Interoperability

Aristotle’s Ontological Square
One of the oldest top level ontologies
Aristotle's Ontological Square

Basic Categories for Top Level Ontologies
Abstract vs. concrete entities
Abstract entities do neither have a temporal nor a spatial dimension, eg. Numbers, Units of measure
Concrete entities do at least have a temporal dimension,i.e., a time span at which they exist (spatial is optional), e.g. Things (books, tables, …), Events (lectures, tournaments, …)

3D vs. 4D view
3D view: Things extend in space. At every point in time, they are completely present

4D view: Things extend in time and space. At a given point in time, they can also be partially present

Actual vs. possible entities
Actualism: only existing entities are included in an ontology
Possibilism: all possible entities are included in an ontology

Co-location
Can multiple entities exist in the same place?
This should be easy…
– 3D view: no
– 4D view: yes, but not at the same time
…but it is not that trivial

Example: a statue and the amount of clay from which it was made
Do statues even exist?
– Or is there only clay in the shape of a statue?
– …and if both exist, should they belong to the same category?

– Another example: a hole in a piece of Swiss cheese
Do holes even exist? Or are there only perforated objects?

John Sowa’s Top Level Ontology
An “older” top level ontology (1990s)
Three distinctions form twelve basic categories

Physical vs. Abstract
Physical: Things that exist in time (and potentially in space)
Abstract: Things that do not

Continuant vs. Occurent
Continuant: Things that exist as a whole at each point in time
Occurent: Things that partially exist at each point in time (a lecture)

Independent vs. Relative vs. Mediating
Independent: Things that can exist on their own
Relative: Things that require other things to exist
Mediating: “Third” things that relate two others

John Sowa's Top Level Ontology1

John Sowa's Top Level Ontology2

DOLCE
Descriptive Ontology for Linguistic and Cognitive Engineering
One of the most well known top level ontologies

Particulars, universals, and quantities
Universals (think: categories): can have instances
– “City”, “University”
Particulars (think: individuals): cannot have instances
– “Mannheim”, “Mannheim University”
Qualities: describe an instance
– e.g., color of a book, height of a person
– Are neither particulars nor universals
– Cannot exist without an instance

A top level ontology of particulars
For both actual and possible entities (possibilistic view)

4D: Some entities may have a temporal dimension

Co-location
Is allowed
restriction: not two entities of the same kind at the same spatial and temporal location
Not: two statues But: a statue and an amount of clay

Top Hierarchy of DOLCE
Top Hierarchy of DOLCE

Endurants vs. Perdurants
Endurants exist in time
Think: things like people, books, … May also be non-physical: organizations, pieces of information
Are always fully present at each point in time during their existence

Perdurants “happen” in time
Think: events and processes
Only exist partially at each point in time during their existence, i.e., previous and future parts of the perdurant may not (yet|anymore) exist at a given point in time

Qualities are attached to endurants and perdurants

Abstracts: numbers, units of measure, etc.

Endurants take part in perdurants
– Actively (Reader and reading)
– Passively (Book and reading)
– DOLCE defines various types of participation

Endurants only consist of endurants, perdurants only consist of perdurants
– Books consist of pages, cover, …
– Reading consists of perceiving, turning pages, …

Endurants in DOLCE
Endurants in DOLCE1

Endurants in DOLCE2

Distinguishing Endurants
Amount of Matter vs. Phyiscal Object
Amount of Matter is “mereologically invariant”, i.e., a part of an AoM is still an AoM
• A part of “some water” is still “some water”
• But a part of a cup is (likely) not a cup
– cf. unity/anti unity in OntoClean

Features
Cannot exist without a physical endurant, e.g., holes, fringes

Perdurants in DOLCE
Perdurants in DOLCE

Distinguishing Perdurants
Distinguishing Perdurants1
Distinguishing Perdurants2

Qualities
Basic distinction
Quality is a property of an entity
Quality space is the set of possible values of the quality

Qualities need entities
In general, all particulars can have qualities. Qualities only exist as long as the entity exists

Qualities

9.4.2 Other Top Level Ontologies

SUMO: Suggested Upper Merged Ontology
– Around 1,000 classes
– Strong formalization in KIF (Knowledge Interchange Format)
Cyc: stems from EnCyClopedia
– Own language (CycL)
– Top Level and deep general ontology
– ~250,000 classes
– OpenCyc: discontinued, but still available
PROTO: PROTo ONtology
– General top level+ upper level, different domain extensions
– ~300 classes, ~100 relations
Comparison

Example: Usage of DOLCE for DBpedia1

Example: Usage of DOLCE for DBpedia2

Wrap-Up

这篇关于Knowledge Graph知识图谱—9. Knowledge Modeling的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/834847

相关文章

Java架构师知识体认识

源码分析 常用设计模式 Proxy代理模式Factory工厂模式Singleton单例模式Delegate委派模式Strategy策略模式Prototype原型模式Template模板模式 Spring5 beans 接口实例化代理Bean操作 Context Ioc容器设计原理及高级特性Aop设计原理Factorybean与Beanfactory Transaction 声明式事物

sqlite3 相关知识

WAL 模式 VS 回滚模式 特性WAL 模式回滚模式(Rollback Journal)定义使用写前日志来记录变更。使用回滚日志来记录事务的所有修改。特点更高的并发性和性能;支持多读者和单写者。支持安全的事务回滚,但并发性较低。性能写入性能更好,尤其是读多写少的场景。写操作会造成较大的性能开销,尤其是在事务开始时。写入流程数据首先写入 WAL 文件,然后才从 WAL 刷新到主数据库。数据在开始

系统架构师考试学习笔记第三篇——架构设计高级知识(20)通信系统架构设计理论与实践

本章知识考点:         第20课时主要学习通信系统架构设计的理论和工作中的实践。根据新版考试大纲,本课时知识点会涉及案例分析题(25分),而在历年考试中,案例题对该部分内容的考查并不多,虽在综合知识选择题目中经常考查,但分值也不高。本课时内容侧重于对知识点的记忆和理解,按照以往的出题规律,通信系统架构设计基础知识点多来源于教材内的基础网络设备、网络架构和教材外最新时事热点技术。本课时知识

【Python知识宝库】上下文管理器与with语句:资源管理的优雅方式

🎬 鸽芷咕:个人主页  🔥 个人专栏: 《C++干货基地》《粉丝福利》 ⛺️生活的理想,就是为了理想的生活! 文章目录 前言一、什么是上下文管理器?二、上下文管理器的实现三、使用内置上下文管理器四、使用`contextlib`模块五、总结 前言 在Python编程中,资源管理是一个重要的主题,尤其是在处理文件、网络连接和数据库

UML- 统一建模语言(Unified Modeling Language)创建项目的序列图及类图

陈科肇 ============= 1.主要模型 在UML系统开发中有三个主要的模型: 功能模型:从用户的角度展示系统的功能,包括用例图。 对象模型:采用对象、属性、操作、关联等概念展示系统的结构和基础,包括类图、对象图、包图。 动态模型:展现系统的内部行为。 包括序列图、活动图、状态图。 因为要创建个人空间项目并不是一个很大的项目,我这里只须关注两种图的创建就可以了,而在开始创建UML图

dr 航迹推算 知识介绍

DR(Dead Reckoning)航迹推算是一种在航海、航空、车辆导航等领域中广泛使用的技术,用于估算物体的位置。DR航迹推算主要通过已知的初始位置和运动参数(如速度、方向)来预测物体的当前位置。以下是 DR 航迹推算的详细知识介绍: 1. 基本概念 Dead Reckoning(DR): 定义:通过利用已知的当前位置、速度、方向和时间间隔,计算物体在下一时刻的位置。应用:用于导航和定位,

【H2O2|全栈】Markdown | Md 笔记到底如何使用?【前端 · HTML前置知识】

Markdown的一些杂谈 目录 Markdown的一些杂谈 前言 准备工作 认识.Md文件 为什么使用Md? 怎么使用Md? ​编辑 怎么看别人给我的Md文件? Md文件命令 切换模式 粗体、倾斜、下划线、删除线和荧光标记 分级标题 水平线 引用 无序和有序列表 ​编辑 任务清单 插入链接和图片 内嵌代码和代码块 表格 公式 其他 源代码 预

图神经网络框架DGL实现Graph Attention Network (GAT)笔记

参考列表: [1]深入理解图注意力机制 [2]DGL官方学习教程一 ——基础操作&消息传递 [3]Cora数据集介绍+python读取 一、DGL实现GAT分类机器学习论文 程序摘自[1],该程序实现了利用图神经网络框架——DGL,实现图注意网络(GAT)。应用demo为对机器学习论文数据集——Cora,对论文所属类别进行分类。(下图摘自[3]) 1. 程序 Ubuntu:18.04

图神经网络(2)预备知识

1. 图的基本概念         对于接触过数据结构和算法的读者来说,图并不是一个陌生的概念。一个图由一些顶点也称为节点和连接这些顶点的边组成。给定一个图G=(V,E),  其 中V={V1,V2,…,Vn}  是一个具有 n 个顶点的集合。 1.1邻接矩阵         我们用邻接矩阵A∈Rn×n表示顶点之间的连接关系。 如果顶点 vi和vj之间有连接,就表示(vi,vj)  组成了

JAVA初级掌握的J2SE知识(二)和Java核心的API

/** 这篇文章送给所有学习java的同学,请大家检验一下自己,不要自满,你们正在学习java的路上,你们要加油,蜕变是个痛苦的过程,忍受过后,才会蜕变! */ Java的核心API是非常庞大的,这给开发者来说带来了很大的方便,经常人有评论,java让程序员变傻。 但是一些内容我认为是必须掌握的,否则不可以熟练运用java,也不会使用就很难办了。 1、java.lang包下的80%以上的类