Common hyper-ontological frame- work

8/8/2019 Common hyper-ontological framework

1/150

Open architecture forAccessible Services

Integration and Standardization - G.A. 215754

UniBremen D1.2.1 vers. 1.0 : RESTRICTED 1

OASIS Open architecture for AccessibleServices Integration and Standardization

GRANT AGREEMENT # 215754

OASIS common hyper-ontological frame-work (COF)

Deliverable No. D1.2.1SubProject No. SP1 SubProject Title Open system reference archi-

tecture, user interfaces, plat-form and tools

Workpackage No. 1.2 Workpackage Title Development of Common On-

tological Framework (COF)Activity No. 1.2.1-1.2.6 Activity Title COF development: all aspects

Authors (per company, if more thanone company provide it together)

John Bateman, Alexander Castro, Immanuel Nor-mann, Omar Pera (UniBremen), Leyla Garcia, Jose-Maria Villaveces

Status(F: final; D: draft; RD: revised draft):

F

Originating File Name: OASIS-D121-V1R-full.doc

Project start date and duration 30 January 2009, 44Months


2/150




Document Revision History D1.2.1

2009.06.30 D1.2.1-v1.doc: preliminary version as planned in theDescription of Work. Focuses exclusively on methodol-

ogy issues for guiding ontology construction with OA-

SIS partners.

2010.01.17 Initial Major Version (authors above):Now covers allaspects of the COF as scheduled.

2010.01.31 Revised Draft finalised after QC feedback withadditional input: this document.

!List of Main Abbreviations D1.2.1CASL Common Algebraic Specification LanguageCMAP Concept Map

COF Common Ontological Framework

DL Description Logic

HetCASL Heterogeneous CASL

HETS Heterogeneous Tool Set

IEEE Institute of Electrical and Electronics Engineers

KE Knowledge Engineering

OOR Open Ontology Repository

OWL Web Ontology Language

REST Representational state transfer

SW Semantic Web

UI User Interface

XML Extensible Markup Language:XML (2008) Extensible Markup Language (XML) 1.0 (5th.Edition) W3C Recommendation 26 November 2008http://www.w3.org/TR/xml/


3/150




Table of Contents

TABLE!OF!CONTENTS!.....................................................................................................................................!3!

LIST!OF!FIGURES!............................................................................................................................................!6!

LIST!OF!TABLES!..............................................................................................................................................!7!

EXECUTIVE!SUMMARY

!...................................................................................................................................

!8!

1! INTRODUCTION!....................................................................................................................................!9!

1.1! OASIS!OBJECTIVES!....................................................................................................................................!10!

1.1.1! Why!ontologies?!.......................................................................................................................... !10!

1.1.2! Why!methodology?!..................................................................................................................... !11!

1.1.3! Why!modular?!.............................................................................................................................!12!

1.1.4! Why!communities?!...................................................................................................................... !16!

1.2! RESEARCH!PROBLEM!AND!STRUCTURE!OF!THE!DELIVERABLE!................................................................................!18!

1.3! OUTCOMES!AND!PUBLICATIONS!WITHIN!THE!OASIS!ACTIVITIES!ASSOCIATED!WITH!THIS!DELIVERABLE!...........................!21!

1.4! INNOVATIONS!RESULTING!FROM!THE!ACTIVITIES!REPORTED!IN!THIS!DELIVERABLE!......................................................!22!

2! EVALUATING!ONTOLOGY"ENGINEERING!METHODOLOGIES:!!COMMUNITIES!AT!THE!MELTING!POINT!..!25!

2.1!

INTRODUCTION:!LEARNING

!FROM

!EXPERIENCE

!..................................................................................................

!25

!

2.2! METHODS!AND!METHODOLOGIES!FOR!BUILDING!ONTOLOGIES!.............................................................................!29!

2.2.1! Methodology!review!criteria!.......................................................................................................!29!

2.2.2! Analysis!of!proposed!methodologies:!criteria!definitions!.............................................................!30!

2.2.3! Analysis!of!proposed!methodologies:!criteria!application!............................................................!32!2.2.3.1! The!Enterprise!Methodology!...............................................................................................................!33!

2.2.3.2! The!TOVE!Methodology.......................................................................................................................!35!

2.2.3.3! The!Bernaras!methodology!.................................................................................................................!36!

2.2.3.4! The!METHONTOLOGY!methodology!...................................................................................................!37!

2.2.3.5! The!SENSUS!methodology!...................................................................................................................!38!

2.2.3.6! DILIGENT!..............................................................................................................................................!39!

2.2.3.7! The!GM!methodology!..........................................................................................................................!40!

2.2.3.8! The!iCapturer!methodology!................................................................................................................!40!

2.2.3.9! DOGMA!MESS!......................................................................................................................................!41!

2.2.3.10!

NeON!...................................................................................................................................................

!42

!2.3! RESULTS!..................................................................................................................................................!43!

2.3.1! Commonalities!across!methodologies!.........................................................................................!46!

2.3.2! Differences!across!methodologies. !..............................................................................................!47!

2.4! CONCLUSIONS!ON!METHODOLOGY!AND!RECOMMENDATIONS!FOR!THE!OASIS!METHODOLOGICAL!FRAMEWORK!.............!49!

3! THE!COMMON!ONTOLOGICAL!FRAMEWORK:!!METHODOLOGY!COMPONENT!.....................................!52!

3.1! TERMINOLOGICAL!CONSIDERATIONS!..............................................................................................................!53!

3.2! THE!METHODOLOGY!AND!THE!LIFE!CYCLE!.......................................................................................................!53!

3.2.1! Documentation!Processes!...........................................................................................................!54!

3.2.2! Management!Processes!..............................................................................................................!56!

3.2.3! Development"oriented!Processes!................................................................................................!57!

3.3! AN!INCREMENTAL!EVOLUTIONARY!SPIRAL!MODEL!OF!TASKS,!ACTIVITIES!AND!PROCESSES!..........................................!62!

3.4! CONCLUSIONS!FOR!THE!OASIS!COMMON!ONTOLOGICAL!FRAMEWORK:!METHODOLOGY!COMPONENT!........................!63!

4! HYPER"ONTOLOGY:!LOGICAL!FOUNDATIONS!......................................................................................!65!

4.1! DEFINING!THE!TERM!HYPER"ONTOLOGY!........................................................................................................!66!

4.2! HYPER"ONTOLOGY!FRAMEWORK!.................................................................................................................. !67!

4.2.1! The!Nodes!in!the!Hyper"ontology!Framework!..............................................................................!67!


4/150




4.2.2! The!Links!in!the!Hyper"ontology!Framework!................................................................................!68!4.2.2.1! Types!of!Heterogeneity!.......................................................................................................................!69!

4.2.2.2! Kinds!of!Links!.......................................................................................................................................!70!

4.2.3! The!State"of"the"art!in!Connecting!Ontologies!............................................................................!73!4.2.3.1! Package"Based!Description!Logics!(PDL)!.............................................................................................!74!

4.2.3.2! Distributed!Description!Logics!(DDL)!...................................................................................................!74!

4.2.3.3! Integrated!Distributed!Description!Logics!(IDDL)!................................................................................!75!

4.2.3.4!

E"Connections!......................................................................................................................................!75!

4.2.3.5! Interface"Based!Modularization!..........................................................................................................!76!

4.2.3.6! Ontology!Mapping!Based!on!Information"flow!Theory!.......................................................................!77!

