ONTOLOGIES FOR MODELING AND SIMULATION: ISSUES AND APPROACHES Part II - PowerPoint PPT Presentation

Loading...

PPT – ONTOLOGIES FOR MODELING AND SIMULATION: ISSUES AND APPROACHES Part II PowerPoint presentation | free to download - id: 5e69a2-M2Q3Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

ONTOLOGIES FOR MODELING AND SIMULATION: ISSUES AND APPROACHES Part II

Description:

ONTOLOGIES FOR MODELING AND SIMULATION: ISSUES AND APPROACHES Part II Paul A. Fishwick CISE University of Florida Gainesville, FL 32611, U.S.A. John A. Miller – PowerPoint PPT presentation

Number of Views:320
Avg rating:3.0/5.0
Slides: 34
Provided by: cobwebCs
Learn more at: http://cobweb.cs.uga.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: ONTOLOGIES FOR MODELING AND SIMULATION: ISSUES AND APPROACHES Part II


1
ONTOLOGIES FOR MODELING AND SIMULATION ISSUES
AND APPROACHES Part II
Paul A. Fishwick CISE University of
Florida Gainesville, FL 32611, U.S.A.
John A. Miller Computer Science
Department University of Georgia Athens, 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
Simple Taxonomies
Expressive Ontologies
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?
About PowerShow.com