ONTOLOGIES FOR MODELING AND SIMULATION: ISSUES AND APPROACHES

Document Sample
ONTOLOGIES FOR MODELING AND SIMULATION: ISSUES AND APPROACHES Powered By Docstoc
					        ONTOLOGIES FOR
         MODELING AND
          SIMULATION:
    ISSUES AND APPROACHES
             Part II
      John A. Miller               Paul A. Fishwick
Computer Science Department                CISE
   University of Georgia          University of Florida
 Athens, GA 30602, U.S.A.     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
   Layer                            Name
                Language
                               eXtensible Markup
Resource/Data      XML
                                   Language
                              Resource Description
  Meta-Data        RDF
                                  Framework
                                 Ontology Web
  Ontology         OWL
                                  Language
                               Semantic Web Rule
    Logic         SWRL
                                  Language
 Proof/Trust    Future work                     3
 Languages for Representing Ontologies

Acronym                  Name                   Complexity
           Ontology Web Language – Minimal
OWL Lite                                        EXP-TIME
           (SHIF)
           OWL – Description Logic
OWL DL                                          NEXP-TIME
           (SHOIN)

OWL Full   OWL – Full Feature Set               Semi-decidable

           Resource Description Framework
RDF(S)                                          Semi-decidable
           (Schema)

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 discrete-
                       event 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 of
                                                                   20
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

                             KEGG                 TAMBIS
                                                                         BioPAX
             Thesauri
            “narrower                                            Disjointness,
                                Formal          Frames
              term”                                                Inverse,
                                 is-a         (properties)        part of…
             relation
 Catalog/ID DB Schema    UMLS         RDF             RDFS        DAML        CYC
              Wordnet           OO                            OWL       IEEE SUO
  Terms/            Informal             Formal          Value          General
 glossary              is-a             instance       Restriction       Logical
                                                                      constraints
                        GO                         GlycO
                                                                           EcoCyc
 Simple                                                    Expressive
 Taxonomies                                                Ontologies
                                                                                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
             Microarray Gene Expression
  MDEG                                      Biology
                        Data
 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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:10
posted:12/13/2011
language:
pages:33