Introduction to Modeling: OO Modeling and Ontologies

1. Introduction to modeling OO modeling and ontologies

2. Where are we?

3. UML modelingSlides for this part are based on Chapters 9 from Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition (ISBN: 978-0-12-373568-3), published by Morgan Kaufmann Publishers.

4. Intro to Unified Modeling Language (UML) • Mainly used for designing object-oriented program code • De facto standard in industry for object-oriented software design • UML notation is a set of languages • Class diagrams are used for the data schema • Like ER, UML uses attributes. Material on this slide based on Ch 9.1 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

5. UML Class diagrams • Class structure – three compartments Material on this slide based on Ch 9.2 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

6. UML Class diagrams (cont’) • Associations - depicted by a line between the classes; the open arrow is a navigability setting (issues related to performance, not conceptual issues about the business domain) • Class diagrams can be used for conceptual analysis. • But no identification schemas are provided for the classes • Nonstandard identification schemas:   “{P}” for preferred reference and “{Un}” for uniqueness (n > 0) Material on this slide based on Ch 9.2 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

7. Attributes in UML Class diagrams • In UML, attributes are mandatory and single valued by default • UML attributes (a) depicted as ORM relationship types (b) Material on this slide based on Ch 9.3 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

8. Attributes in UML Class diagrams (cont’) • Multiplicities: • Multi-valued UML sports attribute depicted as (b) ORM m:n fact type: Material on this slide based on Ch 9.3 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

9. UML object diagrams • Object diagrams: Class diagrams in which each object is shown as a separate instance of a class, with data values supplied for its attributes • They easily become unwieldy if multiple instances for more complex cases are displayed • Populated models in (a) UML and (b) ORM: Material on this slide based on Ch 9.3 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

10. Associations • Binary associations are depicted as lines between classes • Association names are optional, but role names are mandatory • If two or more roles are played by the same class, the roles must be given different names to distinguish them Material on this slide based on Ch 9.4 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

11. Associations (cont’) • Ternary and higher arity associations in UML are depicted as a diamond connected by lines to the classes • Multiplicity constraints on associations similar to those on attributes; multiplicities are written next to the relevant roles

12. Equivalent constraint patterns in UML and ORM Material on this slide based on Ch 9.4 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

13. Equivalent constraint patterns in UML and ORM (cont’) Material on this slide based on Ch 9.4 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

14. n-ary associations, association classes, and qualified associations in UML • A multiplicity constraint on a role of an n-ary association constrains the population of the other roles combined • Association classes in UML are equivalent to objectified associations in ORM Material on this slide based on Ch 9.4 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

15. n-ary associations, association classes, and qualified associations in UML (cont’) • Cases where ORM uses an external uniqueness constraint for co-referencing can be modeled in UML using qualified associations Material on this slide based on Ch 9.4 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

16. Set-Comparison Constraints in UML • Subset constraints can be specified between whole associations by attaching the constraint label “{subset}” next to a dashed arrow between the associations • Subsets properties are used to indicate that the population of an attribute or association role must be a subset of the population of another compatible attribute or association role respectively • However many subset constraint cases in ORM that cannot be represented graphically as a subset constraint in UML Material on this slide based on Ch 9.5 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

17. Set-Comparison Constraints in UML (cont’) • UML has no graphic notation for equality constraints • May be specified as textual constraints in notes Material on this slide based on Ch 9.5 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

18. Set-Comparison Constraints in UML (cont’) • Exclusion constraints: not directly supported in UML, but does include an exclusive-or constraint to indicate that each instance of a class plays exactly one association role from a specified set of alternatives • UML has no symbols for exclusion or inclusive-or constraints • UML has no graphic notation for exclusion between attributes, or between attributes and association roles • An exclusion constraint in such cases may often be captured as a textual constraint Material on this slide based on Ch 9.5 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

19. Subtyping constraints in UML • Single and multiple inheritance is allowed both in UML and ORM • Subtype inherits all the roles of its supertypes in ORM • A subclass inherits all the attributes, associations, and operations/methods of its supertype(s) in UML • UML and ORM both display subtyping using directed acyclic graphs Material on this slide based on Ch 9.6 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

20. Other constraints in UML • Value constraints • Enumeration types may be modeled as classes, stereotyped as enumerations, with their values listed as attributes • Ranges and mixtures may be specified by declaring a textual constraint in braces • Ring constraints: UML does not provide ring constraints built in • Can be specified as a textual constraint or as a note Material on this slide based on Ch 9.7 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