4.2.4! A!Simple!OASIS!Case!Study!of!Connected!Ontologies!...................................................................!77!4.2.4.1! Reuse!via!Imports!and!Renaming!........................................................................................................!78!

4.2.4.2! Concept!Interface!and!Ontology!Merge!via!V"Alignment!....................................................................!80!

4.2.5! Institution"Based!Foundation!of!the!Hyper"ontology!Framework!................................................!82!4.2.5.1! Theory!of!Institutions!and!Entailment!Systems!...................................................................................!82!

4.2.5.2! Development!Graph!............................................................................................................................!83!

4.2.5.3! CASL!and!HetCASL!...............................................................................................................................!85!

4.3! DISCUSSION!AND!OUTLOOK!......................................................................................................................... !88!

5! THE!OASIS!ONTOLOGICAL!TOOLBOX:!CURRENT!STATE!OF!DEVELOPMENT!...........................................!90!

5.1! BASIC!BUILDING!BLOCKS!FOR!THE!OASIS!ONTOLOGY!TOOLBOX!...........................................................................!91!

5.1.1!

The!Protg

!Ontology

!Editing

!Environment

!.................................................................................

!91

!

5.1.2! The!BioPortal!system!................................................................................................................... !91!

5.1.3! The!HETS!system!......................................................................................................................... !91!

5.2! OLS2OWL.!A!REPOSITORY!ACCESS!FACILITY!...................................................................................................!93!

5.3! MAP2OWL,!A!CONCEPT!MAPPING!FACILITY!FOR!PROTEGE!...............................................................................!95!

5.3.1! Lessons!learnt!from!using!CMAPS!................................................................................................!98!

5.3.2! CMAPS!supporting!Knowledge!Elicitation!....................................................................................!99!5.3.2.1! Identification!of!purpose,!scope,!competency!questions!and!scenarios!...........................................!100!

5.3.2.2! Identification!of!reusable!and!recyclable!ontologies!.........................................................................!101!

5.3.2.3! Domain!analysis!and!knowledge!acquisition!.....................................................................................!101!

5.4! ORATE:!AN!OPEN!ONTOLOGY!REPOSITORY!..................................................................................................!102!

5.4.1! ORATE!Welcome!Page!...............................................................................................................!103!

5.4.2! Project!Management!.................................................................................................................!103!

5.4.3!

Publishing!Ontologies

!................................................................................................................

!105

!5.4.4! Browsing!Ontologies!.................................................................................................................!106!

5.4.5! Searching!Ontologies!.................................................................................................................!108!

5.4.6! Browsing!Concept!Mappings!between!Ontologies!.....................................................................!109!

5.5! CURRENT!CONTENTS!OF!THE!ORATE!REPOSITORY!..........................................................................................!111!

5.5.1! Ontologies!developed!by!OASIS!partners!...................................................................................!111!5.5.1.1! Ontologies!from!WP1.3!"Content!Connector!and!Ontology!Management!Tools!and!Interfaces"!....!111!

5.5.1.2! Ontologies!from!WP2.2!"Nutritional!Advisor"!...................................................................................!112!

5.5.1.3! Ontologies!from!WP2.6!"Health!Monitoring"!...................................................................................!114!

5.5.1.4! Ontologies!from!WP2.7!"Environmental!Control"!.............................................................................!114!

5.5.1.5! Ontologies!from!WP3.2!"!Elderly!friendly!transport!Information!Services"!......................................!115!

5.5.2! Ontologies!developed!by!third!parties!.......................................................................................!115!5.5.2.1! DOLCE!................................................................................................................................................!116!

5.5.2.2! GIST!...................................................................................................................................................!117!

5.5.2.3!

Ordnance!

Survey!

Ontologies!

.............................................................................................................!

117!

5.6! CONCLUSION!..........................................................................................................................................!118!

6! THE!FUTURE!OF!OPEN!ONTOLOGY!REPOSITORIES:!ONTOLOGIZING!METADATA!FOR!ASSISTIVE!

TECHNOLOGIES !.........................................................................................................................................!119!


5/150




6.1! REPOSITORIES!AND!METADATA!IN!GENERAL!..................................................................................................!120!

6.2! THE!NEED!FOR!ONTOLOGIZED!METADATA!....................................................................................................!123!

6.3! AN!OASIS!USE!CASE!...............................................................................................................................!125!

6.4! A!SPECIFIC!SCENARIO!...............................................................................................................................!126!

6.5! OUTLOOK!..............................................................................................................................................!128!

7! ONGOING!RESEARCH!AND!DEVELOPMENT!........................................................................................!129!

7.1! CURRENT!ONTOLOGY!DEVELOPMENT!WORK!.................................................................................................!129!

7.2! CURRENT!SOFTWARE!DEVELOPMENT!...........................................................................................................!130!

7.2.1! The!MAP4MAPPING!extension!to!BioPortal/ORATE...................................................................!131!

7.2.2! Connecting!HETS!and!Protg!...................................................................................................!132!

7.2.3! Exploring!the!Hyper"Ontology!Network!in!ORATE!......................................................................!133!

7.2.4! Semantic!Versioning!in!ORATE...................................................................................................!135!

8! CONCLUSIONS!..................................................................................................................................!138!

9! REFERENCES!.....................................................................................................................................!140!

!!


6/150




List of Figures

Fig. 1. The causal chains from modularity to OASIS applications that are of benefit to the end

user. .......................................................................................................................................... 16!

Fig. 2. The common ontological framework: COF and its relation to other ontology

components ............................................................................................................................... 19!

Fig. 3. Innovations as instantiations of components of the OASIS COF and their formative

inputs ........................................................................................................................................ 24!

Fig. 4. Uschold and King methodology ................................................................................... 34!

Fig. 5. The TOVE methodology ............................................................................................... 36!

Fig. 6. METHONTOLOGY. Reproduced with permission from (Corcho et al., 2003) .......... 38!

Fig. 7. Similarities amongst methodologies ............................................................................. 47!

Fig. 8. Terminological relationships ........................................................................................ 53!

Fig. 9. Life cycle, processes, activities, and view of the methodology .................................... 54!

Fig. 10. A view of the whole ontology design process ............................................................ 63!

Fig. 11. The hyper-ontology model compared ......................................................................... 66!

Fig. 12. Hyper-ontology framework ........................................................................................ 67!

Fig. 13. V-Alignment between a radio controller (RC) ontology and a television controller

ontology (TVC). ....................................................................................................................... 82!

Fig. 14. Effect of change in a heterogeneous network of ontologies after modification of O3 in

(a) to O3 (b) ............................................................................................................................ 87!

Fig. 15. HETS architecture ....................................................................................................... 92!

Fig. 16. Plug-in architecture and basic functionalities ............................................................. 94!

Fig. 17. Side-by-side comparison of distinct ontologies ....................................................... 94!

Fig. 18. An example of a conceptual map ................................................................................ 96!

Fig. 19. MAP2OWL ................................................................................................................. 97!

Fig. 20. Steps and milestones ................................................................................................... 98!

Fig. 21. Anchoring of baseline ontology formation within the OASIS methodology ........... 100!

Fig. 22. Ontologies identified after an initial Knowledge Elicitation exercise ...................... 101!

Fig. 23. Welcome page of ORATE ........................................................................................ 103!

Fig. 24. Projects tab: displays a list of ontology development projects ................................. 104!

Fig. 25. Editing project allows the user to modify project information and to assign ontologies

to the project ........................................................................................................................... 105!

Fig. 26. Submission form for a new ontology to be uploaded. .............................................. 106!


