NeOn: Lifecycle Support for Networked Ontologies

Скачать 340.61 Kb.
НазваниеNeOn: Lifecycle Support for Networked Ontologies
Размер340.61 Kb.
  1   2   3   4   5   6   7   8   9

Error: Reference source not found

NeOn: Lifecycle Support for Networked Ontologies

D2.1.1 Design rationales for collaborative development of networked ontologies – State of the art and the Ontology Design Ontology

Deliverable Co-ordinator: Carola Catenacci

Deliverable Co-ordinating Institution: CNR

Other Authors: Aldo Gangemi (CNR), Jos Lehmann (CNR),

Claudio Masolo (CNR), Malvina Nissim (CNR), Valentina Presutti (CNR)

With Contributions from: Klaas Dellschaft (UKO-LD), Diana Maynard (USFD), Wim Peters (USFD), Marta Sabou (OU), Mari Carmen Suárez de Figueroa (UPM), ……


EU-IST Integrated Project (IP) IST-2006-027595 NeOn

Deliverable D2.1.1 (WP2.1)

Version: V1.0 December 6, 2006

Public draft

We present a state-of-the-art survey and an ontology for the representation of collaborative ontology design of networked ontologies

Keyword list: collaborative ontology design, project, workflow, argumentation, design rationale, design pattern, design choice

NeOn Consortium

This document is part of a research project funded by the IST Programme of the Commission of the European Communities, grant number IST-2005-027595. The following partners are involved in the project:

Open University (OU) – Coordinator

Knowledge Media Institute – KMi

Berrill Building, Walton Hall

Milton Keynes, MK7 6AA

United Kingdom

Contact person: Martin Dzbor, Enrico Motta

E-mail address: {m.dzbor, e.motta}

Universität Karlsruhe – TH (UKARL)

Institut für Angewandte Informatik und Formale Beschreibungsverfahren – AIFB

Englerstrasse 28

D-76128 Karlsruhe, Germany

Contact person: Rudi Studer

E-mail address: studer@aifb.uni-karlsruhe.deUniversidad Politécnica di Madrid (UPM)

Campus de Montegancedo

28660 Boadilla del Monte


Contact person: Asunción Gómez Pérez

E-mail address: asun@fi.upm.esSoftware AG (SAG)

Uhlandstrasse 12

64297 Darmstadt


Contact person: Walter Waterfeld

E-mail address: walter.waterfeld@softwareag.comIntelligent Software Components S.A. (ISOCO)

Calle de Pedro de Valdivia 10

28006 Madrid


Contact person: Richard Benjamins

E-mail address: rbenjamins@isoco.comInstitut ‘Jožef Stefan’ (JSI)

Jamova 39

SI-1000 Ljubljana


Contact person: Marko Grobelnik

E-mail address: marko.grobelnik@ijs.siInstitut National de Recherche en Informatique et en Automatique (INRIA)

ZIRST – 655 avenue de l'Europe

Montbonnot Saint Martin

38334 Saint-Ismier


Contact person: Jérôme Euzenat

E-mail address: jerome.euzenat@inrialpes.frUniversity of Sheffield (USFD)

Dept. of Computer Science

Regent Court

211 Portobello street

S14DP Sheffield

United Kingdom

Contact person: Hamish Cunningham

E-mail address:ät Koblenz-Landau (UKO-LD)

Universitätsstrasse 1

56070 Koblenz


Contact person: Steffen Staab

E-mail address: staab@uni-koblenz.deConsiglio Nazionale delle Ricerche (CNR)

Institute of cognitive sciences and technologies

Via S. Martino della Battaglia,

44 - 00185 Roma-Lazio, Italy

Contact person: Aldo Gangemi

E-mail address: aldo.gangemi@istc.cnr.itOntoprise GmbH. (ONTO)

Amalienbadstr. 36

(Raumfabrik 29)

76227 Karlsruhe


Contact person: Jürgen Angele