21. UMLmap - Mapping from ORM to UML Material on this slide based on Ch 9.8 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

22. Some examples of UMLmap steps Step 1 Step 2 Material on this slide based on Ch 9.8 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

23. Some examples of UMLmap steps (cont’) Step 3 Step 4 Material on this slide based on Ch 9.8 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

24. Correspondence between ORM and UML data instances and structures Material on this slide based on Ch 9.9 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition

25. Resources • Chapter 9 in Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition (ISBN: 978-0-12-373568-3), published by Morgan Kaufmann Publishers, an imprint of Elsevier.  • http://www.uml.org/ • Tools: http://en.wikipedia.org/wiki/List_of_UML_tools

26. Ontologies

27. Outline • Foundations • Definitions, features, classifications, applications, modelling principles • Ontology engineering • Methodologies and methods and tools to build, manage and use ontologies • How to build an ontology (Ontology 101) • Selected tools • Protégé, Collaborative Protégé

28. What is an ontology? • An ontology defines the basic terms and relations comprising the vocabulary of a topic area, as well as the rules for combining terms and relations to define extensions to the vocabulary Neches, R.; Fikes, R.; Finin, T.; Gruber, T.; Patil, R.; Senator, T.; Swartout, W.R. Enabling Technology for Knowledge Sharing. AI Magazine. Winter 1991. 36-56 • An ontology is an explicit specification of a conceptualization Gruber, T. A translation Approach to portable ontology specifications. Knowledge Acquisition. Vol. 5. 1993. 199-220

29. What is an ontology (ii)? • An ontology is a hierarchically structured set of terms for describing a domain that can be used as a skeletal foundation for a knowledge base B. Swartout; R. Patil; k. Knight; T. Russ. TowardDistributed Use of Large-Scale OntologiesOntologicalEngineering. AAAI-97 Spring Symposium Series. 1997. 138-148 • An ontology provides the means for describing explicitly the conceptualization behind the knowledge represented in a knowledge base A. Bernaras;I. Laresgoiti; J. Correra. BuildingandReusing Ontologies forElectrical Network ApplicationsECAI96. 12th European conferenceon Artificial Intelligence. Ed. John Wiley&Sons, Ltd. 298-302

30. What is an ontology (iii)? “An ontology is a formal, explicit specification of a shared conceptualization” Consensual Knowledge Machine-readable Concepts, properties relations, functions, constraints, axioms, are explicitly defined Abstract model and simplified view of some phenomenon in the world that we want to represent Studer, Benjamins, Fensel. Knowledge Engineering: Principles and Methods. Data and Knowledge Engineering. 25 (1998) 161-197

31. Players SUMO

32. Features of an ontology • Modelled knowledge about a specific domain • Defines • A common vocabulary • The meaning of terms • How terms are interrelated • Consists of • Conceptualization and implementation • Contains • Ontological primitives

33. Classifications of ontologies (i) • Issue of the conceptualization • Upper-level/Top-level • Domain • Application • Degree of formality • Highly informal: in natural language • Semi-informal: in a restricted and structured form of natural language • Semi-formal: in an artificial and formally defined language • Rigorously formal: in a language with formal semantics, theorems and proofs of such properties as soundness and completeness

34. Classifications of ontologies (ii) General Logical constraints Thessauri “narrower term” relation Frames (properties) Formal is-a Catalog/ID Formal instance Disjointness, Inverse, part-Of ... Terms/ glossary Informal is-a Value Restrs. Lassila O, McGuiness D. The Role of Frame-Based Representation on the Semantic Web. Technical Report. Knowledge Systems Laboratory. Stanford University. KSL-01-02. 2001.

35. Languages for building ontologies • Ontologies can be built using various languages with various degrees of formality • Natural language • UML • ER • OWL/RDFS • WSML • FOL • ... • The formalism and the language limit the kind of knowledge that can be represented • A domain model is not necessarily a formal ontology only because it is written in OWL

36. Applications of ontologies • Knowledge representation • Ontology models domain knowledge • Semantic annotation • Ontology is used as a vocabulary, classification or indexing schema for a collection of items • Semantic annotation of Web services • Semantic search • Ontology is used as a query vocabulary or for query rewriting purposes • Configuration • Ontology defines correct configuration templates

