Common Hyper-Ontological Frame - Work

Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
OASIS – Open architecture for Accessible

Services Integration and Standardization
GRANT AGREEMENT # 215754
OASIS common hyper-ontological frame-

work (COF)
Deliverable No. D1.2.1
SubProject 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 than John Bateman, Alexander Castro, Immanuel Nor-
one company provide it together) mann, Omar Pera (UniBremen), Leyla Garcia, Jose-
Maria Villaveces
Status F
(F: final; D: draft; RD: revised draft):
Originating File Name: OASIS-D121-V1R-full.doc
Project start date and duration 30 January 2009, 44Months
UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 1

Document Revision History D1.2.1
2009.06.30 D1.2.1-v1.doc: preliminary version as planned in the

Description 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 all

aspects of the COF as scheduled.
2010.01.31 Revised Draft finalised after QC feedback with

additional input: this document.
!
List of Main Abbreviations D1.2.1
CASL Common Algebraic Specification Language
CMAP 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 2008
http://www.w3.org/TR/xml/

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.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!Protégé!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!

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!Protégé!...................................................................................................!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!
!!

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!

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, Protégé, 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!

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 possessing
the 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 rather diverse 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
of Independent Living (including at least a nutritional advisor, an activity coach, a brain and
skills 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 levels—in 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.

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 (Fernandéz et al., 1997; Guarino et al., 1993; Uschold, 1996; Uschold and
Gruninger, 1996; Uschold et al., 1998). As more ontologies developed, a wider community
came 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 recognised—leading to a broad
variety of tools, methods and results. In some application areas, the development of ontolo-
gies was taken up by communities as a whole—thus 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 for de 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 ontology’s 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 cannot
be 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))

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 area
and 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 Objectives

1.1.1 Why 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 and
McGuinness, 2001a):

! 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 representation
of the information itself.
1.1.2 Why 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 of
affairs 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-

ment can be pushed higher if the information being matched is made more consistent. For
this, methodology can play a crucial role.
1.1.3 Why 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 be
seen 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 taking
advantage (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 applications
running 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:

! 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 import relation where the target ontology imports all
knowledge 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 the
plug-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 operation—for 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-

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 a
television. 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 modularity—a 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 complexity—another 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. This
means:

! for a service provider: the more difficult it is to find the right ontology for aligning the
web 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 possible
inconsistencies 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 ontology—updates 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. they
might 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 their understandability, maintainability, and even-
tually their quality. 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.

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 to
reduce complexity and to facilitate heterogeneous modelling
1.1.4 Why communities?

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 the
knowledge engineer becomes one of a facilitator of collaboration and communication among
domain experts rather than being a leader or driver of a project—as 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 et
al., 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 by
the 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 be
seen 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

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 defines
communities of practice as follows:
“Communities of practice are the basic building blocks of a social learning system because they are the
social ‘containers’ of the competences that make up such a system… Communities of practice define
competence 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 sense
of joint enterprise. To be competent is to understand the enterprise well enough to be able to contribute
to 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 is
to 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 resources—language, 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; Wenger et 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 and
grounded intuition that provides an environment and framework for evaluating and incorporating new
experiences 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 Protégé
(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 Deliverable

The 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

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-

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 support
and 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, Protégé,
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 of ontology metadata. Metadata provide information about individual ontologies

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 the
full 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 with
this 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 Assistive
Technologies - 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 Protégé 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, Wolfgang
Putz, Sebastian Weber (2009) Ontologies and Reasoning for Ambient Assisted Living. On-

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 Interpretation
Workshop 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 deliverable

The 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 involvement—although
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 without enforcing consensus. Moreover, a
weak 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 powerful than all

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. Within
OASIS this work has been applied for the first time to a detailed consideration and develop-
ment of fully 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-ontology—a
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. It
therefore represents the only open ontology repository at this time for which there exists a
detailed development path towards full support of hyper-ontologies. Moreover, we will again
use 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 been
possible 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

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 graphic
overview of the main areas of innovation covered.
Fig. 3. Innovations as instantiations of components of the OASIS COF and their formative inputs

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) and
Fernandez-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 methodologies
have been proposed for ontology development but there has still been very little reuse across
those 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 experience

Classification 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).

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 rarely
in 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). This
demonstrates 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) (Ashburner et 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 the
Plant 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

throughout their development life-cycle. These are therefore in many respects excellent work-
ing role models for the use of ontologies within OASIS.
Because the biomedical domain is knowledge-intensive and highly collaborative, particular
tools and methods have also been developed to support ontology development within this set-
ting. The Open Biomedical Ontologies (OBO) Foundry (Smith et al., 2007) provides a par-
ticularly interesting scenario in which collaboration is crucial. The OBO Foundry aims to col-
lect a family of public domain ontologies that, by design and revision, work together to facili-
tate information sharing and data interpretation in the health and biological sciences. We can
see the aim of the OASIS platform in precisely these terms, although for the areas of assistive
services rather than biomedical information. Similar problems arise in both cases. Since the
biomedical domain is so highly interconnected, it is difficult to avoid the situation that do-
main ontologies overlap with each other. Moreover, software making use of an ontology may
require more than a single domain ontology to provide the services intended. Typically, in
these types of scenarios, it is therefore necessary to integrate multiple ontologies into a single
coherent narrative.
In order to integrate or re-use specific domain ontologies following this kind of “building-
block” approach, there has to be a high level structure or common “scaffold” into which dif-
ferent parts of different domain ontologies may be “plugged”. One way of making such a
framework that has long been investigated in diverse ontology communities is by drawing on
upper ontologies as fundamental components of the integrative effort. Upper level ontologies
provide a domain independent conceptual model that aims to be highly re-usable across spe-
cific domain applications. Most upper ontologies provide a general classification intended to
make it easy to re-use, extend and maintain the existing ontologies required by a particular
application. Methodologically, therefore, it is desirable that ontology development method-
ologies should provide general guidelines for the use of appropriate upper level ontologies.
These guidelines should cover the documentation of (i) the design decisions and the justifica-
tion for choosing one upper ontology over another, and (ii) examples that illustrate how they
are used in the conceptualisation of a particular domain. In the biomedical case, For instance,
the biomedical community, OBO and some related efforts are currently studying the adoption
of one particular upper level ontology, the Basic Formal Ontology (BFO) of Smith and col-
leagues (Grenon and Smith, 2004; Smith, 2004). Other examples of upper level ontologies
include: DOLCE (http://www.loa-cnr.it/DOLCE.html) (Masolo et al., 2003b) and GFO
(http://www.onto-med.de/en/theories/gfo/) (Hoehndorf et al., 2007). The appropriateness for
OASIS of the upper ontologies on offer will continue to be evaluated throughout ontology
development: currently, based on our previous experiences and the state of formalisation
available within our logical tools (Bateman et al., 2007), we are orienting development most
closely towards the DOLCE ontology.
The biomedical domain is not the only domain where ontologies are being developed and
applied. Within the Geographical Information Science area there is also a long history of con-
sidering ontologies; this is also motivated by the common need to achieve interoperability be-
tween very different kinds of information. Maps as traditionally pursued in the geographical
sciences usually consist of several distinct layers of information, with different applications
drawing on that information (Egenhofer, 2002; Fonseca et al., 2002; Frank, 2008; Frank,
2001). Interoperability across distinct layers is always an issue. Moreover, there is also a very

active area of development in Geographic Information Science concerned with promoting

standards for geographic information representation. Interestingly, most of these standards
share the aim of ontologies of providing clear and well-defined agreed vocabularies of terms,
but are not themselves yet seen in ontological terms. They are also commonly community-
driven efforts—particularly in the case of organisations such as the Open Geospatial Consor-
tium, one of the major drivers of standards in the area. This relates well to the OASIS situa-
tion, where we also find in many of the application areas for which services are being defined
standards and/or service descriptions which are presented informally or in a non-ontological
form such as UML or XML schemas. We see, therefore, a similar demand: information in
non-ontological form needs to be converted progressively and together with the respective
developer communities, into a form compatible with that required for ontology-based solu-
tions.
Finally, The Semantic Web (SW) itself is a vision in which the current, largely human-
accessible Web is to be annotated using ontologies so that the vast content of the Web can be
made available for machine processing (Berners-Lee, 1999; Sure, 2003; W3C, 2007). Within
the SW, just as within the biomedical domain and the GeoScience area, the involvement of
communities of practice is crucial, not only for the development, but also for the maintenance
and evolution, of ontologies. A further initiative that may be positioned here and which has
also explicitly addressed the problem of establishing larger-scale collections of ontologies and
of supporting reusability is that of the EU FP6 large-scale integrating project NeON
(http://www.neon-project.org). NeON has aimed to advance the state of the art in using on-
tologies for real-world semantic applications in distributed organizations. The project targets
in particular an improvement in the capability to handle multiple networked ontologies that
exist in particular contexts, which are created collaboratively, and which might be highly dy-
namic and constantly evolving. As we describe in more detail below, NeON has set a new
high-water mark for networked ontology design and so we also build on the NeON experience
in our design of the OASIS ontology infrastructure. Within NeON, however, less attention
was applied to detailed methodological issues for ensuring development and use of ontologies
by diverse potential user groups; this aspect needs further development within OASIS.
Some methods proposed within the field of Knowledge Engineering (KE) are also applica-
ble when building ontologies and so we have drawn on these equally. For instance, Sowa
(Sowa, 2000) defines several steps to be taken when representing knowledge and these have
already been incorporated in some of the methodologies for developing ontologies investi-
gated in this chapter. Furthermore, the KE knowledge life cycle, as described by Sure (Sure,
2003), is similar to that reported by Garcia (Garcia, 2007a) for ontologies being developed by
communities of practice. Ontology development thus inherits methods and techniques from
Knowledge Engineering. The experiences from Knowledge Engineering have not always been
applied, however, when developing ontologies; valuable methodologies such as KADS, a
structured methodology for the development of knowledge based systems (Schreiber et al.,
1993), have been drawn on insufficiently. Nevertheless, KE methodologies provide in general
rather little detail and focus primarily on the use of the knowledge by a software system,
thereby looking more at the whole process of knowledge use rather than on the development
of an ontology itself (Sure, 2003)—i.e., ontologies are only employed to capture and represent
knowledge that may be subsequently used by a software layer that delivers the functionalities

desired and are less in the centre of attention themselves. A general-purpose methodology
needs to do more than provide ontology engineers with a broad perspective of the stages of
the development process, however. Detailed examples of use should be included for those
stages, outcomes, deliverables, methods and techniques; all of which form part of an ontology
life cycle (Garcia, 2007b; Sure, 2003).
To summarise the discussion so far: several approaches have been reported for developing
ontologies; some of them provide insights when developing de novo ontologies, whereas oth-
ers pay more attention to extending, transforming and re-using existing ontologies. Independ-
ently from the focus, neither of these methods and methodologies has yet been standardised in
a way that makes it clear for the ontology developer how to address the problem at hand. The
process of constructing an ontology usually involves gathering terminology and organizing it
into a taxonomy, from which key concepts are identified and relationships drawn, to create a
concrete ontology. Case studies have been described for the development of ontologies in di-
verse domains but with relatively weak orientation to generic and reusable design methodolo-
gies. This has resulted in a proliferation of ontologies, developed in different ways and often
presenting overlap in terminology or application domain.
This tendency can be observed even in the biomedical domain, despite the fact that this is a
situation that the OBO Foundry is explicitly designed to avoid. Although OBO is a commu-
nity effort designed in part to ensure orthogonality and to overcome the above issues by pro-
viding a set of design principles (http://www.obofoundry.org/crit.shtml) to which domain on-
tologies should adhere (Smith et al., 2007), the OBO Foundry does not suggest a development
process by which these principles can be met. It is therefore necessary at this time to evaluate
more generally the state of the art in ontology methodologies in order to see how these gaps
can be filled. Moreover, not only are there several different methodologies, but there are also
numerous software tools aiming to assist knowledge engineers during the process. A precise
abstract definition for methods, techniques, outcomes and deliverables from the different de-
velopmental stages is required, as well as documentation and examples enabling those respon-
sible for services to construct and implement corresponding ontologies.
2.2 Methods and methodologies for building ontologies

The following sections of this chapter describe the evaluation of methodologies that have
been proposed and applied within the domain of ontology development. The notational con-
ventions used within this chapter are presented along with the methodology review criteria
used to compare and evaluate the methodologies proposed. The results of the evaluation of
ontology methodologies are presented and discussed along with the conclusions drawn from
this work for the subsequent design of the OASIS Common Ontological Framework method-
ology component. To date, no standard methodology for building ontologies has been agreed
upon, either from the pool of available general-purpose methodologies or by creating new
ones.
2.2.1 Methodology review criteria
Within this deliverable we assume Schulze-Kremer's definition of an ontology as “a concise

and unambiguous description of what principal entities are relevant in an application domain

and how they can relate to each other” (Schulze-Kremer, 1998). The chapter also closely
follows the terminological recommendations given by the Institute of Electrical and
Electronics Engineers (IEEE) for methodologies, techniques, and methods (IEEE, 1996;
IEEE, 1998).
We understand a methodology as a “comprehensive integrated series of techniques or
methods creating a general system theory of how a class of thought-intensive work ought to
be performed” (IEEE, 1998). Methodologies are composed of both techniques and methods.
A method is an “orderly” process or procedure used in the engineering of a product or per-
forming a service (IEEE, 1991). A technique is a “technical and managerial procedure used
to achieve a given objective” (IEEE, 1998). Thus methodologies bring together techniques
and methods in a way orchestrated such that the work can be done.
A knowledge engineer is understood to be a person who applies knowledge engineering
techniques to transfer human knowledge into an appropriate machine-readable representa-
tion—not only by modelling the knowledge and problem solving techniques of the domain
expert into the system, but also by promoting collaboration amongst domain experts (Garcia,
2007b; Kendal and Creen, 2006; Negnevitsky, 2004).
Several ontology development methodologies are analyzed in this chapter. The criteria un-
der which these methodologies are evaluated is described in detail in Section 2.2.2. We derive
these criteria from the work of Fernandez (Fernandez, 1999), Mirzaee (Mirzaee, 2004a) and
Corcho et al. (Corcho et al., 2003). These methodologies are the most developed and relevant
for the work carried out within OASIS. The target is to produce a concrete methodology for
guiding all our work with the respective OASIS cooperation partners for the staged develop-
ment of networked, community-based ontologies in all the areas necessary for the project.
2.2.2 Analysis of proposed methodologies: criteria definitions
The criteria used for assessing the applicability of components of the methodologies consid-
ered are as follows.
C1. Inheritance from knowledge engineering. As most ontology building methodolo-
gies are inspired, at least indirectly, by work done in the field of Knowledge Engineer-
ing (KE) to create methodologies for developing knowledge-based systems (KBS) this
criterion considers the influence traditional KE has had on the methodologies studied.
C2. Detail of the methodology. This criterion is used to assess the clarity with which
the methodology specifies the orchestration of methods and techniques.
C3. Strategy for building the ontology. This should provide information about the
purpose of the ontology, as well as the availability of domain experts. There are three
main strategic lines to consider: i) the application of the ontology; ii) the use and type of
domain experts available; and iii) the type of ontology to be developed. These three as-
pects are defined in more detail from C3.1 to C3.3.
C3.1 Application of the ontology
This criteria describes how tightly coupled the ontology is going to be in relation
to the application within which, in principle, it should be used. This is often

evaluated via competency questions. Competency questions can typically be clas-

sified in two forms: informal competency questions (natural language) and formal
competency questions. The criteria for describing the level of application en-
gagement are described as follows:
C3.1.1. Application-dependent: The ontology is built on the basis of an ap-
plication knowledge base, by means of a process of abstraction (Fernandez,
1999).
C3.1.2. Application-semi dependent: Possible scenarios of ontology use are
identified in the specification stage (Fernandez, 1999).
C3.1.3. Application-independent: The process is totally independent of the
uses to which the ontology will be put in knowledge-based systems, or any
software layer making use of the ontology.
C3.2 Domain experts
This criterion outlines the level of perceived expertise of the individuals consulted
within the ontology development process. A domain expert can be graded in the
following manner:
C3.2.1. Specialised domain experts: those with an in-depth knowledge of
their field. Within the biological context, for example, these are usually re-
searchers with considerable laboratory experience, very focused within a
narrow domain of knowledge. Having the specialised domain expert helps
define very specific concepts within an ontology; this can lead to a strategy
for identifying concepts known as the bottom-up approach (see C4.1).
C3.2.2. Broader-Knowledge domain experts: those who have a general
knowledge or a higher level view of the domain(s). Having this kind of do-
main expert usually facilitates capturing concepts more related to high-level
abstraction and general processes, rather than specific vocabulary describing
those processes. The ontology may be built from high-level abstractions
downwards to specifics. This approach is known as the top-down strategy
for identifying concepts (see C4.2).
C3.3. Ontology Type
The ontology type criterion classifies the ontology being developed into the fol-
lowing types or categories (Mizoguchi et al., 1995; Van Heijst et al., 1996);
C3.3.1. Top-level ontologies: These describe very general concepts like
space, time, event, which are independent of a particular problem domain.
Such unified top-level ontologies aim at serving large communities (Sure,
2003). These ontologies are known as foundational ontologies, also com-
monly called upper ontologies as mentioned above.
C3.3.2. Domain ontologies: These are focused within a particular domain
and describe specific vocabulary.

C3.3.3. Task ontologies: These describe vocabulary related to tasks, proc-

esses, or activities.
C3.3.4. Application ontologies: As Sure (Sure, 2003) describes them, appli-
cation ontologies are specialisations of domain and task ontologies as they
form a base for implementing applications with a concrete domain and
scope.
C4. Strategy for identifying concepts. There are three strategies regarding the con-
struction of the ontology and the kinds of terms it is possible to capture (Uschold and
Gruninger, 1996):
C4.1. Bottom-up: work from the most concrete or specific concepts to the most
abstract concepts. (Fernadez-Lopez and Gomez-Perez, 2002; Lakoff, 1987;
Uschold and Gruninger, 1996).
C4.2. Top-down: work from the most abstract to the more domain/application
specific concepts (Fernandez, 1999).
C4.3. Middle–out: work from the most relevant to the most abstract and most do-
main/application specific concepts (Fernandez, 1999; Lakoff, 1987; Mizoguchi et
al., 1995).
C5. Recommended life cycle. Analysis of whether the methodology implicitly or ex-
plicitly proposes a life cycle (Fernandez, 1999).
C6. Recommended methods and techniques. This criterion evaluates whether or not
there are explicit methods and techniques given as part of the methodology. This is
closely related to C2. An important issue to be considered is the availability of software
supporting either the entire methodology or a particular method of the methodology.
This criterion also deals with the methods or software tools available within the meth-
odology for representing the ontology, for example, in OWL (Ontology Web Language)
(http://www.w3.org/TR/owl-ref/), or RDF (Resource Descriptive Framework)
(http://www.w3.org/RDF/).
C7. Applicability. As knowledge engineering is still in its infancy it is important to
evaluate the methodology in the context of those ontologies for which it has been ap-
plied.
C8. Community involvement. As has been pointed out before in this chapter, it is im-
portant to know the level of involvement of the community. Phrasing this as a question,
is the community a consumer of the ontology or is the community taking an active role
in its development?
C9. Knowledge elicitation. Knowledge elicitation is a major bottleneck when repre-
senting knowledge (Cooke, 1994). It is therefore important to know if the methodology
assumes knowledge elicitation to be an integral part of the methodology; does it de-
scribe the elicitation techniques?
2.2.3 Analysis of proposed methodologies: criteria application

Here, for each methodology selected, we apply the classification criteria set out above in or-
der to evaluate the opportunities offered for re-use of aspects of those methodologies for the
particular problems of community-based, modular ontology design as required within the
OASIS application scenarios. The engineering methodologies selected for analysis are:
! the Enterprise Methodology proposed by Uschold and King (Uschold and King, 1995);
! the TOVE Methodology proposed by Gruninger and Fox (Gruninger and Fox, 1994b);
! the Bernaras methodology proposed by Bernaras et al. (Bernaras et al., 1996);
! the METHONTOLOGY methodology proposed by Fernandez et al. (Fernandéz et al.,
1997);
! the SENSUS methodology proposed by Swartout et al. (Swartout et al., 1997);
! the DILIGENT methodology proposed by Pinto et al. (Pinto et al., 2004a; Vrandecic et
al., 2005);
! the GM methodology proposed by Garcia et al. (Garcia et al., 2006);
! the iCAPTURer Methodology proposed by Good et al. (Good et al., 2006);
! the DOGMA-MESS methodology proposed by De Moor et al. (De Moor et al., 2006);
! and the NeON methodology, proposed by Suarez-Figueroa et al. (Suarez-Figueroa et
al., 2008)
This list may be extended in the subsequent planned updates of this deliverable, but is al-
ready considered adequate and representative of the relevant state of the art.
2.2.3.1 The Enterprise Methodology

Uschold and King proposed a set of four activities that are listed here and illustrated in Fig. 4.
! Identify the purpose and scope of the ontology
! Build the ontology, for which they specify three activities
o Knowledge capture
o Development-coding
o Integration with other ontologies
! Evaluate the ontology
! Document the ontology

Fig. 4. Uschold and King methodology
C1. The methodology does not explicitly inherit methods from knowledge engineering,
although Uschold and King identify steps that are in principle related to some method-
ologies from knowledge engineering. Neither a feasibility study nor a prototype method
is proposed.
C2. Stages are identified, but no detail is provided. In particular the “Ontology Coding”
“Integration” and “Evaluation” sections are presented in a superfluous manner
(Mirzaee, 2004a).
C3. Limited information is provided. The proposed method is application-independent
and very general, in principle it is applicable to other domains. The authors do not pre-
sent information about the kind of domain experts they advise working with.
C4. Uschold and Kind do not provide a clear criterion for the selection of either ap-
proach. For Uschold and King the disadvantage of using the top-down approach is that
by starting with a few general concepts there may be some ambiguity in the final prod-
uct. Alternatively, with the bottom-up approach too much detail may be provided, and
not all this detail may be used in the final version of the ontology (Uschold and
Gruninger, 1996). This in principle favours the middle-out approach proposed by La-
koff (Lakoff, 1987). The middle-out is not only conceived as a middle path between
bottom-up and top-down, but also relies on the understanding that categories are not
simply organised in hierarchies from the most general to the most specific, but are
rather organised cognitively in such a way that categories are located in the middle of
the general-to-specific hierarchy. Going up from this level is the generalisation and go-
ing down is the specialisation (Lakoff, 1987; Mirzaee, 2004a).
C5. No life cycle is recommended.
C6. No techniques or methods are recommended. The authors mention the importance
of representing the captured knowledge but do not make explicit recommendations as to
which knowledge formalism to use. This methodology does not support any particular
software as a development tool. The integration with other ontologies is not described,

nor is any method recommended to overcome this issue, nor is whether this integration
involves extending the generated ontology or merging it with an existing one explained.
C7. The methodology was used to generate the Enterprise ontology (Uschold et al.,
1998).
C8. Communities are not involved in this methodology.
C9. For those activities specified within the building stage the authors do not propose
any specific method for representing the ontology (e.g. frames, description logic, etc).
The authors place special emphasis on knowledge elicitation. However, they are not
specific in developing this further.
2.2.3.2 The TOVE Methodology
The Toronto Virtual Enterprise (TOVE) methodology involves building a logical model of the
knowledge that is to be specified by means of an ontology. The steps involved as well as their
corresponding outcomes are illustrated in Fig. 5.
C1. The methodology is heavily influenced by the development of knowledge based
systems using first order logic (Corcho et al., 2003).
C2. No specifics are provided on the activities involved.
C3. The TOVE methodology emphasises competency questions as well as motivating
scenarios as important components in their methodology. This methodology is applica-
tion-semi dependent as specific terminology is used not only to formalise questions but
also to build the completeness theorems used to evaluate the ontology. Once the compe-
tency questions have been formally stated, the conditions under which the solutions to
the questions must be defined should be formalised. The authors do not present infor-
mation about the kind of domain experts they advise working with.
C4. This methodology adopts a middle-out strategy.
C5. No indication about a life cycle is given.
C6. The importance of competency questions is emphasised. However, they do not pro-
vide techniques or methods to approach this problem.
C7. The Toronto Virtual Enterprise ontology was built using this methodology (Fox,
1992).
C8. Communities are not involved in this methodology.
C9. No particular indication for eliciting knowledge is given.

Fig. 5. The TOVE methodology
2.2.3.3 The Bernaras methodology

Bernaras’ work was developed as part of the KACTUS (Bernaras et al., 1996) project which
aimed to investigate the feasibility of knowledge reuse in technical systems.
C1. This methodology is thus heavily influenced by knowledge engineering.
C2. Limited detail about the methodology is provided.
C3. This methodology is application-dependant. As the development of this methodol-
ogy took place within a larger engineering effort ontologies were being developed hand-
in-hand with the corresponding software. This implies that domain experts were being
used for both tasks, for requirements interviews and studies as well as for ontology de-
velopment. This however, does not mean that domain experts were taking an active role.
The authors present very little information about the kind of domain experts they advise
working with.
C4. This methodology adopts a bottom-up approach (Corcho et al., 2003).
C5. As the ontology is highly coupled with the software that uses it, the life cycle of the
ontology is the same as the software life cycle.
C6. For the specific development of the ontology no particular methods or techniques
are provided. However, as this methodology was meant to support the development of
an ontology at the same time as the software it is reasonable to assume that some soft-
ware engineering methods and techniques were also applied to the development of the
ontology.
C7. It has been applied within the electrical engineering domain.

C8. Communities are not involved in this methodology

C9. No particular indication for knowledge elicitation is provided.
2.2.3.4 The METHONTOLOGY methodology
The authors of METHONTOLOGY aim to define a standardisation of the ontology life cycle
(development) with respect to the requirements of the Software Development Process (IEEE
1074-1995 standard) (Mirzaee, 2004a).
C1. METHONTOLOGY has its roots in knowledge engineering.
C2. Detail is provided for the ontology development process; Fig. 3 illustrates the
methodology. It includes the identification of the ontology development process, a life
cycle based on evolving prototypes, and particular techniques to carry out each activity
(Corcho et al., 2003). This methodology heavily relies on the IEEE software develop-
ment process as described in (IEEE, 1998). Gomez-Perez et al. (Gomez-Perez et al.,
2004) consider that all the activities carried out in an ontology development process
may be classified into one of the following three categories:
! Management activities: Including planning, control and quality assurance. Planning
activities are those aiming to identify tasks, time and resources.
! Development activities: Including the specification of the states, conceptualisation,
formalisation, implementation and maintenance. From those activities related to the
specification knowledge engineers should understand the context in which the on-
tology will be used. Conceptualisation activities are mostly those activities in which
different models are built. During the formalisation phase the conceptual model is
transformed into a semi-computable model. Finally, the ontology is updated, and
corrected during the maintenance phase (Fernadez-Lopez and Gomez-Perez, 2002).
! Support activities: these include knowledge elicitation, evaluation, integration,
documentation, and configuration management.

Fig. 6. METHONTOLOGY. Reproduced with permission from (Corcho et al., 2003)
C3. Application independent. No indication is provided as to the kind of domain experts

they advise working with. In principle METHONTOLOGY could be applied to the de-
velopment of any kind of ontology.
C4. This methodology adopts a middle-out approach.
C5. METHONTOLOGY adopts an evolving-prototype life cycle.
C6. No methods or techniques recommended. METHONTOLOGY heavily relies on
WebODE (Arpirez et al., 2003b) as the software tool for coding the ontology. However,
this methodology is in principle independent from the software tool.
C7. This methodology has been used in the development of the Chemical OntoAgent
(Arpirez et al., 1998) as well as in the development of the Onto2Agent ontology
(Arpirez et al., 1998).
C8. No community involvement is considered.
C9. Knowledge elicitation is part of the methodology. However no indication is pro-
vided as to which method to use.
2.2.3.5 The SENSUS methodology
The SENSUS-based methodology (Swartout et al., 1997) is a methodology built on experi-
ences gathered while building the SENSUS ontology. SENSUS was a broad-scale ontology
intended to support conceptual, or interlingua-based, machine translation in the Mikrokosmos
and Pangloss machine translation projects (Beale and Nirenburg, 1997; Hovy and Knight,
1993). The ontology itself combined the linguistically motivated Penman Upper Model
(Bateman et al., 1990) with the lexico-conceptually motivated Mikrokosmos (Nirenburg et

al., 1987) ontology to provide a backbone for subsequent extension by concepts drawn from
WordNet (Fellbaum, 2000), machine-readable dictionaries and, later, text-mining. The result
was a 70,000-node terminology taxonomy that could be used as a framework into which addi-
tional knowledge relevant for translation could be placed (ISI, 2007).
C1. SENSUS is not influenced by knowledge engineering as this methodology mostly
relies on methods and techniques from text mining.
C2. Although there is extensive documentation for those text mining techniques and de-
veloping structures for conceptual machine translation (Knight and Chander, 1994;
Knight and Luck, 1994; Knight and Graehl, 1997) no detail is provided as for the “how”
to build the ontology beyond introspection and the lexical and grammatical guidelines
inherited from its core seed ontologies.
C3. As SENSUS makes extensive use of both text mining and conceptual machine
translation, the methodology as such is application semi-independent. The methods and
techniques proposed by SENSUS may, in principle, be applied to several domains.
C4. SENSUS follows a bottom-up approach. Initially instances are gathered, as the
process moves forward abstractions are then identified.
C5. No life cycle is identified; from those reported experiences the ontology is deployed
on a one-off basis.
C6. Methods and techniques are identified for gathering instances. However, no further
detail is provided.
C7. SENSUS was the methodology followed for the development of semantic lexicons
for concept-based machine translation (cf. Pangloss and Mikrokosmos (Frederking et
al., 1993)), as well as knowledge-based applications such as that for the ‘air campaign
planning’ ontology (Valente et al., 1999).
C8. No community involvement is considered.
C9. Knowledge elicitation is not considered explicitly.
2.2.3.6 DILIGENT
Diligent (DIstributed, Loosely-controlled and evolvInG Engineering of oNTologies) was
conceived as a methodology for developing ontologies on a community basis. Although the
DILIGENT approach assumes the active engagement of a community of practice throughout
the entire process, it does not give extensive details. Some particularities may be found re-
ported for those cases in which DILIGENT has been used, for instance (Pinto et al., 2004b).
C1. DILIGENT is influenced by knowledge engineering as this methodology has been
developed assuming the ontologies will be used by knowledge-based systems. How-
ever, DILIGENT introduces novel concepts such as the importance of the evolution of
the ontology and the participation of communities within the development and life cycle
of the ontology.
C2. DILIGENT provides some details specifically for those developments in which it
has been used.

C3. DILIGENT is application-dependant. There is no indication about the kind of do-

main experts they advise working with.
C4. The selection between top-down, bottom-up or middle-out is problem dependent.
No indication is given as to which strategy would be best to follow.
C5. DILIGENT assumes an iterative life cycle in which the ontology is in constant evo-
lution.
C6. In principle DILIGENT does not recommend methods or techniques. By the same
token DILIGENT is not linked to any software supporting either development or col-
laboration.
C7. Some cases for which DILIGENT has been used have been reported, for instance
the study of legal cases (Tempich et al., 2005).
C8. The involvement of communities is considered in this methodology.
C9. Although knowledge elicitation is considered in this methodology no special em-
phasis is placed on it.
2.2.3.7 The GM methodology
The GM methodology emphasises knowledge acquisition when developing ontologies within
decentralized settings. Similar to DILIGENT, the GM methodology was engineered for sce-
narios in which geographically distributed domain experts were working together on the same
ontology. The GM methodology makes use of conceptual maps to support the acquisition of
knowledge. In contrast to the DILIGENT methodology, the GM methodology provides a de-
tailed description of the process applied within their development scenario.
C1. GM applies knowledge engineering principles.
C2. A detailed description the methods and techniques used are provided.
C3. GM is application-dependant. GM assumes the participation of both specialised and
broader-knowledge domain experts.
C4. A top-down approach is applied within GM.
C5. GM assumes an iterative life cycle in which the ontology is in constant evolution
C6. Methods and techniques for some of the stages of the development process are rec-
ommended.
C7. GM has been used within the biomedical domain (Garcia et al., 2006).
C8. GM assumes an active participation of the community.
C9. GM has an emphasis on knowledge elicitation.
2.2.3.8 The iCapturer methodology
The iCapturer methodology (Good et al., 2006) also emphasises knowledge acquisition within
decentralized settings. However, unlike GM and DILIGENT, iCapturer makes use of text-
mining approaches, such as text-to-onto, to identify important terms and to suggest candidate
ontological relationships between them.

C1. The iCAPTURer approach has received little influence from knowledge engineer-
ing.
C2. The iCAPTURer methodology is very specific in terms of the orchestration of
methods used. The first step is term and relationship extraction from text containing
domain knowledge. The second is web-based, massively collaborative correction, re-
finement, and extension of the automatically extracted concepts and relationships. The
second step may be divided into phases of knowledge elicitation, evaluation, and aggre-
gation.
C3.1 Application of the ontology: Application-independent.
C3.2 Domain experts: The methodology is intended to make use of knowledge
gathered from all levels of domain experts. However, it is assumed that the pool
of experts does contain all of the knowledge that is intended to be represented in
the ontology.
C3.3. Ontology Type: The methodology is best suited for domain ontologies.
C4. Strategy for identifying concepts: The strategy for identifying concepts is to ex-
tract representative terms automatically from text. Though this will typically result in
what appears to be a more bottom-up approach, different bodies of text will produce dif-
ferent results.
C5. Recommended life cycle: The recommended life cycle is: 1) identify a domain of
knowledge to be represented in an ontology 2) identify a corpus thought to contain that
knowledge 3) apply text-mining approaches, such as text-to-onto, to identify important
terms and to suggest candidate ontological relationships between them 4) define user-
interfaces for correcting and extending this knowledge 5) assemble a broad array of ex-
perts in the domain and engage them in using the interface to improve the ontology 6)
evaluate the quality of each contributor based on expected ‘correct’ interactions with the
knowledge elicitation system 7) weight their contributions based on this level of quality
8) aggregate the contributions of all of the experts so that a candidate ontology can be
generated 9) iterate and refine as needed.
C6. Recommended methods and techniques: The methodology specifies the process
but does not suggest any specific method. Several text-mining algorithms or knowledge
gardening interfaces might be applied depending on the domain and the community.
C7. Applicability: iCAPTURer has not yet been applied in real scenarios.
C8. Community involvement: The community is assumed to develop the ontology.
C9. Knowledge elicitation: Knowledge elicitation is an integral part of the methodol-
ogy. iCAPTURer describes some techniques for KE, but there is also wide room for ex-
pansion and adaptation of other methods.
2.2.3.9 DOGMA MESS
C1. The DOGMA MESS approach has received little influence from knowledge engi-
neering.

