《Ontology Matching》：深度探索本体论匹配的理论与实践

需积分: 9 170 浏览量更新于2024-07-22 收藏 2.08MB PDF 举报

《Ontology Matching》是一本由Jérôme Euzenat和Pavel Shvaiko合著的专业书籍，专深入探讨了本体论领域的重要议题。本体论（Ontology）是计算机科学中的一个重要分支，它关注的是如何理解和表示概念以及它们之间的关系，常用于知识管理、信息集成、语义网等领域，以支持更高效的信息共享和理解。本书的主要内容围绕着本体论匹配（Ontology Matching）展开，这是一个复杂而关键的任务，旨在找出不同本体或数据源中的相同或相关概念，并建立映射关系，以便于跨系统间的知识交流和融合。在实际应用中，如医疗信息共享、教育资源整合或者企业数据标准化，准确的本体论匹配能够显著提高信息的可访问性和一致性。书中包含67幅图示和18个表格，这有助于读者直观地理解复杂的理论概念和技术方法。两位作者以其丰富的经验和专业知识，从理论基础到实践应用，全面地讲解了本体论匹配的各种策略、工具和挑战，包括基于规则的方法、基于实例的方法、自动化的匹配技术和策略选择等。此外，本书还遵循了国际学术出版的标准，被收录于美国国会图书馆的分类目录，并获得了ACM Computing Classification（1998）中的H.3（知识工程）、H.4（数据库理论）和I.2（人工智能）等多个分类，以及F.4（软件工程）的相关标签，显示了其在学术界的广泛认可和重要性。版权方面，本书受到德国版权法保护，所有权利均保留，任何复制、重印或传播行为必须得到Springer出版社的明确许可，以确保知识产权的尊重。对于任何未经许可的复制行为，都将可能面临法律追责。《Ontology Matching》是一本不可或缺的参考书，对于研究者、开发人员和对本体论有兴趣的专业人士来说，它提供了一个全面且深入的学习平台，帮助他们理解和解决实际问题，推动信息技术的发展。

Applications

Matching models is an important operation in traditional applications, such as ontol-

ogy integration, schema integration, or data warehouses. Typically, these applications

are characterised by heterogeneous structural models that are analysed and matched

either manually or semi-automatically at design time. In such applications matching

is a prerequisite of running the actual system.

A line of applications that can be characterised by their dynamics, e.g., agents,

peer-to-peer systems, web services, is emerging. Such applications, contrary to tra-

ditional ones, require (ultimately) a run time matching operation and take advantage

of more explicit conceptual models.

In this chapter we ﬁrst present some well-known applications where matching

has been recognised as a plausible solution for a long time. These are ontology

engineering (§1.1) and information integration, including schema integration, cat-

alogue integration, data warehouses and data integration (§1.2). Then, we discuss

some recently emerged new applications, such as peer-to-peer information sharing

(§1.3), web service composition (§1.4), autonomous communication systems, includ-

ing agents and mobile devices communication (§1.5), and navigation and query an-

swering on the web (§1.6). Finally, the legends to the ﬁgures illustrating scenarios

under consideration can be found in Appendix A.

1.1 Ontology engineering

A context where users are confronted with heterogeneous ontologies is ontology

engineering, and, more generally, the task of designing, implementing and maintain-

ing ontology-based applications. This activity requires support of ontology matching

because ontology engineering has to deal with multiple, distributed and evolving

ontologies.

10 1 Applications

1.1.1 Ontology editing and import

Ontology heterogeneity may be ﬁrst faced while designing an ontology for a domain

of interest. Ontology-based system designers often have to integrate different ontolo-

gies, either for the sake of enforcing reuse, and thus not multiplying ontologies on the

same topic, or because it is necessary for interconnecting various relevant resources.

It is often the case that application engineering requires an external set of on-

tologies to be put together. For instance, building a library cataloguing ontology may

require assembling ontologies for

people, books and topics as well as ontologies for

measurement units, geographic coordinates, book identiﬁcation numbers, metadata

ontology

, etc. These ontologies share related concepts: for instance, the friend-of-

a-friend (FOAF

) ontology (which can be used as a starting point for modelling

people) offers a document concept that has to be related to the classes of the book

identiﬁcation numbers

ontology.

Ontology engineers need support for (i) identifying the relevant ontologies and

(ii) matching and recording the relations between the entities in these ontologies.

Additionally, they may want to import the identiﬁed ontologies and merge them (in

which case, they will use some axioms generated from the result of the matching

phase) or to use data expressed under another ontology in the application (in which

case, they will generate a mediator from the matching result).

The scenario under consideration is simple because it is static. In fact, ontologies

