ONTOLOGIES FOR MODELING AND SIMULATION: ISSUES AND APPROACHES Part II

1
ONTOLOGIES FOR MODELING AND SIMULATIONISSUES
AND APPROACHESPart II
Paul A. FishwickCISEUniversity of
FloridaGainesville, FL 32611, U.S.A.
John A. MillerComputer Science
DepartmentUniversity of GeorgiaAthens, GA
30602, U.S.A.
December, 2004
2
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 weve developed a
prototype OWL-based ontology
Discrete-event Modeling Ontology (DeMO)
3
Semantic Web Architecture
Layer Principle Language Name
Resource/Data 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
4
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) ?
5
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
• MathML

MONET (Mathematics On the NET)
6
Existing taxonomies in simulation and modeling
Classification may be based on various
characteristics Static vs. Dynamic Discrete vs.
Continuous Deterministic vs. Stochastic Time-varyi
ng 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
7
DeMO Discrete-event Modeling Ontology
The main goal was to investigate the principles
of construction of an ontology for discrete-event
modeling and to flush out the problems and
promises of this approach, as well as directions
of future research.
8
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
9
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.
10
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.
11
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)
12
CLASSES
Class description
13
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
14
(No Transcript)
15
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.
16
(No Transcript)
17
(No Transcript)
18
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)

19

• 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 available to those
  searching for them.)

20

• 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 of
  simulation tools, model reuse and data sharing.

21
Appendix

• Screen shots and definitions

22
(No Transcript)
23
Instances of classes (individuals)
TransitionTriggering is a ModelMechanism and has
two instances _Multiple_Event_Triggering and
_Single_Event_Triggering
24
Example of OWL code
25
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
26
Knowledge Representation and Ontologies
KEGG
Thesauri narrower term relation
Disjointness, Inverse,part of
Frames (properties)
Formal is-a
CYC
Catalog/ID
RDF
DAML
DB Schema
RDFS
UMLS
Wordnet
OO
IEEE SUO
OWL
General Logical constraints
Formal instance
Informal is-a
Value Restriction
Terms/ glossary
GO
GlycO
SimpleTaxonomies
ExpressiveOntologies
Ontology Dimensions After McGuinness and Finin
27
Ontologies for Scientific Domains
Ontology Name Domain
EngMath Engineering Math Mathematics
EHEP Exp. High-Energy Physics Physics
OntoNova ONTOlogy-based NOVel qA. Chemistry
GO Gene Ontology Genetics
MDEG Microarray Gene Expression Data Biology
AstroGrid Astronomy Grid Astronomy
28
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.
29
StochasticClockFunction class and its properties
30
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.

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

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

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