Ontology Development
Ecoinformatics International Technical Collaboration
Seattle, Washington, USA
January 27, 2010
Bruce Bargmeyer
Lawrence Berkeley National Laboratory
Tel: +1 510-495-2905
[email protected]
1
Topics



Overview of ontology development project
Overview of ontology results
Some observations
Scope

General applications
 Facilitate information discovery, search, retrieval,
assessment, interoperation, reasoning, modeling ,
simulation, analysis and integration across
organizations and domains

Databases, sensors, simulations, documents, etc.
Focus on terminology/concepts that are of use for
Simulations, Analysis and Modeling with an emphasis
on integrated modeling
 General application: advance the state-of-the-art of
monitoring and assessment
 We focused the effort on a particular Use Case

3
Ontology Development
fuller semantics
Formal Ontology
OWL, Common Logic
Conceptual Model
ER/UML
Concepts and relations
expressed in an ontology
representation language that
provides formal semantics
(i.e., specifies logical
inferences).
Concepts and relations among
them in a modeling language
Taxonomy/Thesaurus
Terms (possibly with definitions) & relations
between terms
Glossary
Keywords
Terms associated with definitions (concepts)
Terms
limited semantics
4
Semantics Management
Discipline

While we skipped over some of the past technologies, we
Must keep in mind the discipline and lessons learned with
prior technologies.




Keywords: Term list, may be undefined
Glossary: Terms defined in natural language, limited relation between
terms (may be considered concepts)
Thesaurus/Taxonomy: Terms defined, some relations (broader than,
narrower than, related to, isA)
We need new disciplines to manage new capabilities.


Manage ontology concepts, properties, relations, axioms, natural language
definitions, formal definitions, computable meaning (sameAs,
disjointWith), description logic
Common Logic: Full first order logic.
5
Methodology



There is no Ontological Engineering equivalent to
Knowledge or Software Engineering. There are no
standard methodologies for building ontologies.
We had to develop and evolve our own approach and
methodology as the purpose, skills, and capabilities
emerged.
.General approach



Collaborate between ontologists (mostly geeks) and Subject Matter
Experts (SMEs) to identify and enter content
Set up tools for collaboration
Weekly telecons to interact between participants
6
Ontology Issues




Different use cases call for different ontology content and structure
A single ontology may not address all desired uses
It may be more practical to develop and manage specialized ontologies
that are related
Definitions of concepts and relations


Initially, we used somewhat loose natural language definitions (or none).
Depending on use cases, it will desirable in the future to develop more
formal definitions.
At the beginning, to get a quick start, we did not enforce discipline on the
development of definitions. As we proceed, we want to utilize ISO
704:2000 as guidelines for developing definitions for concepts and
relations. We will also utilize ISO/IEC 11179 Part 4, for data definitions.
7
Content organization
Structure of the ontology
W5H
Framework
Units
Places
Generic Industry
Semiconductor
Device Mfg.
Industry
Domain Abstractions
Domain Individuals
Sensors
Extraction
Imported
Ontologies &
SAM-WIKI
SEMATECH
&
CHIP-WIKI
KB
Occurants
(events)
8
Shared Upper Knowledge
Reference Systems
Processing
Remote Sensing
Geo-Reference
Chemical Processing
Imagery
Temporal-Reference
Manufacturing
Sensors
Physical Geography
Spectroscopy
GeoSpatial
Facilities
Domain Knowledge
Processing
Spectroscopy
GeoSpatial
Facilities
Content Construction
Content of the ontology
 At the core of the framework, we used the four concepts in Ucore:
Who, What, When, and Where.




We extended these to cover Why and How (causal graphs).
Ucore does not currently have this represented as an ontology, but has them
represented in UML. We created an ontology based on the Ucore material.
Event is the central concept in our ontology and Who, What, When, Where, How
and Why are properties of Event.
Identifying concepts and relations
Concepts and relations were identified by a variety of techniques.
These include contributions from existing vocabularies, content
from the use case, products of analysis and extraction activities,
and independent contributions from SMEs.
Special work was required to bridge the gap between the material
provided by the SMEs and the content needed for the Use Case.