7/150




Fig. 27. Browse tab: displays a list of uploaded ontologies ................................................... 107!

Fig. 28. Exploring an ontology in the visualization view ...................................................... 108!

Fig. 29. Exploring an ontology in the visualization view. ..................................................... 108!

Fig. 30. Search tab with displayed results ............................................................................. 109!

Fig. 31. Mapping tab: displays a list of concept mappings from a source to a target ontology.

................................................................................................................................................ 110!

Fig. 32. All concept mappings from the Trip to Transportation ontology. ............................ 110!

Fig. 33. A view of the OMV is-a hierarchy ........................................................................... 121!

Fig. 34. The portion of ABC relevant for modelling ontology evolution .............................. 122!

Fig. 35. A portion of the ABC model ..................................................................................... 124!

Fig. 36. An initial step towards ABCing OMV ...................................................................... 124!

Fig. 37. The ABCed model .................................................................................................... 125!

Fig. 38. Case study ................................................................................................................. 127!

Fig. 39. Supported features .................................................................................................... 132!

Fig. 40. Cooperation between HETS, Protg, and the broker for manipulation of ontologies

in a heterogeneous network of ontologies .............................................................................. 133!

Fig. 41. The OASIS generic ontology platform: organisation and interconnections ............. 138!

List of Tables

Table 1. Summary of methodologies. ...................................................................................... 44!

Table 2. Aspects of Hyper-ontology ........................................................................................ 67!


8/150




EXECUTIVE SUMMARY

The OASIS project involves a knowledge-rich service provision scenario in which services

are constructed and combined by the creation of ontologies. These ontologies represent the

domain knowledge required for the services to run. Several problems are well known to make

such application scenarios difficult to achieve. For example: the domain experts possessingthe knowledge to be represented are geographically distributed and interact relatively rarely

and the structure of the created ontologies can be expected to evolve as services are added or

their functionalities extended. In addition, the needs of ratherdiverse users need to be taken

into account: whereas some service providers may have detailed formalisations of the domain

knowledge their services rely on, the majority can be expected to be less versed in explicit

representations of this kind and so require automated and semi-automated support for their

development of knowledge-rich products.

This situation is exacerbated by the fact that many of the services targeted within the OA-

SIS scenario need to draw on information beyond that available within single domains. A cen-

tral challenge of OASIS is to achieve interoperability spanning complex services in the areas

ofIndependent Living(including at least a nutritional advisor, an activity coach, a brain andskills trainer, social communities platforms, health monitoring and environmental control),

Autonomous Mobility (including at least elderly-friendly transport information services, eld-erly-friendly route guidance, personal mobility services, mobile devices, biometric authentica-

tion interface and multimodal dialogue interaction), and Smart Homes and Workplaces (in-cluding at least ambient assisted living solutions, remote access to data, and accompanying

sensor and control technology). Such a diversity of types of services can only be supported by

providing cross-domain networked ontologies, a goal which is itself a substantial research

challenge.

Within a complex development environment of this kind, the role of the knowledge engi-

neer changes. Rather than leading ontology development, knowledge engineers have the task

of promoting collaboration and communication among domain experts and of guiding knowl-

edge formalisation from informal requirements specifications through to fully specified on-tologies. This requires considerable support at all levelsin particular in terms of method-

ologies to be applied, theoretical foundations for providing guidelines, and computational

support to help both development and application. These requirements are met by the OASIS

Common Ontological Framework (COF), a three-fold knowledge representation paradigm

that provides: (i) methodological principles for developing interoperable ontologies well

suited to their individual application requirements, (ii) formalized connectivity tissue in the

form of a hyper-ontology that facilitates formal semantic interoperability across ontologies,

and (iii) an appropriate software infrastructure for supporting heterogeneous ontologies con-

forming to these principles. The present document provides a thorough description of the

OASIS COF for building interoperable, community based ontologies, its methodological and

theoretical foundations, the current state of the software tools supporting it, and our ongoing

research developing the COF further.


9/150




1 Introduction

The 1990s were a time when the word ontology became a fashionable item within the

Knowledge Engineering (KE) community. Building ontologies was considered an innovative

and promising solution for many problems of knowledge representation and organisation and

considerable research activity was started concerned specifically with ontology construction

and design (Fernandz et al., 1997; Guarino et al., 1993; Uschold, 1996; Uschold andGruninger, 1996; Uschold et al., 1998). As more ontologies developed, a wider communitycame to understand the possibilities they offered. Machine-enabled understanding became a

goal in ever more applications areas, and classification systems and intelligence in those

applications were widely sought. As commonalities in both ontologies and the methods that

could be employed for ontology construction began to emerge, it was realised that it was im-

portant to reach agreements upon standards for protocols to achieve ... unified and consistent

progression of innovation and knowledge (Garcia et al., 2009b). Additionally, as the possibilities offered by available technology grew, so the need for more fine-grained

ontologies, management systems for ontologies, and inference and flexible knowledge

representation paradigms for ontologies was also increasingly recognisedleading to a broadvariety of tools, methods and results. In some application areas, the development of ontolo-

gies was taken up by communities as a wholethus turning a previously behind-the-scenes

process into a community issue. Several ontologies designed at this time illustrate this trend;

one particularly well known example is the Gene Ontology in the biomedical domain. Finally,

the most recent research trend is to consider how user-provided information, such as tagging

and folksonomy extraction, can also be used as information sources when building ontologies.

Ontology Engineering has therefore come a long way since the early days when ontologies

were developed by restricted small groups of domain experts working with a knowledge engi-

neer. The need for easy-to-manage ontologies, well modularized, more straightforward to

formalize, and supporting inference to the extent necessary for their intended applications of

use, has firmly established itself. The problems brought by large monolithic ontologies, such

as SNOMED in the medical domain, have resulted in the conviction that far better modulari-zation techniques need to be found both forde novo ontologies and for those already avail-able. Building ontologies as plain controlled vocabularies is certainly no longer the issue;

nowadays processes for building ontologies should be replicable and enable others to follow

an ontologys development, thus allowing the evolution of an ontology to be monitored and

evaluated. The need for methods and techniques facilitating and structuring the involvement

of the community in this development has also become evident.

Against the backdrop of this growth in ontology and Ontology Engineering, issues of

sound and appropriate methodologies are now central. In this respect, the words of de Hoog

concerning methodology are of particular relevance:

it is extremely difficult to judge the value of a methodology in an objective way. Experimentation is of

course the proper way to do it, but it is hardly feasible because there are too many conditions that cannotbe controlled Introducing a toy problem will violate the basic assumption behind the need for a meth-odology: a complex development process. (cited in (Perez et al., 2004))


10/150




Since current ontology development and the requirements placed on ontologies have moved

well beyond toy problems, the need for appropriate methodologies is greater than ever. More-

over, in addition to a complex development process, it has become clear that it is always nec-

essary to consider ontology design through the filter of evolution: the statement nothing

makes sense except in the light of evolution (Dobzhansky, 1964), again from the biological

domain, appears to be equally applicable for ontological engineering. This then leads natu-rally to such pervasive methodological questions as: How was the ontology built? Which are

the classification principles that should be applied? How could this model be broken down

into manageable pieces? What is the ontology meant to support? How is software to use the

ontology? And so on. These are some of the key questions with which ontology engineering

methodologies must concern themselves.

With this general state of the art presumed as background, several new challenges and di-

rections for development can be isolated at this time. These require specific treatment for on-

tologies to grow and deliver on their promise in a broader range of situations of use. Many of