E-mail address: angele@ontoprise.deAsociación Española de Comercio Electrónico (AECE)

C/Alcalde Barnils, Avenida Diagonal 437

08036 Barcelona


Contact person: Gloria Tort

E-mail address: gtort@fecemd.orgUnited Nations Food & Agriculture Organization (FAO)

Viale delle Terme di Caracalla 1

00100 Rome


Contact person: Johannes Keizer

E-mail address: johannes.keizer@fao.orgAtos Origin S.A. (ATOS)

Calle de Albarracín, 25

28037 Madrid


Contact person: Jose Lopez

E-mail address: jose.lopez@atosorigin.comWork package participants

The following partners have taken an active part in the work leading to the elaboration of this document, even if they might not have directly contributed writing parts of this document:

Universidad Politécnica di Madrid (UPM)

Open University (OU)

Universität Koblenz-Landau (UKO-LD)

University of Sheffield (USFD)

Universität Karlsruhe – TH (UKARL)

Institut National de Recherche en Informatique et en Automatique (INRIA)


Executive Summary

To be done.

[GENERAL NOTES AND DISCLAIMERS: please read as first thing]

This draft contains most of the material to be includes in the deliverable, but not all of it is presented in a complete form. We are looking forward to your feedback.

Please, note the following:

The overall narrative has changed substantially in order to follow the structure of the ontology.

We still need some more examples Feel free to suggest examples yourselves, they would be extremely welcome.

Bibliography is still incomplete. We are in the process of putting the whole bib into LaTex and fixing this problems.

We have much appreciated your comments so far, and most of them have been implemented. Please, do keep contributing!

Table of Contents

Error! No table of contents entries found.

1. Introduction

1.1 The place of design and collaboration in the NeOn global vision

///Introduce a hands-on-like beginning, e.g.:

Have you ever experienced the stress induced by the blank-page effect when trying to devise what to put into a newly started ontology project? Or, conversely, have you ever experienced the frustration of being unable to import your valuable existing work, previously produced in a non-ontological format, to an ontology? Have you ever got stuck when looking for support to discuss your ontology design choices with a collaborator? And have you ever felt lost when trying to retrieve potentially reusable ontologies, and even conceived which one (if any) is best-suited to your needs? If you ever experienced any of those feelings, you are eligible to read this deliverable, together with the onccming ones in this workpackage. Several tools and methods are being developed in WP2 which attempt to alleviate the pains in the life of an ontology designer, and this deliverable introduces a formal overview of how the functionalities that are implemented in those tools (or in other ones) fit the aspects of collaborative ontology design.

ODO and its dimensions (first, intuitive take)

ODO as a social-level requirement analysis ontology, including functionality descriptions, vs. functionality specifications at the computational-level

The objective of this deliverable is to provide a unifying framework for the creation of models and tools that support the (mainly) collaborative design of ontologies. In order to support a common understanding of the work carried out in Work Package 2 (WP2), the following notions are formalized and linked to NeOn functionalities (presented in section 5):

Revise on the basis of the new outline

design rationale (section 2), networked ontology (section 3), and collaborative design (section 4).

Simply stated, WP2 in NeOn deals with the pragmatics of ontology design in a semantic web, i.e. how ontologies and related data can be built, annotated, evaluated, selected, discussed, lexicalized, and composed in the context of a (web-)distributed, often collaborative, lifecycle.

In particular, WP2 tasks are related to the following use cases of ontology design:

1. How to represent and build an ontology, both from the logical and content-based viewpoints, by using existing ontologies, modules, design patterns, or even informal or semi-formal knowledge objects, such as thesauri, handbooks, linguistic corpora, etc.? (cf. tasks T2.2, T2.5)

2. How to make an ontology functional to a given task, or how to evaluate and select an ontology for a given task? (cf. tasks T2.2, T2.3, T2.5)

3. How to discuss and possibly get consensus on an element or on a design motivation in an ontology? (cf. task T2.3)

