· web viewthe resulting viewpoint/characteristic codes can be used to retrieve data about the...

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

OASIS – Open architecture for AccessibleServices 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 draft):

RD

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 D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


Document history

Version Date Comments Author

1.0 26-05-2008 First draft. Dionysios Kehagias, Dionysia Kontotasiou, G. Mouratidis, T. Nikolaou

2.005-06-2008 Second draft, integrating input

from all partners. Dionysios Kehagias, Dionysia Kontotasiou, Ioannis Papadimitriou, Kostas Kalogirou, partners: UniBremen, MIZAR, ANCO, INFOTRIP, LST-UPM

3.0 02-09-2008 New information about the OASIS supported domains ontologies have been added.

Dionysios Kehagias, Dionysia Kontotasiou,

4.0 05-06-2009 First revision after the 1st annual project review. It addresses most of reviewers’ recommendations.

Dionysios Kehagias, Dionysia Kontotasiou

4.1-UniBremen

18.6.-2009 Second revision after 1st annual review, completing all recommendations of reviewers and filling in several remaining gaps.

John Bateman,A. Garcia,I. Normann.

4.2 22.6.2009 Overall review of the document. Minor corrections. Several additions with respect to recommendations of reviewers. Formatting issues.

D. Kehagias, D. Kontotasiou

4.3 25.6.2009 Minor revisions. D. Kehagias4.4 14.7.2009 Extensive review and

corrections of entire document. Removal of change markers (reconstruct with diff if required)

J. Bateman

4.5 14.7.2009 Minor corrections and formatting.

D. Kehagias



List of Abbreviations

AI Artificial intelligenceCASL Common Algebraic Specification LanguageDAML DARPA Agent Markup LanguageDARPA Defense Advanced Research Projects AgencyDL Description LogicDTD Document Type DefinitionHETS Heterogeneous Tool SetHTML HyperText Markup LanguageKB Knowledge BaseKIF Knowledge Interchange FormatKR Knowledge RepresentationKSL Knowledge Systems LaboratoryOCML Operational Conceptual Modelling LanguageOIL Ontology Inference LayerOKBC Open Knowledge Base ConnectivityOWL Web Ontology LanguageRDF Resource Description FrameworkSHOE Simple HTML Ontology ExtensionsXML Extensible Markup LanguageXSD XML Schema Definition



Table of ContentsDOCUMENT 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. OASIS OBJECTIVES.....................................................................................131.2. DELIVERABLE STRUCTURE..........................................................................14

2. EXISTING ONTOLOGIES..............................................................15

2.1. GATHERING RELEVANT ONTOLOGIES..........................................................152.1.1. OASIS WP1.1 Ontologies Benchmarking Template.................................152.1.2. OASIS WP1.1 Ontologies Information Gathering Table.........................172.1.3. OASIS Database.......................................................................................22

2.2. NUTRITIONAL ADVISOR ONTOLOGIES.........................................................222.3. ACTIVITY COACH ONTOLOGIES...................................................................232.4. BRAIN AND SKILLS TRAINER ONTOLOGIES.................................................242.5. SOCIAL RELATION AND RECREATION ONTOLOGIES....................................242.6. HEALTH MONITORING ONTOLOGIES............................................................272.7. ENVIROMENTAL CONTROL ONTOLOGIES.....................................................322.8. TRANSPORT INFORMATION ONTOLOGIES.....................................................332.9. ROUTE GUIDANCE ONTOLOGIES..................................................................352.10. PERSONAL MOBILITY ONTOLOGIES.............................................................352.11. SMART WORKPLACES..................................................................................382.12. OTHER AREAS..............................................................................................382.13. INTERIM CONCLUSIONS: CONSEQUENCES FOR OASIS.................................39

3. DESCRIPTION OF METHODOLOGIES AND METHODS FOR BUILDING ONTOLOGIES FROM SCRATCH......................................40

3.1. EVALUATION FRAMEWORK FOR METHODOLOGIES AND METHODS............403.2. CYC METHOD...............................................................................................403.3. USCHOLD AND KING’S METHOD : ENTERPRISE.......................................413.4. GRÜNINGER AND FOX’S METHODOLOGY.....................................................413.5. KACTUS METHOD.......................................................................................423.6. METHONTOLOGY....................................................................................423.7. SENSUS METHOD........................................................................................433.8. COMMONKADS.............................................................................................433.9. ON-TO-KNOWLEDGE METHODOLOGY : OTK..............................................443.10. RAPID ONTOLOGY DEVELOPMENT : ROD...................................................443.11. HOLSAPPLE METHODOLOGY........................................................................453.12. DOGMA APPROACH...................................................................................45



3.13. DILIGENT METHODOLOGY...........................................................................453.14. HCOME.......................................................................................................463.15. UPON APPROACH........................................................................................463.16. CONSENSUS-BASED ONTOLOGY ENGINEERING APPROACH........................473.17. GM METHODOLOGY....................................................................................473.18. ICAPTURER METHODOLOGY........................................................................473.19. NEON METHODOLOGY.................................................................................483.20. MELTING POINT METHODOLOGY................................................................483.21. CONCLUSIONS..............................................................................................48

4. TYPOLOGY FOR THE CHARACTERISATION OF ONTOLOGIES.............................................................................................56

4.1. EVALUATION METRICS FOR ONTOLOGIES...................................................564.1.1. Internal: Lexical / Vocabulary layer........................................................574.1.2. Internal: Structural / architectural layer.................................................574.1.3. Internal: Representational / semantic layer.............................................584.1.4. Internal: Data / Application layer............................................................584.1.5. Internal: Philosophical layer...................................................................594.1.6. External: Usability layer..........................................................................59

4.2. METRICS AND THEIR SUPPORT BY LANGUAGES AND TOOLS........................60Internal: Lexical / Vocabulary layer.....................................................................60Internal: Structural / architectural layer...............................................................60Internal: Representational / semantic layer..........................................................61Internal: Data / Application layer.........................................................................61Internal: Philosophical layer.................................................................................61External: Usability layer.......................................................................................61

4.3. OASIS METHODOLOGICAL APPROACH FOR ONTOLOGY EVALUATION AND REFINEMENT BASED ON ARCHITECTURAL AND DESIGN ASPECTS..............................61