these challenges are concerned with issues of modularity, of method, and of suitably involv-

ing the communities for which the ontologies are to support functionality. Within the OASIS

project, these issues are raised quite concretely by the need to combine disparate information

sources in order to build assistance technologies for elderly users. Here we have all of the

problems facing ontology development in general: ontologies need to be reusable, ontologies

need to support appropriate inferencing, to respect the needs of the communities who are to

use them, and to be well engineered and maintainable. These problems can only be tackled

within the bounds of an appropriate methodology, with appropriate theoretical frameworks

and supporting technology.

For this purpose, one central deliverable of the OASIS project is its approach to Ontology

Engineering. This approach is manifested at several levels of abstraction, beginning with an

extensive methodology for anchoring ontology development, implementation and use. The

present deliverable describes this approach to ontology in detail. The approach consists of

three main areas: the OASIS Common Ontological Framework (COF), the OASIS Hyper-

Ontology and the OASIS ontology repository. In the chapters below, we introduce each areaand motivate the solutions we have adopted. To begin, however, we summarise briefly the

particular objectives of OASIS with respect to ontology development. This will allow us to

identify more clearly the requirements we need to fulfil for ontology engineering within the

project, to evaluate partial solutions developed by others, and to justify the directions taken up

as the OASIS solution.

1.1 OASIS Objectives1.1.1Why ontologies?

Several authors have extensively discussed the whys of ontologies. Within the computer

science community these reasons have been summarized as follows (Guarino, 1997; Noy andMcGuinness, 2001a):


11/150




! To clarify and share the structure of knowledge

! To make the assumptions used to create some domain explicit

! To allow reuse of knowledge

! To allow a clear differentiation between domain knowledge and operational knowl-

edge

The need to clarify the structure of knowledge and to bring out its underlying assumptions

before it can be shared assumes particular importance in the area of ontology. Different in-

formation systems might, for example, follow different business logics. They are considered

to be interoperable if they can nevertheless exchange data and information. Heterogeneous

applications of this kind are only able to share information if there is an agreed common vo-

cabulary to describe the items these information systems are meant to manage, and this neces-

sitates being particularly clear about the structure of the information at issue. Finally, separat-

ing out operational knowledge allows for an explicit consideration of the use of information

(e.g., for particular applications or by particular communities) in addition to the representationof the information itself.

1.1.2Why methodology?

The need to reuse knowledge becomes increasingly critical as more realistic and applica-

tion-near systems are considered. Large domains of knowledge are typically highly frag-

mented and communities of experts accordingly develop their own conceptualisations accord-

ing to their communities of practice and backgrounds. Ontologies developed in these areas are

intended to allow reuse whenever needed. The ability to integrate and reuse an existing ontol-

ogy is commonly seen as a considerable benefit. However, although long accepted as one of

the major advantages of using ontologies, it is often by no means clear how a merger or inte-

gration of ontologies as required for reuse can be carried out. Ontology interoperability is

therefore recognized as a challenging but as yet unachieved task. No current ontology-

building methodology really addresses this issue or deals with it explicitly. There is no con-sensus for methodologies that could be employed in order to improve the likelihood of effec-

tive merging and integration.

Relations between ontologies studied in the literature include mapping, alignment, coordi-

nation, transformation, translation, merging, reconciliation, and negotiation (Bouquet et al.,2004); many of these employ statistical approaches and similarity measures (Euzenat, 2007b;

Euzenat et al., 2007; Kalfoglou and Schorlemmer, 2003a). Such approaches are essentially

based on inspecting superficial properties of the ontologies, such as concept and roles names,

and the quality of alignments is typically assessed by comparison to a previously defined

gold-standard based on standard precision and recall methods (Hage, 2008). Although consid-

erable progress is being made in this area, possible success is naturally limited to the inherent

compatibility of the ontologies being aligned. As far as methodologies to improve this state ofaffairs is concerned, the current situation is still more of an art than a methodology (Mirzaee,

2004b) and these issues remain very much ongoing research (Beck and Pinto, 2003; Pinto and

Martins; Pinto et al., 1999). This is important for OASIS since the Content Connection Mod-ule (Deliverable D1.2.2) employs several of these methods; the accuracy of content manage-


12/150




ment can be pushed higher if the information being matched is made more consistent. For

this, methodology can play a crucial role.

1.1.3Why modular?

Modularization in itself is a generic concept that is intuitively understood as referring to a

situation where simultaneously a thing (e.g. an ontology) exists as a whole but can also beseen as a set of parts (the modules). How modularization is approached and put into practice,

as well as the advantages and disadvantages that can be expected from modularization, greatly

depend on the goals that are pursued through modularization. The chapter "An Overview of

Modularity" of (Parent and Spaccapietra, 2009) compiles an extensive set of possible goals

for ontology modularization; we will draw on this throughout this section in order to bring out

the issues that any solutions to problems of modularization need to address. Definitions of

modularity also vary (Bateman et al., 2007; Cuenca Grau et al., 2008; Kutz et al., 2008c;

Loebe, 2006; Serafini et al., 2005b; Stuckenschmidt, 2003; Wang et al., 2007); we will there-

fore focus on notions of modularity that move us further towards providing solutions for the

OASIS use scenarios, rather than considering modularity in the abstract.

A good answer to the why question must in the last resort be that there are humans takingadvantage (directly or indirectly) from modularity of ontologies. In the context of OASIS

these humans fall into the following categories:

! ontology developers: knowledge engineers and domain experts (cf. Chapter 3);

! system providers: application developers, web-service providers making use of on-tologies developed by ontology developers (cf. section 2.4 in D1.6.1 for further differ-

entiation of developer types);

! end users: using applications provided by the system providers.

Our claim is that ontology developers and system providers can benefit directly from the

modularity of ontologies and that end users thus indirectly benefit also. The OASIS subpro-

jects SP2 and SP3 investigate how the end user benefits from OASIS software applicationsrunning on various devices and providing services for the elderly. The OASIS application

domains comprise: Independent living, mobility, socialization, and smart workplaces (exhaus-

tive use cases and application scenarios are provided in D2.1.1 and D3.1.1). An architectural

view on these applications and how they interoperate is provided in deliverable D1.6.1 in

chapters 4 and 5.

The OASIS applications being constructed for these services are intended to make use of

ontologies in several ways:


13/150




! in the application development phase:

o as templates for database schemes

o as conceptual models of the envisioned application

o as specifications of application interfaces

! in the application usage phase:

o to configure user profiles

o to connect web services

o to retrieve semantically annotated data

o to interact with reasoners.

In typical OASIS scenarios, several services and devices have to be in interaction and hence

the corresponding software must be highly interoperable. As the software is driven by ontolo-

gies, these ontologies must be interoperable or connectable too: if two applications, based on

ontologies, interoperate in a well specified way then their underlying ontologies must be re-

lated in a meaningful way.

Interoperability or connectivity in the case of ontologies means that two ontologies are

connected via a relation with a well defined semantics. In many cases the purpose of such

connections is to transport concepts and their implications from the source ontology to the

target ontology. A simple example is the importrelation where the target ontology imports allknowledge from a source ontology; details about all the kind of connections we take into ac-

count in the COF are provided in section 4.2.2 below. Let us illustrate the import relation by

the following example: Suppose there is an ontology describing the functionality of a mobile

phone and another ontology describing an application to be plugged in. Then an ontology de-

scribing both the mobile phone and its plug-in is most likely given by importing the plug-in