4. How to lexically encode an ontology? (cf. task T2.4)

With reference to the other work packages, WP2 takes input from the languages and reasoning support for networked ontologies and contexts coming from WP1 and WP3, takes input from the use case requirements in WP7 and WP8, while interacts with WP4 for human-ontology interaction aspects, and with WP5 for the integration of the design methods developed in WP2.

1.2 Informal description of our approach

A unifying framework for describing ontology design should be general enough to encompass all the approaches that address the questions above, and should also be practical enough to be implemented without creating unnecessary complexity in local solutions, models, and tools. Moreover, it should not be a particular methodology, but should provide enough expressivity to describe different methods or aggregation of methods.

Our proposal is to model ontology design in terms of its objective, scope, components, and support. In the following we provide summary definitions of these terms, and then give four informal comments to questions 1-4 above. This should give the reader a general idea of how this deliverable sets out the treatment of the problems at hand.

1.2.1 Basic notions

The objective of an ontology design helps solving the problem of making choices from the (potentially infinite) choice space offered by the used logical language and available vocabulary. Formulating an objective helps getting started with designing an ontology. In analogy with the ‘blank page effect’ of writers, there exists a ‘blank model effect’, which needs to be dealt with in terms of the objective of the model.

The scope of (web) ontology design is related to establishing what we want to describe the design of. In principle, we could describe the design of any kind of data, process, or resource used or generated during the lifecycle of ontologies over the semantic web: classes, individuals, annotations, email discussions, handbooks, etc. Although our proposal is in principle general and robust enough to support the design of all of these kinds of data, the focus of this deliverable is on ontology design only.

The components of ontology design need to be considered under two perspectives. On the one hand, we should be able to determine what entities should such components be. On the other hand, we should be able to determine how to represent such entities. Listed below are the main types of entities selected so far:

Introduce the actual components of ODO (projects, patterns and choices are missing here). Better explanation of the sections as they are outlined now.

Occorre inserire una spiegazione delle sezioni successive e di come si raccordano con le famose quattro domande, che a loro volta si collegano ai task di WP2, i quali task sviluppano le funzionalità definite rispetto a ODO e descritte nella sezione nuova (4).

Da inserire discussione rivista della nozione di networked ontology, riprendendo da D1.1.1 (vecchia sezione 3)

Ontology element: an (identified) element of an ontology, like a concept, a relation, an instance, etc. (section 4.1.1).

Knowledge resource: any piece of knowledge that is used while working on the definition of an ontology, including modules, workspaces, sources, libraries, networks, methods, etc. (sections 2.3, 4.11).

Ontology design rationale: the motivations according to which an ontology is designed the way it is (section 2.3).

Networked ontology: the semantics of the relations between ontologies at design time. Please note, that because of the networked perspective we take here, design is not to be intended as limited to an initial phase of an ontology lifecycle, but as an aspect of the entire ontology lifecycle (section 3).

Epistemic influence: a generalization over the possible relations holding between two ontology elements, as they are created, discussed, used or modified by ontology designers (section 4.1.3).

Collaborative ontology design: a special case of epistemic workflow (on its turn a type of epistemic influence), which is characterized by the ultimate goal of designing networked ontologies and by specific relations among designers, ontology elements, and collaborative tasks.

As mentioned above, a choice is also required on how to represent these components. To do so we distinguish between two levels of representation:

Social level: a ‘social view’ on an ontology development project. At this level components are characterized in terms of what happens in the real world when a person, a group of people, or a community decide to build an ontology or an ontology network in a collaborative fashion. The social level allows to describe the domain of research through the components and to provide developers of a NeOn-compliant platform with a requirement analysis.

System level: a ‘system view’ on an ontology development project. At this level components are represented in terms of the methods and the techniques that provide (possible) solutions for supporting what described at the social level. Such methods and techniques are the base-models for the design and implementation of a NeOn-platform.

