Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
OASIS – Open architecture for Accessible
Services Integration and Standardization
GRANT AGREEMENT # 215754
Ontologies, typologies, models and
management tools
Deliverable No.
D1.1.1
SubProject No.
SP1
SubProject Title
Open system reference
architecture, user
interfaces, platform and
tools
Workpackage No.
WP1.1
Workpackage Title
Benchmarking of
existing ontologies and
ontology management
tools
Activity No.
A1.1.4
Activity Title
Extraction of typologies
and models of
ontologies
Authors (per company, if more than
one company provide it together)
D. Kehagias, D. Kontotasiou, G. Mouratidis, T.
Nikolaou, I. Papadimitriou, K. Kalogirou (CERTH)., J.
Bateman, A. Garcia, I. Normann (UniBremen).
Status (F: final; D: draft; RD: revised RD
draft):
File Name:
OASIS Deliverable OASIS Deliverable
D1_1_1_version_4.5.doc
Project start date and duration
01 January 2008, 48 Months
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 1 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Document history
Version
Date
Comments
Author
1.0
26-05-2008
First draft.
05-06-2008
Second draft, integrating input
from all partners.
3.0
02-09-2008
4.0
05-06-2009
4.1UniBremen
18.6.-2009
4.2
22.6.2009
4.3
4.4
25.6.2009
14.7.2009
4.5
14.7.2009
New information about the
OASIS supported domains
ontologies have been added.
First revision after the 1st annual
project review. It addresses
most of reviewers’
recommendations.
Second revision after 1st annual
review, completing all
recommendations of reviewers
and filling in several remaining
gaps.
Overall review of the document.
Minor corrections. Several
additions with respect to
recommendations of reviewers.
Formatting issues.
Minor revisions.
Extensive review and
corrections of entire document.
Removal of change markers
(reconstruct with diff if required)
Minor corrections and
formatting.
Dionysios Kehagias,
Dionysia
Kontotasiou, G.
Mouratidis, T.
Nikolaou
Dionysios Kehagias,
Dionysia
Kontotasiou, Ioannis
Papadimitriou,
Kostas Kalogirou,
partners:
UniBremen, MIZAR,
ANCO, INFOTRIP,
LST-UPM
Dionysios Kehagias,
Dionysia
Kontotasiou,
Dionysios Kehagias,
Dionysia
Kontotasiou
2.0
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
John Bateman,
A. Garcia,
I. Normann.
D. Kehagias, D.
Kontotasiou
D. Kehagias
J. Bateman
D. Kehagias
PUBLIC
Page 2 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
List of Abbreviations
AI
CASL
DAML
DARPA
DL
DTD
HETS
HTML
KB
KIF
KR
KSL
OCML
OIL
OKBC
OWL
RDF
SHOE
XML
XSD
CERTH/ITI
14/07/2009
Artificial intelligence
Common Algebraic Specification Language
DARPA Agent Markup Language
Defense Advanced Research Projects Agency
Description Logic
Document Type Definition
Heterogeneous Tool Set
HyperText Markup Language
Knowledge Base
Knowledge Interchange Format
Knowledge Representation
Knowledge Systems Laboratory
Operational Conceptual Modelling Language
Ontology Inference Layer
Open Knowledge Base Connectivity
Web Ontology Language
Resource Description Framework
Simple HTML Ontology Extensions
Extensible Markup Language
XML Schema Definition
D1.1.1 – vers. 4.5
PUBLIC
Page 3 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Table of Contents
DOCUMENT HISTORY ........................................................................................... 2
LIST OF ABBREVIATIONS .................................................................................... 3
TABLE OF CONTENTS ........................................................................................... 4
LIST OF FIGURES .................................................................................................... 8
LIST OF TABLES ...................................................................................................... 9
EXECUTIVE SUMMARY ...................................................................................... 10
EXECUTIVE SUMMARY ...................................................................................... 10
1. INTRODUCTION .............................................................................................. 12
1.1.
1.2.
OASIS OBJECTIVES ..................................................................................... 13
DELIVERABLE STRUCTURE ........................................................................... 14
2. EXISTING ONTOLOGIES .............................................................................. 15
2.1.
GATHERING RELEVANT ONTOLOGIES .......................................................... 15
2.1.1. OASIS WP1.1 Ontologies Benchmarking Template ................................ 15
2.1.2. OASIS WP1.1 Ontologies Information Gathering Table ......................... 17
2.1.3. OASIS Database....................................................................................... 22
2.2.
NUTRITIONAL ADVISOR ONTOLOGIES .......................................................... 22
2.3.
ACTIVITY COACH ONTOLOGIES ................................................................... 23
2.4.
BRAIN AND SKILLS TRAINER ONTOLOGIES .................................................. 24
2.5.
SOCIAL RELATION AND RECREATION ONTOLOGIES ..................................... 24
2.6.
HEALTH MONITORING ONTOLOGIES ............................................................ 27
2.7.
ENVIROMENTAL CONTROL ONTOLOGIES ..................................................... 32
2.8.
TRANSPORT INFORMATION ONTOLOGIES ..................................................... 33
2.9.
ROUTE GUIDANCE ONTOLOGIES .................................................................. 34
2.10. PERSONAL MOBILITY ONTOLOGIES .............................................................. 35
2.11. SMART WORKPLACES .................................................................................. 37
2.12. OTHER AREAS .............................................................................................. 37
2.13. INTERIM CONCLUSIONS: CONSEQUENCES FOR OASIS .................................. 38
3. DESCRIPTION OF METHODOLOGIES AND METHODS FOR
BUILDING ONTOLOGIES FROM SCRATCH .................................................. 39
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
3.8.
3.9.
3.10.
3.11.
3.12.
CERTH/ITI
14/07/2009
EVALUATION FRAMEWORK FOR METHODOLOGIES AND METHODS .............. 39
CYC METHOD ............................................................................................... 39
USCHOLD AND KING’S METHOD : ENTERPRISE ........................................ 40
GRÜNINGER AND FOX’S METHODOLOGY ...................................................... 40
KACTUS METHOD....................................................................................... 40
METHONTOLOGY ................................................................................... 41
SENSUS METHOD ........................................................................................ 41
COMMONKADS ............................................................................................ 42
ON-TO-KNOWLEDGE METHODOLOGY : OTK .............................................. 42
RAPID ONTOLOGY DEVELOPMENT : ROD .................................................... 43
HOLSAPPLE METHODOLOGY ........................................................................ 43
DOGMA APPROACH ................................................................................... 44
D1.1.1 – vers. 4.5
PUBLIC
Page 4 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
3.13.
3.14.
3.15.
3.16.
3.17.
3.18.
3.19.
3.20.
3.21.
DILIGENT METHODOLOGY ........................................................................... 44
HCOME ...................................................................................................... 44
UPON APPROACH ........................................................................................ 45
CONSENSUS-BASED ONTOLOGY ENGINEERING APPROACH ......................... 46
GM METHODOLOGY .................................................................................... 46
ICAPTURER METHODOLOGY......................................................................... 46
NEON METHODOLOGY ................................................................................. 46
MELTING POINT METHODOLOGY ................................................................ 46
CONCLUSIONS .............................................................................................. 47
4. TYPOLOGY FOR THE CHARACTERISATION OF
ONTOLOGIES ......................................................................................................... 54
4.1.
EVALUATION METRICS FOR ONTOLOGIES .................................................... 54
4.1.1. Internal: Lexical / Vocabulary layer........................................................ 55
4.1.2. Internal: Structural / architectural layer ................................................. 55
4.1.3. Internal: Representational / semantic layer ............................................ 56
4.1.4. Internal: Data / Application layer ........................................................... 56
4.1.5. Internal: Philosophical layer ................................................................... 57
4.1.6. External: Usability layer.......................................................................... 57
4.2.
METRICS AND THEIR SUPPORT BY LANGUAGES AND TOOLS .......................... 58
Internal: Lexical / Vocabulary layer ..................................................................... 58
Internal: Structural / architectural layer .............................................................. 58
Internal: Representational / semantic layer .......................................................... 59
Internal: Data / Application layer ......................................................................... 59
Internal: Philosophical layer ................................................................................ 59
External: Usability layer ....................................................................................... 59
4.3.
OASIS METHODOLOGICAL APPROACH FOR ONTOLOGY EVALUATION AND
REFINEMENT BASED ON ARCHITECTURAL AND DESIGN ASPECTS ............................... 59
4.3.1. Introduction.............................................................................................. 59
4.3.2. Reusing Existing Candidate Ontologies .................................................. 60
4.3.3. General Restructuring Issues ................................................................... 60
4.3.4. More Specific Comments and Suggestions on Restructuring .................. 62
4.4.
A CASE STUDY EXAMPLE: RESTRUCTURING THE ASK-IT ONTOLOGIES ..... 63
4.4.1. The ASK-IT Ontologies ............................................................................ 63
4.4.2. The Refinement/Improvement Process ..................................................... 64
4.5.
CONCLUSIONS .............................................................................................. 80
5. ONTOLOGY LANGUAGES ............................................................................ 81
5.1.
FIRST GENERATION ONTOLOGY LANGUAGES .............................................. 81
5.1.1. KIF and Ontolingua ................................................................................. 81
5.1.2. Loom ........................................................................................................ 81
5.1.3. PowerLoom .............................................................................................. 82
5.1.4. OCML ...................................................................................................... 82
5.1.5. F-Logic ..................................................................................................... 82
5.1.6. OKBC ....................................................................................................... 82
5.1.7. SHOE ....................................................................................................... 83
5.2.
XML-BASED ONTOLOGY LANGUAGES ........................................................ 83
5.2.1. XOL .......................................................................................................... 83
5.2.2. DAML + OIL............................................................................................ 83
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 5 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
5.2.3. RDF .......................................................................................................... 83
5.2.4. OWL ......................................................................................................... 89
5.2.5. RacerPro .................................................................................................. 95
5.3.
THE HETEROGENEOUS TOOL SET ................................................................. 95
5.4.
ONTOLOGY QUERY LANGUAGES .................................................................. 96
5.4.1. nRQL and Racer ...................................................................................... 96
5.4.2. OWL-QL ................................................................................................... 96
5.4.3. RDQL ....................................................................................................... 97
5.4.4. Vampire .................................................................................................... 97
5.4.5. SPARQL ................................................................................................... 98
5.4.6. WSDL ....................................................................................................... 98
5.5.
ATTRIBUTE-FREE APPROACHES .................................................................... 98
6. OPEN SOURCE ONTOLOGY TOOLS ........................................................ 100
6.1.
EVALUATION FRAMEWORK USED TO COMPARE THE TOOLS ........................ 100
6.2.
PROTÉGÉ 4.0 .............................................................................................. 101
6.2.1. Main Features ........................................................................................ 101
6.3.
BIOPORTAL ................................................................................................ 111
6.4.
OILED ........................................................................................................ 112
6.5.
APOLLO ...................................................................................................... 113
6.6.
RDFEDT ..................................................................................................... 114
6.7.
ONTOLINGUA ............................................................................................. 115
6.8.
ONTOEDIT .................................................................................................. 116
6.9.
WEBODE ................................................................................................... 118
6.10. KAON ....................................................................................................... 120
6.11. ICOM ........................................................................................................ 121
6.12. DOE (DIFFERENTIAL ONTOLOGY EDITOR) ................................................ 123
6.13. WEBONTO .................................................................................................. 125
6.14. ONTOWIKI ................................................................................................. 126
6.15. ISAVIZ ........................................................................................................ 127
6.16. HOZO ........................................................................................................ 128
6.17. GROWL ..................................................................................................... 129
6.18. SEMANTIC WIKIS........................................................................................ 129
6.19. SWOOP ..................................................................................................... 130
6.20. COMPARISON OF TOOLS AGAINST THE EVALUATION FRAMEWORK ............. 131
7. REASONERS ................................................................................................... 136
7.1.
DESCRIPTION LOGIC REASONERS ............................................................... 136
7.1.1. FaCT++ ................................................................................................. 138
7.1.2. RacerPro ................................................................................................ 139
7.1.3. Pellet ...................................................................................................... 141
7.1.4. KAON2 ................................................................................................... 144
7.1.5. CEL ........................................................................................................ 145
7.1.6. Cerebra Engine ...................................................................................... 145
7.1.7. FuzzyDL ................................................................................................. 145
7.1.8. QuOnto ................................................................................................... 146
7.2.
DESCRIPTION LOGIC REASONERS WHICH ARE NO LONGER ACTIVELY
SUPPORTED .............................................................................................................. 146
7.2.1. Classic .................................................................................................... 146
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 6 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
7.2.2. Loom ...................................................................................................... 146
7.3.
RULE ENGINES ........................................................................................... 146
7.3.1. Jess ......................................................................................................... 146
7.3.2. XSB ......................................................................................................... 147
7.3.3. CWM ...................................................................................................... 147
7.3.4. RuleML Engine ...................................................................................... 147
8. CONCLUSIONS............................................................................................... 148
REFERENCES ........................................................................................................ 150
ANNEX 1 – TOOLS AND ASSOCIATED PROJECTS ..................................... 156
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 7 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
List of Figures
Figure 1: Social Relation and Community Building Related Taxonomy .................... 25
Figure 2: Personal Support Services Related Taxonomy ............................................ 36
Figure 3: Tourism and Leisure Ontology..................................................................... 36
Figure 4: Methodology Structure ................................................................................. 40
Figure 5: Grüninger and Fox’s methodology............................................................... 41
Figure 6: Development process and life cycle of METHONTOLOGY ...................... 42
Figure 7: SENSUS Approach ...................................................................................... 42
Figure 8: ROD Framework .......................................................................................... 43
Figure 9: Roles and functions in distributed ontology engineering ............................. 45
Figure 10: A visualization of the different dimensions of ontology classification ...... 54
Figure 11: Examples of concept hierarchy/taxonomy restructuring ............................ 65
Figure 12: Example of equal domain properties restructuring .................................... 67
Figure 13: Examples of eliminating duplicates and merging similar definitions ........ 72
Figure 14: Examples of improving ontology documentation ...................................... 73
Figure 15: Examples of range definition for object properties .................................... 73
Figure 16: Examples where disjointness condition holds or not ................................. 74
Figure 17: Examples of satisfying naming conventions .............................................. 75
Figure 18: An Example RDF Description ................................................................... 84
Figure 19: Graph representation of the example RDF Description in Figure 18......... 85
Figure 20: An example RDF Description illustrating the use of Containers ............... 86
Figure 21: An example of “making Statements about Statements” ............................. 87
Figure 22: An example description illustrating the use of SubClassOf Property ........ 88
Figure 23: Domain and Range Constraints in RDF description .................................. 89
Figure 24: HETS architecture ...................................................................................... 96
Figure 25: Protégé screenshot .................................................................................... 101
Figure 26: OWL Viz plug-in...................................................................................... 103
Figure 27: DL-Query Tab .......................................................................................... 103
Figure 28: Object Property Description Table ........................................................... 104
Figure 29: Matrix Views ............................................................................................ 104
Figure 30: Cardinality View ...................................................................................... 105
Figure 31: Existential Tree......................................................................................... 105
Figure 32: Excel Importer .......................................................................................... 106
Figure 33: Bookmarks................................................................................................ 107
Figure 34: Taxonomy Cut-Paste ................................................................................ 107
Figure 35: The Protégé Nerd...................................................................................... 108
Figure 36: TerMine plug-in ...................................................................................... 109
Figure 37: OWL Lint ................................................................................................. 109
Figure 38: Annotation Search View ......................................................................... 110
Figure 39: Alternative Annotation View ................................................................... 110
Figure 40: Change View ............................................................................................ 111
Figure 41: OilEd screenshot....................................................................................... 112
Figure 42: Main window with loaded ontology in Apollo ........................................ 113
Figure 43: RDFedt screenshot ................................................................................... 115
Figure 44: Screenshot of ontology creation in Ontolingua ........................................ 116
Figure 45: OntoEdit screenshot ................................................................................. 117
Figure 46: WebODE ontology editor ......................................................................... 119
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 8 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Figure 47: KAON Tool screenshot ............................................................................ 121
Figure 48: ICOM screenshot ...................................................................................... 122
Figure 49: ICOM screenshot ...................................................................................... 123
Figure 50: DOE screenshot ........................................................................................ 124
Figure 51: Interoperabitily using RDFS and OWL.................................................... 125
Figure 52: WebOnto screenshot................................................................................. 126
Figure 53: Ontowiki Ontology Editor ........................................................................ 127
Figure 54: IsaViz Ontology Editor ............................................................................ 128
Figure 55: Architecture of Description Logic ............................................................ 136
Figure 56: Pellet architecture ..................................................................................... 143
Figure 57: Kaon2 architecture ................................................................................... 144
List of Tables
Table 1: Approaches' proposed ontology development process .................................. 50
Table 2: Approaches' proposed ontology development process .................................. 51
Table 3: Evaluation metrics supported by Methodologies .......................................... 52
Table 4: Evaluation metrics supported by Methodologies .......................................... 53
Table 5: OWL code for the first example of Figure 11 ............................................... 66
Table 6: OWL code for properties restructuring of Figure 12 ..................................... 69
Table 7: Examples of similar ontological concepts repetition ..................................... 70
Table 8: Rewriting in CASL the classes of Table 7..................................................... 71
Table 9: OWL code for documenting class “Accommodation” of Figure 14 ............ 73
Table 10: OWL code for disjoint concepts of Figure 16 ............................................. 74
Table 11: General Restructuring Issues on Classes ..................................................... 76
Table 12: General Restructuring Issues on Properties ................................................. 77
Table 13: Concept/Hierarchy Restructuring Issues ..................................................... 78
Table 14: Specific Restructuring Issues ....................................................................... 79
Table 15: Recommended XML Schema Data types .................................................... 94
Table 16: Tools’ Architecture .................................................................................... 133
Table 17: Tools' interoperability ................................................................................ 133
Table 18: Tools' inference services ............................................................................ 134
Table 19: Tools' usability ........................................................................................... 134
Table 20: Overview of Tools' versioning and collaborative work support ................ 135
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 9 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
EXECUTIVE SUMMARY
The goal of this deliverable ("Ontologies, typologies, models and management tools")
is to identify all possible existing ontologies and ontology management tools that are
freely available and review them in terms of: a) interoperability, b) openness, c)
easiness to update and maintain, d) market status and penetration. The results of the
review in ontologies are analyzed for each application area, such as transport, tourism,
personal services, domotics, health services, social services, natural languages and
other HCI-related domains.
This revision of the deliverable contains additional material that concerns issues of
methodology for ontology development, tool support for cooperative work, and
versioning issues, as well as establishing relations between evaluation metrics,
methodologies and tool support. In the original version this information was placed
within internal project deliverables and so was less visible. This has now been
corrected. The total work effort contributing to this deliverable can now also be seen
more clearly, as this was previously only documented in relation to internal
deliverables and not to this document and its associated activity as a whole.
Ontology management tools are used by different groups of people for performing
diverse tasks. Although each tool provides different functionalities, most of the users
just use only one, because they are not able to interchange their ontologies from one
tool to another. A major part of the review was to examine interoperability, i.e., the
ability of given ontological organisations to be used for different applications. In
addition, we considered the compatibility of different ontologies with different
development and management tools. We explicitly consider the functionalities offered
by distinct tools in order to isolate features useful for OASIS. Special attention was
given to the special needs of elderly people and ontologies that might support such
applications appropriate for the elderly. An ongoing goal of the OASIS ontology
initiative is to support the ready addition of features appropriate for applications for
the elderly as identified in WP2.1, WP3.1 and WP5.5 (ontology updates).
This deliverable also concerns the detection of commonalities and differences
between the examined ontologies, both on the same domain (application area) and
among different domains. More specifically, during and after the finalization of
A1.1.2, the set of candidate ontologies was examined in a semi-automatic (automatic
parsing and custom tests by experts) manner for common concepts in order to isolate
fragments that may be used within the OASIS hyper-ontology within WP1.2. As part
of this activity some extensions were already made to existing ontologies with a view
to supporting elderly-specific functionalities.
Finally, this activity set out a generic typology of ontologies that characterises any
ontology along two sets of dimensions: the first building on concepts discussed in
previous EU projects, involving 'basic ontological distinctions', such as parthood,
connection, constitution, dependence, participation, unity, and causation (e.g.
WonderWeb), and the second bringing in architectural and design issues, such as:
formal-informal, structured-unstructured, richly expressive-less richly expressive
(e.g., NeOn).
The OASIS innovative contributions are summarized below:
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 10 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754





Selection of a set of existing ontologies for each application domain (transport,
tourism, social services, etc) after thorough testing and evaluation, so as to
inform the definition of the OASIS Hyper Ontology undertaken in WP1.2.
Evaluation of ontology management tools, in terms of modularity and
reusability.
Definition of suitable metrics, in order to review and analyze ontologies and
tools for managing them in terms of practical aspects, such as usability and
accessibility (not only performance).
Spotting commonalities and differences between ontologies not only on the
same domain but in various application areas, in order to assist creating a
mechanism for combining concepts with the aid of the OASIS Hyper
Ontology and to provide re-usable fragments for the hyper-ontology.
Definition of a generic typology of formal ontology properties that can
characterise any ontology with specific detail support for OASIS-relevant
domains.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 11 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
1. Introduction
Ontologies have recently received popularity in the area of knowledge management
and knowledge sharing, especially after the evolution of the Semantic Web and its
supporting technologies. An ontology defines the terms and concepts (meaning) used
to describe and represent an area of knowledge. It may be conceived as an explicit
specification of a conceptualization that includes a set of objects, their properties and
their values along with the describable relationships among them, reflected in a
representational vocabulary with which a knowledge-based program represents
knowledge.
One use of ontologies is to externalize a model and make it easier for business
applications to share and / or reuse knowledge and improve information navigation
and search by using reasoning. Furthermore, the externalization of models facilitates
customization of an application without modifying code. In ontologies, class
definitions and formal axioms are provided that constrain the interpretation and wellformed use of these terms; in addition, definitions may associate the names of entities
in the universe of discourse (e.g., classes, relations, functions, or other objects) with
human-readable text describing what the names mean. Formally, ontologies are the
statement of a logical theory.
The aspects of ontology development and engineering that relevant when constructing
ontologies for applications then include:





Ontology Description Languages, to introduce formal means for representing
ontologies and their attributes.
Ontology Authoring Tools to enable the creation and development and storing
of new ontologies and the modification, editing and refinement of existing
ones.
Ontology development methodologies, to guarantee effective development and
deployment.
Ontology Reasoners to infer information that is not explicitly contained within
ontologies.
Java technologies to enable interoperability between Java applications and
formal ontology description standards, in the form of APIs or tools that
support automatic Java code generation.
As far as the available ontology description languages are concerned, the W3C
(http://www.w3c.org) recommends a number of specifications. These will clearly play
a special role in OASIS due to their widespread adoption. Here specifically, XML
provides a surface syntax for structured documents, but imposes no semantic
constraints on the meaning of these documents. XML Schema is a language for
restricting the structure of XML documents. RDF (Resource Description Framework)
is a language for creating a data model for objects (or "resources") and relations
among them, providing a simple semantics for the data model. The data models are
represented in XML syntax. RDF Schema is a vocabulary for describing properties
and classes of RDF resources, with semantics for generalization hierarchies of such
properties and classes. Finally, OWL (Web Ontology Language) adds more
vocabulary for describing properties and classes, as well as relations among classes,
cardinality, equality, richer typing of properties, and enumerated classes. OWL
succeeds the preceding effort of DAML+OIL in this area. In summary, OWL adds
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 12 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
facilities for expressing meaning and semantics to XML, RDF, and RDF Schema, and
thus it goes beyond these languages in its ability to represent machine-readable
content.
An important issue about ontology-related technologies is the existence of suitable
integrated authoring tools for the creation, development and editing of ontologies. A
large number of such tools have been developed lately that support various input and
output formats with similar or different attributes. In this report the most popular and
accepted ontology authoring tools are presented and comparatively evaluated.
Finally, in addition to the specifications for ontology description languages supported
by the W3C, there are further languages and technologies which are also useful for
ontology development and which the OASIS project will monitor and include as
proves useful. These include OCML and DCMI, while the Unified Modelling
Language (UML) has also been proposed as a means for describing ontologies.
Moreover, there are an increasing range of applications where expressivity beyond
that offered by OWL is required. Here also this deliverable considers the most
prominent proposals available and their tool support.
1.1.
OASIS Objectives
The overall aim of OASIS is to develop an open and innovative reference
architecture, based upon ontologies and semantic services, that will allow plug and
play and cost-effective interconnection of existing and new services in all domains
required for the independent and autonomous living of the elderly and their Quality of
Life enhancement. Both the open reference architecture and the related tools will be
made available as open source.
Within SP1, the innovative new reference architecture is built (called COF: Common
Ontological Framework), together with the key tools for its application, such as the
ontology application GUI and content connection tools, the necessary AMI
framework and agents, the HCI interaction prototyping tool for UI self-adaptation and
personalisation and, finally, the instantiation of the overall architecture to the project
applications. The reference architecture and tools will all be made available as open
source for maximal impact on development practice.
Within WP1.1 currently available ontologies and comparable methods, relevant for
OASIS application scenarios, are firstly extensively benchmarked and used as a
requirements specification for the new OASIS architecture. Recent work in the
ontological engineering community (Ontology Summit)1 has produced a preliminary
classification of ontologies along the following dimensions: 1. Expressiveness, 2.
Structure, 3. Granularity, 4. Intended Use, 5. Automated Reasoning, 6. Prescriptive
vs. Descriptive, 7. Governance. Moreover, recent work on methodologies for ontology
development has moved the state of the art considerably; this is also documented from
the OASIS perspective here.
Thus, this deliverable aims:
 To select a set of existing ontologies for each application domain (transport,
tourism, social services, etc) after thorough testing and evaluation, so as to
inform the definition of the OASIS Hyper Ontology.
1
http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2007
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 13 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754


To evaluate interfaces of ontology management tools, in terms their support
for modularity, reusability and development.
To benchmark the interoperability of ontology management tools.
From this benchmarking activity, clear areas of necessary development for the future
state of the art in ontology development and methodology can be isolated. In
particular, there are requirements for new tools and capabilities, both in terms of the
development process and the formal expressiveness of the languages used for
constructing ontologies. The subsequent work of the OASIS project will move
towards providing these missing functionalities and thereby achieve a significant
advance in the state of the art. The OASIS-specific solutions building on the
recommendations and evaluations produced here feed directly into the design of the
OASIS common ontological framework, which is addressed in detail in Deliverable
D1.2.1.
Particularly important in ontology work at this time is pro-active design. The state of
the art in ontology engineering is moving so rapidly that there has been considerable
change in the tools available and theoretical foundations even over the time that this
document has been in preparation. The state documented here is that mid-2009,
although some of the tools presented have now already fallen into disuse. A primary
function of the deliverable is therefore to provide the highwater mark at the current
time that groups together the state of the art in the individual ontologies, in ontology
methodology, in ontology tools and in ontology evaluation metrics, which together
form the starting point that is being taken further in the design of the OASIS hyperontology and its supporting COF. On the basis of this, and particularly as part of the
activities in WP1.2, contact has been made with the main ontology tool developer
stakeholders (e.g, Protégé and BioPortal) in order to harmonise development. Further
contacts are being established within WP1.2.
1.2.
Deliverable Structure
The deliverable is organized as follows:

In Chapter 2, the existing ontologies are presented.

Chapter 3 provides a description of methodologies and methods for building
ontologies

Chapter 4 provides a typology for the characterisation of ontologies.

Chapter 5 presents the existing ontology languages.

Chapter 6 provides an analytical description of the open source authoring tools
and investigates their functionalities with respect to those that may be useful for
OASIS ontology development.

Chapter 7 introduces a survey on different kinds of existing reasoner
implementations that can be used for reasoning ontologies.

Finally, in Chapter 8, conclusions are drawn for this deliverable.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 14 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
2. Existing Ontologies
2.1. Gathering Relevant Ontologies
The objective of this chapter is to do a state-of-the-art survey of existing ontologies in
the corresponding OASIS domains (nutritional, activity coach, brain and skills trainer,
social relation…). For the purpose of this deliverable it is adequate to have a
representative list of existing ontologies about each specific domain. Our intention is
not to present an exhaustive list of ontologies, but a representative one.
2.1.1.
OASIS WP1.1 Ontologies Benchmarking Template
In order to collect information on existing ontologies form the project partners, a
purpose-specific benchmarking template was created and sent around the OASIS
mailing list on June 30, 2008. This template covered all application domains
supported in OASIS areas and was filled in from all SP2 and SP3 partners. The main
source of information was the Internet. However if partners had access to information
about any relevant ontologies stored in any repository they were asked to include
them as well. Each partner was asked to retrieve (or search for) relevant ontologies in
their respective areas of expertise. Specific ontology-oriented (or semantic) search
engines (e.g. Swoogle) have been also used for this purpose. This provides a database
of potential resources for consideration and evaluation in WP1.2 as contenders for
inclusion within the OASIS hyper-ontology.
A set of filled-in templates provided by UPM that describe ontologies in
the "nutritional advisor" and "health monitoring" domains was used as a template for
each partner. Below, we present the blank Ontologies Benchmarking Template:
Please fill the following questions (1-13) for each relevant ontology that will be included in chapter 2
of OASIS Deliverable 1.1.1.
A. General questions
1. Relevant area (tick as appropriate):
 NUTRITIONAL ADVISOR ONTOLOGIES
 ACTIVITY COACH ONTOLOGIES
 BRAIN AND SKILLS TRAINER ONTOLOGIES
 SOCIAL RELATION AND RECREATION ONTOLOGIES
 HEALTH MONITORING ONTOLOGIES
 ENVIRONMENTAL CONTROL ONTOLOGIES
 TRANSPORT INFORMATION ONTOLOGIES
 ROUTE GUIDANCE ONTOLOGIES
 PERSONAL MOBILITY ONTOLOGIES
 SMART WORKPLACES
 Other areas (describe): habitat, person, equipment, tasks, and behaviour
2. Is the existing ontology designed for a service or project?
 Service
 Project
3. Name of service/project:
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 15 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
B. Technical questions
1.
WSDL URL:
………………………………………………………………………………………………………
………………………………………………………………………
2.
UDDI server publication:
………………………………………………………………………………………………………
………………………………………………………………………
3.
Existing Ontologies:
4.
Public availability:
5.
Ontology Representation Languages:
6.
Number of Concepts:
7.
Number of Relationships:
8.
Structure Consistency:
9.
Ontology Standardization Bodies:
Yes
 No
10. Web Service Standards:
11. Specification of ontology communication interface
12. Ontology Documentation:
13. Most Common Ontology Metrics

Syntax
o
syntactic correctness (automatic checkers available?):
o
Yes  No
breadth of syntax used (restricted formalism?):
Yes
 No
If yes, add details: ………………………………………………...…….
…………………………………………………………………………..

Governance
o
Are the terms regulated by a government body, international standard, etc.?
Yes
 No
If yes, add details: ………………………………………………………….
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 16 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
……………………………………………………………………………...

Modularization (what modules are defined? How are they defined? How is re-use,
import, export of modules regulated, if at all?)

Explicit relation to existing upper level ontologies or ontological modules?
Yes
 No
If yes, add details: ………………………………………………………….
……………………………………………………………………………...

Explicit relation to existing general lexical resources (e.g., WordNet, etc.) or existing
application/domain-specific terminologies.
Yes
 No
If yes, add details: ………………………………………………………….
……………………………………………………………………………...
Where technical questions could not be answered by partners, these gaps were then
flagged as open issues should the ontologies be considered formally according to the
formal OASIS COF-evaluation metrics proposed below.
The ontologies that were finally assembled from the various domains are described
analytically in Sections 2.1.3-2.12.
2.1.2.
OASIS WP1.1 Ontologies Information Gathering Table
Also, CERTH-ITI distributed the “Ontologies Information Gathering Table” in the
form of an excel worksheet, whose purpose was to collect information about which
partner is related to which domains among the supported ones. The information
provided by each partner was:



The application domains of OASIS that are related to each partner.
The OASIS subprojects in which the partner participates.
Contact information of each partner.
Each partner could look up this worksheet to see those partners who are related to
each application domain in order to contact them for information, if needed. Below,
we present the completed Ontologies Information Gathering Table:
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 17 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Partner: MIZAR
Application Domain
1. Nutritional Advisor Ontologies
2. Activity Coach Ontologies
3. Brain and Skills Trainer Ontologies
4. Social Relation and Recreation Ontologies
5. Health Monitoring Ontologies
6. Enviromental Control Ontologies
7. Transport Inforamtion Ontologies
8. Route Guidance Ontologies
9. Personal Mobility Ontologies
10. Smart Workplaces
PHILIPS CERTH/HIT CERTH/ITI ITACA
PTV
AGE SIEMENS VODAFONE
X
X
X
X
X
X
X
X
X
X
X
X
11. Other (please specify)
SP
SP1
SP2
SP3
SP4
SP5
Contact Person
CERTH/ITI
14/07/2009
X
X
X
X
X
X
X
X
X
Monica
Raimondi,
email:monica
.raimondi@ Silvio Bonfiglio Kostas
Dionysis
verona.miz.i silvio.bonfiglio Kalogirou,
Kehagias,
t
@philips.com [email protected] [email protected]
D1.1.1 – vers. 4.5
Ma Pilar
Sala
msalaso@u
pvnet.upv.e
s
PUBLIC
Page 18 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Partner: MOTOROLA
Application Domain
1. Nutritional Advisor Ontologies
2. Activity Coach Ontologies
3. Brain and Skills Trainer Ontologies
4. Social Relation and Recreation Ontologies
5. Health Monitoring Ontologies
6. Enviromental Control Ontologies
7. Transport Inforamtion Ontologies
8. Route Guidance Ontologies
9. Personal Mobility Ontologies
10. Smart Workplaces
POLIS
CRF
FhG/IESE FhG/IAO FhG/IIS UniBremen UNEW
SILO
X
X
X
X
11. Other (please specify)
SP
SP1
SP2
SP3
SP4
SP5
X
X
X
X
Jan-Paul
Leuteritz.
Matthias
Email: jan- Struck
paul.leuterit Matthias.Str
[email protected] [email protected]
hofer.de
unhofer.de
Contact Person
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
stelios
Pantelopoul
os,
spantelopou
los@singula
rlogic.eu
PUBLIC
Page 19 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Partner:
Application Domain
1. Nutritional Advisor Ontologies
2. Activity Coach Ontologies
3. Brain and Skills Trainer Ontologies
4. Social Relation and Recreation Ontologies
5. Health Monitoring Ontologies
6. Enviromental Control Ontologies
7. Transport Inforamtion Ontologies
8. Route Guidance Ontologies
9. Personal Mobility Ontologies
10. Smart Workplaces
DML
ANCO
FORTH
MCA
CONNCEPT
SWISS
eWORX UNIPI INFOTRIP
X
X
X
X
11. Other (please specify)
CERTH/ITI
14/07/2009
X
X
X
X
SP
SP1
SP2
SP3
SP4
SP5
Contact Person
ATAF
X
X
Miltos
Anastasiadis,
[email protected]
Chris
Condos,
[email protected]
D1.1.1 – vers. 4.5
kandreadou@i G.Ambrosino(a
nfotrip.gr,
mbrosino@ata
vmizaras@tre f.fi.it),
dit.gr,
C.Binazzi
tpachinis@info ([email protected]
trip.gr
i.it)
PUBLIC
Page 20 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Partner: ATCROM
Application Domain
1. Nutritional Advisor Ontologies
2. Activity Coach Ontologies
3. Brain and Skills Trainer Ontologies
4. Social Relation and Recreation Ontologies
5. Health Monitoring Ontologies
6. Enviromental Control Ontologies
7. Transport Inforamtion Ontologies
8. Route Guidance Ontologies
9. Personal Mobility Ontologies
10. Smart Workplaces
CTAG
NETSMART
ITESM
TU
LSTUPM INNOVALIA WKK MULTITEL
X
X
X
X
X
X
X
X
X
11. Other (please specify)
SP
SP1
SP2
SP3
SP4
SP5
Contact Person
CERTH/ITI
14/07/2009
X
X
X
X
X
X
X
X
Jordi
Contreras,
jordi.contreras
@ctag.com
Viveca
Jiménez
D1.1.1 – vers. 4.5
Cristina de la
Maza
cmaza@innoval
ia.org
deketelaere@mu
ltitel.be
PUBLIC
Page 21 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
2.1.3.
OASIS Database
In parallel with our data collection process, SP2 partners carried out a thorough investigation
on the relevant technological aids, systems and services able to support independent living, as
well as the lack or existence of relevant ontologies in the different domains. A similar
benchmarking ran in parallel in the Autonomous Mobility and Smart Workplaces area (SP3
Partners), and therefore, a common template was defined including all the relevant
information for both of them.
As a result of all these activities, an online database has been implemented to facilitate the
compilation of information and analysis of all existing products, services and research
projects in the area of Independent Living Applications and Smart Workplaces that are
indenteded for the elderly and disabled. The database interface was constructed over MS SQL
Server 2005. It can be accessed through the project web site (www.oasis-project.eu), and it
can be considered as an active tool, where the user is able not only to search on-line for
entities that he/she is interested in, but also to insert new ones. In other words, the “edit” and
“search” functions are supported.
The methodology used to define the template and the implementations of the database, as well
as a summary of the findings per domain are described in detail in deliverables D2.1.1 and
D3.1.1. This database contains also some fields with ontology-related information. Hence we
can use the information that is coded in the database in a two-fold way. On the one hand the
information that is relevant for ontologies can be retrieved and related to the requirements of
the OASIS ontology methodology, and be consulted when considering extensions. We can
also report on the devices and other products that are appropriate for elderly people that may
need to be incorporated in the OASIS ontologies.
Products, services and research projects that are related to the ontology requirements of
OASIS and which can be found in the database include at present the following:

OneSite Platform

IN-SAFETY

COCOON

EMERGE

PALETTE
These are described in detail in Sections 2.2-2.12 as appropriate.
2.2. Nutritional Advisor Ontologies
As it already mentioned in the DoW, OASIS can benefit from the results of the PIPS project
[66]. This project was focused on the development of a platform of services for health and
life, including domains such as nutrition or physical activity. These nutrition services are built
upon an ontology that includes nutritional facts and models concepts such as diet, menu, food,
calories, etc. It was designed based on existing well-known standards in nutrition such as
Eurocode22, GPC (Global Product Classification), UNSPSC (United Nations Standard
Products and Services Code), and contributions from experts in the domain such as the
University of Parma or the Foundation for the Nutritional Research from Barcelona. OASIS
will evaluate, adopt and extend these results in order to enable integration with the rest of the
project service ontologies.
2
http://www.eurocode2.info/main.asp?page=0
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 22 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
The aim of Food Ontology is to represent an abstract model of the different types of foods
available to the PIPS users, together with their nutritional information, including the type and
amount of nutrients, and the recommended daily intake. The most recent version of the OWL
ontology can be downloaded from http://www.csc.liv.ac.uk/_jcantais/PIPSFood.owl. The
Food ontology described above has a total of 177 classes, 53 properties and 632 instances.
The ontology is represented in OWL-DL. Disjointness and cardinality constraints, as well as
functional properties are defined.
Moreover, OASIS can describe the Nutritional Advisor domain by means of appropriate
terms derived from ontology–like vocabularies such as “Langual”. LanguaL3 stands for
"Langua aLimentaria" or "language of food". It is an automated method for describing,
capturing and retrieving data about food. The thesaurus provides a standardised language for
describing foods, specifically for classifying food products for information retrieval. LanguaL
is based on the concept that: Any food (or food product) can be systematically described by a
combination of characteristics. These characteristics can be categorised into viewpoints and
coded for computer processing. The resulting viewpoint/characteristic codes can be used to
retrieve data about the food from external databases.
LanguaL is a multilingual thesaural system using facetted classification. Each food is
described by a set of standard, controlled terms chosen from facets characteristic of the
nutritional and/or hygienic quality of a food, as for example the biological origin, the methods
of cooking and conservation, and technological treatments.
LanguaL facilitates links to many different food data banks and contributes to coherent data
exchange. LanguaL is the only generally recognised method in common use for describing,
capturing and retrieving data about food, adapted to computerised national and international
food composition and consumption databanks. The following groups of concepts are defined
in the LanguaL Thesaurus:
 Product Type
 Food Source
 Part of Plant or Animal
 Physical State, Shape or Form
 Extent of Heat Treatment
 Cooking Method
 Treatment Applied
 Preservation Method
 Packing Medium
 Container or Wrapping
 Food Contact Surface
 Consumer Group/Dietary Use/Label Claim
 Geographic Places and Regions
 Adjunct Characteristics of Food
2.3. Activity Coach Ontologies
Few efforts have been devoted so far to develop ontologies in this domain, the most notable
being the one of Smart Home for People in Loss of Cognitive Autonomy project. The
Task_SH_Ontology from this project includes concepts based on several physical activities of
the elderly and people in loss of autonomy. This ontology can help to monitor the activity of
users and to motivate them to perform for example some sport activities, aiming to reduce the
3
http://www.langual.org/
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 23 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
age-related declines in the musculoskeletal and cardiovascular systems and to improve their
mental health. Task_SH_Ontology has a total of 41 classes and 2 properties.
There is also an activity ontology in OWL format which was developed from Alis Technet
(activities.owl v 1.4). This ontology describes and models the activities that are available for
tourists (either elderly or not). The most recent version of the OWL ontology can be
downloaded from http://alis.cs.bath.ac.uk/ontologies/Activities/activitiesV1.4.owl. The
activities ontology described above has a total of 85 classes, 57 properties and 21 instances.
The ontology is translated into OWL-DL. Disjointness and cardinality constraints, as well as
functional properties are defined.
Another application of the activity coach ontologies is the support of rehabilitation exercises,
for example due to a fracture. Here, the posture of the user is determined and interpreted.
Especially for elderly people (aged over 75) accident detection (for example fall detection)
will be developed. The aim is to determine a critical situation of the elderly person and to
inform the relatives or a care centre.
An elderly fall ontology has also been implemented in these projects using the Protégé
graphical interface that translates it to OWL code (caida.owl) [73]. The implementation of
the ontology with Protégé was done step by step. Firstly, the fall case concepts were specified
in a hierarchy, in OWL Classes. Then, they were represented with Protégé through a sample
of the Concepts Hierarchy that was made up of three main classes: SystemReport, covering
the system states (alarms, fall, fire...); Virtual Sensor, that is an abstraction of any
combination of physical sensors that will indicate a certain system state (active or not active);
and Task, which are solutions chosen by the system depending on the criteria and sensors
states (To notify the emergency Services, to close taps, …). After the Concepts Hierarchy
definition, the binary relations between the concepts were added in Protégé (Object
Properties), as well as the attributes of each concept (Datatype Properties). The final step of
the framework implementation for the fall awareness model was to define the instances of
each concept required to initially include the KB of the smart home telecare system.
This definition was done in the ontology conceptual diagram completely created for the case
of the elderly fall, developed in Protégé and as such may also be appropriate for consideration
within OASIS applications.
2.4. Brain and Skills Trainer Ontologies
To our knowledge there exists so far no system using Virtual Reality tools for brain training.
Most of the existing diagnostic and training tools (e.g. Wiener Test battery, Test for Attention
Performance, TAP) have a common structure: fundamental neuropsychological functions are
transferred into specific tasks. Therefore, a common ontology and structure will need to be
developed taking into account existing diagnostic and training tools such as the development
of the Virtual Maze.
2.5. Social Relation and Recreation Ontologies
This application relates to the building of a social community platform, at different levels, in
order to fight the social isolation of elderly people living alone and to facilitate new
collaborative experiences, including those related to sharing or discussing with other users of
other OASIS services (i.e. brain trainer or nutritional advisor, etc.).
In terms of ontologies available for social networking there is not much consolidated work
available, although there are many projects in particular areas that may prove relevant for
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 24 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
OASIS. In the context of this area it is particularly worth mentioning the ASK-IT4 subontology for Social Relation and Community Building, the ontologies supported by the Open
Travel Alliance (OTA) and the HARMOTEN ontologies for travel and leisure activities.
The ASK-IT social relations and community building sub-ontology contains Information
about social relations, registration to communities and social events to be considered in the
context of OASIS. Figure 1 illustrates the high-level taxonomy of the Social Relation and
Community Building Sub-ontology.
Figure 1: Social Relation and Community Building Related Taxonomy
The Open Travel Alliance (OTA)5 is a non-profit organization working to establish a common
electronic vocabulary like XML for use in the exchange of travel information (Transport,
Hospitality, Architecture and Travel Integration). Open Travel is comprised of companies
representing airlines, car rental firms, hotels, cruise lines, railways, leisure suppliers, service
providers, tour operators, travel agencies, solutions providers, technology companies and
distributors. Tens of thousands of Open Travel message structures are in use, carrying tens of
millions of messages between trading partners every day.
The Harmonise Trans-European Network for Tourism (Harmo-TEN)6 market validation
project is based on the successful results of the IST project Harmonise7. The Harmonise
Ontology initially covered accommodation facilities (all types of accommodation offering a
room such as pensions, guest houses), events and activities (e.g. theatre, concerts,
conferences, lectures, sporting events). During the HarmoTEN project, the Harmonise
Ontology was extended to new sub domains, e.g. all types of accommodation, food and
beverage, etc.
4
http://askit.iti.gr/ontology
http://www.opentravel.org/
6 http://www.harmo-ten.org
7 http://www.deri.at/research/projects/e-tourism/documents/HarmoniseOntology
5
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 25 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
In addition, the following services are worth mentioning as potential contributions of
organised or structured content relevant for the formation of the OASIS hyper-ontology and
services: the AVANTI (Added Value Access to New Technologies & services on the Internet)
services, the SAID (Social Aid Interactive Developments) services and the services supported
by the TeleCARE project. Also, OASIS will have to closely follow the work of the AMIE
project (Ambient Intelligence for the Elderly) whose target is to improve the quality of life,
providing customized support to all people in need of assistance, according to their own
specific situation and the work of the SWAPME8 project between MIT and NOKIA USA.
The AVANTI9 project aims to encourage people who cannot or believe they they do not need
to use new technology. In particular, it targets elderly people and people with disabilities or
from ethnic minority groups. The AVANTI project partners are developing an "avatar" - an
intelligent on-screen animated character that takes the role of a Council representative, and
talks to the citizen via the screen, while words are simultaneously displayed in a speech
bubble. This is only one part of the work of AVANTI. A sophisticated natural language
processing (NLP) component and a conversation manager have also been developed, and are
interfacing the system with city systems and databases.
SAID10 is meant to develop a set of telematic services for the elderly to aid the work of
Social Assistants by means of Digital TV infrastructure, intelligent Software Agents and
Mobile phone information services. SAID supports the following services under the digital
TV platform: Video Conferencing, alarms, surveillance, personalised assistants (shopping,
reminder, info-searcher), household, entertainment and education. SAID implements a
number of standard services included in the Services Catalogue. The catalogue includes the
following services for the users (the Disabled & Elderly):
 24h Alarms.
 Surveillance (permanent and emergencies).
 Communications: videoconferencing, audio email, etc.
 Catering.
 Households: repairs, etc.
 Tele-Education.
 Internet access (active system).
 E-Commerce (supervised).
 Information: medical, administrative services, payments, etc.
 Entertainment.
 Virtual Assistant: reminder, supervision, adviser, user clubs, etc.
The TeleCARE [74] project aims at a technological infrastructure to enhance collaborative
virtual elderly support communities’ resorts on the basis of the Internet and mobile-agent
technologies. A set of specialised vertical services are implemented on top of the horizontal
TeleCARE infrastructure to support different interactions with the system. The following
initial services have been developed by the TeleCARE consortium:
 Living status monitoring. This service represents an advance regarding the more
traditional “social alarm” systems, as it allows not only bi-lateral interactions and
some semi-automatic supervision functionalities, but also the collection of additional
information when help is needed or requested. The tranquillity and assistance given 24
8
http://dig.csail.mit.edu/SwapMe/
http://193.39.157.27/avanti/default.htm
10 http://www.eptron.es/projects/said/
9
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 26 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754



hours a day is intended to increase in a significant manner the elderly’s quality of life
and relative’s peace of mind.
Agenda reminder. The daily activities related to the welfare of the elderly can be
scheduled in order to improve their quality of life and well being. This service,
implemented through a number of agents, is able to remind the elderly of a number of
activities, ranging from medication to exercise guidance or appointments made with
the care center.
Time bank. This service provides a mechanism for collaborative community building /
re-enforcement, i.e. a way for people to come together and help each other. At the
same time it represents one of the mechanisms to support the “active aging” concept.
Entertainment. The Entertainment Services are designed to ease the sense of isolation
elderly feel and provide light entertaining applications to improve their sense of well
being, contributing to the maintenance of a social life and also an active aging. As a
first demonstration a combination of games, music and education programs are
offered.
The SWAPMe (Semantic Web Application Platform for Mobile Ecosystems) project
developed a new software architecture that enables the mobile ecosystem to take advantage of
the power of the Semantic Web data model.
Finally, Palette Project11 (Pedagogically sustained adaptive Learning through the exploitation
of tacit and explicit knowledge) and OneSitePlatform12 which are derived from OASIS
database can be incorporated in this section. The learning value of communities of Practice
(CoP) is of high importance. The underlying processes of social participation, community
building, development of identity, learning and knowing are deeply interconnected, while
they are articulated around negotiation of meaning, which is at the base of any individual and
collective learning. Moreover, the interacting processes of participation and reification are
considered as fundamental to learning. In deliverables D.KNO.01, D.KNO.02, D.KNO.05 of
Palette CoP independent and dependent ontologies can be found. Moreover OneSite Platform
is one of the leading providers of enterprise-class social sites and communities for media,
entertainment, and lifestyle brands. Community experience with Blogging, Photo and Video
Sharing, Tagging, Rating, Flagging, Commenting, Built-in Messaging, and Groups built on
patent-pending technology is intended to help elderly people to fight social isolation.
2.6. Health Monitoring Ontologies
Many different types of health related ontologies have been developed during the last years,
specifically in different projects. Particularly relevant projects include: “Health Memory”,
“FMA”, “Disease Ontology”, and “GALEN Programme”.
The Health Memory Project developed a “Cardioontology” [67], addressed specifically at
providing a complete cardiology knowledge base for web semantic searches. The Health
Memory Cardiontology is a domain ontology specialized in cardiology. The Cardiontology
defines the main concepts involved in the cardiology domain and relate each other by means
of convenient relations identified by experts in the field. This ontology provides a model of
the cardiology domain specially adapted to the knowledge needs of cardiologists,
pharmaceutical companies and implantable devices companies because these stakeholders
have had an active role in its requirements elicitation process. It is available at UPM
11
12
http://palette.ercim.org/
http://www.onesite.com/index.html
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 27 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
(Universidad Politecnica de Madrid) in an RDF/XML model and it follows the MESH
medical standard as much as is possible in the Cardiology sector.
The Cardiontology consists of the following concept categories:
 Anatomical entities of the cardiovascular system with special emphasis on the heart
structure.
 Main diseases, disorders or syndromes related to the cardiovascular system.
 Body regions to be considered in the valuation of patients’ signs and symptoms for
diagnostic purposes.
 Methods and tests used for the correct diagnosis of cardiovascular patients.
 Treatments considered in the care / management of cardiovascular diseases, disorders
or syndromes.
 Symptoms, signs and risk factors related to cardiovascular diseases, disorders or
syndromes.
 Contraindications to be considered before the administration of a particular treatment
to a cardiovascular patient.
 Possible side effects derived from the administration of a treatment to a cardiovascular
patient.
 Diagnosis, therapeutic and non-therapeutic devices involved in a cardiovascular
patient’s diagnosis, treatment and management processes.
 Organisms cause of cardiovascular infectious diseases.
Moreover, the Cardiontology considers 6 different types of basic relations:
 Risk factors relations: these are the relations among the main cardiovascular risk
factors, their associated pathologies or diseases, the diagnosis methods that can be
used for their detection and their treatments.
 Signs relations: these are the relations among the main signs that a cardiovascular
patient may present and their associated pathologies.
 Symptoms relations: these are the relations among the main symptoms that a
cardiovascular patient may present and their associated pathologies and treatments.
 Diagnosis methods relations: these are the relations among the main diagnosis
methods used in cardiology, their realization criteria, the body regions or
cardiovascular system elements that they cover, the diseases they may diagnose and
the devices that they require.
 Treatment relations: these are the relations among the main treatments used in
cardiology, the diseases they treat, their possible contraindications and side effects,
and the devices that are required for their application if proceeds.
 Disease relations: these are the relations among the main cardiovascular diseases,
syndromes or disorders, their possible treatments, other diseases that they may cause,
the methods used for their diagnosis, their signs and their symptoms.
The (FMA) Foundational Model of Anatomy Ontology13 is an evolving computer-based
knowledge source for biomedical informatics; it is concerned with the representation of
classes or types and relationships necessary for the symbolic representation of the phenotypic
structure of the human body in a form that is understandable to humans and is also navigable,
parseable and interpretable by machine-based systems. Specifically, the FMA is a domain
ontology that represents a coherent body of explicit declarative knowledge about human
anatomy. Its ontological framework can be applied and extended to all other species. It is
13
http://sig.biostr.washington.edu/projects/fm/AboutFM.html
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 28 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
currently only available as a MySQL relational database but there are ongoing efforts in
exporting the FMA into OWL.
The Foundational Model of Anatomy ontology has four interrelated components:
 Anatomy taxonomy (At),
classifies anatomical entities according to the characteristics they share (genus) and by
which they can be distinguished from one another (differentia) -designated in previous
publications as the Anatomy ontology or Ao;
 Anatomical Structural Abstraction (ASA),
specifies the part-whole and spatial relationships that exist between the entities
represented in At;
 Anatomical Transformation Abstraction (ATA),
specifies the morphological transformation of the entities represented in At during
prenatal development and the postnatal life cycle;
 Metaknowledge (Mk),
specifies the principles, rules and definitions according to which classes and
relationships in the other three components of FMA are represented.
Thus, the Foundational Model of Anatomy ontology may be represented by the abstraction:
FMA = (At, ASA, ATA, Mk)
The Foundational Model of Anatomy ontology contains approximately 75,000 classes and
over 120,000 terms; over 2.1 million relationship instances from over 168 relationship types
link the FMA’s classes into a coherent symbolic model. The FMA is one of the largest
computer-based knowledge sources in the biomedical sciences.
The Disease Ontology14 is implemented as a directed acyclic graph (DAG) and utilizes the
Unified Medical Language System (UMLS) as its immediate source vocabulary to access
medical Ontologies such as ICD9CM. Using this standard, much of the process of updating
the ontology can be handled by UMLS, freeing resources for clinicians to pursue more urgent
tasks. For situations where the graph needs to be directly edited, the open source graph editor
DAGEdit can be used. DAGEdit can readily manipulate and view the Disease Ontology
because it is stored in Open Biomedical Ontologies (OBO) format in order to take advantage
DAGEdit and any other OBO standards compliant tools.
As a graph, the Disease Ontology can be thought of as a subset of UMLS. It fills a niche in
the medical ontology world as a lightweight ontology offering context-free concept identifiers
designed specifically to facilitate mapping to medical billing codes. Other Ontologies such as
SNOMED and MESH lack these features.
The previous version of Disease Ontology (v2.1) is based almost entirely on ICD-9-CM with
additional concepts included that are useful for mapping common disease requests. It is a
lightweight ontology containing 19136 concept nodes and is currently available for download.
The newest version Disease Ontology 3 (revision 21) is based on primarily on freely available
UMLS vocabularies (including ICD9) and is currently under development.
The GALEN Programme represents the overall development of the technology, which has
included several EU-funded Research Projects (the GALEN & GALEN-IN-USE projects).
The Galen ontology is an ontology for clinical/medical terminology translated into the OWL
Description Logic. The full GALEN ontology of medical terms, anatomy and drugs translated
into OWL can be downloaded from http://www.co-ode.org/galen/full-galen.owl.
14
http://diseaseontology.sourceforge.net/
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 29 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
The OASIS Health Monitoring Ontology can make use of some of the concepts and structures
of those Ontologies, particularly applicable in the Health Monitoring field. In addition, the
OASIS Health Monitoring Ontology can describe the Health Monitoring domain by means of
appropriate terms derived from ontology–like vocabularies such as “NCI Thesaurus”, “UMLS
Knowledge Sources” and “SNOMED”.
The NCI Thesaurus15 is an ontology-like vocabulary that includes broad coverage of the
cancer domain, including cancer related diseases, findings and abnormalities; anatomy;
agents, drugs and chemicals; genes and gene products and so on. In certain areas, like cancer
diseases and combination chemotherapies, it provides the most granular and consistent
terminology available. It combines terminology from numerous cancer research related
domains, and provides a way to integrate or link these kinds of information together through
semantic relationships.
The NCI Thesaurus contains nearly 110000 terms in approximately 36000 concepts,
partitioned in 20 subdomains, which include diseases, drugs, anatomy, genes, gene products,
techniques, and biological processes, among others, all with a cancer-centric focus in content,
and originally designed to support coding activities across the National Cancer Institute.
The Unified Medical Language System16 (UMLS) facilitates the development of computer
systems that behave as if they "understand" the language of biomedicine and health.
Developers use the Knowledge Sources (databases) and tools to build or enhance systems that
create, process, retrieve, and integrate biomedical and health data and information. The
Knowledge Sources are multi-purpose and are used in systems that perform diverse functions
involving information types such as patient records, scientific literature, guidelines, and
public health data. The associated software tools assist developers in customizing or using the
UMLS Knowledge Sources for particular purposes. The lexical tools work more effectively in
combination with the UMLS Knowledge Sources, but can also be used independently.
UMLS consists of the following components:
 Metathesaurus, the core database of the UMLS, a collection of concepts and terms
from the various controlled vocabularies, and their relationships;
 Semantic Network, a set of categories and relationships that are being used to classify
and relate the entries in the Metathesaurus;
 SPECIALIST Lexicon, a database of lexicographic information for use in natural
language processing;
 a number of supporting software tools.
The Metathesaurus forms the base of the UMLS and comprises over 1 million biomedical
concepts and 5 million concept names, all of which stem from over 100 incorporated
controlled vocabularies and classification systems. Some examples of the incorporated
controlled vocabularies are ICD-9-CM, ICD-10, MeSH, SNOMED CT, LOINC, WHO
Adverse Drug Reaction Terminology, UK Clinical Terms, RxNORM, Gene Ontology, and
OMIM.
Each concept in the Metathesaurus is assigned to at least one "Semantic type" (a category),
and certain "Semantic relationships" may obtain between members of the various Semantic
types. The Semantic network is a catalog of these Semantic types and Semantic relationships.
This is a rather broad classification; there are 135 semantic types and 54 relationships.
15
16
http://nciterms.nci.nih.gov/NCIBrowser/Dictionary.do
http://www.nlm.nih.gov/pubs/factsheets/umls.html
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 30 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
The Metathesaurus is organized by concept, and each concept has specific attributes defining
its meaning and is linked to the corresponding concept names in the various source
vocabularies. Numerous relationships between the concepts are represented, for instance
hierarchical ones such as "is a" for subclasses and "is part of" for subunits, and associative
ones such as "is caused by" or "in the literature often occurs close to" (the latter being derived
from Medline).
SNOMED Clinical Terms17 (SNOMED CT) is a dynamic, scientifically validated clinical
health care terminology and infrastructure that makes health care knowledge more usable and
accessible. It provides a common language that enables a consistent way of capturing, sharing
and aggregating health data across specialties and sites of care. Among the applications for
SNOMED CT are electronic medical records, ICU monitoring, clinical decision support,
medical research studies, clinical trials, computerized physician order entry, disease
surveillance, image indexing and consumer health information services.
Currently SNOMED CT® is distributed only as tab-delimited UTF-8 text files so that
customers can load these files into their database. A second distribution format that has been
requested by several customers is an XML distribution format. An XML format benefits
customers creating local extensions to SNOMED CT in that they will be able to output in an
XML format and easily validate that their extension conforms to the SNOMED CT format. It
is licensed under the Apache License. More than 311,000 active concepts with formal logicbased definitions are organized into top-level hierarchies. More than 920,000 defining
relationships enable consistency of data retrieval and analysis. In addition, a Health Action
concept is described, in order to allow intelligent decisions in relation with possible dangerous
situations for the user. OASIS can also gain in this area from the Task_SH_Ontology
described above. Finally, the final user of the Health Action will be described in the ontology,
so that the appropriate users can be informed about a possible disease or biomedical
parameter according to their profiles.
A further useful ontology in this domain is Person_SH_Ontology which can be downloaded
from http://www.gdst.uqam.ca/Documents/Ontologies/HIT/. The Person _SH_Ontology has a
total of 60 classes and 120 properties represented in OWL-DL. This ontology can be used in
co-operation with Behaviour_SH_Ontology.
The Behaviour Ontology addresses two important aspects in the context of remote
monitoring, the life habits and critical physiological parameters. The Behaviour Ontology
describes the nature of these concepts and their relations. A life habit is characterized, for
example, by the activity associated with this habit, the place where it is held (in relation to the
ontology of the habitat), its time of occurrence, its duration and its frequency [68].
Physiological parameters can be related to the global activity level of the person, to its heart
rhythm or its blood pressure. The Behaviour Ontology describes the characteristics of these
parameters as well as critical elements essential to supervise.
This ontology makes it possible to describe the usual behaviour of the old person in loss of
cognitive autonomy. From this behaviour, an interpretation of the health status of the patient
as well as the detection of emergency situation can be detected in order to generate an
appropriate decision. This decision makes it possible to meet the need for the patient at a time,
in a given space and for a given critical situation. Such a situation can be for example that the
patient is lying on the bed at midday, which is the hour for the dinner and not for the nap. The
Task_SH_Ontology is closely related to this ontology.
17
http://www.ihtsdo.org/snomed-ct/
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 31 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Finally, EMERGE18 (Emergency Monitoring and Prevention) and COCOON19 projects
derived from OASIS database can be incorporated here. The approach of EMERGE is to use
ambient and unobtrusive sensors to monitor activity, location, and vital data. Daily routine is
tracked in order to detect abnormalities and to create early indicators for potentially arising
emergencies. COCOON is an Integrated Project aimed at supporting health care professional
in reducing risk management in their daily practices by building knowledge driven &
dynamically adaptive networked communities within European health care systems.
2.7. Enviromental Control Ontologies
Controlling the house is one of the more demanding applications when some physical decline
comes. Domotics applications will allow the elderly to be confident in their house and
contribute to the comfort of the person. The knowledge of the structure and its technical
aspects inside home will allow tuning of the use of other applications. OASIS can benefit
from
the
Habitat_SH_Ontology,
Equipment_SH_Ontology,
Assertions_Equipment_SH_Ontology, and Assertions_-Habitat_SH_Ontology which can all
be downloaded from http://www.gdst.uqam.ca/Documents/Ontologies/HIT/.
The Assertions_Habitat_SH_Ontology imports the Assertions_Equipment_SH_Ontology,
Habitat_SH_Ontology and Equipment_SH_Ontology and has a total of 251 classes and 19
properties. The ontology is translated in OWL-DL and gives a brief description of the
intelligent habitat (structure -number of rooms, entrance, corridor- and technical aspects such
as sensors, data processing system). It provides a tree representation of furniture, household
and technical equipment (moveable and immoveable). Assertions_Equipment_SH_Ontology
has a total of 222 classes and 19 properties. Habitat_SH_Ontology has a total of 14 classes
and 19 properties and finally Equipment_SH_Ontology has a total of 236 classes and 19
properties.
In addition, the AMIGO project (October 2006) and the opportunities offered by DoNet (A
Semantic Domotic Framework) and DogOnt ontologies can be considered for inclusion in the
relevant OASIS domotics ontology.
The Amigo20 project (Ambient Intelligence for the networked home environment) is intended
to provide solutions for the major problems that are encountered in the use of home
networking today. The project aims to improve the usability of a home network by developing
open, standardised, interoperable middleware and improve the attractiveness by developing
interoperable intelligent user services. The project shows the end-user usability and
attractiveness of such a home system by creating and demonstrating prototype applications
improving everyday life, addressing all vital user aspects: home care and safety, home
information and entertainment, and extension of the home environment by means of ambience
sharing for advanced personal communication. A brief description of the Amigo ontology can
be found in the AMIGO deliverable D1.2: “Specification of the Amigo Abstract Middleware
Architecture”.
DoNet [75] illustrates a home system oriented ontology and an intelligent agent based
framework for the rapid development of home control and automation. The DoNet ontology
makes use of SOUPA [76] and its extensions together with time-entry (subontology of OWLTime [77]) and OWL-S. It gives means to enable multiple representations for things within a
home system. A building, a room, an area within a room, areas in between rooms, corridors
18
http://www.emerge-project.eu/
http://www.cocoon-health.com
20 http://www.hitech-projects.com/euprojects/amigo/
19
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 32 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
etc., are all represented as DoNet SpatialThings. Items, which have a function, or simply some
sort of contextual relevant representation are also defined. It is assumed that anything, which
has spatial properties, also holds a function and/or state, wherever it is located. DoNet
provides means to define Services, Functions and their Relations with service managing
entities. There are a number of important direct and indirect relationships between entities in
DoNet. Amongst these we find both item and service management, as well as function and
state holding relationships. The ontology also provides means to define users and their
preferences.
The DogOnt ontology [78] is designed with a particular focus on interoperation between
domotic systems. DogOnt is deployed along 5 main hierarchy trees:
 Building Thing: modeling available things (either controllable or not);
 Building Environment: modeling where things are located;
 State: modeling the stable configurations that controllable things can assume;
 Functionality: modeling what controllable things can do;
 Domotic Network Component: modeling features peculiar of each domotic plant (or
network).
DogOnt Ontology has a total of 167 named classes, 18 object and 26 datatype properties. It
provides functionality and state auto-completion, and supports model evolution through
classification reasoning.
2.8. Transport Information Ontologies
The ready availability of transport information is one of the keys to encouraging the elderly to
travel, whether locally or further afield. They need however to be reassured before leaving
home that the journey will not produce unexpected problems they feel unable to cope with.
This requires a convenient means of receiving not only pre-trip but also on-trip information
covering private as well as public transport and being able to provide updates regarding the
transport situation as it evolves. It is also essential for this information to be available in a
form with which people feel comfortable: this can be a PC, or a Personal Digital Assistant
(PDA), TV, mobile phone or fixed phone line, with interfaces adapted to the elderly user.
In the transport information sector a first common ontology has been designed within the
IM@GINE IT project (Intelligent Mobility AGents, Advanced Positioning and Mapping
Technologies, INtEgrated Interoperable MulTimodal location based services) IM@GINE IT
project aimed to develop one single access point, through which the end user can obtain
location-based, intermodal transport information (static and dynamic), mapping and routing,
navigation and other related services everywhere in Europe, anytime, taking into account the
personal preferences of the user. Thus, IM@GINE IT targeted the facilitation of seamless
travel in Europe. The following groups of concepts are defined in IM@GINE IT ontology:
 Coordinates;
 Address;
 BoundingBox;
 ScreenSize;
 POIForMap;
 Line;
 ClickablePOI;
 ImageCoordinates;
 Map;
 Image;
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 33 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754












RouteSegmentDetail;
CoordinatesInCountry;
RouteSegment;
Route;
PublicTransportTimeTable;
OptionalInformation;
LineTimetable;
TrafficEvent;
PublicTransportEvent;
HotelGuestInformation;
HotelAvailabilityResponse;
MakeBookingResponse;
An
ontology
documentation
can
be
found
at
http://www.imagineiteu.com/ftp/IM@GINE%20IT%20D2.1.2%20final.pdf. The following services are available in
IM@GINE IT project:
 Reservation of flight/train.
 Hotel reservation.
 Geocoding service.
 Mapping service.
 Car & pedestrian routing service.
 PT routing service.
 Traffic event information.
 POI & event search.
 PT timetable information service.
 Dynamic PT information service.
Another relevant effort in the transport domain is the ASK-IT project that addressed the needs
of elderly users. The publicly available Transportation sub-ontology contains information
about transportation issues. The ontology is authored using the Protégé tool and it is stored in
OWL format. There are 316 concepts on different levels underneath the top level concept
“ASK-IT.TransportationOntology”. The concepts of the ontology are exploiting the grouping
possibilities for concepts of similar types. Hence, concepts that are referring to the same
abstraction level are placed on the same hierarchy level. Finally, the structure of branches has
a balanced (equally developed) hierarchy.
The ASK-IT Transportation sub-ontology is documented, including comments and dimension
units for some datatype properties. As a result the ontology is intended to be easy to use and
understand, especially for those who want to apply/reuse it. The Transportation sub-ontology
has no explicit relation to existing upper level ontologies or ontological modules, however.
Moreover it has no relation to existing general lexical resources and existing
application/domain-specific terminologies.
2.9. Route Guidance Ontologies
Several competing ontologies exist in the area of route guidance, especially since there are
many different sub-domains in it, such as pedestrian and driver route guidance (PT user route
guidance is a rather new concept). They are also included in the IM@GINE IT and ASK-IT
IPs ontologies and will be considered for connection within the OASIS COF. The main
relevant extensions of the ASK-IT ontology are related to the inclusion of new semantics,
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 34 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
such as “picturesque”, “calm” (low traffic volume), etc. route; whereas ASK-IT defined only
the “accessible” route (considering only physical accessibility).
In addition to this, the IN-SAFETY21 (INfrastructure and SAFETY) project recorded in the
OASIS database can be described here. The IN-SAFETY project aims to use intelligent,
intuitive and cost-efficient combinations of new technologies and traditional infrastructure in
order to enhance the self-explanatory nature of roads, by creating comprehensible pictograms
to substitute verbal messages as used on roads, focussing on TERN (Trans European Road
Network) requirements, optimising them for impaired visibility conditions and animating
them for improved comprehension. This information is included in ontologies and so OASIS
will seek to build on these results.
2.10. Personal Mobility Ontologies
In terms of ontologies available for personal mobility there is not much consolidated work
available. Nonetheless it is worth mentioning the OSSATE (One Stop Shop for accessible
tourism in Europe) project whose target is to implement a prototype multi-platform, multilingual digital information service providing national and regional content on Accessible
Tourist Venues, Sites and Accommodation, initially from 2 EU Member States: Greece and
the UK. Also, OASIS will have to closely follow the work of the ASK-IT project (Ambient
Intelligence System of Agents for Knowledge based and Integrated Services for Mobility
Impaired Users) whose target is to develop services based on Information Communication
Technologies (ICT) that will allow Mobility Impaired people to live more independently.
The overall aim of the OSSATE22 project is to create a new transnational e-service in Europe,
which will allow disabled citizens and their families to find information concerning the
accessibility of tourist destinations.
The driver support services (based on existing ADAS and IVIS) have been mapped into the
ASK-IT transport ontology (see 2.8), whereas the flexible on demand mobility services are
included in the ASK-IT personal services ontology. However, in both cases, new
functionalities are added here, such as the combination of driver health monitoring and e-Call
services, the assisted navigation function, etc.
The ASK-IT personal services ontology contains information about travel companion,
specific care at the hotel, eating, paramedical support, etc. These services will be used by MI
people who seek to hire local assistance that matches their needs (including language,
expertise, specific preferences). Figure 2 illustrates the high-level taxonomy of the Personal
Support Services sub-ontology.
Tourism and leisure is another case completely. Here, many ontologies exist, strongly
competing against each other, even in the market place. OASIS will interface through its
reference architecture and ontology connection platform with the most prominent of these,
such as the ASK-IT tourist services ontology (including elderly needs).
Touristic content is defined as anything that would interest a tourist who visits an area or city.
This include, among others, useful content about hotels, museums, interesting places, as well
as useful information about tourism offices, embassies, airlines, useful telephone numbers and
addresses and so on.
21
22
http://www.insafety-eu.org/
http://www.ossate.org/
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 35 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Figure 2: Personal Support Services Related Taxonomy
The leisure content addresses all sectors that are used in every day life not only by tourists but
by residents also. Content about restaurants, theatres and cinemas, entertainment parks,
information about major art or music events and other leisure sectors are covered as well.
Something of the breadth of the class taxonomy is suggested in Figure 3.
Figure 3: Tourism and Leisure Ontology
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 36 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
2.11. Smart Workplaces
Smart workplaces for the elderly encompass a set of context-aware technologies that enables
the elderly to work securely (in terms of secure access to business portal and information but
also in terms of protecting their health against overly excessive stress or fatigue), comfortably
(with interfaces providing high usability and intelligent content retrieval functionality) and
seamlessly (working session remaining uninterrupted while changing device or work location
or while performing interaction with other services) from everywhere, at anytime.
Few efforts have been devoted so far to develop ontologies in this domain, the most notable
being that of the ASK-IT project. The Work, Business and Education Support Ontology from
ASK-IT included concepts based on Services for work and education while on the move
("mobile worker") with special considerations for MI people group info.
The ASK-IT ontology contains information about work and education and it is publically
available at http://askit.iti.gr/ontology/. The ontology is authored using the Protégé tool and it
is stored in OWL format. The concepts of the ontology are exploiting the grouping
possibilities for concepts of similar kinds. Hence, concepts that are referring to the same
abstraction level are placed on the same hierarchy level. Finally, the structure of branches has
a balanced (equally developed) hierarchy. The ASK-IT Work, Business and Education
Support Ontology is documented but shows the general characteristics of the other ASK-IT
ontologies as described above.
The SOPRANO23 project developed affordable, smart ICT-based assisted living services with
interfaces, which are intended to be familiar and easy to use by older people in their domestic
environment.
The MOSQUITO24 project aims at ensuring easy-to-use business applications security for
mobile workers in ubiquitous computing environments. The overall framework relies on Web
services technology and the WSDL standard has been used for the interfaces specification
(Deliverable D4: Specification of service mediation infrastructure).
2.12. Other Areas
The OASIS ontologies will be developed in order to serve the needs of elderly users in a wide
range of use cases, which have not been extensively dealt with before in the literature. The
research efforts related to the use of ontologies for supporting elderly user needs are mainly
focused on their interaction with computer applications and on accessibility issues about web
navigation.
In [69], the authors introduce a semi-automated tool that supports travel and mobility of
visually impaired Web users. This tool uses a travel ontology in order to transform Web
pages, by extracting objects that may interest web travellers. The main goal of this tool is to
analyse Web pages to identify objects that support mobility and travel, discover their roles,
annotate them and transform pages based on these annotations to enhance the provided
mobility support. In this manner, it enhances navigation capabilities on behalf of visually
impaired users. The scope of the developed ontology is narrower compared to OASIS, as it
targets only visually impaired users and addresses activities related to web navigation.
Accessibility of web pages is also addressed in [70] with a low-overhead system that enables
semantic encoding. This work performs a markup of web pages in order to include semantic
23
24
http://www.soprano-ip.org/
http://www.mosquito-online.org/
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 37 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
information. An ontology has been created that captures the meaning of XHTML meta tags.
This approach enables new meta tags to enhance semantics of web pages with CSS support, in
a semi-transparent manner for web page authors. In particular, this approach allows
semantics-based triage, that is, prioritized removal of unnecessary information from the
presentation of a Web site, to make the interaction of visually impaired users with that site
more productive.
Work in [71] provides an ontology to enable mapping between various impairments and
attributes of user interfaces. This enables improved access to personal information systems by
enabling user interfaces adapted to user needs, through a custom application, called
SemanticLIFE. The ontology covers many MI user attributes in a manner similar to ours.
Although advanced use cases, such as trip planning, can be realized, the main focus remains
on the UI customization according to user impairments.
Ontologies are used in [72] for providing accessibility in context of web page annotations for
conveniently navigating the visual structure of web pages. Their ontology consists of
semantics about mobility (travel objects such as way points, orientation points, & travel
assistants), authoring (header, logo, label, heading, footnote, section) & context (information
seeking, surveying, orientation, navigation, browsing). The WAI (Web Accessibility
Initiative) provides WCAG guidelines to encode some of the above information semantics but
not all. Also, the accessibility is provided only for visually impaired users.
2.13. Interim conclusions: consequences for OASIS
In this chapter we have seen that there is a considerably body of material to build upon when
constructing OASIS-related applications. The OASIS hyper-ontology will be able to draw on
considerable experience and results in ontology-based application design. However, the
ontologies described here also show a common set of weaknesses, which it will be precisely
the task of the OASIS method and COF to help correct. In many ontologies we see a lack of
attention to the lifecycle development required for such artefacts, calling for an enforcement
of sounder methods such as those depicted in the following chapters. In addition, we see
considerable overlap in the domains covered. Ontologies have been developed in isolation to
others, resulting in lack of re-use and possibly incompatible definitions of common areas.
This will also be directly addressed within the OASIS hyper-ontology by enforcing a greater
degree of modular design. All of these aspects are taken up in detail in WP1.2 and will be
reported on in detail in D1.2.1
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 38 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
3. Description of methodologies and methods for building
ontologies from scratch
This section presents, in direct chronological order, the most well known approaches for
building ontologies from scratch, as well as reusing ontologies that are stored in ontology
libraries. First the main set of criteria used to compare different approaches of this type is
presented. Then, a brief description of each approach is provided, presenting who has
elaborated it and the proposed steps and activities.
3.1.
Evaluation Framework for Methodologies and Methods
The set of criteria used to compare different approaches is based on the framework
established in [96] which adapts the IEEE 1075-1995 standard for software development
process [93]. Such process is broken down in other processes (management processes,
development-oriented processes, etc.). Processes are made by activities. For each activity of
the framework, we set up whether it is proposed or not, and if it is described in detail. The
following kinds of processes are distinguished:
 Project management processes. They create the framework for the project and ensure
the right level of management throughout the entire product life cycle. Activities
related to project initiation (participants, scheduling, etc.), project monitoring and
control, and ontology quality management belong to this group of processes.
 Ontology development-oriented processes. Produce, install, operate and maintain the
ontology and retire it from use. They are divided into three groups:
- Pre-development processes. They are performed prior to the actual ontology
development. They involve activities related to the study of the ontology
installation environment, and to feasibility studies.
- Development processes. These are the required processes for building the
ontology. They include: requirements, which are comprised of iterative
activities directed towards developing the ontology requirements specification;
design process, the goal of which is to develop a coherent and well-organised
representation of the ontology that meets the requirements specification; and
implementation process, which transforms the design representation of an
ontology into an implementation language.
- Post-development processes. They are related to the installation, operation,
support, maintenance and retirement of an ontology. They are performed after
the ontology construction.
 Integral processes. These processes are needed to successfully complete ontology
project activities. They ensure the completion and quality of project functions. They
are performed at the same time as ontology development-oriented processes and
include activities that do not output ontology, but are absolutely necessary to obtain a
successful system. They cover the processes of knowledge acquisition, verification
and validation, ontology configuration management, documentation development and
training.
3.2.
Cyc method
The Cyc methodology arose from experience of the development of the Cyc knowledge base
(KB), which contains a huge amount of common sense knowledge [79]. According to Cyc
method, the phases to build the Cyc ontology are three. In all of them, the objective is to
extract common sense knowledge (what people in common would agree) that is implicit in
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 39 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
different sources. The difference between them is the degree of automation of the knowledge
acquisition process (from manual to automatic). Once knowledge has been acquired, it is
divided into microtheories (or contexts), which are bundles of assertions in a particular
knowledge domain.
3.3.
Uschold and King’s method : ENTERPRISE
This method is based on the experience of developing the Enterprise Ontology which is a
collection of terms and definitions relevant to business enterprises [80]. This methodology
provides four guidelines for developing ontologies. These guidelines are: identifying the
purpose (which is important in order to establish the goal and aim of the intended ontology),
build the ontology by capturing the knowledge, code this knowledge and integrate existing
ontologies and finally evaluate this ontology and document the ontology.
Figure 4: Methodology Structure
3.4.
Grüninger and Fox’s methodology
This methodology [81] is based on the experience in developing the TOVE (Toronto Virtual
Enterprise) project ontology within the domain of business processes and activities modelling.
Essentially, it involves building a logical model of the knowledge that is to be specified by
means of the ontology. This model is not constructed directly. First, an informal description is
made of the specifications to be met by the ontology and then this description is formalized.
In general, Grüninger and Fox propose first to identify intuitively the possible applications
where the ontology will be used, and determine the scope of the ontology using a set of
natural language questions, called competency questions. These questions and their answers
are used both to extract the main ontology components (expressed in first order logic). This
methodology is very formal and can be used as a guide to transform informal scenarios in
computable models. The steps proposed are shown in Figure 5.
3.5.
KACTUS method
In the method proposed at the KACTUS project [82] the ontology is built on the basis of an
application KB, by means of a process of abstraction (that is, following a bottom-up strategy).
The more applications are built, the more general the ontology becomes; hence, the further the
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 40 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
ontology moves away from a KB. Therefore, every time an application is developed, the
following steps are taken: specification of the application, preliminary design based on
relevant top-level ontological categories, ontology refinement and structuring.
Figure 5: Grüninger and Fox’s methodology
3.6.
METHONTOLOGY
METHONTOLOGY [83] is a methodology, created in the Artificial Intelligence Lab from the
Technical University of Madrid (UPM), for building ontologies either from scratch, reusing
other ontologies as they are, or by a process of reengineering them. The METHONTOLOGY
framework enables the construction of ontologies at the knowledge level. It includes: the
identification of the ontology development process, a life cycle based on evolving prototypes
(shown in Figure 6), and particular techniques to carry out each activity. Many ontologies
have been built by this method, including chemicals, reference and KM ontologies.
METHONTOLOGY has been proposed for ontology construction by the Foundation for
Intelligent Physical Agent (FIPA), which promotes inter-operability across agent-based
applications.
3.7.
SENSUS method
The method based on Sensus [84] is a top-down approach for deriving domain specific
ontologies from huge ontologies. The authors propose to identify a set of ‘‘seed’’ terms that
are relevant to a particular domain. These terms are linked manually to a broad-coverage
ontology (in this case, the Sensus ontology, which contains more than 70,000 concepts).
Then, all the concepts in the path from the seed terms to the root of SENSUS are included. If
a term that could be relevant in the domain has not yet appeared, it is manually added, and the
previous step is performed again, until no term is missing. Finally, for those nodes that have a
large number of paths through them, the entire subtree under the node is added, based on the
idea that if many of the nodes in a subtree have been found to be relevant, then, the other
nodes in the subtree are likely to be relevant as well. Consequently, this approach promotes
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 41 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
sharability of knowledge, since the same base ontology is used to develop ontologies in
particular domains
Figure 6: Development process and life cycle of METHONTOLOGY
.
Figure 7: SENSUS Approach
3.8.
CommonKads
CommonKADS methodology [85] is a modelling primitive which fulfils an important
function: it must allow specification of problem-solving methods in terms which are
independent of particular application domains, thus supporting the re-use of these generic
methods. According to this methodology, the phases to ontology design are: feasibility study,
where ontology scope is identified, kick-off phase, where ontology requirements are
specified; refinement and evaluation where typical queries are analysed; and maintenance
phase.
3.9.
On-To-Knowledge Methodology : OTK
The On-To-Knowledge methodology [86] includes the identification of goals that should be
achieved by knowledge management tools and is based on an analysis of usage scenarios. The
steps proposed by the methodology are: kick-off, where ontology requirements are captured
and specified, competency questions are identified, potentially reusable ontologies are studied
and a first draft version of the ontology is built; refinement, where a mature and applicationCERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 42 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
oriented ontology is produced; evaluation, where the requirements and competency questions
are checked, and the ontology is tested in the application environment; and ontology
maintenance.
3.10. Rapid Ontology Development : ROD
ROD [87] is a methodology that can be used to build ontology for under developed domains.
It consists of four processes: domain analysis, document and language processing, statistical
analysis and extraction and mapping between TART (terms and related terms) and TCAR (top
level concepts and relations). The steps proposed are as follows (see Figure 8):
Figure 8: ROD Framework
3.11. Holsapple Methodology
Holsapple et al. [88] focus their methodology on the collaborative aspects of ontology
engineering but still aim at a static ontology. A knowledge engineer defines an initial
ontology which is extended and modified based on the feedback from a panel from domain
experts. According to [88], the collaborative approach phases’ to ontology design are: the
preparatory phase that defines the design criteria for the ontology for guiding and assessing its
success; the anchoring phase that includes the development of the initial ontology that will
seed the next phase; the iterative improvement phase that revises the ontology until consensus
is reached through a consensus building technique and the application phase that applies the
final ontology structure to the case in order to demonstrate its uses.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 43 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
3.12. DOGMA Approach
The DOGMA methodology [89] consists of two main steps: the preparatory stages where the
overall purpose and management of the project are defined and organised and the ontology
engineering stages where a set of plausible domain fact types are collected, defined, described
and finally constrained by an application committing to their agreed meaning.
The DOGMA modelling methodology partly draws on some best practices established in
earlier methodology approaches; for example:
– TOVE: the inclusion of competency questions as a way to scope the domain of interest
and to evaluate its conceptualization.
– Enterprise Ontology: the notions of brainstorming, the middle-out approach, and the
grouping of terms. The thorough documentation of the entire development process is
also included.
– Methontology: the inclusion of management activities.
– OnToKnowledge: the inclusion of a feasibility study before any ontology development
commences.
– CommonKADS: the focus on specific documented deliverables for every activity in the
ontology development process.
3.13. Diligent Methodology
The Diligent Methodology [102] comprises five main activities: (1) build, (2) local
adaptation, (3) analysis, (4) revision, (5) local update (see Figure 9).
The process starts by having domain experts, users, knowledge engineers and ontology
engineers build an initial ontology. Once the product is made available, users can start using it
and locally adapting it for their own purposes. In their local environment they are free to
change the reused shared ontology. However, they are not allowed to directly change the
ontology shared by all users. Furthermore, the control board collects change requests to the
shared ontology.
The board analyzes the local ontologies and the requests and tries to identify similarities in
users' ontologies. Since not all of the changes introduced or requested by the users will be
introduced, a crucial activity of the board is deciding which changes are going to be
introduced in the next version of the shared ontology. The input from users provides the
necessary arguments to underline change requests. A balanced decision that takes into account
the different needs of the users and meets user's evolving requirements has to be found. The
board should regularly revise the shared ontology, so that local ontologies do not diverge too
far from the shared ontology. Therefore, the board should have a well-balanced and
representative participation of the different kinds of participants involved in the process. Once
a new version of the shared ontology is released, users can update their own local ontologies
to better use the knowledge represented in the new version.
3.14. HCOME
HCOME [92] (A human-centered methodology to ontology engineering) provides clear
distinctions between the phases of the ontology life-cycle, goals that should be achieved in
each phase and tasks that can be performed so as to achieve these goals. The phases proposed
are: specification phase during which knowledge workers (joining groups that are about to
develop shared ontologies) are discussing requirements, produce specification documents, and
agree on the aim and the scope of the new ontology; conceptualisation phase which includes
the import of existing ontologies, for the reuse of conceptualisations, the consultation of
generic top ontologies, thesauruses and domain resources, for better understanding and
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 44 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
clarification of the domain conceptualisations, uncovering the informal human intended
semantics of the ontology specifications, the improvising of ontologies, allowing the fromscratch development of formal ontologies based on workers’ perception on the domain,
mapping, merging and management of multiple versions of ontologies, supporting reuse and
evolution, comparison of different versions of an ontology, for tracking ontologies’ evolution
and for identifying ontologies that can possibly be merged; and exploitation phase which
includes inspection of agreed or shared ontologies either by individuals in their personal space
or by collaborators in the shared space, for reviewing, evaluating and criticizing the specified
conceptualisations, comparison of shared versions of an ontology, for identifying the
differences between them and posting of arguments upon versions of ontologies for
supporting workers decisions, for or against specifications.
Figure 9: Roles and functions in distributed ontology engineering
3.15. UPON Approach
UPON (Unified Process for ONtology building) [90] is an incremental methodology for
ontology building. This process stems its characteristics from the Software Development
Unified Process, one of the most widespread and accepted methods in the software
engineering community, and uses the Unified Modeling Language (UML) to support the
preparation of all the blueprints of the ontology project.
UPON is use-case driven in that it aims at producing an ontology with the purpose of serving
its users, both humans and automated systems (e.g. semantic web services, intelligent agents,
etc.). User interactions take place through use cases that drive the exploration of all aspects of
the ontology. The nature of the process is iterative because each activity is repeated possibly
concentrating on different parts of the ontology being developed, but also incremental, since
at each cycle the ontology is further detailed and extended. The cycles proposed are: inception
phase where the first iterations are mostly concerned with capturing requirements and partly
performing some conceptual analysis;
elaboration phase where iterations analysis is
performed and the fundamental concepts are identified and loosely structured; construction
phase where some additional analysis could be still required aiming at identifying concepts to
be further added to the ontology and transition phase where testing is heavily performed and
the ontology is eventually released.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 45 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
3.16. Consensus-based Ontology Engineering Approach
Karapiperis and Apostolou [94] proposed this methodology which starts with the deployment
of an initial version of the ontology, created by the coordinator, based on the participants’
requirements. This initial version is iteratively evaluated by the participants and is finally
evolved into the final version. This approach ensures that all participants agree and accept the
resulting ontology, being a product of a joint team effort. The phases comply with
Holsapple’s phases [88].
3.17. GM Methodology
In [95] a novel modelling methodology for bio-medical ontologies is designed. A key feature
of this methodology is the use of Concept Maps (graphs consisting of nodes representing
concepts, connected by arcs representing the relationships between those nodes) throughout
the knowledge elicitation process. According to this methodology, the collaborative approach
steps’ to ontology design are: competency questions in order to identify the scope of the
ontology; the second step involves identifying reusable ontologies in order to indicate which
other ontologies should be used; linguistic phase which starts by the identification of those
reusable ontologies and terminates with the baseline ontology; iterative building of informal
ontology models; formalisation and evaluation.
3.18. iCapturer Methodology
Unlike GM and DILIGENT, iCapturer [98] makes use of text-mining approaches, such as
text-to-onto, to identify important terms and to suggest candidate ontological relationships
between them. The first step is term and relationship extraction from text containing domain
knowledge. The second is web-based, massively collaborative correction, refinement, and
extension of the automatically extracted concepts and relationships. The second step may be
divided into phases of knowledge elicitation, evaluation, and aggregation.
3.19. NeOn Methodology
NeOn25 is a framework for developing networked ontologies [99]. It is one of the most
comprehensive works in terms of ontology engineering. The framework incorporates a
methodology. The first version of the NeOn Methodology for collaboratively building
networks of ontologies was made available in February 2008. This version of the
methodology is focused on the ontology requirements specification and on the reuse and reengineering of ontological and non-ontological resources. The second version of the NeOn
Methodology for collaboratively building networks of ontologies is available since February
2009, treating other activities such as ontology design patterns reuse, modularization,
evolution, evaluation, and localization. Many of these aspects are directly relevant to the
internal details of the OASIS COF and will be taken up in more detail in WP1.2 and reported
upon in D1.2.1. There is also considerable detail concerning collaborative methods that we
are building upon directly in our ontology construction practice.
3.20. Melting Point Methodology
The overall process of Melting Point Methodology [100] starts with documentation and
management processes; the development process immediately follows. Managerial activities
happen throughout the whole life cycle. The development process has five main activities:
specification, conceptualisation, formalisation implementation and evaluation. Different
prototypes or versions of the ontology are thus constantly being created. Initially these
25
http://www.neon-project.org
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 46 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
prototypes may be unstable, as the classes and properties may drastically change. In spite of
this, the process evolves rapidly, achieving a stability that facilitates the use of the ontology;
changes become more focused on the inclusion of classes and instances, rather than on the
redefinition of the class hierarchy.
3.21. Conclusions
When making comparisons, one should keep in mind the historical context in which these
methodologies were proposed. Ontologies were recognized as an important issue for enabling
knowledge sharing, in the mid-1980s. The first ontologies had to be built from scratch and
with little methodology to guide their development. After experiments in ontology building, a
few design criteria were found (Gruber 1993). These criteria establish the properties that a
good ontology ought to have. In order to use something, one must be assured of its quality, so
ontology evaluation was already an important research topic at this time. The more ontologies
were built, the better the ontology building process was understood.
Early ontologies and their methodologies were limited with respect to either the ontology they
were built for or their domain of application. The Cyc Method was proposed in 1990, bur was
only used to build Cyc Knowledge Bases; while the Penman Upper Model methodology
worked out by Bateman and others in 1988 was restricted to linguistic ontologies. The first
methodologies for building general ontologies were proposed in 1995. This was when
Ontology Engineering proper emerged. TOVE and ENTERPRISE belong to the first
generation of ontology building methodologies. This is one of the reasons why they both lack
maintenance activities. One was just beginning to understand how ontologies were built.
TOVE methodology does not include the processes described in the evaluation framework.
Furthermore, although ontologies have been developed with this methodology the domain is
confined to business. ENTERPRISE methodology has the same omissions and is less detailed.
The initial version of METHONTOLOGY belongs to the second generation of
methodologies, so it could take advantage of the fact that ontologies were having longer life
cycles and were being re/used in more experiments. It is a very mature and specific approach
for building ontologies; however, recommendations for the pre-development processes are
needed. Additionally, it is recommended by FIPA.
Different methodologies propose different timings. Some methodologies propose that some
activities should take place during the entire ontology building life while others associate
those activities with a stage. For instance, METHONTOLOGY proposes that knowledge
acquisition is one of the activities that take place during the entire life cycle and that the effort
of acquiring knowledge usually is more significant during conceptualization than in other
stages. ENTERPRISE proposes that knowledge acquisition is one of the activities to be
performed in a particular stage of the ontology building life cycle.
Some methodologies are more appropriate for building formal ontologies and some allow for
both informal and formal ontologies to be built. ENTERPRISE allows for the construction of
informal and formal ontologies. TOVE allows the construction of formal ontologies because
they are carefully implemented in FOL. Although the ontologies built according to
METHONTOLOGY are also formal ones, the intermediate representations used to help
conceptualize knowledge simplify implementation (implementation can even be automatic).
The main problem of TOVE is the fact that, for naive ontology builders, it does not provide
much guidance on how the activities should be performed. Because it proposes FOL as the
knowledge representation language to be used, for domain experts with no knowledge
representation or engineering skills, this methodology is, in general, too vague and too
difficult to use.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 47 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
It was found that naive or inexperienced users, when given the chance, choose
METHONTOLOGY. They claim that it gives them more concrete guidelines as to what they
must do in each stage. Moreover, the intermediate tabular representations guide them as to
what knowledge from the domain they should acquire and provide an easy and intuitive
framework to formalization.
METHONTOLOGY is the methodology that provides more guidance, in particular to naive
or inexperienced ontology builders, because the intermediate representations are already
defined, are clear and easily understandable, and focus their acquisition and conceptualization
while easing formalization. However, in the case of naive users, it can focus too much on the
knowledge being acquired, because these users will be tempted to focus their acquisition on
the knowledge required to fill in the intermediate tables rather than on their actual needs.
SENSUS-based approach is completely different from the others. It allows interoperability
between systems. Domain ontologies built using SENSUS share the same high level concepts.
So, systems that use such ontologies will share a common structure of the world and it would
be easier for them to communicate. However, it does have many shortcomings the most
serious one being the inexistence of life cycle. It also has a linguistic bias which may not be
appropriate in all cases.
OTK methodology focuses on the centralized development of static ontologies. It divides
Ontology Engineering into several stages which produce an evaluated ontology for a specific
domain.
HCOME is a methodology which integrates argumentation and ontology engineering in a
distributed setting and allows for ontology evolution. It introduces three different spaces in
which ontologies can be stored. However, this methodology had neither been applied in a case
study nor have the process stages have been described in detail.
In contrast, DILIGENT is a methodology that has been applied in a case study. This
application reveals that DILIGENT is well suited for ontology engineering tasks where
distributiveness and change/evolution are of major concern. In addition it is the first
methodology which formalizes the argumentation taking place in an ontology engineering
discussion. However, DILIGENT does not support pre development activities, since these are
already well supported by other mature methodologies.
The UPON methodology includes neither a detailed evaluation of the process with respect to
the other proposals nor an analysis of how to adapt cross phase activities to the needs of
ontology building. Additionally, an important aspect that is neglected is the possibility of
assessing the quality of an ontology built with the UPON methodology.
The CONSENSUS-based ontology approach to ontology engineering may require more time
and effort to deployment as opposed to other approaches due to the iterative cycles of the
consensus building mechanism but the payback is deemed to be better in the long term. This
is because the resultant ontology is a joint effort reflecting multiple individuals’ viewpoints
instead of a single’s viewpoint that happens in the others approaches. However, the
collaborative ontology has by default the acceptance of the participants and thus pulls together
everybody to make use of it.
The GM, DILIGENT and NeOn methodologies consider the ontology to be constantly
evolving. In addition, the GM methodology also emphasises the notion of collaboration in the
development process, particularly during knowledge elicitation. The GM knowledge
elicitation relies heavily on interaction; 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
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 48 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
between the ontology and the software application in which it will ultimately be used. Within
the NeOn framework the focus is more on the network of ontologies rather than specifically
on the act of collaboration amongst domain experts. However, NeOn offers a complete review
of methods that in principle support collaboration when building ontologies; NeOn supports
the collaboration over two main axes: argumentation and collaborative editing.
Tables 1, 2 summarise the comparison information of the above methodologies. In these
tables the compliance of each approach with respect to the IEEE standard [93] is compared.
For table 1 we have merged tables from Ontoweb Project26 and [97]. To this table we have
added 9 more methodologies. The Melting Point methodology proposed reuses some
components that various authors have identified as part of their methodologies for ontology
development using the biomedical domain as an example. Thus, we have not included this
methodology in tables 1, 2.
The rows in these tables represent the different approaches, and the columns represent the
different processes proposed by the IEEE standard. Each cell of the table can be filled in with
three types of values. The value "described in detail" means that the approach establishes for
the considered activity: how to do each task, when to do it, who has to do it, etc. The value
“proposed” means that the methodology of the corresponding row identifies the process that
is written in the column as a process to be performed during the ontology development
process. The value “not proposed” means that public documentation does not mention the
non-considered aspect. According to these tables, there is no methodology with a perfect
compliance with respect IEEE standard.
In tables 3, 4 the compliance of each methodology with respect to the OASIS evaluation
metrics is compared. There is close correspondence between these evaluation metrics and
criteria derived from the work done in [100]. Lexical/Vocabulary layer can be corresponded
with C9, Structural/Architectural layer with C4, Representational/Semantic layer with C1, C2,
Data/Application layer with C3.1, C7 and finally Philosophical layer with C3.3, C6. We have
used the Enterprise Methodology; the TOVE Methodology; the Bernaras methodology; the
METHONTOLOGY methodology; the SENSUS methodology; the DILIGENT methodology;
the GM methodology; the iCAPTURer Methodology and the NeOn methodology from [100]
and followed the same procedure for the remaining methodologies.
26
http://www.aifb.uni-karlsruhe.de/WBS/ysu/publications/OntoWeb_Del_1-4.pdf
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.3
PUBLIC
Page 49 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Feature
Project
Management
Processes
Project Initiation
Control
Quality Management
Environment
Ontology
PreStudy
Development development
Feasibility
Oriented
processes
Study
Activities
Development Requirement
s
Processes
Design
Postdevelopment
Processes
Implementat
ion
Installation
Maintenance
Retirement
Integral
Processes
Knowledge acquisition
Verification & Validation
Ontology Configuration
Management
Documentation
Training
Cyc
Uschold
&King’s
Grüninger KACTUS METHON SENSUS
& Fox’s
TOLOGY
OTK
DILIGENT
HCOME
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Described
in detail
Described
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Proposed
Described
From OTK
Described
From OTK
Described
From OTK
Proposed
From OTK
Described
From OTK
Described
in detail
Described
Described
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Proposed
Described
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Proposed
Not
Proposed
Not
Proposed
Proposed
Proposed
Proposed
Not
Proposed
Proposed
Not
Proposed
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Proposed
Described
Not
Proposed
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Described in
detail
Described in
detail
Described in
detail
Not
Proposed
Proposed
Not
Proposed
Described in
detail
Described in
detail
Described in
detail
Described in
detail
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Proposed
Not
Proposed
Described
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Proposed
Described
Described in
detail
Described
Proposed
Described
Described
Proposed
Described in
detail
Described
Described
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Described
Not
Proposed
Described
Proposed
Proposed
Proposed
Proposed
Described
From OTK
Described
From OTK
Proposed
Proposed
Not
Proposed
Table 1: Approaches' proposed ontology development process
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 50 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Consensus Holsapple Common DOGMA
based
KADS
Feature
Project
Management
Processes
Project Initiation
Control
Quality Management
Ontology
PreDevelopment development
Oriented
processes
Activities
Development
Processes
Environment
Study
Feasibility
Study
Requirements
Design
Implementation
Postdevelopment
Processes
Installation
Maintenance
Retirement
Integral
Processes
Knowledge acquisition
Verification & Validation
Ontology Configuration
Management
Documentation
Training
Not
Proposed
Not
Proposed
Not
Proposed
Described
detail
Described
detail
Described
detail
Described
detail
Described
detail
Not
Proposed
Described
detail
Not
Proposed
Described
detail
Described
detail
Proposed
UPON
ROD
iCapturer NeOn
Not
Proposed
Not
Proposed
Not
Proposed
Described
Not Proposed
Described
Not
Proposed
Not
Proposed
Not
Proposed
Described
Not
Proposed
Not
Proposed
Not
Proposed
Proposed
Proposed
in
Not
Proposed
Not
Proposed
Not
Proposed
Proposed
Described
Not
Proposed
Proposed
in
Proposed
Proposed
Described
Proposed
Described
Described
Described
in
Proposed
Described
Described
Proposed
Proposed
Described
in
Proposed
Described
in detail
Described
Proposed
Described
Proposed
Proposed
Described
in
Proposed
Described
Not Proposed
Described
Proposed
Proposed
Described
Not
Proposed
Proposed
Not Proposed
Not
Proposed
Proposed
Not
Proposed
Proposed
Not Proposed
in
Not
Proposed
Proposed
Not
Proposed
Proposed
Not
Proposed
Proposed
Not Proposed
Proposed
Not
Proposed
Described
Not
Proposed
Proposed
Not Proposed
in
Not
Proposed
Proposed
Described
Not
Proposed
Proposed
in
Proposed
Proposed
Not Proposed
Described
Proposed
Proposed
Not
Proposed
Proposed
Not Proposed
Proposed
Proposed
Not
Proposed
Described
Proposed
Proposed
Not
Proposed
Proposed
Proposed
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not Proposed
Proposed
Described in
detail
Not
Proposed
Described in
detail
Not
Proposed
Not Proposed
Not
Proposed
Not Proposed
Proposed
Not Proposed
Not
Proposed
Proposed
GM
Not Proposed
Not Proposed
Proposed
Proposed
Proposed
Proposed
Described in
detail
Described in
detail
Described in
detail
Described in
detail
Described in
detail
Proposed
Described
Not Proposed
Described in
detail
Described in
detail
Described in
detail
Described in
detail
Not Proposed
Table 2: Approaches' proposed ontology development process
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 51 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Evaluation Metrics
Internal
Layers
Lexical/Vocabulary
(includes criteria relevant to the
syntactic elements of ontologies)
Structural/Architectural
(includes criteria relevant to the
structural attributes of ontologies)
Representational/Semantic
Cyc
Uschold
&King’s
Grüninger KACTUS METHON SENSUS
& Fox’s
TOLOGY
OTK
DILIGENT
HCOME
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Not
Proposed
Limited
Described
Limited
Limited
Described
Limited
Not
Proposed
Limited
Described
Proposed
but
not
described
Described
Described
Limited
Not Proposed
Proposed
but
not
described
Described
Limited
Limited
Described
Described
Limited
Described
Described
Limited
Described
Described
Described
Described
Described
Described
Described
Limited
Proposed
but
not
described
Proposed
but not
described
Not
Proposed
Not
Proposed
Described
Described
Not Proposed
Described
Described
Described
Described
Not
Proposed
Described
Not
Proposed
Described
Described
Described
(includes criteria relevant to the
semantic elements of ontologies)
Data/Application
(includes the applicability of an
ontology in a given application
domain)
Philosophical
(includes the relation to existing
upper level ontologies or general
lexical resources)
External
Layers
Usability
(includes quality measures that are
required in order to ensure that the
resulted ontologies satisfy a set of
usability standards)
Table 3: Evaluation metrics supported by Methodologies
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 52 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Evaluation Metrics
Internal
Layers
Lexical/Vocabulary
Consensus Holsapple Common DOGMA
based
KADS
ROD
iCapturer
NeOn
Not
Proposed
Not
Proposed
Not Proposed
Not
Proposed
Described
Described
Described
Described
Described
Described
Limited
Described
Not
Proposed
Described
Described
Described
Not
Proposed
Described
Limited
Limited
Described
Limited
Described
Limited
Described
Described
Described
Described
in detail
Described
Described
Described
in detail
Described
Described
Proposed
but not
described
Limited
Described
Not
Proposed
Not
Proposed
Described
Not
Proposed
Described
Described
Described
Described
Described
Described
Described
Described
Described
Described
Not
Proposed
Described
Described
(includes criteria relevant to the
structural attributes of ontologies)
Representational/Semantic
GM
Described
(includes criteria relevant to the
syntactic elements of ontologies)
Structural/Architectural
UPON
(includes criteria relevant to the
semantic elements of ontologies)
Data/Application
(includes the applicability of an
ontology in a given application
domain)
Philosophical
(includes the relation to existing
upper level ontologies or general
lexical resources)
External
Layers
Usability
(includes quality measures that are
required in order to ensure that the
resulted ontologies satisfy a set of
usability standards)
Table 4: Evaluation metrics supported by Methodologies
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 53 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
4. Typology for the characterisation of ontologies
4.1.
Evaluation Metrics for Ontologies
This section presents a set of ontology evaluation metrics in order to produce a set of
dimensions of classification and measurement, plus criteria of best ontology design, that can
guide the decision-making process concerning ontology import, re-use, re-design,
modularisation or rejection. Particular visualisations are to be found for the results, such as
the one illustrated in Figure 1 which has been developed within the OntologySummit 2007 for
several current top-level upper ontologies.
Figure 10: A visualization of the different dimensions of ontology classification
These dimensions of classification will be expanded upon below: in essence the diagram
allows us to compare several ontologies with respect to their ‘fit’ to various desired criteria.
Finding the criteria which are appropriate for the purpose of defining a methodological
approach for ontology refinement and re-structuring and specifying how these criteria can be
operationalised is a major initial concern. The values of the dimensions shown here were
established by peer-review; however, several (e.g., expressiveness) are amenable to formal
validation by automatic means. Such automatic measures also need to be strengthened. We
will no doubt need more of these kinds of diagrams, for particular combinations of types of
features.
We distinguish between internal and external measures. Internal measures are concerned with
the ontologies themselves, their internal organisation, naming conventions, representation and
so on. The external measures are concerned with their take-up and use within user
communities, their role as standards, embedding within business practices and so on.
The basic internal dimensions, seen as ‘layers’, considered so far are:
 lexical/vocabulary layer
 structural/architectural layer
 representational/semantic layer
 data/application layer
 philosophical layer
The basic external dimensions considered so far are:
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 54 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754






User dependence: how many users depend on the ontology? (i.e., what is the impact of
change to the ontology? Should this be avoided or is it simple to implement?)
Is the ontology used as a medium of information exchange across distinct
communities?
Is it documented? If so, in what form? (natural language, UML, logical spec, etc.)
Is it a national or international standard?
Is it a de facto working standard for some community?
Usability layer
Consideration is being given to the extent to which some of these at least can be automated.
This requires a machine-readable form to be available. There are many distinct kinds of
information that may be drawn on as potential ‘ontologies’.
The ontology assessment layers may be applied to any of these kinds of information entities,
although clearly with less formally specified ontologies fewer answers may be obtained. In
more detail the assessment layers are described in the following sections.
4.1.1. Internal: Lexical / Vocabulary layer
This layer includes criteria relevant to the syntactic elements of ontologies. We identify the
following criteria.
 Naming criteria: formulate “good” terms and definitions
o essential features to be satisfied by all naming conventions
(e.g., nominal, verbal, etc. plus other styles)
o no circularity in definitions
o intelligibility (documented?, logically defined?)
o positive naming (no junk categories, minimal ‘other’ categories)
o consistent (no contradictions).

Syntax
o syntactic correctness (automatic checkers available?)
o breadth of syntax used (restricted formalism?).

Governance
o are the terms regulated by a government body, international standard, etc.
4.1.2. Internal: Structural / architectural layer
A very important class of criteria is the one that characterises the structural attributes of
ontologies. These form the structural / architectural layer, which includes:
 Characterization of ‘ontology’ as machine-readable data:
o Which? (UML, DB-Schema, …)? Availability of tools.
o Purpose?:
CERTH/ITI
14/07/2009

Controlled vocabulary.

Taxonomy.

Thesaurus.

Ontology proper.
D1.1.1 – vers. 4.5
PUBLIC
Page 55 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754


Data Models.

Object Models.
Ontologies as graph structures:
o size (how many concepts, relations, etc.)
o depth of hierarch
o breadth of hierarchy
o density (average branching)
o balance (are all areas equally developed or are there areas of low
complexity and others with high complexity)
o overall complexity
o connectivity between concepts, relations, etc. (highly interconnected?
Loosely interconnected, e.g., only by isa-links?).

Richness of relationships, attributes, inheritances (isa, type-of, subclass, part-of,
instance-of, multiple inheritance).

Reasoning (required tasks).

Modularization (what modules are defined? How are they defined? How is re-use,
import, export of modules regulated, if at all?).
4.1.3. Internal: Representational / semantic layer
This layer includes criteria relevant to the semantic elements of ontologies. These concern
those attributes whose goal is to conceptually describe the structural elements defined within
each ontology. Specifically, this layer consists of the following criteria:
 Match between formal and cognitive semantics (cognitive adequacy).

Consistency (no formal contradictions).

Expressiveness (ontology language used: SHIQ, SHOQ, ALC, RCC, FOL, others).

Clarity (context, background knowledge).

Explicitness.

Interpretability (formal, informal, logical specifications, documentation).

Accuracy.

Comprehensiveness (extent of target domain covered).

Granularity (fine-grained coverage vs. loose coverage).

Relevance (for application and users).

Prescriptive vs. descriptive (i.e., does it try and describe the world, or does it
regulate how some portion of the world must be ?)
4.1.4. Internal: Data / Application layer
The applicability of an ontology in a given application domain, as well as the availability of
data to define a set of measurable evaluation metrics is the subject of the Data / Application
Layer. This takes into account the following attributes:
 Data-based evaluation:
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 56 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
o corpus of text representing a given domain
o measure fitness between ontology and corpus terms (congruency)
o refinements: keyword expansion (cluster analysis).

Application-based evaluation:
o precision, recall, accuracy measures


compare results with expected results

compare results with a gold standard.
For-application implementation
o formal mechanisms used (DB, DL-reasoner, etc.)
o query simplicity (query language and support tools).

Application area.

Application users: group-specific or general?
4.1.5. Internal: Philosophical layer
The philosophical layer addresses the following issues:
 OntoClean methodology commitment

Inherent consistency checking / detect contradictions: is this considered necessary?

Essential ontological foundational decisions: are any of the following knowingly
adhered to / considered?

Explicit relation to existing upper level ontologies or ontological modules?

Explicit relation to existing general lexical resources (e.g., WordNet, etc.) or
existing application/domain-specific terminologies.
4.1.6. External: Usability layer
The external layer of usability defines those quality measurements that are required in order to
ensure that the resulted ontologies satisfy a set of usability standards. This layer includes the
following attributes:
 Recognition (easy and effective access, complete documentation)

Efficiency (organizational/developmental annotations)

Interfacing

Modifiability

Versioning

Re-usability

Availability

Purpose:
o Human communication (HC)
o HC + Structure information base; browsing
o HC + Structure digital libraries; indexing, browsing & search
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 57 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
o
o
o
o
4.2.
Union of all the others & more.
HC + Structure (and validate) databases.
HC + Structure software systems.
System-internal functionality only
Metrics and their support by languages and tools
Though metrics is understood as a characterization of an ontology it depends to some extend
also on the language used to formalize the corresponding ontology. An immediate example in
the representational / semantic layer is the expressiveness of the ontology. Moreover, some
aspect of the metrics can depend even on the tool used to develop the ontology. A striking
example in this case is versioning.
This section summarizes such dependencies, however not for all languages and tools listed in
chapters 5 and 6, respectively. We will concentrate here on the languages OWL and CASL –
more precisely the corresponding language families – and the corresponding tools Protege and
Hets for the following reasons: OWL has become the defacto standard for description logic
(DL) based ontology languages. Moreover, it has with Protege the best tool support for
development of ontologies expressible in a DL. CASL is a formal language whose
expressiveness is beyond DL and has a rich structuring mechanism that facilitates modularity
in a more flexible way than OWL . Like Protege for OWL, Hets is the tool to develop and
manage formal ontologies in CASL. CASL is the outcome of several years research on formal
languages in the realm of formal system specification. It covers the essential features of
almost all previous specification languages and thus can be considered as a state of the art
general specification language (http://www.informatik.uni-bremen.de/cofi/wiki/index.php),
similar to the ANSI-standard Common Logic framework but with more tool support and
mature underlying technology.
Most of the ontology metrics presented above do not depend on languages and tools thus we
will mention in the following only those that do depend.
Internal: Lexical / Vocabulary layer

Syntactic correctness (automatic checkers available?) Syntax checker are available
for OWL and CASL
Internal: Structural / architectural layer

Characterization of ‘ontology’ as machine-readable data:
o Which? (UML, DB-Schema, …)? Availability of tools. There exist more
tools for OWL than for CASL

Ontologies as graph structures: Tools that make use of the OWL API and Protege
allow to compute statistics on ontologies as graph structure, like size (how many
concepts, relations, etc.) and depth of hierarchy. Hets does not provide a
comparable statistic feature. Protege provides graph visualization of ontologies,
Hets does not. Hets supports a graph visualization of the network of ontology
modules, Protege does not.

Reasoning (required tasks). Protege connects to DL reasoners whereas Hets
connects in addition to first order and higher order reasoners.

Modularization (what modules are defined? How are they defined? How is re-use,
import, export of modules regulated, if at all?). CASL supports much more
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 58 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
powerful structuring mechanism than OWL. And they are supported by the Hets
system.
Internal: Representational / semantic layer

Consistency (no formal contradictions). Due to its restricted expressiveness OWL
consistency checks are always decidable. In the more expressive languages CASL
consistency check is in general a hard task.

Expressiveness (ontology language used: SHIQ, SHOQ, ALC, RCC, FOL, others).
OWL is restricted to description logics whereas CASL supports first-order and
higher-order logics.

Explicitness. Due its higher expressiveness CASL can be more explicit than OWL.
Internal: Data / Application layer

formal mechanisms used (DB, DL-reasoner, etc.): Racer-DL(and Jena?) can be
used for instance retrieval. Other reasoners (e.g. Pellet) are rather used for
consistency, conservativety, or entailment reasoning. Both reasoners can be
connected to Protege and Hets.

query simplicity (query language and support tools): nRQL (I.e. Racer's query
language) has an easy syntax and SPARQL is a wide spread standard.
Internal: Philosophical layer

OntoClean methodology commitment: OntoClean methodology cannot be applied
fully to OWL, as it requires a more expressive language.

Explicit relation to existing upper level ontologies or ontological modules:
foundational ontologies like DOLCE can be only approximatively formalized in
OWL, but fully in CASL.
External: Usability layer

Recognition (easy and effective access, complete documentation): CASL,
description logic is easy to read and write, OWL in XML is not.
Versioning: OWL/CASL tools currently make use only of at most traditional versioning (e.g.
cvs, svn); semantic versioning is under development in independent projects.
4.3. OASIS Methodological Approach for Ontology Evaluation and
Refinement based on architectural and design aspects
4.3.1. Introduction
In the context of computer and information sciences, an ontology defines a set of
representational primitives with which to model a domain of knowledge or discourse, while in
the context of database systems, ontology can be viewed as a level of abstraction of data
models, analogous to hierarchical and relational models, but intended for modeling
knowledge about individuals, their attributes, and their relationships to other individuals [52].
An introductory guide about creating/developing an ontology for the first time and a simple
knowledge-engineering methodology about ontologies are given in [53].
Building an ontology or an ontology network is not always an easy process. First of all, the
purpose has to be defined; that is, why it is necessary to build the ontology, where it is going
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 59 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
to be used, what are the requirements that have to be met, etc. Next, the activities involved in
the ontology development process must be specified, what is the goal of each activity, how
they are related with each other, etc. Finally, one of the most important decisions that has to
be taken is whether the ontology will be built from scratch without reusing existing resources
or it will be developed by reusing other resources (ontological or non-ontological). In the
latter case, it must also be decided whether more than one ontology modules have to be
merged or not, if a reengineering/restructuring phase is necessary, etc.
4.3.2. Reusing Existing Candidate Ontologies
Creating a new ontology for a specific application from scratch is usually a time-consuming
and cost-inefficient task. It is a procedure that involves not only the creation of classes,
properties, instances, etc, but also the initial phase of designing the ontology itself. The latter
is usually more difficult to decide since it concerns the structure and architecture of the
ontology, the hierarchy/taxonomy to be followed, and other issues like how descriptive the
ontology will be, its overall complexity, reusability, etc.
Therefore it is a common practice, when a new ontology is necessary to describe a domain or
to be used as part of an overall application, to consider reusing one or more of existing
candidate ontologies created before for similar use. After all, several applications can use the
same domain ontology to solve different problems, and the same problem-solving method can
be used with different ontologies. Furthermore, reusing other ontologies (possibly validated
through use in practice) may save significant effort and helps interacting with different
development tools.
However, this practice often results in some problems that arise when the existing ontology is
to be applied in the new application environment. These problems make indispensable an
improvement/restructuring phase to be accomplished, so that existing ontologies become
more suitable to be reused, trying to meet some formal requirements of the new framework
where they are going to be incorporated.
The most important aspects to be considered during the restructuring phase are analyzed
below. They stem from practical experience (a specific example will be given later) and
designate the necessary steps to be followed so as to improve the initial form of the candidate
ontology to be reused. These issues are then taken in addition to the general methodological
concerns of the previous chapter, which focus more on overall lifecycle development.
4.3.3. General Restructuring Issues
In this subsection some general aspects on restructuring are discussed in more detail.

Concept Hierarchy/Taxonomy
This issue refers to the structural/architectural layer of the ontology. It is related to metrics
such as the size, the depth, and the breadth of hierarchy, the density (average branching of
concepts), etc, which define the overall complexity of the ontology. A flat concept hierarchy
for example usually means that there are too many concepts on the same level and implies the
existence of unexploited grouping possibilities for concepts of similar kinds, e.g. to be
grouped together under one more general concept. Another example is the existence of
branches very differently structured than others (e.g. very big depth), which results in an
unbalanced taxonomy. Finally, the level of abstraction (to which the concepts refer) is not
always taken into careful consideration, resulting in an inappropriate structure design.
All of the above aspects need to be considered during the restructuring phase. For instance, a
flat concept hierarchy can be converted to a more “arborescent” (tree-like) structure, so as to
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 60 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
reduce the number of concepts on the same level. Exploiting the grouping possibilities for
concepts of similar kinds results in a better grouping and a more clear reorganized structure
for the ontology. A more appropriate structure design can also be achieved by putting on the
same hierarchy level the concepts referring to the same level of abstraction. Finally, the
structure of branches which are very different than others can change in order to have a more
balanced and equally developed hierarchy.

Property Structure
This issue, like the previous one, refers to the structural/architectural layer of the ontology and
is also related to metrics such as the size, the depth/breadth of hierarchy, density and
complexity of the ontology, etc. It is often observed that there is no structuring for the
properties of an ontology, which are usually not hierarchically grouped at all. In such a case, a
restructuring might be possible by exploiting grouping possibilities for properties of equal
domains/ranges or their functions. Therefore, the relations between concepts and various
function-related requests are more directly and easier accessible. For example, if the
properties of a concept are subsumed as a more general property, a request could get all
information at once if that is requested.
A restructuring on the properties of the ontology can reduce the number of properties on the
same level and produce a more tree-like structure. Furthermore, a better hierarchical grouping
results in a more concrete and understandable structure design. Finally, if further information
might be interesting to describe a specific concept, new properties may be added for
enrichment and better description.

Repetition of Similar Ontological Concepts
Another issue that refers to the structural/architectural layer of the ontology and has to do with
modularization (e.g. what modules are defined in the ontology, how they are defined, if they
can be imported/exported/reused, etc). If similar ontological concepts are repeated frequently
throughout the structure, they can possibly be combined to one module and reused whenever
necessary. Hence, repeated concepts can be defined only once and their use be extended
within other definitions. However, such a reuse mechanism is not always applicable. For
example, it cannot be applied in OWL-DL (Web Ontology Language – Description Logic), a
subset dialect of OWL-Full [54] that is optimized for reasoning and knowledge modeling.
Nevertheless, this reuse mechanism can be implemented in other languages where it is
supported. Such a language is CASL (Common Algebraic Specification Language), a
standardized first-order specification language designed by CoFI (Common Framework
Initiative for algebraic specification and development) [57] and approved by IFIP-WG1.3
(Foundations of System Specifications) [58]. In this case, similar subclass principles that
divide some classes into specific subclasses, can be specified as a distinct module only once
and extend their use within other specifications.
Avoiding repeating similar ontological concepts makes the maintenance of the specified
modules easier (e.g. if something has to be added or removed) and it is also easier to keep
track of the naming in general (less typing errors, always the same naming, etc). In any case,
the definition of modules depends on the language to be used, what is intended to represent,
and the applicability of reusing the modules.

Subtraction of Modules
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 61 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
This issue is closely related to the previous one, since it might be interesting to subtract
modules in general (either functional or logical) from the whole ontology. Such an action can
reduce the overall complexity and elucidate dependencies between various ontology parts. It
also happens sometimes that, after building the ontology for the first time, it is neglected to go
through a refinement phase. Hence, it is often observed that there exist some duplicate
definitions of the same concept or concepts which are very similar (or almost identical to each
other). In such a case, it is necessary to eliminate duplicate definitions and remove similar
concepts or merge them to a single one. Moreover, there might be properties initially created
for some purpose, but finally never used at all. These properties should also be removed. All
these steps usually result in an ontology of reduced complexity, more “clear”, compact and
readable.

Documentation/Visualization
This issue refers to the lexical/vocabulary layer of the ontology, which has to do with naming
criteria/conventions, consistency in naming, documentation, syntax (syntactic correctness,
breadth of syntax used), governance in used terms, etc.
Documenting an ontology and dealing with visualization are issues that are usually left as a
final task and, sometimes, they are never taken care of in the end. Hence, the ontology is
finally poor documented, with few or almost no comments at all and, as a result, difficult to
use and understand, especially for users who want to apply/reuse it (for example, for their
own application). In such a case, the documentation and visualization of the ontology should
be improved and comments should be added for a better description and clarification of
various ontology parts. As a result, the ontology will become easier and more suitable to be
applied, reused, and incorporated in other applications.
4.3.4. More Specific Comments and Suggestions on Restructuring
In this subsection some more specific notes and remarks on modifying/improving an existing
candidate ontology are discussed in more detail.

Domain/Range Definition of Properties
This is an issue that affects the accuracy, comprehensiveness, explicitness/clarity in
expression, and consistency in ontology definition. The existence of properties which do not
define their domain/range can cause significant inconsistencies when using the ontology.
Another common case is the existence of object properties which do not define their range,
but instead they appear in restrictions of concepts, in which the range is set (as a condition of
the concept). In such a case, the range of properties should be directly specified. This could
avoid inconsistencies, when it is defined from the beginning which types of ranges are
possible.

Disjointness Restrictions
This is an issue that mainly affects the usability of the ontology when it comes to be used as
part of an overall application (e.g. when instances are added, forms are created, queries have
to be answered, etc). Although most concepts inside the ontology are usually pairwise disjoint
with each other, this condition is sometimes missing for some concepts. On the other hand,
for some other concepts disjointness might not hold, but where there might be an overlap. In
such a case, if for example there may exist an individual that is an instance of two classes,
disjointness restriction should be removed from these two classes.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 62 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
In general, the issue of disjointness restrictions should be considered more carefully. That is,
for concepts where it is necessary, the missing disjointness condition should be added.
Similarly, for some other concepts where an overlap may occur and a specific individual may
be an instance of all of them, disjointness does not hold and they should not be made pairwise
disjoint with each other.

Naming Conventions
This issue refers to the lexical/vocabulary layer of the ontology, like the comments and
suggestions made on documentation/visualization which were discussed earlier. It has to do
with the formulation of “good” terms and definitions, where essential features should be
satisfied by all naming conventions (e.g. nominal, verbal, etc). Circularity in definitions
should be avoided and junk categories should be eliminated.
As an example, there may be some concepts modeling similar kinds of information. These
concepts usually begin with the same prefix and end with a different suffix (or inversely).
However, it is often observed that not always the same prefix/suffix is used. In such a case,
these concepts should be aligned for reasons of clearness and follow the same naming
conventions (begin with the same prefix or end with the same suffix). Furthermore,
plural/singular forms and the use of camel case/underlines should not be mixed. It is often
proposed as a common practice to adopt using camel case and singular form throughout the
ontology. The concept names usually begin with an upper case letter and the property names
with a lower case one.
4.4.
A Case Study Example: Restructuring the ASK-IT Ontologies
The restructuring issues discussed in detail in the previous section constitute the most
important aspects to be considered during the refinement/improvement phase of an existing
candidate ontology. They define the necessary steps of a procedure to be taken so as to
properly modify the ontology, that is, they constitute a guidance which can be followed in
similar cases. The actions performed by such a process aim to make the ontology more
suitable to be reused, trying to meet some formal requirements of the new application
environment where it is going to be incorporated.
In this section a specific example of following the above steps will be presented. It concerns
the ontologies of ASK-IT (Ambient Intelligence System of Agents for Knowledge-based and
Integrated Services for Mobility Impaired Users) [59] which were initially developed for the
needs of this project. These ontologies were recently proposed to be incorporated into the
design and implementation of the Common Ontological Framework (COF) of the OASIS
project (Open architecture for Accessible Services Integration and Standardization) as
described in the chapters above. However, in order to meet the formal requirements of the
OASIS COF and become more suitable to be reused, a refinement/improvement has been
accomplished for the ontologies of the ASK-IT project. This restructuring process is described
in detail below.
4.4.1. The ASK-IT Ontologies
The ontologies developed within the ASK-IT project are the following:
 Personal Support Services
 Social Relations and Community Building Services
 Touristic and Leisure Related
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 63 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
 Transportation
 Work, Business and Education Support Content
For these ontologies, real-life content 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 supported
services. The ontologies were authored using the Protégé tool [60] and were stored in OWL
format, because the latter is widely supported by the most common freely available tools and
represents the most stable standard among the available ontology description languages. The
OWL plug-in of Protégé was used in order to save and maintain the ontologies in the OWL
language. The ontologies were developed as follows.
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 models, new
knowledge was incorporated in the form of the ASK-IT ontologies encoded in OWL format.
The main feature of the ontologies is that they were basically developed to cover for the first
time the specific needs of various impaired categories user groups (mobility impaired,
cognitive impaired, psychological impaired, etc). They define the interrelationships that may
rationally hold between the ASK-IT user groups and various user information needs of
different content types. Within the ontologies all user information needs are annotated in a
common way to enable ease search and retrieval of information that covers specific user
needs upon requests. 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, the available services were
semantically described inside the ontologies.
These ontologies can all be used within the OASIS COF but without OASIS-compliance
concerning method and internal formal properties. These extensions, involving further
modularization as suggested above, are being addressed further within WP1.2 as part of the
contruction of the hyper-ontology. The following section describes how this has already been
explored and carried out with respect to several of the formal metrics for ontology design
described here.
4.4.2. The Refinement/Improvement Process
All of the ASK-IT ontologies in their initial form suffered from the same problems addressed
in the previous section. Therefore, a restructuring has been accomplished, so that the
ontologies become more suitable to be reused and meet the formal requirements of the OASIS
Common Ontological Framework. The ontology “Touristic and Leisure Related” will be used
as an example to describe the appropriate actions performed for refinement and improvement.
It is noted however, that the same template principles have also been applied by following
similar guideline steps to the rest of the ASK-IT ontologies.
Tables 9, 10, 11, 12 summarise the comparison information of the above methodology. For
tables 9, 10 we have used general restructuring issues as they are derived from protégé
(ontology metrics). Table 11 describe Concept/Hierarchy Restructuring Issues and finally in
table 12 some more specific notes and remarks on modifying/improving ASK-IT ontologies
are discussed in more detail. The rows in these tables represent the different criteria, and the
columns represent the different ASK-IT ontologies (old and new version).
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 64 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754

Concept Hierarchy/Taxonomy
The flat concept hierarchy of the ASK-IT Touristic and Leisure Related ontology has changed
to a more “arborescent” (tree-like) structure. Now there are only 67 (instead of 111) concepts
on the same level underneath the top level concept “ASK-IT.TourismAndLeisureOntology”.
The concepts of the ontology have been reorganized by exploiting the grouping possibilities
for concepts of similar kinds. Hence, a more clear structure has been achieved, where the
concepts referring to the same abstraction level are placed on the same hierarchy level.
Finally, the structure of branches which were very different than the others (regarding depth,
breadth, etc.) has changed in order to have a more balanced (equally developed) hierarchy.
The following figure presents two examples of concept hierarchy/taxonomy restructuring. In
the first one, the concepts “Bar”, “Cafe”, and “Restaurant” have been grouped together under
the more general concept “FoodAndDrink”. Since the latter is a concept referring to a higher
level of abstraction and contains places where someone can eat and drink something, it was
obviously more appropriate for concepts “Bar”, “Cafe”, and “Restaurant” to become members
(subclasses) of “FoodAndDrink”. In the second example, the concepts “Climate”,
“MeanTemperature”, and “Temperature” were all on the same hierarchy level. However,
“Climate” refers to a higher level of abstraction than “MeanTemperature” and “Temperature”.
The latter two concepts are characteristics of weather, so they were placed as subclasses of a
new concept “Weather”, which in turn became member of “Climate”.
Before
After
Bar
Cafe
Restaurant
FoodAndDrink
Bar
Cafe
Restaurant
Climate
MeanTemperature
Temperature
Climate
Weather
MeanTemperature
Temperature
Figure 11: Examples of concept hierarchy/taxonomy restructuring
Other characteristic examples (not presented in the figure above) are the following. “Doctor”
and “Hospital” were grouped together under the more general concept “MedicalService”. “ATM”
became member of the higher abstraction level concept “Banking”, “Gym”, “Sauna”, and “Walk”
of “Athletics”, “Refuge” of “Accommodation”, “Cinema” and “Theatre” of “Entertainment”,
etc.
The OWL code for the first example of Figure 11 is presented below. It can be seen that
initially the classes “Bars”, “Cafe”, and “Restaurant” were all members of the top level class
“ASK-IT_Ontology_TourismAndLeisure”. However, after the restructuring phase these classes
became members (subclasses) of the (higher abstraction level) class “FoodAndDrink”, which in
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 65 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
turn became subclass of “ASK-IT.TourismAndLeisureOntology”. Similar OWL code can also
be provided for the second example of Figure 11 (the code is omitted because it is quite
similar to that of Table 5).
Before
<owl:Class rdf:about="#Bars">
<rdfs:subClassOf rdf:resource="#ASK-IT_Ontology_TourismAndLeisure"/>
</owl:Class>
<owl:Class rdf:about="#Cafe">
<rdfs:subClassOf rdf:resource="#ASK-IT_Ontology_TourismAndLeisure"/>
</owl:Class>
<owl:Class rdf:about="#Restaurant">
<rdfs:subClassOf rdf:resource="#ASK-IT_Ontology_TourismAndLeisure"/>
</owl:Class>
After
<owl:Class rdf:about="#FoodAndDrink">
<rdfs:subClassOf rdf:resource="#ASK-IT.TourismAndLeisureOntology"/>
</owl:Class>
<owl:Class rdf:about="#Bar">
<rdfs:subClassOf rdf:resource="#FoodAndDrink"/>
</owl:Class>
<owl:Class rdf:ID="Cafe">
<rdfs:subClassOf>
<owl:Class rdf:about="#FoodAndDrink"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#Restaurant">
<rdfs:subClassOf rdf:resource="#FoodAndDrink"/>
</owl:Class>
Table 5: OWL code for the first example of Figure 11

Property Structure
A restructuring has been realized on the properties of the ontology, since there was no
property structure in its initial form and there existed 290 properties not hierarchically
grouped at all. As a consequence, the number of datatype properties on the same top level has
been reduced from 198 to 86. This was achieved by exploiting for example grouping
possibilities for properties of equal domains. Hence, the properties of the ontology have been
hierarchically grouped to form a more concrete and tree-like structure (like the new concept
hierarchy). Furthermore, new properties have been added for better description and
clarification of some concepts, in certain cases where further information might be interesting.
The figure below presents a demonstrative example of hierarchically grouping properties of
equal domain, adding also new interesting properties. This example can be seen together with
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 66 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
the corresponding one of Figure 11. The properties “dayValue” and “nightValue” (which are
both
properties
of
“MeanTemperature”)
have
been
subsumed
as
“generalInfoOfMeanTemperature”, while “minValue” and “maxValue” (which are both properties
of “Temperature”) have been subsumed as “generalInfoOfTemperature”. Next,
“generalInfoOfMeanTemperature” and “generalInfoOfTemperature”, together with the new
added properties “cloudy”, “rainy”, “snowy”, and “sunny” were subsumed as
“generalInfoOfWeather”, which finally became subproperty of “generalInfoOfClimate”.
Before
dayValue
nightValue
minValue
maxValue
After
Domain:
MeanTemperature
Domain:
Temperature
generalInfoOfClimate
generalInfoOfWeather
generalInfoOfMeanTemperature
dayValue
nightValue
generalInfoOfTemperature
minValue
maxValue
cloudy
rainy
snowy
sunny
Figure 12: Example of equal domain properties restructuring
Other examples (not presented in the figure above) are the following. The properties
“roomFacility”, “roomPrice”, and “roomType” were all grouped together under
“generalInfoOfAccommodation”. Furthermore, the new properties “dietRelatedFood” and
“vegetarianFood” were added as properties of class ““Restaurant”” and subsumed as
“generalInfoOfRestaurant”. The latter one, together with “noAlcoholicDrink”, were placed
under “generalInfoOfFoodAndDrink”.
The OWL code for restructuring the properties of Figure 12 is presented below. It can be seen
that initially the properties “dayValue”, “nightValue”, “minValue”, and “maxValue” were not
hierarchically grouped at all. However, after the restructuring phase, “dayValue” and
“nightValue” were made subproperties of “generalInfoOfMeanTemperature”, while “minValue”
and “maxValue” were made subproperties of “generalInfoOfTemperature”. Finally, the
properties “generalInfoOfMeanTemperature” and “generalInfoOfTemperature” were made
subproperties of “generalInfoOfWeather”. Similar OWL code can also be provided for the rest
of Figure 12 properties, e.g. “cloudy”, “rainy”, etc. (the code is omitted because it is quite
similar to that of Table 6).
Before
<owl:DatatypeProperty rdf:ID="dayValue">
<rdfs:domain rdf:resource="#MeanTemperature"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>
</owl:DatatypeProperty>
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 67 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
<owl:DatatypeProperty rdf:ID="nightValue">
<rdfs:domain rdf:resource="#MeanTemperature"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="minValue">
<rdfs:domain rdf:resource="#Temperature"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="maxValue">
<rdfs:domain rdf:resource="#Temperature"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>
</owl:DatatypeProperty>
After
<owl:DatatypeProperty rdf:ID="generalInfoOfMeanTemperature">
<rdfs:subPropertyOf rdf:resource="#generalInfoOfWeather"/>
<rdfs:domain rdf:resource="#MeanTemperature"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="generalInfoOfTemperature">
<rdfs:subPropertyOf>
<owl:DatatypeProperty rdf:ID="generalInfoOfWeather"/>
</rdfs:subPropertyOf>
<rdfs:domain rdf:resource="#Temperature"/>
</owl:DatatypeProperty>
<owl:FunctionalProperty rdf:ID="dayValue">
<rdfs:subPropertyOf rdf:resource="#generalInfoOfMeanTemperature"/>
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/>
<rdfs:domain rdf:resource="#MeanTemperature"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>
</owl:FunctionalProperty>
<owl:FunctionalProperty rdf:ID="nightValue">
<rdfs:subPropertyOf rdf:resource="#generalInfoOfMeanTemperature"/>
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/>
<rdfs:domain rdf:resource="#MeanTemperature"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>
</owl:FunctionalProperty>
<owl:FunctionalProperty rdf:ID="minValue">
<rdfs:subPropertyOf rdf:resource="#generalInfoOfTemperature"/>
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/>
<rdfs:domain rdf:resource="#Temperature"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>
</owl:FunctionalProperty>
<owl:FunctionalProperty rdf:ID="maxValue">
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 68 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
<rdfs:subPropertyOf rdf:resource="#generalInfoOfTemperature"/>
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/>
<rdfs:domain rdf:resource="#Temperature"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>
</owl:FunctionalProperty>
Table 6: OWL code for properties restructuring of Figure 12

Repetition of Similar Ontological Concepts
Similar ontological concepts are repeated frequently throughout the structure of the ASK-IT
Touristic and Leisure Related ontology, such as different kinds of impaired categories (visual,
hearing, wheelchair users, etc). These concepts could possibly be combined to one module
and reused whenever necessary. The reuse of such a module could indeed be possible for
concepts of the ontology that are related to all impaired categories. In this case, the
impairments could be defined only once and their use be extended within other definitions.
However, this reuse mechanism does not seem to be applicable in OWL-DL. So, this issue is
left for implementation in other languages where it can be supported, such as in CASL.
The advantages of using CASL in contrast to other formalisms are described in [61] and [62].
A sublanguage of CASL, called CASL-DL (CASL – Description Logic), is also described
(Error! Reference source not found.). CASL-DL is related to the Semantic Web ontology
language OWL-DL and translations between CASL-DL and OWL-DL are formalized as
institution comorphisms in the sense of [63]. OWL can thus benefit from CASL’s strong
typing discipline and powerful structuring concepts. Vice versa, the automatic decision
procedures available for OWL-DL become available for a sublanguage of CASL. The
advantages of CASL are supported by an evolving tool set for syntax and type analysis, called
HETS (Heterogeneous Tool Set) [64], (5.3), that provides the connection to various provers
(interactive and automatic). The tool set allows the combination and detection of various
different logics and sublogics, and its architecture is explained in [65].
Next, a specific example will be given from the ASK-IT Touristic and Leisure Related
ontology and a suggestion about how it could be rewritten in CASL. This example reveals the
advantages of CASL regarding the combination of similar ontological concepts to one module
which can easily be reused, imported, exported, modified, etc.
Class:
UserGroups
Subclasses:
CognitiveImpaired
CommunicationDisabled
HearingImpaired
LowerLimbImpaired
PhysiologicalImpaired
PsychologicalImpaired
UpperBodyImpaired
UpperLimbImpaired
Visualimpaired
WheelchairUsers
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 69 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Class:
ConferenceFacilities
Subclasses:
ConferenceFacilitiesForHearingImp
ConferenceFacilitiesForLowerLimbImp
ConferenceFacilitiesForPhysiological
ConferenceFacilitiesForUpperBodyImp
ConferenceFacilitiesForWheelChairUsers
Class:
DressingRoom
Subclasses:
DressingRoomForLowerLimbImp
DressingRoomForPhysiological
DressingRoomForUpperBodyImp
DressingRoomForWheelchairImp
Class:
ExhibitionsMuseums
Subclasses:
ExhibitionsMuseumsForHearingImp
ExhibitionsMuseumsForLowerLimbImp
ExhibitionsMuseumsForVisionImp
ExhibitionsMuseumsForWheelchairUsers
Table 7: Examples of similar ontological concepts repetition
In the hierarchy of Table 7 above, all the impaired categories are presented at first, and next it
can easily be seen that similar subclass principles divide some classes into specific subclasses
for certain impairments. Reusing a possibly defined module of impaired categories heavily
depends on whether the ontology always has the same (group of) impairments for all classes
or not. For instance, if some classes distinguish only between “CommunicationDisabled” and
“PsychologicalImpaired”, and other classes only between “HearingImpaired” and
“WheelchairUsers”, then apparently this reuse mechanism can only be applied to some classes
(those which are related to all impaired categories).
In such a case, the following modules could be defined in order to rewrite the classes of Table
7 in CASL without repeating similar ontological concepts. It is noted again that this reuse
presupposes that the classes are related to all impaired categories (and not only to some of
them).
spec Impairments =
sort Impairment
sorts ForCognitiveImp, ForCommunicationImp, ForHearingImp, … < Impairment
%% declaration of Impairment as superclass of disjoint subclasses:
%% ForCognitiveImp, ForCommunicationImp, ForHearingImp, …
end
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 70 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
spec ConferenceFacilities = Impairments
%% reuse Impairments specification
then
sort Impairment < ConferenceFacility
%% Impairment subclass of ConferenceFacility
%% add some relations, operations, etc.
end
spec DressingRooms = Impairments
%% reuse Impairments specification
then
sort Impairment < DressingRoom
%% Impairment subclass of DressingRoom
%% add some relations, operations, etc.
end
spec ExhibitionsMuseums = Impairments
%% reuse Impairments specification
then
sort Impairment < ExhibitionsMuseum
%% Impairment subclass of ExhibitionsMuseum
%% add some relations, operations, etc.
end
Table 8: Rewriting in CASL the classes of Table 7
It can be seen from the modules given in Table 8 that in CASL the various impairments are
defined only once and then can be extended within other specifications. Such a reuse
mechanism also makes the maintenance of impairments easier (e.g. if an impairment type has
to be added or removed), and it is also easier to keep track of the naming of the impairments
in general (less typing errors, always the same naming and not “ForWheelchairUsers” vs.
“ForWheelchairImp” vs. “ForWheelchairImpaired”, etc).

Subtraction of Modules
The ontology in its initial form was complex enough, as it contained duplicate definitions of
the same concept. Moreover, there also existed very similar (or almost identical to each other)
concepts, and properties defined but never used at all. In order to reduce the complexity of the
ontology and make it more “clear”, compact and readable, duplicate definitions were
eliminated and similar concepts were removed or merged to a single one. Finally, properties
which were not used at all were removed.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 71 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Before
After
POIS_How_to_get_there2
POIS_How_to_get_to_the_pois
POISHowToGetThere
POIHowToGetThere
General_info2
GeneralInfoForALL
GeneralInfo
hasAccommodation
hasAccommodationInfo
hasAccommodation
mean_tmp
mean_tmp
Figure 13: Examples of eliminating duplicates and merging similar definitions
The figure above gives some examples of eliminating duplicates, merging similar definitions
to a single one, and removing unnecessary or unused properties. For instance, the concepts
“POIS_How_to_get_there2”, “POIS_How_to_get_to_the_pois”, and “POISHowToGetThere”
were replaced by “POIHowToGetThere”, since basically they all represent the same concept.
Similarly, “General_info2” and “GeneralInfoForALL” were also merged to “GeneralInfo”. The
object property “hasAccommodationInfo” was eliminated because it was in essence a duplicate
of “hasAccommodation”, while the datatype property “mean_tmp” was removed because it
was not used at all.
Other examples (not presented in Figure 13) are the following. The concepts
“Availability_assistance_services” and “Availability_assistance_services2” were replaced by
“AvailabilityAssistanceService”. The object property “hasTrip_info” was eliminated because it
was a duplicate of “hasTripInfo”. The properties “hasAny” and “DatatypeProperty_71” were
removed, since they were never used, and many more examples.

Documentation/Visualization
The ASK-IT Touristic and Leisure Related ontology was initially poor documented. There
were almost no comments, except for dimension units of some datatype properties. As a result
the ontology was more difficult to use and understand, especially for those who want to
apply/reuse it. So the documentation of the ontology had to be improved by adding comments
for most of the concepts (mainly the higher level ones) in order to be clarified and better
described. The following Figure 14 shows two examples of the comments added in the
ontology for concepts “Accommodation” and “Climate”. The corresponding OWL code for
documenting class “Accommodation” is given in Table 9 (similar code can also be provided
for concept “Climate” and other concepts).
Accommodation : A concept that models a place where someone can stay,
Climate
CERTH/ITI
14/07/2009
e.g. a hotel room.
: A concept that models some of the climate characteristics.
D1.1.1 – vers. 4.5
PUBLIC
Page 72 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Figure 14: Examples of improving ontology documentation
<owl:Class rdf:ID="Accommodation">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
A concept that models a place where someone can stay, e.g. a hotel room.
</rdfs:comment>
</owl:Class>
Table 9: OWL code for documenting class “Accommodation” of Figure 14

Domain/Range Definition of Properties
There were many properties with undefined domain/range, something that could cause
significant inconsistencies when using the ontology. A common case was the existence of
object properties which did not define their range, but instead they appeared in restrictions of
concepts, in which the range was set (as a condition of the concept). After the restructuring
procedure, the domain and range was directly specified for all properties.
hasMonth
Range:
Month
hasWalk
Range:
Walk
Figure 15: Examples of range definition for object properties
Figure 15 gives two examples of range definition for object properties. In the first example,
the property “hasMonth” initially had the domain “MeanTemperature” and “Temperature”, but
no range was defined. Instead, a condition of “MeanTemperature” and “Temperature” was
that, if they have a month (“hasMonth”), all months are of type “Month”. In this case, “Month”
simply became the range of “hasMonth” (as long as there were no other fillers that could be
used for this property). Similarly for the second example, the property “hasWalk” initially had
the domain “NatureAreaWalks”, but no range was defined. Instead, a condition of
“NatureAreaWalks” was that, if they have a walk (“hasWalk”), all walks are of type “Walk”. In
this case, “Walk” simply became the range of “hasWalk” (as long as there were no other fillers
that could be used for this property).
Other examples (not presented in Figure 15) are the following. The range of “hasParking”
(initially undefined) was set to “Parking”, the range of “hasDevice” to “Device”, the range of
“hasClimate” to “Climate”, etc.

Disjointness Restrictions
There were missing disjointness conditions for many concepts inside the ontology, so the
issue of disjointness restrictions had to be reconsidered more carefully. On the other hand,
disjointness should not hold for some other concepts where there might be an overlap
(existence of an individual that is an instance of all of them). In such a case, disjointness
restriction should be removed from these concepts.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 73 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
MedicalService
Doctor
Hospital
SpectatorStand
SpectatorStand
ForHearingImp
SpectatorStand
ForUpperLimbImp
Disjoint
Not
disjoint
Figure 16: Examples where disjointness condition holds or not
In general, all concepts of the ontology at the same level underneath the top level concept
“ASK-IT.TourismAndLeisureOntology” have been made pairwise disjoint with each other.
Similarly, for concepts where it was necessary, all the subconcepts have also been made
disjoint with each other (for example, the subconcepts “Doctor” and “Hospital” of concept
“MedicalService”, as shown in Figure 16). Another example of disjointness (not shown in the
figure above) constitute the subconcepts of “Entertainment” (namely, “Casino”, “Cinema”,
“Club”, “Park”, “Shop”, “Theatre”).
However, for some concepts like “SpectatorStand” for example (shown in Figure 16),
disjointness does not hold for the subconcepts since there may be an individual that is an
instance of both “SpectatorStandForHearingImp” and “SpectatorStandForUpperLimbImp”.
Therefore, the subconcepts of “SpectatorStand” are not pairwise disjointed with each other.
By considering more carefully the issue of disjointness restrictions, the usability of the
ontology is improved when it comes to be used as part of an overall application.
<owl:Class rdf:ID="Doctor">
<rdfs:subClassOf>
<owl:Class rdf:about="#MedicalService"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="Hospital"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#Hospital">
<rdfs:subClassOf>
<owl:Class rdf:about="#MedicalService"/>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Doctor"/>
</owl:Class>
Table 10: OWL code for disjoint concepts of Figure 16
The OWL code for concepts of Figure 16 which are pairwise disjoint is given in Table 10. It
can be seen that class “Doctor” is disjoint with “Hospital” and class “Hospital” is disjoint with
“Doctor” (that is, they are pairwise disjoint with each other). On the other hand, such OWL
code is not necessary for concepts for which disjointness does not hold (like
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 74 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
“SpectatorStandForHearingImp” and “SpectatorStandForUpperLimbImp”, as presented in
Figure 16).
An important comment worth mentioning regarding the issue of disjointness is the following.
As described earlier, the flat concept hierarchy of the ontology has changed to a more treelike structure by exploiting grouping possibilities for concepts of similar kind. This
restructuring process reduced the number of classes on the same level. Since the classes
belonging to the same hierarchy level are usually pairwise disjoint with each other (except for
those for which disjointness does not hold), the latter reduction also resulted in less OWL
code for disjointness (<owl:disjointWith> … </owl:disjointWith>). Hence, the size of the OWL
file for the ASK-IT Touristic and Leisure Related ontology has been reduced from 987KB to
532KB!

Naming Conventions
There was no alignment for all concept names of the ontology. For example, the impairment
categories sometimes ended with “-Impaired”, sometimes with “-Imp”, and sometimes
without any of this. Some of them used camel case, some of them underlines. Moreover, the
property names sometimes were beginning with an upper case letter, sometimes with a lower
case letter. Finally, plural and singular forms were mixed.
As a consequence all concept names and property names had to be aligned (renamed) for
reasons of clearness. Now, all impaired categories end with “-Imp”, whenever this is
necessary. Camel case is always used and singular form is adopted throughout the ontology.
All property names now begin with a lower case letter. Camel case is used and singular form
is adopted again.
Figure 17 shows two examples of renaming. The concept “Local_support_groups” has been
renamed to “LocalSupportGroup”, so that camel case and singular form are used. The property
name “LongBench” has changed to “longBench” so as to start with a lower case letter. Other
examples (not presented in the figure above) are the renaming of
“Availability_assistance_services_Hearing” to “AvailabilityAssistanceServiceForHearingImp”,
the renaming of “clear_signs” to “clearSign”, etc.
Local_support_groups
LongBench
LocalSupportGroup
longBench
Figure 17: Examples of satisfying naming conventions
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 75 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
General ASK-IT
Personal Support
Services
Social Relations
and Community
Building
Services
New
Version
676
Old
Version
687
New
Version
38
Old
Version
38
New
Version
96
Old
Version
103
New
Version
261
Old
Version
335
New
Version
47
Old
Version
73
New
Version
93
Old
Version
124
676
683
38
38
96
103
261
333
47
73
93
123
0
4
0
0
0
0
0
2
0
0
0
1
2
2
1
1
1
1
1
1
1
1
1
1
2
2
1
1
1
1
1
1
1
1
1
1
17
22
3
3
6
7
11
15
8
0
5
4
61
85
3
3
10
10
67
111
10
0
10
10
ASK-IT Ontologies
General
Restructuring Issues
Total Classes
Primitive Classes (classes
Named Classes
that only have necessary
conditions)
Defined Classes (classes
that have at least one set
of necessary and
sufficient conditions)
Average Number of
Parents for Each Class
Maximum Number of
Parents for Each Class
Average Number of
Siblings for Each Class
Maximum Number of
Siblings for Each Class
Total Number of
Various
Restrictions on
Classes
Touristic and
Leisure Related
Transportation
Work Business
and Education
Support Content
Total
28
27
28
40
75
169
86
250
0
423
36
181
Existential (some values
from)
1
1
28
28
0
0
1
33
0
0
0
0
Universal (all values from)
24
23
0
12
75
169
85
217
0
333
36
180
Cardinality (exactly)
0
0
0
0
0
0
0
0
0
0
0
0
MinCardinality (at least)
0
0
3
0
0
3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
76
0
0
0
0
0
1
0
0
MaxCardinality (at most)
HasValue
Table 11: General Restructuring Issues on Classes
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 76 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
General ASK-IT
Personal Support
Services
Social Relations
and Community
Building
Services
Touristic and
Leisure Related
New
Version
Old
Version
New
Version
Old
Version
New
Version
Old
Version
New
Version
Old
Version
New
Version
Old
Version
New
Version
Old
Version
10
15
98
85
148
142
267
290
269
377
135
157
6
7
34
34
42
49
51
92
31
88
33
58
4
8
64
51
106
93
216
198
238
289
102
99
0
0
0
0
0
0
0
0
0
0
0
0
10
8
96
85
148
109
267
249
269
0
135
49
6
4
34
0
42
1
51
0
31
64
33
1
2
2
0
0
0
0
0
0
0
0
0
0
ASK-IT Ontologies
General
Restructuring Issues
Properties
Total Number of
Properties
Number of Object
Properties
Number of Datatype
Properties
Number of Annotation
Properties
Properties with a domain
specified
Properties with a range
specified
Properties with an inverse
specified
Transportation
Work Business
and Education
Support Content
Table 12: General Restructuring Issues on Properties
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 77 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
General ASK-IT
Personal Support
Services
Social Relations
and Community
Building
Services
Touristic and
Leisure Related
New
Version
Old
Version
New
Version
Old
Version
New
Version
Old
Version
New
Version
Old
Version
New
Version
Old
Version
New
Version
Old
Version
Max Depth
Total Number of Nodes
Total Number of Roots
5
677
1
5
688
1
2
39
1
2
39
1
2
97
1
2
104
1
4
262
1
6
336
1
2
48
1
?
73
1
2
94
1
4
125
1
Total Number of Internal
Nodes (Parents)
82
66
2
2
10
10
46
45
3
9
12
20
676
687
38
38
96
103
261
335
47
85
93
124
595
622
37
37
87
94
216
291
45
81
82
105
262
2792
0
6
6
237
3087
0
7
7
1
41
0
34
34
1
41
0
34
34
9
142
0
42
42
9
150
0
49
49
101
460
0
51
51
100
823
0
92
92
2
60
0
31
31
4
87
0
88
88
11
127
0
33
33
30
195
0
58
58
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
4
4
0
0
0
0
8
8
0
0
0
1
64
14
0
0
0
0
51
51
0
0
0
2
106
29
0
0
0
0
93
93
0
0
0
3
216
86
0
0
0
0
198
198
0
0
0
1
238
35
0
0
0
0
289
289
0
0
0
1
102
41
0
0
0
0
99
99
0
0
13
0
16
0
34
0
29
0
12
0
0
0
0
0
0
0
50
0
50
0
0
0
73
0
73
0
0
0
117
0
117
0
0
0
203
0
203
0
0
0
61
0
61
0
0
0
ASK-IT Ontologies
Concept Hierarchy
Restructuring Issues
Classes
Object
Properties
Datatype
Properties
Total Number of Children
Total Number of External
Nodes
Internal Path Length
External Path Length
Max Depth
Total Number of Nodes
Total Number of Roots
Total Number of Internal
Nodes (Parents)
Total Number of Children
Internal Path Length
External Path Length
Max Depth
Total Number of Nodes
Total Number of Roots
Total Number of Internal
Nodes (Parents)
Total Number of Children
Internal Path Length
External Path Length
Transportation
Work Business
and Education
Support Content
Table 13: Concept/Hierarchy Restructuring Issues
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 78 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
General ASK-IT
Personal Support
Services
Social Relations
and Community
Building
Services
New
Version
Old
Version
New
Version
Old
Version
New
Version
Old
Version
New
Version
Old
Version
New
Version
Old
Version
New
Version
Old
Version
676
0
38
0
96
0
261
0
47
0
93
0
0
0
0
0
0
0
0
0
0
0
0
0
676
0
38
0
96
0
261
261
47
0
93
0
100%
79.63%
100%
63.15%
100%
57.28%
100%
76.12%
100%
21.91%
100%
26.63%
100%
100%
100%
100%
100%
38.77%
100%
66.30%
100%
89.77%
100%
43.10%
100%
62.5%
100%
94.12%
100%
16.13%
100%
67.17%
100%
74.74%
100%
41.41%
ASK-IT Ontologies
Specific
Restructuring Issues
Documentation
Total Number of
Documented Classes
Total Number of
Documented
Properties
Total Number of Disjointness
Restrictions on Classes
Naming
Conventions
Percentage of Classes
followed the same
naming conventions
Percentage of Object
Properties followed the
same naming
conventions
Percentage of Datatype
Properties followed the
same naming
conventions
Touristic and
Leisure Related
Transportation
Work Business
and Education
Support Content
Table 14: Specific Restructuring Issues
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 79 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
4.5.
Conclusions
In this chapter we presented a formal methodology whose goal is to provide a set of
guidelines and good practices for ontology re-structuring and refinement. We have applied
this methodology on the initial ASK-IT ontologies. The result of the application of the
refinement process according to a set of criteria derived from the presented evaluation metrics
is a more concrete ontology ready to be re-used in various contexts. Moreover, the resulted
ontology is characterised by a better structured schema both for concepts and attributes,
elimination of duplicates and definition of reusable ranges of values for several attributes. The
resulted ASK-IT ontologies, compared to the previous ones, are more lightwave, well
documented and readable.
The expected outcome of the presented case study is to form the basis for the development of
a concrete methodological approach and a set of guidelines for ontology authoring. This
approach can be used and applied as a set of evaluation criteria for new ontologies as well.
Adherence to these criteria may ensure that the produced ontology enjoys a reasonable degree
of coherence, according to a set of common good practices on ontology authoring. In order for
those criteria to have also countable hypostasis, we aim at the definition of a set of measurable
dimensions for each one of the presented ontology evaluation criteria. This is comprised by
the definition of measurable attributes to be assigned to each one of the ontology evaluation
criteria presented in section 4.1. The set of this criteria could be use in order to form
measurable evaluation metrics that can be also used for ontology benchmarking purposes.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 80 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
5. Ontology Languages
The presentation of the existing ontology languages starts with the “first-generation” ontology
languages, which include the results of early research on the establishment of the basic
concept of ontologies. Efforts in this direction started several years ago, before the
information technology community converge to a consensus on the standards and tools that
are widely adopted today. Most of these languages are not in use today, but have played
significant role in the development of today’s popular standards on ontology description, so
they are mentioned here for completeness. These “first-generation” languages include KIF
and Ontolingua, Loom, PowerLoom, OCML, F-Logic, OKBC, and SHOE.
Modern languages, examined next, have the common characteristic that they are XML-based.
That is, they all define their syntax and semantics using the eXtensible Markup Language,
which is the lingua franca of the existing metadata representation languages today. From
these ontology languages, RDF and OWL are presented in more detail, because they have
contributed to today’s established standards.
Moreover, a short description of the Heterogeneous Tool Set (HETS) is provided. The
Heterogeneous Tool Set (HETS) is the main analysis tool for the specification language
heterogeneous CASL. Heterogeneous CASL (HETCASL) combines the specification
language CASL [33] with CASL extensions and sublanguages, as well as completely different
logics and even programming languages such as Haskell. HETCASL extends the structuring
mechanisms of CASL: Basic specifications are unstructured specifications or modules written
in a specific logic.
Finally, a brief presentation of query languages is provided.
5.1.
First Generation Ontology Languages
5.1.1. KIF and Ontolingua
Knowledge Interchange Format [11] is a language based on first order logic created in 1992
as an interchange format for diverse KR systems. The Ontolingua language [12], written in
KIF, was developed in 1992 by the KSL at Stanford University for the purpose of portable
ontology specifications. It combines the KR paradigms of frames and first order predicate
calculus and can represent ontologies in a canonical format, such that they can be easily
translated into a variety of representation and reasoning systems. This allows one to maintain
the ontology in a single, machine-readable form while using it in systems with different
syntax and reasoning capabilities. It is the most expressive of all the languages that have been
used for representing ontologies, allowing the representation of concepts, taxonomies of
concepts, n-ary relations, functions, axioms, instances and procedures. Ontolingua extends
KIF with standard primitives for defining classes and relations, and organizing knowledge in
object-centered hierarchies with inheritance.
5.1.2. Loom
Loom [13] was developed simultaneously with Ontolingua at the Information Science
Institute (ISI) at the University of South California. Initially, it was not meant for
implementing ontologies but for constructing intelligent applications and general KBs and
thus the heart of Loom is a knowledge representation system that is used to provide deductive
support for the declarative portion of the Loom language. Loom is based on DLs and
production rules, and provides automatic classifications of concepts. Declarative knowledge
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 81 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
in Loom consists of definitions, rules, facts, and default rules. A deductive engine called a
classifier utilizes forward-chaining, semantic unification and object-oriented truth
maintenance technologies in order to compile the declarative knowledge into a network
designed to efficiently support on-line deductive query processing.
5.1.3. PowerLoom
PowerLoom is the successor to the Loom knowledge representation system. It provides a
language and environment for constructing intelligent, knowledge-based applications.
PowerLoom uses a fully expressive, logic-based representation language (a variant of KIF). It
uses a natural deduction inference engine that combines forward and backward chaining to
derive what logically follows from the facts and rules asserted in the knowledge base. While
PowerLoom is not a description logic, it does have a description classifier, which uses
technology derived from the Loom classifier to classify descriptions expressed in full first
order predicate calculus (see paper). PowerLoom uses modules as a structuring device for
knowledge bases, and ultra-lightweight worlds to support hypothetical reasoning.
5.1.4. OCML
Operational Conceptual Modelling Language [14] was developed at KMi at the Open
University. It was created as a kind of ‘‘operational Ontolingua’’. In fact, most of the
definitions that can be expressed in OCML are similar to the corresponding definitions in
Ontolingua, and some additional components can be defined: deductive and production rules
and operational definitions for functions. OCML was built for developing executable
ontologies and knowledge models in problem solving methods.
5.1.5. F-Logic
Frame Logic [15] was developed in 1995 at the Karlsruhe University. F-Logic combines
frames and first order logic, allowing representing concepts, concept taxonomies, binary
relations, functions, instances, axioms and deductive rules. Features include, among others,
object identity, complex objects, inheritance, polymorphism, query methods, encapsulation.
F-Logic stands in the same relationship to object-oriented programming as classical predicate
calculus stands to relational database programming. Its inference engine, Ontobroker [16], can
be used for constraint checking and deducting new information.
5.1.6. OKBC
In Spring 1997, the High Performance Knowledge Base program (HPKB) started. This
research program was sponsored by DARPA, and its objective was to solve many of the
problems that usually appear when dealing with large KBs (concerning efficiency, content
creation, and integration of the content available in different systems, etc.). One of the results
of this program was the development of the Open Knowledge Base Connectivity (OKBC)
application programming interface. This API allows accessing KBs stored in different
knowledge representation systems (KRSs) and enables the construction of reusable KB tools.
OKBC improves upon its predecessor, the Generic Frame Protocol (GFP), in several
significant ways such as that it can be used with a much larger range of systems because its
knowledge model supports an assertional view of a KRS, it provides an explicit treatment of
entities that are not frames, and it has a much better way of controlling inference and
specifying default values. Of the systems presented before, Ontolingua and LOOM are OKBC
compliant.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 82 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
5.1.7. SHOE
Simple HTML Ontology Extensions [17] was built in 1996 as an extension of HTML, in the
University of Maryland. It uses tags different from those of the HTML specification, thus it
allows the insertion of ontologies in HTML documents. SHOE combines frames and rules and
allows representing concepts, their taxonomies, n-ary relations, instances and deduction rules,
which are used by its inference engine to obtain new knowledge.
5.2.
XML-Based Ontology Languages
5.2.1. XOL
XML-Based Ontology Exchange Language [32] was developed by the AI centre of SRI
international, in 1999, as an XMLization of a small subset of primitives from the OKBC
protocol, called OKBC-Lite. It is a very restricted language where only concepts, concept
taxonomies and binary relations can be specified. No inference mechanisms are attached to it,
as it was mainly designed for the exchange of ontologies in the biomedical domain.
5.2.2. DAML + OIL
(Formerly: DAML-ONT) DAML+OIL is a semantic markup language for Web resources and
the precursor of the OWL language. It builds on earlier W3C standards such as RDF and RDF
Schema, and extends these languages with richer modeling primitives. DAML+OIL provides
modeling primitives commonly found in frame-based languages. The DAML+OIL (March
2001) language release extends DAML+OIL (December 2000) release with values from XML
Schema datatypes. DAML+OIL was built from the original DAML ontology language
DAML-ONT (October 2000) in an effort to combine many of the language components of
OIL. The language has a clean and well-defined semantics. It is composed by


DAML: The DARPA Agent Markup Language (DAML) Program officially began in
August 2000. The goal of the DAML effort was to develop a language and tools to
facilitate the concept of the Semantic Web.
OIL [3]: The Ontology Inference Layer OIL is a proposal for a web-based
representation and inference layer for ontologies, which combines the widely used
modeling primitives from frame-based languages with the formal semantics and
reasoning services provided by description logics. It was developed in the framework
of the European IST project On-To-Knowledge. It is compatible with RDF Schema
(RDFS) as it adds frame-based KR primitives to RDF, and includes a precise
semantics for describing term meanings (and thus also for describing implied
information). OIL presents a layered approach to a standard ontology language. Each
additional layer adds functionality and complexity to the previous layer. This is done
such that agents (humans or machines) who can only process a lower layer can still
partially understand ontologies that are expressed in any of the higher layers.
5.2.3. RDF
Resource Description Framework [19], [20] provides a general-purpose language for
representing information in the World Wide Web. It is particularly intended for representing
metadata about Web resources, and it provides a common framework for expressing this
information in such a way that it can be exchanged between applications without loss of
meaning.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 83 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
The basic RDF data model expressing the syntax and structure consists of three object types:
 resources which are the things being described by RDF
 properties which are specific aspects, attributes or relations describing a resource and
 statements that assign a value to a property of a resource
A resource can be any object that is uniquely identifiable by a Uniform Resource Identifier
(URI). For example, “http://www.srdc.metu.edu.tr/eCatalog” is a resource in Figure 18.
<?xml version = "1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/rdf-syntax-ns#"
xmlns:dc="http://dublincore.org/documents/dces/">
<rdf:Description about = "http://www.srdc.metu.edu.tr/eCatalog">
<dc:Creator>ABC Company</dc:Creator>
<dc:Date>April 23, 2002</dc:Date>
</rdf:Description>
</rdf:RDF>
Figure 18: An Example RDF Description
Values may be atomic in nature or can be other resources, which in turn may have their own
properties. A value can just be a string, for example “ABC Company” or it can be another
resource, for example “http://www.srdc.metu.edu.tr/Privacy”. A collection of these properties
that refers to the same resource is called a description. The RDF data model provides an
abstract, conceptual framework; a concrete syntax is also required and XML is used for this
purpose.
Consider, for example, the description given in Figure 18, which states that the “ABC
Company” is the creator of the indicated electronic catalog. In this RDF description, a
resource, namely, “http://www.srdc.metu.edu.tr/eCatalog” is being described by giving a
value, “ABC Company” to its “dc:Creator” property. Notice that rdf:RDF tag marks the
beginning and end of the description document. rdf:Description tag envelopes the description
of the resource. dc:Creator is a property of this resource. The resource
“http://www.srdc.metu.edu.tr/eCatalog”, its property dc:Creator and the value “ABC
Company” constitutes an RDF statement.
In fact, RDF models descriptions and statements in terms of a directed graph consisting of
nodes and arcs. The nodes describe resources, and properties represented by directed arcs that
connect subject nodes to object nodes. A property arc is interpreted as an attribute,
relationship or predicate of the resource, with a value given by the object node. Figure 19
shows the graph representation of the sample RDF description given in Figure 18.
The
namespace
URI
in
a
namespace
declaration,
like
xmlns:rdf="http://www.w3.org/1999/rdf-syntax-ns" in the example of Figure 18, is a globally
unique identifier for a particular schema, and it indicates that rdf:Description tag is defined in
this schema.
The <rdf:RDF> tag tells us that this is an RDF description, that is, we (or a software program)
is informed that an RDF statement will follow with a well-defined syntax. However to
understand the meaning of this description we need to know what “dc:Creator” means. For the
dc:Creator element, its meaning may be intuitive, but the meaning of the dc:Date is not clear:
it could be the date publishing the catalog, or the date of catalog expiry or something else.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 84 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
http://www.srdc.metu.edu.tr/eCatalog
dc:Creator
dc:Date
ABC Company
April 23, 2002
Figure 19: Graph representation of the example RDF Description in Figure 18
Therefore meaning in RDF is expressed through a reference to an application-specific
schema, which defines the terms that will be used in RDF statements and gives specific
meanings to them. That is, RDF does not specify semantics for each resource description
community, but rather provides the ability for these communities to define metadata elements
as needed. Individual resource description communities define the semantics, or meaning of
metadata that addresses their particular needs using RDF Schema Specification mechanisms
[21]. The XML namespace mechanism [22] serves to identify RDF Schemas. The “dc” in the
example refers to a well-known schema, namely Dublin Core [23].
Once the meanings of the attributes are known, this description becomes machine
processable. Any program (having a prior knowledge of the syntax and semantics of RDF, in
this case) can parse the description, extract meta-data, interpret it and use it for its purposes.
Note however that even when an application knows only the RDF Syntax and has no
understanding of a particular schema will still be able to parse the description into the
property-type and corresponding values and will still be able to deduce that a resource is
being described with a certain property and a property value.
There could be any number of statements in a description and any number of descriptions
about different resources in an RDF document. The description element may have one of the
following two attributes: “about” and “ID” to identify the resource being described. The
“about” attribute names an existing resource to which the description applies. If the resource
does not yet exist (i.e., does not yet have a resource identifier) then the “ID” attribute provides
an identifier for the resource to be described. In other words, the “ID” attribute signals the
creation of a new resource and the “about” attribute refers to an existing resource.
Frequently it is necessary to refer to a collection of resources. In this respect, RDF Syntax
provides the container facilities consisting of Bag, Sequence, and Alternative container
objects. A Sequence and a Bag represent sets; whereas Alternative represents an element.
More precisely, a Sequence is an ordered list of resources or literals whereas in a Bag, order is
not important. An Alternative is a list of resources or literals that represents alternatives for a
single element. Figure 20 demonstrates the use of containers. In this example, the component
C1 is made up of parts P1, P2 and P3, and part P4 is a substitute for P3, and the meaning of
“cs:made_Up_Of”
tag
is
given
in
the
schema
provided
at
“http://www.srdc.metu.edu.tr/Catalog_Schema#”.
RDF also provides enumeration to the members of a class. An enumeration defines a class by
giving an explicit list of its members. As an example:
Basically, this is just the definition of the instances of the class in the schema. However,
exactly for this reason the enumeration in RDF is not closed, that is anyone can add items to
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 85 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
the enumeration without a restriction. Usually a tight control is needed over the items in an
enumeration, meaning that RDF lacks ways of expressing such a restriction.
<?xml version = "1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/rdf-syntax-ns#"
xmlns:cs="http://www.srdc.metu.edu.tr/Catalog_Schema#">
<rdf:Description about="http://www.srdc.metu.edu.tr/eCatalog/Components/C1">
<cs:made_Up_Of>
<rdf:Bag>
<rdf:li rdf:resource="http://www.srdc.metu.edu.tr/eCatalog/ComponentParts/P1"/>
<rdf:li rdf:resource="http://www.srdc.metu.edu.tr/eCatalog/ComponentParts/P2"/>
<rdf:Alternative>
<rdf:li rdf:resource="http://www.srdc.metu.edu.tr/eCatalog/ComponentParts/P3"/>
<rdf:li rdf:resource="http://www.srdc.metu.edu.tr/eCatalog/ComponentParts/P4"/>
</rdf:Alternative>
</rdf:Bag>
</cs:made_Up_Of>
<cs:Creator>Delphi Company</cs:Creator>
</rdf:Description>
</rdf:RDF>
Figure 20: An example RDF Description illustrating the use of Containers
5.2.3.1. Statements about Statements
In addition to making statements about Web resources, RDF can be used for making
statements about other RDF statements; in other words, RDF allows a form of reification. In
order to make a statement about another statement, that is, to express a belief about a
statement to be true or false, it is necessary to model the original statement as a reified
statement.
To model reified statements, RDF defines the following properties:
 subject: The subject property identifies the resource being described by the modeled
statement; the value of this property is the resource about which the original statement
was made.
 predicate: The predicate property identifies the original property in the modeled
statement; that is, the value of the predicate property is a resource representing the
specific property in the original statement.
 object: The object property identifies the property value in the modeled statement; that
is, the value of the object property is the object in the original statement.
 type: The value of the type property describes the type of the new resource. All reified
statements are instances of RDF:Statement; that is, they have a type property whose
object is RDF:Statement.
A new resource with the above four properties represents the original statement and can both
be used as the object of other statements and have additional statements made about it. The
resource with these four properties is not a replacement for the original statement; it is a
model of the statement. A statement and its corresponding reified statement exist
independently in an RDF graph and either may be present without the other.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 86 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Consider, for example, the resource described in Figure 20. To express the fact that the Web
Site Administrator of this resource believes that the “Creator” of this resource is “Delphi
Company”, we need to make a statement as shown in Figure 21.
<?xml version = "1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cs="http://www.srdc.metu.edu.tr/Catalog_Schema">
<rdf:Description>
<rdf:subject rdf:resource="http://www.srdc.metu.edu.tr/eCatalog/Components/" />
<rdf:predicate rdf:resource="http://www.srdc.metu.edu.tr/Catalog_Schema/Creator" />
<rdf:object>Delphi Company</rdf:object>
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement" />
<cs:attributedTo>Web Site Administrator</cs:attributedTo>
</rdf:Description>
</rdf:RDF>
Figure 21: An example of “making Statements about Statements”
5.2.3.2. RDF Schema
The declaration of properties and their corresponding semantics are defined in the context of
RDF as a schema. RDF Schema [20] defines a Schema Specification Language for this
purpose and provides a basic type system for use in RDF Models. It defines resources and
properties such as “Class” and “subClassOf” that are used in specifying application-specific
schemas.
To be more specific the RDF Schema mechanism defines the following core classes:
 rdfs:Resource: This class is the top class, i.e., all resources are considered to be
instances of this class.
 rdf:Property: This class represents the subset of RDF resources that are properties.
 rdfs:Class: The class rdfs:Class represents the subset of RDF resources that are
classes. An RDF schema is organized into a collection of classes.
The RDF Schema mechanism also defines the following core properties:



rdf:type: This property indicates which class a resource belongs to. Resources may be
instances of one or more classes by multiple inheritance. Note that when a schema
defines a new class, the resource representing that class must have an rdf:type property
whose value is the resource rdfs:Class. The resource known as rdfs:Class is itself a
resource of rdf:type rdfs:Class.
rdfs:subClassOf: Classes are often organized in a hierarchy and rdfs:subClassOf
property is defined to express subclass relationship among classes.
rdfs:subPropertyOf: This core property specifies that one property is a specialization
of another.
Property names must be associated with a schema. This can be done by qualifying the element
names with namespace prefixes to unambiguously connect the property definition with the
corresponding RDF schema.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 87 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
The class hierarchy mechanism provided by RDF is very helpful in defining ontologies which
are much needed in e-commerce applications. The example provided in Figure 22 defines
such a class hierarchy where “Product” is the subclass of the top level class “resource”, and
“Physical_Product” is a subclass of “Product”.
<?xml version = "1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/TR/WD-rdf-syntax#"
xmlns:rdfs="http://www.w3.org/TR/WD-rdf-schema#">
<rdf:Description rdf:ID="Product">
<rdf:type rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Resource"/>
<rdfs:comment>All kinds of trade Products</rdfs:comment>
<rdfs:label>Product</rdfs:label>
</rdf:Description>
<rdf:Description rdf:ID="Physical_Product">
<rdf:type rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#Product"/>
<rdfs:comment>All kinds of physical products</rdfs:comment>
<rdfs:label>PhysicalProduct</rdfs:label>
</rdf:Description>
</rdf:RDF>
Figure 22: An example description illustrating the use of SubClassOf Property
An RDF schema can declare constraints associated with classes and properties. In particular,
the concepts of domain and range are used in RDF schemas to make statements about the
context in which certain properties make sense. Range property expresses the fact that the
value of a property should be a resource of a designated class. Assume, for example, we
would like to define user profiles to deliver personalized information to the users on the Web.
For this purpose we define a property called “interested.in”, whose domain is the “user” class,
and whose range is the “subject” class. The definition of this property is provided in Figure
23. A domain constraint applying to the “interested.in” property expresses that this property
may only be used for the resource class “User” and the range constraint expresses that the
value of this attribute must be an instance of the class “Subject”.
5.2.3.3. RDF Syntax and Schema Summary
The basic building block in RDF Syntax is an object-attribute-value triple. Any object can
play the role of a value, and thus it is possible to chain the resources. RDF also allows any
RDF statement to be the object or value of a triple, which means resources can be nested as
well as chained [24]. Finally, it is possible to indicate that a given object is of a certain type
through rdf:type property.
RDF schema lets developers define a particular vocabulary for RDF data. In other words, the
RDF schema mechanism provides a basic type system for RDF models. This type system uses
some predefined terms, such as Class, subClassOf, subPropertyOf, for defining application
specific schema.
RDF objects can be defined as instances of one or more classes using the type property. The
subClassOf property allows organizing classes in a class hierarchy and subPropertyOf does
the same for properties. Constraints on properties can be specified using domain and range
constructs.
The RDF Schema specification provides a machine-understandable system for defining
“schemas” for descriptive vocabularies like the Dublin Core mentioned previously [23].
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 88 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
<?xml version="1.0" encoding="UTF-8" ?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/TR/WD-rdf-syntax#"
xmlns:rdfs="http://www.w3.org/TR/WD-rdf-schema#"
<rdf:Description rdf:ID="User">
<rdf:type rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Resource"/>
<rdfs:label>User</rdfs:label>
<rdfs:comment>Web users</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="Subject">
<rdf:type rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="http://www.w3.org/TR/WD-rdf-schema#Resource"/>
<rdfs:label>Subject</rdfs:label>
<rdfs:comment>Subject areas</rdfs:comment>
</rdf:Description>
<rdf:Description rdf:ID="interested.in">
<rdf:type rdf:resource="http://www.w3.org/TR/WD-rdf-syntax#Property"/>
<rdfs:label>List of subject that a user has been interested</rdfs:label>
<rdfs:domain rdf:resource="#User">
<rdfs:range rdf:resource="#Subject">
<rdfs:comment>This property indicates the subjects that are of interest to a user</rdfs:comment>
</rdf:Description>
</rdf:RDF>
Figure 23: Domain and Range Constraints in RDF description
5.2.4. OWL
The OWL Web Ontology Language is designed for use by applications that need to process
the content of information instead of just presenting information to humans. OWL can be
used to explicitly represent the meaning of terms in vocabularies and the relationships
between those terms as an ontology. OWL facilitates greater machine interpretability of Web
content than that supported by XML, RDF, and RDF Schema (RDF-S) by providing
additional vocabulary along with a formal semantics. OWL is a revision of the DAML+OIL
web ontology language incorporating lessons learned from the design and application of
DAML+OIL [25].
In OWL 2004 [26] W3C has expressed the need for a Web Ontology language on top of the
existing XML, and RDF. These can be summarized as follows: “Ontologies are critical for
applications that want to search across or merge information from diverse communities.
Although XML DTDs and XML Schemas are sufficient for exchanging data between parties
who have agreed to definitions beforehand, their lack of semantics prevent machines from
reliably performing this task given new XML vocabularies. The same term may be used with
(sometimes subtle) different meaning in different contexts, and different terms may be used
for items that have the same meaning. RDF and RDF Schema begin to approach this problem
by allowing simple semantics to be associated with identifiers. With RDF Schema, one can
define classes that may have multiple subclasses and super classes, and can define properties,
which may have sub properties, domains, and ranges. In this sense, RDF Schema is a simple
ontology language. However, in order to achieve interoperation between numerous,
autonomously developed and managed schemas, richer semantics are needed. For example,
RDF Schema cannot specify that the Person and Car classes are disjoint, or that a string
quartet has exactly four musicians as members.”
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 89 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
In summary OWL is part of the growing stack of W3C recommendations related to the
Semantic Web.
 XML provides a surface syntax for structured documents, but imposes no semantic
constraints on the meaning of these documents.
 XML Schema is a language for restricting the structure of XML documents.
 RDF is a datamodel for objects ("resources") and relations between them, provides a
simple semantics for this datamodel, and these datamodels can be represented in an
XML syntax.
 RDF Schema is a vocabulary for describing properties and classes of RDF resources,
with a semantics for generalization-hierarchies of such properties and classes.
 OWL adds more vocabulary for describing properties and classes: among others,
relations between classes (e.g. disjointness), cardinality (e.g. "exactly one"), equality,
richer typing of properties, characteristics of properties (e.g. symmetry), and
enumerated classes
A number of use cases have been identified where Web Ontology Language can be used in.
These can be summarized as follows:
 Web Portals: A web portal is a web site that provides information content on a
common topic, for example a specific city or domain of interest. Portals usually
provide a simple index of subject areas, however this does not provide the community
with sufficient ability to search for the content that its members require. Ontologies
can be designed to organize the contents in the Web Portals in order to facilitate their
discovery both by the humans and software agents.
 Multimedia Collections: Ontologies can be used to provide semantic annotations for
collections of images, audio, or other non-textual objects. It is even more difficult for
machines to extract meaningful semantics from multimedia than it is to extract
semantics from natural language text. Thus, these types of resources are typically
indexed by captions or metatags. However, since different people can describe these
non-textual objects in different ways, it is important that the search facilities go
beyond simple keyword matching. Ideally, the ontologies would capture additional
knowledge about the domain that can be used to improve retrieval of images.
 Corporate Web Site Management: Large corporations typically have numerous web
pages concerning things like press releases, product offerings and case studies,
corporate procedures, internal product briefings and comparisons, white papers, and
process descriptions. Ontologies can be used to index these documents and provide
better means of retrieval. Although many large organizations have a taxonomy for
organizing their information, this is often insufficient. A single ontology is often
limiting because the constituent categories are likely constrained to those representing
one view and one granularity of a domain; the ability to simultaneously work with
multiple ontologies would increase the richness of description. Furthermore, the
ability to search on values for different parameters is often more useful than a
keyword search with taxonomies.
 Design Documentation: Ontologies can be used to build an information model which
allows the exploration of the information space in terms of the items which are
represented, the associations between the items, the properties of the items, and the
links to documentation which describes and defines them (i.e., the external
justification for the existence of the item in the model). This can be necessary for a
large body of engineering documentation, such as that used by the aerospace industry.
Through such an ontology the interrelationships of each document can be stored and
managed.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 90 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754


Agents and Services: OWL can provide agents with the capability to understand and
integrate diverse information resources and services. A specific example is that of a
social activities planner, which can take the preferences of a user (such as what kinds
of films they like, what kind of food they like to eat, etc.) and use this information to
plan the user's activities for an evening. The task of planning these activities will
depend upon the richness of the service environment being offered and the needs of
the user. Defining the services through ontologies will facilitate the service
determination / matching process. These functionalities can also be provided using
other services. For example ratings and review services may also be consulted to find
closer matches to user preferences.
Web services and Ubiquitous Computing: Ubiquitous computing is an emerging
paradigm of personal computing, characterized by the shift from dedicated computing
machinery to pervasive computing capabilities embedded in our everyday
environments. A key technology of true ad hoc networks is service discovery,
functionality by which "services" (both the functions offered by various devices such
as cell phones, printers, sensors, etc. and the services provided as Web services) can
be described, advertised, and discovered by others. Hence there is a need for a Web
Ontology Language to describe the characteristics and the functionalities of the
services.
5.2.4.1. OWL Language Basics
OWL provides three increasingly expressive sublanguages designed for use by specific
communities of implementers and users.
 OWL Lite supports those users primarily needing a classification hierarchy and simple
constraints. For example, while it supports cardinality constraints, it only permits
cardinality values of 0 or 1.
 OWL DL supports those users who want the maximum expressiveness while retaining
computational completeness (all conclusions are guaranteed to be computed) and
decidability (all computations will finish in finite time). OWL DL includes all OWL
language constructs, but they can be used only under certain restrictions (for example,
while a class may be a subclass of many classes, a class cannot be an instance of
another class). OWL DL is so named due to its correspondence with description
logics, a field of research that has studied the logics that form the formal foundation of
OWL.
 OWL Full is meant for users who want maximum expressiveness and the syntactic
freedom of RDF with no computational guarantees. For example, in OWL Full a class
can be treated simultaneously as a collection of individuals and as an individual in its
own right. OWL Full allows an ontology to augment the meaning of the pre-defined
(RDF or OWL) vocabulary.
In the next paragraphs we will be presenting the features of OWL Lite and state the features
of OWL DL and OWL Full incrementally over OWL Lite.
5.2.4.2. OWL Lite Features
In OWL Lite, as in RDF, it is possible to define Classes and class/subclass hierarchies in your
domain, and properties of these classes using RDF constructs such as Class, rdfs:subClassOf,
rdfs:Property, rdfs:subPropertyOf, rdfs:subPropertyOf:, rdfs:domain, rdfs:range.
In order for ontologies to have the maximum impact, they need to be widely shared. In order
to minimize the intellectual effort involved in developing an ontology they need to be re-used.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 91 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
In the best of all possible worlds they need to be composed. To tie together a set of
component ontologies as part of a third it is frequently useful to be able to indicate that a
particular class or property in one ontology is equivalent to a class or property in another
ontology. For stating the equality/inequality relationships between the Ontology components
the following constructs are available in OWL Lite:
 equivalentClass : Two classes may be stated to be equivalent.
 equivalentProperty: Two properties may be stated to be equivalent
 sameAs: Two individuals may be stated to be the same.
 differentFrom: An individual may be stated to be different from other individuals
 allDifferent: A number of individuals may be stated to be mutually distinct in one
allDifferent statement.
In OWL Lite it is possible to specify property characteristics, which provides a powerful
mechanism for enhanced reasoning about a property. The following special identifiers can be
used to provide information concerning properties and their values [27]:
 inverseOf: One property may be stated to be the inverse of another property. For
example if hasPatient is the inverse of hasDoctor and Gokce hasDoctor Dr. Alp, then a
reasoner can deduce that Dr. Alp hasPatient Gokce.
 TransitiveProperty: Properties may be stated to be transitive. For example, if the part
of relation is stated to be transitive, and if CardiologyDepartment is a partOf Hospital
A (i.e., (CardiologyDepartment, Hospital A) is an instance of the property partOf) and
ElectroCardioLab is partOf CardiologyDepartment (i.e., (ElectroCardioLab,
CardiologyDepartment) is an instance of the property partOf), then a reasoner can
deduce that ElectroCardioLab is a partOf Hospital A. OWL Lite (and OWL DL)
impose the side condition that transitive properties (and their superproperties) cannot
have a maxCardinality 1 restriction.
 SymmetricProperty: Properties may be stated to be symmetric. For example,
roomMate may be stated to be a symmetric property. Then a reasoner that is given that
Gokce is the roomMate of Yildiray can deduce that Yildiray is a roomMate of Gokce.
 FunctionalProperty : Properties may be stated to have a unique value. If a property is
a FunctionalProperty, then it has no more than one value for each individual (it may
have no values for an individual). For example, hasInsuranceId may be stated to be a
FunctionalProperty. From this a reasoner may deduce that no patient may have more
than one PatientId for an Insurance Company. This does not imply that every Patient
must have at least one insurance id from an insurance company however
 InverseFunctionalProperty: Properties may be stated to be inverse functional. If a
property is inverse functional then the inverse of the property is functional. Thus the
inverse of the property has at most one value for each individual. For example,
hasPatientId (a unique identifier for the patients of a unique hospital) may be stated to
be inverse functional (or unambiguous). The inverse of this property (which may be
referred to as isThePatientIdFor) has at most one value for any patient (for a unique
hospital). Thus any one patient's patientID is the only value for their isThePatientIdFor
property. From this a reasoner can deduce that no two different individual instances of
Patient have the identical patientId in a unique hospital. Also, a reasoner can deduce
that if two instances of Patient in a unique hospital have the same patientID, then those
two instances refer to the same individual.
In addition to designating property characteristics, it is possible to further constrain the range
of a property in specific contexts in a variety of ways. OWL Lite allows restrictions to be
placed on how properties can be used by instances of a class. The following two restrictions
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 92 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
limit which values can be used while the cardinality restrictions limit how many values can be
used.
 allValuesFrom: The restriction allValuesFrom is stated on a property with respect to a
class. It means that this property on this particular class has a local range restriction
associated with it. For example, we may have defined the hasPrimaryDoctor property
of a Patient with a range of Doctor class. Then we may define a subClass of Patient,
namely CardiologyPatient for specifying the patients of the Cardiology Department in
the hospital; and we may define a restriction on the hasPrimaryDoctor (which has been
inherited to CardiologyPatient from the PatientClass) to have all values from
Cardiologist Class (Cardiologist is a subClass of Doctor Class). This means that if an
individual CardiologyPatient Gokce is related by the property hasPrimary to the
individual Dr.Alp, then from this a reasoner can deduce that Dr.Alp is an instance of
the class Cardiologist.
 someValuesFrom: The restriction someValuesFrom is stated on a property with
respect to a class. A particular class may have a restriction on a property that at least
one value for that property is of a certain type. For example, the class
MedicalInformaticsPaper may have a someValuesFrom restriction on the hasKeyword
property that states that some value for the hasKeyword property should be an instance
of the class MedicalInformaticsTopic. This allows for the option of having multiple
keywords and as long as one or more is an instance of the class
MedicalInformaticsTopic, then the paper would be consistent with the
someValuesFrom restriction.
OWL Lite includes a limited form of cardinality restrictions. OWL Lite cardinality
restrictions are limited because they only allow statements concerning cardinalities of value 0
or 1 (they do not allow arbitrary values for cardinality, as is the case in OWL DL and OWL
Full). This permits the user to indicate 'at least one', 'no more than one', and 'exactly one'.
 minCardinality: Cardinality is stated on a property with respect to a particular class. If
a minCardinality of 1 is stated on a property with respect to a class, then any instance
of that class will be related to at least one individual by that property. This restriction
is another way of saying that the property is required to have a value for all instances
of the class.
 maxCardinality: Cardinality is stated on a property with respect to a particular class. If
a maxCardinality of 1 is stated on a property with respect to a class, then any instance
of that class will be related to at most one individual by that property. A
maxCardinality 1 restriction is sometimes called a functional or unique property.
 cardinality: Cardinality is provided as a convenience when it is useful to state that a
property on a class has both minCardinality 0 and maxCardinality 0 or both
minCardinality 1 and maxCardinality 1.
OWL provides additional constructors with which to form classes. These constructors can be
used to create so-called class expressions. OWL Lite contains an intersection constructor but
limits its usage.
 intersectionOf: OWL Lite allows intersections of named classes and restrictions. For
example, the class InsuredPatient can be described as the intersectionOf Patient and
InsuredPerson (which could be defined as person that have a minimum cardinality of 1
on the hasInsurance property). From this a reasoner may deduce that any particular
InsuredPatient has at least one Insurance.
In OWL properties are categorized according to whether they relate individuals to individuals
(object properties) or individuals to datatypes (datatype properties). Datatype properties may
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 93 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
range over RDF literals or simple types defined in accordance with XML Schema datatypes
[28].
OWL uses most of the built-in XML Schema datatypes. References to these datatypes are by
means of the URI reference for the datatype, http://www.w3.org/2001/XMLSchema. The
following datatypes are recommended for use with OWL:
The datatypes presented inTable 15, plus rdfs:Literal, form the built-in OWL datatypes. Other
built-in XML Schema datatypes may be used in OWL Full.
xsd:string
xsd:decimal
xsd:integer
xsd:nonPositiveInteger
xsd:long
xsd:unsignedLong
xsd:hexBinary
xsd:dateTime
xsd:gYear
xsd:anyURI
xsd:NMTOKEN
xsd:normalizedString
xsd:float
xsd:nonNegativeInteger
xsd:negativeInteger
xsd:int
xsd:unsignedInt
xsd:base64Binary
xsd:time
xsd:gMonthDay
xsd:token
xsd:Name
xsd:boolean
xsd:double
xsd:positiveInteger
xsd:short
xsd:unsignedShort
xsd:byte
xsd:unsignedByte
xsd:date
xsd:gDay
xsd:language
xsd:NCName
xsd:gYearMonth
xsd:gMonth
Table 15: Recommended XML Schema Data types
5.2.4.3. Incremental Language Description of OWL DL and OWL FULL
Both OWL DL and OWL Full use the same vocabulary although OWL DL is subject to some
restrictions. Roughly, OWL DL requires type separation (a class can not also be an individual
or property, a property can not also be an individual or class). This implies that restrictions
cannot be applied to the language elements of OWL itself (something that is allowed in OWL
Full). Furthermore, OWL DL requires that properties are either ObjectProperties or
DatatypeProperties: DatatypeProperties are relations between instances of classes and RDF
literals and XML Schema datatypes, while ObjectProperties are relations between instances of
two classes. We describe the OWL DL and OWL Full vocabulary that extends the
constructions of OWL Lite below.
 oneOf: (enumerated classes): Classes can be described by enumeration of the
individuals that make up the class. The members of the class are exactly the set of
enumerated individuals; no more, no less. For example, the class of organisationType
for a healtcare institution can be described by simply enumerating the individuals
hospital, outpatient clinic, emergency department, diagnostic department, laboratory
service, day care service, nursing home, physician’s office, rehabilitation center,
residential facility as proposed by CEN, ENV13606, Electronic healthcare record
communication, DomainTem List27.
 hasValue: (property values): A property can be required to have a certain individual as
a value (also sometimes referred to as property values). For example, instances of the
class of TurkishCitizens can be characterized as those people that have Turkey as a
value of their nationality. (The nationality value, Turkey, is an instance of the class of
Nationalities).
 disjointWith: OWL Full allows the statement that classes are disjoint. For example,
Man and Woman can be stated to be disjoint classes. From this disjointWith
27
http://www.chime.ucl.ac.uk/work-areas/ehrs/EHCR-SupA/13606v1_8/sld001.htm
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 94 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754



statement, a reasoner can deduce an inconsistency when an individual is stated to be
an instance of both and similarly a reasoner can deduce that if A is an instance of Man,
then A is not an instance of Woman.
unionOf, complementOf, intersectionOf (Boolean combinations): OWL DL allows
arbitrary Boolean combinations of classes and restrictions: unionOf, complementOf,
and intersectionOf. For example, using unionOf, we can state that a class contains
things that are either USCitizens or EUCitizens. Using complementOf, we could state
that children are not SeniorCitizens. (i.e. the class Children is a subclass of the
complement of SeniorCitizens). Citizenship of the European Union could be described
as the union of the citizenship of all member states.
minCardinality, maxCardinality, cardinality (full cardinality): While in OWL Lite,
cardinalities are restricted to at least, at most or exactly 1 or 0, full OWL allows
cardinality statements for arbitrary non-negative integers.
complex classes: In many constructs, OWL Lite restricts the syntax to single class
names (e.g. in subClassOf or equivalentClass statements). OWL Full extends this
restriction to allow arbitrarily complex class descriptions, consisting of enumerated
classes, property restrictions, and Boolean combinations. Also, OWL Full allows
classes to be used as instances (and OWL DL and OWL Lite do not)
5.2.5. RacerPro
RacerPro [38] stands for Renamed ABox and Concept Expression Reasoner Professional. As
the name suggests, the origins of RacerPro are within the area of description logics. Since
description logics provide the foundation of international approaches to standardize ontology
languages in the context of the so-called semantic web, RacerPro can also be used as a system
for managing semantic web ontologies based on OWL (e.g., it can be used as a reasoning
engine for ontology editors such as Protégé). However, RacerPro can also be seen as a
semantic web information repository with optimized retrieval engine because it can handle
large sets of data descriptions (e.g., defined using RDF). Last but not least, the system can
also be used for modal logics such as Km. In addition to these basic features, RacerPro also
provides facilities for algebraic reasoning including concrete domains for dealing with:



min/max restrictions over the integers,
linear polynomial (in-)equations over the reals or cardinals with order relations,
equalities and inequalities of strings.
RacerPro implements the HTTP-based quasi-standard DIG for interconnecting DL systems
with interfaces and applications using an XML-based protocol. RacerPro also implements
most of the functions specified in the older Knowledge Representation System Specification
(KRSS)
5.3.
The Heterogeneous Tool Set
The heterogeneous tool set (HETS) is a parsing, static analysis and proof management tool
combining various such tools for individual specification languages, thus providing a tool for
heterogeneous multi-logic specification. HETS is based on a graph of logics and languages
(formalized as so-called institutions), their tools, and their translations (Figure 24). This
provides a clean semantics of heterogeneous specifications, as well as a corresponding proof
calculus. For proof management, the calculus of development graphs (known from other
large-scale proof management systems) has been adapted to heterogeneous specification.
Development graphs provide an overview of the (heterogeneous) specification module
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 95 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
hierarchy and the current proof state, and thus may be used for monitoring the overall
correctness of a heterogeneous development. We illustrate the approach with a sample
heterogeneous proof proving the correctness of the composition table of a qualitative spatial
calculus. The proof involves two different provers and logics: an automated first-order prover
solving the vast majority of the goals, and an interactive higherorder prover used to prove a
few bridge lemmas.
Figure 24: HETS architecture
HETS supports the algebraic specification language CASL (Common Algebraic Specification
Language), which has recently been applied to ontology development. CASL is a first-order
logic that is similar in capabilities to representations such as Common Logic, which has also
been proposed for ontology work. However, due to its embedding within HETS, CASL is
superior in its support of structured specifications. It is also naturally embedded within
heterogeneous specifications involving logics of differing expressiveness. In particular,
variants equivalent to Description Logic and OWL have been defined. Due to this flexibility,
CASL will play a central role for the subsequent development of the Common Ontological
Framework within OASIS. This will be described in detail in Deliverable D1.2.1. For present
purposes we can note that due to the coverage of HETS, it is in principle possible to build
formal connections between this framework and all of the ontology representation languages
we have described in this deliverable. A significant advance of this approach is, therefore, that
we can rely upon a common underlying framework that is strong enough to support the
diversity of ontology requirements here identified.
5.3.1.
Ontology Query Languages
Based on the ontology languages described above, several query languages and systems have
been already developed. RDQL [39] is the query language for Jena2. Vampire [41] is a FOL
theorem prover using TPTP3 format for problem input and query input. nRQL is the query
language for RACER. Finally, OWL-QL [40] is a query language for the OWL-QL system.
SPARQL [42] is a Server-Client-based RDF query language. It has SQL syntax and is
influenced by RDQL and SquishQL4. SPARQL supports disjunction in the query and thus
can process more complex query than RDQL. SPARQL also provides optional variable
binding and result size control mechanisms for real world usage.
5.3.2. nRQL and Racer
nRQL (new RACER Query Language, an extension of RQL) [43] is an extended query
language for RACER. nRQL was constructed based on Description Logic model theory [44].
5.3.3. OWL-QL
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 96 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
The OWL Query Language (OWL-QL) is a well designed language for querying over
knowledge represented in a repository [40]. OWL-QL is an updated version of DAML Query
Language (DQL). It is intended to be a candidate for query-answering dialogues among
answer agents and query agents. Then information receivers and information providers can
transfer queries and answers via the Internet.
OWL-QL provides a formal description of the semantic relationships among queries, answers,
and knowledge bases used to produce answers. An OWL-QL query contains a collection of
OWL sentences in which some URI references are considered to be variables. This collection
is called query pattern.
The answers to a query provide bindings to the query pattern so that the binding result of the
query pattern is existentially quantified. It may not necessarily entail a binding for every
variable in the query. OWL-QL extends this by enabling clients to designate which variable or
set of variables must be bound to the query pattern. Each variable occurring in the answer
pattern has one of the three binding types, i.e., must-bind variable, may-bind variable, and
don’t-bind variable. A quantified answer must provide all the bindings for all the must-bind
variables, may provide bindings for any of the may-bind variables and must not provide
bindings for any of the don’t-bind variables. All the lists are disjoint with each other. By
adjusting the variable for binding, OWL-QL can answer the questions such as “What
resources make the query pattern true” or “Is the query pattern true”. This is quite flexible and
allows for sophisticated queries. It also provides users the ability to specify an answer pattern,
so that the server knows in what format the answers should be returned.
Since OWL-QL provides a large range of query-answer services, the size of the answers
returned for a query may be very large. In addition, if the query is over a large KB, the
process may take an unexpected long time. The solution is to permit the answering server to
return part of query results. In addition, there needs to be a communication channel between
clients and server. OWL-QL introduces the mechanisms called answer bundle and process
handle to deal with this.
5.3.4. RDQL
RDQL is a query language for RDF in the Jena framework. The development of RDQL is to
provide a data-oriented query model. This means that RDQL only retrieves information stored
in the model which contains a set of N-Triple [45] statements. RDQL provides no reasoning
mechanisms. The reasoning is provided by user selected reasoners bound to the model
containing the original ontology information. Provided with a proper reasoner, RDQL can
process ontology in various languages including OWL. Unlike OWL-QL, all variables in the
input query are must-bind variables.
5.3.5. Vampire
Vampire is a saturation-based theorem prover. The problem given to the kernel of Vampire is
a set of clauses. Each clause is a disjunction of literals. The prover then tries to derive new
clauses from the initial clause set until an empty clause is found (proved). Otherwise, the
prover goes on until no new clause can be generated (unproved) and the problem set is called
saturated [46]. As a result, Vampire is very efficient for unsatisfiable problem like proving a
subsumption (a subsumption holds if the corresponding problem is unsatisfiable), since it can
often derive an empty clause before consuming all clauses to stop. For satisfiable problems
like non-subsumption, it will be less efficient since it have to exhaust all the clauses until it
can not generate any new clause.
Vampire is a theorem prover, which makes it less efficient for acting as a real time FOL query
engine. Vampire can only prove a set of clauses that contains a query problem one at a time
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 97 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
and with only three possible outputs: satisfiable (unproved), unsatisfiable (proved) and
timeout. It can not return a list of answers like a common query engine. As a result, for
queries potentially having multiple answers, Vampire can not return all the answers at once.
In addition, Vampire needs to reload the problem data (ontology information in our test) for
each query, since Vampire can only take a file as input. All these limitations compromise the
performance of Vampire as an ontology reasoner.
5.3.6. SPARQL
It is a recursive acronym standing for SPARQL Protocol and RDF Query Language [42]. As
the name implies, SPARQL is a general term for both a protocol and a query language. Most
uses of the SPARQL acronym refer to the RDF query language. In this usage, SPARQL is a
syntactically-SQL-like language for querying RDF graphs via pattern matching. The
language's features include basic conjunctive patterns, value filters, optional patterns, and
pattern disjunction.
SPARQL can be used to express queries across diverse data sources, whether the data is
stored natively as RDF or viewed as RDF via middleware. SPARQL contains capabilities for
querying required and optional graph patterns along with their conjunctions and disjunctions.
SPARQL also supports extensible value testing and constraining queries by source RDF
graph. The results of SPARQL queries can be results sets or RDF graphs.
5.3.7. WSDL
WSDL is an XML format for describing network services as a set of endpoints operating on
messages containing either document-oriented or procedure-oriented information. The
operations and messages are described abstractly, and then bound to a concrete network
protocol and message format to define an endpoint. Related concrete endpoints are combined
into abstract endpoints (services). WSDL is extensible to allow description of endpoints and
their messages regardless of what message formats or network protocols are used to
communicate.
5.4.
Attribute-free approaches
There is also a family of representational approaches that are strongly visual, thereby
supporting knowledge elicitation from domain experts. These vary in their formal
expressiveness. Some of the more well-known members of this family include the following.
Object-Role Modeling (ORM) is similiar to the Entity-Relationship Model (ERM), but has
certain advantages. Although ER models can be of use once the design process is finished,
they are less suitable for formulating transforming or evolving a design. ER diagrams are
further removed from natural language, cannot be populated with fact instances, require
complex design choices about attributes, lack the expressibility and simplicity of a role-based
notation for constraints, hide information about the semantic domains which glue the model
together, and lack adequate support for formal transformations. ORM simplifies the design
process by using natural language, as well as intuitive diagrams which can be populated with
examples, and by examining the information in terms of simple or elementary facts. By
expressing the model in terms of natural concepts, like objects and roles, it provides a
conceptual approach to modeling. It may be appropriate to consider lessons learnt in this
framework for the user-interface tools for developing ontologies, but they are not suitable for
the formal foundations.
Another visually oriented representation system is Conceptual Graphs. These are clearly more
powerful than the above representations and can be considered as an alternative
representational form for more expressive logics. There use within ontology development is
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 98 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
so far somewhat limited. They do not add to the capabilities of more complete ontology
languages that we have described above, apart from providing a graphical view.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 99 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
6. Open Source Ontology Tools
In http://xml.com/2002/11/06/Ontology_Editor_Survey.html there is a survey that covers
software tools that have ontology editing capabilities and are in use today. The tools may be
useful for building ontology schemas (terminological component) alone or together with
instance data. Ontology browsers without an editing focus and other types of ontology
building tools are not included. Otherwise, the objective was to identify as broad a crosssection of editing software as possible. The editing tools are not necessarily production level
development tools, and some may offer only limited functionality and user support.
Concise descriptions of each software tool were compiled and then reviewed by the
organization currently providing the software for commercial, open, or restricted distribution.
The descriptions are factored into a dozen different categories covering important functions
and features of the software. These categories are summarizing the results.
Despite the immaturity of the field they were able to identify a surprising number of ontology
editors -- more than 50 overall. We have used only 12 (from 52) “popular and accepted”
ontology authoring tools (Apollo, DOE, ICOM, KAON, LinkFactory, OILEd, OntoEdit Free
Version, Ontolingua, Protégé4, RDFedt WebODE and WebOnto) from this survey, taking
into consideration tha advantages of these 12 over 52 tools. The remainder tools (IsaViz,
Hozo, Growl, Sematic Wikis, Swoop and Ontowiki) are incorporated in D1.1.1 after the
review process form UniBremen in March 2008.
6.1.
Evaluation framework used to compare the tools
This section presents the set of criteria that will be used for comparing ontology development
tools in the context of OASIS project. We will divide it into the following groups:
General description of the tools, which includes information about developers, releases and
availability.
Tool architecture, which includes information about how the tool can be extended with other
functionalities/modules and how ontologies are stored (databases, text files, etc.).
Interoperability with other ontology development tools and languages, which includes
information about the interoperability capabilities of the tool. We will review the tool's
interoperability with other ontology tools (for merge, annotation, storage, inferencing, etc.), as
well as translations to and from ontology languages.
Inference services attached to the tool. We will analyze whether the tool has a built-in
inference engine or it can use other external inference engines. We will also analyze if the tool
performs constraint/consistency checking, if it can automatically classify concepts in a
concept taxonomy and if it is able to manage exceptions in taxonomies.
Usabillity. We will analyse the existence of graphical editors for the creation of concept
taxonomies and relations, the ability to prune these graphs and the possibility to perform
zooms of parts of it. We will also analyze if the tool allows some kind of collaborative
working and if it provides libraries of ontologies.
Collaborative Ontology Evolution. Ontologies are constantly evolving; supporting the
evolution is a key feature we evaluate in the tools reported in this chapter. Two main features
supporting the collaborative structure for ontology evolution are also analyzed. We consider
multi-user editing and collaborative editing as technical features supporting both,
collaboration amongst domain experts as well as the evolution of the ontology. Multi-user
editing is here regarded as multiple parallel single-user processes on disjoint parts of the
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 100 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
ontology; whereas, collaborative editing is here regarded as working, and agreeing on shared
parts in order to satisfy a well-established set of semantic. Both activities support the
evolution of the ontology. The evolution and the processes supporting the consensus are also
related to the methodology being used. For instance, although DILIGENT does not rely on
any tool, the methodology aims to facilitate both, the collaborative and the agreement
processes.
Versioning System for Ontology Management. We analyze whether the tool supports any
versioning system.
6.2.
Protégé 4.0
6.2.1. Main Features
Protégé is a tool, which allows a user to construct domain ontology, customize data entry
forms and enter data. The tool can be easily extended to access other knowledge based
embedded applications. For example, Graphical widgets can be added for tables and
diagrams. Protégé can also be used by other applications to access the data.
Figure 25: Protégé screenshot
Protégé allows a user to simultaneously work on classes and instances. This is provided for by
a uniform GUI whose top level is composed of overlapping tabs for compact representation.
‘Classes’ tab is used to define classes and the class hierarchy, slot and slot-value restrictions,
relationships between classes and properties of these relationships. The ‘Instances’ tab can be
used to acquire instances of classes defined in the ontology. The forms are used for acquiring
instances based on the type of slots that you have specified. The default form can then be
changes by rearranging the fields on the screen, changing the size, label and properties for a
slot.
The main assumption of Protégé is that knowledge-based systems are usually very expensive
to build and maintain. For example, the expectation is that knowledge-based system
development is a team effort, including both developers and domain experts who may have
less familiarity with computer software. Protégé is designed to guide developers and domain
experts through the process of system development. Protégé is designed to allow developers
to reuse domain ontologies and problem-solving methods, thereby shortening the time needed
for development and program maintenance. Several applications can use the same domain
ontology to solve different problems, and the same problem-solving method can be used with
different ontologies.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 101 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754








GUI Framework
 Configurable (persistent) layout of components
 Multiple alternative views of the same ontology
 Tearoff and cloning of components
 Keyboard shortcuts
 Drag and Drop support
 Lazy loading components/plugins for improved speed and memory usage
API
 OWL API for OWL 1.1 provides efficient in-memory model
 Plug-in framework is OSGi compliant equinox
 Generic application framework is separated from OWL Editor Kit
Modularization
 Intelligent use of local/global repositories to handle import dependencies
 Loading of multiple ontologies into a single workspace
 Switching between ontologies dynamically
 UI hints for showing in which ontology statements are made
 Refactoring: merging ontologies and removal of redundant imports
Navigation
 History
 Global/local find
 Global usage
 Hyperlinking in editors
Refactoring Tools
 Renaming
 Handling Disjoints
 Covering Axioms
 Built-in change support allowing compound changes and undo
Reasoning Support
 Reasoners are plugins
 Direct interface to FaCT++ reasoner
 Direct interface to Pellet reasoner
OWL Editing
 Consistent rendering of ontology elements, using URI fragments or annotation
values
 OWL Description Parsing (also supports names in annotations)
 Autocompletion
 Syntax Highlighting
Plug-ins
 OWLViz (Subsumption hierarchy view/imports graph view)
The popular OWLViz has been ported over to Protégé 4.0. Implemented as a view,
the subsumption graph can now be shown on any tab. In addition, a new imports
graph is available to help understand the import dependencies within highly
modularised ontologies. OWLViz requires installation of third party libraries Graphviz.
 DL Query Tab
DL Query is part of the standard Protégé 4.0 distribution. Quickly test definitions of
classes to see that they subsume the appropriate subclasses. Or check for class
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 102 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
membership of arbitrary descriptions without having to create named class
placeholders.
Figure 26: OWL Viz plug-in
Figure 27: DL-Query Tab
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 103 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
 Object Property Description Table
Figure 28: Object Property Description Table
 Matrix Views (Class existential fillers/Individual relationships/class annotations)
Several spreadsheet-style views of an ontology, including existential fillers,
individual relationships and an object properties view. Drag and drop to add
columns and values.
Figure 29: Matrix Views
 "Tag Cloud" views (for classes/props/inds by usage and other metrics)
Wondering about the "shape" of your ontology? Several implementations of
the popular TagCloud can give you insight into different aspects of your
ontology - ratings are based on different criteria (eg class usage, depth in
hierarchy etc). The bigger the name, the higher the rating. Sort alphabetically
or by rating, and filter out low ranking entities easilly.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 104 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
 Cardinality View (restrictions shown as min/max cardinality)
An experimental alternative to the conditions widget that shows restrictions in
relation to their cardinality. If several different restrictions are along the same
property with the same filler, it "merges" them into a single line to aid
readability. It also provides hints as to whether a given set of restrictions are
closed.
Figure 30: Cardinality View
 Existential Tree
The subsumption hierarchy is not the only "axis" on which an ontology relies.
Many other axis (such as partOf) can be useful for navigation.
The Outline View follows existential (and appropriate cardinality) restrictions
to build up a view of the current class by its structure. The Existential Tree
view is a simplified version that shows the tree along a specified property.
Figure 31: Existential Tree
 Sub Ontology Tab
Ever wished you could copy/drag and drop a class hierarchy from one
ontology into another instead of typing them in? Or ever wished you could
extract the class hierarchy from one section of a large ontology like the NCI
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 105 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
meta-thesaurus or GO into a separate ontology? If so, the Sub Ontology tab is
your answer to these tedious tasks! What is more, it also lets you copy over the
annotations on concepts in the hierarchy being copied/extracted across so the
concepts from your ontology can still retain the metadata from the original
ontology.
 Excel Import
Load excel or CSV files and generate classes from the content. Provide rules to
create restrictions between columns.
Figure 32: Excel Importer

Bookmarks
Forever getting lost in large ontologies? Or, want to keep a set of
classes/properties handy for a demo? Drag classes/properties into this view and
they are accessable anytime to click on. They will also be saved along with
your ontology annotations for future reference.
 Taxonomy cut-paste
Sometimes, all you need is a quick extract of a part of your hierarchy for a
paper or presentation. These 2 very simple views provide a quick way to
extract parts of your hierarchy into text form. The Tabbed Subclasses view just
shows a tab-indented list of your asserted class hierarchy from the currently
selected class. The Decendant Names view does the same without indentation.
Just cut and paste into your favourite applications.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 106 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Figure 33: Bookmarks
Figure 34: Taxonomy Cut-Paste
 Browser (OWLDoc)
The first rewrite of the popular OWLDoc tool that now has both an export to
HTML and a dynamic view that allows you to browse from within Protégé.
OWL1.1 is supported and full use is made of the highly optimised OWLAPI
Usage model. All links navigate to the appropriate resource. Further features
(including a server version with search/query support) are under development.
Find the OWLDoc View (above) under the View-Misc views menu. An HTML
presentation of the last selected class, property or individual will be displayed
as you browse. Updates to the ontology are reflected immediately.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 107 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
OWLDoc export (below) is in the Tools menu - just provide a directory to
export to and a browser will open when it finishes. OWLDoc will create a
bundle of (mostly) static HTML pages for publishing to the web or distributing
to colleagues (a small amount of javascript is used to create a fragment of the
class hierarchy on each class summary page).
 The Protégé Nerd
For all of those die-hard Protégé users who love to reminisce - the Nerd returns
- practice your view duplication and create a whole nerd tab - excellent Kitsch
value especially made for Olivier Dameron.
Figure 35: The Protégé Nerd
 TerMine Plugin
The Protégé TerMine plugin uses text mining tools to extract candidate terms
from a corpus of text and provides an interface for rapidly bringing these terms
into an OWL ontology. It currently uses the TerMine term extraction tool
provided by NaCTeM to extract concepts from text. The plugin accesses
TerMine via a Web Service over the Internet.
 OWL lint plugin
The OWL lint framework is designed to be a flexible way to define and run
tests against a set of OWL ontologies for quality control, debugging, best
practice and many other purposes. The plugin provides a tab in which lints can
be loaded and a report can be generated for the active ontologies.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 108 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Figure 36: TerMine plug-in
Figure 37: OWL Lint
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 109 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754

Annotation Search View
A view for searching entity annotations for a string or regular expression match. Can also be
used with no string specified, just the annotation URI, for finding deprecated entities, or
TODO items. The entity name at the start of each result is a link that can be clicked for easy
navigation.
 Alternative Annotation View
A view that can be configured to show a set of standard annotation fields for every
class/property/individual. This makes it quicker to annotate as they are always in the same
order, editable inline and easy to navigate through (Ctrl-Tab/Shift-Ctrl-Tab). Useful when
developing in a consortium and some standard metadata set should always be entered.
Configure the view and import/export shared configurations in File | Preferences | Annotate
Preferences.
Figure 38: Annotation Search View
Figure 39: Alternative Annotation View
 Change View
When writing plugins, particularly those that perform refactoring, it is useful to be able to
verify the changes that have been applied to the model. This view provides a very
straightforward list of changesets and the axioms that have been added and removed.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 110 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Figure 40: Change View
Collaborative Ontology Evolution: Protégé 3.4 supports collaborative ontology editing as
well as annotation of both ontology components and ontology changes. It supports the
searching and filtering of user annotations, also known as notes, based on different criteria.
Multiple users may edit the same ontology at the same time. In multi-user mode, all changes
made by one user are seen immediately by other users. There are two working modes
available for Collaborative Protege. Both modes support multiple users working on an
ontology:
1. The multi-user mode - allows multiple clients to edit simultaneously the same ontology
hosted on a Protege server. All changes made by one client are immediately visible by
other clients. This mode is also referred to as client-server mode, or concurrent mode
and requires a client-server setup. This mode is based on the implementation of the
multi-user Protege and is the preferred mode in which Collaborative Protege should be
run.
2. The standalone mode - allows multiple users to access the same ontology in succession.
The ontology can be stored on a shared network drive and all clients will access the
same project files. However, simultaneous access is not possible. This mode is also
referred to as the consecutive mode. The evolution of the ontology is annotated so that
other users can follow the process. Although this feature has been available in Protégé
since 2007 few ontology developments have reported on its usability. Protégé 4.0
Multi-user editing is thus supported by the stand-alone version of both Protégé 3.4 and 4.0.
Versioning System for Ontology Management: Neither Protégé 3.4 nor 4 supports any
versioning system.
6.3.
BioPortal
Collaborative Ontology Evolution: Biportal is an ontology repository management tool that
allows developers to store, annotate, visualize, search and retrieve ontologies. Per se
BioPortal does not support collaborative editing nor dies it support multiple users working on
different branches on an ontology. However, it does provide an environment that promotes
collaboration, for instance by being able to annotate ontologies. BioPortal also provides a
manual mapping mechanism that facilitates the engagement of the community.
Versioning System for Ontology Management: not supported as such. However, as
Bioportal is an ontology repository it makes it possible for users to store several copies of an
ontology.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 111 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
6.4.
OilEd
OilEd is a simple editor that allows the user to create and edit OIL ontologies. The main
intention behind OilEd is to provide a simple, freeware editor that demonstrates the use of,
and stimulates interest in, DAML+OIL. OilEd is not intended as a full ontology development
environment - it will not actively support the development of large-scale ontologies, the
migration and integration of ontologies, versioning, argumentation and many other activities
that are involved in ontology construction. It should, however, provide enough to allow the
basic construction of OIL ontologies and demonstrate the power of the connection to the
FaCT reasoner.
Figure 41: OilEd screenshot
OilEd has been built by The Information Management Group, Department of Computer
Science, University of Manchester, and is copyright University of Manchester. The original
development of OilEd was supported by Interprice GmbH and the Free University of
Amsterdam.

Basic features :
 Import format
o RDF(S), OIL and DAML+OIL
 Export format
o RDF(S), OIL, DAML+OIL, SHIQ, dotty and HTML
 Not support graph view
 Consistency check
o Via built-in FaCT
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 112 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754

 Limited web support
o RDF URIs, limited namespaces, limited XML Schemas
Additional features :
 Arbitrary class expressions can be used as slot fillers.
 Primitive & defined classes
 Concrete type expressions
 Concrete Types aren’t very well supported
o XML Schema types now in DAML+OIL
 Ontology storage
o File
 No extensibility
Collaborative Ontology Evolution: not supported.
Versioning System for Ontology Management: not supported
6.5.
Apollo
Apollo is a user-friendly knowledge modeling application. The modeling is based around the
basic primitives, such as classes, instances, functions, relations etc. Internal model is build as
a frame system according to the internal model of the OKBC protocol.
Figure 42: Main window with loaded ontology in Apollo
Apollo’s class system is modeled according to the OKBC. The knowledge base consists of
ontology’s that are hierarchically organized. Ontology can inherit other ontology’s and then
use classes of inherited ontology’s as its own.
Every ontology inherits at least one ontology − a default ontology, which contains all
primitive classes: Boolean, integer, float, string, list etc. Class contains slots of two types: non
template and template slots. Apollo currently does not support non template class slots. For
each class is possible to create a number of instances. An instance inherits all slots of the
class. Each slot has a set of facets.
The following set of default facets, that is implicitly created for each slot:
:VALUE−TYPE,:VALUE,:DEFAULT−VALUE,:CARDINALITY,:MINIMUM−CARDINA
LITY,:MAXIMUM−CARDINALITY,:ALIAS,:INHERITANCE.

Basic features :
 Import/export format
o CLOS(Common LISP Object System) and OCML
 Not support graph view
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 113 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
 Consistency check
Apollo’s object model features strong typing, that is, value of the slot can be only of the same
type as is a type of the slot and all values are checked during editing for the correct type and
existence. Undefined instances are immediately removed from the ontology, as soon as there
is not any slot that refers to them. Similar concept applies to the undefined classes − e.g. for
the type of the slots. You cannot create instances of such classes as well as edit their slots.
Such strong type checking is a very powerful feature; however it is often required to use weak
typing as present in Lisp language. Future versions of Apollo will incorporate support for
weak typing, as well as Meta classes.

 Not support web
 Not support multi-user
Additional features :
 Not support merging
 Not support information extraction
 Extensibility with plug-ins
 Ontology storage
o File
 Ontology library
 No collaborative working
Collaborative Ontology Evolution: not supported.
Versioning System for Ontology Management: not supported
6.6.
RDFedt
The RDFedt brings fast and easy ways to build complex and structured RDF (and RSS)
documents. With the element-tree one can get the overview at complex datastructures.
Additionally functions help to test the data and - if necessary - they give comments and
errormessages.
This publisher supports: language RDF properly said; language RDF Schema; Dublin
elements Core (standard of metadados); the RDF Site Summary 1.0 with the following
modules: aggregation, notation, change of page, content, cut, organization, threading;
declaration and levels of styles in XML; set of imported elements; to open and to save
documents in archives of the type xml; to generate code from tree RDF; to print the generated
codes; to test entered in tree RDF; to generate list automatically of links based in RDF of a
document HTML.
An important point is that it is not a Java program, so it is not platform independent. RDFedt
works only on Windows platforms.


Basic features :
 Import/export format
o RDF(S), OIL, DAML and SHOE
 Not support graph view – only tree view
 Very limited consistency check
o Only checks writing mistakes
 Not support multi-user
 Web support
o Via RSS (RDF Site Summary)
Additional features :
 Support for Dublin Core Element Set
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 114 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
 Support RSS modules
o Aggregation, Annotation, etc
 Automatic generation of a rdf-based linked list from a html-document
 Load and save XML files
Collaborative Ontology Evolution: not supported.
Versioning System for Ontology Management: not supported
Figure 43: RDFedt screenshot
6.7.
OntoLingua
Ontolingua provides a distributed collaborative environment to browse, create, edit, modify,
and use ontologies. This tool is an Ontology library and server, which supports a WWW
interface and translation into various formats. It provides a suite of ontology authoring tools
and a library of modular, reusable ontologies. The environment is available as a World Wide
Web service and has a substantial user community. The tools in Ontolingua are oriented
toward the authoring of ontologies by assembling and extending ontologies obtained from the
library. The Ontolingua server can be accessed with a standard web browser.
The available services include:
Chimaera: Helps in reorganizing the taxonomy and resolve name conflicts in a KB especially useful when merging KBs, but also useful as an ontology browser, and ontological
sketchpad.
CML Model Fragment Editor: Allows browsing, creating and editing CML model
fragments.
General purpose data structure inspector: Allows one to look inside data structures in the
Lisp image within which the server is running according to multiple perspectives.
Ontology Editor: Provides browsing, creating and editting Ontologies using your web
browser.
Webster: An HTTP gateway to a webster server.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 115 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Figure 44: Screenshot of ontology creation in Ontolingua

Basic features :
 Import format
o IDL, KIF
 Export format
o KIF, CLIPS, IDL, OKBC syntax and PROLOG syntax
 No support for graphical view
 Limited consistency check
o Via Chimaera (reorganize the taxonomy and resolve name conflicts in KB)
 Freely web access
 Multi-user support
o Via write-only locking and user access levels

Additional features :
 No extensibility
 Ontology storage
o Files
Collaborative Ontology Evolution: not fully supported. OntoLingua provides a distributed
collaborative environment to browse, create, edit, modify, and use ontologies. In principle
OntoLingua makes it easy for multiple users to work on the same file by write-only locking
and user access levels. However, the facilities provided by OntoLingua for editing and
visualizing are scant and not specifically oriented to ontology development.
Versioning System for Ontology Management: not supported
6.8.
OntoEdit
OntoEdit is an Ontology Engineering Environment supporting the development and
maintenance of ontologies by using graphical means. OntoEdit is built on top of a powerful
internal ontology model. This paradigm supports representation-language neutral modeling as
much as possible for concepts, relations and axioms. Several graphical views onto the
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 116 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
structures contained in the ontology support modeling the different phases of the ontology
engineering cycle - the ontology kickoff phase, refinement phase, and evaluation phase. It
relies on W3C standards and offers a multitude of export interfaces to all major ontology
representation languages. The tool is based on a flexible plug-in framework. Firstly this easily
allows extending functionality in a modularized way. The plug-in interface is open to third
parties, which enables users to extend OntoEdit easily by additionally needed functionalities.
Secondly, having a set of plug-ins available like e.g. a domain lexicon, an inferencing plug-in
and several export and import plug-ins, this allows for user-friendly customization to adapt
the tool to different usage scenarios.
The Requirements Specification phase for ontology development leads to an ontology
requirements specification document describing what an ontology should support. Collecting
requirements for the envisaged ontology starts the ontology development. This task is
performed by a team of experts for the domain accompanied by experts for modeling. It also
guides an ontology engineer to decide about relevant concepts and their hierarchical structure
in the ontology. This phase is supported by OntoEdit by the two plug-ins OntoKick and
Mind2Onto5 for meta ontology description with automatically calculated statistic
information.
Figure 45: OntoEdit screenshot
The goal of the Refinement phase is to produce a mature and application-oriented target
ontology according to the specification given by the kickoff phase. The ontology engineer
may develop the concept hierarchy, relations and axioms in as much as possible independence
of a concrete representation language. The ontology engineering environment OntoEdit uses a
powerful ontology model to store the conceptual model of an ontology. With a single click,
the Ontology Engineer is supported to transform the conceptual representation to all major
ontology representation languages like RDF(S), XML, DAML+OIL or F-Logic.
OntoEdit tool allows the user to edit a hierarchy of concepts or classes. These concepts may
be abstract or concrete, which indicates whether or not it is allowed to make direct instances
of the concept. The Ontologies are modeled in a 'is-a' hierarchy which means that sub
concepts have all properties of their super concepts. A concept may have several names,
which essentially is a way to define synonyms for that concept. Concepts may participate in
binary typed relations. Attributes of concepts are also considered to be relations. For this
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 117 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
purpose, built-in types such as STRING, INTEGER and BOOLEAN are introduced. Relations
can also be composed based on other relations. Relations can be ordered in a hierarchy, which
allows for inheritance/refinement of characteristics of relations. Each concept and relation can
be documented explicitly within the ontology. This is especially important when exchanging
ontologies. Metadata of the ontology, such as the creator and the date of last modification, can
also be stored within the ontology. Transformation modules can be linked into the system,
which allow translating the ontology from its own general XML-based storage format to a
more specific format. Currently an F-Logic transformation module is available, and work on
an RDF module is being done. The whole system is multilingual, meaning that each concept
name, relation name or documentation string can be entered in several languages. The tool
allows for multiple ontologies to be opened at the same moment. The OntoEdit plug-in
architecture is hot-pluggable. That means that you can load and unload plugins during
runtime.

Basic features :
 Import/export format
o XML, RDF(S), FLogic and DAML+OIL for free version
o XML, RDF(S), FLogic, DAML+OIL and SQL-3 (export only) for
professional version
 Graph view
 Consistency check
 Web support
o URIs

Additional features :
 Ontology storage
o File (free) vs. File and DBMS (professional)
 Built-in inference engine
o Not support (free) vs. support via OntoBroker (professional)
 Collaborative working and Ontology library
o Not support (free) vs. support (professional)
Currently, the successor of OntoEdit is OntoStudio which is a commercial product based on
IBM’s development environment Eclipse. It can be downloaded for three months free
evaluation period.
Collaborative Ontology Evolution: not supported.
Versioning System for Ontology Management: not supported
6.9.
WebODE
This tool is based on the widely used and tested Methontology methodology built in the
Technical School of Computer Science (FI) in Madrid.
A strong need for an integrated ontological engineering workbench supporting three groups of
activities was the major motivation behind development of this tool. These are grouped as
follows:
(1) Ontology Development, Management and Population activities;
(2) Ontology middleware services to allow the easy used and integration of ontological
technology in information systems; and
(3) Ontology-based applications' development suites to ease the creation of ontology-based
applications.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 118 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Concisely, WebODE is not an isolated tool for the development of ontologies, but an
advanced ontological engineering workbench that provides varied ontology related services,
and covers and gives support to most of the activities involved in the ontology development
process. WebODE has been created to provide technological support for Methontology, an
ontology construction methodology. Nevertheless, this fact does not prevent it from being
used following other methodologies or no methodological approach at all. It has been
implemented using state-of-the-art technology such as Java, RMI, CORBA or XML and
Minerva Application Server.
WebODE Architecture (3-tier model)
The first tier provides the user interface. For the current release, this interface is provided by
means of a web browser. The presentation tier was implemented using HTML, CSS
(Cascading Style Sheets) and XML (Extended Mark-up Language) to easily interoperate with
other applications. So that the client can work more rapidly and thus ease the server of the
burden of user validations, technologies like JavaScript and Java are used at this level. The
first one provides easy and quick form validation while the second allows more complex
presentation and logic schemas like graphical design or formula validation.
The second tier provides the business logic. In fact, this tier consists of two other sub-tiers:
presentation sub-tier and logic-subtier. The logic sub-tier provides direct access to ontologies
by means of a well-defined API (Application Programming Interface) supplied through an
application server developed by our team (Minerva Application Server). This server provides
access to services through RMI-IIOP (Remote Method Invocation-Internet Inter ORB
Protocol) thus making application development and integration very easy. The presentation
sub-tier is responsible for generating the content to be presented in the user’s browser. It is
also aimed at handling user requests from the client (like form handling, queries, etc.) and
forward them to the ODE service as appropriate. Technologies such as servlets or JSPs (Java
Server Pages) were used for this purpose.
The third tier is comprised of the data. For our ontologies, we use a relational database
(Oracle) to store all the information about them. This database is accessed by means of the
JDBC (Java Database Connectivity) standard.
Figure 46: WebODE ontology editor
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 119 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754

Basic features :
 Import format
o WebODE’s xml, RDF(S), DAML+OIL, OWL and UML
 Export format
o WebODE’s xml, RDF(S), OIL, DAML+OIL, OWL, PROLOG, X-CARIN,
Java/Jess and UML
 Graph view
o Form based graphical user interfaces
 Consistency check
o Type constraints, numerical constraints, cardinality constraints, taxonomic
consistency variation
 Web support
o URIs
 Multi-user support
o By synchronization, authentication and access restrictions per user groups

Additional features:
 Merging
o Via ODEmerge methodology
 Extensibility
o Via plug-ins
 Ontology storage
o DBMS
 Collaborative working
 No support for ontology libraries
Collaborative Ontology Evolution: WebOde is intrinsically related to METHONTOLOGY,
a methodology for developing ontologies. The methodology does not provide methods or
techniques that support the evolution of ontologies. However, as WebOde is a web based tool,
it does support collaborative development. WEBOde facilitates the generation of groups of
users, which allow establishing access to ontologies, as well as Synchronization mechanisms
also exist that allow several users to edit the same ontology. It does not support the process by
means of which agreements are reached.
Versioning System for Ontology Management: not fully supported.
6.10. KAON
KAON is an open-source ontology management system targeted for business applications. It
includes a comprehensive tool suite allowing easy ontology creation and management and
provides a framework for building ontology-based applications.
KAON provides two user-level applications: OiModeler and KAON PORTAL, All other
KAON modules are intended for software development. OI-modeler is an ontology editor and
provides support for ontology creation and maintenance. KAON Portal provides a simple
framework for navigating and searching ontology’s through Web browsers. The latest version
is 1.2.7 [20].
KAON is primarily a framework for the development of other ontology-based applications. It
has the following modules:
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 120 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
- Front-end: The front-end is mainly presented by two applications, OI-modeler and
KAON Portal.
- Core of KAON: The core of KAON is the two APIs for the Resource Description
Framework (RDF) and the KAON ontology language
- Libraries: To provide the functionality of KAON.
Figure 47: KAON Tool screenshot

Basic features :
 Import/export format
o RDF(S)
 Not support graph view
 Consistency check
 Web support
o Via KAON Portal
 Multi-user support
o By concurrent access control with transaction oriented locking and rollback

Additional features :




No support for merging
Scalable and efficient reasoning with ontologies
Extends RDFS with symmetric, transitive and inverse relations
Meta-modeling similar to F-Logic using axiom patterns
Collaborative Ontology Evolution: Multiple users can edit the same file by a lock and
release mechanism. KAON does not support in any particular manner the agreement
process. The collaboration is only supported by making it possible for the users to access
the same file.
Versioning System for Ontology Management: not supported
6.11. ICOM
ICOM is an advanced CASE tool which allows the user to design multiple extended EntityRelationship diagrams with inter- and intra-schema constraints. The intention behind ICOM is
to provide a simple, freeware conceptual modelling tool that demonstrates the use of, and
stimulates interest in, the novel and powerful knowledge representation based technologies
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 121 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
for database and ontology design. It turned out to be extremely useful also in supporting the
conceptual modelling of "classical" databases involving a single rich schema with integrity
constraints, and in designing ontologies for various purposes.
Figure 48: ICOM screenshot
The conceptual modeling language supported by ICOM can express:
- the standard Entity-Relationship data model, enriched with IsA links (i.e., inclusion
dependencies),disjoint and covering constraints, full cardinality constraints, and definitions
attached to entities and relations by means of view expressions over other entities and
relationships in the schema.
- aggregated entities together with their multiply hierarchically organized dimensions -- e.g. it
is possible to represent multidimensional cubes over star and snowflake schemas.
- rich class of (inter-schema) integrity constraints, as inclusion and equivalence dependencies
between view expressions involving entities and relationships possibly belonging to different
schemas.
ICOM reasons with (multiple) diagrams by encoding them in a single description logic
knowledge base, and shows the result of any deductions such as inferred links, new stricter
constraints, and inconsistent entities or relationships. Theoretical results guarantee the
correctness and the completeness of the reasoning process. To the best of our knowledge, this
is the first implemented tool for EER conceptual modelling with a provably complete
inference mechanism for consistency checking and for deduction -- i.e., derivation of implied
links and constraints in the schema.
Completeness of reasoning means in this context that no valid deduction is left out by the
inference engine. This of course holds for the full data model employed by ICOM, which is
much richer than EER. The system employs the DLR/SHIQ description logic to encode the
schemas and to express the views and the constraints.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 122 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
ICOM tool is written in standard Java 1.2, and it is being used on Linux and Windows
machines. ICOM communicates via a CORBA protocol with the FaCT description logic
server.
Collaborative Ontology Evolution: not supported
Versioning System for Ontology Management: not supported
Figure 49: ICOM screenshot

Basic features :
 Import/export format
o XML and UML
 Graph view
o Native editing of ER diagrams
 Consistency check
o Via FaCT
 No web support
 No multi-user support

Additional features :
 Merging
o Supports inter-ontology mapping with graphical interface
 Not support information extraction
Collaborative Ontology Evolution: not supported
Versioning System for Ontology Management: not supported
6.12. DOE (Differential Ontology Editor)
DOE is a simple ontology editor which allows the user to build ontologies according to the
methodology proposed by Bruno Bachimont. The specification process is divided in 3 steps.
In the 1st step, the user is invited to build taxonomies of concepts and relations, explicitly
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 123 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
justifying the position of each item (notion) in the hierarchy. For each notion, the user builds a
definition following 4 principles which come from the Differential Semantics theory. Hence,
the user has to explicit why a notion is similar but more specific than its parent (2 principles),
and why this notion is similar but different from its siblings (2 other principles). The user can
also add synonyms and encyclopedic definition in a few languages for all notions. In a 2nd
step, the two taxonomies are considered from an extensional semantics point of view. The
user can augment them with new entities (defined) or add constraints onto the domains of the
relations. Finally, in a 3rd step, the ontology can be translated into a knowledge representation
language, which allows to use it in an appropriate ontology-based system or to import it into
another ontology-building tool to specify it further: RDFS, OWL, DAML+OIL, OIL and
CGXML (a language to specify conceptual graphs). DOE is not intended as a full ontology
development environment: it will not actively support many activities that are involved
traditionally in ontology construction, such as advanced formal specification dealt with by
tools like Protégé 2000. It is rather a complement of other editors, offering linguistics-inspired
techniques which attach a lexical definition to the concepts and relations used, and justifies
their hierarchies from a theoretical, human-understandable point of view.
Figure 50: DOE screenshot

Basic features :
 Import/export format
o OWL, OIL, CGXML, XSLT, RDFS and DAML+OIL
 No support for graphical view
 Consistency check
o Via arity and type inheritance on relational domains
o Via detection of cycles in hierarchies
 Basic web support
o URL of the ontology

Additional features :
 Interoperability
o The structured textual information is exported in comments. There are few
formal features such as multi-hierarchies, individuals which make it very
similar to RDFS. Interpretability is achieved using both RDFS and OWL.
Results using RDFS produces satisfactory results, while with OWL some
problems arise with Protégé and WebODE. Theses are discussed in the
drawbacks section.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 124 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
 No support for merging
 Problems with Dublin Core Metadata during importing
 For interoperability with Protégé OWL plug in, the individual namespaces need to
be explicitly declared using the Protégé namespace
 While using WebODE, the individuals are not imported
 Concepts cannot be defined intentionally with constraints
 Only types of the domains of relationships can be specified
 No axiom editor
Figure 51: Interoperabitily using RDFS and OWL
Collaborative Ontology Evolution: not supported
Versioning System for Ontology Management: not supported
6.13. WebOnto
WebOnto, which is a tool developed by the Knowledge Media Institute of the Open
University in England, supports the collaborative browsing, creation and editing of
ontologies, which are represented in the knowledge modeling language OCML without
suffering form the interface problems. The aim of WebOnto is to be easy-to-use, yet have
scalability up to large ontologies. Main features of WebOnto are management of ontologies
using a graphical interface, the automatic generation of instance editing forms from class
definitions, inspection of elements taking into account the inheritance of properties and
consistency checking, and support for collaborative work using broadcast / receive and
making annotations. WebOnto consists of Java-based central server and clients.


Basic features :
 Import format
o RDF
 Export format
o GXL, RDF(S) and OIL
 Graph view
 Limited consistency check
 Web support
 Multi-user
o Global write-only locking with change notification
Additional features :
 Multiple inheritance and exact coverings
 Meta-classes
 Class level support for prolog-like inference
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 125 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
 Online service only
 Information extraction
o Via MnM
 Not support merging
 No extensibility
 Built-in inference engine
 Ontology storage
o File
 Collaborative environment
Figure 52: WebOnto screenshot
Collaborative Ontology Evolution: it is a collaborative enviroment for building ontologies.
Although it facilitates multi editing, and to some extempt the collaboration, the agreement
process is not considered. Furthermore, it does not proviede any mapping or annotation
mechanism.
Versioning System for Ontology Management: not supported
6.14. OntoWiki
OntoWiki is a free, open source ontology editor and a knowledge acquisition system.
OntoWiki is a web-application written in PHP and using MySQL as a persistent storage
backend. Other than many Semantic wikis OntoWiki is rather form based than syntax based
and thus tries to hide as much of the complexity of knowledge representation formalisms from
its users as possible. OntoWiki is being mainly developed by the AKSW research group at
Universität Leipzig in collaboration with many volunteers around the world.
Collaborative Ontology Evolution: Although Ontowiki is a web-based environment the
support it offers for multiple users working on the same file is limited to a lock and release
mechanism. Moreover, it does not support in any special manner the agreement process. The
annotation facilities it provides are negligible.
Versioning System for Ontology Management: not supported
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 126 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Figure 53: Ontowiki Ontology Editor
6.15. IsaViz
IsaViz is a visual environment for browsing and authoring RDF models as graphs. This tool is
offered by W3C Consortium. IsaViz (http://www.w3.org/2001/11/IsaViz/Overview.html) was
developed by Emmanuel Pietriga. The first version was developed in collaboration with
Xerox Research Centre Europe which also contributed with XVTM, the ancestor of ZVTM
(Zoomable Visual Transformation Machine) upon which IsaViz is built. As of October 2004,
further developments are handled by INRIA Futurs project In Situ. IsaViz also includes
software developed by HP Labs (Jena 2 Semantic Web Toolkit), the Apache Software
Foundation (Xerces Java 2), and makes use of the GraphViz library developed by AT&T
Research (http://www.w3.org/2001/11/IsaViz/Overview.html). IsaViz does not follow or
include any methodology for building an ontology. IsaViz imports RDF/XML and N-Triples,
and exports RDF/XML, N-Triples, Portable Network Graphics (PNG) and Scalable Vector
Graphics (SVG). Therefore, it is possible to import ontologies to other editors, for instance,
Protégé or OilEd. The IsaViz environment is composed of four main windows: the IsaViz
RDF Editor window, the Graph window, the Definition window and the Attribute window.
The IsaViz RDF Editor window contains the main menus and a palette of tools. The Graph
window is a ZVTM view (http://www.w3.org/2001/11/IsaViz/Overview.html ) in which is
displayed the RDF model represented as a 2D graph. ZVTM views display an area of an
endless space as seen through a camera. This camera can be moved in the virtual space and its
altitude can be changed, resulting in a 2.5D Graphical User Interface with smooth zooming
capabilities. IsaViz has a user friendly interface. IsaViz has three different ways of viewing a
graph. This can be a distinguishing feature when evaluating this tool with others tools. There
are 3 different ways of viewing a graph: Graph View; Radar View and Property Browser.
IsaViz is also recognized by its Zoomable User interface (ZUI). This interface allows rapid
navigation of the graphs used to represent the RDF models.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 127 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
The Definitions window is composed of five tabs:





The tab Namespaces is a table containing namespace definitions (with their optional
prefix bindings).
The tab Property Types is a table containing property type definitions.
The tab Property Browser is a text browser in which is exhibit all the properties
associated with the currently selected resource.
The tab Stylesheets (since version 2.0) is a table containing all Graph Stylesheets
(GSS) that should be applied to the model.
The tab Quick Input (since version 2.0) is a text area used for pasting statements
expressed in RDF/XML, N-Triples or Notation3.
The Attribute window shows the attributes of a selected item of the graph. All the attributes
shown in this window can be edited. IsaViz can render RDF graphs using GSS, a stylesheet
language derived from Cascade Style Sheet (CSS) and Scalable Vector Graphics (SVG) for
styling RDF models represented as node-link diagrams. Resources and literals are the nodes
of the graph (ellipses and rectangles respectively), with properties represented as the edges
linking these nodes.
This editor has a user manual and a Web page with installation instructions. It also has a
mailing list and a list of the most common problems. For that reason, it is really simple to start
using this tool. The user can easily solve the problems that can emerge during installation or
usage, by using the mailing list of IsaViz.
Figure 54: IsaViz Ontology Editor
Collaborative Ontology Evolution: not supported
Versioning System for Ontology Management: not supported
6.16. HOZO
Hozo is based on both of a fundamental consideration of an ontological theory and a
methodology of building ontology. Since Hozo is based on an ontological theory of a roleconcept, it can distinguish concepts dependent on particular contexts from so-called basic
concepts and contribute to building reusable ontologies. “Hozo” is composed of “Ontology
Editor”, “Onto-Studio” and “Ontology Server”. The ontology and the resulting model are
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 128 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
available in different formats (Lisp, Text, XML/DTD,DAML+OIL) that make it portable and
reusable.
Ontology Editor provides users with a graphical interface, through which they can browse and
modify ontologies by simple mouse operations. It treats “role concept” and “relation” on the
basis of fundamental consideration. Onto-Studio is based on a method of building ontologies,
named AFM (Activity- First Method). It helps users design ontology from technical
documents.
Collaborative Ontology Evolution: not fully supported. HOZO Server facilitates that
multiple users work on the same file by means of a lock and release mechanisms. However, it
does not support the collaborative agreement or discussion process when developing
ontologies.
Versioning System for Ontology Management: not supported
6.17. GrOWL
GrOWL is a visualization and editing tool for OWL and DL ontologies. GrOWL aims to
reconcile modern ontology language OWL with old semantic network philosophy by
providing a set of graphic idiom that cover almost every OWL construct.
Growl provides:
 Graphic representation for all OWL constructs and all common DL expressions
 Advanced methods of navigation within large ontologies
 Facilities to view separately TBox, ABox, RBox, Class Hierarchy , etc.
 Framework for visual editing of OWL ontologies
 Growl is implemented as java applet and stand alone editor and uses WonderWeb
OWL API. It runs on Sun java runtime 1.4.2 or later.
Collaborative Ontology Evolution: not supported
Versioning System for Ontology Management: not supported
6.18. Semantic Wikis
The basic idea of semantic wikis is to provide an underlying formal and (partially) machineprocessable model of the knowledge described it their pages, which allows users to capture or
identify metadata about the pages and their relations. Based on this knowledge model, new
facts, e.g. implied relations between pages, can be inferred from existing facts in the
knowledge model.
Semantic Wikis Projects: [47] describe Makna, a Wiki engine that was extended with generic
ontology-driven components that allow collaborative authoring, querying, and browsing
Semantic Web information. IkeWiki [48] allows annotating links, typing of pages, and
context dependent content adaptation. [49] have the objective to make the knowledge within
Wikipedia, the online encyclopedia, machine-accessible by adding semantic information.
Platypus Wiki [50] focus on the creation of RDF (instance) data, Platypus Wiki aims at
augmenting a wiki with semantics. WikiFactory [51] is a framework that allows the automatic
generation of domain specific wikis. The main difference to our work is that existing
approaches aim at augmenting existing wiki content with semantics instead of using a Wikilike infrastructure as an environment for collaboratively building ontologies. The OASIS COF
and the related content management tools developed within the project will be made available
to all partners as well as outside Consortium in a “Wikipedia style” framework and as open
source software.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 129 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Currently, there is an internal Wiki for the OASIS project 28. Every partner is encouraged to
add OASIS relevant information to this Wiki. In particular the submitted deliverables should
be available there. In Deliverable ID1.2.2 you can find more information about the role of the
wiki as a useful tool in the collaborative management of ontologies.
Collaborative Ontology Evolution: not supported
Versioning System for Ontology Management: not supported
6.19. SWOOP
SWOOP is a Web-based OWL ontology editor and browser. SWOOP contains OWL
validation and offers various OWL presentation syntax views. It has reasoning support and
provides a multiple ontology environment. Ontologies can be compared, edited and merged.
Different ontologies can be compared against their Description Logic-based definitions,
associated properties and instances. SWOOP’s interface has hyperlinked capabilities so that
navigation can be simple and easy. SWOOP does not follow a methodology for ontology
construction.
Users can reuse external ontological data [101]. This is possible either by purely linking to the
external entity, or importing the entire external ontology. It is not possible to do partial
imports of OWL. There are several ways to achieve this, such as a brute-force syntactic
scheme to copy/paste relevant parts (axioms) of the external ontology, or a more elegant
solution that involves partitioning the external ontology while preserving its semantics and
then reusing (importing) only the specific partition as desired.
It is possible to search concepts across multiple ontologies. SWOOP makes use of an
ontology search algorithm, that combines keywords with DL-based in order to find related
concepts. This search is made along all the ontologies stored in the SWOOP knowledge base.
With SWOOP it is possible to have collaborative annotation using the Annotea plugin. This
plug-in presents a useful and efficient Web ontology development. Users may also download
annotated changes for a given ontology. The plug-in is used by the users to write and share
annotations on any ontological entity. Different SWOOP users can subscribe to the server.
Users can maintain different version of the same ontology since mechanisms exist to maintain
versioning information using a public server.
SWOOP takes the standard Web browser as the User Interface paradigm. This Web ontology
browser has a layout that is well known by most of the users. There is a navigation side bar on
the left. The sidebar contains a multiple ontology list and a class/property hierarchy of the
ontology. The center pane works like an editor. There is a range of ontology/entity renders for
presenting the core content.
This editor provides support for ontology partitioning. OWL ontologies can be automatic
portioned into distinct modules each describing a separate domain. There is also support for
ontology debugging/repair. SWOOP has the ability to identify the precise axioms that causes
errors in an ontology and there are also natural language explanation of the error. An
automatic generation of repair plans to resolve all errors are provided. To better understand
the class hierarchy, a “CropCircles” visualization format was implemented.
SWOOP is based on the conventional Model-View Controller (MVC) paradigm. The
SWOOP Model component stores all ontology-centric information pertaining to the SWOOP
workspace and defines key parameters used by the SWOOP UI objects. A SWOOP
ModelListener is used to reflect changes in the UI based on changes in the SWOOP Model
28 https://134.102.53.11/oasis-wiki/pmwiki.php?n=OASIS.Homepage
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 130 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
[101]. Control is managed through a plug-in based system. This system loads new Renders
and Reasoners dynamically. Therefore, it is possible to guarantee modularity of the code, and
encourage external developers to contribute to the SWOOP project easily.
SWOOP uses the Wonder Web OWL API. This API provides programmatic access to data
representing OWL ontologies. This API is used as the underlying OWL representation model.
It has Ontology Renderers that display statistical information about the ontology, the
annotations, the DL expressivity and the OWL species level. There are default plug-ins for
different presentation syntax for rendering ontologies. For instance, there are the following
presentations syntax RDF/XML, OWL and N3. It is easy to install and has two public mailing
lists available: General SWOOP (for users) and Technical SWOOP (for developers). A
SWOOP application can be downloaded from http://www.mindswap.org/. After downloading
the package, the user has only to run the “runme” batch file.
SWOOP is developed as a separate Java application that attempts to provide the look and feel
of a browser-based application. Its architecture was designed to optimize OWL browsing and
to be extensible via a plug-in architecture.
Collaborative Ontology Evolution: not supported
Versioning System for Ontology Management: not supported
SWOOP is no longer an active project. In the description of the tool it is claimed that
cooperative work is supported by virtue of its being is a Web ontology browser. However this
appears not now to be available in any form and development is discontinued.
6.20. Comparison of tools against the evaluation framework
The comments concerning this section are based on tools that have been described above and
are most often used in projects. In alphabetical order: Apollo, DOE, ICOM, KAON, KInfinity, LinkFactory, MediusVOM, OILEd, OntoEdit Free Version, Ontolingua, Protégé4,
RDFedt WebODE and WebOnto.
An important aspect when analyzing a tool is its tool architecture (Table 16). We have
included information about extensibility and storage of the ontologies (databases, ACII files,
etc.). From this perspective, most of the tools are moving towards extensible architectures.
Storage in databases is still a weak point of ontology tools, since just a few of them use
databases for storing ontologies: LinkFactory, Protégé4 and WebODE.
Interoperability (Table 17) with other ontology development tools, merging tools, information
systems and databases, as well as translations to and from some ontology languages, is
another important feature in order to integrate ontologies in applications. Most of the new
tools export and import to ad-hoc XML and other markup languages. However, there is not a
comparative study about the quality of all these translators. Moreover, there are no empirical
results about the possibility of exchanging ontologies between different tools and about the
loose of knowledge in the translation processes.
Before selecting a tool, it is also important to know which inference services are attached to it
(Table 18). This includes: built-in and other inference engines, consistency checking
mechanisms and exception handling, among others. LinkFactory has its own inference engine,
OILEd performs inferences using the FACT inference engine, Ontolingua uses ATP, Protégé4 uses PAL, WebODE uses Ciao Prolog and WebOnto uses the OCML inference engine.
Finally, none of the tools except RDFedt provide exception-handling mechanisms.
Related to the usability of tools (Table 19), WebOnto has the most advanced features related
to the cooperative and collaborative construction of ontologies. In general, more features are
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 131 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
required in existing tools to ensure the successful collaborative building of ontologies.
Finally, other usability aspects related to help system, edition & visualization, etc., should be
improved in most of the tools.
For the purposes of OASIS Project Protégé 4 is used as an authoring tool because it has
features that we identified as the more important to look for when selecting an ontology tool.
First of all it is widely used and open source. It has been used by experts in domains, for
domain modeling and for building knowledge-base systems, it is an intuitive editor, plug-ins
are available to carry out some of the tasks for building an ontology. Moreover, it supports
OWL and an OWL API is available, it exports ontologies into a variety of formats, it is based
on Java and includes a Programming Development Kit.
Although ontologies are constantly evolving very few of the investigated tools support the
evolution of the ontology. The collaborative process is partially supported by providing lockand-release mechanisms. Stand-alone tools as well as those providing a web interface do not
fully support the control of changes when developing ontologies; Protégé facilitates the
annotation of those segments that have changed; however, it does not provide a consistent
versioning system. The lack of relationship between ontology development tools and
methodologies makes it difficult to understand which stages of the development process these
tools are supporting. An interesting problem to be addressed is the management of the
evolution of the ontology as well as how to best supports the agreement process when
building conceptual models. Both these issues are not fully covered by the investigated tools.
For the formal foundations that will be developed further within OASIS, it is clear that strong
support for heterogeneous specifications will play a major role. The diverse areas of ontology
development identified in the use cases reported above, as well as the differing degrees of
expressiveness that are appropriate for distinct problems, all point in the direction of adopting
heterogeneity as a fundamental principle in OASIS’s future development. For this reason, and
as will be described in detail in D1.2.1, the formal foundation of the Common Ontological
Framework will be the combination of HETS and CASL. This guarantees that we are able to
cover all of the diversity required. With respect to the focus of the present deliverable, tools
and methodologies, this has several consequences. It will be necessary to relate tools that are
currently only directed towards ontologies of lesser expressivity (e.g., OWL) to range more
freely over the full set of possibilities offered by HETS and its further development as part of
the COF. The benchmarking undertaken here indicates clearly just which tools will be the
most suitable for this construction—in particular, Protégé in its web-based variants, and
BioPortal. Intermediary interfaces will be required for relating these OWL-based systems to
an extended range of logics; lessons learnt in the design of the NeOn tools will also be
included here. This is taken up in WP1.2 and reported upon in D1.2.1 and D1.2.2.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 132 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Feature
Apollo
DOE
Hets
ICOM
KAON
K-Infinity
LinkFactor
y
Medius
VOM
OILEd
OntoEdit
Ontolingua
Protégé 4
RDFedt
WebODE
WebOnto
Extensibility
Via plugins
No
Yes
Yes
No
No
Yes
Yes
No
Via plug-ins
No
Via plug-ins
No
Via plug-ins
No
Ontology Storage
Files
Files
Files
DBMS
?
DBMS
DBMS
?
Files
Files
Files
Files &
DBMS
Files
DBMS
Files
Table 16: Tools’ Architecture
Feature
Apollo
DOE
Hets
ICOM
KAON
K-Infinity
LinkFactor
y
Medius
VOM
OILEd
OntoEdit
Ontolingua
Protégé 4
RDFedt
WebODE
WebOnto
Import Format
OCML,
CLOS
OWL,
Manches
ter,
XML,
Syntax,
CASL,
TPTP,
DFG,
OMDoc
XML,
UML
RDF
(S)
RDF
XML, RDF
(S), DAML
+ OIL and
OWL
XML
Schema,
RDF and
DAML+
OIL
RDF (S),
OIL and
DAML
+ OIL
XML, RDF
(S), Flogic,
and DAML
+ OIL
IDL, KIF
XML, RDF
(S), XML
Schema and
OWL
RDF (S),
OIL,
DAML,
SHOE
RDF (S), UML,
DAML+OIL
and OWL
OCML
Export Format
OCML,
CLOS
OWL,
Manches
ter,
XML,
Syntax,
CASL,
TPTP,
DFG,
OMDoc
XML,
UML
RDF
(S)
RDF
XML, RDF
(S), DAML
+ OIL,
OWL and
html
XML
Schema,
RDF and
DAML+
OIL
RDF (S),
OIL and
DAML
+ OIL,
SHIQ,
dotty,
html
XML, RDF
(S), Flogic,
and DAML
+ OIL
KIF, CLIPS,
IDL,
OKBC,
syntax,
Prolog
syntax
XML, RDF
(S), XML
Schema,
Flogic,
CLIPS, Java,
html
RDF (S),
OIL,
DAML,
SHOE
RDF (S), UML,
DAML+OIL,
OWL, prolog,
X-CARIN,
Java/Jess
OCML,
GXL, RDF
(S), and
OIL
Merging
No
XSLT,
RDF
(S),
OIL,
DAML
+OIL,
OWL
and
CGXM
L
XSLT,
RDF
(S),
OIL,
DAML
+OIL,
OWL
and
CGXM
L
No
Yes
With
Inter
Ontolo
gy
mappi
ng
No
?
Yes
Limited
No
?
?
Via
ANCHORPROMPT
plug-in
?
Via ODEmerge
?
Table 17: Tools' interoperability
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 133 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Feature
Apollo
DOE
Hets
ICOM
KAON
K-Infinity
LinkFactory
Medius
VOM
OILEd
OntoEdit
Ontolingua
Protégé 4
RDFedt
WebODE
WebOnto
Inference Engine
No
Yes
Yes
Yes
Yes
Yes
Yes
With
FACT
No
No
With PAL
No
Prolog
Yes
Exception
Handling
No
No
Pellet,
Vampire,
SPASS,
Isabelle,
Darwin
?
No
No
?
No
?
No
No
No
No
Yes
No
No
Consistency
Checking
Yes
Via
type
inherita
nce and
detectio
n of
cycles
in
hierarch
ies
Yes
Via
FACT
Yes
Yes
Yes
With a
set of
ontology
authorin
g
wizards
Via
FACT
Yes
Via
Chimaera
Via plug ins
like FACT
and PAL
Only
checks
writing
mistakes
Yes
Yes
Table 18: Tools' inference services
Feature
Apollo
DOE
Hets
ICOM
KAON
K-Infinity
LinkFactory
Medius
VOM
OILEd
OntoEdit
Ontolingua
Protégé 4
RDFedt
WebODE
WebOnto
Collaboration
with other tools
No
No
No
No
?
Yes
Yes
Yes
No
No
Yes
No
No
Yes
Yes
Ontology Library
Yes
No
Yes
?
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
No
No
Yes
Visualization
No
No
Yes
Yes
No
With graph
editor
No
UML
diagram
s via
ROSE
No
Yes
No
Via plug-ins
like Graph
Viz and
jambalaya
No
Froma based
graphical user
interface
Yes
Table 19: Tools' usability
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 134 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Feature
P4
Bioportal
OilED
Apollo
RDFEdit
OntoLingua
OntoEdit
WebOde
KAON
Versioning
Not supported
Not fully
supported
Not supported
Not supported
Not supported
Not supported
Not supported
Not supported
Not supported
Collaboration
Supported by P3.4, and webbased Protégé
Not fully
supported
Not supported
Not supported
Not supported
Not fully
supported
Not supported
Not fully
supported
Not fully
supported
ICOM
DOE
WebOnto
OntoWiki
IsaViz
HOZO
GrOWL
SemanticWiki
Swoop
Versioning
Not supported
Not supported
Not supported
Not supported
Not supported
Not supported
Not supported
Not supported
Not supported
Collaboration
Not supported
Not supported
Not fully
supported
Not fully
supported
Not supported
Not fully
supported
Not supported
Not supported
Not fully
supported
Feature
Table 20: Overview of Tools' versioning and collaborative work support
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 135 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
7. Reasoners
A Description Logic (DL) system is characterized by four fundamental aspects: the set of
constructs used in concept and role expressions, the kind of assertions allowed in the TBox
(assertions on concepts) and the ABox (assertions on individuals), and the inference
mechanisms for reasoning on both the TBox and the ABox. This section presents a survey on
different kinds of existing reasoner implementations that can be used for reasoning ontologies.
Figure 55: Architecture of Description Logic
7.1. Description Logic Reasoners
The basic inferencing problems in description logics reasoning are
 Knowledge Base Consistency - A knowledge base is consistent if it has a model, i.e.
it can be interpreted in the model-theoretic sense. A knowledge base that contains a
contradiction does not have a model.
 Concept Satisfiability - A concept is satisfiable with respect to a knowledge base if
this knowledge base can be interpreted such that the extension of the concept is nonempty, i.e. the concept can potentially have an instance.
 Concept Subsumption - A concept A subsumes a concept B with respect to a
knowledge base if any instance of B is also an instance of A, no matter how the
knowledge base is interpreted.
 Concept Equivalence - A concept A is equivalent to a concept B with respect to a
knowledge base if A and B subsume each other.
 Concept Disjointness - Two concepts are disjoint with respect to a knowledge base if
they don't have a common instance, no matter how the knowledge base is interpreted.
All these inference tasks can be reduced to the main inference of checking a knowledge base
for consistency, which can be realized by checking the set of facts in the knowledge base for
unsatisfiability. Apart from KAON2, all state-of-the-art reasoners for DL implement the
tableau mechanism for performing this check. The basic idea of the tableau method is to
construct a model-theoretic interpretation for the set of facts to be checked according to the
constraints these facts impose on the individuals in this interpretation, which is either
successful or leads to a contradictory situation. If successful, the thus constructed
interpretation is a model for the set of facts in the knowledge base.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 136 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
To provide access to their reasoning functionality, the various available reasoners have
proprietary APIs that conform to their implementation language, or they support the DIG
interface, which is a standardized interface for handling DL elements in an XML format. The
following are the most famous DL reasoners:









CEL is a free (for non-commercial use) LISP-based reasoner for EL+. It implements a
refined version of a known polynomial-time classification algorithm and supports new
features like module extraction and axiom pinpointing. Currently, it accepts inputs in a
small extension of the KRSS syntax and supports the DIG-API.
Cerebra Engine is a commercial C++-based reasoner. It implements a tableau-based
decision procedure for general TBoxes (subsumption, satisfiability, classification) and
ABoxes (retrieval, tree-conjunctive query answering using a XQuery-like syntax). It
supports the OWL-API and comes with numerous other features.
FaCT++ is a free open-source C++-based reasoner for SHOIQ with simple datatypes
(i.e., for OWL-DL with qualifying cardinality restrictions). It implements a tableaubased decision procedure for general TBoxes (subsumption, satisfiability,
classification) and incomplete support of ABoxes (retrieval). It supports the lisp-API
and the DIG-API.
fuzzyDL is a free Java/C++ based reasoner for fuzzy SHIF with concrete fuzzy
concepts (explicit definition of fuzzy sets + modifiers). It implements a tableau +
Mixed Integer Linear Programming optimization decision procedure to compute the
maximal degree of subsumption and instance checking w.r.t. a general TBox and
Abox. It supports Zadeh semantics, Lukasiewicz semantics and is backward
compatible with classical description logic reasoning.
KAON2 is a free (free for non-commercial usage) Java reasoner for SHIQ extended
with the DL-safe fragment of SWRL. It implements a resolution-based decision
procedure for general TBoxes (subsumption, satisfiability, classification) and ABoxes
(retrieval, conjunctive query answering). It comes with its own, Java-based interface,
and supports the DIG-API.
MSPASS is a free open-source C reasoner for numerous description logics. It
implements a resolution-based decision procedure for extensions of ALB (which is
ALC with inverse and Boolean operators on roles) with general TBoxes (satisfiability,
subsumption) and ABoxes (instance checking, retrieval). It is an extension of the
theorem prover SPASS, and can thus also be used to reason about arbitrary first-order
statements.
Pellet is a free open-source Java-based reasoner for SROIQ with simple datatypes
(i.e., for OWL 1.1). It implements a tableau-based decision procedure for general
TBoxes (subsumption, satisfiability, classification) and ABoxes (retrieval, conjunctive
query answering). It supports the OWL-API, the DIG-API, and Jena interface and
comes with numerous other features.
QuOnto is a free (for non-commercial use) Java-based reasoner for DL-lite with
GCIs. It implements a query rewriting algorithm for both consistency checking and
query answering for unions of conjunctive queries over DL-Lite knowledge bases,
whose ABox is managed through relational database technology. It comes with its
own Java-based interface.
RacerPro is a commercial (free trials and research licenses are available) lisp-based
reasoner for SHIQ with simple datatypes (i.e., for OWL-DL with qualified number
restrictions, but without nominals). It implements a tableau-based decision procedure
for general TBoxes (subsumption, satisfiability, classification) and ABoxes (retrieval,
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 137 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754


nRQL query answering). It supports the OWL-API and the DIG-API and comes with
numerous other features.
Hoolet is an implementation of an OWL-DL reasoner that uses a first order prover.
The ontology is translated to collection of axioms (in an obvious way based on the
OWL semantics) and this collection of axioms is then given to a first order prover for
consistency checking. Hoolet is implemented using the WonderWeb OWL API for
parsing and processing OWL, and the Vampire prover for reasoning purposes. Other
reasoners could also be used — communication with the reasoner is via the TPTP
format which is understood by a number of theorem provers.
KRHyper is an automated deduction system for first-order Horn clause logic with
default negation (i.e. 'normal logic programs'). Unlike most other systems, KRHyper
'computes at the first-order level', i.e. no grounding of the program is carried out,
neither 'statically' before the program is run nor 'dynamically' during the run of the
system. KRHyper works "botton-up" and is feasible for model computation.
Below, we introduce a detailed overview for most famous reasoners.
7.1.1. FaCT++
The FaCT++ system is the predecessor of the former FaCT [1], which has mainly been used
for T-Box classification tasks in description logic reasoning. In its new ver- sion, it has
recently been updated to support A-Box reasoning and also nominals. It provides an
optimized tableaux reasoner for the description logic SHOIQ(D), includ- ing support of
restrictions on Integer and String data types. It offers basic reasoning tasks on T-Boxes, such
as ontology consistency, concept satisfiability and concept subsumption, and also A-Box
retrieval tasks. The system is implemented in the C++ programming language to provide an
efficient software tool.
FaCT++ can be used for the following tasks:




Checking the consistency of an ontology;
Checking the satisfiability of a single concept / group of concepts;
Checking the subsumption relationship between two concepts;
Classifying the whole ontology (creating a taxonomy);
FaCT++ provides full reasoning support for the SHIF(D) Description Logic. In addition, it
has some extra features:
First-order logic interface
FaCT++ can create FOL problems for subsumption and satisfiability checking in the SHOIQ
logic using a standard syntax (TPTP) that can be read by most first order theorem provers. See
[2] for a comparison of the performance of the FaCT++ reasoner with a state of the art first
order theorem prover running on TPTP problems created using FaCT++.
Limited individual support
FaCT++ currently has limited support for individuals. All individuals are treated as concepts,
and reasoning is performed on the modified ontology. This approach results in no loss of
inferences if the ontology contains no relations between individuals, a restriction that holds
for many of useful ontologies. Even in case where relations between individuals are present, it
is sometimes possible to get a correct answer to satisfiability and/or subsumption query. In
this case, FaCT++ gives answer together with correctness information.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 138 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Role domain and range absorption
If the reasoning tool has no support of range and domain constructions (as in FaCT), it must
treat them as general axioms of a kind which are not absorbable. This slows the reasoning
process significantly. In FaCT++, native support of these constructions was implemented, and
this results in speedups of as much as two orders of magnitude for some ontologies. Besides
that, new absorbtion methodic based on domain and range constructions was implemented,
which leads to more efficient reasoning on several tasks.
7.1.2. RacerPro
RacerPro stands for Renamed ABox and Concept Expression Reasoner Professional. As the
name suggests, the origins of RacerPro are within the area of description logics. Since
description logics provide the foundation of international approaches to standardize ontology
languages in the context of the so-called semantic web, RacerPro can also be used as a system
for managing semantic web ontologies based on OWL (e.g., it can be used as a reasoning
engine for ontology editors such as Prot_eg_e). However, RacerPro can also be seen as a
semantic web information repository with optimized retrieval engine because it can handle
large sets of data descriptions (e.g., defined using RDF).
RacerPro as a Semantic Web Reasoning System and Information Repository
The semantic web is aimed at providing “machine-understandable” web resources or by
augmenting existing resources with “machine-understandable” metadata. An important aspect
of future systems exploiting these resources is the ability to process OWL (Web Ontology
Language) documents (OWL KBs), which is the official semantic web ontology language.
Ontologies may be taken of the shelf or may be extended for domain-specific purposes
(domain-specific ontologies extend core ontologies). For doing this, a reasoning system is
required as part of the ontology editing system. RacerPro can process OWL Lite as well as
OWL DL documents (knowledge bases). Some restrictions apply, however. OWL DL
documents are processed with approximations for nominals in class expressions and userdefined XML datatypes are not yet supported.
The following services are provided for OWL ontologies and RDF data descriptions:
 Check the consistency of an OWL ontology and a set of data descriptions.
 Find implicit subclass relationships induced by the declaration in the ontology.
 Find synonyms for resources (either classes or instance names).
 Since extensional information from OWL documents (OWL instances and their
interrelationships) needs to be queried for client applications, an OWL-QL query
processing system is available as an open-source project for RacerPro.
 HTTP client for retrieving imported resources from the web. Multiple resources can
be imported into one ontology.
 Incremental query answering for information retrieval tasks (retrieve the next n
results of a query). In addition, RacerPro supports the adaptive use of computational
resource: Answers which require few computational resources are delivered first, and
user applications can decide whether computing all answers is worth the effort.
RacerPro as a Description Logic System
RacerPro is a knowledge representation system that implements a highly optimized tableau
calculus for very expressive description logic. It offers reasoning services for multiple Tboxes and for multiple A-boxes as well. The system implements the description logic
ALCQHIR+ also known as SHIQ (see [3]). This is the basic logic ALC augmented with
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 139 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
qualifying number restrictions, role hierarchies, inverse roles, and transitive roles. In addition
to these basic features, RacerPro also provides facilities for algebraic reasoning including
concrete domains for dealing with:



min/max restrictions over the integers,
linear polynomial (in-)equations over the reals or cardinals with order relations,
equalities and inequalities of strings.
RacerPro supports the specification of general terminological axioms. A T-box may contain
general concept inclusions (GCIs), which state the subsumption relation between two concept
terms. Multiple definitions or even cyclic definitions of concepts can be handled by RacerPro.
RacerPro implements the HTTP-based quasi-standard DIG for interconnecting DL systems
with interfaces and applications using an XML based protocol [4]. RacerPro also implements
most of the functions speci_ed in the older Knowledge Representation System Speci_cation
(KRSS), for details see.
Given a T-box, various kinds of queries can be answered. Based on the logical semantics of
the representation language, different kinds of queries are defined as inference problems
(hence, answering a query is called providing inference service). As a summary, we list only
the most important ones here:




Concept consistency w.r.t. a T-box: Is the set of objects described by a concept empty?
Concept subsumption w.r.t. a T-box: Is there a subset relationship between the set of
objects described by two concepts?
Find all inconsistent concept names mentioned in a T-box. Inconsistent concept names
result from T-box axioms, and it is very likely that they are the result of modelling
errors.
Determine the parents and children of a concept w.r.t. a T-box: The parents of a
concept are the most speci_c concept names mentioned in a T-box which subsume the
concept. The children of a concept are the most general concept names mentioned in a
T-box that the concept subsumes. Considering all concept names in a T-box the parent
(or children) relation de_nes a graph structure which is often referred to as taxonomy.
Note that some authors use the name taxonomy as a synonym for ontology.
Note that whenever a concept is needed as an argument for a query, not only predefined
names are possible, instead concept expressions allow for adaptive formulation of queries that
have not been anticipated at system construction time.
If also an A-box is given, among others, the following types of queries are possible:
 Check the consistency of an A-box w.r.t. a T-box: Are the restrictions given in an Abox w.r.t. a T-box too strong, i.e., do they contradict each other? Other queries are
only possible w.r.t. consistent A-boxes.
 Instance testing w.r.t. an A-box and a T-box: Is the object for which an individual
stands a member of the set of objects described by a speci_ed concept? The individual
is then called an instance of the concept.
 Instance retrieval w.r.t. an A-box and a T-box: Find all individuals from an A-box
such that the objects they stand for can be proven to be a member of a set of objects
described by a certain query concept.
 Retrieval of tuples of individuals (instances) that satisfy certain conditions w.r.t. an
A-box and a T-box.
 Computation of the direct types of an individual w.r.t. an A-box and a T-box: Find the
most speci_c concept names from a T-box of which a given individual is an instance.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 140 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754


Computation of the _llers of a role with reference to an individual w.r.t. an A-box and
a T-box.
Check if certain concrete domain constraints are entailed by an A-box and a T-box.
RacerPro provides another semantically well-defined query language (nRQL, new Racer
Query Language), which also supports negation as failure, numeric constraints w.r.t. attribute
values of different individuals, substring properties between string attributes, etc. In order to
support special OWL features such as annotation and datatype properties, special OWL
querying facilities have been incorporated into nRQL. The query language OWL-QL [4] is
the W3C recommendation for querying OWL documents. nRQL has been used as a basic
engine for implementing a very large subset of the OWL-QL query language.
RacerPro as a combination of Description Logic and SpecificRrelational Algebras
For some representation purposes, e.g., reasoning about spatial relations such as contains,
touching, etc., relational algebras and constraint propagation have proven to be useful in
practice. RacerPro combines description logics reasoning with, for instance, reasoning about
spatial (or temporal) relations within the A-box query language nRQL. Bindings for query
variables that are determined by A-box reasoning can be further tested with respect to an
associated constraint network of spatial (or temporal) relationships.
Although RacerPro is one of the first systems supporting this kind of reasoning in
combination with description logics (or OWL), we expect that international standardization
efforts will also cover these important representation constructs in the near future. Note also
that the semantically well-founded treatment can hardly be efficiently achieved using rule
systems.
7.1.3. Pellet
Pellet is an open-source Java based OWL DL reasoner. It can be used in conjunction with
both Jena and OWL API libraries and also provides a DIG interface. Pellet is an OWL DL
reasoner based on the tableaux algorithms developed for expressive Description Logics.
It supports the full expressivity OWL DL including reasoning about nominals (enumerated
classes). Therefore, OWL constructs owl:oneOf and owl:hasValue can be used freely.
Currently, Pellet is the first and only sound and complete DL reasoner that can handle this
expressivity. Pellet ensures soundness and completeness by incorporating the recently
developed decision procedure for SHOIQ (the expressivity of OWL-DL plus qualified
cardinality restrictions in DL terminology). Pellet has a number of features either driven by
OWL requirements or Semantic Web issues. These are described in what follows.
Ontology analysis and repair
OWL has two major dialects, OWL DL and OWL Full, with OWL DL being a subset of
OWL Full. All OWL knowledge bases are encoded as RDF/XML graphs. OWL DL imposes
a number of restrictions on RDF graphs, some of which are substantial (e.g., that the set of
class names and individual names be disjoint) and some less so (that every item have a
rdf:type triple). Ensuring that an RDF/XML document meets all the restrictions is a relatively
difficult task for authors, and many existing OWL documents are nominally OWL Full, even
though their authors intend for them to be OWL DL. Pellet incorporates a number of
heuristics to detect "DLizable" OWL Full documents "repair" them.
Species Validation
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 141 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Species Validation is a write-up by one of the Pellet programmers that explains how we
process an OWL file for species validation.
Entailment
In Semantic Web, entailment is the key inference whereas the Description Logic community
have focused on satisfiability and subsumption. While entailment can be reduced to
satisfiability, most DL systems do not support it. In part to pass a large portion of the OWL
test suite, we implemented entailment support in Pellet.
Conjunctive ABox query
Query answering is yet another important feature for Semantic Web. We have implemented
an ABox query answering module in Pellet using "rolling-up'' technique. We have devised
algorithms to optimize the query answering by changing how likely candidates for variables
are found and tried. Exploiting the dependencies between different variable bindings helps us
to reduce the total number of satisfiability tests thus speeding up the answer significantly.
Datatype Reasoning
XML Schema has a rich set of basic datatypes including various numeric types (integers and
floats), strings, and date/time types. It also has several mechanism, both standard and unusual
for creating new types out of the base types. For example, it's possible to define a datatype by
restricting the integers to the set of integers whose canonical representation has only 10 digits,
or whose string representation matches a certain regular expression. Currently, XML Schema
systems tend toward validation of documents and generation of PSVI instead of type checking
(though, with the advent of XQuery, this might change). Pellet can test the satisfiability of
conjunctions of thus constructed datatypes.
User-defined Simple Datatypes
The main problem of having user-defined datatypes is how to define URI's for XML Schema
definitions. This document from SWBPD working group at W3C discusses the problem and
several different solutions in detail. In Pellet, we adopt the DAML+OIL solution which says a
datatype URI is constructed from the URI of the XML schema document and the local name
of the simple type. We parse the XML schema document from the given URI and locate the
type using name attribute of the definitions. See as an example ontology that refers to the
datatype descriptions in the XML schema document located here.
Multi-Ontology Reasoning using E-Connections
An E-Connection is a knowledge representation language defined as a combination of other
logical formalisms. We use E-Connections as a language for defining and instantiating
combinations of OWL-DL ontologies, i.e. as a way of combining KBs, rather than logics.
This approach provide an alternative to owl:imports will always bring all the axioms from the
imported ontology, lets us to identify sub-parts of an ontology and gives a well-founded
logical framework for reasoning with multiple ontologies. See this page for more information
about E-Connections and example ontologies. Pellet provides support for reasoning with Econnected ontologies through both Jena and OWL-API interfaces.
Ontology Debugging
Detection of unsatisfiable concepts in an ontology is a straright-forward task. However, the
diagnosis and resolution of the bug is generally not supported at all. For example, no
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 142 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
explanation is given as to why the error occurs (e.g., by pinpointing the root clash, or axioms
in the ontology responsible for the clash) or how dependencies between classes cause the
error to propagate (i.e., by distinguishing root from derived unsatisfiable classes). Pellet,
provides support for both kinds of tasks by pinpointing axioms that cause an inconsistency
and the relation between unsatisfiable concepts. Currently, these features are provided in a
separate development branch but there is a version of Swoop that integrates the explanationgenerating version of Pellet to allow users debug ontologies.
Pellet Architecture
The core of the Pellet reasoner is the tableaux reasoner that checks the consistency of a KB,
i.e. a pair of an ABox and a TBox. The reasoner is coupled with a datatype oracle that can
check the consistency of conjunctions of (built-in or dervied) XML Schema simple datatypes.
The OWL ontologies are loaded to the reasoner after a step of species validation and ontology
repair. This step ensures that all the resources have an appropriate type triple (a requirement
for OWL DL but not OWL Full) and missing type declarations are added using some
heuristics (see Section \ref{repair} for details). During the loading phase, axioms about
classes (subclass, equivalent class or disjointness axioms) are put into the TBox component
and assertions about individuals (type and property assertions) are stored in the ABox
component. TBox axioms go through the standard preprocessing of DL reasoners before they
are fed to the tableaux reasoner.
Figure 56: Pellet architecture
Essentially, a tableau reasoner has only one functionality which is, checking the satisfiability
of an ABox with respect to a TBox. All the other reasoning tasks can be reduced to KB
consistency test with an appropriate transformation. The System Programming Interface (SPI)
of Pellet provides generic functions to manage such transformations. This KnowledgeBase
interface, as the rest of internal components, is based on the ATerm library. ATerm (short for
Annotated Term) is an abstract data type designed for the exchange of tree-like data structures
between distributed applications. The ATerm library provides maximal subterm sharing and
automatic garbage collection making it very suitable for representing OWL class expressions.
The term sharing feature reduces the overall memory consumption spent for storing concept
expressions and makes it is easy to transform the data from Pellet SPI to external API's.
This KnowledgeBase interface is not supposed to be used by programmers. For convenience,
there are two different interfaces to support Jena and OWL-API applications. There is also a
DIGServer so that Pellet can be used with DIG applications, e.g. as an external reasoner for
Protege.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 143 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
7.1.4. KAON2
KAON2 is an infrastructure for managing OWL-DL, SWRL, and F-Logic ontologies [5]. The
ontology management system currently consists of the following modules:
– An API for programmatic management of OWL-DL, SWRL, and F-Logic ontologies,
– A stand-alone server providing access to ontologies in a distributed manner using
RMI,
– An inference engine for answering conjunctive queries (expressed using SPARQL
syntax),
– A DIG interface, allowing access from tools such as Protégé,
– A module for extracting ontology instances from relational databases.
KAON2 supports answering conjunctive queries, albeit without true non-distinguished
variables [6]. This means that all variables in a query are bound to individuals explicitly
occurring in the knowledge base, even if they are not returned as part of the query answer.
The algorithms for answering queries with non-distinguished variables have been developed,
but have not been implemented yet.
Figure 57: Kaon2 architecture
Figure 57 describes the technical architecture of KAON2. The Ontology API provides
ontology manipulation services, such as adding and retrieving axioms. The API fully supports
OWL and the Semantic Web Rule Language (SWRL) at the syntactic level. Several similar
APIs already exist, such as the OWL API or Jena. Ontologies can be saved in files, using
either OWL RDF or OWL XML syntax. Alternatively, ABox assertions can be stored in a
relational database (RDBMS): by mapping ontology entities to database tables, KAON2 will
query the database on the fly during reasoning.
The Reasoning API allows one to invoke various reasoning tasks, and to retrieve their results.
All APIs can be invoked either locally, using KAON2 as a dynamic library, or remotely, for
example, through the DL Implementors Group (DIG) interface.
The central component of KAON2 is the Reasoning Engine, which is based on the algorithm
for reducing a SHIQ knowledge base KB to a disjunctive datalog program DD (KB) [29]. To
understand the intuition behind this algorithm, considering the knowledge base KB
= {C  R.E1, E1  E2, R.E2  D} . For an individual x in C, the first axiom implies
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 144 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
existence of an R-successor y in E1. By the second axiom, y is also in E2. Hence, x has an Rsuccessor y in E2, so, by the third axiom, x is in D. The program DD (KB) contains the rules
E2(x) ← E1(x) and D(x) ← R(x, y), E2(x), corresponding to the second and the third axiom,
respectively. However, the first axiom of KB is not represented in DD (KB); instead, DD
(KB) contains the rule D(x) ← C(x). The latter rule can be seen as a “macro”: it combines into
one step the effects of all mentioned inference steps, without expanding the R-successors
explicitly. Computing all relevant “macro” rules is performed by saturating the TBox of KB
using basic superposition (BS) [30], [31](a clausal refutation calculus), which is implemented
in the Theorem Prover subcomponent of the Reasoning Engine.
The Ontology Classification subcomponent of the Reasoning Engine is responsible for
translating the TBox of a SHIQ knowledge base KB into a set of first-order clauses. It is very
important to reduce the number of clauses produced in the translation.
The Disjunctive Datalog Engine subcomponent of the Reasoning Engine is used for
answering queries in the disjunctive datalog program obtained by the reduction.
7.1.5. CEL
CEL [7] is the first reasoner for the description logic EL+, supporting as its main reasoning
task the computation of the subsumption hierarchy induced by EL+ ontologies. The most
distinguishing feature of CEL is that, unlike other modern DL reasoners, it implements a
polynomial-time algorithm. The supported description logic EL+ offers a selected set of
expressive means that are tailored towards the formulation of medical and biological
ontologies.
7.1.6. Cerebra Engine
Cerebra, by Cerebra Inc. (formerly Network Inference) is a recent commercial system,
providing reasoning as well as ontology management features. Cerebra differs from
traditional DL based systems, in that it provides some extra features that may be desirable in a
production environment. Nevertheless, its expressive power is by no means exceedingly
different.
Indeed, one interesting feature of Cerebra is the ability to add persistency to the knowledge
bases that is able to process. Cerebra can load OWL documents either from the local file
system or directly from the Web, provided the corresponding URL. The ontology information
is stored, following an internal data model, in a relational database and can then be reloaded if
needed.
Cerebra provides for connecting with client applications written in Java or .NET. Further, any
web service may use its functionality through its SOAP interface. Clients written in Java can
connect to the system either through RMI or SOAP, by using the classes provided by Cerebra
for this purpose. For .NET, Cerebra provides a .dll library which can be used to connect with
the SOAP interface. In both cases there is an API that provides for processing, managing and
posing queries to ontologies. Query composition, especially when involving instances,
follows to some extent the XQuery standard.
7.1.7. FuzzyDL
FuzzyDL is a Description Logic Reasoner supporting Fuzzy Logic reasoning. The FuzzyDL
system includes a reasoner for fuzzy SHIF with concrete fuzzy concepts (ALC augmented
with transitive roles, a role hierarchy, inverse roles, functional roles, and explicit definition of
fuzzy sets).
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 145 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
7.1.8. QuOnto
The QuOnto System [8] was developed to implement efficient reasoning algorithms over
Knowledge Bases with large amount of instances. It is based on a particular Description
Logic, called DL-Lite [9].
It represents a good trade-off between expressive power and computational complexity of
sound and complete reasoning, in particular, it is tailored to capture basic ontology languages
and allows to answer to complex queries expressed on ontologies in LOG-SPACE compared
to the data complexity (the data size) [10]. This system doesn't feature yet a user interface nor
managing tools and it uses a particular XML syntax to write the ontology, this makes it not
easy-to-use. Protégé is an open-source ontology editor based on Java that has a plug-in
architecture which makes it flexible and easy to be extended. In addition it can read and write
ontologies in OWL format, that is the standard language proposed by W3C. This features
have driven the idea to use it as a framework to manage some element of the QuOnto System.
7.2. Description Logic Reasoners which are no longer actively supported
7.2.1. Classic
Classic is a family of knowledge representation (KR) systems designed for applications where
only limited expressive power is necessary, but rapid responses to questions are essential. The
Classic systems are based on description logics (DLs), which gives them an object-centered
flavor, and thus most of the features available in semantic networks are also available in
Classic. Classic has a framework that allows users to represent descriptions, concepts, roles,
individuals and rules. Classic allows for both primitive concepts, similar to the classes and
frames of other knowledge representation systems and object-oriented programming
languages, and defined concepts, i.e. concepts that have both necessary and sufficient
conditions for membership. Concepts are automatically organized into a generalization
taxonomy and objects are automatically made instances of all concepts for which they pass
the membership test. Another type of reasoning that Classic does is to detect inconsistencies
in information that it is told. In the presence of defined concepts these operations are nontrivial and useful.
7.2.2. Loom
Loom’s architecture achieves a tight integration between rule-based and frame- based
paradigms, by providing the capability to use terminological reasoning within the pattern
matching and control components of a rule processing system architecture. By terminological
reasoning , we mean the ability to represent knowledge about the defining characteristics of
concepts, and to use that knowledge to automatically infer and maintain a complete and
accurate taxonomic lattice of logical subsumption relations between concepts.
7.3. Rule Engines
7.3.1. Jess
Jess (Java Expert System Shell),originally inspired by the CLIPS expert system shell and the
CLIPS language (C Language Integrated Production System) is a productive development and
delivery expert system tool. It provides a complete environment for the construction of rule
and/or object based expert systems. Like CLIPS, Jess uses the Rete (Latin for “net”)
algorithm to process rules, whose main idea is to improve the speed of forward-chained rule
systems by limiting the effort required to recompute the conflict set after a rule is fired.
However, Jess also adds many features to CLIPS, including backwards chaining, working
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 146 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
memory queries, and the ability to manipulate and directly reason about Java objects. In short,
Jess has grown into a complete, distinct, dynamic environment of its own, with powerful Java
scripting capabilities.
7.3.2. XSB
XSB is a Logic Programming and Deductive Database system, and it extends Prolog with
new semantic and operational features, mostly based on the use of Tabled Logic
Programming or tabling. Consequently, it was also named after Tabled Prolog. XSB can be
used as a Prolog system since it provides all the functionality of Prolog. Further on XSB is
based on tableaux calculus, which provides termination to various classes of programs
including definite programs(also called Horn Clause Programs) and normal programs.
Besides, both backtrackable and non-backtrackable updates to asserted code are included in
XSB.
7.3.3. CWM
Cwm is a general-purpose data processor for the SemanticWeb, which is part of SWAP
(Semantic Web Application Platform). Cwm is a forward chaining reasoner which can be
used for querying, checking, transforming and filtering information. Its core language is RDF,
extended to include rules. It uses RDF/XML or RDF/N3 serializations as required. We note
that Cwm was designed as a proof of concept for the standard Semantic Web layered
architecture. Therefore the implementation of the reasoner does not particularly focus on
scalability or performance issues for large data sets or rule sets as in real-world applications.
7.3.4. RuleML Engine
Mandarax was implemented as the first complete input-processing-output environment for
RuleML. In Mandarax, rule bases can be made persistent using the XKB module which stored
rules and other knowledge in a format similar to RuleML, and export and import of RuleML
rule bases are also supported. Being pure OO, Mandarax is an open source java class library
for deduction rules, and it is based on backward reasoning. jDREW7 also provides modules to
process rules in RuleML format, and it is an deductive reasoning engine for clausal first order
logic (facts and rules) written in Java and well integrated with the Web. Besides, XSLT
translators can directly transform the RuleML rulebases into the representation for a specified
target engine such as XSB, Jess and Cwm.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 147 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
8. Conclusions
We have surveyed the state of the art in ontologies relevant for OASIS concerns and have
highlighted both the strengths and weaknesses of that state. In general there are many
ontologies that can be employed, but they will all require considerable formal improvement
and modularisation in order to maximise their benefits to applications, their support of the
needs of the elderly, and their degree of re-use. In addition, we have identified gaps where
new ontologies will need to be created for particular applications required by the OASIS
scenarios.
For this development, effective tools are a central requirement. Fortunately, software tools are
already available to achieve most of the required activities of ontology development allowing
us to focus specifically on the innovate requirements of ontology development within the
OASIS model. Projects often involve solutions using numerous ontologies from external
sources. Sometimes there is also the need to use existing and newly developed in-house
ontologies. For this reason it is important that the editing tools for ontology construction
promote interoperability. As we have seen above, Protégé is the most common tool now used
for domain modelling and for building knowledge-base systems. Protégé provides an intuitive
editor for ontologies and has extensions for ontology visualization, project management,
software engineering and other modelling tasks. It also provides interfaces for Description
Logic Reasoners such as Racer. Protégé ontologies can be exported into a variety of formats
including RDF(S), OWL, and XML Schema. It is a tool installed locally in a computer and
does not allow collaborative editing of ontologies by groups of users and there is a large
number of diverse plug-ins available. Functionalities formerly provided by individual tools
are now more commonly becoming available as Protégé plug-ins. OASIS will accordingly
make more extensive use of this capability than originally thought. This will enable the
project to secure a user base more effectively: most ontology development will continue to be
performed with Protégé, but via plug-ins users will be led to the more sophisticated
capabilities of the OASIS platform and other OASIS-solutions.
However, in addition to this, for the management and document processes of more effective
methodologies for ontology development, Wikis will also play an increasingly major role. All
the tasks, activities, milestones, etc. described in the development process need to be managed
with respect to time and person resources: who has to do what and when? In a collaborative
setting a Wiki has proved to be the most flexible tool to accomplish this task. However, the
trade off of a Wiki's flexibility is the danger to evolve in an unsystematic way: in particular
recurring tasks should be structured always in the same way. For instance different ontology
developer teams for different domains of to go through same development process so the
corresponding Wiki pages for task and role definitions, scheduling, etc. should be structured
equally. Traditional Wikis do not support such kind of template mechanism well. Semantic
Wikis (e.g. Semantic MediaWiki) overcome this problem with semantic forms and templates.
Moreover, they allow developers to have different views on content via semantic search.
Therefore, particularly in WP1.2 and WP1.3, support for the OASIS hyper-ontology and COF
will also focus on making available Wiki-based solutions as a complete package along with
Protégé plug-ins. The use of web-based Protégé will also be considered as part of this line of
development. OASIS-members have already established contact with the leading stakeholders
in the Protégé development process in order to facilitate close cooperation and compatibility
in the solutions pursued.
Apart from management documentation of the ontology development process is the other
important part that can be supported by (semantic) Wiki. Some languages, e.g. OWL, provide
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 148 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
a rich annotation mechanism to add meta-information to the ontology. However, this
information concerns initially the ontology as it is, but not how it evolved to its current status.
The history of ontology development needs to documented as well in order to understand why
an ontology is as it is. This covers the documentation of use cases, competency questions,
reviews, comparison to related ontologies, etc. Practical experience will show what kind of
documentation should be directly presented in the Wiki and what should be only uploaded to
the Wiki together with some abstract. Within OASIS, the use and development of Wiki-like
environments is the topic of Deliverable ID1.2.2. At the present stage of development of the
project, a Wiki is already being used to record ontology development progress and to relate
development to stages in the methodology for ontology development. This will be extended
during the second year of the project and reported on in ID1.2.2.
To conclude, there are open source ontology tools (Protégé), there are ontology tools that
demand learning/knowing a specific language (Ontolingua and OilEd) and there are ontology
tools that are more graphic (IsaViz). Other tools are Web-based application (WebODE and
SWOOP) or follow a methodology (DOE and WebODE). Some tools only support common
edition and browsing functionalities. Other tools provide ontology documentation, ontology
import/export for different formats, graphical view of ontologies, ontology libraries and
attached inference engines. In this deliverable, we compared a selection of some of the
available ontology tools and environments that can be used for ontology construction, either
from scratch or by reusing other existing ontologies. For the purposes of the OASIS Project
Protégé 4 is selected for use as an authoring tool because it has features that we identified as
the most important to look for when selecting an ontology tool. First of all it is widely used
and open source. It has been used by experts in domains, for domain modeling and for
building knowledge-base systems, it is an intuitive editor, plug-ins are available to carry out
some of the tasks for building an ontology. Moreover, it supports OWL and an OWL API is
available, it exports ontologies into a variety of formats, it is based on Java and includes a
Programming Development Kit.
This deliverable has also gone into considerable detail concerning the methodologies that are
currently available for guiding ontology design. This input will be drawn on when designing
the COF-management tools within WP1.2 and in pursuing the practical work of developing
and guiding ontologies with SP2 and SP3 for their required OASIS applications. The
inclusion of methodological steps within the information presented in documentation and the
OASIS Wikis will also be a major contribution. Methodological considerations have been
made concerning both the global lifecycle of ontologies and the internal formal metrics that
can be applied for ensuring ontology quality.
Finally, for the underlying formal foundations of the future work within OASIS, we identified
CASL and HETS as a robust and well-developed basis for being able to deal with the
diversity of ontological information required as well as the strong structuring and modularity
that will be required. Both of these aspects mark a significant point of departure for future
ontology work that extends beyond the current state of the art, in which ontology
development is typically limited to less expressive formalisms and for which structuring
mechanisms are extremely limited. A challenge for the next phase of development of the
project will be to bring these advanced capabilities together with the best of the available tools
for distributed ontology development and visualisation. This combination is itself expected to
advance ontology development practice significantly.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 149 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
I. Horrocks. Using an Expressive Description Logic: FaCT or Fiction? In A. G.Cohn, L.
Schubert, and S. C. Shapiro, editors, Proc. of the 6th Int. Conf. on the Principles of
Knowledge Representation and Reasoning (KR '98), pages 636-647, Trento, Italy, June
2-5 1998. Morgan Kaufmann Publishers.
Dmitry Tsarkov and Ian Horrocks. DL reasoner vs. first-order prover. In Proc. Of the
2003 Description Logic Workshop (DL 2003), volume 81, pages 152–159. CEUR
(http://ceur-ws.org/), 2003.
I. Horrocks, U. Sattler, and S. Tobies. Reasoning with individuals for the description logic shiq.
In David MacAllester, editor, Proceedings of the 17th International Conference on Automated
Deduction (CADE-17), number 1831 in Lecture Notes in Computer Science, pages 482{496,
Germany, 2000. Springer Verlag.
S. Bechhofer, P. Crowther, and R. M•oller. The description logic interface. In D. Calvanese, G.
De Giacomo, and E. Franconi, editors, International Workshop on Description Logics, pages
196{203, September 2003.
KAON2 infrastructure for managing OWL-DL, SWRL and F-Logic Ontologies
http://kaon2.semanticweb.org/
B. Motik and U. Sattler. A Comparison of Reasoning Techniques for Querying Large
Description Logic ABoxes. Proc. of the 13th International Conference on Logic for
Programming Artificial Intelligence and Reasoning (LPAR 2006), Phnom Penh,
Cambodia, November, 2006
CEL A polynomial-time Classifier for the description logic EL+ http://lat.inf.tudresden.de/systems/cel/
D.Calvanese, G.De Giacomo, D.Lembo, M.Lenzerini and R.Rosati. Tailoring OWL for
Data Intensive Ontologies. In Proc. of the Workshop on OWL: Experiences and
Directions (OWLED 2005), 2005
A.Acciarri, D.Calvanese, G.De Giacomo, D.Lembo, M.Lenzerini, M.Palmieri and
R.Rosati. QuOnto: Querying ontologies. In Proc. of the 20th Nat. Conf. on Artificial
Intelligence (AAAI 2005), 2005.
D.Calvanese, G.De Giacomo, D.Lembo, M.Lenzerini and R.Rosati. DL-Lite: Tractable
Description Logics for Ontologies. In Proc. of the 20th Nat. Conf. on Artificial
Intelligence (AAAI 2005), 2005
M. Genesereth, R. Fikes, “Knowledge interchange format”, Technical Report Logic-921, Computer Science Department, Stanford University, 1992
T. Gruber, « A translation approach to portable ontologies », Knowledge Acquisition
5(2), Academic Press (1993), pp 199-220
R. MacGregor, “Inside the LOOM clasifier”, SIGART bulletin 2, 1991, pages 70–76
Motta E. Reusable Components for Knowledge Modelling. IOS Press, Amsterdam, The
Netherlands. ISBN: 1 58603 003 5, 1999
M. Kifer, G. Lausen, J. Wu, “Logical foundations of object-oriented and frame-based
languages”, Journal of the ACM 42, 1995, pages 741–843
S. Decker, M. Erdmann, D. Fensel, R. Studer, Ontobroker “Ontology based access to
distributed and semi-structured information”, Semantic Issues in Multimedia Systems
(DS8), Kluwer Academic Publisher, Boston,1999, pages 351–369
S. Luke, J. Heflin “SHOE 1.01. proposed specification”, SHOE Project technical report,
University of Maryland,2000
I. Horrocks, D. Fensel, F. Harmelen, S. Decker, M. Erdmann, M. Klein “OIL in a
Nutshell”, ECAI00 Workshop on Application of Ontologies and PSMs, Berlin, 2000
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 150 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
[19] http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
[20] http://www.w3.org/TR/1999/PR-rdf-schema-19990303/
[21] E. Miller. An Introduction to the Resource Description framework, D-Lib Magazine,
May 1998, (also available at http://www.dlib.org/dlib/may98/miller/05miller.html)
[22] Namespaces in XML,http://www.w3.org/TR/REC-xml-names/
[23] Dublin Core: The Metadata Element Set, http://dublincore.org, 1998.
[24] S. Decker, S. Melnik, F. Van Harmelen, D. Fensel, M. Klein, J. Broekstra,M. Erdmann,
I. Horrocks. The Semantic Web: The Roles of XML and RDF, IEEE Internet
Computing, 2000, 4(5): 63-74
[25] OWL Web Ontology Language Reference, http://www.w3.org/TR/2003/PR-owl-ref20031215/
[26] OWL Web Ontology Language Reference, http://www.w3.org/TR/2004/REC-owl-ref20040210/
[27] http://www.w3.org/TR/2004/REC-owl-guide-20040210/
[28] http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/
[29] U. Hustadt, B. Motik, and U. Sattler. Reducing SHIQ− Description Logic to Disjunctive
Datalog Programs. In Proc. KR 2004, pages 152–162, Whistler, Canada, June 2–5, 2004
2004. AAAI Press.
[30] L. Bachmair, H. Ganzinger, C. Lynch, and W. Snyder. Basic Paramodulation.
Information and Computation, 121(2):172–192, 1995.
[31] R. Nieuwenhuis and A. Rubio. Theorem Proving with Ordering and Equality
Constrained Clauses. Journal of Symbolic Computation, 19(4):312–351, 1995.
[32] Karp, Peter D. and Chaudhri, Vinay K. and Thomere, Jerome F. XOL: An XML-Based
Ontology Exchange Language, Technical Note 559. AI Center, SRI International, 333
Ravenswood Ave., Menlo Park, CA 94025, Jul 1999.
[33] M. Bidoit and P. D. Mosses. Casl User Manual, volume 2900 of LNCS. Springer, 2004.
Free online version available at http://www.cofi.info.
[34] Peter D. Mosses, editor. CASL Reference Manual, volume 2960 of Lecture Notes in
Computer Science. Springer, 2004. Free online version available at
http://www.cofi.info.
[35] Lutz Schr¨oder and Till Mossakowski. HasCasl: Towards integrated specification and
development of Haskell programs. In H. Kirchner and C. Ringeissen, editors, Algebraic
Methods and Software Technology, 9th International Conference, AMAST 2002, SaintGilles-les-Bains, Reunion Island, France, Proceedings, LNCS Vol. 2422, pages 99–116.
Springer, 2002.
[36] S. Peyton-Jones, editor. Haskell 98 Language and Libraries — The Revised Report.
Cambridge, 2003. Also: J. Funct. Programming 13 (2003).
[37] K. L¨uttich, T. Mossakowski, and B. Krieg-Br¨uckner. Ontologies for the Semantic Web
in CASL. In Jos´e Fiadeiro, editor, Recent Trends in Algebraic Development
Techniques, 17th International Workshop (WADT 2004), volume 3423 of Lecture
Notes in Computer Science, pages 106–125. Springer; Berlin; http://www.springer.de,
2005.
[38] An Overview of RacerPro http://www.racer-systems.com/products/racerpro/index.phtml
[39] Seaborne, A., Jena Tutorial A Programmer's Introduction to RDQL. HP Labs, 2002.
[40] Richard Fikes, P.H., and Ian Horrocks, OWL-QL – A Language for Deductive Query
Answering on the Semantic Web. KSL 03-14, 2003.
[41] Voronkov, A.R.a.A., Vampire 1.1. IJCAR, 2001. LNAI 2083: pp. 376-380.
[42] Seaborne, E.P.h.a.A., SPARQL Query Language for RDF. 2005.
[43] Volker Haarslev, R.M.o., and Michael Wessel, Querying the Semantic Web with Racer
+ nRQL. In Proceedings of the KI-2004 International Workshop on ADL'04, 2004.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 151 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
[44] Franz Baader, I.H., Ulrike Sattler, Description Logics for the Semantic Web. KI –
Künstliche Intelligenz, 2002. 16(4):57-59.
[45] Brian McBride, J.G.a.D.B., RDF Test Cases. W3C, 2004.
[46] Dmitry Tsarkov, A.R., Sean Bechhofer and Ian Horrocks, Using Vampire to Reason
with OWL. ISWC2004
[47] Dello, C., E. Paslaru Bontas Simperl, and R. Tolksdorf, Creating and using semantic
content with Makna. In Proceedings of the Wiki meets Semantics workshop at the
ESWC2006. 2006. Budva, Montenegro.
[48] Schaffert, S., IkeWiki: A Semantic Wiki for Collaborative Knowledge Management. in
1st international workshop on Semantic Technologies in Collaborative Applications
STICA06. 2006. Manchester, UK.
[49] Völkel, M., et al. Semantic Wikipedia. In Proceedings of the 15th International
Conference on World Wide Web (WWW2006). 2006. Edinburgh, Scotland.
[50] Campanini, S.E., P. Castagna, and R. Tazzoli, Platypus Wiki: a Semantic Wiki Wiki
Web. In Proceedings of the 1st Italian Semantic Web Workshop Semantic Web
Applications and Perspectives (SWAP). 2004. Ancona, Italy.
[51] Di Iorio, A., V. Presutti, and F. Vitali, WikiFactory: An Ontology-Based Application for
Creating Domain-Oriented Wikis. In Proceedings of the 3rd European Semantic Web
Conference, ESWC 2006. 2006, Springer LNCS: Budva, Montenegro.
[52] T. Gruber, “Ontology”, Encyclopedia of Database Systems, Springer, 2008 (to appear).
[53] N.F. Noy and D.L. McGuinness, “Ontology Development 101: A Guide to Creating
Your First Ontology”, Technical Report KSL-01-05, Stanford Knowledge Systems
Laboratory, March 2001.
[54] Web Ontology Language (OWL), Available online: http://www.w3.org/2004/OWL/ .
[55] M. Bidoit and P.D. Mosses, “CASL User Manual – Introduction to Using the Common
Algebraic Specification Language”, LNCS 2900, Springer, 2004.
[56] P.D. Mosses, “CASL Reference Manual – The Complete Documentation of the
Common Algebraic Specification Language”, LNCS 2960, Springer, 2004.
[57] The Common Framework Initiative (CoFI) for algebraic specification and development,
Available online: http://www.informatik.uni-bremen.de/cofi/wiki/index.php/CoFI .
[58] International Federation for Information Processing (IFIP) – WG1.3 on Foundations of
System Specifications, Available online: http://www.fiadeiro.org/jose/IFIP-WG1.3 .
[59] ASK-IT Project, Available online: http://www.ask-it.org/ .
[60] The Protégé Ontology Editor and Knowledge Acquisition System, Available online:
http://protege.stanford.edu/ .
[61] K. Lüttich and T. Mossakowski, “Specification of Ontologies in CASL”, in Proc. of 3rd
International Conference on Formal Ontology in Information Systems (FOIS’04), vol.
114, pp. 140-150, IOS Press, 2004.
[62] K. Lüttich, T. Mossakowski, and B. Krieg-Brückner, “Ontologies for the Semantic Web
in CASL”, in Proc. of 17th International Workshop on Algebraic Development
Techniques (WADT’04), LNCS 3423, pp. 106-125, Springer, 2005.
[63] J. Goguen and G. Rosu, “Institution morphisms”, Formal Aspects of Computing, vol.
13, no. 3-5, pp. 274-307, July 2002.
[64] Hets – the Heterogeneous Tool Set, Available online: http://www.informatik.unibremen.de/agbkb/forschung/formal_methods/CoFI/hets/ .
[65] T. Mossakowski, C. Maeder, and K. Lüttich, “The Heterogeneous Tool Set, HETS”, in
Proc. of 13th International Conference on Tools and Algorithms for the Construction
and Analysis of Systems (TACAS’07), LNCS 4424, pp. 519-522, Springer, 2007.
[66] Cantais, J.; Dominguez, D.; Gigante, V.; Laera,L.; Tamma,V.: An example of food
ontology for diabetes control in C. Welty and A. Gangemi, "Working notes of the ISWC
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 152 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
[67]
[68]
[69]
[70]
[71]
2005 workshop on Ontology Patterns for the Semantic Web", Galway, Ireland,
2005.11.07.
Fernandez, J. Martinez-Selles, M. Correal, C. J. Arredondo, M. T. Nicolosi, G. L.
Koumpouros, Y. Martinelli, E.: “Self-Maintained Collaborative and Multidisciplinary
System for Knowledge Management in Cardiology”, Computers in Cardiology, 2004
Gao, J. et al. 2004. Dining Activity Using a Hiden Markov Model. 17th International
Conference on Pattern Recognition (ICPR04), 915-18.
Y. Yesilada, S. Harper, C. Goble, R. Stevens, Screen readers cannot see (ontology based
semantic annotation for visually impaired web travellers), in: N. Koch, P. Fraternali, M.
Wirsing (eds.), Web Engineering - 4th International Conference, ICWE 2004
Proceedings (LNCS 3140), Springer, 2004.
S. Harper, S. Bechhofer, Semantic Triage for Increased Accessibility, IBM Systems
Journal 44 (3) (2005) 637–648.
S. Karim, A. M. Tjoa, Towards the Use of Ontologies for Improving User Interaction
for People with Special Needs, in: Computers Helping People with Special Needs, vol.
4061/2006, Springer Berlin / Heidelberg, 2006, pp. 77–84.
[72] Plessers P., Casteleyn S., Yesilada Y., Troyer O.D., Stevens R., Harper S. and Goble C.,
Accessibility: A web engineering approach. Proceedings of the Fourteenth International
Conference on World Wide Web, Sep, 2005, pp 353–362, Chiba-Japan.
[73] Valero, M.A.; Vadillo, L.; Penalver, A.; Pau, I.; Gago, E.; Martin, M.; Gonzalez y Eloy
Portillo, M., An Implementation Framework for Smart Home Telecare Services,
Page(s): 60-65
[74] L. M. Camarinha-Matos, H. Afsarmanesh, “TeleCARE: Collaborative virtual elderly
care support communities”, The Journal on Information Technology in Healthcare, Vol.
2, Issue 2, pp 73-86, London, Apr 2004.
[75] Attard, M. and Montebello, M. 2006. DoNet: a semantic domotic framework. In
Proceedings of the 15th International Conference on World Wide Web (Edinburgh,
Scotland, May 23 - 26, 2006).
[76] Chen, H., et al. SOUPA: Standard Ontology for Ubiquitous and Pervasive Applications.
In International Conference on Mobile and Ubiquitous Systems: Networking and
Services. 2004. Boston, MA.
[77] Hobbs, J.R. and F. Pan, An ontology of time for the semantic web. ACM Transactions
on Asian Language Information Processing (TALIP), 2004. 3(1): p. 66-85.
[78] D. Bonino and F. Corno, “DogOnt - Ontology Modeling for Intelligent Domotic
Environments”. International Semantic Web Conference pp.790-803, 2008.
[79] D.B. Lenat and R.V. Guha, “Building large knowledge-based systems”. AddisonWesley Publising Company, Inc. 1990.
[80] M. Uschold and M. King, “Towards a Methodology for Building Ontologies”.
Workshop on Basic Ontological Issues in Knowledge Sharing (1995).
[81] M. Grüninger and M.S. Fox, “Methodology for the design and evaluation of
ontologies”. Workshop on Basic Ontological Issues in Knowledge Sharing, Montreal,
Canada, 1995
[82] A. Bernaras, I. Laresgoiti and J. Corera, “Building and reusing ontologies for electrical
network applications”. In Proc. European Conference on Artificial Intelligence
(ECAI_96), Budapest, Hungary, 1996, pp. 298–302.
[83] M. Fernandez-Lopez, A. Gomez-Perez, A. Pazos-Sierra and J. Pazos-Sierra, “Building a
chemical ontology using METHONTOLOGY and the ontology design environment”.
IEEE Intelligent Systems & their applications 4 (1) (1999) 37–46.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 153 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
[84] B. Swartout, P. Ramesh, K. Knight and T. Russ, “Toward Distributed Use of LargeScale Ontologies”. AAAI Symposium on Ontological Engineering, Stanford, 1997.
[85] G. Schreiber, H. Akkermans, A. Anjewierden, R. de Hoog, N. Shadbolt, W. Van de
Velde and B. Wielinga, “Knowledge Engineering and Management – The
CommonKADS Methodology”. MIT Press. (1999)
[86] S. Staab, H.P. Schnurr, R. Studer and Y. Sure, “Knowledge processes and ontologies”.
IEEE Intelligent Systems 16 (1) (2001) 26–34.
[87] L. Zhou, Q. E. Booker, D. Zhang, “Toward Rapid Ontology Development for
Underdeveloped Domains”. HICSS 2002: 106
[88] C.W. Holsapple and K.D. Joshi, “A collaborative approach to ontology design”.
Commun. ACM 45 (2002) 42–47
[89] P. Spyns, R. Meersman and M. Jarrar, “Data modelling versus ontology engineering”.
SIGMOD Record Special Issue 31(4), 12–17. (2002)
[90] Christoph Tempich, H. Sofia Pinto, York Sure, and Steffen StaabAn Argumentation
Ontology for DIstributed, Loosely-controlled and evolvInG Engineering processes of
oNTologies (DILIGENT). in Second European Semantic Web Conference. 2005.
Greece.
[91] M. Missikoff and R. Navigli, “Applying the unified process to large-scale ontology
building”. In Proceedings of 16th IFAC World Congress (IFAC) (pp. 61–96).
Amsterdam: Elsevier. (2005)
[92] K. Kotis and G. Vouros, “Human-Centered Ontology Engineering: the HCOME
Methodology”. International Journal of Knowledge and Information Systems (KAIS),
10(1): 109-131 (Published Online First: 9 Sept. 2005)
[93] IEEE Standard for Developing Software Life Cycle Processes. IEEE Computer Society.
New York (USA). April 26, 1996.
[94] S. Karapiperis and D. Apostolou, “Consensus building in collaborative ontology
engineering processes”. Journal of Universal Knowledge Management, 1(3), 199–216
(2006).
[95] A. Garcia Castro, P. Rocca-Serra, R. Stevens, C. Taylor, K. Nashar, M. Ragan and S.
Sansone, “The use of concept maps during knowledge elicitation in ontology
development processes – the nutrigenomics use case”. BMC Bioinformatics, 7, 267–
281. (2006)
[96] M.F. Lopez and A.G. Perez, “Overview and Analysis of Methodologies for Building
Ontologies”. Knowledge Engineering Review, 17(2), 129-156. (2002)
[97] C. Tempich, H. S. Pinto, S. Staab, “Ontology Engineering Revisited: An Iterative Case
Study”. ESWC 2006: 110-124
[98] Good, B., Tranfield, E.M., Tan, P.C., Shehata, M., Singhera, G., Gosselink, J., Okon,
E.B., Wilkinson, M., “Fast, cheap, and out of control: A zero curation model for
ontology development”. In: Pacific Symposium on Biocomputing. (2006)
[99] M. C. Suárez-Figueroa, K. Dellschaft, E. Montiel-Ponsoda, B. Villazón-Terrazas, Z.
Yufei, G. Aguado de Cea, A. García, M. Fernández-López, A. Gómez-Pérez, M.
Espinoza, M. Sabou. NeOn Deliverable D5.4.1. NeOn Methodology for Building
Contextualized Ontology Networks. NeOn Project. http://www.neon-project.org.
February 2008.
[100] Alexander Garcia, Kieran O’Neill, Leyla J. Garcia, Phillip Lord, Robert Stevens, Oscar
Corcho and Frank Gibson, “Developing ontologies in decentralised settings”. Nature
Preccedings (2009)
[101] Aditya Kalyanpur, Bijan Parsia, Evren Sirin, Bernardo Cuenca Grau, James A. Hendler:
“Swoop: A Web Ontology Editing Browser”. J. Web Sem. 4(2): 144-153 (2006).
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 154 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
[102] H. S. Pinto, S. Staab, and C. Tempich, “DILIGENT: Towards a fine-grained
methodology for Distributed, Loosely-controlled and evolving Engineering of
oNTologies”. ECAI 2004: 393-397.
CERTH/ITI
14/07/2009
D1.1.1 – vers. 4.5
PUBLIC
Page 155 of 156
Open architecture for Accessible Services
Integration and Standardization - G.A. 215754
Annex 1 – Tools and associated projects
Tools
Protégé 4
OilEd
Apollo
Ontolingua
AbstractionInGeoinformation, AdWiser,
AgentService, AnimeManga, BioPAX,
CellFrame, DBOM, ARTESAS, Catalysoft,
CivicActions, Dama Concepts
GONG, GOAT, CLEF, myGRID, COHSE
CIPHER
Accounting Information Systems, The Trial
Bank
OntoEdit
WonderWeb Project
WebODE
MKBEEM, Spanish CICYT project ContentWeb,
Environment Ontology
KAON
ICOM
DOE
WebOnto
OntoWiki
IsaViz
HOZO
GrOWL
Semantic
Wikis
Medius
VOM
LinKFactory
K-Infinity
CERTH/ITI
14/07/2009
Projects
KAON PORTAL has been successfully
adapted to meet different corporate layouts for
multiple industrial projects carried out by FZI.
Tones
MENELAS
WebOnto
Soft Wiki, ProDV AG, QA-Systems
MEG Registry
Omnibus
Science Environment for Ecological
Knowledge (SEEK)
Makna, IkeWiki, Platypus Wiki
KACTUS
National Patient Safety Network
CULTOS
D1.1.1 – vers. 4.5
PUBLIC
Page 156 of 156