ontology into the mobile phone ontology. For instance, if the target ontology of the mobile

phone has a notion of telephone numbers in the address book and the source ontology of theplug-in has in addition to this a notion of emergency numbers as a subclass of telephone num-

bers, then the target ontology will also gain a notion of emergency numbers when it imports

the source ontology. An alternative way of describing this is to say that a plug-in is inte-

grated into a target system.

With interoperability we always associate some degree of independence between the par-

ticipating components. To give an OASIS relevant example: in particular for the elderly (but

not only for the elderly!) it may be annoying to have for each and every remote controllable

device its own remote control with its own specific style of being handled. Different handling

for the same purpose is an unnecessary irritation. A remote control that can be used to control

several different devices instead may then be desirable. Typically such a remote control

should have only few operating elements with a very intuitive operationfor instance: a

wheel that can be used to adjust the volume of the radio or of the television or its brightness

depending on the context. With such an example we already see several natural modularities

that call for independence of accounts. The basic operation and meaning of the wheel gadget

can be defined independently of the particular values that it is used to manipulate. Those val-


14/150




ues are themselves then defined within the individual theories of TV operation, radio opera-

tion, and so on. Interoperability is achieved by defining the necessary relation between the

modules.

This very simple scenario already suggests the value of adopting different ontological per-

spectives to describe the involved objects: this wheel can be just an object that can be turned,

it can be a volume controller or a brightness controller, or it can be a controller for a radio or atelevision. Moreover, volume is a position for the wheel as volume controller, but a certain

voltage for the speaker, or decibel for an acoustic sensor, etc.

Concerning modularity we therefore come to at least two conclusions. First, different pur-

poses of a single entity can call for different ontologies reflecting those purposes. It is even

possible that different perspectives can lead to incompatible ontologies; for instance, what is

called a small symbol in an ontology for visually users with a vision deficit might be called a

big symbol in an ontology for users without such a deficit. In fact, this is only one type of the

many heterogeneity requirements that we will discuss in more detail in section 4.2.2.

Second, the fact that one wheel can be used for many purposes implies that it has some fea-

tures that are reusable in different contexts. But this means that a small ontology describing

these reusable features is also reusable for an ontology that makes use of this feature in a spe-cific context. Reusability is one of the central arguments for modularitya fact that is well

known in software engineering. To design a robust module of reusable software of high qual-

ity can be costly. But once this is accomplished it can be applied arbitrarily often for free or

low cost with always the same quality guaranteed. The obvious tendency is that the smaller a

module is, the higher its reusability becomes: thus, a wheel ontology can be reused much

more often than a controller ontology that already contains among other similar concepts a

wheel-like volume controller.

To keep an ontology small is not just a good idea for reusability, however. It also serves to

reduce complexityanother very important aspect that is eventually for the benefit of the

end user, but at first for the ontology developer and system providers. The larger an ontology

is, the more difficult it is for humans to grasp the knowledge contained in that ontology. Thismeans:


15/150




! for a service provider: the more difficult it is to find the right ontology for aligning theweb service (cf. D1.6.1 for an architectural view on the Content Connector Module

and D1.3.2 for details);

! for an application developer: the more difficult it is to check whether the application(or its API) reflects the ontology;

! for the ontology developer: the more involved the analysis is with respect to possibleinconsistencies or redundancies, and the more expensive the evaluation of an ontology

becomes against the reality it aims to model;

! for the maintainer: the harder it is to identify the semantic difference between two ver-sions of an ontologyupdates to a new ontology may therefore cause incomprehensi-

ble or unexpected effects;

! for a reasoning machine: the more time is taken by the reasoning process;

! for an ontology editor or browser: the more cluttered the ontology presentation be-comes.

All these consequences can negatively affect the quality of produced ontologies; i.e. theymight be inconsistent, redundant, incoherent, and inadequate with respect to the domain and

intended application. Applications built on top of such ontologies naturally inherit these defi-

ciencies and reliable interoperability is compromised. Small ontologies in contrast avoid these

negative consequences and thus improve theirunderstandability, maintainability, and even-

tually theirquality. In sum, a high quality of connectable ontologies facilitates high quality

interoperable applications for the benefit of the end user.

Fig. 1 schematically presents the causal chains from modularity to the OASIS applications

that are for the benefit of the end user. For clarity it does not cover every aspect mentioned

above, but emphasizes the most important connections in order to reduce complexity and to

facilitate the approaches to heterogeneous modelling we take up in more detail below.


16/150




Fig. 1. The causal chains from modularity to OASIS applications that are of benefit to the end user.

This benefit is the ultimate criterion to motivate the modularity of ontologies. In the OASIS approach we aim for highly interoperable applica-tions based upon ontologies. The diagram indicates why this approach calls for highly interoperable ontologies by emphasizing the importance toreduce complexity and to facilitate heterogeneous modelling

1.1.4Why communities?


17/150




Ontologies in the future will not only be domain and/or task specific but also application ori-

ented. However, the construction of applications and ontologies will not always take place as

parts of individual, isolated software development projects. It will therefore be important for

ontologies to be easily extensible, meaning that the ontology life cycle should be one in which

ontologies are in constant evolution, highly dynamic and highly re-usable. This means not

only that the structure of the ontology is constantly evolving, but also that the role of theknowledge engineer becomes one of a facilitator of collaboration and communication among

domain experts rather than being a leader or driver of a projectas still often the case in cur-

rent day ontology-based projects.

Parallels can be drawn between these tendencies and the Semantic Web (SW) in general.

SW-related scenarios are often described as being distributed, loosely controlled and evolving

(Pinto et al., 2004a). The main differences between the classic proposals for building ontolo-gies and those requirements applied to the SW have been summarised by Pinto et al(Pinto etal., 2004a), as well as Garcia et al(Garcia et al., 2006) and are described in four key points:

1. Distributed information processing with ontologies: Within the SW scenario, ontolo-gies are developed by geographically distributed domain experts willing to collabo-

rate, whereas traditional knowledge engineering deals with centrally developed on-tologies.

2. Domain expert-centric design: Within the SW scenario, domain experts guide the ef-fort while the knowledge engineer assists them. There is a clear and dynamic separa-

tion between the domain of knowledge and the operational domain. In contrast, tradi-

tional knowledge engineering approaches relegate the role of the expert as an infor-

mant to the knowledge engineer.

3. Ontologies are in constant evolution in SW, whereas in traditional knowledge engi-neering scenarios, ontologies are simply developed and deployed.

4. Additionally, within the SW scenario, fine-grained guidance should be provided bythe knowledge engineer to the domain experts on just how to proceed, since those

domain experts cannot in general (and should not) be expected to be knowledge en-

gineering experts also.

Another interesting parallel can be drawn from the development of the Linux operating

system (OS) and the K Desktop Environment (KDE). These two collaborative efforts offer a

more mature example of cooperative community work than that so far achieved in ontology

development efforts. Both these collaborative structures rely on the active participation of the

community, as well as on an effective set of guidelines to ensure the plug-ability of the final

product. The core of the OS is overseen by a high level architect, an expert in the structures

that hold the Linux kernel together, while highly specialized experts write, for instance, driv-

ers for specific hardware. The high level overseer is responsible for the formalization and

gathering of these efforts into a coherent and structured whole. Although similar in its col-

laborative nature, sharing code is, however, different from sharing knowledge; it is yet to beseen how the lessons learnt from the open source community can best be applied to the devel-

opment of ontologies. Unfortunately little attention has been paid to the actual how of the