Finally, support consists of the functionalities that (are needed to) support collaborative ontology design. The present list of functionalities (described in detail in section 5) includes evaluation, selection, re-engineering, learning, upgrading database content, mapping, collaborative workflow, argumentation, provenance, data annotation, social network analysis, lexical domains, ontology localization, multilingual ontology integration.

1.2.2 Initial treatment of questions 1-4

Revise and complete, if possible

We provide here informal comments to the questions listed in section 1.1 (WORK IN PROGRESS!):

1. How to represent and build an ontology, both from the logical and content-based viewpoints, by using existing ontologies, modules, design patterns, or even informal or semi-formal information objects, such as thesauri, handbooks, linguistic corpora, etc.?

When using logical languages like OWL or when reusing existing ontologies, modules, and folksonomies the choice space is huge and cognitively intractable. Useful solutions include e.g. pre-compiled patterns or best practices, which help making explicit the design rationales of logical and content encoding. For example, it could be more effective in a team to carry out discussions based on a shared understanding of the distinctions assumed by the members. An example in logic: sharing a practice on how to represent classes as values or n-ary relations greatly speeds up the process of getting consensus on an ontology. As a content example, agreeing on a distinction between events and objects or agreeing on the same meaning of a part-of relation (say, on its transitivity) could be key to make progress on a conceptual conflict between two ontology designers. In these cases, by representing the choice space, we can then represent the design rationales of logical modelling and content creation.

2. How to make an ontology functional to a given task, or to evaluate and select an ontology for a given task?

The choice space can be reduced by making explicit tasks or competency questions that an ontology should accomplish or help answering. Useful solutions include e.g. pre-compiled use cases, unit tests, etc. For example, agreeing on a typical use case, or matching an ontology against a test knowledge base makes explicit the required or existing design rationales that depend on task, thus further reducing the choice space.

3. How to discuss and possibly get consensus on an element or design motivation in an ontology?

Controlling design on the logical, content, and task-oriented aspects is not enough, because the designers in a team should be enabled to discuss those choices explicitly, and to possibly get consensus.

4. How to lexically encode an ontology?

Finally, the lexical encoding of ontologies is crucial for collaborative design, and appropriate support must be provided.

2. Overview and foundations of ODO

schema generalissimo di ODO, commento con esempi, quindi un paio di pagine per spiegare gli schemi/pattern riusati: D&S, Plans, Collectives

inserire riferimento alle network of ontologies qui, riporto anche vecchia sezione:

2.1 What is ontology design?

2.2 Reused components from other ontologies

We are buying the food we produce, …

2.3. Networks of Ontologies

Revise in the light of D1.1.1!, …

2.3.1 Logical description

Informally stated, a networked ontology is "a collection of interconnected individual ontologies, possibly distributed over a number of nodes, connected via a variety of different relationships such as mapping-, modularization-, version-, and dependency-relationships" (D1.1.1, p.6 - draft april 30, 2006).

In this definition, a central role is played by the notion of "individual ontology". While for the specification of mapping, modularization, and versioning aspects there are no standards as yet, the Web Ontology Language (OWL) can be considered as a de-facto standard for representing individual ontologies. For this reason, in NeOn, OWL represents the core language for representing networked ontologies. This core language is extended by different languages that provide additional features regarding mapping, modularization, and versioning aspects.

OWL is a logical language that combines classical "logical" notions (e.g. class, property, individual, rule) with classical "programming/metalevel" notions (e.g. import and annotations of ontologies). In this sense, OWL supports the representation not only of individual ontologies, but also of some weak modularization and versioning aspects.

The ontology mapping module extends OWL allowing for axioms that define a semantic relation between elements, i.e. arbitrary parts of ontology specifications, in different ontologies. In particular, this first version of the Networked Ontology Model model considers the equivalence, containment and overlap (intensional and extensional) mappings (see D1.1.1 for more details).

The modularization and versioning modules are not defined as yet in D1.1.1.

