Transcript ONTOLOGIES FOR MODELING AND SIMULATION: ISSUES AND APPROACHES

ONTOLOGIES FOR
MODELING AND
SIMULATION:
ISSUES AND APPROACHES
Part II
John A. Miller
Computer Science Department
University of Georgia
Athens, GA 30602, U.S.A.
Paul A. Fishwick
CISE
University of Florida
Gainesville, FL 32611, U.S.A.
December, 2004
1
What is it we are trying to do?
Study the potential use, benefits and the
developmental requirements of Web-accessible
ontologies for discrete-event simulation and
modeling. As a case study we’ve developed a
prototype OWL-based ontology :
Discrete-event Modeling Ontology
(DeMO)
2
Semantic Web Architecture
Principle
Language
Name
XML
eXtensible Markup
Language
Meta-Data
RDF
Resource Description
Framework
Ontology
OWL
Ontology Web
Language
Logic
SWRL
Semantic Web Rule
Language
Proof/Trust
Future work
Layer
Resource/Data
3
Languages for Representing Ontologies
Acronym
Name
Complexity
OWL Lite
Ontology Web Language – Minimal
(SHIF)
EXP-TIME
OWL DL
OWL – Description Logic
(SHOIN)
NEXP-TIME
OWL Full
OWL – Full Feature Set
Semi-decidable
RDF(S)
Resource Description Framework
(Schema)
Semi-decidable
KIF
Knowledge Interchange Format
Undecidable
UML
Unified Modeling Language (w/ OCL)
?
4
Upper and mid-level ontologies
• Modeling and Simulation Ontology should
eventually be build from upper ontologies
defining foundational concepts.
• Examples:
–
–
–
–
Suggested Upper Merged Ontology (SUMO)
Standard Upper Ontology (SUO)
OpenMath
MONET (Mathematics On the NET)
MathML
5
Existing taxonomies in simulation and
modeling
Classification may be based on various characteristics
Static vs. Dynamic
Discrete vs. Continuous
Deterministic vs. Stochastic
Time-varying vs. Time-invariant
Descriptive vs. Prescriptive
Time-driven vs. Event-driven
Analytic vs. Numeric
Classification may be based on existing taxonomies
Simulation World Views:
Event-scheduling, Activity-scanning, Process-interaction,
State-based
Programming Paradigms:
Declarative, Functional, Constraint
6
DeMO – Discrete-event Modeling Ontology
The main goal was to
investigate the principles
of construction of an
ontology for discreteevent modeling and to
flush out the problems
and promises of this
approach, as well as
directions of future
research.
7
DeMO Design Approach
To build a discrete-event modeling ontology essentially means to
capture and conceptualize as much knowledge about the DE
modeling domain as possible and/or plausible.
We start with the more general concepts and move down the
hierarchy, while building necessary interconnections as we go.
DeMO has four main abstract classes representing the main
conceptual elements of this knowledge domain:
DeModel,
ModelConcepts,
ModelComponents,
ModelMechanisms
8
Rationale behind DeMO design
Any DeModel is built from model components
and is “put in motion” by model mechanisms,
which themselves are built upon the most
fundamental model concepts.
9
MODEL CONCEPTS
The most basic, fundamental
terms upon which the ontology is
built. Some of the concepts may
not be formally defined.
In this respect similar to geometric
terms as point, line, etc.
MODEL MECHANISMS
Specify the “rules of engagement”
adopted by different models. In
essence “explain how to run the
model”.
10
Protégé - OWL
To build DeMO we used Protégé -- an open-source
ontology editor and a knowledge-base editor.
(http://protege.stanford.edu/)
Protégé OWL plug-in allows one to easily
build ontologies that are backed by OWL
code.
OWL ontologies roughly contain three types
of resources:
Classes - represent concepts from the knowledge domain (e.g., the
class Person)
Individuals - specific instances of classes (e.g., the tall Person that
lives in 12 Oak st.)
Properties - determine the values allowed to each individual (e.g.,
the specific Person has height 190 cm)
11
CLASSES
Class description
12
BACKBONE TAXONOMY
IN PROTEGE
A backbone taxonomy is our
mental starting point for
building an ontology.
It is defined based on
i World-views of the models
ii Subsumption relationships
DeModel class is the root of
the backbone taxonomy
13
14
MODEL COMPONENTS
This class describes the
elements that are used as
the building blocks of
DeModel classes.
Generally correspond to
the elements in n-tuples
traditionally used in the
literature to formally
define the models.
15
16
17
Research Issues with DeMO
• Depth vs. breadth of ontology
• Design choices for the ontology
• Issues of ambiguity (multiple ways of defining concepts
and how to deal with them)
• Mappings between various modeling formalisms
• Relating different ontologies (e.g., a future Math
ontology, or an ontology for Graph Topology)
• Combining instance-based and conceptual
knowledge (linking DeMO with simulation engines)
• Terminal points (where do we stop the ontology)
18
Potential Benefits
• Browsing. One could look at the concepts in the ontology and
navigate to related concepts.
• Querying. Query languages under development (e.g., RQL,
DQL, OWL-QL) and more. Next layer, the logic layer (e.g.,
SWRL and FORUM).
Given such query capabilities, queries on DeMO would be very useful.
• Service Discovery. One could look for a Web service to perform
a certain modeling task (Verma et al.,2003), (Chandrasekaran et al., 2002).
• Components. DeMO can serve as Web-based infrastructure for
storing and retrieving executable simulation model components.
These components can facilitate reuse.
(e.g. Code implementations of specific probability density functions can be attached
directly to the ProbabilisticTransitionFunction link, and they are made
19
available to those searching for them.)
• Hypothesis Testing. The LSDIS Lab is currently carrying out
funded research to allow hypothesis testing to be performed using the
Semantic Web (Sheth et al., 2003).
In the future, this capability could be used to pose challenging questions such as which
adaptive routing algorithm will work best on the evolving Internet.
• Research Support. Papers in the field of modeling and simulation
may be linked into the ontology to help researchers find more relevant
research papers more rapidly.
These links can be added manually or through automatic extraction/classifications tools such
as those provided by Semagix (www.semagix.com).
• Mark-up Language Anchor. Domain-specific XML-based mark-up
languages allow interfaces to software or descriptions of software to
be presented in platform and machine-independent ways.
The tags used in the markup language should ideally be anchored in a domain ontology. In
the simulation community such work has begun (e.g., XML for rube (Fishwick, 2002b)).
This enhances the interoperability of simulation models.
• Facilitate Collaboration. Shared conceptual framework provides
opportunities for increased collaboration, including interoperability
20 of
simulation tools, model reuse and data sharing.
Appendix
Screen shots and definitions
21
22
Instances of classes (individuals)
TransitionTriggering is a ModelMechanism and has two instances:
_Multiple_Event_Triggering and _Single_Event_Triggering
23
Example of
OWL code
24
What is an Ontology?
Traditional: a branch of metaphysics concerned with the
nature and relations of being .
Merriam-Webster
Information Technology: “An explicit formal
specification of how to represent the objects,
concepts and other entities that are assumed to
exist in some area of interest and the
relationships that hold among them.”
or more concisely:
“An ontology is a formal, explicit
specification of a shared conceptualization.”
Gruber, T. R
25
Knowledge Representation and Ontologies
TAMBIS
KEGG
Thesauri
“narrower
term”
relation
Catalog/ID DB Schema
UMLS
Wordnet
Terms/
glossary
Frames
(properties)
RDF
RDFS
OO
Informal
is-a
GO
Simple
Taxonomies
Formal
is-a
Formal
instance
BioPAX
Disjointness,
Inverse,
part of…
DAML
CYC
OWL
IEEE SUO
Value
Restriction
General
Logical
constraints
GlycO
Expressive
Ontologies
EcoCyc
26
Ontology Dimensions After McGuinness and Finin
Ontologies for Scientific Domains
Ontology
Name
Domain
EngMath
Engineering Math
Mathematics
EHEP
Exp. High-Energy Physics
Physics
OntoNova
ONTOlogy-based NOVel q&A.
Chemistry
GO
Gene Ontology
Genetics
MDEG
Microarray Gene Expression
Data
Biology
AstroGrid
Astronomy Grid
Astronomy
27
MODEL COMPONENTS
Many of the ModelComponents characterizing
different first-level formalisms are either identical in
meaning or translatable into each other. These
relationships may be captured using description
logic tools provided by OWL, thus placing stronger
semantic connections between the model
components.
e.g.
All first-level formalisms use TimeSet as a
formal component.
ClockFunction is another example, although it
may have slightly different meaning in different
first-level formalisms.
28
StochasticClockFunction class and its properties
29
Breadth vs Width of the Ontology.
• If the domain ontology is too broad it may
become too complex and disjointed.
Ambiguities may be quite difficult to
resolve.
• On the other hand, if it is too narrow, it is
of limited use.
30
Handling of Multiple Taxonomies.
• What is the best way to embed multiple
taxonomies in the ontology? Should a
principal taxonomy be picked as the
backbone (subsumption of modeling
techniques was chosen in DeMO). The
other taxonomies then became secondary
(e.g., determinacy, application area, etc.).
31
Further categorization
• Knowledge subdomains such as
ModelMechanisms, for example, require
further formal categorization (at present English
descriptions are used for ModelMechanisms).
• Deeper relationships between the concepts
(such as mappings between different
modeling formalisms, for example) need to
be developed.
32
Design choices for the ontology
• Do we have to have a unified theory where
top level formalisms are some special cases
of one general model?
• Can we create different ontologies and
merge/link them together without
developing a unifying formalism?
33