are encountered at design time and mediators can be built at that moment. Thus, the

application developer can ﬁnd the correspondences and design the necessary trans-

formations manually. Some tools provide support for ﬁnding the correspondences,

for example, Prot

e through the Prompt suite of tools

[

Noy and Musen, 2000

]

Newer ontology development environments will have to take into account, from the

beginning, the existence of multiple ontologies and the need for the mediators be-

tween them.

1.1.2 Ontology evolution and versioning

It is natural that domains of interest, application requirements and the way in which

knowledge engineers conceptualise those by means of ontologies undergo changes

and evolve over time. Moreover, ontology development, similar to software devel-

opment, is often performed in a distributed and collaborative manner. Therefore,

multiple versions of the same ontology, e.g., the Gene ontology

, often exist. Some

applications keep their ontologies up to date, while others may continue to use old

ontology versions and update them on their own. These situations arise because

knowledge engineers and developers usually do not have a global view of how and

where the ontologies have changed. In fact, change logs may not always be available

(which is often the case in distributed ontology development). Therefore, developers

need to manage and maintain the different versions of their ontologies.

http://www.foaf-project.org

http://www.geneontology.org

1.2 Information integration 13

In some concrete information integration scenarios, the common ontology can

be either physically existing or virtual. Below, we discuss these scenarios in some

detail.

1.2.1 Schema integration

Schema integration is the oldest scenario

[

Batini et al., 1986,

Sheth and Larson, 1990, Parent and Spaccapietra, 1998

]

. Suppose that two (or

more) enterprises want to perform either a merger or an acquisition among them.

Ultimately, these enterprises have to integrate their databases into a single one.

Usually, a ﬁrst technical step is to identify correspondences between semantically

related entities of the schemas before merging the databases. This step, known as

matching, is required even if the databases to be integrated are coming from the

same domain of interest, e.g., book selling, car rentals. This is because the schemas

have been designed and developed independently. In fact, people follow diverse

modelling principles and patterns, even if they have to encode the same real-world

object. Finally, the schemas to be integrated might have been developed according

to different business goals. This makes the matching problem even harder.

Under the schema integration heading we can classify some other scenarios. For

example, (tightly-coupled) federated databases

[

Sheth and Larson, 1990

]

. These typ-

ically have one global schema providing a uniﬁed access to the federation of com-

ponent databases. Component databases, in turn, are autonomous. Thus, in this ap-

plication when, for example, one component schema of the federated database is

changed, the federated (global) schema has consequently to be also reconsidered.

Matching can help in identifying those changes.

Finally, it is worth noting the applications which we are not discussing here,

e.g., distributed databases systems

[

Ozsu and Valduriez, 1999

]

. These are usually de-

signed in a centralised way, e.g., by a database administrator, and therefore, semantic

heterogeneity does not exist there by construction

[

Elmagarmid et al., 1999

]

1.2.2 Catalogue integration

In Business-to-Business (B2B) applications, trade partners store information about

their products in electronic catalogues. Typical examples of catalogues are prod-

uct directories of electronic sales portals, such as Amazon or eBay. In order for a

merchant to participate in the marketplace, e.g., eBay, it has to determine corre-

spondences between entries of its catalogues and those of the marketplace catalogue

(see Fig. 1.3). This process of ﬁnding correspondences among entries of the cat-

alogues is referred to as the catalogue matching problem

[

Bouquet et al., 2003c

]

Notice that if we look at this problem from a merchant viewpoint, matching has to

be performed for each marketplace it would like to participate. Having identiﬁed the

correspondences between the entries of the catalogues, they are further analysed in

order to generate query expressions that automatically translate data instances be-

tween the catalogues. Finally, having matched the catalogues, users of a marketplace

剩余331页未读，继续阅读

风声2012

粉丝: 268
资源: 30

《Ontology Matching》：深度探索本体论匹配的理论与实践

Ontology_matching:基于机器学习方法的本体匹配

Jerome和Pavel的《Ontology Matching》(2007英文版)

ontology.RAR_ontology_ontology matching_ontology web_semantic se

go富集如何分开ontology

Ontology IRI中填写的新建本体资源的IRI

R语言GO分析ontology

do disease ontology数据库怎么用

请给出这篇文献的标准引用：Toponym Disambiguation using Ontology-based Semantic Similarity

ONTOLOGY ID Description GeneRatio BgRatio pvalue p.adjust qvalue geneID Count这是啥

SWRLRuleEngine ruleEngine = SWRLAPIFactory.createSWRLRuleEngine(ontology);报错.NoRegisteredSWRLRuleEnginesException: no registered SWRL rule engines

最新资源