Simulation and the Semantic Web

1. Simulation and the Semantic Web John A. MillerGregory Baramidze Computer Science DepartmentUniversity of GeorgiaAthens, GA 30602, U.S.A. December, 2005

2. Outline of the Talk • Ontology and the Semantic Web • Adding Semantics to Simulation • Purpose of the DeSO Ontology • DeSO Screenshots • Purpose of the DeMO Ontology • DeMO Screenshots • Applications and Benefits • Research Issues

3. Semantic Web • Traditional Web • HTML • Keyword and page rank search • Semantic Web • Several XML based languages • Foundations and logic • Increased machine understanding • Query languages (e.g. SPARQL, SWOPS)

4. Semantic Web Architecture

5. Languages for Representing Ontologies For Satisfiability and Subsumption

6. Protégé Ontology Editor • Supports OWL-Lite, DL, and Full • Has an extension for SWRL rules • Able to output human-readable syntax • Able to import multiple ontologies • Several visualization tools available • OntoViz, OWLViz, Jambalaya, TGViz • Supports UML imports and exports

7. Ontologies for Scientific Domains

8. Increasing Realism and Meaningfulness Abstract, low fidelity Model Greater Semantics Greater Fidelity

9. Purpose of DeSO • A concise, but adequately precise ontology • The most fundamental concepts in modeling and simulation • Time: t  T • Space: x(t)  X • Entity: j  J • State: s(t) = (x1(t), …, xi(t), …) • Effector: event or force • Model: integrates the above elements

10. DeSO in Protégé

11. DeSO Screenshots

12. Sample Abstract Syntax • OWL Class • Class(State partial owl:Thing) • OWL Properties • ObjectProperty(now Functional domain(State) range(Time)) • ObjectProperty(currentValue domain(State) range(PhysicalEntity))

13. Sample Abstract Syntax SWRL Rules • existsIn(?m, ?st) ∧ populatedBy(?st, ?pe) ∧ effectedBy(?pe, ?f) ∧ Force(?f) → isContinuousChange(?m, true) • isContinuousChange(?m, false) → isDiscreteChange(?m, true) • existsIn(?m, ?st) ∧ populatedBy(?st, ?pe) ∧ effectedBy(?pe, ?ef) ∧ computes(?ef, ?f) ∧ StochasticFunction(?f) → isStochastic(?m, true)

14. Purpose of DeMO • DeSO is a higher-level ontology with a broad scope • DeMO is more narrowly focused • Discrete-event modeling • DeMO is more fully developed • ModelConcept • ModelComponent • ModelMechanism • DeModel

15. DeMO ModelConcept

16. DeMO ModelComponent

17. DeMO ModelMechanism

18. DeMO DeModel

19. Applications and Benefits • Browsing. One could look at the concepts in the ontology and navigate to related concepts using Protégé or visualization tools. • Querying.Query languages under development (e.g., RQL, SPARQL, DQL, OWL-QL, SWOPS). • Service Discovery.One could look for a Web service to perform a certain modeling task (e.g. semantic web service discovery using WSDL-S). • Components.DeSO/DeMO can serve as Web-based infrastructure for storing and retrieving executable simulation model components. These components can facilitate reuse.

20. 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. Research Issues with DeSO/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., DeSO imports SUMO) • Combining instance-based and conceptual knowledge(linking DeMO with simulation engines)

22. Thank You.

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

24. Using the Semantic Web in Simulation 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)

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

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

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

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

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

30. 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”.

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

32. CLASSES Class description

33. 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 iiSubsumption relationships DeModel class is the root of the backbone taxonomy

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

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

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

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

41. Appendix Screen shots and definitions

43. Instances of classes (individuals) TransitionTriggering is a ModelMechanism and has two instances: _Multiple_Event_Triggering and _Single_Event_Triggering

44. Example of OWL code

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

46. TAMBIS BioPAX EcoCyc Knowledge Representation and Ontologies KEGG Thesauri “narrower term” relation Disjointness, Inverse,part of… Frames (properties) Formal is-a CYC Catalog/ID DB Schema UMLS RDF RDFS DAML Wordnet OO OWL IEEE SUO Formal instance General Logical constraints Informal is-a Value Restriction Terms/ glossary GO GlycO SimpleTaxonomies ExpressiveOntologies Ontology Dimensions After McGuinness and Finin

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

48. StochasticClockFunction class and its properties

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

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