2.3.2 Ontological description

Our aim in the NeOn project is to provide an ontological model of networked ontology/ies. This model will be necessarily different from, though compliant with, the logical model developed in WP1.

We propose the following first sketch of an ontological definition of networked ontology/ies:

I. Let us consider a single ontology which, as a whole or as far as some of its components are concerned, is linked to at least one other ontology; in this case, each of the linked ontologies is a 'networked ontology'.

II. Let us consider a collection of networked ontologies (the focus here is on the set); in this second case, we have an 'ontology network'. Intuitively, the network emerges only if there is some explicit link between at least two ontologies in the collection, which is also the criterion for a collection to emerge in the model proposed by [BOT06]. Such links are not arbitrary, but obey some design rationale, i.e. the representation of the reason why the links between the ontologies are established. Following [BOT06], we will say that a design rationale for an ontology network is a description that unifies a collection of ontologies. From I. and II., in terms of [BOT06] model, it follows that a networked ontology is a member of an ontology network.

III. Let us consider an ontology with distributed URIs, i.e. the elements of the ontology are distributed on the web, because they are taken from ontologies with different namespaces (although not necessarily different ontologies). [CLARIFY WITH EXAMPLES] In this case, we have a 'distributed networked ontology'. The network, here, emerges a posteriori wrt ontology’ creation. This third case is orthogonal to the previous ones, since a distributed networked ontology results to be a networked ontology because of its elements, and its ontology network emerges from the namespaces to which those elements belong.

According to the above definitions, a ‘networked ontology’ in WP1 corresponds to an ‘ontology network’ in WP2.

An example of unifying relationship is given, e.g., by versioning. From the content point of view, the design rationale of versioning may consists in tracking an ontology (or ontology network) evolution through time, or verifying knowledge growth and dissemination, etc. In the next steps of the project, we will identify and characterize types and dimensions of unifying relationships. These latter are the same we have identified for the design rationales of the single component ontologies, i.e. the three dimensions of content, task and sustainability (see Sec. 2.2).

All the functionalities included in the Niys model need to be revised in the light of the above-given definitions (see secs. 4.1.2 and 5 below).

In any case, a network DOES NOT coicide with the ‘Niys scenario'. The latter is much wider, and includes also projects (with related goals), agents, and collaboration among agents (see Sec. 4.2). A network, however, can be a pre- or post-condition of said scenario.

  1   2   3   4   5   6   7   8   9


NeOn: Lifecycle Support for Networked Ontologies iconThe Use of uml as a Tool for the Formalisation of Standards and the Design of Ontologies in Agriculture

NeOn: Lifecycle Support for Networked Ontologies iconEnterprise Architecting Lifecycle Management

NeOn: Lifecycle Support for Networked Ontologies icon[edit] Primary lifecycle processes

NeOn: Lifecycle Support for Networked Ontologies iconNetworked Peers For Business

NeOn: Lifecycle Support for Networked Ontologies iconThe importance of trust in the digital networked economy

NeOn: Lifecycle Support for Networked Ontologies iconDans – Data Archiving and Networked Services

NeOn: Lifecycle Support for Networked Ontologies iconVirtual Collaborative Learning Environments for Music: Networked DrumSteps

NeOn: Lifecycle Support for Networked Ontologies iconРуководитель программы: проф. В. А. Иванов Кафедра оптики Научный доц. Ю. Э. Скобло Рецензент: доц. А. А. Пастор Study of the population processes of neon atom

NeOn: Lifecycle Support for Networked Ontologies iconHighly versatile Senior System Administrator, skilled in the architectural design and implementation of high-availability systems for all major networked

NeOn: Lifecycle Support for Networked Ontologies iconNew Media is the term used for networked computerized or digital technologies that permeate society. There are many definitions of New Media, depending on the

Разместите кнопку на своём сайте:

База данных защищена авторским правом © 2014
обратиться к администрации
Главная страница