4.3.1. Introduction..............................................................................................614.3.2. Reusing Existing Candidate Ontologies...................................................624.3.3. General Restructuring Issues...................................................................624.3.4. More Specific Comments and Suggestions on Restructuring...................64

4.4. A CASE STUDY EXAMPLE: RESTRUCTURING THE ASK-IT ONTOLOGIES....654.4.1. The ASK-IT Ontologies............................................................................664.4.2. The Refinement/Improvement Process.....................................................66

4.5. CONCLUSIONS..............................................................................................83

5. ONTOLOGY LANGUAGES...............................................................84

5.1. FIRST GENERATION ONTOLOGY LANGUAGES.............................................845.1.1. KIF and Ontolingua.................................................................................845.1.2. Loom.........................................................................................................845.1.3. PowerLoom..............................................................................................855.1.4. OCML.......................................................................................................855.1.5. F-Logic.....................................................................................................855.1.6. OKBC.......................................................................................................855.1.7. SHOE........................................................................................................86

5.2. XML-BASED ONTOLOGY LANGUAGES........................................................865.2.1. XOL..........................................................................................................865.2.2. DAML + OIL............................................................................................86



5.2.3. RDF..........................................................................................................865.2.4. OWL.........................................................................................................925.2.5. RacerPro..................................................................................................98

5.3. THE HETEROGENEOUS TOOL SET................................................................995.4. ONTOLOGY QUERY LANGUAGES...............................................................100

5.4.1. nRQL and Racer.....................................................................................1005.4.2. OWL-QL.................................................................................................1005.4.3. RDQL.....................................................................................................1015.4.4. Vampire..................................................................................................1015.4.5. SPARQL.................................................................................................1015.4.6. WSDL.....................................................................................................102

5.5. ATTRIBUTE-FREE APPROACHES..................................................................102

6. OPEN SOURCE ONTOLOGY TOOLS...........................................103

6.1. EVALUATION FRAMEWORK USED TO COMPARE THE TOOLS......................1036.2. PROTÉGÉ 4.0..............................................................................................104

6.2.1. Main Features........................................................................................1046.3. BIOPORTAL................................................................................................1166.4. OILED.........................................................................................................1176.5. APOLLO......................................................................................................1186.6. RDFEDT.....................................................................................................1196.7. ONTOLINGUA.............................................................................................1206.8. ONTOEDIT..................................................................................................1226.9. WEBODE...................................................................................................1246.10. KAON........................................................................................................1266.11. ICOM.........................................................................................................1276.12. DOE (DIFFERENTIAL ONTOLOGY EDITOR)................................................1296.13. WEBONTO..................................................................................................1316.14. ONTOWIKI..................................................................................................1326.15. ISAVIZ........................................................................................................1336.16. HOZO........................................................................................................1356.17. GROWL.....................................................................................................1356.18. SEMANTIC WIKIS.......................................................................................1366.19. SWOOP.....................................................................................................1366.20. COMPARISON OF TOOLS AGAINST THE EVALUATION FRAMEWORK...........138

7. REASONERS.......................................................................................143

7.1. DESCRIPTION LOGIC REASONERS..............................................................1437.1.1. FaCT++.................................................................................................1457.1.2. RacerPro................................................................................................1467.1.3. Pellet.......................................................................................................1487.1.4. KAON2...................................................................................................1517.1.5. CEL.........................................................................................................1527.1.6. Cerebra Engine......................................................................................1527.1.7. FuzzyDL.................................................................................................1537.1.8. QuOnto...................................................................................................153

7.2. DESCRIPTION LOGIC REASONERS WHICH ARE NO LONGER ACTIVELY SUPPORTED..............................................................................................................153

7.2.1. Classic....................................................................................................153



7.2.2. Loom.......................................................................................................1537.3. RULE ENGINES...........................................................................................154

7.3.1. Jess.........................................................................................................1547.3.2. XSB.........................................................................................................1547.3.3. CWM.......................................................................................................1547.3.4. RuleML Engine.......................................................................................154

8. CONCLUSIONS..................................................................................155

REFERENCES...........................................................................................157

ANNEX 1 – TOOLS AND ASSOCIATED PROJECTS........................163



List of Figures

Figure 1: Social Relation and Community Building Related Taxonomy....................25Figure 2: Personal Support Services Related Taxonomy.............................................36Figure 3: Tourism and Leisure Ontology.....................................................................37Figure 4: Methodology Structure.................................................................................41Figure 5: Grüninger and Fox’s methodology...............................................................42Figure 6: Development process and life cycle of METHONTOLOGY......................43Figure 7: SENSUS Approach.......................................................................................43Figure 8: ROD Framework..........................................................................................44Figure 9: Roles and functions in distributed ontology engineering.............................46Figure 10: A visualization of the different dimensions of ontology classification......56Figure 11: Examples of concept hierarchy/taxonomy restructuring............................68Figure 12: Example of equal domain properties restructuring.....................................69Figure 13: Examples of eliminating duplicates and merging similar definitions........74Figure 14: Examples of improving ontology documentation.......................................75Figure 15: Examples of range definition for object properties....................................75Figure 16: Examples where disjointness condition holds or not..................................76Figure 17: Examples of satisfying naming conventions..............................................78Figure 18: An Example RDF Description....................................................................87Figure 19: Graph representation of the example RDF Description in Figure 18.........88Figure 20: An example RDF Description illustrating the use of Containers...............89Figure 21: An example of “making Statements about Statements”.............................90Figure 22: An example description illustrating the use of SubClassOf Property........91Figure 23: Domain and Range Constraints in RDF description...................................92Figure 24: HETS architecture......................................................................................99Figure 25: Protégé screenshot....................................................................................104Figure 26: OWL Viz plug-in......................................................................................106Figure 27: DL-Query Tab..........................................................................................107Figure 28: Object Property Description Table...........................................................107Figure 29: Matrix Views............................................................................................108Figure 30: Cardinality View.......................................................................................108Figure 31: Existential Tree.........................................................................................109Figure 32: Excel Importer..........................................................................................110Figure 33: Bookmarks................................................................................................110Figure 34: Taxonomy Cut-Paste................................................................................111Figure 35: The Protégé Nerd......................................................................................112Figure 36: TerMine plug-in.......................................................................................113Figure 37: OWL Lint..................................................................................................114Figure 38: Annotation Search View..........................................................................115Figure 39: Alternative Annotation View....................................................................115Figure 40: Change View............................................................................................116Figure 41: OilEd screenshot.......................................................................................117Figure 42: Main window with loaded ontology in Apollo.........................................118Figure 43: RDFedt screenshot....................................................................................120Figure 44: Screenshot of ontology creation in Ontolingua........................................121Figure 45: OntoEdit screenshot..................................................................................122Figure 46: WebODE ontology editor.........................................................................125