18/150




process of knowledge management carried out by these open source communities in their cor-

responding projects (Hemetsberger and Reinhardt, 2004). Further studies are required.

As a consequence of these developments, a recurrent and important term throughout this

deliverable will be community, and more broadly community of practice. Although on-tologies traditionally were built by one or few experts, the field is currently moving from the

idea of a single authoritative expert to harvesting the collective intelligence. Wenger definescommunities of practice as follows:

Communities of practice are the basic building blocks of a social learning system because they are thesocial containers of the competences that make up such a system Communities of practice definecompetence by combining three elements. First, members are bound together by their collectively devel-oped understanding of what their community is about and they hold each other accountable to this senseof joint enterprise. To be competent is to understand the enterprise well enough to be able to contributeto it. Second, members build their community through mutual engagement. They interact with one an-other, establishing norms and relationships of mutuality that reflect these interactions. To be competent isto be able to engage with the community and be trusted as a partner in these interactions. Third, commu-nities of practice have produced a shared repertoire of communal resourceslanguage, routines, sensibili-ties, artefacts, tools, stories, styles, etc. To be competent is to have access to this repertoire and be able to

use it appropriately. (Wenger, 1998; Wenger, 2000; Wengeret al.

, 2002).Interestingly, Wenger emphasizes the shared repertoire of resources such as language,

routines, artefacts, etc.; this part of his definition also has close parallels with the apparently

unrelated community of knowledge management. Knowledge there is defined, for example,

by Davenport and Prusak thus:

Knowledge is a mix of framed experience, values, contextual information, expert insight andgrounded intuition that provides an environment and framework for evaluating and incorporating newexperiences and information. It originates and is applied in the minds of knowers. In organisations, it of-ten becomes embedded not only in documents or repositories but also in organisational routines, proc-esses, practices and norms. (Davenport and Prusak, 1998)

Davenport and Prusak accordingly also place emphasis on organizational routines, processes,

practices and norms.These shared commonalities across the two definitions make it clear that communities of

practice are brought together by virtue of their intersecting knowledge. The importance of

communities in knowledge representation and ontologies has been acknowledged by Gruber,