C2. The DOGMA MESS methodology is described as a meta-methodology that can ac-
commodate many different ontological methodologies and technologies. The orchestra-
tion of methods and techniques is not addressed by this methodology; according to the
authors “There is thus not one right way of designing these macro/micro processes”.
C3.2 Domain experts: Domain experts are expected to participate.
C4. Strategy for identifying concepts: No method or technique is explicitly provided.
DOGMA MESS apparently assumes a middle-out approach.
C5. Recommended life cycle: It is acknowledged an evolutionary life cycle; however,
no details for the structure of the evolution are provided.
C6. Recommended methods and techniques: The methodology specifies the process
as a whole, highly abstract. It does not suggest any specific methods/techniques.
C7. Applicability: DOGMA MESS has to the best of our knowledge not yet been ap-
plied in real scenarios.
C8. Community involvement: The community is assumed to be involved. DOGMA
MESS aims to make “the complex and fuzzy shared meaning evolution process of a col-
laborative community as effective and efficient as possible”.
C9. Knowledge elicitation: Knowledge elicitation considered by the methodology. No
methods or techniques are provided.
2.2.3.10 NeON
C1. The NeON approach has received considerable influence from knowledge engineer-
ing.
C2. The NeON methodology provides detailed guidance. Methods and techniques, as
well as documenting strategies are well described.
C3.2 Domain experts: domain experts are expected to participate.
C4. Strategy for identifying concepts: no methods or techniques are explicitly pro-
vided.
C5. Recommended life cycle: NeON assumes an evolutionary life cycle and aims to
support the development of the ontology within such a life cycle.
C6. Recommended methods and techniques: The methodology specifies the process,
describes the life cycle and provides methods and techniques.
C7. Applicability: NeON has been applied to real scenarios.

C8. Community involvement: It is assumed that the community participates in the de-
velopment of the ontology
C9. Knowledge elicitation: Knowledge elicitation considered and supported by the
methodology.
2.3 Results
Building well-developed ontologies is an important and difficult challenge as ontology engi-
neering is in many respects still in its infancy. The availability of standard and broadly appli-
cable methodologies represents an “adult” stage for a particular discipline (Fernadez-Lopez
and Gomez-Perez, 2002; Fernandez, 1999). Although some methodologies have been pro-
posed and applied, such as those summarised and evaluated here, currently ontology engineer-
ing has no widely accepted methodology for developing ontologies (Fernandéz et al., 1997;
Mirzaee, 2004a); there is an ongoing debate amongst those within the ontology community as
to which methodology or combination of methodologies should be used (Mirzaee, 2004a;
Sure, 2003). Nevertheless, several groups have engineered particular methodologies to solve
their specific problems within their domains of knowledge (Fernadez-Lopez and Gomez-
Perez, 2002; Sure, 2003). These, however, have often been more interested in the application
of the ontology rather than in how it was built (Mirzaee, 2004a), because the main interest has
been until very recently in reporting content and use, rather than in the engineering of meth-
odologies (Garcia et al., 2006).
We have now analysed a selection of methodologies judged to be representative of the
field and also directly relevant to OASIS concerns. Each methodology was analysed against
the criteria presented in Section 2.2.2.
Table 1 provides a summary of the methodologies and the results of the analysis against
these criteria.

Table 1. Summary of methodologies.
Modified and extended from Fernadez, M. (Fernandez, 1999) according to our evaluations in Section 2.2.3
Application-independent= AI, Application-Semi Independent=ASD, Application-Dependant=AD
Top-Down=TD, Bottom-Up=BU, Middle-Out=MOut,
Domain Expert Dependent=DED, Terminology Extraction Dependent =TED
N/A=Not available, To Be Detailed=TBD, Evolving Prototypes=EP
Inheritance Detail of the Strategy for building the ontology Strategy for Recom- Recom- Applicability Community Knowledge
from knowl- methodology identifying mended life mended involvement elicitation
edge engi- Application Domain ex- Ontology concepts cycle methods,
neering of the ontol- perts type techniques
ogy and technol-
ogy
Uschold and Partial Very little AI N/A N/A MOut N/A N/A Enterprise N/A N/A
King ontology
Gruninger Small Little ASD N/A Domain and MOut TBD N/A Business and N/A N/A
and Fox task ontolo- foundational
gies ontologies
Bernaras A lot Very little AI N/A Domain and TD N/A N/A Electrical N/A N/A
task ontolo- engineering
gies domain
Fernadez A lot A lot AI N/A In principle MOut EP Some activi- Multiple N/A Partially
applicable to ties missing. developments
any kind of Technology reported
ontology recommended
Swartout Inexistent Medium ASD N/A In principle N/A TBD N/A Air campaign N/A N/A
(Sensus) applicable to planning
any kind of ontology +
ontology MT

Pinto Small Small AD N/A N/A DED/TED TBD N/A N/A Community Partially
involvement
Garcia Small A lot AD Focus more Domain and DED/TED EP Some tech- Develop- Community Supported
on special- task ontolo- niques and ments re- involvement
ized domain gies methods rec- ported for the
experts ommended Bio domain
icapturer medium A lot AD Focus more Domain and DED/TED EP Methods and Develop- Community Supported
on special- task ontolo- techniques ments re- involvement
ized domain gies recommended ported for the
experts dur- for commu- Bio domain
ing Knowl- nity engage-
edge Elicita- ment and
tion Knowledge
elicitation
DOGMA- Little Very Little AI Assumes the In principle Mout Evolutionary N/A N/A Community Considered.
MESS participation Domain and involvement Not sup-
of domain task ontolo- ported.
experts gies
NeON Heavily A lot AI Assumes the In principle N/A Evolutionary Some tech- Scenarios Community Supported
participation Domain and niques and extracted involvement
of domain task ontolo- methods rec- from within
experts gies ommended the NeON
project.

The considerable number of methodologies coupled with the limited descriptive detail of
the ontology development approach makes it difficult to achieve a consensus or a melting
point where the methodologies converge, or from which an essence emerges. From the meth-
odologies studied, very few clearly state the methods and techniques being suggested, al-
though the roles of those participating in the development of the ontology are clearly outlined.
None of the methodologies completely fulfil the requirements identified for OASIS. Some of
the methodologies, such as that of Bernaras, provide information about the importance of the
relationship between the final application using the ontology and the process by which the
ontology is engineered. This consideration is not, however, always taken from the beginning
of the development, although the kind of ontology that is being developed heavily influences
this relationship.
The final application in which the ontology will be used also influences which domain ex-
perts should be considered for the development of the ontology. For instance, specialised do-
main experts are necessary when developing application ontologies, domain ontologies or
task ontologies, but they tend not to have such a dominant role when building foundational
ontologies. For these kinds of ontologies, philosophers and broader knowledge experts are
usually more appropriate. Foundational ontologies rarely consider the software using the on-
tology as an important issue; these ontologies focus more on fundamental issues affecting the
classification system such as time, space, and events. They tend to study the intrinsic nature of
entities independently from the particular domain in which the ontology is going to be used
(Sure, 2003).
None of the methodologies investigated provided sufficient detail for users or service de-
velopers not already centrally concerned and familiar with ontology development; the descrip-
tions for the processes were scarce, and where present theoretical. There was generally little
analysis of actual ontology building sessions. The methods employed during the development
of the ontologies were not fully described. For instance, the reasons for choosing a particular
method over a similar one were not presented. Similarly, there was no indication as to what
software should be used to develop the ontologies. METHONTOLOGY was a particular case
for which there is a software environment associated with the methodology; however, the rec-
ommended software, WebODE (Arpirez et al., 2003a), was developed by the same group to
be used within the framework proposed by their methodology.
The lack of support for the continued involvement of geographically distributed domain
experts was not considered when engineering most of the studied methodologies. As we see
the OASIS ontology development to be one which is necessarily distributed, a use scenario is
established in which information is highly decentralised, domain experts are geographically
distributed and the interaction, such as it is, takes place mostly on a virtual basis. Such con-
siderations are therefore particularly important but insufficiently addressed in the methods
considered.
The following sections discuss the identified commonalities and differences in approach
gathered from the evaluation in more detail.
2.3.1 Commonalities across methodologies

The evaluation process identified certain commonalities in the ontology development ap-
proach across the methodologies. For instance, all the studied methodologies consider a kick-
off, formalization as well as an evaluation phase. Fig. 7 illustrates those stages shared across
all methodologies. The DILIGENT and GM methodologies, however, present some funda-
mental differences when compared to the others. This is due to the fact that both were explic-
itly engineered for developing ontologies within geographically distributed settings. The iden-
tified differences of DILIGENT and the GM methodology when compared with the other
methodologies are then as follows.
Both the GM methodology and DILIGENT consider the ontology to be constantly evolv-
ing. In fact, the life-cycle ‘spirals’ with the ontology, progressing further towards the
achievement of specified design goals on each iteration of the cycle. In addition, the GM
methodology also emphasises the notion of collaboration in the development process, particu-
larly during knowledge elicitation. The GM knowledge elicitation relies heavily on interac-
tion: the higher the level of interaction amongst domain experts the more refined the specific
models are likely to be. Both DILIGENT and GM methodologies assume a leading role for
the domain experts as well as a tight relationship between the ontology and the software ap-
plication in which that ontology will ultimately be used.
Fig. 7. Similarities amongst methodologies
2.3.2 Differences across methodologies.
The methodologies investigated take different views on the life cycle of the ontology. Only
DILIGENT and GM consider the life cycle to be dynamic. This is reflected in the processes
these methodologies propose. The development happens in a continuum; some parts within

the methodologies are iterative processes, but the steps are linear, taking place one after the
other. In the case of DILIGENT the different view on the life cycle is clear. There is, how-
ever, no clear understanding as to how this life cycle is dynamic and evolving; the authors do
not present discussion of this.
Both Fernandez et al. and Perez-Gomez et al. emphasise the importance of complying with
Institute of Electrical and Electronics Engineers (IEEE) standards, more specifically with the
“IEEE standard for software quality assurance plans” (IEEE, 1998). However, as also dis-
cussed by (Garcia, 2007b), METHONTOLOGY is the only methodology that rigorously
complies with these; this facilitates the applicability and extensibility of the methodology.
Other methodologies, such as those studied by (Fernadez-Lopez and Gomez-Perez, 2002) do
not explicitly orient to the terms posed by the IEEE, although some of the activities proposed
by those methodologies can nevertheless be framed using the IEEE standards. The methodol-
ogy proposed below accordingly reuses and adapts many components from METHONTOL-
OGY. It also follows Sure’s (Sure, 2003) work as this considers throughout the whole process
the importance of the software applications that will ultimately use the ontology. The work
done by Sure is complementary to that presented in this chapter, as both study different stages
of the same process: developing knowledge-based software.
METHONTOLOGY also allows for a controlled development and evolution of the ontol-
ogy placing special emphasis on quality assurance (QA) throughout the processes. Although
QA is considered, the authors do not propose any methods for this specific task. Management,
development and support activities are carried out in a centralized manner; a limited group of
domain experts interact with the knowledge engineer, conceptualize and prototype the ontol-
ogy, successive prototypes are then built, and the ontology gains in formality (e.g., logical
constraints are introduced) until it is decided that the ontology may be deployed. Once the on-
tology has been deployed a maintenance process takes over. Neither the development nor the
evolution of the ontology involves a decentralized community; the process does not assume a
constant incremental growth of the ontology as has been observed and reported for real on-
tologies by (Garcia et al., 2006). QA is also considered to be a centralized activity, contrasting
with the way decentralized ontologies promote the participation of the community in part to
ensure the quality of the delivered ontology.
Finally, the language choice for encoding an ontology is also still an open debate across
ontology building communities. This situation can be illustrated by the use of both the OBO-
format and OWL within the bio-ontology community (Moreira and Musen, 2007). Conform-
ing to, or accepting a single formalism for ontology encoding would bring consistency and
standardisation to the engineering methodology, such as tool support and reasoning engines,
but consensus is still some way away. Although OWL has a wide acceptance at present, there
are increasing moves to allow extensions over OWL for particular application demands: the
use of the Semantic Web Rule Language (SWRL) is one example of this since the underlying
logic is more similar to Prolog than to the Description Logic of OWL. The existence of ISO
standards for the first-order logic Common Logic (Common Logic Working Group, 2003)
and the logically equivalent Conceptual Graphs of Sowa (Sowa, 2000) also opens up possi-
bilities beyond OWL-DL. As a consequence, our consideration of methodologies in the cur-
rent chapter has been pursued in a language independent manner so as to ensure that the re-
sults apply independently of particular ontology modelling language adopted. In particular,

our own theoretical foundations for ontology connections will be framed within the very gen-
eral mathematical framework of Institution Theory (cf. Section 4.2.4), which has the theoreti-
cal scope to cover all known approaches.
2.4 Conclusions on methodology and recommendations for the OASIS meth-

odological framework
There is an increasing need to emphasise the reuse of methodologies rather than developing
ad hoc, de novo methodologies. The reuse of methodologies will go some way to ensure effi-
cient development, interoperability and the elucidation of best practice in ontology develop-
ment, irrespective of the domain of application. These are precisely the issues that a method-
ology for community-based ontologies such as that targeted within OASIS needs to address.
To move towards an appropriate assessment and re-use of methodological work, this chapter
has presented a comparison and analysis of existing methodologies. Chronologically, early
proposed methodologies such as (Fernandéz et al., 1997), (Uschold and King, 1995) and
(Gruninger and Fox, 1994a), mostly considered static scenarios for which the ontology could
be developed and deployed on a one-off basis; furthermore, these methodologies were mostly
designed for development scenarios for which domain experts were not leading the process
and could be gathered in one place; geographically decentralized settings were not initially
considered.
As ontologies grow in complexity, however, so do the processes by which they are con-
structed. Methods, techniques, activities and tasks become more group-oriented, making it
necessary to re-evaluate the whole process as well as the way in which it is described. As the
networked feature of ontologies gains prominence, so do communities as the primary devel-
opers and consumers of technology using ontologies. Consequently methodologies have
started to address these issues; for instance, Pinto et al., (Pinto et al., 2004a), Sypyns et al.
(Spyns et al., 2008) as well as Garcia et al. (Garcia et al., 2009b) and Suarez-Figueroa et al.
(Suarez-Figueroa et al., 2008) have all explicitly addressed the problem of developing ontolo-
gies within decentralized settings. Important issues such as the evolution, maintenance, intrin-
sic networked nature, modularization, reusability and life cycle of ontologies have also started
to be more carefully considered within recent methodological frameworks (Garcia et al.,
2009b; Jarrar, 2005; Suarez-Figueroa et al., 2008). These issues, however, still present con-
siderable challenges (Jarrar, 2005). The IEEE proposes a set of concepts that should in princi-
ple facilitate the description of a methodology; however these guidelines need to be more ex-
plicitly oriented to decentralized environments.
Interesting lessons have been drawn from the life sciences domain, where collaboration
and community involvement is highly encouraged within the ontology development process.
More importantly, the ontologies in this domain aim actively for interoperability and are used
by software supporting common activities for researchers. Within the biomedical community
the Open Biomedical Ontologies (OBO) foundry provides basic guidelines for ontology de-
velopers; it acts as a registry collecting a family of public domain ontologies, and ensuring
that, by design and revision, these are developed by and available to the community. Within
the bio-ontology domain, communities of practice are crucial not only for the development,

but also for the evolution, usability and quality assurance of the ontologies. There is therefore
much to be learnt and applied here in the OASIS scenario.
As knowledge is in constant flux, ontologies under development should be flexible so that
they remain re-usable and easily extensible in the face of required changes. This is not effort-
lessly achievable since representing knowledge requires the active participation of domain
experts. Moreover, since the costs and efforts associated with the development of ontologies
are considerable, it is important to facilitate this process by encouraging the community to
participate in development. Active participation allows some important aspects of ontology
development can be covered more effectively: first, the chance of the ontology being usable is
greatly increased—there will often be an implicit agreement and the quality of the model is
constantly verified; second, the evolution of the ontology is made more feasible. This means
that collaboration should be placed at the centre of a methodology for developing ontologies.
Nevertheless, although we have seen that such collaboration is present in the DILIGENT and
the GM methodologies, even these methodologies neither propose methods for engaging the
collaborators nor do they provide sufficiently clear methodological guidelines for non-
ontologists. Collaboration, knowledge elicitation, a better understanding of the ontology life
cycle and detailed description for the different steps involved are then essential criteria that
should be documented to ensure that methodologies can be more efficiently replicated and
applied.
Activities within decentralized ontology developments are also highly interrelated. The
greater the maturity of the product, the more engineers and domain experts can determine
boundaries, and by doing so establish milestones for each and every activity and task. Al-
though managerial activities are interrelated and impact those development processes at a
high-level, it is advisable not to have too rigid management structures. For instance, control
and inbound-outbound activities usually coexist with some development activities when a
new term needs to be added. This interaction requires the orchestration of all the activities to
ensure the evolution of the ontology. Again, a precursor for this kind of organisation can be
found in the biomedical domain: in the development of the Proteomics Standards Initiatives
(PSI), for example, minimum reporting guidelines as well as data transfer formats and on-
tologies to control the terminology used for reporting were developed (Taylor et al., 2007 ).
Nevertheless, as a result of the evaluation of ontology engineering methodologies given, it
is also apparent that the lack of unified criteria makes it difficult to amalgamate methodolo-
gies; each group applies its own methodology, adapting it to the specific problem they are ad-
dressing. Much of the problem arises from a lack of detail in the methods and techniques pro-
posed in all of the investigated methodologies. The process of knowledge elicitation, whether
within the context of collaboration or as a focus group activity, is also not fully addressed in
most of the methodologies investigated. METHONTOLOGY considers knowledge elicitation
as part of the methodology, but there are no recommendations regarding knowledge elicitation
methods.
A further feature not covered by any of the methodologies investigated is the use of upper
level ontologies; as these are meant to support classification based on universal criteria it is
important to understand the structure proposed by these ontologies in order to ease the inte-
gration of domain ontologies. This adoption has, however, not been documented within a

methodological framework that facilitates both the adoption of the upper level ontology and
its proper use. If such a “building-block” approach is to be achieved, orthogonality across
domain ontologies should be maximised; by the same token some minimal quality parameters
should be clearly specified by broad community initiatives; within the biomedical ontology
domain, OBO (Brinkely et al., 2006) provides one clear example, requiring at least in theory
that the overlapping of ontologies should be avoided. For this, the community should agree on
the review processes, methods and techniques should be shared across members of the com-
munity, and documentation (lexical definitions and use cases) should be compulsory. Ongo-
ing work within the OBO context reveals, however, just how difficult these goals are to
achieve in practice.
Finally, we have seen in this chapter that there is increasing experience in building large
ontologies within complex domains of knowledge. More research, methodologies and shared
experience from these developments should enable and encourage the development of ontolo-
gies fit for purpose, and allow the ontology community to cope with the demands for scalabil-
ity and reproducibility. Support for the maintenance and evolution of ontologies, as well as
reproducibility in their developments, provide the bedrock for the semantic web. The publica-
tion of papers concerning methods and techniques about the development of ontologies
should be encouraged, not only by members of the community but also by publishers. Such
methodological specifications and reports on the results of applying such specifications are an
important prerequisite for enabling knowledge rich application development in general. Set-
ting out such specifications is also crucial for achieving and documenting the kind of inter-
domain interoperability targeted within OASIS. From the analysis presented in this chapter, it
is clear that whatever methodology finally emerges, it will need to support the construction of
ontologies by communities and utilize the collective intelligence available in the application
domains concerned.

3 The Common Ontological Framework:

Methodology Component
The previous chapter has shown that most of the methodologies proposed for developing on-
tologies do not provide support for the continued involvement of domain experts scattered
around the world. Moreover, tools and activities supporting specific steps within the devel-
opment process have not always been usefully described. The OASIS project sets out a sce-
nario for which domain experts are geographically distributed, domain experts will interact
relatively rarely, the structure of the ontology is constantly evolving, and the role of the
knowledge engineer is not one of leader but more of one of promoting collaboration and
communication among domain experts. Presenting a methodology for guiding and informing
ontology development in this scenario is an important contribution to the state of the art in
ontology engineering, one which is already proving relevant for a host of scenarios far beyond
OASIS.
To develop knowledge-rich services of the kinds envisaged, OASIS needs to construct and
maintain cross-domain interoperable networked ontologies that draw maximally on the ac-
tions and knowledge of service developers. The problem is how to enable interoperability
across such a diverse range of application areas. Many of the features required have general
parallels with those demands of the semantic web. In particular, the following properties need
to be addressed:
! volatility of knowledge in the domains pertaining to the OASIS project – domain ex-
perts’ understanding of their domain cannot be assumed to remain constant indefi-
nitely;
! domains are highly interconnected;
! networks of ontologies representing those domains relevant to OASIS should be orches-
trated in such a way that reasoning is supported;
! domains are generally large, complex, and cannot, therefore be modelled in one single
effort, nor can they be represented sensibly by just one large ontology;
! knowledge holders are distributed and cannot be brought together for frequent knowl-
edge elicitation exercises.
As set out above, the aim of the OASIS ontology solution is therefore to support interopera-
bility across the independently developed ontologies. This involves: modularization of on-
tologies, reusability, and a community driven process for the ontologies being developed as
well as evolution of the knowledge artefacts.
The major contribution of this chapter is the presentation of the general description of the
methodological component of our Ontological Framework (COF) for building interoperable,
community based ontologies that respect the properties identified so far. Our approach is in-
tended to guarantee consistency between the life cycle of the ontology and those proposed
methods and techniques the COF orchestrates. We first set out the consequences drawn from

the evaluation of the previous chapter, and then proceed to the particular methodological
commitments adopted.
3.1 Terminological Considerations

Several commonalities identified across the methodologies previously proposed and identified
in Chapter 2 have been adapted for the present work. An important contribution comes from
observations made by Perez-Gomez et al. (Perez, 1994a; Perez et al., 1996), Fernandez et al.
(Fernandéz et al., 1997), Pinto et al. (Pinto and Martins, 2004; Pinto et al., 2004a), and Garcia
et al. (Garcia et al., 2006). As seen above, both Fernandez et al. and Perez-Gomez et al. em-
phasise the importance of complying with standards developed by the Institute of Electrical
and Electronics Engineers (IEEE), more specifically with the “IEEE standard for software
quality assurance plans” (IEEE, 1998). According to these IEEE standards, methodologies
bring together techniques and methods in an orchestrated way so that work can be done.
A method is “an orderly process or procedure used in the engineering of a product or per-
forming a service” (IEEE, 1991). A technique is defined as a “technical and managerial pro-
cedure used to achieve a given objective” (IEEE, 1998). Fig. 8 illustrates these relationships
more comprehensively.
Fig. 8. Terminological relationships
Greenwood (Greenwood, 1973) as well as Gomez-Perez et al. (Gomez-Perez et al., 2004)

present these terminological relationships in a simple way: “a method is a general procedure
while a technique is the specific application of a method and the way in which the method is
executed” (Gomez-Perez et al., 2004). According to the IEEE (IEEE, 1996), a process is a
“function that must be performed in the software life cycle. A process is composed by activi-
ties”. The same set of standards defines an activity as “a constituent task of a process” (IEEE,
1996). A task is the atomic unit of work that may be monitored, evaluated and/or measured; a
task is “a well defined work assignment for one or more project member. Related tasks are
usually grouped to form activities” (IEEE, 1996). We also adhere to these conceptualisations
below.
3.2 The Methodology and the Life Cycle

For the purpose of the OASIS methodology it was decided that the activities involved would
be framed within processes and activities. As discussed in the previous chapter, this concep-
tion is promoted by METHONTOLOGY (Fernandéz et al., 1997) for centralised settings;

therefore, since the activities envisaged here are conceived within decentralised settings, their
scope has had to be redefined so that they better fit the life cycle of distributed ontologies de-
veloped by communities. The OASIS methodology accordingly emphasises decentralised set-
tings and community involvement, as well as the importance of the particular life cycle such
ontologies follow. The methodology provides activities, methods and techniques coherently
embedded within this life cycle. Both the methodology and the life cycle are illustrated in Fig.
9, showing how activities and processes contribute.
Fig. 9. Life cycle, processes, activities, and view of the methodology
The overall life cycle starts with documentation and management processes; the develop-
ment process follows immediately after. Managerial activities occur throughout the whole life
cycle. The interaction amongst domain experts is used not only to ensure the quality of the
ontology, but also to see that the predefined control activities take place. The development
process itself is made up of five main activities: specification, conceptualisation, formalisa-
tion, implementation and evaluation. Different prototypes or versions of the ontology are thus
constantly being deployed. Initially these prototypes may be unstable, as the classes and prop-
erties may change drastically. In spite of this, the process evolves rapidly, achieving a stability
that facilitates the use of the ontology; this is because changes generally become more fo-
cused and centre on the inclusion of classes and instances, rather than on the redefinition of
the class hierarchy as a whole.
3.2.1 Documentation Processes
Documentation is a continuous process throughout the entire development of the ontology.

The documentation has as one of its primary functions the requirement that it should make it
possible for new communities of practice to get involved in the development of the ontology
with a minimum of learning overhead. Documentation should also generally include the de-
sign decisions that are made throughout the development process; this information is best