Figure 47: KAON Tool screenshot............................................................................126Figure 48: ICOM screenshot......................................................................................127Figure 49: ICOM screenshot......................................................................................128Figure 50: DOE screenshot........................................................................................130Figure 51: Interoperabitily using RDFS and OWL....................................................131Figure 52: WebOnto screenshot.................................................................................131Figure 53: Ontowiki Ontology Editor........................................................................133Figure 54: IsaViz Ontology Editor.............................................................................135Figure 55: Architecture of Description Logic............................................................143Figure 56: Pellet architecture.....................................................................................150Figure 57: Kaon2 architecture....................................................................................151

List of TablesTable 1: Approaches' proposed ontology development process..................................52Table 2: Approaches' proposed ontology development process..................................53Table 3: Evaluation metrics supported by Methodologies...........................................54Table 4: Evaluation metrics supported by Methodologies...........................................55Table 5: OWL code for the first example of Figure 11................................................68Table 6: OWL code for properties restructuring of Figure 12.....................................71Table 7: Examples of similar ontological concepts repetition.....................................72Table 8: Rewriting in CASL the classes of Table 7.....................................................73Table 9: OWL code for documenting class “Accommodation” of Figure 14.............75Table 10: OWL code for disjoint concepts of Figure 16..............................................77Table 11: General Restructuring Issues on Classes.....................................................79Table 12: General Restructuring Issues on Properties.................................................80Table 13: Concept/Hierarchy Restructuring Issues......................................................81Table 14: Specific Restructuring Issues.......................................................................82Table 15: Recommended XML Schema Data types....................................................97Table 16: Tools’ Architecture....................................................................................140Table 17: Tools' interoperability................................................................................140Table 18: Tools' inference services............................................................................141Table 19: Tools' usability...........................................................................................141Table 20: Overview of Tools' versioning and collaborative work support................142



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:



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.



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 well-formed 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



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 ObjectivesThe 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.

To evaluate interfaces of ontology management tools, in terms their support for modularity, reusability and development.

1 http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2007



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 hyper-ontology 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 StructureThe 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.



2.Existing Ontologies 2.1. Gathering Relevant OntologiesThe 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:



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: Yes No

9. Ontology Standardization Bodies:

10. Web Service Standards:

11. Specification of ontology communication interface

12. Ontology Documentation:

13. Most Common Ontology Metrics

Syntaxo syntactic correctness (automatic checkers available?):

Yes Noo breadth of syntax used (restricted formalism?):

Yes NoIf yes, add details: ………………………………………………...…….…………………………………………………………………………..

Governanceo Are the terms regulated by a government body, international

standard, etc.?Yes No



If yes, add details: ………………………………………………………….……………………………………………………………………………...

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 NoIf yes, add details: ………………………………………………………….……………………………………………………………………………...

Explicit relation to existing general lexical resources (e.g., WordNet, etc.) or existing application/domain-specific terminologies.

Yes NoIf 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:



Partner: MIZAR PHILIPS CERTH/HIT CERTH/ITI ITACA PTV AGE SIEMENS VODAFONEApplication Domain 1. Nutritional Advisor Ontologies X 2. Activity Coach Ontologies X 3. Brain and Skills Trainer Ontologies 4. Social Relation and Recreation Ontologies X 5. Health Monitoring Ontologies X 6. Enviromental Control Ontologies X 7. Transport Inforamtion Ontologies X X 8. Route Guidance Ontologies X X 9. Personal Mobility Ontologies X X X 10. Smart Workplaces

11. Other (please specify)

SP SP1 X XSP2 XSP3 X XSP4 X XSP5 X X

Contact Person

Monica Raimondi, e-mail:[email protected]

Silvio Bonfiglio [email protected]

Kostas Kalogirou, [email protected]

Dionysis Kehagias, [email protected]

Ma Pilar Sala [email protected]

Partner: MOTOROLA POLIS CRF FhG/IESE FhG/IAO FhG/IIS UniBremen UNEW SILO

CERTH/ITI D1.1.1 – vers. 4.5 PUBLIC14/07/2009 of 160


Application Domain 1. Nutritional Advisor Ontologies 2. Activity Coach Ontologies X3. Brain and Skills Trainer Ontologies 4. Social Relation and Recreation Ontologies 5. Health Monitoring Ontologies X6. Enviromental Control Ontologies7. Transport Inforamtion Ontologies8. Route Guidance Ontologies 9. Personal Mobility Ontologies10. Smart Workplaces X X


SP SP1 XSP2 XSP3 XSP4 XSP5

Contact Person

Jan-Paul Leuteritz. Email: [email protected]

Matthias Struck [email protected]

stelios Pantelopoulos, [email protected]

Partner: DML ANCO FORTH MCACONNCEPT

SWISS eWORX UNIPI INFOTRIP ATAF



Application Domain 1. Nutritional Advisor Ontologies 2. Activity Coach Ontologies 3. Brain and Skills Trainer Ontologies 4. Social Relation and Recreation Ontologies X 5. Health Monitoring Ontologies 6. Enviromental Control Ontologies X 7. Transport Inforamtion Ontologies X X8. Route Guidance Ontologies X9. Personal Mobility Ontologies X X10. Smart Workplaces

11. Other (please specify) X

SP SP1 XSP2 SP3 XSP4 SP5

Contact Person

Miltos Anastasiadis, [email protected]

Chris Condos, [email protected]

[email protected], [email protected], [email protected]

G.Ambrosino([email protected]), C.Binazzi ([email protected])

Partner: ATCROM CTAG NETSMART ITESM TULST-UPM INNOVALIA WKK MULTITEL

Application Domain



1. Nutritional Advisor Ontologies X2. Activity Coach Ontologies 3. Brain and Skills Trainer Ontologies 4. Social Relation and Recreation Ontologies X5. Health Monitoring Ontologies X6. Enviromental Control Ontologies 7. Transport Inforamtion Ontologies X X8. Route Guidance Ontologies X X9. Personal Mobility Ontologies X X10. Smart Workplaces