37. Principles for the design of ontologies • Clarity: • To communicate the intended meaning of defined terms • Coherence: • To sanction inferences that are consistent with definitions • Extendibility: • To anticipate the use of the shared vocabulary • Minimal Encoding Bias: • To be independent of the symbolic level • Minimal Ontological Commitments: • To make as few claims as possible about the world Gruber, T.; TowardsPrinciplesfortheDesignofOntologies. KSL-93-04. Knowledge Systems Laboratory. Stanford University. 1993

38. Clarity An ontology should communicate effectively the intended meaning of defined terms. Definitions should be objective. Definitions can be stated on formal axioms, and a complete definition (defined by necessary and sufficient conditions) is preferred over a partial definition (defined by only necessary or sufficient conditions)…

39. Minimal Encoding Bias The conceptualization should be specified at the knowledge level without depending on a particular symbol-level encoding. (define-class Travel (?travel) "A journey from place to place" :axiom-def (and (Superclass-Of Travel Flight) (Subclass-Of Travel Thing) (Template-Facet-Value Cardinality arrivalDate Travel 1) (Template-Facet-Value Cardinality departureDate Travel 1) (Template-Facet-Value Maximum-Cardinality singleFare Travel 1)) :iff-def (and (arrivalDate ?travel Date) (departureDate ?travel Date)) :def (and (singleFare ?travel Number) (companyName ?travel String))) No minimal encoding bias

40. Euro Currency Dimension Minimal Encoding Bias (singleFare ?travel Number) should be substituted by: (singleFare ?travel CurrencyQuantity) Standard-UnitsOntology Ampere Amu Angstrom . . . Volt Watt Year Instance-of Physical-Quantities Ontology Standard-Dimensions Ontology Unit-of-Measure Instance-of .... Density-Dimension .... Frequency-Dimension .... Length-Dimension Mass-Dimension .... Pressure-Dimension Resistance-Dimension ...... Work-Dimension Subclass-of Instance-of Instance-of Ampere Candela Degree-Kelvin Identity-Unit Kilogram Meter Mole Second-of-Time System-of-Units Si-Unit Instance-of Physical-Dimension Instance-of Instance-of

41. Extensibility One should be able to define new terms for special uses based on the existing vocabulary, in a way that does not require the revision of the existing definitions. • Currencydimension • Definition of currencies • Relationshipbetweencurrencies (define-individual Euro (Unit-of-Measure) “Euro is the currency on the European Union" := (* 0,96 USDollar) :axiom-def (= (Quantity.dimension Euro) CurrencyDimension))

42. Coherence An ontology should be coherent: that is, it should sanction inferences that are consistent with the definitions.[…] If a sentence that can be inferred from the axioms contradicts a definition or example given informally, then the ontology is incoherent.

43. Ontological Commitments • Agreements to use the vocabulary in a coherent and consistent manner (Gruber) • An agent commits (conforms) to an ontology if it “acts” consistently with the definitions • Connection between the ontology vocabulary and the meaning of the terms of such vocabulary

44. What is ontology engineering? • “the set of activities that concern the ontology development process, the ontology life cycle, and the methodologies, tools and languages for building ontologies” Gomez-Perez et al, 2004

45. Ontology life cycle Project management: controlling, planing, qualityassurance etc. Documentation Evaluation Knowledge acquisition Domain analysismotivating scenarios, competency questions, existing solutions Conceptualization conceptualization of the model, integration and extension of existing solutions Implementationimplementation of the formal model in a representation language Usage/Maintenance adaptation of the ontology according to new requirements

46. Ontology engineering activities

47. Methodologies for building ontologies • Validated guidelines on how the ontology building process should be structured • Well-organized process instead of „ontology development driven by inspiration and intuition only“ • Methodologies do not support all of the aforementioned activities • They implicitly assume a particular development paradigm for the ontology engineering process • Some of them also provide supporting methods and tools

48. Collaborative ontology engineering • Two or more people interact and exchange knowledge in order to build a common, shared ontology in pursuit of a shared, collective, bounded goal. • Interaction may be indirect but required. • Argumentation as a common interaction means. • Simple contributions not enough. • Bounded goal: beginning and end. • Collaborators may have individual goals.

49. Uschold and King Methodology • Identify purpose • Build ontology • Capture • Coding • Integrating • Evaluation • Documentation

50. Grüninger and Fox Methodology • Identify motivating scenarios • Elaborate informal competency questions • Specify terminology in FOL • Identify objects • Identify predicates • Formal competency questions • Specify axioms in FOL • Specify completeness theorems