10
Content Construction


To the extent possible, we incorporated existing ontologies
identified by SMEs.
 Reuse or adapt existing ontologies
 Save time
 Gain benefit of broader consensus
 Facilitate interoperation
Issues raised by integration of existing ontologies
 Ontology alignment
 Ontology merging
 Poor documentation


Implicit assumptions
Choices between alternative ontologies covering same
domain
11
Content Input for Ontology Construction

Glossaries identified as potentially useful by SMEs
 Ontologies identified as potentially useful by SMEs
 Term lists (some with definitions) developed by SMEs
and Assessment Teams
 Content entered into a Wiki by SMEs
 UML models for Who, What, Where, When from
Ucore
 Content extensions needed for Use Case
12
Interrelated Ontologies Developed
 Interrelated

Ontologies
Broader, multi-level framework with a domain
independent core plus industry specific content

The core of the framework is based on W5H
SME terms incorporated into the ontologies
 “Lightning strike” ontology that goes from general
level to data instance level to demonstrate an ontology
approach to the Use Case



Small knowledgebase developed for Use Case
Ontologies extended by importing or otherwise
incorporating externally developed ontologies
13
Tools





After review, we decided to use Protégé 3.x to create the ontology. The newly
released Protégé 4.x is missing some of the useful functions of 3.x. We will
watch continued development of Protégé to see when to make the switch.
Protégé 4.x provides support for OWL 2, so we will want to go there.
To avoid everyone having to install Protégé on their local computers we used
Web Protégé.
We built an initial version of a Semantic MediaWiki for collaborative work on
ontology development.
For future efforts, want to check out Collaborative Protégé. This is an
extension of the existing Protégé system that supports collaborative ontology
editing as well as annotation of both ontology components and ontology
changes.
We used various visualization tools to display the ontology
14
Ontology Output
 SME
term lists translated into ontologies
 facilities-modeling.owl
 integrated-modeling.owl
 advanced-spectroscopy.owl
15
Ontology Output (Cont.)





ChipO.owl
ChipWiki.owl
MicroelectronicsLevel 1.owl
MicroelectronicsLevel 2.owl
SEMATECH.owl















Imports the SAMO ontologies:
Advanced-spectroscopy.owl
Elements.owl
Faciltities_modeling.owl
Integrated-modeling.owl
Intell.owl
Materials.owl
Ogc-gml.owl
SAMO.owl
SAMWiki.owl
Sensor-data.owl
Skos-owl1.dl.rdf
Things.owl
Time-entry.owl
W5H.owl
16
Ontology Output (Cont.)















Imports the NASA SWEET ontologies:
Material_thing.owl
Numerics.owl
Phenomena.owl
Process.owl
Property.owl
Space.owl
Substance.owl
Sunrealm.owl
Time.owl
Units.owl
Biosphere.owl
Data.owl
Earthrealm.owl
Human_activities.owl
17
Bangkadi Knowledge Base
 bangkadi.owl
- A small knowledge base for
demonstration of the use case
18
Visualizations
19
Ontology Overview
20
Ontology Hierarchy
21
Imported SKOS
22
Ontology Elephants
There is no single real elephant
There must be a purpose for
an elephant: use cases?
An elephant is abstract
An elephant is very abstract
There must be an
upper elephant
An elephant is the result
An elephant is
really very simple of consensus
Open vs.
Closed
Elephant
There are only
distributed
elephants &
their mappings Source: Leo Obrst, MITRE
Acknowledgements
 Kevin
Keck, LBNL
 Craig Blackhart, LANL
 Helen Cui, LANL
 Ryan Hohimer, PNNL
 Leo Obrst, MITRE
24