SP SP1 XSP2 X XSP3 X SP4 X X XSP5 X

Contact Person

Jordi Contreras, [email protected]

Viveca Jiménez

Cristina de la Maza [email protected]

[email protected]



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=0CERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


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 D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160

http://www.csc.liv.ac.uk/_jcantais/PIPSFood.owl


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


http://alis.cs.bath.ac.uk/ontologies/Activities/activitiesV1.4.owl


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 OASIS. In the context of this area it is particularly worth mentioning the ASK-IT4 sub-ontology 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

4 http://askit.iti.gr/ontology5 http://www.opentravel.org/6 http://www.harmo-ten.org7 http://www.deri.at/research/projects/e-tourism/documents/HarmoniseOntologyCERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160

http://en.wikipedia.org/wiki/XML

http://askit.iti.gr/ontology


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.

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

8 http://dig.csail.mit.edu/SwapMe/9 http://193.39.157.27/avanti/default.htm10 http://www.eptron.es/projects/said/CERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160

http://dig.csail.mit.edu/SwapMe/


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

11 http://palette.ercim.org/12 http://www.onesite.com/index.htmlCERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


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 (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,

13 http://sig.biostr.washington.edu/projects/fm/AboutFM.htmlCERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


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

14 http://diseaseontology.sourceforge.net/CERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


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.

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 http://nciterms.nci.nih.gov/NCIBrowser/Dictionary.do16 http://www.nlm.nih.gov/pubs/factsheets/umls.htmlCERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160

http://www.co-ode.org/galen/full-galen.owl


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 logic-based 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 D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160

http://www.gdst.uqam.ca/Documents/Ontologies/HIT/


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 OntologiesControlling 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 OWL-Time [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 etc., are all represented as DoNet SpatialThings. Items, which have a function, or simply 18 http://www.emerge-project.eu/19 http://www.cocoon-health.com20 http://www.hitech-projects.com/euprojects/amigo/CERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160

http://www.gdst.uqam.ca/Documents/Ontologies/HIT/


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; RouteSegmentDetail;



CoordinatesInCountry; RouteSegment; Route; PublicTransportTimeTable; OptionalInformation; LineTimetable; TrafficEvent; PublicTransportEvent; HotelGuestInformation; HotelAvailabilityResponse; MakeBookingResponse;

An ontology documentation can be found at http://www.imagineit-eu.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, such as “picturesque”, “calm” (low traffic volume), etc. route; whereas ASK-IT defined only the “accessible” route (considering only physical accessibility).


http://www.imagineit-eu.com/ftp/IM@GINE%20IT%20D2.1.2%20final.pdf

http://www.imagineit-eu.com/ftp/IM@GINE%20IT%20D2.1.2%20final.pdf


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 OntologiesIn 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, multi-lingual 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 http://www.insafety-eu.org/22 http://www.ossate.org/CERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


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



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 AreasThe 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

23 http://www.soprano-ip.org/24 http://www.mosquito-online.org/CERTH/ITI D1.1.1 – vers. 4.3 PUBLIC 14/07/2009 of 160

http://askit.iti.gr/ontology/


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 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 OASISIn 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



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 different sources. The difference between them is the degree of automation of the knowledge CERTH/ITI D1.1.1 – vers. 4.3 PUBLIC 14/07/2009 of 160


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 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 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 application-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 : RODROD [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 MethodologyHolsapple 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.

3.12. DOGMA ApproachThe 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 MethodologyThe 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 clarification of the domain conceptualisations, uncovering the informal human intended semantics of the ontology specifications, the improvising of ontologies, allowing the from-scratch CERTH/ITI D1.1.1 – vers. 4.3 PUBLIC 14/07/2009 of 160


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 ApproachUPON (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 D1.1.1 – vers. 4.3 PUBLIC 14/07/2009 of 160


3.16. Consensus-based Ontology Engineering ApproachKarapiperis 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 re-engineering 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

25 http://www.neon-project.orgCERTH/ITI D1.1.1 – vers. 4.3 PUBLIC 14/07/2009 of 160


prototypes or versions of the ontology are thus constantly being created. Initially these 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. ConclusionsWhen 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.

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 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.pdfCERTH/ITI D1.1.1 – vers. 4.3 PUBLIC 14/07/2009 of 160


Feature Cyc Uschold &King’s

Grüninger & Fox’s

KACTUS METHONTOLOGY

SENSUS OTK DILIGENT HCOME

Project Management

Processes

Project Initiation Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Described From OTK Not Proposed

Control Not Proposed

Not Proposed

Not Proposed

Not Proposed

Proposed Not Proposed


Quality Management Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed


Ontology Development

Oriented Activities

Pre-development

processes

Environment Study

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Proposed From OTK Not Proposed

Feasibility Study

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed


Development Processes

Requirements

Not Proposed

Proposed Described in detail



Described Proposed

Design Not Proposed

Not Proposed

Described Described Described in detail

Not Proposed

Described Described in detail

Proposed

Implementation

Proposed Proposed Described Proposed Described in detail

Described Described Described Proposed

Post-development

Processes

Installation Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Proposed Described Described

Maintenance Not Proposed

Not Proposed

Not Proposed

Not Proposed



Described

Retirement Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Described Proposed

Integral Processes

Knowledge acquisition Proposed Proposed Proposed Not Proposed

Described in detail

Not Proposed

Described Proposed Not Proposed

Verification & Validation Not Proposed

Proposed Proposed Not Proposed

Described in detail

Not Proposed


Ontology Configuration Management

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Described in detail

Not Proposed


Documentation Proposed Proposed Proposed Not Proposed

Described in detail

Not Proposed

Described From OTK Described

Training Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Not Proposed


Table 1: Approaches' proposed ontology development process



Feature Consensus based

Holsapple CommonKADS

DOGMA UPON GM ROD iCapturer NeOn

Project Management

Processes

Project Initiation Not Proposed

Not Proposed

Not Proposed


Not Proposed

Not Proposed Not Proposed

Proposed

Control Not Proposed

Not Proposed

Not Proposed

Not Proposed Proposed Not Proposed


Proposed

Quality Management Not Proposed

Not Proposed

Not Proposed


Not Proposed


Proposed

Ontology Development

Oriented Activities

Pre-development

processes

Environment Study

Described in detail

Proposed Proposed Described Proposed Described Described Described Described in detail

Feasibility Study

Described in detail

Proposed Proposed Described Proposed Described Described Described Described in detail

Development Processes

Requirements Described in detail


Described Described Proposed Proposed Described Described in detail

Design Described in detail

Proposed Described Proposed Described Proposed Proposed Described Described in detail

Implementation Described in detail

Proposed Described Not Proposed Described Proposed Proposed Described Described in detail

Post-development

Processes

Installation Not Proposed

Not Proposed

Not Proposed


Not Proposed


Proposed

Maintenance Described in detail

Proposed Proposed Not Proposed Proposed Proposed Proposed Proposed Described

Retirement Not Proposed

Not Proposed

Not Proposed


Not Proposed


Not Proposed

Integral Processes

Knowledge acquisition Described in detail

Proposed Proposed Proposed Described Proposed Described Proposed Described in detail

Verification & Validation Described in detail

Proposed Proposed Not Proposed Described Described in detail

Proposed Proposed Described in detail

Ontology Configuration Management


Not Proposed


Not Proposed


Documentation Proposed Proposed Proposed Proposed Described Described in detail


Training Not Proposed

Not Proposed

Not Proposed

Not Proposed Proposed Not Proposed


Not Proposed

Table 2: Approaches' proposed ontology development process



Evaluation Metrics Cyc Uschold &King’s

Grüninger & Fox’s

KACTUS METHONTOLOGY

SENSUS OTK DILIGENT HCOME

Internal Layers

Lexical/Vocabulary (includes criteria relevant to the syntactic elements of ontologies)

Not Proposed

Not Proposed

Not Proposed

Not Proposed

Proposed but not described

Limited Not Proposed

Limited Proposed but not described

Structural/Architectural(includes criteria relevant to the

structural attributes of ontologies)

Not Proposed

Limited Described Described Described Described Limited Not Proposed Described

Representational/Semantic(includes criteria relevant to the semantic elements of ontologies)

Limited Limited Limited Limited Described Described Limited Described Described

Data/Application(includes the applicability of an ontology in a given application

domain)

Described Limited Described Described Described Described Described Described Described

Philosophical(includes the relation to existing upper level ontologies or general

lexical resources)

Limited Proposed but not described

Proposed but not described

Not Proposed

Not Proposed

Described Described Not Proposed Described

External Layers

Usability(includes quality measures that are required in order to ensure that the resulted ontologies satisfy a set of

usability standards)

Described Described Described Not Proposed

Described Not Proposed

Described Described Described

Table 3: Evaluation metrics supported by Methodologies



Evaluation Metrics Consensus based

Holsapple CommonKADS

DOGMA UPON GM ROD iCapturer NeOn

Internal Layers

Lexical/Vocabulary(includes criteria relevant to the syntactic elements of ontologies)


Not Proposed


Described Described Described Described

Structural/Architectural(includes criteria relevant to the

structural attributes of ontologies)

Described Described Limited Described Not Proposed

Described Described Described Not Proposed

Representational/Semantic(includes criteria relevant to the semantic elements of ontologies)

Described Limited Limited Described Limited Described Limited Described Described

Data/Application(includes the applicability of an ontology in a given application

domain)

Described Described in detail

Described Described Described in detail

Described Described Proposed but not described

Limited

Philosophical(includes the relation to existing upper level ontologies or general

lexical resources)


Not Proposed


Described Described Described Described

External Layers

Usability(includes quality measures that are required in order to ensure that the resulted ontologies satisfy a set of

usability standards)

Described Described Described Described Described Described Not Proposed

Described Described

Table 4: Evaluation metrics supported by Methodologies



4. Typology for the characterisation of ontologies

4.1. Evaluation Metrics for OntologiesThis 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:



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 definitionso essential features to be satisfied by all naming conventions

(e.g., nominal, verbal, etc. plus other styles) o no circularity in definitionso intelligibility (documented?, logically defined?)o positive naming (no junk categories, minimal ‘other’

categories)o consistent (no contradictions).

Syntaxo syntactic correctness (automatic checkers available?)o breadth of syntax used (restricted formalism?).

Governanceo 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?:

Controlled vocabulary. Taxonomy.



Thesaurus. Ontology proper. Data Models. Object Models.

Ontologies as graph structures:o size (how many concepts, relations, etc.)o depth of hierarcho breadth of hierarchyo density (average branching)o balance (are all areas equally developed or are there areas

of low complexity and others with high complexity)o overall complexityo 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: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 implementationo 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; browsingo HC + Structure digital libraries; indexing, browsing & search

o Union of all the others & more.o HC + Structure (and validate) databases.o HC + Structure software systems.o System-internal functionality only

4.2. Metrics and their support by languages and toolsThough 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


http://www.informatik.uni-bremen.de/cofi/wiki/index.php


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 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 aspects4.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 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 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

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.

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

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

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”.



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


Before After

BarCafeRestaurant

BarCafeRestaurant

FoodAndDrink

ClimateMeanTemperatureTemperature

WeatherMeanTemperatureTemperature

Climate


<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 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”.



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>

<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"/>


Before After

dayValue

nightValue

minValue

maxValue

MeanTemperatureDomain:

TemperatureDomain:

generalInfoOfClimategeneralInfoOfWeather

generalInfoOfMeanTemperature

generalInfoOfTemperature

dayValuenightValue

minValuemaxValue

cloudyrainysnowysunny


<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"> <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

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 Table7 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

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


end

spec ExhibitionsMuseums = Impairments %% reuse Impairments specification

then

sort Impairment < ExhibitionsMuseum %% Impairment subclass of ExhibitionsMuseum


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.



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

Figure 14: Examples of improving ontology documentationCERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160

Before After

POIS_How_to_get_there2POIS_How_to_get_to_the_poisPOISHowToGetThere

POIHowToGetThere

General_info2GeneralInfoForALL

GeneralInfo

hasAccommodationhasAccommodationInfo

hasAccommodation

mean_tmp mean_tmp

Accommodation :

Climate :

A concept that models a place where someone can stay, e.g. a hotel room.A concept that models some of the climate characteristics.


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

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.


hasMonth

hasWalk

Range:

Range:

Month

Walk


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 “SpectatorStandForHearingImp” and “SpectatorStandForUpperLimbImp”, as presented in Figure 16).


DoctorHospital

MedicalService

DisjointSpectatorStandForHearingImp

SpectatorStand

Not disjointSpectatorStand

ForUpperLimbImp


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 tree-like 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.

Figure 17: Examples of satisfying naming conventions


Local_support_groups LocalSupportGroupLongBench longBench


ASK-IT Ontologies

General Restructuring Issues

General ASK-IT Personal Support Services

Social Relations and Community

Building Services

Touristic and Leisure Related Transportation

Work Business and Education

Support Content

New Version

Old Version

New Version

Old Version

New Version

Old Version

New Version

Old Version

New Version

Old Version

New Version

Old Version

Named Classes

Total Classes 676 687 38 38 96 103 261 335 47 73 93 124Primitive Classes

(classes that only have necessary

conditions)

676 683 38 38 96 103 261 333 47 73 93 123

Defined Classes (classes that have at least

one set of necessary and sufficient

conditions)

0 4 0 0 0 0 0 2 0 0 0 1

Average Number of Parents for Each Class 2 2 1 1 1 1 1 1 1 1 1 1Maximum Number of Parents for Each Class 2 2 1 1 1 1 1 1 1 1 1 1

Average Number of Siblings for Each Class 17 22 3 3 6 7 11 15 8 0 5 4Maximum Number of

Siblings for Each Class 61 85 3 3 10 10 67 111 10 0 10 10

Total Number of Various

Restrictions on Classes

Total 28 27 28 40 75 169 86 250 0 423 36 181Existential (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 180Cardinality (exactly) 0 0 0 0 0 0 0 0 0 0 0 0

MinCardinality (at least) 0 0 0 0 0 0 0 0 0 76 0 1MaxCardinality (at most) 0 0 0 0 0 0 0 0 0 0 0 0

HasValue 3 3 0 0 0 0 0 0 0 0 0 0

Table 11: General Restructuring Issues on Classes



ASK-IT Ontologies

General Restructuring Issues



Building Services



Support Content

New Version

Old Version

New Version

Old Version

New Version

Old Version

New Version

Old Version

New Version

Old Version

New Version

Old Version

Properties

Total Number of Properties 10 15 98 85 148 142 267 290 269 377 135 157

Number of Object Properties 6 7 34 34 42 49 51 92 31 88 33 58

Number of Datatype Properties 4 8 64 51 106 93 216 198 238 289 102 99

Number of Annotation Properties 0 0 0 0 0 0 0 0 0 0 0 0

Properties with a domain specified 10 8 96 85 148 109 267 249 269 0 135 49

Properties with a range specified 6 4 34 0 42 1 51 0 31 64 33 1

Properties with an inverse specified 2 2 0 0 0 0 0 0 0 0 0 0

Table 12: General Restructuring Issues on Properties



ASK-IT Ontologies

Concept Hierarchy Restructuring Issues



Building Services



Support Content

New Version

Old Version

New Version

Old Version

New Version

Old Version

New Version

Old Version

New Version

Old Version

New Version

Old Version

Classes

Max Depth 5 5 2 2 2 2 4 6 2 ? 2 4Total Number of Nodes 677 688 39 39 97 104 262 336 48 73 94 125Total Number of Roots 1 1 1 1 1 1 1 1 1 1 1 1

Total Number of Internal Nodes (Parents) 82 66 2 2 10 10 46 45 3 9 12 20

Total Number of Children 676 687 38 38 96 103 261 335 47 85 93 124Total Number of External

Nodes 595 622 37 37 87 94 216 291 45 81 82 105

Internal Path Length 262 237 1 1 9 9 101 100 2 4 11 30External Path Length 2792 3087 41 41 142 150 460 823 60 87 127 195

Object Properties

Max Depth 0 0 0 0 0 0 0 0 0 0 0 0Total Number of Nodes 6 7 34 34 42 49 51 92 31 88 33 58Total Number of Roots 6 7 34 34 42 49 51 92 31 88 33 58


Total Number of Children 0 0 0 0 0 0 0 0 0 0 0 0Internal Path Length 0 0 0 0 0 0 0 0 0 0 0 0External Path Length 0 0 0 0 0 0 0 0 0 0 0 0

Datatype Properties

Max Depth 0 0 1 0 2 0 3 0 1 0 1 0Total Number of Nodes 4 8 64 51 106 93 216 198 238 289 102 99Total Number of Roots 4 8 14 51 29 93 86 198 35 289 41 99


Total Number of Children 0 0 50 0 73 0 117 0 203 0 61 0Internal Path Length 0 0 0 0 0 0 0 0 0 0 0 0External Path Length 0 0 50 0 73 0 117 0 203 0 61 0

Table 13: Concept/Hierarchy Restructuring Issues

ASK-IT Ontologies General ASK-IT Personal Support Services


Touristic and Leisure Related Transportation Work Business

and Education



Specific Restructuring Issues

Building Services Support Content

New Version

Old Version

New Version

Old Version

New Version

Old Version

New Version

Old Version

New Version

Old Version

New Version

Old Version

Documentation

Total Number of Documented Classes 676 0 38 0 96 0 261 0 47 0 93 0

Total Number of Documented Properties

0 0 0 0 0 0 0 0 0 0 0 0

Total Number of Disjointness Restrictions on Classes 676 0 38 0 96 0 261 261 47 0 93 0

Naming Conventions

Percentage of Classes followed the same

naming conventions100% 79.63% 100% 63.15% 100% 57.28% 100% 76.12% 100% 21.91% 100% 26.63%

Percentage of Object Properties followed the

same naming conventions

100% 100% 100% 100% 100% 38.77% 100% 66.30% 100% 89.77% 100% 43.10%

Percentage of Datatype Properties followed the

same naming conventions

100% 62.5% 100% 94.12% 100% 16.13% 100% 67.17% 100% 74.74% 100% 41.41%

Table 14: Specific Restructuring Issues



4.5. ConclusionsIn 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.



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 Languages5.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 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.

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 Languages5.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.

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.



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 D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160

ABC Company April 23, 2002

http://www.srdc.metu.edu.tr/eCatalog

dc:Creator dc:Date


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.



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:RDFxmlns: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.



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 Figure23. 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].



<?xml version="1.0" encoding="UTF-8" ?><rdf:RDFxmlns: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.”



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.



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. In the best of all possible worlds they need to be composed. To tie together a set of CERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


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 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 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:normalizedString xsd:booleanxsd:decimal xsd:float xsd:doublexsd:integer xsd:nonNegativeInteger xsd:positiveIntegerxsd:nonPositiveInteger xsd:negativeIntegerxsd:long xsd:int xsd:short xsd:bytexsd:unsignedLong xsd:unsignedInt xsd:unsignedShort xsd:unsignedBytexsd:hexBinary xsd:base64Binaryxsd:dateTime xsd:time xsd:date xsd:gYearMonthxsd:gYear xsd:gMonthDay xsd:gDay xsd:gMonthxsd:anyURI xsd:token xsd:languagexsd:NMTOKEN xsd:Name xsd:NCName

Table 15: Recommended XML Schema Data types5.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 statement, a reasoner can deduce an inconsistency when an individual is stated to be

27 http://www.chime.ucl.ac.uk/work-areas/ehrs/EHCR-SupA/13606v1_8/sld001.htmCERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


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 hierarchy and the current proof state, and thus may be used for monitoring the overall


http://dl.kr.org/krss-spec.ps

http://www.sts.tu-harburg.de/~r.f.moeller/racer/interface1.1.pdf


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 architectureHETS 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

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 CERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


query problem one at a time 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 approachesThere 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 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.



6. Open Source Ontology ToolsIn 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 cross-section 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 toolsThis 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


http://xml.com/2002/11/06/Ontology_Editor_Survey.html


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.



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



membership of arbitrary descriptions without having to create named class placeholders.

Figure 26: OWL Viz plug-in

Figure 27: DL-Query Tab



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.



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



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.



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.



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.



Figure 36: TerMine plug-in

Figure 37: OWL Lint



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.



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. BioPortalCollaborative 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.



6.4. OilEdOilEd 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 FaCTCERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160

http://img.cs.man.ac.uk/


Limited web supporto 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−CARDINALITY,:MAXIMUM−CARDINALITY,:ALIAS,:INHERITANCE.

Basic features : Import/export format

o CLOS(Common LISP Object System) and OCML



Not support graph view 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



6.6. RDFedtThe 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.


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 Support RSS modules

o Aggregation, Annotation, etc Automatic generation of a rdf-based linked list from a html-document Load and save XML files



Figure 43: RDFedt screenshot

6.7. OntoLinguaOntolingua 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.



Figure 44: Screenshot of ontology creation in Ontolingua


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.


6.8. OntoEditOntoEdit 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



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 D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


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.


o XML, RDF(S), FLogic and DAML+OIL for free versiono 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 storageo File (free) vs. File and DBMS (professional)

Built-in inference engineo Not support (free) vs. support via OntoBroker (professional)

Collaborative working and Ontology libraryo 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.



6.9. WebODEThis 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.

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


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 viewo Form based graphical user interfaces

Consistency checko 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:

Mergingo Via ODEmerge methodology

Extensibilityo Via plug-ins

Ontology storageo 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. KAONKAON 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:

- 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


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 rollbackCERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160



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.


6.11. ICOMICOM is an advanced CASE tool which allows the user to design multiple extended Entity-Relationship 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 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.

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


Figure 49: ICOM screenshot


o XML and UML Graph view



o Native editing of ER diagrams Consistency check

o Via FaCT No web support No multi-user support


Mergingo Supports inter-ontology mapping with graphical interface

Not support information extraction



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




o OWL, OIL, CGXML, XSLT, RDFS and DAML+OIL No support for graphical view Consistency check

o Via arity and type inheritance on relational domainso Via detection of cycles in hierarchies

Basic web supporto URL of the ontology


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.

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



6.13. WebOntoWebOnto, 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 CERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


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.


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




6.14. OntoWikiOntoWiki 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.


Figure 53: Ontowiki Ontology Editor

6.15. IsaVizIsaViz 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


http://www.w3.org/2001/11/IsaViz/Overview.html

http://en.wikipedia.org/wiki/Universit%C3%A4t_Leipzig

http://aksw.org/

http://en.wikipedia.org/wiki/Semantic_wiki

http://en.wikipedia.org/wiki/PHP

http://en.wikipedia.org/wiki/Knowledge_management

http://en.wikipedia.org/wiki/Ontology_(computer_science)


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.

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



6.16. HOZOHozo 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 role-concept, 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 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.


6.17. GrOWLGrOWL 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


http://www.w3.org/TR/2003/PR-owl-guide-20031215/


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.



6.18. Semantic WikisThe basic idea of semantic wikis is to provide an underlying formal and (partially) machine-processable 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 Wiki-like 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.

Currently, there is an internal Wiki for the OASIS project28. 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.



6.19. SWOOPSWOOP 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.

28 https://134.102.53.11/oasis-wiki/pmwiki.php?n=OASIS.Homepage


https://134.102.53.11/oasis-wiki/pmwiki.php?n=OASIS.Homepage

http://sourceforge.net/projects/owlapi


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 [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.



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 frameworkThe 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, K-Infinity, 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 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 lock-and-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 CERTH/ITI D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


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.



Feature Apollo DOE Hets ICOM KAON K-Infinity LinkFactory

Medius VOM

OILEd OntoEdit Ontolingua Protégé 4 RDFedt WebODE WebOnto

Extensibility Via plug-ins

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 LinkFactory

Medius VOM


Import Format OCML, CLOS

XSLT, RDF (S), OIL,

DAML+OIL, OWL and

CGXML

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

XSLT, RDF (S), OIL,

DAML+OIL, OWL and

CGXML

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 No Yes With Inter

Ontology

mapping

No ? Yes Limited No ? ? Via ANCHOR- PROMPT

plug-in

? Via ODEmerge ?

Table 17: Tools' interoperability



Feature Apollo DOE Hets ICOM KAON K-Infinity LinkFactory Medius VOM


Inference Engine No Yes Pellet,Vampire,SPASS,Isabelle,Darwin

Yes Yes Yes Yes Yes With FACT

No No With PAL No Prolog Yes

Exception Handling

No No ? No No ? No ? No No No No Yes No No

Consistency Checking

Yes Via type

inheritance 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 servicesFeature Apollo DOE Hets ICOM KAON K-Infinity LinkFactory Medius

VOMOILEd 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



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 web-based Protégé

Not fully supported

Not supported Not supported Not supported Not fully supported

Not supported Not fully supported

Not fully supported

Feature 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

Table 20: Overview of Tools' versioning and collaborative work support



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 ReasonersThe 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 non-empty, 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.



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 tableau-based 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, 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 version, 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), including 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.

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. RacerProRacerPro 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 user-defined 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 T-boxes 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 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 A-

box 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.



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. PelletPellet 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


http://www.cs.man.ac.uk/~horrocks/Publications/#HoSa05a


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 E-connected 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



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 explanation-generating 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.



7.1.4. KAON2KAON2 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 =

. For an individual x in C, the first axiom implies existence



of an R-successor y in E1. By the second axiom, y is also in E2. Hence, x has an R-successor 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. CELCEL [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 EngineCerebra, 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. FuzzyDLFuzzyDL 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).



7.1.8. QuOntoThe 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. ClassicClassic 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 non-trivial and useful.

7.2.2. LoomLoom’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. JessJess (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 D1.1.1 – vers. 4.5 PUBLIC 14/07/2009 of 160


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. XSBXSB 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. CWMCwm 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 EngineMandarax 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.



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



References

[1] 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.

[2] 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.

[3] 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.

[4] S. Bechhofer, P. Crowther, and R. Moller. The description logic interface. In� D. Calvanese, G. De Giacomo, and E. Franconi, editors, International Workshop on Description Logics, pages 196{203, September 2003.

[5] KAON2 infrastructure for managing OWL-DL, SWRL and F-Logic Ontologies http://kaon2.semanticweb.org/

[6] 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

[7] CEL A polynomial-time Classifier for the description logic EL+ http://lat.inf.tu-dresden.de/systems/cel/

[8] 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

[9] 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.

[10] 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

[11] M. Genesereth, R. Fikes, “Knowledge interchange format”, Technical Report Logic-92-1, Computer Science Department, Stanford University, 1992

[12] T. Gruber, « A translation approach to portable ontologies », Knowledge Acquisition 5(2), Academic Press (1993), pp 199-220

[13] R. MacGregor, “Inside the LOOM clasifier”, SIGART bulletin 2, 1991, pages 70–76[14] Motta E. Reusable Components for Knowledge Modelling. IOS Press, Amsterdam, The

Netherlands. ISBN: 1 58603 003 5, 1999[15] M. Kifer, G. Lausen, J. Wu, “Logical foundations of object-oriented and frame-based

languages”, Journal of the ACM 42, 1995, pages 741–843[16] 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

[17] S. Luke, J. Heflin “SHOE 1.01. proposed specification”, SHOE Project technical report, University of Maryland,2000



[18] 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

[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-ref-20031215/

[26] OWL Web Ontology Language Reference, http://www.w3.org/TR/2004/REC-owl-ref-20040210/

[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öder 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, Saint-Gilles-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üttich, T. Mossakowski, and B. Krieg-Brückner. Ontologies for the Semantic Web in CASL. In José 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.


http://www.racer-systems.com/products/racerpro/index.phtml

http://www.cofi.info/

http://www.cofi.info/


[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.

[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.uni-bremen.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.


http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/

http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/

http://protege.stanford.edu/

http://www.ask-it.org/

http://www.fiadeiro.org/jose/IFIP-WG1.3

http://www.informatik.uni-bremen.de/cofi/wiki/index.php/CoFI

http://www.w3.org/2004/OWL/


[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 2005 workshop on Ontology Patterns for the Semantic Web", Galway, Ireland, 2005.11.07.

[67] 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

[68] Gao, J. et al. 2004. Dining Activity Using a Hiden Markov Model. 17th International Conference on Pattern Recognition (ICPR04), 915-18.

[69] 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.

[70] S. Harper, S. Bechhofer, Semantic Triage for Increased Accessibility, IBM Systems Journal 44 (3) (2005) 637–648.

[71] 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”. Addison-Wesley 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.

[84] B. Swartout, P. Ramesh, K. Knight and T. Russ, “Toward Distributed Use of Large-Scale 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).

[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.


http://www.informatik.uni-trier.de/~ley/db/conf/ecai/ecai2004.html#PintoST04

http://www.informatik.uni-trier.de/~ley/db/journals/ws/ws4.html#KalyanpurPSGH06

http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/h/Hendler:James_A=.html

http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/h/Hendler:James_A=.html

http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/g/Grau:Bernardo_Cuenca.html

http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/s/Sirin:Evren.html

http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/p/Parsia:Bijan.html

http://precedings.nature.com/users/3e4be56d9f760e6c51c46168270a4fa9

http://precedings.nature.com/users/5c38eefbb62d65c1d79682ad03cdfeed

http://precedings.nature.com/users/837dbbbbfc6edaa6e7c750b81819ba88


Annex 1 – Tools and associated projects

Tools ProjectsProtégé 4 AbstractionInGeoinformation, AdWiser,

AgentService, AnimeManga, BioPAX, CellFrame, DBOM, ARTESAS, Catalysoft, CivicActions, Dama Concepts

OilEd GONG, GOAT, CLEF, myGRID, COHSEApollo CIPHER

Ontolingua Accounting Information Systems, The Trial Bank

OntoEdit WonderWeb ProjectWebODE MKBEEM, Spanish CICYT project ContentWeb,

Environment OntologyKAON KAON PORTAL has been successfully

adapted to meet different corporate layouts for multiple industrial projects carried out by FZI.

ICOM Tones DOE MENELAS

WebOnto WebOntoOntoWiki Soft Wiki, ProDV AG, QA-Systems

IsaViz MEG RegistryHOZO Omnibus

GrOWL Science Environment for Ecological Knowledge (SEEK)

Semantic Wikis

Makna, IkeWiki, Platypus Wiki

Medius VOM

KACTUS

LinKFactory National Patient Safety NetworkK-Infinity CULTOS


http://www.biomath.jussieu.fr/~pz/Menelas/

http://www.ksl.stanford.edu/software/ontolingua/ontology-server-projects.html#trialbank

http://www.ksl.stanford.edu/software/ontolingua/ontology-server-projects.html#trialbank