made available in a form closely associated with the ontology but not as, for example, in-line
comments or other machine-inaccessible forms within ontology files. Within the OASIS con-
text, this information is being considered for inclusion with the OASIS Wiki as part of the
Framework Update and Maintenance Strategy (cf. Deliverable D1.2.1); clearly, the more
structured this information becomes, the more accessible it is for semantic search and other
processing.
Activities for Documenting the Management Processes.
Scheduling and Control: Although there are several software suites that assist in project man-
agement, some of them offering workgroup capabilities (see for instance
http://www.mindtools.com/), within ontology development one still generally finds simpler
solutions at work. For example, even quite large biological ontology projects use solutions
such as those facilities offered by Google for networking. Scheduling and controlling activi-
ties are done here using Google calendar (http://www.google.com/calendar), while sharing
documents is facilitated by Google documents (http://docs.google.com). When establishing
communication and exchanging information, email, wiki pages and voice over Internet Proto-
col (IP) systems have proven themselves useful in projects such as the Ontology for Biomedi-
cal Investigations (OBI) (http://obi.sourceforge.net/, 2007 ) and the Microarray Ontology
(MO) (http://www.mged.org/, 2006; Stoeckert and Parkinson, 2003). A more detailed descrip-
tion of the involvement of communities by electronic means was published by Garcia et al.
(Garcia et al., 2006).
For both scheduling and controlling, software tool(s) should in principle:
o help to plan the activities and tasks that need to be completed,
o give a basis for scheduling when these tasks will be carried out,
o facilitate planning the allocation of resources needed to complete the project,
o help to work out the critical path for a project where one must complete it by a
particular date,
o facilitate the interaction amongst participants, and
o provide participants with simple means for exchanging information.
Documenting Classes and Properties.

Although documentation can happen naturally, facilitated by discussions via email, it is often
difficult to follow the argumentative thread. Even so, the information contained in mailing
lists is useful and should whenever possible be related to classes and properties. Use cases, in
the form of examples for which the use of a term is well-illustrated, should also be part of the
documentation of classes and properties. Ontology editors allow domain experts to comment
on the ontology; this kind of documentation is useful, as it reflects the understanding of the
domain expert, and should be made more accessible.
For classes and properties there are three main sources of documentation:

! Mailing lists: discussions about why should a class be part of the ontology, why should
it be part of a particular class hierarchy, how is it being used by the community, how a
property relates two classes, and in general all discussions relevant to the ontology
happen on an email basis.
! On-the-Ontology comments: in the cases when domain experts are familiarised with the
ontology editor, they usually comment on classes and properties directly—perhaps in
comments within files or, increasingly due to the support offered by ontology tools
such as Protégé, as semi-structured annotations within the ontology definitions.
! Use cases: this should be the main source of structured documentation provided by do-
main experts. However, gathering use cases is often difficult and time-consuming. The
use cases should illustrate how a term is being used in a particular context, how the
term is related to other terms, and those different uses or meanings a term may have.
Guidance is available for the construction of use cases when developing software;
however this direction is not available when building ontologies.
Experiences by ourselves and others in this phase of ontology development suggest
several general guidelines. For instance: use cases should be brief and they should be
based upon real-life examples. The knowledge engineers involved have also to be fa-
miliar with both the terminology and the domain of knowledge because use cases are
usually provided in the form of narratives describing processes. Graphical illustra-
tions should be provided as part of the use case wherever possible and, also whenever
possible, concept maps, or other related KA artefacts, should be used. In Chapter 5 be-
low we describe a tool that we have developed particularly to support this latter phase
of development/documentation.
3.2.2 Management Processes
These start as soon as there is a motivation and a decision for developing an ontology and
continue throughout the whole ontology development process. Managerial processes aim to
assure the successful development of the ontology by providing domain experts with all that
they need to make timely progress. Also, managerial processes define general policies that
allow the orchestration of the whole development. Some of the activities involved in the
managerial processes are:
! Scheduling: Scheduling identifies tasks, time and resources needed.
! Control: Control monitors all tasks to ensure that the planned tasks are completed.
! Inbound-interaction: Inbound-interaction specifies how the interaction amongst domain
experts will take place, for instance by phone calls, mailing lists, wiki pages and web
publications.
! Outbound-interaction: As different communities should in principle be allowed to par-
ticipate, there also has to be an inclusion policy that specifies how other communities
could collaborate and engage with the ongoing development.

! Quality Assurance: This activity defines minimal standards to be met by the outputs
from each and every process, activity or task carried out within the development of the
ontology.
3.2.3 Development-oriented Processes
Specification. The specification of the ontology involves defining the motivation—in other
words why the development of an ontology is required for the application domain at all. The
specification phase can also be called a feasibility study and includes addressing straightfor-
ward questions such as: what is the ontology going to be used for? How is the ontology ulti-
mately going to be used by the software implementation? What do we want the ontology to be
aware of, and what is the scope of the knowledge we want to have in the ontology? These
statements are typically represented as competency questions which define the requirements
of the ontology, dependent on the motivation, described as informal questions or tasks that an
ontology must be able to answer. Competency questions are understood here as those ques-
tions which allow us to define the reasoning and inference processes that the ontology is to
support (Garcia et al., 2006). This can help both to define and subsequently to enforce the
boundaries of the ontology being developed to prevent time being wasted in formalisations
that are not necessary for its goals.
Conceptualisation. The conceptualisation of the ontology involves the process of identifying
the key concepts that exist in the domain, their properties and the relationships that hold be-
tween them. This also can include identifying natural language terms to refer to such con-
cepts, relations and attributes as well as structuring domain knowledge into explicit concep-
tual models (Stevens et al., 2000). These natural language terms may be drawn from one or
more languages as appropriate for the language of the community carrying out the develop-
ment. In general, it is appropriate here to consider issues of multilinguality and localisation:
however, on the level of ontology content or ontology development tools, this is not a focus
within the OASIS project and so we do not pursue this aspect further here.
In order to achieve conceptualisation, the processes of Domain Analysis (DA), Knowledge
elicitation (KE) and Knowledge Acquisition (KA) are typically performed. DA is the process
by which a domain of knowledge is analysed in order to find common and variable compo-
nents that best describe that domain. KE is the process of collecting from a human source of
knowledge information that is relevant to that knowledge (Cooke, 1994). KA includes the
elicitation, collection, analysis, modelling and validation of knowledge for knowledge engi-
neering and knowledge management projects. The motivation and force of both KA and KE
come from the development of knowledge bases; for the purposes of developing ontologies,
KA and KE can be considered as transposable terms. KA and DA are complementary activi-
ties by which the information used in a particular domain is identified, captured and organised
for the purpose of making it is available in an ontology (Gaines and Shaw, 1993).
Identifying available sources of knowledge is also important since this can help to refine
or confirm the ontology specification. In the bio-ontology domain, for example, this process
has been facilitated by the OBO Library and its registry of available and accessible domain
ontologies. Searching the registry is made possible via the BioPortal tool from the National
Center for Biomedical Ontology (NCBO) (Rubin et al., 2006) or the Ontology LookUp ser-

vice (OLS, http://www.ebi.ac.uk/ontology-lookup/). The OLS provides a user-friendly single

entry point for querying publicly available ontologies in the Open Biomedical Ontology
(OBO) format. By means of the OLS it is possible to verify if an ontology term has already
been defined and in which ontology it is available (Cote et al., 2006). We build on this func-
tionality in the OASIS context further below.
Typically, baseline ontologies tend to lack formal definitions, whole/part-of relationships,
and a stable is-a structure. Those activities related to DA and KA focus more on capturing and
representing knowledge in a more immediate manner and not necessarily on having logical
expressions as part of the models. When formalizing and evaluating an ontology, however,
activities and tasks are more oriented to include logical constraints. DA and KA may be seen
as the ‘art of questioning’, since ultimately all relevant knowledge is either directly or indi-
rectly in the heads of domain experts. This activity accordingly involves the definition of the
terminology. It starts by the identification of ontologies that are reusable and terminates with a
baseline ontology, i.e. a draft version of the targeted ontology containing few but seminal
elements.
The following criteria have been found to be important during knowledge acquisition
(Garcia et al., 2006):
! Accuracy in the definition of terms. The terminological phase of ontology development
is also meant to support the sharing of information/knowledge. The availability of
relevant aspects of context as part of the definitions provided is particularly useful
when sharing knowledge further beyond the immediate and original developers.
! Coherence: the narrative explaining and motivating the acquisition of knowledge should
be coherent.
! Extensibility: the conceptual models (CM) being grown during domain knowledge elici-
tation are constantly gaining information and this always part of a larger, encompass-
ing narration. Extending the conceptual model is not only about adding more detail to
the existing CMs, nor it is it just about generating new CMs; it is also about grouping
concepts into higher-level abstractions and validating these with domain experts. This
task can therefore be seen as involving problems of ‘aggregation’. Scaling the models
involves the participation of both domain experts and the knowledge engineer. This is
mostly done by direct interview and confrontation with the models from different per-
spectives. The participation of new “fresh” domain experts, as well as the intervention
of experts from allied domains, allows analyzing the models from different angles.
This participatory process supports re-factorizing the models by increasing their level
of abstraction.
Throughout these activities, Gruber’s original ontology design principles (Gruber, 1993)
described below should also be considered:
! First design principle: “The conceptualization should be specified at the knowledge level without
depending on a particular symbol-level encoding.”
! Second design principle: “Since ontological commitment is based on the consistent use of the vo-
cabulary, ontological commitment can be minimised by specifying the weakest theory and defin-
ing only those terms that are essential to the communication of knowledge consistent with the

theory.”
! Third design principle: “An ontology should communicate effectively the intended meaning of de-
fined terms. Definitions should be objective. Definitions can be stated on formal axioms, and a
complete definition (defined by necessary and sufficient conditions) is preferred over a partial
definition. All definitions should be documented with natural language.”
For the purpose of DA and KA it is critical to elicit and represent knowledge from domain
experts. They do not, however, have to be aware of knowledge representation languages; this
makes it important that the elicited knowledge is represented in a knowledge representation
language independent manner. Researchers participating in knowledge elicitation sessions are
not always aware of the importance of these sessions; however they are aware of their own
operational knowledge. This is consistent with the first of Gruber’s design principles.
Regardless of the syntactic format in which the information is encoded, domain experts
have to communicate and exchange information. For this matter it is usually the case that
wide general theories, principles, broad-scope problem specifications are more useful when
engaging domain experts in discussions, as these tend to contain only essential basic terms
known across the community and causing the minimal number of discrepancies; this falls un-
der Gruber’s second design principle. As the community subsequently engages in the devel-
opment process and the ontology grows, it becomes more important to have definitions that
are usable by computer systems and humans; here we move on to the considerations of the
third design principle.
Milestones, Techniques and Tasks for the Conceptualisation Activities. The milestones,
techniques and tasks that must be carried out and, where appropriate, enforced during DA and
KA related activities are:
! Tasks: focus groups, limited-information and constrained-processing tasks, protocol
analysis, direct one-to-one interviews, terminology extraction, and inspection of exist-
ing ontologies.
! Techniques: concept mapping, sorting techniques, automatic or semi-automatic termi-
nology extraction, informal modelling and identifying pre-existing resources.
! Milestones: baseline ontology, knowledge sources, basic terminology, reusable ontolo-
gies.
Formalisation. Formalisation of the ontology is the activity during which proposed classes
are constrained by further distinguishing axioms and instances are attached to their corre-
sponding classes. For example: “a male is constrained to be an animal with a y-chromosome”
is an important additional axiom that allows reasoning to be done on the class; without this
axiom, it is only known that the class is (somehow) distinguished from other classes at that
point in the is-a hierarchy. During the formalisation, domain experts and knowledge engineers
work with an ontology editor, often exchanging versions for critique and consistency check-
ing. When building iterative models and formalizing the ontology, the model generally grows
in complexity; instances, classes and properties are added, and logical expressions are built in
order to achieve definitions with necessary and sufficient conditions to support the reasoning
tasks identified for the ontology in previous development stages.

For both formalisation and the iterative building of ontology models (IBOM: see below),
Gruber’s fourth designing principle is applicable as well as Noy and McGuinness’s guidelines
(Noy and McGuinness, 2001b); grouped together here as follows:
! Fourth principle: “An ontology should be coherent: that is, it should sanction inferences that are
consistent with de definitions. […] If a sentence that can be inferred from the axioms contradicts
a definition or example given informally, then the ontology is inconsistent.”
! Noy and McGuinness’s first guideline: “The ontology should not contain all the possible informa-
tion about the domain: you do not need to specialise (or generalise) more than you need for your
application.”
! Noy and McGuinness’s second guideline: “subconcepts of a concept usually i) have additional rela-
tions that the superconcept does not have, or ii) restrictions different from these of supercon-
cepts, or iii) participate indifferent relationships than superconcepts. In other words, we introduce
a new concept in the hierarchy usually only when there is something that we can say about this
concept that we cannot say about the superconcept. As an exception, concepts in terminological
hierarchies do not have to introduce new relations”.
! Noy and McGuinness’s third guideline: “If a distinction is important in the domain and we think of
the objects with different values for the distinction as different kinds of objects, then we should
create a new concept for the distinction”.
! Noy and McGuinness’s fourth guideline: “A concept to which an individual instance belongs
should not change often”.
Implementation. The implementation of the ontology concerns the choice and justification of
the encoding formalism, for example the OBO-format or the Web Ontology Language
(OWL). The choice and the justification of a language takes into account the required expres-
sivity demanded by the specification process and by extension the tools required to facilitate
the encoding. For example, if the chosen language was OWL, then it would be appropriate to
use an ontology editor such as Protégé (http://protege.stanford.edu/). Ultimately implementa-
tion is concerned with encoding the decisions made as part of the formalization process.
However, the implementation process and the formalization process can often happen simul-
taneously as an iterative process.
Iterative Building of Ontology Models (IBOM). Iterative building of informal ontology
models helps to expand the glossary of terms, relations, their definition or meaning, and addi-
tional information such as examples to clarify the meaning where appropriate. Different mod-
els are built and validated with the domain experts. There is a fine boundary between the
baseline ontology and the refined ontology since both are treated as work in progress; how-
ever, the refined ontology is always either one further stage nearer community agreement or is
explicitly marked as a branch where certain (documented) issues have not been resolved at
that time.
Methods, Techniques and Milestones for the IBOM. The milestones, techniques and tasks
identified for IBOM related activities are:
! Methods: focus groups
! Techniques: concept mapping, informal modelling with an ontology editor

! Milestones: refined ontology + documentation increment.

Evaluation. There is no unified framework to evaluate ontologies and so this area remains an
field of active research (Almeida, 2009; Gangemi et al., 2006; Perez et al., 2004). When de-
veloping ontologies on a community basis three main evaluation activities have been identi-
fied:
! Specification Evaluation. The specification defines the motivation and the scope of the
ontology in the form of competency questions. Specification evaluation concerns the abil-
ity of the ontology to answer the competency questions and therefore demonstrate fulfil-
ment of the intended scope.
! Application-dependent Evaluation. Ontologies should be evaluated according to their fit-
ness for purpose, i.e. an ontology developed for annotation purposes should be evaluated
by the quality of the annotation and the usability of the annotation software it supports
(Garcia et al., 2006). By the same token, the recall and precision of the data, and the us-
ability of the conceptual query builder, would form the basis of the evaluation of an ontol-
ogy designed to enable data retrieval. The respective communities concerned in each case
carry out evaluations of this kind in an interactive manner; as the ontology is ideally being
used at the same time, constant feedback can be generated. This makes it possible for
communities themselves to effectively guarantee the usability and the quality of the on-
tologies under development.
! Terminology Evaluation. This activity was proposed by Perez-Gomez et al. (Perez et al.,
1995). The goal of this kind of evaluation is to determine what precisely the ontology has
succeeded in defining, and how accurate those definitions are. Perez-Gomez et al. provide
the following criteria for this evaluation:
o Consistency: it is assumed that a given definition is consistent if, and only if,
no contradictory knowledge may be inferred from other definitions and axioms
in the ontology.
o Completeness: it is assumed that ontologies are in principle incomplete (Perez
et al., 1995; Perez et al., 2004); however it should be possible to evaluate
completeness within the context in which the ontology will be used. An ontol-
ogy is complete if and only if: “All that is supposed to be in the ontology is ex-
plicitly stated, or can be inferred”.
o Conciseness: an ontology is concise if it does not store unnecessary knowl-
edge, and any redundancy in the set of definitions has been properly removed.
! Taxonomy Evaluation. For Description Logic ontologies this evaluation is usually carried
out by means of reasoning systems such as RACER (Haarslev and Möller, 2003) or Pellet
(Sirin et al., 2007). The knowledge engineer checks for inconsistencies in the taxonomic
backbone of an ontology. Errors may also be caused here by in adequacies in the logical
expressions that are part of the axioms and so require reasoning support rather than simple
visual inspection of is-a definitions.

3.3 An Incremental Evolutionary Spiral Model of Tasks, Activities and Proc-

esses
Ontologies, like software, evolve over time; specifications often change as the development
proceeds, making a simple and direct path to the final ontology unrealistic. One source of in-
put for ontology development is therefore offered by the variety of software process models
that has been proposed in the literature, such as, for example, linear sequential models and
prototyping models.
Linear sequential models are also known as waterfall models (Eden and Hirshfeld, 2001;
Pressman, 2001) since they are designed for straight-line development. These models suggest
a systematic, sequential approach in which the complete system is delivered once the linear
sequence is completed (Pressman, 2001). The role of domain experts is passive, as end-users
of technology. They are placed in a reacting role in order to give feedback to designers about
the product. The software or knowledge engineer leads the process and controls the interac-
tion amongst domain experts. A high-speed adaptation of the linear sequential model is the
Rapid Application Development (RAD) model (Kerr and Hunter, 1994; Martin, 1991). This
emphasises short development cycles for which it is possible to add new software compo-
nents, as they are needed. RAD also strongly suggests reusing existing program components,
or creating reusable ones (Pressman, 2001).
In contrast to the linear sequence models, prototyping models are more flexible as proto-
types are constantly being built. The prototypes are used as a means for defining requirements
(Pressman, 2001), which allows for a more active role from domain experts. A quick design is
often obtained in short periods of time. The model grows as prototypes are released (Perez et
al., 2004); both engineers and domain experts work on these quick designs. Applied to ontol-
ogy, such models focus on representational aspects while the main development of the ontol-
ogy (building the models, defining what is important, documenting, etc) is left to the knowl-
edge engineer.
Although useful, the particular evolutionary nature of software is considered in neither of
the aforementioned models. From the software engineering perspective, evolutionary models
are iterative and allow engineers to develop increasingly more complex versions of software
(Gilb, 1988; Gilb, 2004; Pressman, 2001). Again, applying this to ontologies, ontologies are
no different from other software components and we can see a progression in which process
models have evolved from a “linear thinking” into evolutionary process models that recognise
that uncertainty dominates most projects, that timelines are often impossibly short, and that
iteration provides the ability to deliver a partial but extendible solution even when a complete
product is not possible within the time allotted. Evolutionary models emphasise the need for
incremental work products, risk analysis, planning followed by plan revision, and customer
(domain expert) feedback (Pressman, 2001).
These considerations fit ideally with our requirement that communities be involved cen-
trally in ontology development. The life cycle of an ontology is changed accordingly: an on-
tology is not typically deployed on a one-off basis; there is thus no definitive final version of
the ontology. The involvement of the community allows for rapid evolution, as well as for
high quality user-oriented standards; errors may be identified and discussed and corrections

made available within short time frames. The corresponding methodology therefore brings
together ideas from not only linear sequential modelling (Dagnino, 2001; Pressman, 2001)
and prototyping as described above, but also incorporates notion of spiral (Boehm, 1986), in-
cremental (Larman and Basili, 2003; McDermid and Rook, 1993) and evolutionary models
(May and Zimmer 1996; Pressman, 2001). Ontologies are seen as growing rapidly and con-
tinuously and, during this process, prototypes are delivered, documentation is constantly gen-
erated, and evaluation takes place at all times arising out of argumentation amongst domain
experts with respect to the ontology in use. The development process is then incremental as
new activities may occur without disrupting the evolution of the collaboration as a whole.
We can therefore characterise our methodological model for ontology development as an
incremental evolutionary spiral in which tasks and activities can coexist simultaneously at
several levels of detail. As the process moves forward activities and/or tasks are applied re-
cursively depending on needs. Fig. 10 illustrates the model as well as how processes, activi-
ties and tasks are consistent with it.
Fig. 10. A view of the whole ontology design process
3.4 Conclusions for the OASIS Common Ontological Framework: Method-

ology Component
As we increasingly build large ontologies for complex domain knowledge in a community-
based and collaborative manner, there is an identified need for appropriate methodologies to
provide frameworks for this process. A shared methodology tailored for the decentralized
development environment, facilitated by the internet should increasingly enable and
encourage the development of ontologies fit for purpose. The COF methodology provides this

framework, which should enable the ontology community to cope with the escalating
demands for scalability and repeatability in the representation of community defined
knowledge bases, such as those in required in diverse application scenarios such as OASIS
and other semantic web-based initiatives.
The COF methodology proposed here reuses components that various authors have identi-
fied as part of their methodologies for ontology development. It then combines them within
the spiral developmental life cycle characterised in the previous section so as to explicitly de-
fine their use within decentralised settings. The COF methodology stresses the importance of
a detailed description of the methods, techniques, activities, and tasks that could be used for
developing community-based ontologies. Furthermore, a discussion of how the development
process evolves, adapts and expands with growth or redefinition of the ontology specification
is presented within the life cycle model of these ontologies.
The adoption of this methodology provides a level of rigour and consistent development of
ontologies, with a particular focus on community contribution. Ontologies developed within
the same methodology framework are expected to more straightforwardly contribute to ontol-
ogy interoperability and integration, as the processes and design decisions can be dissemi-
nated upon publication and be followed and evaluated. The COF methodology has now been
employed for all of the ontologies under development within OASIS and has informed the
working practice of the Ontology Development Task Force as carried out under Activity
A1.2.6 Coordination of development of new ontologies. An initial representation of the indi-
vidual stages reached in the development of each ontology was added to the original OASIS
project wiki under the Ontology Development Task Force pages; this has now been replaced
by our platform for managing ontologies in general, the BioPortal-based ORATE system
(http://ontologies.informatik.uni-bremen.de/) described in detail in the next chapter in Section
5.4. 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.
We also see this effort as offering a substantial contribution to ontology methodology with
much broader applicability than that purely within OASIS. For example, the methodology is
envisaged as facilitating a development process that is actually capable of achieving the prin-
ciples of orthogonality and community-involvement foreseen, but not entirely realized, for the
OBO Foundry for bio-ontology development (http://www.obofoundry.org/crit.shtml). The
methodology is also equally applicable in the development of the knowledge infrastructure of
the Semantic Web, a decentralised environment by design. Finally, we are also promoting the
use of the methodology for other ontology development work: for example, its application is
currently being considered for the community development of an ontology for neurophysiol-
ogy experiments as part of the CARMEN project (www.carmen.org.uk). We will use all of
these experiences as crucial feedback and evaluation of the methodology as a whole and re-
port on our conclusions in appropriate dissemination activities over the third year of the OA-
SIS project.

4 Hyper-ontology: Logical Foundations

By far the most common approach for achieving interoperability via the use of ontologies is
still to plug domain ontologies into some upper level ontology; this was the original frame-
work motivated and applied in such early ontology work as that reported in (Bateman, 1990).
This framework, although conceptually simple, has certain theoretical and practical limita-
tions that we will describe from a formal perspective below. In addition to this method, there-
fore, the OASIS Hyper-Ontology model provides an alternative, more general set of mecha-
nisms. The Hyper-Ontology is intended to facilitate interoperability by standardizing a series
of logically well defined relationships that act as a connectivity tissue for bringing together
heterogeneous ontologies. In this way, domain ontologies remain independent from the net-
work as a whole and so can each undergo development processes as set out in the previous
chapter without impacting on one another in complex and difficult to control ways.
The hyper ontology approach can be seen as a continuation and extension of several re-
search and development threads begun in a range of large-scale engineering areas, including
software engineering and the initial efforts within ontological engineering of projects such as
KnowledgeWeb and NeON, whose results we consider further below. The hyper-ontology
allows domain ontologies to be interlinked in a manner similarly to the ‘Lego’ approach, i.e.,
by allowing bricks to be connected to one another by having well defined interoperable con-
nectors,. This approach is also similar to that used in Object Oriented Programming. The hy-
per-ontology model shifts the question from “How can I make my Ontology compliant with
an Upper level Ontology” to “What connector should I use?” This accordingly adds a further
dimension to the methodology classification criteria set out in Section 2.2.2 above. The ap-
proach is not one of top-down, bottom-up or middle-out, but rather orthogonal to all previous
methods. We do not need to commit to particular data-driven methods. Nor do we have to
think of any of our domain ontologies in terms of any other ontology, as is the case when re-
lying on an upper level ontology where domain ontologies must be designed and implemented
according to the guidelines given by that upper level ontology. In this case, plug-ability is
controlled by the upper level ontologies—a process that is by no means always straightfor-
ward, nor automatic. In fact, one consequence of adapting ontologies to upper-level ontolo-
gies is that those ontologies are shaped precisely so that they can be plugged, thereby possibly
distorting the content to be expressed and impacting negatively on their own internally moti-
vated design development.
As thousands of ontologies have so far been developed and continue to be developed
world-wide, the hyper-ontology recognizes and accepts this diversity. It does not aim to stan-
dardize content in individual domains, but instead seeks to facilitate the availability of general
well-defined and highly reusable connectors. These connectivity mechanisms therefore form a
candidate for standardisation initiatives at the level of meta-models and particularly in the area
of inter-module relationships at that meta level. An illustration of the contrast between the hy-
per-ontology and the upper level approach is given in Fig. 11. Standardisation proceeds in
parallel to the application of the hyper-ontology and, indirectly, by virtue of the clear meth-
odological guidelines developed. These guidelines are intended to make it more likely that
conformant ontologies will result, without needing to lay down specific requirements for each
domain.

Fig. 11. The hyper-ontology model compared
4.1 Defining the term ‘hyper-ontology’

Both the formal specification and actual implementation or instantiation of the idea of a hy-
per-ontology are further central deliverables of the OASIS project. In the present document,
for more convenient reference to these two aspects we call the formal specification of the no-
tion "hyper-ontology" the hyper-ontology framework and its instantiation or materialization
the hyper-ontology network. Sometimes we will just talk of hyper-ontology and it should be
clear from the context which of these aspects is meant.
The term "hyper-ontology" itself is new and has no pre-established meaning in the litera-
ture. Obviously it suggests an association with the well known term "hypertext" and thereby
already fosters a basic intuition as to what is intended: whereas in hypertext, texts blocks are
connected via hyperlinks, so the hyper-ontology aims to link ontologies. Both terms are there-
fore concerned with a network of digitalized knowledge. Their common prefix "hyper"—
which could be approximately translated as "beyond"—also expresses the claim that such a
network facilitates a knowledge gain that goes beyond the mere accumulation of its knowl-
edge pieces. The main difference, however, between hypertext and hyper-ontology is that the
latter deals with machine-understandable content. We say a machine can "understand" a for-
mal ontology if its response to a request concerning this ontology is sound with respect to a
formal semantics. Specifying the formal semantics of the hyper-ontology is thus a central part
of its formal specification. In addition, any semantics needs some form of representation.
Hence the syntax of a hyper-ontology is also an important aspect of its formal specification.
Semantics and syntax together constitute the formal hyper-ontology framework.

In order to make use of the hyper-ontology framework we then need two things: (1) we
need concrete content that is compliant with the framework—i.e. a hyper-ontology network as
we called it above—and (2) we need tools that can operate on this content in compliance with
that framework. These three aspects are summarized in Table 2. The subsequent sections of
this chapter address each of these aspects in turn.
Table 2. Aspects of Hyper-ontology
Aspects of Hyper-ontology
Framework formal specification of syntax and semantics for languages, ontologies and their connections
Network materialization of the framework with concrete network of connected ontologies

Tools operations on the hyper-ontology
4.2 Hyper-ontology Framework

In the introduction above we said that the hyper-ontology network is the instantiation of its
framework. We can also put it the other way around: the framework specifies the semantics of
the hyper-ontology network. A hyper-ontology network consists of nodes—the ontologies—
and links connecting them.
We therefore have to provide formal specifications of two things in the hyper-ontology
framework: 1) specifications for the nodes and 2) specifications for the connections. The sub-
sequent two subsections are about these two respective aspects. Moreover, we have to talk
about syntax and semantics in both cases — as already mentioned before. Fig. 12 summarizes
the scope of the corresponding hyper-ontology framework accordingly.
Fig. 12. Hyper-ontology framework
4.2.1 The Nodes in the Hyper-ontology Framework
Description Logic (DL — in all its variants) is the predominant logic in the Semantic Web
that provides ontologies with a formal semantics. We will assume the reader is broadly famil-
iar with DL — many introductions can be found on the web (http://dl.kr.org/) or in textbooks

such as (Baader, 2007). Concerning syntax, several machine-readable formats for DL are also
well established; first of all the W3C recommends OWL (http://www.w3.org/2007/OWL) in
five syntax variants: RDF/XML, OWL/XML, Functional Syntax, Manchester Syntax, and
Turtle.
OWL is accordingly the first choice in the OASIS project for the development of ontolo-
gies. This is for two interdependent methodological reasons: DL is expressive enough for
most of the current OASIS application purposes and OWL is the ontology language with the
best tool support in terms of ontology development. Nevertheless, we cannot in general re-
strict our formal framework to DL and OWL since the overriding research aim of OASIS is
for an open and extensible framework. While the web ontology language OWL is being con-
stantly refined and extended, its main target application remains the Semantic Web and re-
lated areas, and it cannot therefore be expected to be fit for all purposes; there will always be
new, typically cross-domain application areas for ontologies where the employed (or re-
quired) formal languages do not directly fit into the OWL landscape. Although DL is suffi-
cient for many current applications, there are already some domains where formalisms other
than OWL are more applicable — this can be seen in certain tasks of spatial reasoning as well
as in the rules necessary in the domain of indoor localization and domotics, both areas which
are of direct relevance for OASIS.
In this context, it can be a rather difficult task for an ontology designer to choose an appro-
priate logic and formalism for a specific ontology design in advance. Moreover, failing in
making the right choice can lead to the necessity of re-designing large parts of an ontology
from scratch, or limit future expandability— both costly consequences. Heterogeneity of on-
tology languages is thus clearly an important issue and the more support we can provide for
moving between choices of underlying logic, the more general and reusable solutions will be.
As a first conclusion for the hyper-ontology framework, we therefore note the following
generic requirement for the semantic specification for ontologies: although DLs currently rep-
resent the most relevant family of logics in OASIS, other logics should be supported in the
hyper-ontology framework too, in order to be open for a broader range of semantic driven ap-
plications. Our general approach to specifying semantics for a very broad class of logics (in
particular including all DLs) is based on the theory of institutions. Since this theory also cov-
ers connections between ontologies, we go into more detail in those later sections where we
talk about the links in the hyper-ontology. At the end of this section, we also provide more
details concerning the syntax of the logics usable to formalize ontologies in this way.
4.2.2 The Links in the Hyper-ontology Framework
In the previous section we considered isolated ontologies. Yet, the major benefit of the hyper-
ontology framework for semantic applications is expected to be in the way these ontologies
can be inter-connected based on a well founded semantics, a practicable syntax, and suitable
support tools.
Again OWL already provides one—but only one—mechanism to connect ontologies,
namely via the import construct. With imports one can build a coherent network of OWL on-
tologies where each ontology can be reused arbitrarily often by other ontologies. Importing a
source theory into a target theory means that the target theory extends or refines (or both at the

same time) the source ontology: that is, by adding new concepts and roles (classes and proper-
ties in OWL terminology) to an ontology, we extend its vocabulary and, by adding new axi-
oms, we refine its meaning.
This mechanism is very similar to the inheritance mechanism in the object oriented pro-
gramming paradigm where the extended construct for classes corresponds to the import con-
struct for ontologies: by adding new properties or methods we extend an object’s signature
and by adding additional functionality to methods (e.g. via overloading or overwriting) we are
refining its functionality. Imports in the ontology realm are as beneficial as inheritance in ob-
ject oriented programming and import or include mechanisms in other modular programming
paradigms. Enabling content (code) reuse is the most obvious relevant benefit of the mecha-
nism in both cases.
The mechanism has one serious limitation, however. It requires a homogeneous conceptual
organization of the content, i.e. the ontologies participating in an import chain must be en-
coded in the same logic (OWL), they must not contradict each other in any detail and they
must be particularly strict and coherent in their vocabulary across all of the ontologies thus
related (i.e., no renaming is supported). It is this homogeneity requirement that leads to the
striking limitations of ontology networks when restricted to import links: in the real world,
ontologies are at most developed homogeneously within one developer community, but in
most cases even this is not the case. Existing ontologies in the real world are heterogeneous
to a high degree and this fact needs now to be paid sufficient attention when targeting real-
world ontology development.
4.2.2.1 Types of Heterogeneity
Heterogeneity can be observed with respect to at least the three aspects described, for exam-
ple, by (Bouquet et al., 2004) and (Euzenat, 2007a) in terms of: (1) the logic formalism, (2)
the axiomatization, and (3) the vocabulary.
Heterogeneity in the Logical Formalisms
! We already argued in the previous section that different logic formalisms are more or
less adequate for different purposes. Again we can draw a parallel to software engi-
neering where various domain specific languages (DSL) have been developed — for
instance the family of all the XML-languages to process XML data. Software industry
and research have put considerable effort to make DSLs and even different program-
ming paradigms cooperate; perhaps the most notable here is Microsoft's .Net- frame-
work.
! Many communities of the semantic web rely crucially on OWL as the all-round solu-
tion to encode ontologies. But with the diversification of ontology applications it is
foreseeable that OWL will not remain the all-round solution. Some communities of
the semantic web are already aware of this fact — as shown for example in the devel-
opment of the rule markup language initiative (http://www.ruleml.org). In fact there is
no clear border line of which logic formalism should be, or should not be, called a
language for formal ontologies. With the diversification of ontology applications, this
fuzzy border line will be extended. In fact, from the perspective of formal semantics
we actually see no reason to separate formal ontologies from algebraic specification.

In the latter realm the need for heterogeneous logic formalisms has been acknowl-
edged for many years and we believe that the formal ontology community will pass
through this experience too.
Heterogeneity in the Axiomatization
Euzenat distinguishes in (Euzenat, 2007a) three types of conceptual heterogeneity differing in
coverage, granularity, and perspective. Let us take food ontologies to explain these types of
heterogeneity:
! Difference in coverage occurs when two ontologies describe different, possibly over-
lapping, regions of the world at the same level of detail and from a unique perspective.
For instance, one food ontology may cover only food that is typically consumed in
central Europe whereas another is about food consumed in central Africa.
! Difference in granularity occurs when two ontologies describe the same region of the
world from the same perspective but at different levels of detail: for one food ontol-
ogy, apples and oranges are just fruits, whereas for another one they are windfall and
citrus fruits respectively.
! Difference in perspective, also called difference in scope, occurs when two ontologies
describe the same region of the world, at the same level of detail, but from different
perspectives. A recipe-related food ontology may classify food with respect to its
taste, whereas a health oriented food ontology may instead classify food with respect
to its vitamins and nutrients.
Heterogeneity in the Vocabulary
Terminological heterogeneity occurs due to variations in names when referring to the same
entities in different ontologies. This can be caused by the use of different natural languages,
e.g. fruit vs. Frucht; different technical sublanguages, e.g. domotic vs. house_automation; dif-
ferent naming conventions, e.g. HouseAutomation vs. house_automation; or the use of syno-
nyms, e.g. car vs. automobile.
4.2.2.2 Kinds of Links
From what has been said about heterogeneity above, it should be clear that we have to con-
sider connections other than (simple) imports in order to exploit the full knowledge from a
network of heterogeneous ontologies. The subsequent section will give an overview of the
state of the art in kinds of ontology connections, drawing in particular from results reported
by the NeOn project [http://www-neon-project.org]. In addition, however, we will need also
to classify ontology links beforehand in a more abstract manner that will allow us to build a
more generic foundation for links that are of relevance to ontology design.
First of all we should be more precise in our terminology with "link", "connection", and
"relation" between ontologies. To start with the clearest term: a relation between ontologies is
a statement that can be either true or false. We say two ontologies are linked either if a rela-
tion holds between them or if one ontology is the result of an operation on the other. For in-
stance, if we take an ontology and add some concepts or axioms to it, we have linked the
original ontology to the result ontology via an extension operation. Alternatively, we can take
these additional concepts or axioms and then import the original ontology. The effect is in

both cases the same: the result ontology extends the original ontology — or equivalently: the
result ontology imports the original ontology. Instead of calling the involved ontologies
"original" and "result", it is sometimes more natural to call them source and target ontologies
as suggested above— so that the target theory is the result of an operation on a source theory.
We call such links operational links.
Every operation trivially implies a relation, namely that this operation was applied; e.g. if
we extend a source ontology to a target ontology we can trivially say that the target theory is
an extension of the source theory. Usually when an ontology developer starts developing an
ontology, it is common practice to copy and paste fragments of related ontologies into one’s
own new ontology. Of course, we could then claim that the new ontology is linked to all the
source theories (or slices of them), namely via copy and paste. With this kind of operational
semantics we are already building a kind of semantic-network, but with a rather poor seman-
tics. Knowing that an operation (like copy and paste) has been applied does not say much
about the semantic consequences of the operation. We need more from a semantic network of
ontologies than such shallow operational semantics.
For OASIS purposes, rather more significant than the operational semantics of relations is
their denotational semantics. This asks for possible interpretations of the related objects.
For instance, if one cuts pieces out of an ontology, then the question is whether this piece,
separated from its parent ontology, can still be interpreted in the same way as before or does
the cutting operation restrict or increase the possible interpretations of that piece. To give a
concrete example, consider an ontology that contains the concepts male and female, and two
axioms: 1) male and female are disjoint, 2) humans are male or female. If we remove only the
first axiom (or equivalently, extract the two concepts and the first axiom), then there are obvi-
ously other interpretations possible than in the original ontology: we could have humans who
are both male and female. Or if we decide to add to the original ontology the axiom that male
is a subconcept of female and that Peter is male, then we are actually in the situation where
we cannot find any interpretation that satisfies all the axioms (because the subsumption con-
tradicts the disjointness). Such knowledge regarding changes of possible interpretations is
much more informative then the trivial operational semantics that axioms have been added or
removed. Our focus in the remainder of this chapter is therefore on the denotational semantics
of relations between ontologies; we can accordingly omit the adjective "denotational" hence-
forth.
In our example above we considered two simple operations: adding and removing axioms
from an ontology. For these kinds of operations we actually also assume an almost trivial se-
mantic consequence: adding axioms (possibly) restricts but never increases the set of interpre-
tations, whereas removing axioms has the opposite effect. So if we have an interpretation sat-
isfying an ontology, then it might no longer be satisfiable after adding an axiom to this ontol-
ogy, whereas it stays always satisfiable whenever we remove axioms from this ontology. We
say an ontology A entails an ontology B if any interpretation for A also satisfies B. The op-
eration of extending an ontology A to A' by adding some axioms has therefore the semantic
consequence that A' entails A. In the case of restriction by removing axioms, we have the op-
posite relation.

The connection between the operation of ontology extension (and restriction respectively)
and entailment is almost trivial, but only when our underlying logic is monotonic (as is the
case for DL). The situation would be different if we would assume non-monotonic logics
where the addition of axioms can lead to the retraction of consequences. To give the standard
example: suppose we believe that every bird can fly. From the fact that Tweety is a bird it is
reasonable to infer that Tweety can fly; but if you add the premise that Tweety is a penguin
then the inference is nullified. However, at the present time we do not consider non-
monotonic logics in the hyper-ontology context.
For monotonic logics, if A is an extension of B (B a restriction of A) then A entails B. This
fact holds by the definition of the underlying logic: that is, we do not need to prove that the
entailment relation holds since this is guaranteed by the possibilities that the logic imposes.
We call links that hold by definition (with respect to any logic that we consider here) defini-
tional links. The most important links of this kind to mention here are the import
(=extension) link and its counterpart the export (=restriction or extraction) link. These defini-
tional links are used to build new ontologies from given ontologies. Instead of merely import-
ing a single ontology, it is also straightforward to import several ontologies. This can be seen
as a two step process: first build the union of all ontologies to be imported then import this
union. Analogously, we can extract axioms from the intersection of several ontologies. Both
of these operations have the semantic consequence regarding entailment as said above —
there is nothing further requiring proof. In an OWL-network of ontologies there are in fact
only definitional links, more precisely import links. Thus, as a consequence, OWL networks
can only be homogeneous due to the implied entailment relation of the import links; i.e. these
import links cannot state any other relationship then entailment by definition.
In contrast to definitional links, we can also considering asserting links that claim a rela-
tion between ontologies that does not hold straightforwardly by definition; relations of this
kind do trigger proof obligations. This means that when such a link is specified, whether the
relation actually holds or not needs to be proved with respect to the concrete ontologies being
related. In principle it is always possible to assert links arbitrarily between two ontologies and
so we can consider an entire family of inter-ontology links. One of the most significant kinds
includes relations answering the question of whether two given ontologies contain overlap-
ping knowledge; or more formally: do they have a partially common interpretation—and, in a
specialized case, whether one ontology entails the other without importing it. Knowing the
answer to such questions is relevant practically: when we know that a target ontology T en-
tails a source ontology S, then we know that everything that can be inferred from S can also
be inferred from T. Moreover, we know from the transitivity of the entailment relation that for
any ontologies O1, O2, and O3, if O1 entails O2 and O2 entails O3, then O1 entails O3 also.
This then provides reusable knowledge. Also, if we know that two ontologies O1 and O2 con-
tain overlapping knowledge, then we know that we can extract an ontology C from these two
ontologies such that C is entailed in O1 and O2. This extract ontology C might in turn be en-
tailed in other ontologies, thereby increasing knowledge reuse even more. We can therefore
get much more knowledge reuse out of a network of ontologies if we make use not just of
definitional but also of asserting links.
Apart from entailment as an asserting link between ontologies, there are other links of
practical interest corresponding to the following question for a given ontology O1 that entails

another ontology O2: does O1 contain more knowledge than the entailed ontology O2? Even
if O1 contains many more axioms than O2, it may still not contain more information. In this
case we say that O1 is a conservative extension of O2. If the entailing ontology O1 has a lar-
ger signature (i.e. has more concepts than O2), then O1 is still called a conservative extension
of O2 as long as it does not add any constraints on their common concepts. For instance, re-
call our toy ontology O2 from above that contains Male and Female as its only concepts and
as only axiom that these concepts are disjoint. Now suppose that we have an ontology O1
containing the same concepts and the same axiom as O2 and, in addition to that, the concept
Human and the axiom that Human is the union of Male and Female. Then O1 is still only a
conservative extension of O2 (although O1 has one more concept than O2), since O1 does not
add any new information to their common concepts Male and Female (only to the concept
Human). In fact, here we have the special case of definitional conservative extension: any
interpretation of the common concepts of O1 and O2 uniquely determines the interpretation of
the additional concept Human, since we defined that Human is equivalent to the union of
Male and Female. If we had defined Human only as a subclass of this union, then the concept
would not be uniquely determined by the concepts Male and Female — it would also allow
interpretations where Males or Females are not humans.
Finally, we also mention at this point the term "connection" as a particular kind of link. In
the context of ontologies, we consider the concept of E-connections (Kutz et al., 2004) as the
prototype of connection. We present E-connections in depth below, but basically an E-
connection serves to link concepts from different ontologies with relations that are themselves
not part of any of the involved ontologies. Our understanding of connection tries to capture
informally the idea behind E-connections in a rather general way: given two independent on-
tologies then any set of axioms that constrain the concepts of these ontologies (but no addi-
tional concepts) is called a connection between these ontologies. This loose definition of
"connection" is flexible enough to cover all the kind of connections discussed in the following
sections.
4.2.3 The State-of-the-art in Connecting Ontologies
Connecting between ontologies can be seen analogously to connecting between submodules

of a single ontology. In fact, since we now see ontologies as combinations of modules, the
exact distinction between ‘ontology’ and ‘ontology module’ becomes more one of bundling
functional components for use than a formal distinction. Concerning modularization, the de-
liverables D1.1.3 and D1.4.4 of the NEON project [http://www.neon-project.org] report the
relevant state-of-the art in considerable detail. All that is reported in these deliverables is es-
sentially still up-to-date and so we only need to summarize their review; we focus, however,
particularly on those parts that are relevant for talking about formal semantics. In addition,
there are some further approaches relevant in the OASIS contexts that we also consider worth
mentioning but which have not been considered in the NEON deliverables. These include, in
particular: 1) interface based ontology modularization (Ensan and Du, 2008) and 2) ontology
mapping based on information-flow theory (Kalfoglou and Schorlemmer, 2003b) (the theory
of information flow is introduced in (Barwise and Seligman, 1997)). We summarize these two
approaches at the end of this section.

4.2.3.1 Package-Based Description Logics (PDL)

Package-based Description Logics were introduced by Bao, Caragea, and Honavar (Bao et
al., 2006). Here we summarize from NEON's deliverable D1.4.4 page 33. A package of an
ontology is a fragment of the ontology's terms and axioms. A package P can also use terms
defined in another package Q, called foreign terms in P. In this case we say that P imports Q.
The importing closure of a package P contains all packages that are either directly or indi-
rectly imported into P. A package-based Description Logic ontology, or a PDL ontology, then
consists of multiple packages, each of them expressed in DL.
A package P can be nested in one and only one other package Q. In that case we say that P
is a subpackage of Q and Q is the superpackage of P. The collection of all package nesting
relations in an ontology constitutes the organizational hierarchy of the ontology.
For each package in a PDL, we can define the local interpretation of the package in a way
similar to the interpretation for a description logic ontology. A local interpretation interprets
everything in the local domain and excludes the semantics of the foreign terms. This means
that the same term may be interpreted differently in two packages; they do not need to be in
accordance one with another.
In contrast to the local interpretation, a global interpretation is the interpretation of all the
packages of an ontology: i.e., the ontology is interpreted from the point of view of all pack-
ages making up the ontology and not from the local point of view of any single package. A
PDL ontology is globally consistent iff a global interpretation exists. While it makes perfect
sense to demand that a local interpretation exists for each package, the same does not hold for
the stronger requirement of global interpretation of all packages. Moreover, if local consis-
tency cannot be guaranteed, integrity of any information that is based on that package also
cannot be guaranteed. On the other hand, taking into consideration that the different modules
may be developed independently by developer groups with different perspectives and inter-
ests, it could be that global consistency does not exist even though local consistency is
achieved.
Finally, a distributed interpretation witnessed by a package P represents the semantics of
axioms in P and its importing closure. This is different from a local interpretation in that a lo-
cal interpretation provides an interpretation only for the local package, handling foreign terms
as local terms. It is also different from a global interpretation, since the latter is a global model
for the whole ontology, whereas the former is a model for only some packages in the ontol-
ogy.
4.2.3.2 Distributed Description Logics (DDL)
As introduced in (Borgida and Serafini, 2003; Serafini and Tamilin, 2004; Serafini et al.,
2005a), a DDL knowledge base consists of a set of local TBoxes of ontologies and a set of
bridge rules B between these local TBoxes. Each of the local TBoxes is a collection of axioms
called general concept inclusions (GCIs) in its own local DL. Each set of rules bridge from
one TBox T1 to another T2. Intuitively, these rules are meant to “import” information from
T1 to T2, and are therefore directed. There are two kinds of bridge rules: into-bridge rules and
onto-bridge rules. An into-bridge rule states that a concept in the source ontology is subsumed
by a concept in the target ontology; an onto-bridge rule states the opposite.

Each local ontology has its own local interpretation (as in standard DL semantics), whereas
the bridge-rules are interpreted as relationships between the distinct interpretation domains of
the participating local interpretations.
4.2.3.3 Integrated Distributed Description Logics (IDDL)
Here it suffices to simply quote from deliverable D1.1.3 of the NEON project:
"IDDL (Zimmermann, 2007) is another formalism for distributed reasoning upon net-
worked DL knowledge base. Similarly to DDL, an IDDL interpretation allocates a differ-
ent interpretation to each ontology but instead of relating domains directly, they are corre-
lated in another domain called global domain of interpretation. The intuition behind this
formalism is that ontology mappings may be provided by third party agents which assert
correspondences from a point of view encompassing both mapped ontologies. With that
perspective in mind, using directional bridge rules like DDL is quite unsatisfactory. A con-
sequence of the semantics of this formalism is the transitivity of ontology mappings. This
formalism instantiates a generic distributed semantics presented in (Zimmermann and
Euzenat, 2006) in the case of ontologies represented in description logics. The notion of
equalising function –i.e. an abstract function that is part of the global interpretation and
map elements of a local domain to elements of the global domain– is used to correlate local
domains of interpretation from different ontologies into a unique global domain."
4.2.3.4 E-Connections
A full account of E-connections is provided in (Kutz et al., 2004). A good summary of this
approach is provided online by the "Maryland Information and Network Dynamics Lab Se-
mantic Web Agents Project" (http://www.mindswap.org), which we quote in the following:
"An E-Connection is a knowledge representation language defined as a combination of
other logical formalisms. Each of the component logics has to be expressible in the Ab-
stract Description System (ADS) framework, which includes Description Logics (and
hence OWL-DL), Modal and Epistemic logics, as well as many logics of time and space.
Obviously, different component logics will give rise to different combined languages, with
different expressivity and computational properties.”
E-Connections were originally introduced as a way to go beyond the expressivity of each of
the component descriptions, while preserving the decidability of the reasoning services run-
ning with respect to those descriptions. An E-Connection language is a formalism strictly
more expressive than any of its component logics, and which is decidable provided that each
of its components is decidable. Hence, E-Connections provide a trade-off between the expres-
sivity gained and the computational robustness of the combination.
Here, we will consider E-Connections particularly as a language for defining and instanti-
ating combinations of OWL-DL ontologies. We restrict ourselves to OWL-DL, since OWL-
Full is beyond the Abstract Description System framework upon which the original defini-
tions of E-connections rely. Whenever we mention OWL in the following, therefore, we now
implicitly refer to OWL-DL.
An E-Connection is a set of "connected" ontologies. An E-Connected ontology typically
contains information not only about classes, properties and their instances, as in OWL, but

also about a new kind of property, called links, which are somewhat similar in spirit to
datatype properties. In OWL, the classes defined in terms of datatype properties "combine"
information from different domains: the actual application domain of the ontology and the
domain of datatypes. The coupling between datatypes and the ontology is always achieved
through restrictions on datatype properties. For example, a "retired person" can be defined in
OWL as a person whose age is greater than 65 by using a class ("Person") in the ontology and
a restriction on a datatype property "age" to a value "greater than 65". Both from a logical and
from a modelling perspective, the domain of the ontology and the domain of datatypes are
disjoint: from a modelling perspective the (application) domain of "persons" is disjoint from
the (application) domain of "numbers"; from a logical perspective, in OWL the domain where
classes, properties and individuals in the ontology are interpreted is disjoint from the domain
of datatypes, and datatype properties are interpreted as binary relations with the first element
belonging to the domain of the ontology and the second to the domain of the datatypes.
In the same vein, link properties allow us to create classes in one ontology based on infor-
mation from a different ontology—provided that the domains of the ontologies are disjoint,
both from a logical and a modelling perspective. For example, a "Graduate Student" in an on-
tology about "people" could be defined as a student who is enrolled in at least one graduate
course, by using the class "Student" in the people ontology and a someValuesFrom restriction
on the link property "enrolledIn" with value "GraduateCourse". This latter could be a class in
a different ontology dealing with the domain of "academic courses". There is no then no need
for these ontologies to be more closely connected or combined within a single specification or
theory. Link properties are logically interpreted as binary relations where the first element be-
longs to the "source" ontology and the second to the "target ontology" of the link property.
Conceptually, a link property will be defined and used in its "source" ontology. For example,
the link property "enrolledIn" would be defined as a link property in the "people" ontology
with target ontology "academic courses". An E-Connected ontology in the Semantic Web
context can be roughly described as an OWL-DL ontology extended with the ability to define
link properties and construct new classes in terms of restrictions on them.
From a modelling perspective, each of the component ontologies in an E-Connection is
modelling a different application domain, while the E-Connection itself is modelling the un-
ion of all these domains. For example, an E-Connection could be used to model all the rele-
vant information referring to a certain university, and each of its component ontologies could
model, respectively, the domain of people involved in the university, the domain of schools
and departments, the domain of courses, etc. Below we explore the utility of this construct for
domains required in the OASIS scenario.
4.2.3.5 Interface-Based Modularization
The interface-based ontology modularization framework for knowledge encapsulation is pre-
sented in (Ensan and Du, 2008). Within the context of this framework, an ontology can be
defined and developed as a set of ontology modules that can access the knowledge bases of
the others through well-defined interfaces. These interfaces facilitate knowledge encapsula-
tion as they allow access only to those parts of an ontology that are published in the interface.
Thus a modular ontology in this framework is an ontology together with its interface. Any
individual ontology can realize or utilize several interfaces.

An important implication of this framework is again that ontology modules can be devel-
oped completely independently of each others’ signature and language. Such modules are free
to utilize only the required knowledge segments of the others. The variety of approaches
which, each in their own way, provide support for the independent development of ontologies
and ontology modules all point towards the increasingly accepted position that alternatives to
monolithic ontology design are urgently required.
4.2.3.6 Ontology Mapping Based on Information-flow Theory
In a rather different approach, Schorlemmer and Kalfoglu (Kalfoglou and Schorlemmer,
2003b) employ information theory (Barwise and Seligman, 1997) to connect ontologies. They
suppose that, when two communities desire to share knowledge but each one has encoded
knowledge according to its own local ontology—O1 and O2 respectively—they have previ-
ously agreed upon a common understanding, a reference ontology O0 , in order to favour the
sharing of knowledge. Typically each community will have its local ontology populated with
its own instances, while the reference ontology will not have instances.
However, although having agreed upon a reference ontology, each community might pre-
fer to communicate via its own local ontology, provided these ontologies O1 and O2 (or at
least a significant fragment of them) conform to the reference ontology O0. They provide a
methodology to establish this conformance by looking for, and further generating, ontology
mappings O0 ! O1 and O0 ! O2 from the reference ontology to local ontologies. The
methodology is based upon formalising ontologies as local logics and ontology mappings as
logic infomorphisms. The link O1 " O0 ! O2 between local ontologies via the reference
ontology, together with the generated ontology mappings from the latter to the former two,
provides an alignment structure of ontologies that uniquely determines a global ontology O—
an ontology that could be either constructed from the alignment structure or else generated
‘on-the-fly’ for the purpose of knowledge sharing.
4.2.4 A Simple OASIS Case Study of Connected Ontologies
Having introduced the basic notions upon which a hyper-ontology framework can be built,
before proceeding further we will exemplify them in a simple OASIS case study.
Modern consumer electronics tend to be more and more hybrid. The functionality of the
first mobile phones on the market in the early 1980's was restricted to the telephone. Nowa-
days, almost every mobile phone is not just a mobile phone, but also an address book, a cal-
endar tool, a digital camera, an mp3-player, etc. Since the user interface of such gadgets al-
lows only for a very limited number of control elements, most of these elements are necessar-
ily reused. Sometimes one control element is used for the same functionality in different ap-
plications and sometimes for different functionalities. For instance, a pair of buttons is used
not only to control the volume for the telephone mode as well as for the mp3-player, but also
to control light sensitivity when the gadget is used as a digital camera.
The general observation is that user interfaces of hybrid devices require a high degree of
re-usability of their control elements. Before the emergence of the touch screen, there was one
inevitable problem: the controller as physical objects are always also present in applications
where they don't bear any functionality. This is clearly unsatisfactory as it may irritate the

user. One design approach to overcome this problem is extreme reuse, whose maxim is: no
dead controller in any context. However, the result of this approach is very often a deeply
nested menu to switch the context. In the limit, the extreme case would be a single button that
can have any functionality depending only on the context. Since the context is changed by
navigating through a menu, this results in unmanageable menu structures that in practice
would distract people (in particular the elderly) when using such devices.
With the advent of touch screens as user interfaces the problem can be easily avoided. Pre-
sumably the flexibility of a touch screen to display virtually any user interface is the basis for
the commercial success of those gadgets making use of this technique. However, based on
this flexibility new challenges arise, namely how to manage the potentially infinite number of
possible user interfaces? The naive way is to build for each application its own GUI from
scratch. Obviously this is not very cost-effective; the reusability factor would be zero. For
that reason many GUI software libraries provide reusable modules. However, these building
blocks are often viewed only as visual objects. Their conceptual role in different contexts is
usually not systematically specified.
Specifying GUIs employing modularized ontologies could be used to support a rigorous
composition of simple GUI elements to the most complex GUI configurations, at the same
time reflecting a natural adaption to different contexts. The various kinds of ontology links
described so far can serve as useful facilitators for this task. We mentioned above the import
link as the most obvious construct for this purpose. Here we demonstrate how other con-
structs, beyond OWL 2.0, facilitate further possibilities of reuse. These constructs are already
part of a rigorously defined extension of OWL, provided as part of the HetCASL language
family that we describe more below; this provides rich structuring constructs and is already
supported by the Hets system that we employ (cf. Section 5.1.3). For the current version of
this deliverable we provide just two basic examples. These exemplify two fundamental means
of modularization that being to move us beyond the current state of the art in ontology devel-
opment. The first means is renaming and the second is ontology integration, or V-alignment
as defined in (Kutz et al., 2008b).
4.2.4.1 Reuse via Imports and Renaming
Our goal in this example is to build systematically from a very generic Controller ontology
new ontologies for more specific controllers, namely for volume and brightness control (e.g.
for a television) as well as for a mute button and a power switch. This example should make it
clear how ontology import with renaming facilitates knowledge reuse.
Our formalism in the following is OWL expressed in Manchester syntax and enriched with
the structuring constructs supplied by HetCASL (cf. Section 4.2.5). Each ontology starts with
the token spec followed by the name of the ontology at hand and ends with the end token.
We start with the Controller ontology:
spec!Controller!=!
!!!!!Class:!Controller!
!!!!!Class:!StateSpace!
!!DataProperty:!hasSize!
! !!! Domain:!StateSpace!Range:!integer!
!

!!!!!ObjectProperty:!regulates!
! !!Domain:!Controller!!Range:!StateSpace!
! !!Characteristics:!Functional!
end!
This generic ontology simply says that a Controller!regulates a StateSpace.

Another very elementary and generic controller is a switch. Actually a switch is already a
specialization of a generic Controller in that it restricts the StateSpace to contain only two
values:
spec!Switch!=!
!!!!!Controller!with!StateSpace!|">!BinaryState!
then!
!!!!!Class:!BinaryState!SubclassOf:!hasSize!exactly!2!
end!
!
The Switch ontology imports everything from the Controller ontology, but renames
StateSpace to BinaryState!while doing so. The import line is followed by the then to-
ken that marks the beginning of new constraints for the current ontology—here it is the con-
straint that the BinaryState contains exactly two states. Based on this generic switch we
can straightforwardly model more specific switches such as, for instance, a power switch, a
mute button, etc.:
spec!PowerSwitch!=!
!!!!!Switch!with!BinaryState!|">!PowerSupply!
then!
!!!!!PowerSupply!EquivalentTo:!{on,off}!
end!
!
To improve the intelligibility of this ontology definition, we rename BinaryState to
PowerSupply and make the two states explicit {on,off}. Similarly we can proceed for a
mute button and any other kind of switch accordingly; e.g.:
spec!MuteSwitch!=!
!!!!!Switch!with!BinaryState!|">!Loudness!
then!
!!!!!Loudness!EquivalentTo:!{normal,quiet}!
end!
Apart from switches, a typical UI also provides sliders. The characteristic of a slider is that
its state space has a minimal and maximal element, but many (possibly infinite) states in be-
tween. For the sake of brevity we only sketch a LinearSpace ontology:
spec!LinearSpace!=!
!!!!!Class:!LinearSpace!!
! !!!!SubclassOF:!lessThan!{Maximum}!and!greaterThan!{Minimum}!
!
!!!!!ObjectProperty:!lessThan!

!!!!!!!Domain:!LinearSpace!Range:!LinearSpace!
!
!!!!!ObjectProperty:!greaterThan!
!!!!!!!Domain:!LinearSpace!Range:!LinearSpace!
end!
!
By means of this LinearSpace ontology and the generic Controller ontology com-
bined, it is straightforward to specify a generic LinearController ontology as follows:
spec!LinearRegulator!=!
!!!!!LinearSpace!and!{Regulator!with!StateSpace!|">!LinearSpace}!
end!
Here we form both the union of the two contributing ontologies (via the and token) and at the
same time effect a type restriction (via the with token as above).
From this new ontology, we can readily create further ontologies for volume, brightness, or
similar linear sliders:
spec!VolumeControl!=!
!!!!!LinearRegulator!with!StateSpace!|">!Volume!
then!
!!!!!hasUnit!value!"dB"!
end!
!
spec!BrightnessControl!=!
!!!!!LinearRegulator!with!StateSpace!|">!Brightness!
then!
!!!!!hasUnit!value!"lum"!
end!
These examples show how to model stepwise more complex UI's by means of import with
renaming. In each case it has to be stressed that we simultaneously achieved a fairly deep se-
mantic modelling that supports reasoning appropriate for these objects. The combinations of
properties follow from the mechanics of the formalism.
Let us now turn to a more involved construction to connect ontologies also making use of
renaming.
4.2.4.2 Concept Interface and Ontology Merge via V-Alignment
The method presented above can be viewed as a method for building more and more complex
or specialized ontologies in a top-down manner. We want to consider now a scenario that
suggests rather a middle-out procedure.
Suppose we already have two medium complex ontologies for remote controls—say one to
control a radio and one to control a TV. It is not uncommon for people to have turned on the
television and the radio at the same time. As an example situation, we could imagine listening
to music in the radio, while also waiting for a TV broadcast that actually should have started
already but is delayed for some unknown reason. So one watches TV and listens to the radio.

If the current sound from the TV is unpleasant whereas the music from the radio is agreeable,
one would probably want to control both volumes accordingly. Assume a remote control at
hand with a touch screen interface. As already mentioned above, such a UI can easily display
any kind of UI. For the given scenario the optimal UI would be perhaps a merged UI that
combines some elements but identifies others from the TV and radio remote control respec-
tively—so to say a spontaneously produced hybrid remote control.
On the ontological level this can be accomplished with the so called push out method
(more details can be found in (Kutz et al., 2008b). Fig. 13 depicts this idea: given is a radio
remote control (RC) ontology and a TV remote control (TVC) ontology. For the sake of clar-
ity we consider only the two types of control elements: volume slider and power switch. In
our scenario we want to have a merged UI with two volume sliders, one for the television and
one for the radio. Note that in both source ontologies RC and TVC, the same concept names
for their volume sliders are used. Therefore a simple merge of these two ontologies would
identify the two sliders. On the other hand there are two distinct names for the power
switches: Power in the RC ontology and On/Off in the TVC ontology. However, it is con-
ceivable that we might need only one power button in our scenario. Again a simple merge
would not yield the result we would like to have here— a single power button instead of two
in the merged UI.
The so called V-alignment is the solution to this problem. At first we decide which of the
concepts from the given two ontologies RC and TVC we want to identify. This step results in
a one-to-one concept mapping. Now we create a new ontology that contains for each of these
mapped concept pairs the preferred concept name (or possibly even a new name if preferred).
In our case we chose Power. This new ontology in the middle represents the interface be-
tween the RC and TVC ontology. Now the mapped concept pairs can be replaced without loss
of information by a renaming from the interface concept to the original; i.e. in the case of RC
the concept name Power remains Power, but in case of the TVC ontology the Power is re-
named to On/Off.
The intention of the interface is that the concept names of the interface should only occur
once in the merged ontology; even if they are different in the involved source ontologies, they
are identified when appropriate. Syntactically this affects not just a single name occurrence,
but any occurrence in any axiom: this is because the operations described here are essentially
semantic, i.e., they operate at the level of what the specifications mean rather than on the sur-
face and structural patterns observable in the specifications. Similarly, all concept names that
happened to be identical in the two source theories but are not intended to be identified are
renamed so that they are distinguishable (syntactically again in each occurrence) in the final
merged ontology. Using the sophisticated tools of the Hets system, much of this combination
can be automated. Selecting the concepts that are to be placed in correspondence must be de-
cided by an ontology developer, then the appropriate renamings for the merge and the merge
from the two source ontologies to the result ontology itself is done by Hets.

Fig. 13. V-Alignment between a radio controller (RC) ontology and a television controller ontology (TVC).
Only the relevant controllers are displayed to demonstrate V-Alignment, so named because of the V-shapes formed by the connecting arrows
between the ontologies.
The creation of concept mappings is already supported to a certain extent in ORATE (cf.
section 5.1.2), although the semantics for these mappings is left open. By employing the con-
cept of V-alignment we will be able to equip these mappings with a rigorous semantics which
can then be operated upon by tools such as Hets.
To conclude, it should be reiterated that at this stage we have exemplified only two kinds
of connection. More will follow in the updates of this deliverable as we draw on further de-
velopments in the theory of ontology connection. (Kutz et al., 2008a) in fact go on to define
several distinct ‘shapes’ of alignments beyond their V-alignment illustrated here. In particular
more expressive alignment methods—so-called W and M shapes--will allow to model align-
ments with far more sophisticated cross connections of ontology concepts than just the one-
to-one mappings shown here. Such one-to-one concept mappings can be viewed as the sim-
plest kind of bridge rules, whereas the W- and even more powerful M-alignments provide
method to realize the full generality of E-connections employing CASL structuring mecha-
nisms. This path from theory to practice will be explored concretely with respect to the mod-
elling requirements revealed during application construction within OASIS.
4.2.5 Institution-Based Foundation of the Hyper-ontology Framework
In the following sections we sketch the central components for a general foundation of the
hyper-ontology framework. This will be refined as needed in the planned updates of this de-
liverable scheduled for M30, 40 and 44 of the OASIS project and sets out just how the con-
siderations discussed previously in this chapter can be formally anchored.
4.2.5.1 Theory of Institutions and Entailment Systems
Institutions originated in the late 1970s and early 1980s for studying model-theoretic proper-
ties of logics (Goguen and Burstall, 1992); they have given semantics to powerful module
systems of both imperative and declarative programming languages, multi-logic specification
languages, databases, and ontologies. Most recently they have also been applied to provide

abstract semantics to semantic web languages (Lucanu et al., 2006). An institution captures
the essential aspects of logical systems that underlie any formal specification of a computer
program: i.e., the notion of a signature system, of well-formed sentences over a signature, and
for each signature, notions of a system of models and a satisfaction relation between models
and sentences.
The theory of institutions is based on category theory and in particular on the notions of
category, opposite category, functor, and natural transformation. We will not go into technical
details here, but briefly present the formal definition of an institution for completeness. For-
mally, an institution is a quadruple I = (Sign, Sen, Mod, |=) consisting of
! a category Sign of signatures and signature morphisms;
! a functor Sen : Sign ! Set assigning to each signature # a set of well-formed #-
sentences;
! a functor Mod : Signop ! Set assigning to each signature # a set of #-structures;
! a function |= assigning to each # a binary relation |=# ∈ Mod(#) × Sen(#) called

satisfaction, satisfying the following fundamental property: for all $ : # ! # , % ∈
Sen(#) and M ∈ Mod(# ),
Mod($)(M ) |=# % iff M |=# Sen($)(%).
Institution theory can be viewed as a model-theoretic view on logics. The concept of an en-
tailment system is introduced by Meseguer (Meseguer, 1989) and aims to integrate proof-
theoretic aspects with institution theory. The entailment relation is the central object in an en-
tailment system and can be viewed as an abstract relation for derivability in a proof-theoretic
sense. It is required to be reflexive, monotonic, transitive, and invariant with respect to signa-
ture morphisms. Actually the following properties are shared by all calculi that we consider
relevant for reasoning in the area of formal ontologies:
1. reflexivity: we can always prove a formula if we can assume it,
2. monotonicity: we can always prove with more assumptions what we can prove with
fewer,
3. transitivity: using as an additional assumption something already proved should not
give us more conclusions than those already entailed by our original assumptions, and
4. translation: changing our signature should affect neither the semantics of our formula
nor the validity of our proofs.
4.2.5.2 Development Graph
The development graph (Autexier et al., 2000) is a specification management framework. Its
semantics relies on institution theory and entailment systems. It was designed to maintain and
utilize the structured mechanisms of various specification languages for the purposes of the
evolution and verification of industrial-scale software. In this setting, software systems as
well as their requirement specifications are formalized in a specification language like CASL

(Mosses, 2004) or VSE-SL (Dieter Hutter et al., 1996). We already suggested above that we
consider specification languages to include ontology languages and any DL-language (e.g.
OWL). Consequently we can use "specification" and "ontology" synonymously in this con-
text.
Fundamental for the understanding of the purpose of the development graph are the no-
tions verification in-the-large and verification in-the-small. Basically verification in-the-large
means the verification of postulated specification entailments, whereas verification in-the-
small is about verification of postulated assertions within a specification.
The development graph is then a graph whose nodes represent specifications and whose
links represent logical relations between those specifications. The graph allows four types of
edges:
local definition links global definition links
local theorem links global theorem links
Global links are transitive relations, i.e. if specifications S1, S2 and S3 are on a path of
global links, then S1 is implicitly related to S3. Local links in contrast do not have this transi-
tive semantics. All links are labelled with signature morphisms. The axiomatization of each
specification is split into a local part, which is attached to the node as a set of formulae, and
into a global part, denoted by ingoing definition links which import the axiomatization of
other nodes via the signature morphisms attached to the links. While a local link imports only
the local part of the axiomatization of the source node of links, global links are used to import
the entire axiomatization of the source node (including all the imported axiomatizations of
other source nodes). In the same way, local and global theorem links are used to postulate re-
lations between nodes, namely specification interpretations. This distinction between local
and global is a specific feature of development graphs.
These graphs are more than simple pictorial representations in that a well-defined seman-
tics stands behind them; this enables substantial organisational work to be carried out auto-
matically. In particular, the development graph calculus provides inference rules to decom-
pose the global links into local links preserving the semantics of the logical relations between
specification nodes: all theorem links between specification nodes hold in the original graph
iff all local relations between those nodes hold after the decomposition. In the course of a
specification change some of the links’ statuses are changed from proven to unproven. The
goal is to prove all postulated theorem links within the graph since this then shows that the
organisation of the contributing theories, together with all of their explicit imports and ex-
ports, are correctly accounted for. Such proofs can be done either in the original graph or in
the decomposed graph, but graph decomposition reduces complex proof obligations to smaller
local proof obligations.
A local change of some specification typically changes the status of the whole graph to un-
proven. However, usually this can then be repaired locally, i.e. without reproving all theorem
links again. Decomposition to local links serves exactly the purpose of identifying redundant
proof obligations, since the status of all local theorem links is maintained. An unproven global
theorem link typically decomposes to many local theorem links, most of which, however, are
already proven (either as there is a parallel definitional link, or a proof was found before in

the evolution of the graph). Thus development graph decomposition explicitly captures
mechanisms that enable systems to avoid redundant proofs (verification in-the-large). If there
are still open proof obligations after the complete decomposition, then these obligations must
be passed to an external theorem prover (verification in-the-small), of which the Hets tools
provides several standard alternatives.
Basic operations on the development graph. In order to build complex specifications sys-
tematically and to relate them to each other, the following basic operations are defined over
the indicated types of objects:
• Nodes: insert/delete nodes
• Links: insert/delete global/local definition/theorem links
• Local signature: insert/delete symbols
• Local axioms: insert/delete/change local axioms
After modifying the development graph a difference analysis between the old and the new
graph triggers one or several of these operations. The difference analysis aims at the preserva-
tion of as many validated conjectures during the transformation of the old proof to the new
development graph. This means the difference of axioms and signatures (between the old and
new development graph) which were available during proof time must be determined.
The basic operations which change the development graph require a notion of node-
equivalence. As there is in general no simply provable optimal solution to this question, heu-
ristics are applied based on the number of shared local signature symbols plus the similarity
of the incoming definition links. This then associates nodes and links of the new and old de-
velopment graph. In summary, development graphs provide an overview of the (heterogene-
ous) specification module hierarchy and the current proof state, and thus may be used for
monitoring the overall correctness of a heterogeneous development such as a hyper-ontology.
To this point in this section we have focused on the components of the hyper-ontology
framework that are meant to specify its semantics. We now shift our focus to concentrate on
languages that can be used to encode ontologies as institutions and to link them in a develop-
ment graph, thereby providing an actual foundation for specifying hyper-ontologies.
4.2.5.3 CASL and HetCASL
CASL (Bidoit and Mosses, 2004; Mosses, 2004) is an expressive specification language that
has been designed by CoFI, the international Common Framework Initiative for algebraic
specification and development (Mosses, 1997), with the goal to subsume many previous alge-
braic specification languages and to provide a standard language for the specification and de-
velopment of modular software systems. CASL provides four layers:
1. Basic specifications provide the means to write specifications in a particular institu-
tion, and provide a proof calculus for reasoning within such unstructured specifica-
tions.
2. Structured specifications express how more complex specifications are built from
simpler ones.

3. Architectural specifications, in contrast to structured specifications, prescribe the

modular structure of the implementation, with the possibility of enforcing a separate
development of composable, reusable implementation units. The semantics and proof
calculus within this layer is formulated in terms of the semantics and proof calculus
given in the previous layers.
4. Finally, libraries of specifications allow the (distributed) storage and retrieval of
named specifications.
In the context of the hyper-ontology framework, the first two layers are particularly inter-
esting. The first layer basically allows one to write standalone ontologies, i.e. an isolated node
in the development graph, whereas the second layer provides all the rich structuring con-
structs that represent the various kinds of links in the development graph. In the previous sub-
section about the development graph, we have in fact mentioned only basic types of links.
CASL actually provides more variants that are relevant here: in particular, a signature mor-
phism can be attached to every definitional and theorem link. The effect of this signature
morphism is basically a renaming of all signature symbols of the source ontology on the fly.
In the case of an import link, this means that we do not import the source ontology as is, but
instead translate it into a new vocabulary according to our needs. Hence, this feature supports
what we called above ‘heterogeneity in the vocabulary’ (which is not supported in the simple
import construct in OWL). We saw some uses of this above; some further obvious use cases
are to adjust concept names from different natural or technical languages (e.g. Frucht -> fruit,
domotic -> house_automation) and to adjust naming conventions (e.g. HouseAutomation ->
house_automation). A more sophisticated use case would be to import a source ontology
twice into the same target theory, but with different renamings. At first glance it might appear
obscure to have two different names for one thing in an ontology, but in a highly modularized
ontology network this can in fact be extremely useful. For example, there are usually very
small ontologies with such a general structure and accompanying semantics that their con-
cepts can stand for several concrete concepts in parallel. For instance, consider an ontology
with just one relation "less" that is axiomatized with the usual axioms for a partial ordering.
This small specification could naturally be imported several times into the same target ontol-
ogy since it provides important aspects of the meaning for a whole range of more concrete
relations such as "smaller", "earlier", "before", etc. because all these more concrete concepts
have in common that they obey the axioms of partial order.
Within any group of ontologies that are considered within the current state of the art and
which have been developed independently, one finds occurrence of repeated definitions which
fail to bring out such repeated semantics. This can even be shown in many single ontologies,
where due to their size and monolithic structuring, opportunities for reuse are missed and
definitions repeated. This is more than just an issue of economy: it may well be the case that
changes made to such repeated semantics occur, and then these changes may fail to be propa-
gated to all uses of the similar semantics. This cannot be detected as a formal error since it is
perfectly conceivable that an ontology designer meant different things. It is more likely, how-
ever, that a design error is being made, since the similarity of the semantics used is not explic-
itly represented anywhere in the ontology, and perhaps not even in the documentation. Using
explicit structuring and renaming as motivated here is therefore crucial for proper, large-scale
ontology design. Some ontology frameworks have noted this in the past: for example, the Cyc

ontology (Lenat, 1995; Reed and Lenat, 2002)provides the structuring notion of the ‘mi-
crotheory’. This can only be applied within the Cyc knowledge system, however, whereas our
account is fully general and spans arbitrary logics—including the DL OWL standard for cur-
rent Semantic Web ontologies and OASIS.
Like import links, theorem links can also be attached with a signature morphism. In many
cases humans can see that two ontologies are basically the same but they only use different
concept names. To make this knowledge explicit we can again specify an appropriate renam-
ing (=signature morphism). Otherwise a machine has little chance to recognise such equali-
ties. Another structuring feature of CASL is hiding. With hiding, parts of the signature can be
declared to be invisible from the outside; e.g. if an ontology imports another one with hidden
symbols, then these symbols are not accessible for the importing ontology. This then covers a
similar range of possibilities to declaring interfaces for ontologies mentioned above; but,
again, is carried out within a much more general organisational framework that applies be-
yond the individual logics where interfaces have been considered.
For the purposes of building a fully general hyper-ontology, however, CASL still has one
limitation: it does not itself support heterogeneity in logics; i.e. all ontologies in a network
must be in CASL. To overcome this limitation, Mossakowski introduces Heterogeneous
CASL (HetCASL) (Mossakowski, 2004b), an extension that allows mixing specifications
written in different logics (using translations between the logics). At the level of structuring
constructs, this extends CASL only by adding constructs for choosing the logic and translat-
ing specifications among logics; otherwise all of the structuring notions applied above con-
tinue to apply. HetCASL is needed when combining specifications written in CASL with
specifications written in its sublanguages and extensions. HetCASL also allows the integra-
tion of logics that are completely different from the CASL logic.
This then is the final step we need in order to provide a specification language with the rich
structuring constructs necessary for modularizing ontologies and for providing the hyper-
ontology organisation envisaged for the OASIS application scenario. HetCASL allows the
formalization of ontologies in different logics and their connection in a graph-like structure
with edges of different meanings.
Fig. 14. Effect of change in a heterogeneous network of ontologies after modification of O3 in (a) to O3’ (b)

Fig. 14 illustrates this graph-like network of heterogeneous ontologies and how a change of
a single ontology affects the links between various other ontologies. Circles in different col-
ours in this figure depict ontologies in different logics, black arrows in the figure represent
import links that possibly translate signature and logics from the source to the target ontology.
Import links are used to extend ontologies—thereby they also always represent a relation that
holds by definition: the target ontology entails the source ontology (modulo signature and
logic translation). In contrast to definitional links, there are also theorem links—in the figure
depicted by coloured links. These links represent asserted relations that do not hold by defini-
tion, but need to be proved or refuted. Examples of these relations are that a target ontology is
a definitional or conservative extension of a source ontology, or that the source theory can be
interpreted in the target theory. These are extremely important notions for any subsequent no-
tion of advanced semantic versioning of ontologies, although this goes beyond the scope of
the current deliverable.
When a single node (i.e. an ontology) in the graph is modified (O3 in the figure above),
this may have several effects on some of the edges (directly or indirectly) connected to that
node. Because the modification of the ontology usually changes its meaning, several asserted
relations may become true or false. The HETS change management systems take care so as to
be able to verify as much as possible which of the asserted relations still hold. In many cases
the asserted relations need to be proven again or refuted.
4.3 Discussion and Outlook

We have specified the intended scope of the hyper-ontology framework and listed the cor-
responding entities subject to specification with respect to syntax and semantics. This com-
prises on the first level the languages admissible for ontologies and on the second level the
structuring constructs available for connecting ontologies into a heterogeneous network of
ontologies. We identified several types of links between ontologies and distinguished between
definitional (or import) links and asserting (or theorem) links. Furthermore, we considered
connections as a third type of link that cannot be just true or false, but which adds semantics
to the connected ontologies. We also presented a survey of the state-of-the art in ontology
modularization via connections. Finally, we sketched our approach to provide a general foun-
dation for the hyper-ontology, based on institution theory. This has provided the theoretical
underpinning for the design decisions followed in our instantiation of the hyper-ontology
framework within our Open Ontology Repository described in the next chapter.
For the purposes of OASIS, we have focused particularly on the application of this founda-
tion for providing more advanced connectivity within a hyper-ontology. Concerning the man-
agement of modularization, the development graph is taken as the central framework and this
is also based on institution theory (and entailment systems). We also briefly outlined the rich
structuring mechanism of the specification language CASL, which is the outcome of several
years of research of CoFI for non-ontology-related applications and, again, is based on institu-
tion theory. Finally, it should be mentioned that institution theory has recently been independ-
ently recognised by several researchers in the area of modular ontologies as a possible foun-
dational theory for networked ontologies, including Schorlemmer (Schorlemmer and
Kalfoglou, 2008) and Lucanu (Lucanu et al., 2006). It is therefore becoming clear that institu-

tion theory provides one of the strongest contenders to date for a solid formal foundation for
ontology interoperability and inter-connection in general.
Our current research is now accordingly centered on connections; in particular: (a) how on-
tology connections can be understood in the light of institution theory and (b) how they can be
supported within a new generation of ontology management tools including editors and re-
positories. On the theoretical side, we noted that connections are not currently first class citi-
zens in CASL. However, Kutz, Lücke, and Mossakowski (Kutz et al., 2008b) have already
shown how to simulate E-connections in HetCASL with appropriate ‘push-outs’, a technical
operation basic to category theory. Moreover, since Kutz reports in (Kutz et al., 2004) that E-
connections are essentially a generalization of distributed description logics (DDLs), we are
also confident to be able to show that such DDLs can be simulated in HetCASL also—thus
establishing formally that our account also includes other current approaches to ontological
modularity as summarised in section 4.2.3 above. Finally it remains to extend HetCASL so
that E-connections become first class citizens which can be used fully flexibly as a regular
structuring device within ontology specifications. These activities, which to a certain extent
are also being pursued in parallel for ontology work in general, will feed directly into exten-
sions undertaken within OASIS in activity A1.2.7 on framework extension and maintenance
strategies. Here the formal foundation in development graphs and the monitoring of change
that these support will be particularly valuable.
Parallel to this theoretical development, we are also pursuing the integration or interfacing
of Hets both with established ontology editors, particular Protégé, and the ontology repository
capability that we are developing for OASIS. These ongoing efforts and the results to date are
described in the chapters following.

5 The OASIS ontological toolbox: current state of development

In order for our COF and its specification of a hyper-ontology to deliver practical outcomes
and to facilitate the development of ontologies, we are developing a suite of tools that instan-
tiate our methodology and facilitate the emergence of the hyper ontology. In the same way
that our COF and hyper-ontology reuse theoretical components, we are reusing, adapting, and
generating new software tools that facilitate the development of ontologies and the
management of networks of ontologies.
As described and motivated at length in OASIS Deliverable D1.1.1, we are currently using
Protégé (Noy et al., 2000) as our ontology editor and decided to adopt BioPortal technology
(Noy, 2009; Rubin et al., 2008) for the core of our ontology repository. This latter choice was
motivated both by the relative degree of maturity of the BioPortal system and the many points
of similarity between the needs of distributed ontology development in the medical domain
and in OASIS that we pointed out at length in Chapter 2 above. We have extended and will
continue to extend both Protégé and our own instantiation of BioPortal, called the Ontology
Repository for Assistive Technologies (ORATE), in order to support the particular needs
and aims of OASIS. The Protégé extensions developed to date under the activities being re-
ported in this deliverable are: a Protégé interface to ontology repositories called OLS2OWL
(Garcia et al., 2009a), and a Protégé plug-in that supports the development of ontologies us-
ing the Concept Mapping (CMAP) paradigm called MAP2OWL. This latter plug-in was mo-
tivated by our need to work constantly and closely with domain experts whose experience de-
veloping ontologies is scant. This has been a particular result of the OASIS research and de-
velopment environment which we believe offers useful lessons for real-world practical ontol-
ogy development in general.
As our environment aims to deal increasingly with heterogeneous ontologies, we have also
adopted the heterogeneous tool set, the HETS system, as set out in D1.1.1 and explained in
detail in the previous chapter (cf. Section 5.1.3). In order for ontology engineers to make ef-
fective use of this system, our current research activities also involve a tight interfacing of
HETS with both Protégé and BioPortal so that, on the one hand, Protégé will be able to edit
heterogeneous ontologies and, on the other, ORATE will be able to accept ontologies inde-
pendently of the logic in which they were encoded—currently ORATE, as with BioPortal,
only accepts OWL files. This is work in progress and so is described further below in the
chapter on ongoing and future developments and, if successful, would represent a major result
for ontology engineering as a whole with applications ranging across the entire spectrum of
ontology applications (Section 7.2.2).
The present chapter describes those tools (i) which we have either developed or adapted on
the foundation of established technology and (ii) which have already been released for ontol-
ogy work by OASIS partners. We begin by reiterating briefly the basic building blocks that
our suite of tools builds upon; of these Protégé and BioPortal are already used, HETS will be
incorporated in the second half of the OASIS project as the framework is extended in the light
of experiences gained with practical application building. Following this review, we then pre-
sent the plug-ins OLS2OWL and MAP2OWL, commenting in particular on our experiences
with promoting CMAPS for ontology development within the OASIS transport domain. Fi-

nally, we provide a detailed overview of our ORATE open ontology repository and its current
contents, focusing on this as a concrete instantiation of the hyper-ontology framework show-
ing the common ontological framework in action.
In summary, our Ontology Repository for Assistive Technologies (ORATE) is based on
Protégé, a standalone editor, Web Protégé, supporting collaboration when building ontologies,
and BioPortal technology, providing an ontology repository. Our software infrastructure
therefore already goes a considerable distance towards supporting the Ontolog vision for a
repository and facilitates the automatic comparison of ontology and ontology elements (e.g.
classes, properties, etc) for the purposes of reusability.
5.1 Basic Building Blocks for the OASIS ontology toolbox

5.1.1 The Protégé Ontology Editing Environment
As described in previous deliverables (particularly the state of the art review of D1.1.1), we
make use of the international de facto standard system for ontology editing, Stanford’s Pro-
tégé (http://protege.stanford.edu/), with whose developers we are also cooperating. Several of
the components of the OASIS toolbox for ontology management are constructed as plug-ins
for Protégé; this usage will continue over the course of the OASIS project as Protégé seems
set to continue its dominant role in the area. Providing tools in the form of Protégé plug-ins
automatically guarantees a maximally broad potential user-basis among ontology developers
unrivalled by any other system.
5.1.2 The BioPortal system
The Ontology Repository for Assistive Technologies (ORATE,

http://ontologies.informatik.uni-bremen.de/) is built upon BioPortal (Rubin et al., 2008) tech-
nology. BioPortal provides facilities for browsing, visualizing, and reusing ontologies as well
as a basic repository for ontology storage and retrieval. Within OASIS, we are developing ad-
ditions within the BioPortal framework that move the system further towards the OASIS pro-
ject goals of modularity and re-usability. To the best of our knowledge, ORATE is the first
application of BioPortal technology in a non-biomedical domain and the first independent in-
stantiation of the system in Europe.
5.1.3 The HETS system
We are also, as summarized in deliverable D1.1.1 and explained in detail in the previous
chapter, building upon HETS, the heterogeneous tool set introduced in Section 4.2.5.3 above.
HETS is a parsing, static analysis and proof management tool combining various such tools
for individual specification languages, thus providing a powerful framework for heterogene-
ous multi-logic specification. HETS is based on a graph of logics and languages (formalized
as so-called institutions), their tools, and their translations (Fig. 15). This provides a clean se-
mantics of heterogeneous specifications, as well as a corresponding proof calculus. For proof
management, the calculus of development graphs (known from other large-scale proof man-
agement systems) has been adapted to heterogeneous specification as described in the previ-

ous chapter. This system provides the foundation for the advanced ontology interoperability
capabilities presupposed by our view of the OASIS hyper-ontology. Full integration using
HETS is planned as part of the extensions required for the framework update and maintenance
strategy extensions of activity A1.2.7 over the remaining duration of the OASIS project as
described above as well as in the supportive activities provided for continuous services inte-
gration for OASIS subprojects SP2 and SP3.
Fig. 15. HETS architecture
HETS supports the algebraic specification language CASL (Common Algebraic Specifica-
tion Language: (Mossakowski et al., 2008)), which we now apply to ontology development as
motivated in the previous chapter. CASL is a first-order logic that, on the one hand, is similar
in capabilities to representations currently under development for ontology work such as
Common Logic (Common Logic Working Group, 2003) but, on the other hand, is better
suited to structured ontology development due to its embedding within HETS. CASL together
with HETS provide both a specification language and tools that strongly support structured
specifications. Its use of HETS provides a natural embedding within heterogeneous specifica-
tions involving logics of differing expressiveness. Variants equivalent to Description Logic
and OWL have been defined. Due to this flexibility, CASL plays a central role for the Com-
mon Ontological Framework within OASIS. In particular, to facilitate heterogeneity, HETS
supports the HetCASL heterogeneous variant of CASL (Mossakowski, 2004a), which, as de-
scribed in the previous chapter, appears to offer an ideal foundation for hyper-ontologies in
general. The integration and application possibilities for HETS/CASL are described in more
detail in Chapter 7.

5.2 OLS2OWL. A repository access facility

Currently, when ontology engineers need to construct an ontology for their own application
needs, they often search repositories, one at a time, and retrieve those ontologies they find in-
teresting on a one-by-one basis. Neither repositories nor ontology editors then facilitate the
extraction of segments/slices of ontologies as might be required for a particular application
need. For instance, after having searched over the current ontology
collections provided by WATSON and SWOOGLE, two independent operations, an ontology
engineer has to download those ontologies he/she has found and, once stored locally, manipu-
late the selected ontologies with an ontology editor. This manipulation may require slicing the
ontologies, extracting only those portions he or she would like to reuse, and integrating them
into a new ontology. In a nutshell, available tooling support for managing large numbers of
ontologies in the engineering process is very limited, particularly with regard to maximizing
reuse of existing definitions and semantic links between related conceptual entities. This is
problematic for us here because the Common Ontological Framework foresees precisely this
operation of selecting and combining portions of pre-existing ontologies as crucial. To instan-
tiate the COF in practice, therefore, we need far better tool support for this kind of work.
OLS2OWL is a plug-in for Protégé 4.0 that allows users to define local and external re-
positories and to navigate through ontologies; it also facilitates the execution of queries across
ontology repositories. Ideally, a tool of this kind should be independent of the particular re-
positories that happen to be in existence at any particular time. Therefore, in order to increase
the set of repositories known by OLS2OWL, a web service has been developed that can be
extended straightforwardly to enable OLS2OWL to access new repositories on demand. The
OLS2OWL web service standardises access to heterogeneous APIs; the service queries, re-
trieves and sends results back to the client.
In order to use OLS2OWL, ontology developers select those repositories they wish to in-
clude in a query; users are also able to specify if they want to limit the query to instances,
properties, classes or a combination of these OWL constructs. Results include a description of
the ontologies based on available metadata and on-the-fly illustrative statistics such as number
of classes, properties, and instances. Fig. 16 illustrates the architecture of the plug-in as well
as some of the functionalities available. OLS2OWL also delivers a direct manipulation inter-
face over a visualization layer; ontologies are displayed as graphs by means of GrOWL, a fur-
ther OASIS Protégé plug-in developed as part of the activities of WP1.3 on user interfaces
and tool support for ontology work (http://www.uvm.edu/~skrivov/growl/).
OLS2OWL makes it straightforward for users to compare classes by visually inspecting
their surroundings. A comparative ‘side-by-side’ view, as seen in Fig. 17, is provided. Finally,
a slicing operation allows users to select portions of active ontologies and “import” (facili-
tated by a drag and drop operation) them into a new blank ontology. This facilitates reusing
both entire ontologies as well as sections of them.

Fig. 16. Plug-in architecture and basic functionalities
The pizza ontology

(http://www.co-
ode.org/ontologies/pizza/
2007/02/12/pizza.owl)
and the pet ontology
(http://www.atl.lmco.c
om/projects/ontology/o
ntolo-
gies/people+pets/peopl
e+petsB.owl)
Fig. 17. ‘Side-by-side’ comparison of distinct ontologies
Ontology Lookup Services (OLS) are not in themselves new. For instance the European
Bioinformatics Institute (EBI) OLS (Cote et al., 2006) facilitates search operations against the
EBI Open Biomedical Ontologies (OBO) repository. The Watson Plug-in (d’Aquin and
Suarez-Figueroa) also facilitates similar operations against the Watson repository. Although

these examples allow users to query a specific repository, they do not facilitate querying sev-
eral repositories in one operation, nor do they support in any special way successive manipu-
lation operations. Moreover, these tools do not facilitate reuse, nor do they provide mecha-
nisms for dealing with more than one ontology. They were not, therefore, as they stand, ap-
propriate tools for realising the OASIS Common Ontological Framework view of ontology
work.
The OLS2OWL approach does, however, inherit the limitations of the available APIs: the
more expressive the API, the more facilities could be provided by OLS2OWL. Repositories
indexing ontologies, not storing them, also pose a significant limitation to services such as
ours; it often happens that ontologies are no longer available or, as indexes are not frequently
updated, false positives may be presented to users in the resulting set. As we envision that
several repositories of ontologies will be established, interoperability is an important aspect
that needs to be preserved. This can be facilitated by having core metadata that facilitate the
development of specialized descriptors while maintaining the coherence of the core—thus
enabling interoperability. As better metadata become available (and for our contribution to
this, see Chapter 6 below), OLS2OWL will facilitate the execution of richer semantic queries
against existing repositories; in the meantime we are adopting the minimal common metadata
denominator—i.e., metadata shared by all repositories. OLS2OWL therefore aims to bridge
the gap between ontology repositories and ontology editors —specifically Protégé.
5.3 MAP2OWL, a Concept Mapping facility for Protégé

Ontology development is central for the OASIS vision. However, as illustrated above, prob-
lems with ontology development arise at many points. One particular bottleneck, well known
across all attempts to employ ontologies within real application situations, is where knowl-
edge must be elicited from, and represented by, domain experts. Such experts are not always
aware of the ontology development process, nor are they aware of the syntactical structures of
the languages commonly used to represent knowledge. Moreover, development tools such as
Protégé have been conceived for engineers, not for domain experts. The domain analysis and
knowledge acquisition phases of the ontology development methodology can therefore
quickly become a major obstacle to progress. It is necessary here to pay particular attention to
the establishment of formal means of communication (i.e. in sharing knowledge) between
domain experts and ontology engineers.
Knowledge elicitation is the stage in ontology construction in which the person managing
the development of the ontology gathers, in the form of concepts and relationships between
concepts, what the domain expert understands to exist in that domain. Particularly complex
here is the task of gathering relationships across ontologies and the formal logic behind these
relationships so that the resulting network of ontologies is able to support the reasoning re-
quired. In contrast, conceptual maps (CMAPS) have been demonstrated to be an effective
means of representing and communicating knowledge (Canas et al., 1999; Cañas et al., 2004)
in a wide variety of domains. They have a simple semantics that appears to be an intuitive
form by which domain experts can convey their domain understanding. To support the re-
quired knowledge elicitation phases of our ontology development methodology more effec-
tively, we therefore decided to employ concept maps to reduce the gap between domain ex-

perts and formal ontological specification, exploiting their perceived simplicity in order to
perform the informal modelling stage of building an ontology. This had not been carried out
previously because the gap between CMAPs and OWL structures was considered a problem-
atic issue leading to translations that were prone to error (Garcia et al., 2006). Formally,
CMAPs are graphs consisting of nodes representing concepts, connected by arcs representing
the relationships between those nodes (Canas et al., 1999). Nodes are labelled with text de-
scribing the concept that they represent, and the arcs are labelled (sometimes only implicitly)
with a relationship type. Fig. 18 illustrates a typical CMAP. The graphical representations of
the CMAPs used here and below were originally produced with CMAPs tools available at
http://cmap.ihmc.us/.
Fig. 18. An example of a conceptual map
Currently the CMAP syntax is independent of ontology formalisms such as OWL and this
opens up the possibility of divergent specifications. The relationship between CMAPs and
ontologies has, however, been investigated previously by Hayes et al (Hayes et al., 2005).
They propose a Collaborative Ontology development Environment (COE) which uses concept
maps to display, edit and compose OWL. Central to their approach is the use of CMAPs in
their native XML-based format, and the importance granted to effective support for the col-
laboration process employing tools available under the CMAP-Tools package
(http://cmap.ihmc.us/). The availability of supporting tools such as these for facilitating visu-
alization, query formulation, and consistency checking by means of reasoners is extremely
important when developing ontologies.
Within COE support is provided by an integrated development environment built on top of
an open plug-in based architecture similar to the one provided by Protégé. We have built on
these prior experiences, taking them further in our new Protégé-based tool MAP2OWL. This
draws on Garcia’s study of CMAP tools in both centralised and decentralised settings (Garcia,
2007a). MAP2OWL allows the representation of CMAPs in the OWL formalism. More spe-

cifically, it supports knowledge representation by domain experts with no previous exposure

to ontologies. CMAPs have subsequently proved themselves particularly useful for OASIS
ontology development both in the sharing and capturing of activities and in the formalization
of use cases.
A significant difference between a CMAP and an OWL ontology is therefore the presence
of concepts and relationships versus classes and properties—both data type and object proper-
ties. CMAP concepts can be seen as non-formalized classes; by the same token, relationships
can be considered non-formalized properties. The transition from a concept into a class is de-
fined by the knowledge engineer; usually during the knowledge elicitation phase. As concepts
are being gathered, higher levels of abstractions are required; consequently classes can be de-
fined. A similar process occurs when defining properties. Initially, simple relationships are
elicited. Then, as these are being formalized, more accurately abstracted and defined proper-
ties emerge.
The MAP2OWL tool also handles communication with the Protégé OWL plug-in. This al-
lows the direct manipulation of created OWL file via CMAPs: that is, users not only “draw”
their ontologies, but are also able to carry out operations such as defining domain and range
without interacting with the OWL syntax or the OWL plug-in. Fig. 19 illustrates how
MAP2OWL facilitates this development of OWL ontologies graphically.
Immediate access to
other plug-ins
Users can represent the

Users can set attributes on ontologies as concept
properties and classes maps
Fig. 19. MAP2OWL
These graphical manipulations supporting the ontology development process provide sev-
eral advantages; for instance: (i) novices can learn basic functionality quickly, usually through
a demonstration by a more experienced user, (ii) experts can work extremely rapidly to carry

out a wide range of tasks, even defining new functions and features, (iii) knowledgeable in-
termittent users can retain operational concepts, (iv) error messages are rarely needed, (v) us-
ers can see immediately if their actions are furthering their goals—if not, they can simply
change the direction of their activity, (vi) users have reduced anxiety because the system is
comprehensible and because actions are easily reversible.
5.3.1 Lessons learnt from using CMAPS
The COF methodology as developed in Chapter 3 strongly emphasizes: (i) capturing knowl-
edge, (ii) sharing knowledge, (iii) supporting needs with well-structured use cases, and (iv)
supporting collaboration in distributed (decentralized) environments. For ease of reference,
we show the main development steps and corresponding milestones that this methodology
defines in Fig. 20; as we saw above, all of these stages are anchored within the OASIS COF
methodology. In this subsection we show how the development of ontologies conformant
with the methodology and the steps defined are supported by MAP2OWL using CMAPs.
Fig. 20. Steps and milestones
Step 1: The first step involves addressing straightforward questions such as: what is the on-
tology going to be used for? How is the ontology ultimately going to be used by the software
implementation? What do we want the ontology to be aware of, and what is the scope of the
knowledge we want to have in the ontology?

Step 2: When identifying reusable ontologies, it is important to focus on what any particular
concept is used for, how it impacts on and relates to other concepts, how it is embedded
within the process to which it is relevant, and how domain experts understand it. It is not im-
portant to identify exact linguistic matches. By the recyclability of different ontologies, we do
not imply that we can indicate which other ontology should be used in a particular area or
problem; instead, we mean conceptually how and when one can extrapolate from one context
to another. Extrapolating from one context to another largely depends on the agreement of the
community and specific conditions of the contexts involved. Indicating where another ontol-
ogy should be used to harmonize the representation at hand is a different issue that we refer to
as reusability.
Step 3: Domain analysis and knowledge acquisition are processes by which the information
used in a particular domain is identified, captured and organized for the purpose of making it
available in an ontology. As we set out in detail in section 3.2 above, there are a number of
criteria that need to be applied during knowledge acquisition—in particular insuring the accu-
racy of terms, coherence and extensibility. The appeal to CMAPs was beneficial for all of
these criteria. The improved intelligibility of the communicated knowledge helped raise the
accuracy of the initial term definitions. Moreover, as CMAPs were being enriched it was eas-
ier to ensure the coherence of the story they were capturing: domain experts were explicitly
asked to use the CMAPs as a means to tell a story and so consistency within the narration was
kept in view throughout the process. Finally, extensibility was also supported in that the re-
quired stages of aggregation were made explicit. The CMAPs being developed were con-
stantly gaining information which was always part of a bigger narration. Extending the con-
ceptual model was then not only about adding more details to the existing conceptual models,
nor was it just about generating new CMAPs—it was also about grouping concepts into
higher-level abstractions and validating these with domain experts. Scaling these models in-
volved the participation of both domain experts and the knowledge engineer and was carried
out by direct interview as described in section 3.3.
Step 4: Iterative building of informal ontology models with the CMAPs helped to expand our
glossary of terms, relations, their definition or meaning, and additional information such as
examples to clarify the meaning where appropriate. Different models were built and validated
with the domain experts.
Step 5: Formalization of the ontology then moved the CMAP specification towards OWL
definitions by adding further constrains on classes. As usual, this step gradually moves ontol-
ogy development to standard ontology tools such as ontology editors.
Step 6: Since, as described above, there is no unified framework to evaluate ontologies, we
focus on evaluation metrics that rate ontologies according to the application needs they are to
serve. The CMAP representation can help assess whether information necessary is included or
not, but the final evaluation must come from ontology deployment and evaluation of the per-
formance of the applications served.
5.3.2 CMAPS supporting Knowledge Elicitation

The development process set out above was applied concretely during the knowledge elicita-
tion phase within the development of the OASIS transport related ontologies. The goal of this
effort was to gather a baseline ontology for this domain. Fig. 21 illustrates where within the
overall methodological process, this effort was situated.
Fig. 21. Anchoring of baseline ontology formation within the OASIS methodology
The goal determines the complexity of the ontology development process. Creating an on-
tology intended only to provide a basic understanding of a domain may require less effort than
creating one intended to support formal logical arguments and proofs in a domain. We must
therefore answer at the outset questions such as: Why are we building this ontology? What do
we want to use it for? How is it going to be used by the software layer? These steps are set out
for the present use case in subsections 5.3.2.1—5.3.2.3 in detail.
5.3.2.1 Identification of purpose, scope, competency questions and scenarios
Only some of the answers gathered during this process are presented below; they are indica-
tive of the development process and its interactive and evolutionary nature. The domain ex-
pert was given questions such as the following; she also had to document the CMAPs pro-
duced by including the standard information required by the CMAP software tool.
! What sort of process is the ontology supporting? Answer: Public Transport (PT) Route
Planning.
! How is the ontology going to be used? Answer: “presumably to obtain additional con-
tent from other web services”.
! What is the ontology meant to describe/classify? Answer: the processes and content re-
quired for elderly-friendly PT routing

! What software is using the ontology? Answer: “At least Route Planning Systems”.
5.3.2.2 Identification of reusable and recyclable ontologies
In order to guide the elicitation exercise, the knowledge engineer identified some reusable
controlled vocabularies. OLS2OWL was also used here in order to identify existing controlled
vocabularies. This made it possible to better assist the domain expert and also, at the same
time, to further enrich the growing CMAPs.
5.3.2.3 Domain analysis and knowledge acquisition
As the CMAPS were being produced, the domain expert asked for further refinements. For
instance, the importance of architecturally-induced barriers was evident for the domain expert,
but she did not understand how to relate these classifiers with others such as those related to
Points of Interest and elderly-friendly-features. Initially the domain expert provided one
CMAP, but as the elicitation moved forward, the need for modularizing and thus generating
more CMAPS became obvious. From the original CMAP provided by the domain expert,
three sub-domain ontologies were identified and subsequently represented in OWL files—see
Fig. 22. Relationships across ontologies were also identified during this methodology step.
Fig. 22. Ontologies identified after an initial Knowledge Elicitation exercise
By gathering use cases in the form of CMAPs, we could identify classes, subclasses and
instances. Moving from instances to classes was an iterative process in which domain experts

were representing their knowledge by providing a narration full of instances, specific proper-
ties, and relationships. The knowledge engineer analyzed all the material. By doing so, differ-
ent levels of abstractions that could be used in order to group those instances were identified;
ultimately domain experts validated this analysis by examining the resulting CMAPs.
In the future, we will improve Map2OWL so that relationships across ontologies can be
better defined: here a more accurate semantics is needed so that federated reasoning can be
supported. Providing these relationships as formal mappings is also on our agenda, building
on the foundations for such relations set out within the hyper-ontology specification. In addi-
tion, the relation between CMAP relations and the important notion of ontology design pat-
terns from ontology development will be investigated. Ontology design patterns (Gangemi,
2005) suggest particularly useful and simple reusable patterns that can be employed when de-
signing an ontology: they resemble small packages of generic content or templates for rela-
tionships. Making ontology design patterns available to CMAP developers as explicit candi-
dates for populating a CMAP could well accelerate ontology development still further: here
practical investigation and evaluation is required.
5.4 ORATE: an Open Ontology Repository

The Ontology Repository for Assistive Technologies (ORATE) is an open ontology reposi-
tory and web portal based on BioPortal (Noy et al., 2009). ORATE users can browse and
search ontologies, update the ontologies that they authored by uploading new versions, com-
ment on any ontology in the library, evaluate it, describe their experience in using the ontol-
ogy, or make suggestions to ontology developers. As mentioned above, ORATE is the first
application of BioPortal technology in a non-biomedical domain. Any member of the OASIS
community may register themselves on ORATE at:
http://ontologies.informatik.uni-bremen.de/
and then use its full functionality.
ORATE can be seen from two complementary perspectives. First, it is one of the primary
OASIS deliverables that support ontology development and use. Second, it represents a con-
crete instantiation of the hyper-ontology framework. Within ORATE we can see all of the
considerations set out in the Common Ontology Framework expressed within a running sys-
tem. Although not complete or finalised with the current state of the work, it nevertheless
provides the working backbone for OASIS ontology work, including particularly the support
required for modular and interlinked ontologies. ORATE is described from the perspective of
its function as an ontology support tool together with corresponding use cases for ontology
developers in OASIS deliverable D1.3.1. Here, we concentrate on its role as an instantiation
of a hyper-ontology and the various development stages motivated by the COF methodologi-
cal component. The views presented here are accordingly more those that are appropriate for
an ontology engineer rather than an application builder or a service provider. The correspond-
ing ontology support tools for these latter uses fall more under the activities of WP1.3; for
OASIS such access will be explored from within the OASIS Wiki environment, which will
function as a front-end to ORATE functioning as a hyper-ontology repository in the back-
ground.

5.4.1 ORATE Welcome Page
The above URL leads to the ORATE Welcome page shown in Fig. 23. This already provides
an overview of the latest content uploaded into ORATE's and allows visitors to search ontolo-
gies or to look for individual concepts within the entire set of ontologies. This therefore di-
rectly supports from the outset an orientation towards re-use and respect for previously exist-
ing modules. The overview and listing of latest operations performed on the ontologies main-
tained also anchors the user within the ontology development communities active in ORATE-
related areas.
Fig. 23. Welcome page of ORATE
There are four tabs on top of the page: Browse, Search, Projects, and All Mappings. In the
following we will describe the functionality of these tabs, although in order to reflect more
transparently their role in supporting the COF methodology, we adopt a different order. We
start with project management (Projects tab), followed by subsections on how to publish and
browse ontologies, add comments and create mappings across ontologies (Browse tab), how
to search for concepts in ontologies (Search tab), and finally how to browse mappings (All
Mappings tab). The mappings are the concrete instantiation of the links within the hyper-
ontology. At present only simple links are supported; this will be progressively extended ac-
cording to application requirements during framework extension over the third year of the
OASIS project.
5.4.2 Project Management

When submitting an ontology to ORATE the first time, the developer is requested to either
add a new project or to associate the ontology to an existing project. Both tasks can be carried
out in the Project tab. As can be seen in the figure below, the "Add Project" option allows the
user to create a new project. Below this button all existing projects are listed. A click on "Edit
Project" allows the user to modify all information about the corresponding project and in par-
ticular to assign ontologies from the list of all unassigned ontologies to this project.
The "Add Project" (Fig. 24) and the "Edit Project" (Fig. 25) links lead to basically the
same form—the only difference being that the edit form is already filled with content that can
be modified. All ontologies uploaded on ORATE are listed below the text fields. Here the
user can select ontologies that should be assigned to this project.
Fig. 24. Projects tab: displays a list of ontology development projects

Fig. 25. Editing project allows the user to modify project information and to assign ontologies to the
project
5.4.3 Publishing Ontologies
Any ontology that is relevant to the OASIS community can be published in ORATE. This is a
convenient way to announce a web presence for an ontology so that other community
members can find and use it. As clarified in the conclusion to the deliverable in Chapter 8
below, there is no requirement that any such ontology conforms to OASIS standards or has
been produced using the OASIS methodology. At present, ORATE serves as a genuinely
open Open Ontology Repository in the sense defined by the Ontolog virtual community
working group. Nevertheless, when submitting an ontology to ORATE, the user must provide
essential metadata about the ontology such as its name and acronym, the domain that the
ontology covers, keywords, links to additional information, and provenance information,
including who developed the ontology, version details, dates of the release, and so on. Fig. 26
below shows the relevant submission form. In the chapter following we characterise in more
detail how we see metadata for ontologies evolving in the future to provide more

sophisticated repository-based control of ontology use. After the ontology author submits an
ontology, ORATE parses and indexes it in order to make it available for searching and
browsing.
Fig. 26. Submission form for a new ontology to be uploaded.
5.4.4 Browsing Ontologies
The ontology engineer can browse ontologies via the Browser tab (Fig. 27). This provides (i)
a link to submit new ontologies and (ii) select boxes to filter (by category, group, or text) the
list of ontologies hosted on ORATE displayed on the same page. Any ORATE user can also
subscribe to an RSS feed of changes to a specific ontology in order to receive notifications of
any user-contributed content relevant to that ontology, such as comments or mappings.

Fig. 27. Browse tab: displays a list of uploaded ontologies
Each row in the list of ontologies presents the most important of their meta data. The on-
tology name links to a summary page of that ontology. A click on an "Explore" link pops up
the ontology "visualization view" (depicted in the Fig. 28). In the visualization view the user
can navigate through the is-a hierarchy in the tree representation or in the graph representa-
tion. Context dependent menus enable quick access to more detailed information on any on-
tology element under mouse focus. These details can be also viewed in the Details tab in the
righthand pane. Notes can be attached to each concept or just viewed in the Notes tab. Finally;
the Mapping tab in this pane allows the user to associate the current concept with any concept
of a different ontology. Notes can also be attached to these mappings.

Fig. 28. Exploring an ontology in the visualization view
A click on the ontology name (either in the list of all ontologies or in the visualisation view
of a single ontology) leads to an ontology overview page (shown in the Fig. 29) that displays
all meta-data and provides access to previous versions of that ontology, as well as links to all
notes and mappings attached to it.
Fig. 29. Exploring an ontology in the visualization view.
5.4.5 Searching Ontologies
In the Search Tab, see Fig. 30, the user can search for ontologies containing specified ele-
ment names. Search results can be filtered by categories, given filter text, or by manually in-
cluding or excluding ontologies.

Fig. 30. Search tab with displayed results
5.4.6 Browsing Concept Mappings between Ontologies
We mentioned above that mappings between concepts of different ontologies can be created
in the visualization view of the Browser tab. The All Mappings tab is the place where these
mappings can be examined. For this, the user first has to choose an ontology with concepts of
interest participating in a mapping. The select box shows a list of ontologies each annotated
with the number of mappings from or to its concepts. Once an ontology is selected, two tables
are presented: one for the target and one for the source ontologies together with the number of
mappings. In the screenshot of Fig. 31, for instance, the ontology "Trip" was selected. It
contains seven concepts involved in mappings. The first table below says that one concept
from the "Trip" ontology is mapped to one concept of the "Tourism and Leisure" ontology,
and four concepts from "Trip" to four concepts of the "Transportation" ontology, etc. The
second table lists mappings in the opposite direction. In the current example, all of the
mappings are bidirectional and so the source-target and target-source lists are identical.

Fig. 31. Mapping tab: displays a list of concept mappings from a source to a target ontology.
In order to see which concepts of the initially selected ontology ("Trip" in the screenshot
above) are mapped to which concept in the other ontology, the user has to click on this target
(or source) ontology. Then all concept mappings are listed. The screenshot below, Fig. 32, for
instance, is the result of a click on the "Transportation" link. It shows that the concepts bus,
sea_transport, mean_of_transport [sic], and train from the Trip ontology are mapped respec-
tively to the concepts Bus, Ship, Vehicle, and Train from the Transportation ontology.
Fig. 32. All concept mappings from the Trip to Transportation ontology.

Finally these mappings can be exported as RDF-triples and explored with other OASIS
tools for employing mappings. The import to the Content Connection Module of OASIS
WP1.3 will be of particular interest for the next round of development.
5.5 Current contents of the ORATE repository

This section gives an overview of the ontologies currently uploaded on the ORATE repository
(http://ontologies.informatik.uni-bremen.de/ontologies). The first subsection is about ontolo-
gies developed by OASIS partners, whereas the second subsection is about ontologies devel-
oped by third parties. The latter have been uploaded to the repository because their content
will be or is already being reused by OASIS partners for their own ontologies.
5.5.1 Ontologies developed by OASIS partners
OASIS partners have so far developed ontologies within the following work packages:
1. WP1.3 Content Connector and Ontology Management Tools and Interfaces
2. WP2.2 Nutritional Advisor
3. WP2.6 Health Monitoring
4. WP2.7 Environmental Control
The following subsections briefly summarize the current ontologies produced from these
work packages that have been uploaded as ORATE content.
5.5.1.1 Ontologies from WP1.3 "Content Connector and Ontology Management Tools and
Interfaces"
In this work package it was proposed that ontologies from the ASK-IT project (Ambient Intel-
ligence System of Agents for Knowledge-based and Integrated Services for Mobility Impaired
Users http://www.ask-it.org) be incorporated into the design and implementation of the
Common Ontological Framework (COF) of the OASIS project. For the development of these
ontologies in ASK-IT, real-life content was drawn from various heterogeneous databases and
test data were used as the baseline source for the implementation of the ASK-IT ontology
model. The latter was used for semantic web-based search and retrieval of the ASK-IT sup-
ported services. After collecting all relevant content for the project, the models derived from
content aggregation provided the necessary input for the ASK-IT data delivery format to be
shaped. The concepts belonging to this format were represented in a semantically unified
manner by exploiting semantic information of the content descriptors obtained from the XML
schemes. This included the definition of the various logical relationships between the different
concepts and domains involved in content models. By semantically annotating content mod-
els, new knowledge was incorporated in the form of the ASK-IT ontologies encoded in OWL
format.
In order to meet the more stringent formal requirements of the OASIS COF and thus better
to support reuse and cross-domain reasoning, progressive refinement/improvement of these
ontologies is under way following the methodological stages defined within the OASIS COF

(Kehagias et al., 2008). So far this has resulted in the following improved ontology sub-
modules being maintained within ORATE as components of the growing hyper-ontology:
! General Purpose Ontology: ASK-IT OWL General Purpose Ontology.
! Personal Support Services: ASK-IT OWL Ontology for 1.4 - Personal Support
Services.
! Social Relations: ASK-IT OWL Ontology for 1.6 - Social Relations and Community
Building Services.
! Tourism and Leisure: ASK-IT OWL Ontology for 1.3 - Touristic and Leisure
Related.
! Transportation: ASK-IT OWL Ontology for 1.2 - Transportation
! Work Business Education: ASK-IT OWL Ontology for 1.5 - Work, Business and
Education Support Content
The main feature of these ontologies is that they were developed to cover for the first time
the specific needs of various user groups defined according to specified impairment categories
(e.g., mobility impaired, cognitive impaired, psychological impaired, etc). They define the
interrelationships that may logically hold between the ASK-IT user groups and various user
information needs of different content types. Within these ontologies all user information
needs are annotated in a common way to enable on request straightforward search and re-
trieval of information covering specific user needs. This is achieved by providing a common
mechanism for representing content. Since the ontologies aim to provide the appropriate
means to enable mappings between the supported mobility services and user requests, at pre-
sent the available services are semantically described inside the corresponding ontologies.
This is currently being investigated further in order to explore the possibilities for finer-
grained ontology definitions and opportunities for modularisation.
In addition, a growing ontology is being provided for the services. This ontology is used
directly by the Content Connection Module for classifying new services that are to be linked
with the OASIS platform.
5.5.1.2 Ontologies from WP2.2 "Nutritional Advisor"
According to activity A2.2.1 an ontology for the nutritional profile for elderly has to be de-
fined. This profile will be used in the nutritional plan builder (activity A2.2.2) that creates in-
dividual nutritional plans adjusted to user profile and depending on a set of variables that
should be collected and measured on a daily basis, monitoring physical activity, food inges-
tion and health status.
In activity A2.2.3 (Nutritional empowerment and assessment) a system will be built that
will also acquire data from the health monitoring system of WP2.6 (vital parameters, such as
blood pressure) and the activity coach of WP2.3 (activity data), in order also to provide inter-
rogated feedback about effects of the user’s habits on his/her health status. Hence, there will
be a connection to the ontologies developed in WP2.3 and WP2.6.
The main activities performed by the user concerning their nutritional state are shopping
and cooking. In activity A2.2.4 (Shopping & cooking assistant) an assistant that is being de-

veloped will suggest to the user, on a daily or weekly basis, what and when to eat, what sup-
plies they need to purchase and how to cook it so as to achieve optimal alignment with the
plan builder. For all these activities corresponding ontologies are in continuous development.
The current state of ontologies in this work package is as follows:
! Diet: An ontology to hold prescribed diets and habits: Nutritional Plans and
Recommendations
! Menu: An ontology for managing nutritional menus prescribed by a nutritionist.
! Menu repository: An ontology to hold menu instances and reuse them.
! Questionnaire: An ontology for managing questionnaires, questions and answers.
! Questionnaire repository: An ontology to hold questionnaires, questions and
answers.
! Filled questionnaire: An ontology to hold the responses from the user to a
questionnaire.
! Food Inventory List: An ontology for managing a food inventory.
! Storage place: An ontology describing storage places to be used by the food
inventory.
! Shopping list: An ontology for managing a shopping list.
In addition, the following ontologies have been brought into the OASIS project from the
PIPS project (http://www.pips.eu.org/), but have been undergone the OASIS ontology review
process, being refined accordingly:
! PIPSClinicalRecord: This ontology contains a categorisation of the clinical
conditions that have relevance to our case study, as well as allergies and food
intolerances.
! PIPSFood: In this ontology food is categorised according to EUROCODE2 standard
classification1. The main source for its construction is the PIPS Food DB.
! PIPSMenu: This ontology describes menus and their components
! PIPSMenuPlanner: contains the concepts that are necessary for planning a daily
menu.
! PIPSNutrition: This ontology contains the description of the conceptualisations of the
nutritional domains that are necessary to characterise food in terms of their
macronutrients. It also defines the concept of food pyramid, which is a convenient way
nutritionists use to represent food and put it in relation with serving recommendations.
Each layer of the pyramid corresponds to a serving recommendation, and contains a
set of nutritionally similar foods.
! PIPSPerson: This ontology contains the concept from the PIPS Virtual Ego that are
relevant for OASIS case studies, such as a person’s age, gender, special conditions
(hypertension, breast feeding, and so on) as well as a person’s food preferences

! PIPSRecipe: This ontology contains the entities in the recipe domain that are relevant
with respect to PIPS. Recipes are described in terms of ingredients, courses, meals for
which they are suitable.
5.5.1.3 Ontologies from WP2.6 "Health Monitoring"
Health well-being implies the maintenance of appropriate health conditions. This implies the
need to watch out for current health conditions and their variations, as well as health events
suffered over time.
Activity A2.6.1 (Health profile definition & personalization) provides a study of the main
health conditions that should be monitored to keep an elderly person in a healthy life style.
The study presents a three-dimensional health monitoring matrix that relates health conditions
with biomedical and activity based measurable parameters and rates the urgency of response
to maintain the user’s health status. Based on this study and monitoring matrix, a Health
monitoring ontology has been developed. The current version of this ontology is to be found
in ORATE under the name "Health Monitoring". The ontology is composed of different types
of general concepts (health conditions, monitoring possibilities, final health decisions), which
are being described by means of specific descriptive properties/attributes. Finally, the rela-
tions between these objects are defined to allow generating health recommendations or warn-
ings/alerts that can be used to recommend appropriate actions.
5.5.1.4 Ontologies from WP2.7 "Environmental Control"
In activity A2.7.2 ontologies for indoor user localization are being developed. The DOLCE
ontology (see third party ontologies below) has served as the starting point for various general
concepts concerning actors and their locations following the structured scheme for domotic
ontologies proposed by (Hois et al., 2009). Domain specific concepts and relations are de-
fined here to describe buildings, objects (furniture and sensors) inside buildings, etc. Cur-
rently six ontologies related to indoor localization have been uploaded:
! Building architecture: Architecture-related entities of buildings. The entities are
functionally defined. Topological (qualitative) RCC-8 relations define their spatial
relations.
! Building construction: Building construction entities and their metrical data; We
consider only higher elements like RasterElements and a set of raster elements
! Indoor localization: An ontology of indoor objects and areas and their spatial
properties (deprecated).
! User InDoor Localization: Indoor Localization for the OASIS project.
! Localization Address: An ontology for absolute, relative, and symbolic location
addresses and their properties.
! Place ontology: Ontology of an OASIS place. Models buildings with several floors
and apartments as well as the containment and connectivity relations of the different
entities.
In activity A2.7.3 a further ontology for domotics has been developed that will also be re-
usable for indoor localisation:

! Domotic Ontology: A device ontology that describes various domotic devices based
on their functions as building sensors.
5.5.1.5 Ontologies from WP3.2 " Elderly friendly transport Information Services"
The overall aim of this workpackage is to make the use of transport services accessible to eld-
erly people, from the pre-trip planning stage to on-trip assistance: in particular, to
! take into consideration elderly people’s needs at the trip planning stage (especially
trips involving public transport),
! analyse elderly people’s needs when planning a multimodal trip,
! take into consideration elderly people’s needs while a) on a short-range trip ; b) on a
long-range trip,
! analyse public transport information available at stations and hubs for elderly people,
! analyse ways of presenting traffic information to elderly people while travelling,
! define a common interface for inter-modal trip planning.
So far the following ontologies have been developed in this work package and uploaded to
ORATE:
! Device: An ontology for devices with focus on mobile devices.
! Point Of Interest: An ontology that describes general points of interest, but from
elderly and disabled perspective.
! Trip: A general ontology for any kind of trip.
5.5.2 Ontologies developed by third parties
Besides ontologies created by OASIS partners, ORATE hosts third party ontologies that are
considered beneficial for knowledge reuse or alignment. This represents an open list of on-
tologies that are being progressively evaluated and used for guidance in the restructuring of
the OASIS-internal ontologies. The most significant of these ontologies currently uploaded
and hosted on ORATE are:
1. DOLCE-lite: a light, i.e., restricted to lie with the expressivity of OWL, version of the
foundational ontology Descriptive Ontology for Linguistic and Cognitive Engineering
(DOLCE - see. http://www.loa-cnr.it/DOLCE.html)
2. GIST: the minimalist upper ontology (http://gist-ont.com/).
3. Ordnance Survey Ontologies: a network of topographic ontologies that include
substantial treatments of objects relevant for route planning, etc.
(http://www.ordnancesurvey.co.uk/oswebsite/ontology/).
Both the Ordnance Survey and DOLCE-lite ontologies are already spread across several
modular subontologies and so appear as a network of interlinked ontologies within the
repository. As is common with the current state of the art in OWL ontologies, however, the
interlinking is restricted to OWL imports. Within ORATE we are progressively incorporating

cross-links within and across the subontologies according to our hyper-ontology principles.
5.5.2.1 DOLCE
The Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) is the first
module of the EU FP6 WonderWeb Project (2002-2004) foundational ontologies library. As
implied by its acronym, DOLCE has a clear cognitive bias in that it aims at capturing the on-
tological categories underlying natural language and human cognition. The categories it intro-
duces are thought of as cognitive artefacts, which are ultimately dependent on human percep-
tion, cultural imprints and social conventions. In this sense, they intend to be descriptive (vs.
prescriptive) notions that assist in making already formed conceptualizations explicit.
The DOLCE-Lite module encodes the basic DOLCE (http://dolce.semanticweb.org) ontol-
ogy into OWL-DL. It comprises the following modules:
1. DOLite with Temporal Relations: The Temporal Relations module encodes some
spatial relations into OWL-DL, as a plugin to DOLite.
2. DOLite with Spatial Relations: The Spatial Relations module encodes some spatial
relations into OWL-DL, as a plugin to DOLite.
3. DOLite with Descriptions and Situations: The Descriptions and Situations (DnS)
module includes concepts and relations for modelling ways of contextualizing entities
and facts (e.g. viewing a set of entities and facts as resources for a plan, or as
ingredients for a recipe, or as elements of an observed scene), etc., as a plugin to the
DOLite+ library.
4. DOLite with Information Objects: The Information Objects module includes
concepts and relations for modelling documents, texts, linguistic elements, icons, and
their realizations, content, etc., as a plugin to the DOLite+ library.
5. DOLite with Functional Participation: The Functional Participation module
includes relations for modelling thematic roles and action frames, such as performing,
being a target, an agent, etc., as a plugin to the DOLite+ library.
6. DOLite with Modal Descriptions: The Modal Descriptions module includes classes
and relations for modelling modal relations or operators, such as right, obligation, etc.,
as a plugin to the DOLite+ library.
7. DOLite with Collections and Social Objects: The Social Objects module includes
concepts and relations for modelling entities that are created by a society, or within a
social perspective, e.g. collectives, natural, social or legal persons, organizations,
systems, etc., as a plugin to the DOLite+ library.
8. DOLite with Plans: The Plans module includes concepts and relations for modelling
plans, tasks, roles, executions, etc., as a plugin to the DOLite+ library.
9. DOLite+ (Complete DOLite Library): The DOLCE-Lite-Plus library contains all
the modules that are plugged into DOLCE-Lite, but are of general use. The DLP_397
module itself is empty, as it only contains the imports of all contributing modules and
is used for organising the entire DOLCE-Lite ontology according to principles of
modularity.

5.5.2.2 GIST
The GIST ontology is an experimental prototype proposed by Dave McComb of Semantic
Arts Inc. developed for commercial information systems with the particular aims of providing
an upper level, i.e., general ontology for organising all kinds of domains, and at the same time
remaining small. The motivation for this approach draws from the current success stories in
ontology application which are, almost without exception, small scale: obvious examples are
Dublin Core, FoaF, and similar light-weight organisations. The GIST ontology draws its input
from the theory of Semantic Primes from Wierzbicka (Wierzbicka, 1996) and, what McComb
describes as, ‘consensus primes’, which are “invented, but widely agreed upon” constructs,
such as legal entities, collections, geo-regions and intellectual property. As an ontology that
has been developed completely independently of OASIS and of other approaches that we have
explored previously—both in the ongoing cooperations of the Bremen Ontology Research
Group (e.g., DOLCE) and our general state of the art reviews (e.g., SUMO, Cyc)—the GIST
ontology has been included to explore its overlap and mapping potential for further organising
and cross-classifying OASIS domain ontologies.
5.5.2.3 Ordnance Survey Ontologies
The goal of Ordnance Survey’s (OS) GeoSemantics team
(http://www.ordnancesurvey.co.uk/oswebsite/ontology/) is to provide both an explicit repre-
sentation of their organisation's knowledge and a set of increasingly automated operations that
allow different datasets to be combined, by representing them in a semantically meaningful
way via ontologies. Ontologies contain a set of knowledge about a specific domain relevant
for geographic information systems. Currently the OS team is building including a
Topographic ontology by employing a staged process in which ontologies are progressively
constructed for sub-domains within topography. So far they have released ontologies
describing Hydrology, Buildings and Places and Administrative Geography, along with
modules containing terms common across the modules as a set.
For OASIS, we uploaded to ORATE two of the OS ontologies which overlap very closely
with OASIS application targets:
! OS Spatial Relations: to define spatial topological relationships required by the OS
Topographic Ontology.
! OS Buildings and Places: to describe buildings and places that are topographically
relevant—i.e., which are sufficiently important to be recognised and recorded by
Ordnance Survey surveyors. Crudely, buildings are defined as fixed permanent roofed
structures and places “where something happens”. The scope is extended to cover the
identification of such buildings and places (e.g. in terms of naming or addressing) and
the main activities that may occur in such buildings and places. Also in scope are
significant topological or mereological relationships and spatial extent where this is
definable. Out of scope are buildings smaller than 5m2, parts of buildings (all uses are
assumed to occur within a building without specifying where) other than through
inference (i.e. the assignment of multiple addresses to a building). Also out of scope
are places that are located within buildings. In this ontology, place is regarded only in
a topographic sense, although historical uses of buildings are also considered in cases
where the form is distinctive—for example, when a lighthouse now used as a hotel.

During year 3 the possible use and extension of these ontologies for route planning activities
within SP3 applications will be explored.
5.6 Conclusion
In this chapter, we have described the current state of the OASIS COF support tools, includ-
ing both plug-ins for ontology editing with Protégé and the OASIS Open Ontology Reposi-
tory, ORATE. In addition, we have shown how the interaction with OASIS project partners
during ontology design has been particularly beneficial. The interaction enabled us to clarify
not only which particular ontological information is necessary for specific application scenar-
ios, but also, just as important, showed how we could streamline the process of transferring
informal or non-ontological conceptualisations into ontological form. This led to particular
software components precisely aimed at opening up this traditional bottleneck in the knowl-
edge acquisition process. The resulting tools enable the stages of the COF methodological
component to be followed more closely and with less prior knowledge concerning ontological
engineering on the part of domain experts and application developers. Finally, we have also
summarised the currently uploaded contents of the ORATE OOR, describing how these relate
to the ongoing service development activities within the other OASIS subprojects.

6 The future of Open Ontology Repositories: Ontologizing

Metadata for Assistive Technologies
As the Semantic Web (SW) envisions a metadata-rich Web where human-readable content
will have machine-understandable semantics, there has been an increasing number of OWL
ontologies responding to these knowledge representation requirements. In 2005 Wang et al.
(Wang et al., 2006) collected 1275 ontology files including both OWL and RDF schemas; a
more recent count, based on web crawling, gave the impressive result of over 6000 validated
OWL ontologies (Backer et al., unpublished data); in the same vein Swoogle (Ding, 2004)
now hosts 2,563,125 Semantic Web Documents (SWD) (Swoogle.umbc.edu, 2008). These
growing numbers, which reflect the intrinsic need of the SW for ontologies, have fostered a
number of research projects aimed at supporting re-usability, better modularization as well as
intelligent storage and retrieval for the encoded knowledge. To this end the design and devel-
opment of standardised metadata for describing ontologies is critical. Repositories should be
able to facilitate not only the discovery of reusable components, entire ontologies or just por-
tions of them, but also interoperability across repositories.
An indication of the problem can already be seen within the OASIS context. As reported in
the previous chapter, the OASIS repository ORATE already contains over 45 ontologies. Al-
though useful for the ontology engineer, the lists presented do not directly indicate the do-
mains covered in anything more than a schematic way by virtue of the descriptions offered of
individual ORATE projects and examination of the actual contents of ontologies and map-
pings. A further goal of OASIS is to make the bundled information available within its on-
tologies more straightforwardly available to potential users and service providers. This is one
of the foci of WP1.3. To provide support for such information presentation, we see the need
for clean meta-descriptions of the ontologies that are being maintained within ORATE. This
concerns the definition and use of ontology metadata.
In a recent effort to unify the description of ontologies, the Ontology Metadata Vocabu-
lary Consortium (Palma et al., 2008) proposed a set of descriptors following the principles of
the Dublin Core. This is a step in the right direction as most ontologies currently developed
exist without any additional information in the form of machine-accessible metadata. For the
OASIS ontologies being developed according to the COF, we therefore also advocate the use
of OMV and are currently investigating further refinements and extensions of this proposal.
Although the extensions we propose for the OMV are, in principle, domain independent, our
main interest for the purposes of this deliverable lies in supporting repositories with a particu-
lar focus on the applications targeted for elderly people within OASIS. We identify the fol-
lowing guiding principles when using metadata for structuring ontology repositories: (i) exist-
ing ontology standards should be kept intact; (ii) the metadata-core is connected to various
meta-descriptions through alignment mediators; (iii) meta-descriptions structure specific parts
of knowledge; (iv) meta-descriptions need to support query languages and reasoning; (v)
meta-descriptions may again be ontologies.
In this chapter we show how we can adopt and extend the OMV initiative, understood here
as a core metadata language for OASIS COF-conformant ontologies. We argue that OMV
needs to be extended in two dimensions: horizontally, by adding specific metadata meeting

our application needs (i.e. motivated by OASIS), and vertically, by refining a specific part of
this extended metadata by means of an alignment with a purpose-specific meta-description or
ontology. We are particularly interested in the OMV metadata that addresses temporal aspects
as this is closely related to the evolution of ontologies: this is therefore the vertical extension
provided.
6.1 Repositories and Metadata in general

Repositories, within the context of the Semantic Web at large, will need to offer more than
just data storage. The Ontolog community, a virtual community of practice of ontology
experts, have discussed this matter at length and agreed that the purpose of an Open Ontology
Repository (OOR) is to provide an architecture and an infrastructure that supports: a) the
creation, sharing, searching, and management of ontologies, and b) linkage to database and
XML Schema structured data and documents (OASIS, 2008). Currently there are some
ontology repositories available over the web, but none of them complies with the
requirements agreed upon during the last Ontolog Summit (OntologySummit, 2008). For
instance, Swoogle provides a single entry-point to several semantic web documents
(ontologies), but does not offer any validation, as there is no quality control over the exposed
material; nor does it facilitate query or editing operations. Swoogle’s query approach for
finding ontologies is based on (sub-)string search and link-based reference counting; once the
document has been found, it does not support any further operation. It does, however, allow
the composition of queries via the REST interface.
OntoSelect (Buitelaar et al., 2004) offers a similar approach; it presents the user with a
basic overview of web-accessible ontologies. The collection can be browsed by: ontology
name (derived from owl:Ontology/rdfs:comment); format (from the ontology URL); human
language (from rdfs:label); number of labels, classes, properties, or included ontologies
(owl:imports). Currently OntoSelect hosts 1530 ontologies. Another repository, developed as
part of the TONES project (Calvanese, 2006), hosts 185 ontologies. It aims to provide a
sufficient number of ontologies for testing purposes, emphasizing reasoning techniques. This
repository also supports the REST interface for programmatic access. Ontologies can be
selected and sorted by means of metrics for expressivity, class and property restrictions and
axioms, logics, and individuals.
A novel approach is provided by Rubin et al. (Rubin et al., 2008) with BioPortal. Not only
does it provide access to several ontologies, but it also facilitates online editing operations
such as annotation of ontologies in the form of marginal notes currently only available for
classes. In (Pan et al., 2003), a lightweight metadata ontology for an ontology repository of a
multiagent system is presented. The ontology consists of four classes: Conceptualization,
Ontology, Person, and Representation. The Ontology is described by a title, version number,
language, author, and textual description. The Person defines the author of an ontology, while
the Conceptualization class defines an abstract view on which the ontology is based. The class
Representation specifies the encoding of Ontology, Person, and Conceptualization. This
repository also supports the REST interface.
Although existing ontology repositories aim to provide access to semantic web documents,
interestingly each one of them interprets and uses metadata in a different manner. For
instance, Swoogle defines three categories of metadata; (i) basic metadata, which considers

the syntactic and semantic features of an ontology, (ii) relations, which consider the explicit
semantics between individual ontologies, and (iii) analytical results such as SWO/SWDB
classification, and ontologies. Both TONES and OntoSelect also rely on structural metadata;
however, the use of this metadata is limited to a subset of it. As BioPortal supports the
involvement of communities of practice it makes use not only of structural metadata but also
of that metadata describing how the community has engaged with the development: for
instance, by describing those who have defined a new relationship by means of a marginal
note that facilitates establishing confidence rankings. Having a common metadata framework
could improve queriability and comparison across ontologies; for instance, finding similar
classes across several ontologies could be possible. More complex queries, such as “which is
the most commonly used object property for which there is this X domain and this Y range
defined within the domain of transport ontologies across K, L, and M repositories”, could be
executed if we had such a common metadata framework.
The most developed and unified metadata approach is, as mentioned above, the OMV
approach. A view of the is_a hierarchy proposed by OMV is presented in Fig. 33.
Fig. 33. A view of the OMV is-a hierarchy
The ontology metadata standard OMV aims to enhance the retrieval, identification, and re-
use of ontologies from the Web effectively and efficiently. Modularity is one of its design
principles: OMV distinguishes between the OMV Core and various OMV Extensions. We
will consider here only OMV Core and refer to it, for convenience, simply as OMV. The main
class in OMV is Ontology. With its datatype properties URI, version, and resourceLocator, it
allows the description of an ontology file in a particular version at a particular physical loca-
tion. Possible relations between instances of the class Ontology are: useImports, hasPriorVer-
sion, isCompatibleWith, and isBackward-Compatible. Moreover, there are ten properties re-
lating Ontology to ten other classes: designedForTask OntologyTask, usedKRParadigm
KnowledgeRepresentationParadigm, usedTool OntologyEngineeringTool, hasLevel Formal-
ity-Level, hasLicense LicenseModel, usedMethodology OntologyEngineeringMethodology,
isOfType Ontology-Type, hasSyntax OntologySyntax, hasLanguage Ontology-Language and

hasCreator/hasContributor Party. A Party is a Person or an Organization and isLocatedAt Lo-

cation. Moreover, Party is related to all other classes apart from Ontology with developedBy
or specifiedBy.
For our extension of OMV towards more effective support of ontology evaluation, we
make use of the ABC model (Wang et al., 2006). The ABC metamodel was initially pro-
posed as a core ontology for digital libraries and there are several useful several similarities
between the concept of a digital library and that of an ontology repository that we build upon.
The ABC metamodel was developed within the Harmony international digital library project.
It was initially applied to metadata descriptions for complex objects of museums and libraries.
A central intent of ABC was the ability to model the creation, evolution, and transitions of
objects. Inspired from the theory of Petri Nets a process or evolution is modelled as a network
of events and situations where transition links only exist between events and situations. These
abstract concepts provide contexts for more concrete objects: Actions performed by agents
occur in the contexts of events and manifestations of works exist in situations. Fig. 34 depicts
the relevant portion of the ABC ontology. We adopt this here as a basic metamodel/ontology
that provides an appropriate notional basis both for developing domain specific ontologies
and for describing their evolution.
Fig. 34. The portion of ABC relevant for modelling ontology evolution
The main motivation for providing any kind of metadata is to support meta-reasoning con-
cerning the use or non-use of annotated materials. The need for meta-reasoning has been
noted many times, and there are several approaches to support reasoning and querying on the
meta-level; one recent proposal in the area of ontology is (Tran et al., 2008). Similar to our
approach, Tran et al. interpret a domain ontology O independently from its meta-ontology M,
which they call a meta-view (and assume to be an OWL ontology as well). However, to facili-
tate maintenance, they store the meta-view within O itself as an annotation, and define an op-
erator "(O) = M that can extract the meta-view M from O on demand. Apart from this rather
technical detail, the main difference with our approach is a shift in focus of what the meta-
reasoning is about: in our approach, metadata is data about ontologies as a whole, and the

meta-reasoning is intended to filter out ontologies from a large family of ontologies that fit,
for instance, a particular purpose or task. In (Tran et al., 2008), the meta-view contains a reifi-
cation of the axioms and annotations of a (fixed) ontology O, and meta-reasoning is intended
to evaluate and select pieces of information, e.g. axioms, from within the ontology O. Clearly
this might also prove of use in the OASIS context at a later stage in the project’s develop-
ment.
6.2 The Need for Ontologized Metadata

We agree with both the OMV and the ABC as well as with those metadata models proposed
by other investigated repositories in that the syntactical structure of the ontology is a valuable,
and viable, metadata source. But this needs to be taken further. If we consider metadata as
ontologies in the style of Tran et al. and as we propose here, then it is logical to apply our
own methodology for ontology development to this. Accordingly, we have closely followed
the steps proposed by the COF methodological component, namely: (i) identification of com-
petency questions, (ii) reusable ontologies, (iii) domain analysis and knowledge acquisition,
iv) iterative building of ontology models, (v) formalization, (vi) evaluation, and have consid-
ered the OMV with respect to the particular purpose of organising ontologies for assistive
technologies. In particular, we started with the definition of competency questions (Bontas et
al., 2006; Garcia et al., 2006; Gomez-Perez et al., 2004) for which time and temporal changes
were an issue. For instance, (i) for which versions of ontology X has developer A contributed?
(ii) Which action caused existence of two variants (e.g. RDF/OWL) of the same version of
ontology X? (iii) Has that ontology been reused for the development of a new ontology? (iv)
Who was the developer who has taken ontology X as basis for the new ontology Y? As ours
is a proposed model, we evaluated it against the competency questions.
We also used these questions as a framework to conduct an informal evaluation that could
produce information as to where the OMV model was not sufficient; scenarios for which
modularization were essential were then laid down. One significant feature for our scenario
was the specialization of metadata; for instance, the need for additional categories for describ-
ing assistive technologies. We continued with the identification of reusable upper-level on-
tologies that could be used to better modularize our domain and also that could make it easier
for us to model temporal aspects. We analyzed DOLCE (Masolo et al., 2003a), ABC, and
CIDOC-CRM (ISO, 2006). In the present case, we decided to adopt ABC because it focuses
on ontologizing metadata by proposing a core ontology for it. This has several benefits;
firstly, it allows for untangling the metadata, thus achieving a more modular structure. In ad-
dition, temporal aspects are central for ABC—modelling changes over time for digital media
was one of its primary motivations. ABC thus provides a simple and easy-to-adapt model that
is closer to our domain: digital media for ABC, become ontologies for us. In this respect,
DOLCE was too general for our purpose here of ontologizing metadata. Moreover, although
CIDOC-CRM provided special features for modelling time and temporal events, the nature of
change is intriguingly different. The motivation behind the ABC model is to represent how
objects change over time, whereas CIDOC-CRM focuses more on changes in context and as-
cription rather than the transformation of the object (Doerr et al., 2003). The domain analysis
and knowledge acquisition were then done in parallel with the re-definition of the OMV
model. After analyzing both models in detail with regard to merging and restructuring strate-

gies, we identified and mapped those ABC classes that are most significant and relevant.
Mappings were constantly validated against the relevant use scenarios.
Fig. 35 illustrates a fragment of the ABC ontology and how it models time and temporal
changes. ABC takes from the Functional Requirements for Bibliographic Records (FRBR)
standardization effort (IFLAI, 2008) the definition: “Work is an abstract notion of an artistic
or intellectual creation”. A Work as an abstract notion is not tangible, but it always has a re-
alization (hasRealization) which is called Manifestation in ABC. Assertions on Manifesta-
tions depend on the context (inContext) of a Situation. Situations can change only when an
Event happens; that is to say, a situation follows an event and an event precedes a situation
which essentially allows for modelling temporal aspects of change. Therefore events are al-
ways annotated with timestamps. An event not only changes situations, but also may produce
(hasResult) new manifestations. Moreover, events are composed (hasAction) of Actions,
which are performed in the presence (hasPresence) of Agents.
Fig. 35. A portion of the ABC model
The ABC model allows us to answer questions such as: how many variants of the file XY
(=manifestation) exist after (=event) the maintainer A (=agent) migrated (=action) to the new
format that was adopted as a new standard by the market (=situation)? The type of manifesta-
tion we have in mind within the context of OMV is an ontology as a tangible object (e.g.
OWL file). In a real world scenario an ontology developer, similarly to a software engineer,
creates, modifies, and/or deletes ontology files. This is therefore a very abstract and general
view of versioning as such. ABC both models the versioning process and allows for further
formal refinements as required. Fig. 36 illustrates an appropriately tailored version of the
ABC fragment where we change the rather passive property name hasPresence to the active
name performs. The tailored ABC model can be summarized as: A Manifestation is the reali-
zation (hasRealization) of a Work that is subjected (hasResult) to Actions performed by an
Agent.
Fig. 36. An initial step towards ABCing OMV

None of the OMV classes/properties represent temporal aspects related to the class Ontology.
OMV models temporal aspects only as data type properties; namely, version,
modificationDate and creationDate, thereby restricting the range of reasoning that can be
performed. Intended instances of this class are concrete objects like OWL-files hosted on a
specific server with a specific version number. The OMV model also does not allow
representing which of these files belong to a common history of changes, i.e. an abstract
notion of ontology that is the umbrella for all its manifestations in concrete OWL files. To
make best use of both ontologies the ABC and the OMV, we therefore suggest to merge them
as depicted in Fig. 37.
Fig. 37. The ABCed model
The major change we introduce to the original OMV model is the refactorization of the
class ontology into two classes: Work and Manifestation. The intended instances of Ontology
in OMV are in fact all manifestations. Apart from that, we used from ABC the class Action
which connects manifestations. First and foremost this allows us to model the evolution of
ontologies. The refactorization also makes it possible to have a clearer definition for the ob-
ject properties that are being used by the class Ontology in OMV; for instance, a concrete file
(=manifestation) is written in a certain OntologyLanguage. However, a class such as Ontol-
ogyTask may refer to the work as a whole, rather than to one of its manifestations.
The original OMV resembles an extensive checklist and some of the classes proposed may
not be necessary for the purpose of describing an ontology. For instance, it remains an open
question if classes such as OntologyEngineeringMethodology are necessary. Very few meth-
odologies are explicit in the accurate description of those methods and techniques they sug-
gest. Furthermore, the application of a methodology usually involves the redefinition of some
of the original steps/methods/techniques proposed.
Repositories such as sourceforge.com have defined their own set of metadata and their
query facilities make use of these metadata in order to facilitate more accurate searches. These
software repositories are, however, different from open ontology repositories because they
provide users with functionalities oriented to store projects, there is no need for a program-
matic access via APIs, nor is there any dependency on the repository software being able to
consume ontologies from other repositories.
6.3 An OASIS Use Case

To give an illustrative example we want to describe the evolution of the transportation ontol-
ogy by means of the ABC-ontology as illustrated in Fig. 38. We will use object identifiers as
in: i) from ABC: WK for Work, MN for Manifestation, AC for Action, and AG for Agent, ii)

from OMV: OL for OntologyLanguage, OD for OntologyDomain, OET, and iii) from an
OASIS module: OUG for OASIS User Group.
A developer (AG1), whose interest is accessible transportation (OD1), wants to develop an
ontology (WK2) accordingly. Initially, AG1 re-uses (AC1) the latest version (MN1) of a
transportation ontology (WK1) from the repository. As the developer is familiar with the de-
velopment tool IsaViz (OET1), the first draft (MN2) of the redefined transportation ontology
is written in RDF (OL1).
After submitting MN2 to the repository, another developer (AG2) is engaged in the work
(WK2) and adds (AC2) information about OASIS user groups (see below). Therefore, MN2
needs to be written in OWL 1.1 (OL2) and results in a new version (MN3). After reviewing
MN2, AG1 and AG2 decide to split the ontology into two versions (MN4 and MN5). MN4
specifies accessible transportation for blind users (OUG1): this ontology (WK3), for instance,
specifies blind-specific services at airports and train stations. MN5 specifies accessible trans-
portation for wheelchair users (OUG2). This ontology (WK4), for instance, specifies wheel-
chair-specific services, such as elevator facilities. This example also shows how we use the
competency questions as discussed in the chapters on methodology above (Chapters 2 and 3).
6.4 A Specific Scenario

For application-specific purposes, the OMV model should be extended with additional sub-
categories, i.e. vertical refinement. In the OASIS project, aspects for supporting independent
living, health monitoring, and social relationships are specified by ontologies. The OASIS
repository needs to be enriched with metadata about the OasisUserGroup, Device, Health,
Transportation, and others so that queries can be processed; for instance: (a) Are there ver-
sions of the transportation ontology addressing issues related to impaired users? , (b) For
which OASIS devices and/or user groups were these ontologies designed? , or (c) Which
transportation ontologies can be used with mobile devices for way-finding (as in route plan-
ning)?
The first competency question requires information about OntologyDomain (transportation
and mobile devices) and OntologyTask (way-finding). For this case it would be sufficient to
define instances (e.g. Transportation and MobileDevice) for the original OMV classes Ontol-
ogyDomain and OntologyTask. However, the second question illustrates that queries related
to specific types of OntologyDomain depend on a structured representation of the domain.
Hence, for the OASIS repository of ontologies for assistive technologies, refinements of the
OMV categories OntologyDomain and OntologyTask have to be implemented.

Fig. 38. Case study
As seen in the example above, see Fig. 38, specific user groups (OasisUserGroup) are de-
fined by the metadata. This category defines the user group for which the ontology is intended
to be used. This category of OasisUserGroup is specialized into several subtypes, such as dif-
ferent elderly, impaired, or stakeholder classes. Also, in the example above, the transportation
ontology has different versions (MN4, MN5) for either wheelchair users (OUG2) or blind us-
ers (OUG1). Furthermore, Device is specified as a subclass of OntologyDomain. In the OA-
SIS project, assistive technologies are employed on different devices, such as mobile phones,
handhelds, PDAs, wearable clothing, stand-alone computers, or integrated devices in station-
ary systems. Ontologies that support short-range trip planning, for instance, for visiting
friends, the art gallery, or a hospital department, will provide applications with different mod-
ules for maps, route instructions, navigation or way-finding depending on the kind of device.
Ontologies are therefore selected specifically by their device, based on information from the
metadata. Given this refinement of OasisUserGroup and Device for OntologyDomain, the ex-
ample (b) above can be supported. Similarly, not only Device and OasisUserGroup but also
other specializations for OntologyDomain are needed. For instance, Environment, SocialRela-
tionship, Tourism and Health. The granularity of the refinement as well as the required or-
chestration of the resulting metadata will be the result of future experiences and work on the
OASIS repository. The competency question (c) illustrates that both (i) versioning informa-
tion provided by the ABC extension of OMV together with (ii) the OASIS extension of OMV
are necessary.

6.5 Outlook
The query capabilities of the investigated repositories remain limited and are restricted mostly
to the set of metadata being used; this constrains the queries mostly to syntactical features
presented in the ontology. The programmatic access to the repository provided by Swoogle
facilitates the construction of more complex queries that involve, for instance, a subset of the
available ontologies in Swoogle. However, the lack of a standard programmatic access to
other repositories makes it difficult to do cross-queries examinations. For instance, simple
queries such as which is the most commonly used object property for which there is this X
domain and this Y range defined within the domain of transport ontologies across K, L, and
M repositories are not possible. Query functionality can thus be improved by having better
structured, richer and more extensible metadata. As we envision that several repositories of
ontologies will be established, one important aspect that needs to be preserved is interopera-
bility. This can be facilitated by having core metadata that facilitate the development of spe-
cialized descriptors while maintaining the coherence of the core; thus enabling interoperabil-
ity. This will also facilitate efficient reasoning and maintenance of the entire ecosystem of
metadata. In our ongoing work and use case study, we have analyzed which modules should
refine or specialize OMV in order to support OASIS-specific requirements, i.e. a repository of
ontologies for assistive systems. By refining OMV with relevant modules addressing particu-
lar issues of the related repository as described above, it should be straightforward to adapt
different modules for repositories storing other kinds of ontologies. This information can then
be provided directly as a meta-index into the maintained ontologies that can be presented to
users in the Wiki-style OASIS interface under development in WP1.3.

7 Ongoing Research and Development

During the OASIS activities reported on in this deliverable, we have succeeded in making
available to the entire OASIS community a state of the art ontology repository environment
and several Protégé plug-ins for working with modular ontologies with simple mapping rela-
tions between them. These tools are the direct realisation of the OASIS Common Ontological
Framework. All the software is either web-based or available as extensions for Protégé and so
already provides sophisticated ontology development tools without the need for specialised
software. The resulting platform offers a solid foundation for work involving the connection
of ontologies of distinct kinds for the generation of OASIS services as required at this stage in
the project. For the full functionality envisaged as a main scientific result of the OASIS pro-
ject in the area of ontology development, however, we need to continue extending the frame-
work drawing on the theoretical advances described above with respect to the specification of
hyper-ontologies and the tool support offered. For this, we are progressively enhancing all
components of our system, focusing particularly on the support and maintenance of connec-
tions between ontologies, i.e., on the ‘hyper’ component of the hyper-ontology. These activi-
ties accompany the development of applications and services. In this chapter, we describe
these ongoing developments, showing how they fit into our longer term plans for OASIS on-
tology solutions.
7.1 Current Ontology Development Work

As specified in the OASIS COF development methodology for ontologies, there are several
distinct kinds of activities that are currently underway and which will continue over the third
year of the OASIS project as supporting activities for service connection and application de-
velopment. These are:
! the further factorisation and modularisation of existing ontologies (particularly but not
only the large-scale ASK-IT ontologies);
! the further development of ontologies provided by OASIS partners for specific do-
mains;
! the provision of new ontologies for further domains and services as these are begun in
the OASIS subprojects SP2, SP3 and SP4;
! the construction of sets of mappings between ontology modules as specifically driven
by OASIS applications;
! the inter-connection of automatic and semi-automatic ontology mappings as produced
by the OASIS content connection module.
All of these work items will be described in later deliverables concerning the individual
services provided and in the planned updates of this deliverable scheduled for the third year of
the project.

7.2 Current Software development

Current software development involves extensions and interconnections among all the com-
ponents identified in Chapter 5. ORATE is already a useful tool for the OASIS community to
publish, store, find, and share its ontologies—but it also has several limitations that we will
address in our forthcoming work. For this, we first have to define the main direction in which
ORATE is to develop. This means, in particular, that we define the set of core functionalities
desired for ORATE, decide which of ORATE's already available features are part of that core
and which are not and, on this basis, prioritize our development plan accordingly.
A rough classification of ORATE's major functionalities gives three categories:
! editing meta data and comments;
! defining alignments between ontologies;
! searching, browsing, navigation, presentation;
! storage and versioning.
With respect to the first category, ORATE is not intended as a web-based editor for ontolo-
gies and we do not intend to change this; appropriate functionality of this kind is already (par-
tially) accomplished by the WebProtege project
(http://protegewiki.stanford.edu/index.php/WebProtege/). ORATE's actual editing features are
restricted to meta-data and comments. The BioPortal developer community is very active in
this area since these features are considered fundamental for collaborative development and
the sharing of ontologies. Since ORATE is built on top of BioPortal, it will continue to benefit
from the efforts of the BioPortal developer community. Therefore, regarding further im-
provement of meta-data support and annotation facilities, we will continue to draw on BioPor-
tal rather than developing this area ourselves unless we encounter any OASIS requirements
that cannot be met in this way.
In contrast to this, however, the alignment or mapping feature of BioPortal, and hence of
ORATE, can only be seen as a very rudimentary implementation of just part of what we envi-
sion for supporting the OASIS hyper-ontology network. Therefore we must prioritise this line
of development accordingly: we discuss this further in the next subsection.
The ability to search and browse ontologies, navigating across them, is also only supported
to a very limited extent within BioPortal, even though the alignments are intended to play a
significant role. A truly navigable hyper-ontology is not foreseen as a BioPortal functionality
and so, in this area too, we will provide our own OASIS extensions as discussed below.
Finally, the fourth category of BioPortal’s storage and versioning is also limited when
compared with the full potential offered by our logical foundation of hyper-ontologies. Since
ORATE inherits these limitations, we examine in the final subsection of this chapter possibili-
ties to turn ORATE's poor versioning functionality into a powerful semantically aware ver-
sioning system by making use both of HETS and some further existing versioning systems
developed by partners of the Bremen Ontology Research Group outside of the OASIS consor-
tium.

7.2.1 The MAP4MAPPING extension to BioPortal/ORATE
We are currently extending the native mapping facilities available in BioPortal in order to
move ORATE more towards the hyper-connectivity envisaged for OASIS. For this, we are
developing MAP4MAPPING, an extension to ORATE that eases the manipulation of map-
pings across ontologies developed using the Framework for cross-platform rich Internet ap-
plications, FLEX. The MAP4MAPPING tool constitutes part of the instantiation of the hyper-
ontology. In particular, we are formalizing the relationships between ontology concepts by
providing a well-defined specification for representing the mappings involved. We are also
providing a flexible user interface that facilitates the generation of mappings and the explora-
tion of the relations across ontologies.
MAP4MAPPINGS is currently being developed in close collaboration with the BioPortal
team, in the near future we expect BioPortal users also to be able to integrate our extension
into their BioPortal installations if desired. Some of the features we are supporting are the fol-
lowing, summarized further in Fig. 39:
! mapping editor: create, edit or delete mappings;
! full filtering capabilities for the ontology mappings: relationship type, concept and
author, etc.;
! view the notes for mappings;
! view the origin and target for properties;
! visualize the neighbourhood of a concept, or the entire ontology;
! browse source and target ontologies in mapping relationships;
! name/rename and further specify the relationships across ontologies;
! browse mappings for a specific ontology class.

Fig. 39. Supported features
7.2.2 Connecting HETS and Protégé
Protégé is currently the first editor of choice for ontology development for most of the ontol-
ogy development community and for OASIS in particular. Regarding heterogeneity, though,
Protégé has significant shortcomings: it does not support ontologies in different logics, it sup-
ports import links only without renaming and hiding, and has no notion of ontology interpre-
tation and other connections (cf. the discussion in Section 4.2.2.1 above on heterogeneity).
On the other hand it provides several very useful plugins for visualization and editing of on-
tologies in addition to its built-in editing functionality.
HETS is not a competitor of Protégé in this respect. Our goal is to let the developer benefit
from the best features of both systems in cooperation. We aim to accomplish this by using
Protégé as a client for HETS as illustrated in Fig. 40.

Fig. 40. Cooperation between HETS, Protégé, and the broker for manipulation of ontologies in a
heterogeneous network of ontologies
HETS and Protégé cooperate as follows: Inside the HETS’ GUI the user selects a node in
the development graph (say O3 in the figure) that she wants to modify; then she selects in
HETS’ context menu the editor Protégé. HETS translates the subgraph of O3 (i.e. O3 together
with the ontologies it imports, i.e. O1 and O2) to an OWL-graph (here the only links are
OWL imports). Note that the imported ontologies O1 and O2 might be in different logics and
different signatures than O3, because HetCASL supports import modulo logic and signature
translation. Inside Protégé the user modifies O3 to O3' and commits the OWL graph to the
broker. The broker computes the difference of the change and replaces the old HetCASL-
subgraph for O3 by the new one for O3' and takes care about potential new proof obligations
in the new HetCASL graph with respect to the old one.
The current state of this work is that a loose coupling has already been implemented that
allows HETS and Protégé to exchange data. In work to come, this will be provided in a seam-
less fashion so that users can move between the two systems without programmatic interven-
tion. Since achieving this combination is of benefit to a wide range of applications and is not
only relevant to OASIS, this combination will be pursued in cooperation with the Bremen On-
tology Research Group, which will provide extra resources specifically for this task.
7.2.3 Exploring the Hyper-Ontology Network in ORATE

In the above chapter on the hyper-ontology, we considered the hyper-ontology as a graph

structure whose nodes are ontologies in various formalisms and whose edges are different
kinds of links or connections. To explore a hyper-ontology network therefore requires the ca-
pability to present both, ontologies and the links or connections between them. In summary,
BioPortal, and hence ORATE, is limited in the presentation of ontologies and still very poor
in the presentation of connections. Let us substantiate this claim in more detail, starting with
the presentation of ontologies.
BioPortal supports the formats: OBO, OWL, RDF, RRF Protégé frames, and LexGrid
XML. Apart from RDF and OWL, these formats are specifically designed for the needs of the
biomedical community. All of them have more or less the same expressiveness as OWL and
hence less expressiveness than those formalisms covered by HetCASL. We already men-
tioned that OWL is the dominant format in OASIS, so ORATE is sufficient in this respect for
the medium-term. But already in some OASIS work packages we see more expressive formal-
isms than those supported by BioPortal required—for instance, RuleML-like expressiveness
in seen as one natural way of implementing the conditionality of actions upon situations
within the domotic domain. Similar complaints about the lack of support for more expressive
formalisms in BioPortal have also been reported in the Ontolog forum
(http://ontolog.cim3.net/); in particular, support for Common Logic, similar to CASL, is a
common request. Furthermore, even the presentation of OWL-ontologies is limited in BioPor-
tal: only the is-a hierarchy can be browsed, whereas relationships between ontologies cannot
be displayed. This is clearly unsatisfactory because in many cases it is the axioms of an ontol-
ogy that carry the most significant information, not the bare concept classification.
Let us now turn to the presentation of connections between ontologies in BioPortal. Here,
in fact, rather little information is maintained. This can be seen from the tables of concept
mappings in the "All Mappings" tab that we illustrated in Section 5.4.6 above. This already
shows almost of the content available. Considering all the different types of ontology links
and connections presented in the hyper-ontology chapter (where we introduced the hyper-
ontology specification), this kind of presentation is clearly far from being complete. Even if
we would only consider OWL, there would already be more to present, namely the network of
ontologies induced by import links. In general what is missing in BioPortal is a visualization
of many (possibly all) ontologies as nodes and different types of edges representing the vari-
ous connections between these ontologies. But this is exactly the main requirement for an
adequate presentation of a hyper-ontology as a network.
Therefore for ORATE, our extension of BioPortal, we are currently gathering all require-
ments to facilitate an effective exploration of the hyper-ontology comprising navigation inside
ontologies as well as across ontologies via connections as specified by the hyper-ontology
specification. For the exploration of single ontologies (i.e. exploration inside an ontology) we
also plan the support of more expressive formalisms than OWL - not just Common Logic, but
those formalisms covered by HetCASL. For these formalisms, and even for OWL, we aim at
a richer presentation that covers not just concept hierarchies, but also relationships and axi-
oms. For the exploration across ontologies we aim a visualization that takes into account
those connection and link types described in the hyper-ontology specification.

Technically we are working towards this by adopting HETS. HETS offers solid ground-
work for this task in two respects:
! For all languages under the umbrella of HetCASL there are parser implemented in
HETS, including OWL and soon also Common Logic.
! HETS already provides powerful data structures for graph-like presentations for net-
works of ontologies.
We are currently investigating how HETS can be used as back-end for the presentation of the
hyper-ontology in ORATE. HETS, when working as a standalone application, already con-
nects to a legacy graph-visualization tool called uDraw (http://www.informatik.uni-
bremen.de/uDrawGraph/). This demonstrates that the central graphical functionality regarding
the visualization of a hyper-ontology network is actually already provided for. The GUI can
therefore stand as a functional requirements specification for similar functionalities to be sup-
ported in ORATE. The corresponding extension required for ORATE will be explored by
adopting HETS' underlying data structures for graph-like visualization since their general de-
sign makes them suitable to connect to any kind of graph rendering tool—be it standalone or a
web-based. Moreover, since HETS is an implementation based on solid theoretical grounds,
all displayed objects are guaranteed to have a formal semantics—in contrast to the mappings
present in BioPortal that deliberately remain agnostic concerning any formal semantics.
Finally, it should be mentioned that deliverable D1.3.1 presents in section 5 a visualisation
and editing tool for those concept mappings that can already be created in ORATE/BioPortal.
However, the formal semantics of these mappings naturally remains an open issue for this
tool too. This can stand as a concrete baseline for further development that can draw on a
more varied and formally specified range of mapping types for a next cycle of hyper-ontology
development.
7.2.4 Semantic Versioning in ORATE
Ontologies naturally evolve over time for various reasons: new scientific insights or applica-
tion purposes may imply changes (refinements or corrections) of axiomatization. In this evo-
lution, typically the coverage and granularity of ontologies increase, or the perspective on the
domain shifts. Sometimes a developer or user community agree on new naming conventions;
sometimes there are even good reasons to change the whole formalism, etc.
Such evolutionary steps always aim to improve ontologies, but by the same token they are
a source of unpredictable problems: ontologies are tightly interconnected in the hyper-
ontology network as well as in the applications using these ontologies. Local changes in an
ontology can therefore have global effects in the network: connections between ontologies
might become inconsistent and applications operating on these ontologies may no longer
work well together. Keeping a network of ontologies consistent and their applications interop-
erable is evidently a never-ending requirement. To accomplish it effectively, a sophisticated
management of change is indispensable.
ORATE via its software basis in BioPortal provides only a simple versioning mechanism:
every uploaded ontology has one owner, namely the person who checked in the ontology the
first time. Only the owner of an ontology is permitted to submit new versions of an ontology.

A version is identified by a version Id that is created by the owner. Every registered ORATE
user can check out any version of any ontology in the database. Each version of an ontology is
stored as a separate file in the back-end that is identified by a unique number in the tail of its
URL. Differences between subsequent versions can be downloaded in text or RDF format.
The handling of ORATE's versioning system is in fact very easy to learn, but it is much too
simplistic as a serious system for the management of change. Indeed, its functionality is far
below the state-of-the-art of existing versioning systems as used for software development.
Several of the shortcomings of BioPortal’s simple versioning approach are the following:
! Since it is up to the ontology owner’s preference how to deal with the version number-
ing, there is no common numbering scheme. It is not uncommon to find version Ids
like "3971", "1.101", "beta", "dev", "See Remote", "2009_2009_02_13", etc. More-
over, it is even possible to create smaller version numbers for later versions or the
same Ids for two different versions. This chaos of numbering schemes hampers auto-
mated access to versions and the version numbers given for the repository often fail to
correspond to the version number in the meta-data inside the file.
! The single owner paradigm contradicts the idea of collaborative development.
! There is no easy way to check out a version of a bundle (or directory) of ontologies
that are connected in the hyper-ontology network. Often the locally downloaded on-
tologies are not interoperable as they belong to incompatible versions. Moreover, it is
not always easy to figure out whether the recently downloaded version of an ontology
is still the latest. So it could easily happen that a developer works on an outdated ver-
sion.
! Differences are computed between consecutive but not between arbitrary versions of
ontologies.
! Neither branching of versions nor tagging is supported to bundle ontologies of (possi-
bly different) versions to a major release.
! A conflict or merge mechanism to handle conflicting submissions is not available.
! Versions are stored as complete files instead of mere diffs. Though storage is cheap
nowadays, this might noticeably reduce a repository’s capacity in the long run: typi-
cally, the bigger ontologies are the more revisions per time period are submitted and
large ontologies can consume several MBs.
In contrast to this state of affairs, there are many standard versioning systems on the mar-
ket, like CVS, Subversion, GIT, etc., whose basic features overcome these and several other
shortcomings of BioPortal's simple versioning approach; these have not so far however been
applied to the special case of ontology versioning in a way responsive to ontological engineer-
ing needs.
In our next versions of the OASIS ontology toolset we aim to make these features available
to ORATE by connecting a dedicated versioning system to the repository. However, version-
ing systems as mentioned above have one main drawback: their versioning is line based -
more precisely - they take lines as atomic units for calculating the difference between two

documents. This is not suitable for highly structured documents where a semantic unit is not
delimited by a line break. Therefore we envision a versioning system that respects the seman-
tic units of the versioned document.
XML is nowadays the widest spread format for any kind of structured document. It is rea-
sonable to assume that not just OWL, but any other ontology formalism can be more or less
straightforwardly encoded in an appropriate XML-format. We are therefore currently investi-
gating, together with the KWARC research group (http://kwarc.info) at the Jacobs University
Bremen, the suitability of the OMDoc format (Kohlhase, 2006) as a general ontology lan-
guage. Since this language has been applied for many years in formalized mathematics to en-
code various logics, we do not expect any barrier to its use as a format for ontologies. One of
OMDoc's particular strength in comparison with other ontology languages is its sophisticated
integration of informal and formal content that would also support the documentation aspects
of our ontology development methodology as described above.
For versioning of documents in OMDoc format the KWARC group has also developed an
XML-aware versioning system, called TnTBase (https://trac.mathweb.org/tntbase/), on top of
subversion. We are currently investigating how this can be connected to ORATE to improve
its functionality for management of change. Since this versioning system is applicable to any
XML documents and ontologies are generally represented in XML-compatible formats, we
see this as a very promising line of development, which could have a significant impact on the
process of ontology development in general.

8 Conclusions
We have in this deliverable introduced the OASIS Common Ontology Framework, its meth-
odological component, its hyper-ontology component, and the instantiation of this component
within the OASIS repository, ORATE. The entire framework stands as the embodiment of the
general OASIS ontology platform scheme depicted in schematic form in Fig. 41. Major steps
have now been taken towards realisation of all the originally envisaged organisation and func-
tionality. To conclude this deliverable, these steps are now summarised and their planned ex-
tensions during the remainder of the OASIS project briefly reiterated.
Our description follows the graphical representation in Fig. 41, generally proceeding from
top to bottom.
Fig. 41. The OASIS generic ontology platform: organisation and interconnections
As described at length above, the Common Ontological Framework provides the general
guidelines, both methodological (Chapters 2 and 3) and logical (Chapter 4), for the establish-
ment of a hyper-ontology framework. This hyper-ontology framework is itself instantiated as
a concrete network of implemented ontologies maintained with the OASIS Ontology Reposi-
tory ORATE (Chapter 5). ORATE is an Open Ontology Repository, indicating that any user
may upload an ontology regardless of quality: this is indicated by the larger solid box labelled
the “OASIS Ontology Repository” in the figure. From this set of ontologies, those selected
for, or particularly developed for, OASIS use need to undergo the COF guidelines for quality
control and methodological development. This control and development is carried out under
the supervision of the ontology development team of OASIS. The resulting COF-conformant
ontologies form the ‘inner circle’ of OASIS ontologies maintained within ORATE; this is in-
dicated by the dashed box within the OASIS Ontology Repository in the figure. As part of
this control mechanism, we have evaluated existing metadata proposals for organising ontolo-
gies and have made a particular recommendation for metadata extension relevant for assistive
technology ontologies such as those maintained within ORATE (Chapter 6); the use of this
metadata specification will be explored further in the next round of hyper-ontology develop-

ment. The ontologies maintained within ORATE are then available for the construction of
OASIS services and application, for driving self-configurable interfaces, and for linking with
the OASIS Content Connection Manager (CCM: WP1.3). In all cases, programmatic access
(i.e., automatic access via defined protocols) are being extended and tested. The original use
of BioPortal did not foresee this style of use and so we are needing to make additions to
ORATE accordingly; the highest priority automatic linkage is naturally with the OASIS Con-
tent Connection Manager as this has precisely the function of defining and discovering the
links between ontologies that form the heart of the hyper-ontology. The repository taken to-
gether with the OASIS applications and further components, form the OASIS ontology-based
architecture as a whole. Over the next year of the project, all of the ontologies maintained will
be developed further, modularised, and evaluated with respect to their support for the OASIS
services being constructed in OASIS subprojects SP2, SP3 and SP4. New ontologies will also
be added as required, entering the OASIS ontology lifecycle as foreseen in the OASIS De-
scription of Work.
The technical infrastructure provided by the repository needs in addition to support particu-
lar functionalities as indicated to the right of the figure. Of these, currently concept-concept
and module-module mappings are supported, building on the core functionality of BioPortal
and of OWL respectively. Both are being extended and augmented by theory-theory links as
defined in Chapter 4 and described in more detail as currently ongoing research in Sections
7.2.2 and 7.2.3: here we draw on the very general specification of a hyper-ontology that we
have established are are employing the capabilities of HETS in order to allow inter-ontology
links of many kinds, all with well-defined semantics. The versioning of ontologies supported
is still the basic model inherited from BioPortal. Our current work is therefore exploring the
implementation of a fully semantically-aware versioning system for ontologies as described in
Section 7.2.4. It is worth emphasising here that there are currently no versioning capabilities
for ontologies of this kind in any tools that have been developed: we therefore see this explo-
ration as being of considerable significance for the state of the art in ontological engineering
as a whole. Finally, as indicated above, we will also address further the use of our metadata
proposals for streamlining access to the ontologies maintained with OASIS. We see this also
to be a significant area that will be of increasing importance as the number of ontologies and
the range of intended uses of those ontologies grow, even within OASIS.

9 References
Almeida M.B. (2009) A proposal for evaluating ontology content. Applied Ontology 4:245-
266.
Arpirez J., Corcho O., Fernadez-Lopez M., Gomez-Perez A. (2003a) WebODE in a nutshell.
AI Magazine 24:37-47.
Arpirez J.C., Gomez-Perez A., Lozano A., Pinto H., S. (1998) Reference Ontology and
ONTO2 Agent: The Ontology Yellow Pages, Workshop on applications of Ontologies
and Problem-solving Methods, European Conference on Artificial Intelligence
(ECAI98), Brighton, UK.
Arpirez J.C., Corcho O., Fernadez-Lopez M., Gomez-Perez A. (2003b) WebODE in a
nutshell. AI Magazine 24:37-47.
Ashburner M., Ball C., Blake J., Botstein D., Butler H., Cherry J., Davis A., Dolinski K.,
Dwight S., Eppig J., Harris M., Hill D., Issel T.L., Kasarskis A., Lewis S., Matese J.,
Richardson J., Ringwald M., Rubin G., Sherlock G. (2000) Gene Ontology: tool for
the unification of biology. The Gene Ontology Consortium. Nature Genetics 25:25-29.
Autexier S., Hutter D., Mantel H., Schairer A. (2000) Towards an evolutionary formal
software- evelopment using Casl. In C. Choppy and D. Bert, editors, Recent Trends in
Algebraic Development Techniques, 14th International Workshop, WADT’99, Bonas,
France 1872 of Lecture Notes in Computer Science, Springer:73-88.
Baader F. (2007) The description logic handbook : theory, implementation, and applications.
2nd ed. Cambridge University Press, Cambridge ; New York.
Bada M., Stevens R., Goble C., Gil Y., Ashbourner M., Blake J., Cherry J., Harris M., Lewis
S. (2004) A short study on the success of the GeneOntology. Journal of Web
Semantics 1:235-240.
Bao J., Caragea D., Honavar V. (2006) On the semantics of linking and importing in modular
ontologies. ISWC 2006, LNCS 4273 (In Press):72-86.
Barwise J., Seligman J. (1997) Information flow : the logic of distributed systems Cambridge
University Press, Cambridge ; New York.
Bateman J.A. (1990) Upper Modeling: organizing knowledge for natural language processing,
Proceedings of the Fifth International Natural Language Generation Workshop,
Pittsburgh, PA. pp. 54-60.
Bateman J.A., Kasper R.T., Moore J.D., Whitney R.A. (1990) A general organization of
Knowledge for natural language processing: the PENMAN Upper Model,
USC/Information Sciences Institute, Marina del Rey, California.
Bateman J.A., Borgo S., Lüttich K., Masolo C., Mossakowski T. (2007) Ontological
Modularity and Spatial Diversity. Spatial Cognition and Computation 7:97-128.
Beale S., Nirenburg S. (1997) Breaking down the barriers: The Mikrokosmos Generator,
Natural Language Processing Pacific Rim Symposium (NLPRS), Phuket. pp. 141-148.
Beck H., Pinto H.S. (2003) Overview of Approach, Methodologies, Standards, and Tools for
Ontologies, The Agricultural Ontology Service (UN FAO).
Bernaras A., Laresgoiti I., Correa J. (1996) Building and Reusing Ontologies for Electrical
Network Applications, Proceedings of the European Conference on Artificial
Intelligence (ECAI96), Budapest.

Berners-Lee T. (1999) Weaving the Web HarperCollins.

Bidoit M., Mosses P. (2004) CASL user manual : introduction to using the Common algebraic
specification language Springer, Berlin ; New York.
Boehm B. (1986) A spiral model of software development and enhancement. ACM SIGSOFT
Software Engineering Notes 11:14-24.
Bontas E., Tempich C., Sure Y. (2006) ONTOCOM: A Cost Estimation Model for Ontology
Engineering, Proceedings of the International Semantic Web Conference ISWC 2006.
Borgida A., Serafini L. (2003) Distributed description logics: Assimilating information from
peer sources. Journal of Data Semantics 1.
Bouquet P., Euzenat J., Franconi E., Serafini L., Stamou G., Tessaris S. (2004) D2.2.1
Specification of a common framework for characterizing alignment. KnowledgeWeb
Project.
Brinkely J., Suciu D., Landon D., John G., Rosse C. (2006) A framework for using reference
ontologies as a foundation for the semantic web, AMIA Annu Symp.
Buitelaar P., Eigner T., Declerck T. (2004) OntoSelect: A Dynamic Ontology Library with
Support for Ontology Selection, Demo Session at the International Semantic Web
Conference, Hiroshima, Japan.
Calvanese D. (2006) TONES – Thinking ONtologiES, Project overview, Tones Industrial
Advisory Team Workshop, Edinburgh, U.K.
Canas A.J., Leake D.B., Wilson D.C. (1999) Managing, Mapping and Manipulating
Conceptual Knowledge,, AAAI Workshop Technical Report WS-99-10: Exploring the
Synergies of Knowledge Management & Case-Based Reasoning, AAAI Press, Menlo
California.
Cañas A.J., Hill G., Carff R., Suri N., Lott J., Eskridge T., Gómez G., Arroyo M., Carvajal R.
(2004) CmapTools: A Knowledge Modeling and Sharing Environment, in: J. D. N.
A.J. Cañas, and F.M. González (Ed.), Proceedings of the First International
Conference on Concept Mapping, Pamplona, Spain.
Common Logic Working Group. (2003) Common Logic: Abstract syntax and semantics.
Cooke N. (1994) Varieies of Knowledge Elicitation Techniques. International Journal of
Human-Computer Studies 41:801-849.
Corcho O., Fernadez-Lopez M., Gomez-Perez A. (2003) Methodologies, tools, and languages
for building ontologies. Where is their meeting point? Data and Knowledge
Engineering 46:41-64.
Cote R., Jones P., Apweiler R., Hermjakob H. (2006) The Ontology Lookup Service, a
lightweight cross-platform tool for controlled vocabulary queries. BMC
Bioinformatics 7.
Cuenca Grau B., Horrocks I., Kazakov Y., Sattler U. (2008) Modular Reuse of Ontologies:
Theory and Practice. J. Artif. Intell. Res. (JAIR) 31:273-318.
d’Aquin M., Suarez-Figueroa M. A Quick Guide to Knowledge Reuse with the Watson
Plugin for the NeOn Toolkit,
http://watson.kmi.open.ac.uk/DownloadsAndPublications_files/WNTP-guide.pdf.
Dagnino A. (2001) Coordination of hardware manufacturing and software
developmentlifecycles for integrated systems development, IEEE International
Conference on Systems, Man, and Cybernetics. pp. 1850-1855.

Davenport T.H., Prusak L. (1998) How organizations manage what they know Harvard
Bussines School Press, Boston, Massachusetts.
De Leenheer P. (2009) On Community-based Ontology Evolution FACULTY OF SCIENCE,
Department of Computer Science, Semantics Technology and Applications Research
Lab, Vrije University Brussel.
De Leenheer P., Mens T. (2008) Ontology Evolution: State of the Art and Future Directions,
in: M. Hepp, et al. (Eds.), Ontology Management for the Semantic Web, Semantic
Web Services and Bussines Applications, Springer.
De Moor A., De Leenheer P., ., Meersman R. (2006) DOGMA-MESS: A Meaning Evolution
Support System for Interorganizational Ontology Engineering, 14th International
Conference on Conceptual Structures (ICCS 2006), Springer-Verlag, Aalborg,
Denmark. pp. 189-203.
Dieter Hutter, Bruno Langenstein, Claus Sengler, Jörg H. Siekmann, Werner Stephan,
Wolpers A. (1996) Deduction in the Verification Support Environment (VSE). FME
'96: Industrial Benefit and Advances in Formal Methods, Third International
Symposium of Formal Methods Europe, Co-Sponsored by IFIP WG 14.3, Oxford,
UK, March 18-22, 1996, Proceedings:268-286.
Ding L. (2004) Swoogle: A Search and Metadata Engine for the Semantic Web, Thirteenth
ACM Conference on Information and Knowledge Management.
Dobzhansky T. (1964) Biology, Molecular and Organismic. American Zoologist 4:443-452.
Doerr M., Hunter J., Lagoze C. (2003) Towards a Core Ontology for Information Integration.
Journal of Digital Information 4.
Eden H.A., Hirshfeld Y. (2001) Principles in formal specification of object oriented design
and architecture, Proceedings of the 2001 conference of the Centre for Advanced
Studies on Collaborative research, IBM Press, Toronto, Canada.
Egenhofer M.J. (2002) Towards the Semantic Geospatial Web, Proceedings of the
Geographic Information Science Conference (GIS'02), McLean, Virginia.
Ensan F., Du W. (2008) An Interface-Based Ontology Modularization Framework for
Knowledge Encapsulation. ISWC 2008, LNCS 4273 (In Press):517-532.
Euzenat J. (2007a) Ontology matching Springer, Berlin ; New York.
Euzenat J. (2007b) Semantic Precision and Recall for Ontology Alignment Evaluation, Proc1
of the 20th International Joint Conference on Artificial Intelligence (IJCAI 2007),
Hyderabad, India, January 6-12, 2007. pp. 348-353.
Euzenat J., Isaac A., Meilicke C., Shvaiko P., Stuckenschmidt H., Sváb-Zamazal O., Svátek
V., vanHage W., Yatskevich M. (2007) Results of the Ontology Alignment Evaluation
Initiative 2007, International Semantic Web Conference & Asian Semantic Web
Conference - International Workshop on Ontology Matching, Busan, Korea.
Fellbaum C. (2000) WordNet, An Electronic Lexical Database The MIT Press, Boston.
Fernadez-Lopez M., Gomez-Perez A. (2002) Overview and Analysis of Methodologies for
Building Ontologies. The Knowledge Engineering Review 17:129-156.
Fernandez M. (1999) Overview Of Methodologies For Building Ontologies, In Proceedings
of the IJCAI-99 Workshop on Ontologies and Problem-Solving Methods(KRR5),
Stockholm, Sweden.

Fernandéz M., Gómez-Pérez A., Juristo N. (1997) METHONTOLOGY: From Ontological

Art to Ontological Engineering, Workshop on Ontological Engineering. Spring
Symposium Series. AAAI97, Stanford.
Fonseca F.T., Egenhofer M.J., Agouris P., Câmara G. (2002) Using ontologies for integrated
geographic information systems. Transactions in GIS 6.
Fox M.S. (1992) The TOVE Project: A Common-sense Model of the Enterprise Systems, in:
F. Belli and F. J. Radermacher (Eds.), Industrial and Engineering Applications of
Artificial Intelligence and Expert, Springer-Verlag. pp. 25-34.
Frank A. (2008) Ontology, Encyclopedia of Geographic Information Science, SAGE
Publications, Los Angeles, London, New Delhi, Singapore. pp. 326-329.
Frank A.U. (2001) Tiers of ontology and consistency constraints in geographical information
systems. International Journal of Geographical Information Science 15:667-678.
Frederking R., Cohen A., Grannes D., Cousseau P., Nirenburg S. (1993) The PANGLOSS
mark i MAT system, Sixth conference of the European Chapter of the Association for
Computational Linguistics, Association for Computational Linguistics. pp. 468.
Gaines B., R.,, Shaw M.L., Q. (1993) Knowledge acquisition tools based on personal
construct psychology. The Knowledge Engineering Review 8:49-85.
Gangemi A. (2005) Ontology Design Patterns for Semantic Web Content, Proceedings of the
International Semantic Web Conference 2005 (ISWC 2005), Springer, Berlin /
Heidelberg. pp. 262-276,.
Gangemi A., Catenacci C., Ciaramita M., Lehmann J. (2006) Qood Grid: a metaontology-
based framework for ontology evaluation and selection, 4th International Workshop
on Evaluation of Ontologies for the Web (EON 2006) at the 15th International World
Wide Web Conference, Edinburgh, Scotland.
Garcia A. (2007a) Developing Ontologies within the Biological Domain, Institute for
Molecular Biosciences, University of Queensland Brisbane. pp. 257.
Garcia A. (2007b) Developing ontologies within the Biomedical domain, Institute for
Molecular Biosciences, University of Queensland, Brisbane.
Garcia A., Garcia L.-J., Villaveces J., Calderon G., Hepp M. (2009a) OLS2OWL. A
repository management facility., Submitted to the 11th International Protege
Conference, Amsterdam, Holland.
Garcia A., O'Neil K., Gibson F., Garcia L.-J., Corcho O., Lord P., Stevens R. (2009b) The
Melting Point when developing ontologies, in: H. Chen and Y. Wang (Eds.), Semantic
E-Science, Springer Verlag.
Garcia C.A., Rocca-Serra P., Stevens R., Taylor C., Nashar K., Ragan M.A., Sansone S.
(2006) The use of concept maps during knowledge elicitation in ontology
development processes - the nutrigenomics use case. BMC Bioinformatics 7:267.
Gilb T. (1988) Principles of Software Engineering Management Addison-Wesley Longman.
Gilb T. (2004) Evolutionary Project Management: Multiple Performance, Quality and Cost
Metrics for Early and Continuous Stakeholder Value Delivery., International
Conference on Enterprise Information Systems, Porto, Portugal.
Goguen J., Burstall R. (1992) Institutions: Abstract model theory for specification and
programming. Journal of the ACM 39:95-146.
Gomez-Perez A., Fernadez-Lopez M., Corcho O. (2004) Ontological Engineering Springer-
Verlag, London.

Good B., Tranfield E.M., Tan P.C., Shehata M., Singhera G.K., Gosselink J., Okon E.B.,
Wilkinson M. (2006) Fast, Cheap, and Out of Control: A Zero Curation Model for
Ontology Development, Pacific Symposium on Biocomputing.
Greenwood E. (1973) Metodologia de la investigacion social Paidos, Buenos Aires.
Grenon P., Smith B. (2004) Towards Dynamic Spatial Ontology. Spatial Cognition &
Computation 4:69-104.
Gruber R., Tom. (1993) Toward Principles for the Design of Ontologies Used for Knowledge
Sharing, International Workshop on Formal Ontology, Padova, Italy,.
Gruninger M., Fox M.S. (1994a) The Design and Evaluation of Ontologies for Enterprise
Modelling, Workshop on Implemented Ontologies, European Workshop on Artificial
Intelligence, Amsterdam, NL.
Gruninger M., Fox M.S. (1994b) The Role of Competency Questions in Enterprise
Engineering, Proceedings of the IFIP WG5.7 Workshop on Benchmarking - Theory
and Practice, Trondheim, Norway.
Guarino N. (1997) Understanding, building and using ontologies. International Journal of
Human-Computer Studies 46:293-310.
Guarino N., Poli R., Gruber T. (1993) Toward Principles for the Design of Ontologies Used
for Knowledge Sharing, International Workshop on Formal Ontology, Kluwer
Academic Publishers.
Haarslev V., Möller R. (2003) Racer: A Core Inference Engine for the Semantic Web,
Proceedings of the 2nd International Workshop on Evaluation of Ontology-based
Tools (EON2003), Sanibel Island, Florida, USA. pp. 27-36.
Hage W.R.v. (2008) Evaluating Ontology-Alignment Techniques, Vrije Universiteit
Amsterdam.
Hayes P., Eskridge C.T., Saavedra R., Reichherzer T., Mehrotra M., Bobrovnikoff D. (2005)
Collaborative Knowledge Capture in Ontologies, K-CAP 05, Banff, Canada.
Hemetsberger A., Reinhardt C. (2004) Sharing and Creating Knowledge in Open-Source
Communities The case of KDE, Fifth European Conference on Organizational
Knowledge, Learning and Capabilities., Innsbruck, Austria.
Hoehndorf R., Loebe2 F., Kelso J., Herre H. (2007) Representing default knowledge in
biomedical ontologies: application to the integration of anatomy and phenotype
ontologies. BMC Bioinformatics 8:377.
Hois J., Bhatt M., Kutz O. (2009) Modular Ontologies for Architectural Design, Formal
Ontologies Meet Industry, IOS Press, Amsterdam. pp. 66-77.
Hovy E.H., Knight K. (1993) Motivating shared knowledge resources: an example from the
Pangloss collaboration, Proceedings of IJCAI Workshop on Knowledge Sharing and
Information Interchange.
http://obi.sourceforge.net/. (2007 ) OBI, Ontology for Biological Investigations, Ontology for
Biological Investigations, http://obi.sourceforge.net/, Ontology for Biological
Investigations.
http://www.mged.org/. (2006) Microarray Gene Expression Data.
IEEE. (1991) IEEE Standard Glossary of Software Engineering Terminology, IEEE Standards
IEEE.
IEEE. (1996) IEEE Standard for Developing Software Life Cycle Processes, in: IEEE (Ed.),
IEEE Computer Society.

IEEE. (1998) IEEE standard for software quality assurance plans, in: IEEE (Ed.), IEEE
Computer Society.
IFLAI. (2008) Functional Requirements for Bibliographic Records.
ISI. (2007) Information Sciences Institute, SENSUS Ontology, http://www.isi.edu/natural-
language/projects/ONTOLOGIES.html.
ISO. (2006) Information and documentation -- A reference ontology for the interchange of
cultural heritage information, in: ISO (Ed.), ISO.
Jarrar M. (2005) Towards Methodological Principles for Ontology Engineering, Faculty of
Science, Vrije Universiteit, Brussel.
Kalfoglou Y., Schorlemmer M. (2003a) Ontology mapping: the state of the art. The
Knowledge Engineering Review 18:1-31.
Kalfoglou Y., Schorlemmer W.M. (2003b) IF-Map: An Ontology-Mapping Method Based on
Information-Flow Theory. J. Data Semantics (JODS) 1:98-127.
Kehagias D.D., Papadimitriou I., Hois J., Tzovaras D., Bateman J.A. (2008) A
Methodological Approach for Ontology Evaluation and Refinement, ASK-IT
International Conference 2008.
Kendal S., Creen M. (2006) An Introduction to Knowledge Engineering Springer-Verlag,
London.
Kerr J., Hunter R. (1994) Inside RAD Mc-Graw-Hill.
Knight K., Chander I. (1994) Automated Postediting of Documents, Proc. of the National
Conference on Artificial Intelligence (AAAI).
Knight K., Luck S. (1994) Building a large knowledge base for machine translation,
Proceedings of the American Association of Artificial Intelligence. pp. 773-778.
Knight K., Graehl J. (1997) Machine Trasnliteration, Proc. of the Conference of the
Association for Computational Linguistics (ACL).
Kohlhase M. (2006) OMDoc -- an open markup format for mathematical documents :
(version 1.2) Springer, Berlin ; New York.
Kutz O., Mossakowski T., Codescu M. (2008a) Shapes of Alignments: Construction,
Combination, and Computation, Proc of the 1st Workshop on Ontologies: Reasoning
and Modularity (WORM-08), CEUR-WS, Vol-348, ESWC, Tenerife, Spain.
Kutz O., Lucke D., Mossakowski T. (2008b) Heterogeneously Structured Ontologies -
Integration, Connection, and Refinement. Knowledge Representation Ontology
Workshop (KROW) Sydney, Australia. CRPIT, 90. Meyer, T. and Orgun, M. A., Eds.
ACS:41-50.
Kutz O., Mossakowski T., Codescu M. (2008c) Shapes of Alignments: Construction,
Combination, and Computation, Proceedings of the 1st Workshop on Ontologies:
Reasoning and Modularity (WORM-08), CEUR-WS, ESWC, Tenerife, Spain.
Kutz O., Lutz C., Wolter F., Zakharyaschev M. (2004) E-connections of abstract description
systems. Artificial Intelligence 156(1):1-73.
Lakoff G. (1987) Women, fire, and dangerous things: what categories reveal about the mind
Chicago University Press, Chicago.
Larman C., Basili R., Victor. . (2003) Iterative and Incremental Development: A Brief
History Computer, IEEE Computer Society 36:47-56.
Lenat D. (1995) Cyc: a large-scale investment in knowledge infrastructure. Communications
of the ACM 38.

Loebe F. (2006) Requirements for Logical Modules, in: P. Haase, et al. (Eds.), Proceedings of
the First International Workshop on Modular Ontologies (WoMO 2006), Athens,
Georgia.
Lucanu D., Li Y.F., Dong J.S. (2006) Semantic web languages - towards an institutional
perspective, In K. Futatsugi, J.-P. Jouannaud & J. Meseguer (eds), Algebra, Meaning,
and Computation. Essays Dedicated to Joseph A. Goguen on the Occasion of His 65th,
Birthday, Lecture Notes in Computer Science. Springer. pp. 99-123.
Martin J. (1991) Rapid Application Development Prentice-Hall.
Masolo C., Borgo S., Gangemi A., Guarino N., Oltramari A. (2003a) Ontologies library,
WonderWeb Deliverable ISTC-CNR, Padova, Italy.
Masolo C., Borgo S., Gangemi A., Guarino N., Oltramari A. (2003b) Wonderweb deliverable
d18. Technical report, CNR.
May L., Elaine, Zimmer A., Barbara. (1996) The Evolutionary Development Model for
Software. HP Journal:http://www.hpl.hp.com/hpjournal/96aug/aug96a4.htm.
McDermid J., Rook P. (1993) Software Developement Process Models, Software Engineer's
Reference Book, CRC Press. pp. 15-28.
Meseguer J. (1989) Geneeral Logics. In Logic Colloquium, North Holland 87.
Mirzaee V. (2004a) An Ontological Approach to Representing Historical Knowledge. MSc
Thesis, Department of Electrical and Computer Engineering, Department of Electrical
and Computer Engineering, University of British Columbia, Vancouver.
Mirzaee V. (2004b) An Ontological Approach to Representing Historical Knowledge. PhD
Thesis, Department of Electrical and Computer Engineering, Department of Electrical
and Computer Engineering, University of British Columbia., Vancouver.
Mizoguchi R., Vanwelkenhuysen J., Ikeda M. (1995) Task Ontology for reuse of problem
solving knowledge, in: N. Mars (Ed.), Towards Very Large Knowledge Bases:
Knowledge Building and Knowledge Sharing (KBKS’95), IOS Press, University of
Twente, Enschede, The Netherlands. pp. 46-57.
Moreira D., Musen M.A. (2007) OBO to OWL: a protege OWL tab to read/save OBO
ontologies. Bioinformatics 23:1868-70.
Mossakowski T. (2004a) HetCASL - Heterogeneous Spcification, Languag Summary,
Bremen.
Mossakowski T. (2004b) HetCASL - Heterogeneous Spcification. Languag Summary.
Mossakowski T., Haxthausen A., Sannella D., Tarlecki A. (2008) CASL, the Common
Algebraic Specification Language, Logics of formal specification languages, Springer-
Verlag Heidelberg. pp. 241-298.
Mosses P. (2004) CASL reference manual : the complete documentation of the Common
Algebraic Specification Language Springer, Berlin ; New York.
Mosses P.D. (1997) CoFI: The Common Framework Initiative for Algebraic Specification
and Development. TAPSOFT ’97, Proc. Intl. Symp. on Theory and Practice of
Software Development 1214 of LNCS, Springer:115-137.
Negnevitsky M. (2004) Artificial Intelligence: A Guide to Intelligent Systems. 2nd Rev Ed
edition (27 Sep 2004) ed. Addison Wesley.
Nirenburg S., Raskin V., Tucker A. (1987) The structure of Interlingua in TRANSLATOR,
Machine Translation: Theoretical and Methodological Issues, Cambridge University
Press, Cambridge.

Noy N. (2009) Bioportal: a community-based repository for biomedical ontologies and data
resources, AAAI 2009 Spring Symposium on Social Semantic Web: Where Web 2.0
meets Web 3.0.
Noy N.F., McGuinness D.L. (2001a) Ontology Development 101: a Guide to Creating Your
First Ontology, Stanford University, Stanford, CA.
Noy N.F., McGuinness D.L. (2001b) Ontology Development 101: a Guide to Creating Your
First Ontology, Protege Documentation, Stanford University, Stanford, CA.
Noy N.F., Fergerson R.W., Musen M.A. (2000) The knowledge model of Protege-2000:
Combining interoperability and flexibility, 2th International Conference on
Knowledge Engineering and Knowledge Management (EKAW'2000), Juan-les-Pins,
France.
Noy N.F., Shah N.H., Whetzel P.L., Dai B., Dorf M., Griffith N., Jonquet C., Rubin D.L.,
Storey M.-A., Chute C.G., Musen M.A. (2009) BioPortal: ontologies and integrated
data resources at the click of a mouse. Nucl. Acids Res. 37:W170-173.
OASIS. (2008) Open architecture for Accessible Services Integration and Standardization,
Available from: http://www.oasis-project.eu.
OntologySummit. (2008) Ontology Summit 2008 Communiqué: Towards an Open Ontology
Repository in: P. Yim (Ed.), http://ontolog.cim3.net/, Washington.
Palma R., Hartmann J., Haase P. (2008) Ontology Metadata Vocabulary for the Semantic
Web, OMV Consortium.
Pan J., Cranefield S., Carter D. (2003) A lightweight ontology repository, Second
international joint conference on Autonomous agents and multiagent systems. pp. 632
- 638.
Pankaj J., Shulamit A., Katica I., Elizabeth A., Kellogg. , Susan M., Anuradha P., Leonore R.,
Seung Y., Rhee., Martin M. S., Mary S., Lincoln S., Peter S., Leszek V., Doreen W.,
Felipe Z. (2005) Plant Ontology (PO): a controlled vocabulary of plant structures and
growth stages. Comparative and Functional Genomics 6:388-397.
Parent C., Spaccapietra S. (2009) An Overview of Modularity, Modular Ontologies. pp. 5-23.
Perez A.G. (1994a) Some Ideas and Examples to Evaluate Ontologies, Knowledge Systems,
AI Laboratory, Stanford University, Stanford.
Perez A.G., Juristo N., Pazos J. (1995) Evaluation and assessment of knowledge sharing
technology in: N. Mars (Ed.), Towards Vey Large Knowledge Bases: Knowledge
Building and Knowledge Sharing(KBK95), IOS Press, Amsterdan, The Netherlands.
pp. 289-296.
Perez A.G., Lopez M.F., De Vicente A. (1996) Towards a Method to Conceptualize Domain
Ontologies, Workshop on ontological Engineering. ECAI'96, Budapest, Hungary. pp.
41-51.
Perez A.G., Fernadez-Lopez M., Corcho O. (2004) Ontological Engineering Springer, Berlin
Heidelberg.
Pinto H., S., Martins P., Joao. A methodology for ontology integration, Proceedings of the
international conference on Knowledge capture,, ACM Press, New York, USA. pp.
131-138.
Pinto H., Sofia. , Martins P., Joao. (2004) Ontoloigies: How can they be built? Knowledge
and information Systems 6:441-463.

Pinto H.S., Staab S., Tempich C. (2004a) Diligent: towards a fine-grained methodology for
Distributed, Loosely-controlled and evolving engineering of ontologies, European
Conference on Artificial Intelligence, Valencia, Spain. pp. 393-397.
Pinto S., Perez A.G., Martins J.P. (1999) Some issues on ontology integeration, Workshop on
Ontologies and Problem-Solving Methods: Lessons Learned and Future Trends.
(IJCAI99). Stockholm, Sweden.
Pinto S., Staab S., Sure Y., Tempich C. (2004b) OntoEdit Empowering SWAP: a Case Study
in Supporting DIstributed, Loosely-Controlled and evolvInG Engineering of
oNTologies (DILIGENT), ESWS 2004. pp. 16-30.
Pressman S., Roger. (2001) Software Engineering, A practitioners Approach. Fifth ed.
Thomas Casson.
Reed S.L., Lenat D.B. (2002) Mapping Ontologies into Cyc, AAAI 2002 Conference
Workshop on Ontologies For The Semantic Web, Edmonton, Canada.
Rubin D., Lewis S., Mungall C., Misra S., Westerfield M., Ashburner M., Sim I., Chute C.,
Solbrig H., Storey M., Smith B., Day-Richter J., Noy N., Musen M. (2006) National
Center for Biomedical Ontology: advancing biomedicine through structured
organization of scientific knowledge. OMICS 10:85-98.
Rubin D.L., Abreu Moreira d.D., Kanjamala P.P., Musen M.A. (2008) BioPortal: A Web
Portal to Biomedical Ontologies, AAAI Spring Symposium Series, Symbiotic
Relationships between Semantic Web and Knowledge Engineering, Stanford
University Press.
Schorlemmer W.M., Kalfoglou Y. (2008) Institutionalising ontology-based semantic
integration. Applied Ontology (AO) 3(3):131-150.
Schreiber G., Wielinga B., Breuker J. (1993) KADS: A Principled Approach to Knowledge-
Based System Development Academic Press Limited, San Diego, CA, USA.
Schulze-Kremer S. (1998) Ontologies for molecular biology, Pacific Symposioum on
Biocomputing pp. 693-704.
Serafini L., Tamilin A. (2004) Local tableaux for reasoning in distributed description logics.
Procs. of DL’04. CEUR-WS.
Serafini L., Borgida A., Tamilin A. (2005a) Aspects of distributed and modular ontology
reasoning. Procs. of IJCAI’05:570-575.
Serafini L., Borgida A., Tamilin A. (2005b) Aspects of Distributed and Modular Ontology
Reasoning, Proceedings of the Nineteenth International Joint Conference On Artificial
Intelligence (IJCAI-05), Edinburgh, Scotland. pp. 570-575.
Sirin E., Parsia B., Cuenca-Grau B., Kalyanpur A., Katz Y. (2007) Pellet: A practical OWL-
DL resoner. Journal of Web Semantics 5.
Smith B. (2004) Beyond Concepts: Ontology as Reality Representation, International
Conference on Formal Ontology and Information Systems, FOIS, Turin.
Smith B., Ashbourner M., Rosse C., Bard J., Bug W., Ceusters W., Goldberg L., Eilbeck K.,
Lewis S. (2007) The OBO Foundry: coordinated evolution of ontologies to support
biomedical data integration. Nature Biotechnology 25:1251-1255.
Sowa J.F. (2000) Knowledge Representation: Logical, Philosophical, and Computational
Foundation Brooks Cole Publishing, Pacific Grove, CA.
Spyns P., Tang Y., Meersman R. (2008) An ontology engineering methodology for DOGMA
Applied Ontology 3:13-39.

Stevens R., Gooble C., Bechhofer S. (2000) Ontology-based knowledge representation for
bioinformatics. Briefings in Bioinformatics:398-414.
Stoeckert C.J., Parkinson H. (2003) The MGED ontology: a framework for describing
functional genomics experiments. Comparative and Functional Genomics 4:127-132.
Stuckenschmidt H. (2003) Modularization of ontologies - wonderweb: Ontology
infrastructure for the semantic web, WonderWeb Project.
Suarez-Figueroa M., Dellschaft K., Montiel-Ponsoda E., Villazon-Terrazas B., Yufei Z.,
Aguado de Cea G., Garcia A., Fernandez-Lopez M., Gomez-Perez A., Espinoza M.,
Sabou M. (2008) NeOn Deliverable D5.4.1. NeOn Methodology for Building
Ontology Networks: Ontology Specification, http://www.neon-project.org.
Sure Y. (2003) Methodology, Tools & Case Studies for Ontology based Knowledge
Managment, Economy Sciences, Universitat Fridericiana zu Karlsruhe, Karlsruhe.
Swartout B., Ramesh P., Knight K., Russ T. (1997) Toward Distributed use of Large-Scale
Ontologies, Symposium on Ontological Engineering of AAAI, Stanford, California.
Swoogle.umbc.edu. (2008) Swoogle's Statistics of the Semantic Web.
Taylor C., Paton N., Lilley K., Binz P., Julian R.J., Jones A., Zhu W., Apweiler R., Aebersold
R., Deutsch E., Dunn M., Heck A., Leitner A., Macht M., Mann M., Martens L.,
Neubert T., Patterson S., Ping P., Seymour S., Souda P., Tsugita A., Vandekerckhove
J., Vondriska T., Whitelegge J., Wilkins M., Xenarios I., Yates J.r., Hermjakob H.
(2007 ) The minimum information about a proteomics experiment (MIAPE). Nature
Biotechnology 25:887-93.
Tempich C., Pinto S., Sure Y., Vrandecic D., Casellas N., Casanovas P. (2005) Evaluating
DILIGENT Ontology Engineering in a Legal Case Study, 22nd World Congress - Law
and Justice in a Global Society. pp. 330-331.
Tran T., Haase P., Motik B., Grau B.C., Horrocks I. (2008) Metalevel Information in
Ontology-Based Applications, AAAI-08, Chicago.
Tudorache T., Noy N. (2007) Collaborative Protege Social and Collaborative Construction of
Structured Knowledge, 16th International WWW Conference, Alberta, Canada.
Uschold M. (1996) Building Ontologies: Towards a Unified Methodology, 16th Annual Conf.
of British Computer Society Specialist Group on Expert Systems,, Cambridge, UK.
Uschold M., King M. (1995) Towards Methodology for Building Ontologies, Workshop on
Basic Ontological Issues in Knowledge Sharing, held in conjunction with IJCAI-95.,
Cambridge, UK.
Uschold M., Gruninger M. (1996) Ontologies: Principles, methods and applications.
Knowledge Engineering Review 11:93-136.
Uschold M., King M., Moralee S., Zorgios Y. (1998) The Enterprise Ontology. The
Knowledge Engineering Review 13.
Valente A., Russ T., McGregor R., Swartout B. (1999) Building and (Re)Using an Ontology
of Air Campaign Planning. IEEE Intelligent Systems & Their Applications.
Van Heijst G., Van der Spek R., Kruizinga E. (1996) Organizing Corporate Memories, in: B.
Gaines and M. Musen (Eds.), Tenth Knowledge Acquisition for Knowledge-Based
Systems Workshop (KAW’96), Banff, Canada. pp. 42.1–42.17.
Vrandecic D., Pinto H.S., Sure Y., Tempich C. (2005) The DILIGENT Knowledge Processes.
Journal of Knowledge Management 9:85-96.
W3C. (2007) Semantic Web Activity Statement, http://www.w3.org/2001/sw/Activity.

Wang T., Parsia B., Hendler J. (2006) A Survey of the Web Ontology Landscape,
International Semantic Web Conference, Springer, Heraklion, Greece. pp. 682-694.
Wang Y., Haase P., Bao J. (2007) A Survey of Formalisms for Modular Ontologies,
Proceedings of the SWeCKa Workshop at the 2007 International Joint Conference on
Artificial Intelligence (IJCAI'07), Hyderabad, India.
Wenger E. (1998) Commuities of practice. Learning, meaning, and identity Cambridge
University Press, Cambridge, UK.
Wenger E. (2000) Comunities of practice and social learning systems. Organization 7.
Wenger E., McDermott R., Snyder S. (2002) Cultivating communities of practice. A guide to
managing knowledge Harvard Business School Press, Boston.
Wierzbicka A. (1996) Semantics - Primes and Universals Oxford University Press, Oxford.
Zimmermann A. (2007) Integrated Distributed Description Logics. Proc. of the 20th
International Workshop on Description Logics DL’07. Bolzano University Press.
Zimmermann A., Euzenat J. (2006) Three Semantics for Distributed Systems and their
Relations with Alignment Composition. Proc. of 5th International Semantic Web
Conference (ISWC’06) 4273 of LNCS Springer:16-29.

Common Hyper-Ontological Frame - Work

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Common Hyper-Ontological Frame - Work

Uploaded by

Copyright:

Available Formats

Open architecture for Accessible Services

Integration and Standardization - G.A. 215754

OASIS – Open architecture for Accessible

OASIS common hyper-ontological frame-

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 1

Document Revision History D1.2.1

2009.06.30 D1.2.1-v1.doc: preliminary version as planned in the

2010.01.17 Initial Major Version (authors above): Now covers all

2010.01.31 Revised Draft finalised after QC feedback with

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 2

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 3

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 4

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 5

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 6

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 7

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 8

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 9

1.1 OASIS Objectives

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 10

! To clarify and share the structure of knowledge

1.1.2 Why methodology?

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 11

1.1.3 Why modular?

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

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 12

! in the application development phase:

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 13

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 14

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 15

1.1.4 Why communities?

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 16

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 17

1.2 Research Problem and Structure of the Deliverable

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 18

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 19

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 20

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 21

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

1.4 Innovations resulting from the activities reported in this deliverable

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 22

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 23

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 24

2 Evaluating ontology-engineering methodologies:

2.1 Introduction: learning from experience

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 25

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 26

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 27

active area of development in Geographic Information Science concerned with promoting

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 28

2.2 Methods and methodologies for building ontologies

2.2.1 Methodology review criteria

Within this deliverable we assume Schulze-Kremer's definition of an ontology as “a concise

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 29

2.2.2 Analysis of proposed methodologies: criteria definitions

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 30

evaluated via competency questions. Competency questions can typically be clas-

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 31

C3.3.3. Task ontologies: These describe vocabulary related to tasks, proc-

2.2.3 Analysis of proposed methodologies: criteria application

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 32

2.2.3.1 The Enterprise Methodology

UniBremen D1.2.1 – vers. 1.0 : RESTRICTED 33

Fig. 4. Uschold and King methodology