22 owl section 1

525 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
525
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

22 owl section 1

  1. 1. OWL Representing Information Using the Web Ontology Language
  2. 2. 1 Current Web • Publishing medium • Dominated by HTML ▫ Hyper Text Markup Language • Pages accessible using URLs ▫ Uniform Resource Locators ▫ http://www.w3.org/ • Supports human readers using browsers
  3. 3. 1.1 Current Web History • Internet infrastructure created by DARPA • Mostly text-based (telnet, ftp, gopher) • 1992: Tim Berners-Lee/CERT developed ▫ HTML & HTTP (Hyper Text Transfer Protocol) ▫ Web browser (Mosaic) • Allows anyone to publish structured documents connected by hyperlinks • Combined with TCP/IP and XML (eXtensible Markup Language) to create “killer app”
  4. 4. 1.3 The Web is Not Enough • Not enough structure to support computer processing of content • No way to connect information to enable complex queries • HTML too focused on format/display • Need to add markup to explain meaning (semantics) • Semantics will enable automated interpretation of structured web content
  5. 5. 1.3.1 Information Structure • HTML documents ▫ Semi-structured formatting ▫ Unstructured text • Natural Language Processing (NLP) ▫ Improving, but impractical on a large scale • Structured database information must be shared in a computer-parseable maner • Goal: allow automated software agents to mine the web, creating new functionality
  6. 6. 1.3.2 Finding Requires Metadata  “Find the cheapest Key lime pie within 5 miles.” • Keyword-based search engines ▫ Find pages that might contain desired content ▫ Don’t provide answers to questions…the goal! ▫ Have to find local restaurants, then look at their menus • Query engines aim to answer questions ▫ Should be able to filter restaurants within 5 miles, access menus, compare prices, get answer ▫ Show how answer gotten from reliable sources
  7. 7. 1.3.3 Semantics Must Be Explicit • Providing semantic information explicitly in documents enables software to: ▫ Manipulate information (filter, summarize) ▫ Infer new facts (inference) ▫ Link multiple distributed information representations (semantic join)
  8. 8. 2.2.2.1 Structured Representations • Computers need ▫ Consistently structured information collections ▫ Inference rules to conduct automated reasoning ▫ Representations formal enough to detect inconsistencies and errors ▫ Network-distributed information to support scalability
  9. 9. 2.2.2.2 Supporting Language • Need a tagged markup language to provide ▫ Syntax  Language format rules; open & vendor-neutral ▫ Semantics  Meaning of concepts; formal, finite, & extensible ▫ Expressiveness  Richness; able to express concepts & relationships  Completeness, correctness, & efficiency (hardest!) ▫ Standards  Common language for all
  10. 10. 2.2.3 Compromise • Must balance need for structure with need for human-friendly data representations ▫ True natural language processing not yet ready ▫ Humans don’t like to process raw structured data • Proposed solution ▫ Humans must augment content with markup ▫ Must show an ROI payoff for extra effort
  11. 11. 2.3 Semantic Web to the Rescue • Next evolutionary generation of the web ▫ Structured information representations provide explicit meaning ▫ Information “marked up” according to language standards ▫ Software provides new functionality by interpreting, exchanging, & processing meaning • Technologies focus on information representations tied to explicit meaning
  12. 12. 2.3.1 Semantic Web History • Term coined by Sir Tim Berners-Lee • US Dept of Defense/DARPA created DAML ▫ DARPA Agent Markup Language ▫ Helped define critical concepts • European Union created OIL ▫ Ontology Interface Layer ▫ Combined with DAML to create DAML+OIL • W3C built on DAML+OIL to create OWL ▫ Web Ontology Language (yes, it’s out of order) ▫ First draft approved February 2004
  13. 13. 2.3.2 Semantic Web Vision • Next generation of the web • Vast object-oriented integrated knowledge base that can be accessed and inferenced via machine-understandable schemas • Transparent to the end-user • Link documents and the information in them • Leverage the current web infrastructure • Reduce the cost of performing tasks
  14. 14. 2.3.4 Use Cases • Tactical level functionality ▫ Lower-level functions & basic operations ▫ Behind the scenes • Strategic applications ▫ Higher-level compositions of tactical features ▫ Provide more complex functionality ▫ Customer-facing
  15. 15. 2.3.4.1 Tactical Services • Describe distributed information ▫ Harvest content, process, & exchange results • Support queries ▫ Answer questions & explain reasoning • Support searching ▫ Find information based on meaning, not keywords • Support inferring ▫ Drawing conclusions from explicit facts ▫ Reduces size & complexity of knowledge bases
  16. 16. 2.3.4.2 Strategic Applications • Vertical applications ▫ Provide specialized services to a particular domain ▫ E-commerce (B2B, B2C) • Agent software ▫ Autonomous; mobile; architecture-independent ▫ Find & interpret information, act, report results • Information management ▫ Migrate intelligence from the software to the data ▫ Provide new functionality without modifying code ▫ Integrate repositories
  17. 17. 2.3.5 Appropriate Applications • Semantic web applications appropriate to: ▫ Publish content for both humans and computers ▫ Share information without understanding model ▫ Inferring new facts & joining information sources • Characteristics of good candidate domains: ▫ Well-understood but dynamic domain ▫ Heterogeneous information sources ▫ Existing information interchange requirements • Not suited to binary data, e.g. image processing
  18. 18. Chapter 3
  19. 19. 3.1 Ontology Definitions • Historical definition ▫ Studies of the science of being, and the nature and organization of reality ▫ Definitive classifications of objects & their relationships • Other definitions ▫ Computer science definition ▫ Types of ontologies ▫ Gruber definition ▫ OWL-specific ontology definitions
  20. 20. 3.1.1 Computer Science Definition • Popularized by AI community • Tbox ▫ Terminogical components ▫ Equivalent to “schema” ▫ Define concepts ▫ Semantic Web equivalent  Ontology • Abox ▫ Assertional components ▫ Equivalent to “records” ▫ Assert facts ▫ Semantic Web equivalent  Individuals
  21. 21. 3.1.2 Types of Ontologies • Many types ▫ Domain ontologies ▫ Metadata ontologies (Dublin Core) ▫ Method/task ontologies • Many ways to classify ontologies ▫ Formality ▫ Regularity ▫ Expressiveness • Simplest ontology: Taxonomy ▫ Hierarchy of concepts related with IS-A relationship ▫ Can’t express complex relationships
  22. 22. 3.1.3 Gruber Definition • “Formal specification of a conceptualization” – T. Gruber • An ontology is a ▫ Formally-described ▫ Machine-readable ▫ Collection of terms & their relationships ▫ Expressed in a language ▫ Stored in a file
  23. 23. 3.1.4 OWL-Specific Ontology Def’n • Web Ontology Language (OWL) ontology ▫ “An OWL-encoded, web-distributed vocabulary of declarative formalisms describing a model of a domain” • Domain ▫ A specific subject area or area of knowledge ▫ Typically the focus of a particular community of interest • Encode a model of the domain, not all of it
  24. 24. 3.2 Ontology Features • Communicate a common understanding of a domain • Example: restaurant association describes relationships between food items • Declare explicit semantics • Make assumptions explicit • Reduce ambiguity • Make expressive statements • Have reasoning properties to support scalable, decidable inferencing • Support sharing of information • Allow semantic mapping between information sources
  25. 25. 3.3 Ontology Development Issues • Authoring ontologies ▫ Can be developed by anyone, but ▫ Better if developed by consensus-based standards development groups ▫ Vertical ontologies describe a domain ▫ Horizontal ontologies span domains and describe basic concepts • Separating ontologies from individuals ▫ Usually a good idea ▫ Sometimes not possible • Committing to an ontology ▫ Makes applications easier to understand, modify, reuse
  26. 26. 3.4 Describing Semantics • Defining information representation building blocks • Describing relationships between building blocks • Describing relationships within building blocks
  27. 27. 3.4.1 Building Blocks • Three basic blocks ▫ Class constructs ▫ Property constructs ▫ Individual constructs • Together, they describe a model of a domain • Each type requires ▫ A computer-understandable representation ▫ Identifiers for referencing these representations
  28. 28. 3.4.1.1 Class Construct • Similar to ▫ “Class” in OO terminology ▫ “Table” in relational DB terminology • Group or set of objects with similar properties or characteristics (explicit or implicit) in common • General statements can be made that apply to all members of the class • Examples ▫ Food ▫ Menu Item ▫ Person
  29. 29. 3.4.1.2 Property Construct • Similar to ▫ “Accessor method” in OO terminology ▫ “Columns” or “fields” in relational DB terms • Binary association that relates an object (instance) to a value • Examples ▫ Price ▫ Size • Unlike OO accessors, properties can be associated with multiple unrelated classes!
  30. 30. 3.4.1.3 Individuals • Similar to ▫ “Objects” in OO terminology ▫ “Rows” or “records” in relational DB terminology • Represent class object instances in the domain ▫ Physical things ▫ Virtual concepts • Unlike objects, Individuals have no functionality • Examples ▫ KnightOwlRestaurant ▫ Order456 • Difference b/w individuals & classes not always clear • Literal values (“1”, “A”) are special case of individuals
  31. 31. 3.4.2 Relating Constructs • Need to describe relationships between building blocks • “is an instance of” ▫ Individual to Class • “has value for” ▫ Individual to Property • Restrictions ▫ Between Class and Property
  32. 32. 3.4.2.1 Relate Individuals & Classes • Individuals are members of classes • “Membership” or “is an instance of” relationship • Must be explicitly stated • Examples ▫ “KnightOwlRestaurant” is an instance of “Restaurant” class ▫ “Mark” is an instance of “Person” class
  33. 33. 3.4.2.2 Relate Individuals & Properties • Individuals have attributes described by properties • “has value for” relationship • Example ▫ “KeyLimePie” individual has value “$2” for the property “price” ▫ “Mark” individual has value “34” for the property “age”
  34. 34. 3.4.2.3 Relate Classes & Properties • Classes can restrict use of Properties in individuals ▫ “IsBrotherOf” property range restricted to “Male”s • Properties can be used to define Classes by defining membership in the class ▫ Individual is member of class “Boy” iff Individual is in “Male” class and “Age” property value <= 18. • Restrictions can constrain Property values ▫ To be of a certain class (range) ▫ To only describe particular classes (domain)
  35. 35. 3.4.3 Semantic Relationships in Blocks • Must be able to describe semantic relationships within classes, properties, and individuals • Synonymy • Antonymy • Hyponymy • Meronymy
  36. 36. 3.4.3.1 Synonymy Relation • Connects concepts with similar meaning ▫ equals() in Java – same meaning, different instance • Stricter form is equivalence (identical) ▫ == in Java – same instance • Class to Class ▫ Noodles & Pasta; Soda & Pop • Instance to Instance ▫ Knight Owl Restaurant & franchiseProperty123 • Property to Property ▫ Cost & Price • Allows merging concepts & linking heterogeneous knowledge bases =
  37. 37. 3.4.3.2 Antonymy Relation • Opposite meaning • Stricter form is disjointness • Establishes dichotomy of meaning b/w terms • Class to Class ▫ Regular Price Menu Item & Sale Price Menu Item • Instance to Instance • Property to Property ≠
  38. 38. 3.4.3.3 Hyponymy Relation • Specialization & generalization • Creates taxonomic hierarchies • Also called ▫ “is-a” ▫ “inheritance” ▫ “subsumption” • Transitive downward • Better for permanent relationships • Class to Class ▫ Spaghetti “is-a” Pasta ▫ New York Style Pizzeria “is-a” Italian Restaurant “is-a” Restaurant • Property to Property ▫ salePrice “is-a” price Δ
  39. 39. Meronymy/Hyponymy Relation • Aggregation & composition • Also called ▫ “part-of” ▫ “component of” • Mereology (part-whole theory) • Holonymy (whole-part theory) • Closely related to “ownership” • Transitive downward • Class to Class ▫ Meatball “part-of” Spaghetti and Meatballs Dish ▫ Fork “part-of” Place Setting • Individual to individual ▫ Drink Order 321 “part-of” Restaurant Bill 789
  40. 40. 3.4.4 Semantics Summary • Building Blocks • Relationships Construct Description A group or set of individual objects with similar characteristics Associates attrib/value pairs with individuals, restricts classes Represents a specific instance object of a class Functionality Relationship Summary Relating blocks to each other Individuals to Classes Membership Individuals to Properties Attribute values Classes to Properties Restrictions Describing relationships Synonymy Similarities Antonymy Differences Hyponymy Specialization Meronymy Part/whole Holonymy Whole/Part
  41. 41. 3.5 Ontology Languages • Formal, parseable, & usable by software • Define semantics in context-independent way • Support some level of logic expression • OWL based on: ▫ Frame-based systems ▫ Description logics
  42. 42. 3.5.1 Frame-based Systems • Modeling primitives called “frames” (classes) • Properties (attributes) are called “slots” • Property values are called “fillers” • Same slot name usable with different classes ▫ Can specify different range & value restrictions
  43. 43. 3.5.2 Description Logics (DLs) • Modeling primitives called “concepts” (classes) • Properties (attributes) are called “roles” • DLs also called “terminological logics” or “concept languages” • Balance expressiveness with “decidability” ▫ Whether software can reach a conclusion or not • DL concepts defined by their objects’ membership constraints ▫ Used to automatically derive classification taxonomies (hierarchies)
  44. 44. 3.5.2 Descriptions Logics cont’d • DLs can specify ▫ Class constructors ▫ Property constructors ▫ Axioms relating classes & properties • Allow composite descriptions ▫ E.g. restrictions on relationships between objects • Use first-order logic • Still decidable • Support efficient inferencing
  45. 45. 3.6 Ontologies Summary • Various definitions (AI, Gruber, OWL) • Purposes ▫ Communicate specification of domain ▫ Declare explicit semantics ▫ Support information sharing • Different types; taxonomies most common • Divided into Tbox & Abox ▫ Tbox: schema, definitions of concepts ▫ Abox: records, defintions of individuals/objects
  46. 46. 3.6 Ontologies Summary cont’d • Building blocks ▫ Class, Property, Individual • Relationships between different block types ▫ Membership, Attribute Values, Restrictions • Relationships between same block types ▫ Synonomy, Antonymy, Hyponymy, Meronymy, Holonymy • Ontologies described using formal languages
  47. 47. Chapter 4
  48. 48. 4.1 OWL Features • Primary goals ▫ Intuitive for humans, minimal investment ▫ Expressive, with explicit semantics for software • Can define and/or extend ontologies • Supports scalability (needs some work) • XML-based annotations • Makes statements/assertions about classes, properties, & individuals • Additional facts derived via inferencing
  49. 49. 4.2 Layered Architecture Applications } Implementation Layer Ontology Languages (OWL Full, OWL DL, and OWL Lite) } Logical Layer RDF Schema Individuals } Ontological Primitive Layer RDF and RDF/XML } Basic Relational Language Layer XML and XMLS Datatypes } Transport/Syntax Layer URIs and Namespaces } Symbol/Reference Layer
  50. 50. 4.4 OWL Introduction Summary • Web Ontology Language (OWL) ▫ Defined by the W3C ▫ Used to make statements about  Classes  Properties  Individuals ▫ Designed as a layered architecture built on  URIs & Namespaces  XML & XMLS  RDF & RDFS
  51. 51. Backup – Entire slide set
  52. 52. OWL Representing Information Using the Web Ontology Language
  53. 53. Section 1
  54. 54. Section 1 • Chapter 1: Historical Web ▫ Web history, context, features, & shortcomings • Chapter 2: Semantic Web ▫ Challenges, requirements, & solutions • Chapter 3: Ontologies ▫ Concepts, purposes, relationships, features, & languages • Chapter 4: OWL Introduction ▫ OWL language, layered architecture, & supporting technologies
  55. 55. Chapter 1
  56. 56. 1 Current Web • Publishing medium • Dominated by HTML ▫ Hyper Text Markup Language • Pages accessible using URLs ▫ Uniform Resource Locators ▫ http://www.w3.org/ • Supports human readers using browsers
  57. 57. 1.1 Current Web History • Internet infrastructure created by DARPA • Mostly text-based (telnet, ftp, gopher) • 1992: Tim Berners-Lee/CERT developed ▫ HTML & HTTP (Hyper Text Transfer Protocol) ▫ Web browser (Mosaic) • Allows anyone to publish structured documents connected by hyperlinks • Combined with TCP/IP and XML (eXtensible Markup Language) to create “killer app”
  58. 58. 1.2 Current Web Characteristics • Features • Benefits • Applications
  59. 59. 1.2.1 Current Web Features • Diverse • Document-centric • Virtual repository of information • No controlling authority • Managed by open standards from W3C ▫ World Wide Web Consortium • Intended for human access & reading
  60. 60. 1.2.2 Current Web Benefits • Superior to private networks • Transactions are cheaper (self-service) • Cheap to communicate world-wide • Created online communities ▫ Open-source movement – free high-quality tools ▫ Countless online forums
  61. 61. 1.2.3 Current Web Applications • Most content designed for humans • Variety of purposes ▫ E-commerce ▫ Education ▫ Financial services ▫ Auctions ▫ Music • Many sites use generated HTML & XML generated from databases
  62. 62. 1.3 The Web is Not Enough • Not enough structure to support computer processing of content • No way to connect information to enable complex queries • HTML too focused on format/display • Need to add markup to explain meaning (semantics) • Semantics will enable automated interpretation of structured web content
  63. 63. 1.3.1 Information Structure • HTML documents ▫ Semi-structured formatting ▫ Unstructured text • Natural Language Processing (NLP) ▫ Improving, but impractical on a large scale • Structured database information must be shared in a computer-parseable maner • Goal: allow automated software agents to mine the web, creating new functionality
  64. 64. 1.3.2 Finding Requires Metadata  “Find the cheapest Key lime pie within 5 miles.” • Keyword-based search engines ▫ Find pages that might contain desired content ▫ Don’t provide answers to questions…the goal! ▫ Have to find local restaurants, then look at their menus • Query engines aim to answer questions ▫ Should be able to filter restaurants within 5 miles, access menus, compare prices, get answer ▫ Show how answer gotten from reliable sources
  65. 65. 1.3.3 Semantics Must Be Explicit • Providing semantic information explicitly in documents enables software to: ▫ Manipulate information (filter, summarize) ▫ Infer new facts (inference) ▫ Link multiple distributed information representations (semantic join)
  66. 66. 1.4 Current Web Summary • Current Web ▫ Document-centric ▫ Focused on humans using browsers ▫ Insufficient for automated data processing • New technologies needed ▫ Structure information for automated processing ▫ Improve searches ▫ Link disparate data sources with each other • The Semantic Web!
  67. 67. Chapter 2
  68. 68. 2 Semantic Web Introduction • Web information representation challenges • Requirements for a solution • Semantic Web concepts that satisfy those requirements
  69. 69. 2.1 Web Information Representation Challenges • Increased Need for Information Representation • Ambiguous Human Descriptions • Software Demands for Specificity
  70. 70. 2.1.1 Information Representation • Volume of information increasing exponentially • User expectations of the Internet also growing • To satisfy expectations, we need more than just HTML, XML & databases
  71. 71. 2.1.2 Ambiguous Descriptions • Many human information formats ▫ Specialized domains with unique terminology ▫ Regional language differences ▫ Many sublanguages within communities ▫ Difficult to get consensus • Language agreement impossible • Meta-language agreement possible ▫ Language to express language • We need a language that can represent information from many domains
  72. 72. 2.1.3 Demands for Specificity • Computers need information to be ▫ Structured ▫ Consistent ▫ Well-formed ▫ Logical
  73. 73. 2.2 Requirements for a Solution • Minimize Human Investment • Satisfy Computer Requirements • Compromise between these goals
  74. 74. 2.2.1 Minimize Human Investment • Information Representation Producers • Information Representation Consumers • Requirements common to both
  75. 75. 2.2.1.1 Representation Producers • Provide content from existing sources • Aim to generate information representations ▫ Quickly ▫ Effectively ▫ Inexpensively • Represent data using natural models that are ▫ Extendable ▫ Versionable ▫ Configuration-managed
  76. 76. 2.2.1.2 Representation Consumers • Aim to create software to ▫ Parse information ▫ Interpret information ▫ Manipulate information • Software should be able to ▫ Combine information from different domains ▫ Use others’ data without needing to understand the underlying data model ▫ Reduce human intervention
  77. 77. 2.2.1.3 Requirements Common to Both • Solution must be ▫ Inexpensive ▫ Easy to implement ▫ Intuitive ▫ Evolutionary, not revolutionary ▫ Compatible with existing web standards
  78. 78. 2.2.2 Satisfy Computer Requirements • Structured distributed representations to enable applications • Supporting language
  79. 79. 2.2.2.1 Structured Representations • Computers need ▫ Consistently structured information collections ▫ Inference rules to conduct automated reasoning ▫ Representations formal enough to detect inconsistencies and errors ▫ Network-distributed information to support scalability
  80. 80. 2.2.2.2 Supporting Language • Need a tagged markup language to provide ▫ Syntax  Language format rules; open & vendor-neutral ▫ Semantics  Meaning of concepts; formal, finite, & extensible ▫ Expressiveness  Richness; able to express concepts & relationships  Completeness, correctness, & efficiency (hardest!) ▫ Standards  Common language for all
  81. 81. 2.2.3 Compromise • Must balance need for structure with need for human-friendly data representations ▫ True natural language processing not yet ready ▫ Humans don’t like to process raw structured data • Proposed solution ▫ Humans must augment content with markup ▫ Must show an ROI payoff for extra effort
  82. 82. 2.3 Semantic Web to the Rescue • Next evolutionary generation of the web ▫ Structured information representations provide explicit meaning ▫ Information “marked up” according to language standards ▫ Software provides new functionality by interpreting, exchanging, & processing meaning • Technologies focus on information representations tied to explicit meaning
  83. 83. 2.3.1 Semantic Web History • Term coined by Sir Tim Berners-Lee • US Dept of Defense/DARPA created DAML ▫ DARPA Agent Markup Language ▫ Helped define critical concepts • European Union created OIL ▫ Ontology Interface Layer ▫ Combined with DAML to create DAML+OIL • W3C built on DAML+OIL to create OWL ▫ Web Ontology Language (yes, it’s out of order) ▫ First draft approved February 2004
  84. 84. 2.3.2 Semantic Web Vision • Next generation of the web • Vast object-oriented integrated knowledge base that can be accessed and inferenced via machine-understandable schemas • Transparent to the end-user • Link documents and the information in them • Leverage the current web infrastructure • Reduce the cost of performing tasks
  85. 85. 2.3.3 Populating the Semantic Web • Developing representation standards ▫ Scope the domain/analyze requirements ▫ Define terms and relationships ▫ Encode vocabulary & relationships (ontology) ▫ Publish representation on servers • Requires significant up-front effort, but • Yields greater returns than current solutions • Cost reduces as reuse grows
  86. 86. 2.3.4 Use Cases • Tactical level functionality ▫ Lower-level functions & basic operations ▫ Behind the scenes • Strategic applications ▫ Higher-level compositions of tactical features ▫ Provide more complex functionality ▫ Customer-facing
  87. 87. 2.3.4.1 Tactical Services • Describe distributed information ▫ Harvest content, process, & exchange results • Support queries ▫ Answer questions & explain reasoning • Support searching ▫ Find information based on meaning, not keywords • Support inferring ▫ Drawing conclusions from explicit facts ▫ Reduces size & complexity of knowledge bases
  88. 88. 2.3.4.2 Strategic Applications • Vertical applications ▫ Provide specialized services to a particular domain ▫ E-commerce (B2B, B2C) • Agent software ▫ Autonomous; mobile; architecture-independent ▫ Find & interpret information, act, report results • Information management ▫ Migrate intelligence from the software to the data ▫ Provide new functionality without modifying code ▫ Integrate repositories
  89. 89. 2.3.5 Appropriate Applications • Semantic web applications appropriate to: ▫ Publish content for both humans and computers ▫ Share information without understanding model ▫ Inferring new facts & joining information sources • Characteristics of good candidate domains: ▫ Well-understood but dynamic domain ▫ Heterogeneous information sources ▫ Existing information interchange requirements • Not suited to binary data, e.g. image processing
  90. 90. 2.4 Semantic Web Intro Summary • Existing challenges ▫ Humans want information in readable formats ▫ Computers need structured formats ▫ Solution must minimize human investment, but meet computer needs • Semantic web is the solution ▫ Builds on the existing web ▫ Supplies new information representation features ▫ Presents information understandable to both
  91. 91. Chapter 3
  92. 92. 3 Ontologies Enable the Semantic Web • Ontology definitions • Development issues • Description methods • Ontology features • Language issues
  93. 93. 3.1 Ontology Definitions • Historical definition ▫ Studies of the science of being, and the nature and organization of reality ▫ Definitive classifications of objects & their relationships • Other definitions ▫ Computer science definition ▫ Types of ontologies ▫ Gruber definition ▫ OWL-specific ontology definitions
  94. 94. 3.1.1 Computer Science Definition • Popularized by AI community • Tbox ▫ Terminogical components ▫ Equivalent to “schema” ▫ Define concepts ▫ Semantic Web equivalent  Ontology • Abox ▫ Assertional components ▫ Equivalent to “records” ▫ Assert facts ▫ Semantic Web equivalent  Individuals
  95. 95. 3.1.2 Types of Ontologies • Many types ▫ Domain ontologies ▫ Metadata ontologies (Dublin Core) ▫ Method/task ontologies • Many ways to classify ontologies ▫ Formality ▫ Regularity ▫ Expressiveness • Simplest ontology: Taxonomy ▫ Hierarchy of concepts related with IS-A relationship ▫ Can’t express complex relationships
  96. 96. 3.1.3 Gruber Definition • “Formal specification of a conceptualization” – T. Gruber • An ontology is a ▫ Formally-described ▫ Machine-readable ▫ Collection of terms & their relationships ▫ Expressed in a language ▫ Stored in a file
  97. 97. 3.1.4 OWL-Specific Ontology Def’n • Web Ontology Language (OWL) ontology ▫ “An OWL-encoded, web-distributed vocabulary of declarative formalisms describing a model of a domain” • Domain ▫ A specific subject area or area of knowledge ▫ Typically the focus of a particular community of interest • Encode a model of the domain, not all of it
  98. 98. 3.2 Ontology Features • Communicate a common understanding of a domain • Declare explicit semantics • Make expressive statements • Support sharing of information
  99. 99. 3.2.1 Domain Understanding • Provided by communities of interest ▫ Example: restaurant association describes relationships between food items • Ontology formally documents one common understanding of a domain ▫ Reduces misunderstanding • Shared and common understanding communicated between humans and software systems
  100. 100. 3.2.2 Explicit Semantics • Semantics ▫ Formal descriptions of terms and relationships ▫ Traditionally coded into the software or schema ▫ Document concepts using modeling primitives and semantic relationships ▫ Make assumptions explicit ▫ Reduce ambiguity ▫ Enable interoperability • Must be described formally to be processed
  101. 101. 3.2.3 Expressiveness • “Extensiveness” of the ontology • Must be expressive enough to ▫ Represent formal semantics ▫ Have reasoning properties to support inferencing • Support canonical granular representations • Limited to keep reasoning ▫ Decidable ▫ Scaleable
  102. 102. 3.2.4 Sharing Information • OWL-compliant software can ▫ Manipulate information internally ▫ Interoperate with other software ▫ Do semantic mapping between information sources • Need to have a shared language and access to information
  103. 103. 3.3 Ontology Development Issues • Authoring ontologies ▫ Can be developed by anyone, but ▫ Better if developed by consensus-based standards development groups ▫ Vertical ontologies describe a domain ▫ Horizontal ontologies span domains and describe basic concepts • Separating ontologies from individuals ▫ Usually a good idea ▫ Sometimes not possible • Committing to an ontology ▫ Makes applications easier to understand, modify, reuse
  104. 104. 3.4 Describing Semantics • Defining information representation building blocks • Describing relationships between building blocks • Describing relationships within building blocks
  105. 105. 3.4.1 Building Blocks • Three basic blocks ▫ Class constructs ▫ Property constructs ▫ Individual constructs • Together, they describe a model of a domain • Each type requires ▫ A computer-understandable representation ▫ Identifiers for referencing these representations
  106. 106. 3.4.1.1 Class Construct • Similar to ▫ “Class” in OO terminology ▫ “Table” in relational DB terminology • Group or set of objects with similar properties or characteristics (explicit or implicit) in common • General statements can be made that apply to all members of the class • Examples ▫ Food ▫ Menu Item ▫ Person
  107. 107. 3.4.1.2 Property Construct • Similar to ▫ “Accessor method” in OO terminology ▫ “Columns” or “fields” in relational DB terms • Binary association that relates an object (instance) to a value • Examples ▫ Price ▫ Size • Unlike OO accessors, properties can be associated with multiple unrelated classes!
  108. 108. 3.4.1.3 Individuals • Similar to ▫ “Objects” in OO terminology ▫ “Rows” or “records” in relational DB terminology • Represent class object instances in the domain ▫ Physical things ▫ Virtual concepts • Unlike objects, Individuals have no functionality • Examples ▫ KnightOwlRestaurant ▫ Order456 • Difference b/w individuals & classes not always clear • Literal values (“1”, “A”) are special case of individuals
  109. 109. 3.4.2 Relating Constructs • Need to describe relationships between building blocks • “is an instance of” ▫ Individual to Class • “has value for” ▫ Individual to Property • Restrictions ▫ Between Class and Property
  110. 110. 3.4.2.1 Relate Individuals & Classes • Individuals are members of classes • “Membership” or “is an instance of” relationship • Must be explicitly stated • Examples ▫ “KnightOwlRestaurant” is an instance of “Restaurant” class ▫ “Mark” is an instance of “Person” class
  111. 111. 3.4.2.2 Relate Individuals & Properties • Individuals have attributes described by properties • “has value for” relationship • Example ▫ “KeyLimePie” individual has value “$2” for the property “price” ▫ “Mark” individual has value “34” for the property “age”
  112. 112. 3.4.2.3 Relate Classes & Properties • Classes can restrict use of Properties in individuals ▫ “IsBrotherOf” property range restricted to “Male”s • Properties can be used to define Classes by defining membership in the class ▫ Individual is member of class “Boy” iff Individual is in “Male” class and “Age” property value <= 18. • Restrictions can constrain Property values ▫ To be of a certain class (range) ▫ To only describe particular classes (domain)
  113. 113. 3.4.3 Semantic Relationships in Blocks • Must be able to describe semantic relationships within classes, properties, and individuals • Synonymy • Antonymy • Hyponymy • Meronymy
  114. 114. 3.4.3.1 Synonymy Relation • Connects concepts with similar meaning ▫ equals() in Java – same meaning, different instance • Stricter form is equivalence (identical) ▫ == in Java – same instance • Class to Class ▫ Noodles & Pasta; Soda & Pop • Instance to Instance ▫ Knight Owl Restaurant & franchiseProperty123 • Property to Property ▫ Cost & Price • Allows merging concepts & linking heterogeneous knowledge bases =
  115. 115. 3.4.3.2 Antonymy Relation • Opposite meaning • Stricter form is disjointness • Establishes dichotomy of meaning b/w terms • Class to Class ▫ Regular Price Menu Item & Sale Price Menu Item • Instance to Instance • Property to Property ≠
  116. 116. 3.4.3.3 Hyponymy Relation • Specialization & generalization • Creates taxonomic hierarchies • Also called ▫ “is-a” ▫ “inheritance” ▫ “subsumption” • Transitive downward • Better for permanent relationships • Class to Class ▫ Spaghetti “is-a” Pasta ▫ New York Style Pizzeria “is-a” Italian Restaurant “is-a” Restaurant • Property to Property ▫ salePrice “is-a” price Δ
  117. 117. Meronymy/Hyponymy Relation • Aggregation & composition • Also called ▫ “part-of” ▫ “component of” • Mereology (part-whole theory) • Holonymy (whole-part theory) • Closely related to “ownership” • Transitive downward • Class to Class ▫ Meatball “part-of” Spaghetti and Meatballs Dish ▫ Fork “part-of” Place Setting • Individual to individual ▫ Drink Order 321 “part-of” Restaurant Bill 789
  118. 118. 3.4.4 Semantics Summary • Building Blocks • Relationships Construct Description A group or set of individual objects with similar characteristics Associates attrib/value pairs with individuals, restricts classes Represents a specific instance object of a class Functionality Relationship Summary Relating blocks to each other Individuals to Classes Membership Individuals to Properties Attribute values Classes to Properties Restrictions Describing relationships Synonymy Similarities Antonymy Differences Hyponymy Specialization Meronymy Part/whole Holonymy Whole/Part
  119. 119. 3.5 Ontology Languages • Formal, parseable, & usable by software • Define semantics in context-independent way • Support some level of logic expression • OWL based on: ▫ Frame-based systems ▫ Description logics
  120. 120. 3.5.1 Frame-based Systems • Modeling primitives called “frames” (classes) • Properties (attributes) are called “slots” • Property values are called “fillers” • Same slot name usable with different classes ▫ Can specify different range & value restrictions
  121. 121. 3.5.2 Description Logics (DLs) • Modeling primitives called “concepts” (classes) • Properties (attributes) are called “roles” • DLs also called “terminological logics” or “concept languages” • Balance expressiveness with “decidability” ▫ Whether software can reach a conclusion or not • DL concepts defined by their objects’ membership constraints ▫ Used to automatically derive classification taxonomies (hierarchies)
  122. 122. 3.5.2 Descriptions Logics cont’d • DLs can specify ▫ Class constructors ▫ Property constructors ▫ Axioms relating classes & properties • Allow composite descriptions ▫ E.g. restrictions on relationships between objects • Use first-order logic • Still decidable • Support efficient inferencing
  123. 123. 3.6 Ontologies Summary • Various definitions (AI, Gruber, OWL) • Purposes ▫ Communicate specification of domain ▫ Declare explicit semantics ▫ Support information sharing • Different types; taxonomies most common • Divided into Tbox & Abox ▫ Tbox: schema, definitions of concepts ▫ Abox: records, defintions of individuals/objects
  124. 124. 3.6 Ontologies Summary cont’d • Building blocks ▫ Class, Property, Individual • Relationships between different block types ▫ Membership, Attribute Values, Restrictions • Relationships between same block types ▫ Synonomy, Antonymy, Hyponymy, Meronymy, Holonymy • Ontologies described using formal languages
  125. 125. Chapter 4
  126. 126. 4 OWL Introduction • OWL Features • Semantic Web’s Layered Architecture
  127. 127. 4.1 OWL Features • Primary goals ▫ Intuitive for humans, minimal investment ▫ Expressive, with explicit semantics for software • Can define and/or extend ontologies • Supports scalability (needs some work) • XML-based annotations • Makes statements/assertions about classes, properties, & individuals • Additional facts derived via inferencing
  128. 128. 4.2 Layered Architecture Applications } Implementation Layer Ontology Languages (OWL Full, OWL DL, and OWL Lite) } Logical Layer RDF Schema Individuals } Ontological Primitive Layer RDF and RDF/XML } Basic Relational Language Layer XML and XMLS Datatypes } Transport/Syntax Layer URIs and Namespaces } Symbol/Reference Layer
  129. 129. 4.2 Layered Architecture cont’d • Layers illustrate rough dependencies ▫ Each layer uses features of lower layers • Implementation Layer ▫ Provides specific applications • Logical Layer ▫ OWL supports formal semantics and reasoning • Ontological Primitive Layer ▫ RDFS defines vocabulary ▫ Individuals defined in RDF RDF Schema Individuals XML and XMLS Datatypes URIs and Namespaces Applications Ontology Languages (OWL Full, OWL DL, and OWL Lite) RDF and RDF/XML
  130. 130. 4.2 Layered Architecture cont’d • Relational Language Layer ▫ RDF’s simple data model & syntax for making statements ▫ Serialized as  RDF/XML or  N-triples • Transport/Syntax Layer ▫ Define primitive datatypes ▫ Provide encoding format • Symbolic/Reference Layer ▫ Identify and reference classes, properties, and individuals RDF Schema Individuals XML and XMLS Datatypes URIs and Namespaces Applications Ontology Languages (OWL Full, OWL DL, and OWL Lite) RDF and RDF/XML
  131. 131. 4.3 Technology Support for Layers • Symbol/Reference Layer ▫ Provides identifiers & references to objects described in ontologies and instance files • Transport/Syntax Layer ▫ XML used to serialize OWL syntax ▫ XMLS defines standard datatypes • Basic Relational Layer ▫ RDF makes statements using Attribute/Value pairs to describe objects
  132. 132. 4.3 Tech Support for Layers, cont’d • Ontological Primitive Layer ▫ RDFS provides basic vocabulary describing  Classes and subclasses  Properties and subproperties ▫ Instances & property values specified by RDF & XMLS • Logical Layer ▫ OWL dialects (Full, DL, Lite) enhance RDFS • Implementation Layer ▫ Applications built using OWL • Additional layers being considered for rules & trust
  133. 133. 4.4 OWL Introduction Summary • Web Ontology Language (OWL) ▫ Defined by the W3C ▫ Used to make statements about  Classes  Properties  Individuals ▫ Designed as a layered architecture built on  URIs & Namespaces  XML & XMLS  RDF & RDFS

×