Smith et al (Smith et al., 2007), Dellschaft et al. (http://www.neon-project.org/web-content/index.php?option=com_weblinks&task=view&catid=17&id=158), and many others.

The trend is also reflected in the availability of software supporting the engagement of several

domain experts, communities, representing knowledge and developing ontologies. For in-

stance, WebOnto (http://kmi.open.ac.uk/projects/webonto/) and Collaborative Protg

(Tudorache and Noy, 2007) both aim to support collaboration. Clearly, for OASIS, this is a

direction that needs to drawn upon and developed considerably further.

1.2 Research Problem and Structure of the DeliverableThe OASIS response to the requirements and areas of previous work identified above is a de-

tailed development of a Common Ontological Framework (COF) that is intended to move


19/150




the state of the art in ontology methodology, design, implementation and maintenance signifi-

cantly forwards. This is only possible drawing on a broad front of previous work and describ-

ing that previous work accordingly makes up a substantial portion of this deliverable; the par-

ticular innovative increments that take us beyond previous work are set out in detail within the

relevant chapters and are also grouped together and characterised as a whole in section 1.4.

The Common Ontological Framework has been constructed to support the OASIS re-quirements identified by defining a three-fold knowledge representation paradigm that pro-

vides: (i) methodological principles for developing interoperable ontologies well suited to

their individual application requirements, (ii) formalized connectivity tissue in the form of a

hyper-ontology that facilitates formal semantic interoperability across ontologies, and (iii)

an appropriate software infrastructure for supporting heterogeneous ontologies conforming to

these principles. In the chapters following we will introduce the research issues addressed as

well as the key concepts upon which we build; outcomes and deliverables are also presented.

The structure of the deliverable follows the structure of the ontological framework. The COF,

and its intended role as a guiding set of principles for all OASIS ontology components, is

shown graphically in Fig. 2.

Fig. 2. The common ontological framework: COF and its relation to other ontology components

Chapters 2 and 3 concern themselves with the methodological component of the COF. In

Chapter 2 we review previous experiences in ontology methodology that are of particular

relevance to the application scenario of OASIS and the highly diverse, distributed ontology

development required. Throughout this chapter, we present a critical review describing most

of the methodologies proposed for ontology development to date; this analysis illustrates

commonalities across proposed methodologies, the importance of the orchestration of meth-

ods and issues not yet addressed are also discussed.

In Chapter 3 we then provide at a high level of abstraction the particular ontology method-

ology and development guidelines that we have developed. The OASIS project as a whole

provides an ideal development opportunity for engineering a methodology for building on-


20/150




tologies in a sound and well motivated manner. On the one hand, there is the need for well

designed and implemented ontologies, supporting reasoning and facilitating interoperability

across heterogeneous domains. On the other hand, OASIS itself facilitates direct access to

geographically distributed domain experts for whom participating in the development of on-

tologies is critical. Both these aspects allow knowledge engineers to study what could be ap-

plicable from previously proposed methodologies and how; thus making it possible to supportand test each and every step along the development process. Not only do these particularities

of the OASIS project facilitate engineering an ontology development methodology, but they

also make it possible to study, within a set of real scenarios, the problems associated with

networked ontologies and most effective solutions to these problems.

The methodological component of the Common Ontological Framework provides an envi-

ronment within which commonalities across proposed methodologies have been combined in

order to facilitate the development of ontologies, more specifically but not restricted to, net-

worked ontologies. In short, the COF instantiates the proposed methodology and makes the

notion of networked ontologies workable by providing specifications and tools for networking

heterogeneous ontologies. On the methodological side the COF then delivers: (i) user-friendly

guidance, (ii) design and development principles, and (iii) tools supporting the methods and

techniques being brought together by the methodology. By providing well-orchestrated meth-

ods and techniques together with well-structured documentation, it should be straightforward

for others to reproduce the development process and so be able to interoperate with those on-

tologies developed as part of the OASIS project. Interoperability arises from two factors: (i)

the application of common design and development principles and (ii) the hyper-ontology.

The formal specification of just what modules are and their theoretical foundations are set

out in Chapter 4. This draws in detail on the current state of the art in networked and linked

ontologies, describing to what extent solutions can be adapted for the OASIS case. This chap-

ter then goes on to describe how these foundations provide for the definition of the OASIS

hyper-ontology, which stands at the heart of our solutions to interoperability.

In Chapter 5 we present the current state of instantiation of the hyper-ontology in the form

of an ontology repository and the tools supporting the methodological concerns identified in

the preceding chapters for OASIS. These tools bring together the ontology editor, Protg,

and our new ontology repository, ORATE, available at http://ontologies.informatik.uni-

bremen.de/. ORATE is already an extensive ontology repository and we expect it to be home

to an increasing number of ontologies in all areas relevant to OASIS services and application

developments, as well as to ontologies concerned with internal details of the OASIS platform,

such as user models and profiles.

With this development, issues of securing access to the ontologies that are being main-

tained grow in importance: not all ontologies are potentially relevant to all purposes. It there-

fore becomes necessary to consider methods for systematically filtering access to ontologies

according to specified requirements. Moreover, the evolutionary aspect of the ontology life-

cycle means that not all ontologies within ORATE will be relevant at all times: ontology ver-sions may be superseded by newer versions or change their network relationships with other

ontologies. To support intelligent access to relevant ontologies, advances are then also needed

in the area ofontology metadata. Metadata provide information about individual ontologies


21/150




so that they can be selected when relevant for some purpose, and filtered out when not rele-

vant. Chapter 6 accordingly sets out our considerations concerning metadata for open ontol-

ogy repositories and a use case that we have explored within the OASIS scenario.

In Chapter 7 we motivate and describe ongoing developments that we are pursuing with re-

spect to the hyper-ontology and its computational support and theoretical foundations. These

advances are necessary for bringing the OASIS Common Ontological Framework up to thefull set of functionalities targeted in the Description of Work for the project. These extensions

will be reported on in the additions to this deliverable scheduled within the third year of the

OASIS project.

Finally, in Chapter 8, we briefly summarise the contributions to date and conclude.

1.3 Outcomes and Publications within the OASIS Activities associated withthis deliverable

The work described in this deliverable has focused primarily on providing a working infra-

structure and sound methodology for ontology design, both of which are now being applied

within the OASIS project. For this work, we have prioritised early prototyping and deploy-ment for OASIS partners in order to move us towards concrete experimentation and evalua-

tion as quickly as possible. Early results have nevertheless already appeared in the following

publications:

1. Garcia Castro, I. Normann, J. Hois, and O. Kutz: Ontologizing Metadata for AssistiveTechnologies - The OASIS Repository, In: First International Workshop on Ontologies in

Interactive Systems (Ontoract-08), Liverpool, UK, 2008.

2. Garcia A, Norena A, Betancourth A, Garcia L-J, Sequeda J-F: CMAPS supporting the de-velopment of OWL ontologies In: Poster Session, ISWC-08: 2008; 2008.

3. Garcia A, Garcia L-J, Villaveces J, Calderon G, Hepp M: OLS2OWL. A repository man-agement facility. In: 11th International Protg Conference, oral presentation: 2009; Am-

sterdam, Holland; 2009.4. Garcia A, Bateman J: The use of CMAPS supporting Knowledge Elicitation during the de-

velopment of OWL Ontologies: Lessons learnt. In: OASIS International Conference. Flor-ence, Italy; 2009.

5. Garcia, A., O'Neil, K., Gibson, F., Garcia, L.-J., Corcho, O., Lord, P. and Stevens, R.(2009) The Melting Point when developing ontologies. In Chen, H. and Wang, Y. (eds),

Semantic E-Science. Springer Verlag.

6. Kehagias D.D., Papadimitriou I., Hois J., Tzovaras D., Bateman J.A. (2008) A Methodo-logical Approach for Ontology Evaluation and Refinement, ASK-IT International Confe-

rence 2008.

7. Kutz, O. and I. Normann. (2009) Context Discovery via Theory Interpretation. IJCAI

Workshop on Automated Reasoning about Context and Ontology Evolution, ARCOE-09,Pasadena, California, 2009.

8. Normann, I., Frank Dylla, Joana Hois, Oliver Kutz, Mehul Bhatt, Mario Schmitt, WolfgangPutz, Sebastian Weber (2009) Ontologies and Reasoning for Ambient Assisted Living. On-


22/150




line proceedings of the 1st. OASIS International Conference, Florence, Italy.

http://www.oasis-project.eu/oasis_1_conf/A1_SESSION/4.NORMANN.pdf

9. Normann, I. and O. Kutz. (2009) Ontology Correspondence via Theory InterpretationWorkshop on Matching and Meaning, Automated development, evolution and interpreta-

tion of ontologies. Artificial Intelligence and Simulation of Behaviour Convention, AISB

2009, April 9th, 2009, Edinburgh, UK.Our Common Ontological Framework supports not only the development of ontologies,

but also the instantiation of the hyper-ontology. To date the methodology has been applied to

the development of 45 ontologies, with more than 15 domain experts distributed around

Europe and interacting via electronic means (including e-mail, the OASIS Wiki, and ontology

repository). Updates of this deliverable are scheduled for months M30, 40 and 44 of the OA-

SIS project.

1.4 Innovations resulting from the activities reported in this deliverableThe major OASIS innovations are summarised succinctly here and addressed in detail in the

chapters following. Innovations have been made in each of the three areas of concern in this

deliverable: i.e., advances in ontological engineering methodology, advances in the under-standing and definition of networked ontologies under the new construct of the hyper-

ontology, and advances in the practical instantiation of these concepts within an extensible

Open Hyper-Ontology Repository particularly geared towards OASIS requirements.

First, the OASIS ontological engineering methodology draws on previous work that ex-

plored the importance of involving communities of service and application developers within

the ontology development process. This previous work has primarily been of a theoretical na-

ture and has remained at the level of limited case studies or proposals. Only in isolated cases,

such as in the BioMedical domain, do we find substantial community involvementalthough

here too explicit methodologies remain somewhat loosely specified and are predicated on

consensus. The OASIS methodology takes these previous considerations to new levels of ex-

plicitness, attention to detail, and concrete evaluation. The resulting OASIS COF methodol-ogy represents the first complete wall-to-wall ontology development methodology that is

fully supportive of community-based, networked, heterogeneous ontologies that are oriented

first and foremost to the needs of individual applications or services while also encouraging

reuse and interoperability across those ontologies withoutenforcing consensus. Moreover, aweak point of almost all previous proposals for ontology methodologies has been their lack of

evaluation: it is rare that the methodologies can be tested in real situations of use. The OASIS

scenario provides an almost unique opportunity for such testing, due both to the diverse ser-

vices targeted and the diverse kinds of developers involved. First rounds of evaluation and

the consequences drawn are described below. As a consequence, we have also now developed

new software support tools geared specifically to the earlier stages of the development meth-odology, another OASIS first.

Second, whereas the need to provide networked ontologies has been circulating increas-

ingly in recent years, with some research and development projects explicitly taking this ori-

entation, the OASIS notion of the hyper-ontology combines new sources of input that make

the resulting hyper-ontology development significantly more general and powerfulthan all


23/150




previous proposals. As already sketched in the OASIS Description of Work, our approach is

informed throughout by already well developed formal work in the area of algebraic specifi-

cations. Prior to its involvement in OASIS, the Bremen Ontology Research Group had pio-

neered the use of this algebraic specification technology for ontology development; experi-

ments with constructing modular ontologies had also yielded promising results and some fun-

damental theoretical descriptions of connections between modules had been achieved. WithinOASIS this work has been applied for the first time to a detailed consideration and develop-

ment offully inter-connected heterogeneous ontologies making use of formal graph repre-

sentations for relating theories and the dependencies between theories (the so-called develop-

ment graph and its accompanying calculus). Explicitly relating the notion of the development

graph to that of networked ontologies gives us the OASIS definition of a hyper-ontologya

new richly structured meta-organisation over ontologies. We consider the OASIS hyper-ontology approach a strong contender for a new round of standardisation possibilities in the

areas of ontology meta-models and interoperability. Here the theoretical underpinnings will

continue to be developed both inside OASIS and within the broader research work of the

Bremen Ontology Research Group and its co-operations worldwide, while the increasingly

practical use and evaluation of the framework with concrete applications and service ontolo-

gies will remain within OASIS. The practical application of this abstract theoretical founda-tion is a unique contribution of OASIS at this time and represents an unrivalled opportunity

for pushing ontology development forward.

Third, there are several research and development initiatives at this time aiming at produc-

ing open ontology repositories; the most stable and mature of these is the BioPortal platform

developed for the BioMedical domain. Within OASIS, we have taken BioPortal and consid-

ered the precise extensions and mechanisms necessary for moving the BioPortal framework to

be supportive of the OASIS hyper-ontology notion. The result is a new repository, the OASIS

Ontology Repository for Assistive Technologies, that is the first instantiation of BioPortal

technology outside of the BioMedical domain. Within OASIS, we are using this repository as

an already functional computational platform that is being iteratively extended to include the

diverse range of inter-ontology connections identified in our hyper-ontology definition. Ittherefore represents the only open ontology repository at this time for which there exists adetailed development path towards full support of hyper-ontologies. Moreover, we will againuse the practical demands of the OASIS scenario to focus that development around working

use cases, services and applications so that theoretical development, computational realisa-

tions of that development in usable repositories, and practical applications for service support

and interoperability remain strongly coupled at all times.

Finally, within these major innovations there are several additional advances that have

been made in their support, including the new tools for ontology development that have been

produced as well as new guidelines for ontology metadata.

As evident from our description here and described at length in the chapters below, the

significant new steps taken in each of the areas addressed in this deliverable have only beenpossible by building on an already highly advanced state of the art, of which we also form a

part. For this reason we have characterised each innovation both in terms of what is the new

contribution of OASIS and in terms of what is being relied upon from elsewhere. In addition,

all of the ontology work described here is solidly situated within the international state of the


24/150




art in ontology research and in the corresponding ontology development communities. The

synergies thus created play a significant role in making the OASIS advancements possible

and will continue to play a role in furthering the dissemination of OASIS results across ontol-

ogy development communities worldwide. The focused efforts of OASIS ontology research

over the past two years have therefore contributed decisively to the advances in the field re-

ported here; these advances would not have been possible otherwise. Fig. 3 gives a graphicoverview of the main areas of innovation covered.

Fig. 3. Innovations as instantiations of components of the OASIS COF and their formative inputs


25/150




2 Evaluating ontology-engineering methodologies:Communities at the melting point

The maturity of a particular discipline can often be associated with the availability of stan-

dards and accepted methodologies (Fernandez, 1999); within the discipline of ontology engi-neering several methodologies have been proposed and applied. Some consensus has been

achieved across these methodologies in terms of orchestration of outcomes and deliverables

from the stages suggested and several methods and tools have been developed for ontology

engineering. Experience is also being gained from the increasing number of ontologies being

developed. All of these aspects are contributing to a more mature engineering process than

has been available in the past (De Leenheer and Mens, 2008).

Sure et al(Sure, 2003), Mirzaee (Mirzaee, 2004a),Garcia et al(Garcia et al., 2009b) andFernandez-Lopez (Fernadez-Lopez and Gomez-Perez, 2002) have highlighted some common-

alities to be found across many of the methodologies proposed hitherto. One interesting issue

that arises from this work is the evolution that reported methodologies have gone through as

well as the importance of evolution per se when developing ontologies. Established tech-niques from data schema evolution have been successfully adopted for managing the evolu-

tion of single ontologies and some consensus on a general ontology evolution process model

is beginning to emerge (De Leenheer and Mens, 2008). Much less explored, however, is the

problem of the evolution of highly interrelated ontologies (De Leenheer, 2009)i.e., concep-tually related and interdependent ontologies that together shape a network of conceptual

models. This is clearly a central requirement of OASIS ontologies and so needs to be devel-

oped further so as to provide adequate support for OASIS partners.

This chapter therefore presents an analysis of ontology methodologies that have been pro-

posed or applied from the perspective of communities of practice leading the development

process. We pay particular attention to methodological support for the involvement of com-

munities and to the importance of the life cycle when developing ontologies on a community

basis. As we will see in our comprehensive analysis in Section 2.2, several methodologieshave been proposed for ontology development but there has still been very little reuse acrossthose methodologies. Moreover, steps, stages, activities, methods and techniques are pre-

sented with little detail and software supporting the proposed steps is rarely made available.

As a consequence, more often than not methodologies are poorly instantiated; they consider

an ontology as a monolithic static structure and do not generally support the involvement of

the community. This situation notwithstanding, we need to reuse as much as is possible of this

previous work on methodologies for ontology engineering. Below, based on our critical

evaluation, we draw together those points that are suitable for re-use in order to build the

starting point for the methodological component of the OASIS Common Ontological Frame-

work that we define in the chapter following.

2.1 Introduction: learning from experienceClassification systems have been built over the years by many communities for many differ-

ent purposes; indeed, such efforts have been taking place at least since Aristotle (Sowa, 2000).


26/150




Particularly relevant for OASIS are models that can be considered precursors or examples of

ontology design where the involvement of communities has already been explored. These

models provide much that we can draw upon and apply to the distributed ontology develop-

ment targeted as part of the OASIS platform functionality.

One extensive area of experience that we build on is that of biomedical ontologies. Biolo-

gists have been building classification systems since before Linnaeus (1707-1778) and, be-cause of this long history, ontology efforts in the biomedical area have already gathered con-

siderable experience in distributed, community-based ontology development initiatives. The

main use of biological classification systems has been in facilitating the identification, nam-

ing, and grouping of living entities and biological material according to predefined criteria.

Work of this kind makes it possible for the community as a whole to be sure they know the

position in the taxonomy of any organism being examined and discussed. However, as de-

scribed by Garcia et al. (Garcia et al., 2006), domain experts in biological sciences are rarelyin one place; they tend to form virtual organisations, where experts with different but com-

plementary skills collaborate in building an ontology for a specific purpose. Moreover, the

structure of the collaboration does not necessarily incorporate central control and different

domain experts join and leave the network at any time, deciding on the scope of their contri-

bution to the joint effort. What is more, biological ontologies are also constantly evolving, not

only as new instances are added and new scientific knowledge is disseminated, but also as

new properties are required due to new applications of the ontology being investigated.

In many respects, we see the properties of this community as similar to that targeted within

OASIS. There also we have a diverse collection of stakeholders who participate in ontology

design on an ad hoc and application-oriented basis. Their main business aims are not to pro-duce ontologies, but to produce applications and services, drawing on their own and other on-

tologies to multiply the capabilities and possibilities of the products developed. Moreover, it

has been found that it is important to properly anchor the process of ontology development

among these stakeholders rather than considering it an external enterprise. The kind of rapid

evolution observed among biological ontologies is due in part precisely to the fact that the

ontology builders are also those who will ultimately use the ontology (Bada et al., 2004). Thisdemonstrates that involving the community of users within the ontology development process

is itself a highly worthwhile aim that can contribute significantly to the evolution of ontologi-

cal resources.

Considered concretely, there are several ontologies within the biomedical community that

have been developed with many of the properties and against a similar backdrop of commu-

nity use in varied applications and for varied purposes to that considered for OASIS. We can

use the experiences gained with respect to these ontologies for the design of the OASIS ap-

proach also. Two examples of such ontologies are the Gene Ontology (GO) (Ashburneret al.,2000) and the plant ontology (PO) (Pankaj et al., 2005). In both cases the communities con-cerned have played a vital role. The Gene Ontology has since been adopted as the de facto

standard ontology for describing the principle functional attributes of gene products, while thePlant Ontology Consortium (POC) (www.plantontology.org) is a collaborative effort that

brings together several plant database administrators, curators and experts in plant systemat-

ics, botany and genomics. The ontologies of both GO and PO focus on providing controlled

vocabularies, facilitating cross-database queries, and having strong community involvement


27/150




throughout their development life-cycle. These are therefore in many respects excellent work-

ing role models for the use of ontolo

Documents

Common hyper-ontological frame- work