The document discusses the role of ontologies in modern expert system development. It provides background on expert systems and ontologies, explaining that ontologies define domains of knowledge and are used to encapsulate domain knowledge for use in expert systems. The document outlines the process of developing ontologies, including identifying concepts and relationships in a domain. It also provides an example of an expert system called SINFERS that uses ontologies to select soil property prediction models.
8. The AI Value Proposition Why care about AI/ expert systems at all? By reasoning about information using applied knowledge, expert systems help stakeholders make timely and reliable decisions. => Modern businesses need to make complex decisions. 1 Complex decisions require lots of information and applied knowledge. 2 Such decisions must be made quickly and reliably. 3
9. Market Drivers & Enablers What is driving the apparent renaissance in AI? An incubator for new technologies and a source for new markets – a “killer-app”! 3 INTERNET Dramatic increases in CPU speed, RAM capacity, storage, etc. 1 Hardware Power Mass-production has lowered technology costs. 2 Hardware Cost
10.
11.
12. Linking ES and Ontologies Ontology Ontologies disambiguate meaning. =
16. From the Engineer’s POV Our knowledge engineer would prefer that her project get recognition here… Rather than here.
17.
18. Parlez-Vous AI? “ Instances are the actual data in your knowledge base … If you have to make changes to your class or slot structure after instances have been entered, you may lose some information .” Anything odd about this? From a popular ontology editor help file…
19. Noise Defined as the universe of all possible invariants … … an endless sea of qualitative and quantitative values without a cognitive pattern .
20. Data Noise is filtered and sampled to separate useful measurements (facts) and to form data. Thus, in a sense, data is created via our cognitive attention.
21. Information Data is analyzed and interpreted, to uncover meaning and relationships , producing actionable information. Information aids decisions . x y
22.
23. Declarative Knowledge Rules We can represent them by asserting a fact or facts when certain other facts are present. IF fact(s) THEN assert fact(s) These represent the invariants that can be inferred when one or more invariants hold. Context Invariant(s) Invariants(s) =>
24. Procedural Knowledge Rules These represent the actions to take when certain invariants hold. Context We can represent them by calling functions when certain facts are present. IF fact(s) THEN call function foo Invariant(s) Actions(s) =>
25. Declarative vs. Procedural An example of declarative knowledge. IF (instance-of ?x THING) (composed-of ?x CLAY) (composed-of ?x SAND) (composed-of ?x SILT) THEN (instance-of ?x SOIL) THEN we can compute the soil property IF we have the soil property values An example of procedural knowledge.
26. Ontological Commitment “ An agreement to use a vocabulary (i.e., ask queries and make assertions) in a way that is consistent (but not complete) with respect to the theory specified by an ontology … An agent commits to an ontology if its observable actions are consistent with the definitions in the ontology.” – Tom Gruber
27.
28. The “Bottleneck” Issue Converting Expert Knowledge To Rules Elicitation How can they make each other understand what each knows?
29. Part I: Ontology Fundamentals The How, What, Where, When, and Why of Ontologies
30. Ontological Classes CLASS Represents a “thing” or concept. CLASS FACET 1 FACET m FACET An allowed value for a slot [optional]. SLOT 1 SLOT ( n – 1) SLOT n SLOT A data field within a class. Type is optional.
31. Classes vs. Instances organic_carbon symbol “_6A1” value 0.06 units “kg/kg” stdev 0.01 id 42 Soil Property symbol STRING value FLOAT units STRING stdev STRING id INTEGER
32. Specializing vs. Inheriting CLASS A CLASS B CLASS C Subclassing or extending a parent class, superclass, or base-class CLASS X CLASS Y CLASS Z Inheritance from one or more parent classes
33. Subclass / Inherit Examples Soil Acrisol Vertisol Acrisol and Vertisol are specializations of Soil. Horizon A Horizon B Horizon AB A soil horizon can inherit properties from distinct types.
38. Implied Ontologies (deftemplate soil-property "A fact describing a soil property“ (slot symbol) (slot value) (slot error) (slot units)) Using these templates, what could an expert system reason about implicitly? (deftemplate ptf "A fact describing a pedotransfer function" (slot symbol) (multislot args) (slot value) (slot units))
39. How do ontologies help? Ontologies Semantic Search (Web 2.0) Business Rules General Inferencing Rules Knowledge Layer Entity Relationship Diagrams SQL Queries Data Exchange Data Layer Design Layer OOP Object Models UML Diagrams
40.
41.
42.
43. Problem Solving Methods In “Preliminary Steps Towards a Taxonomy of Problem Solving Methods”, McDermott says… “… In traditional expert systems terminology, a problem-solving method is called an inference engine .” In our case, we are using a rule-engine as our inference engine. So, forward-chaining through rules is our problem-solving method.
45. Ontology Bifurcation Doing this allows developers to make explicit tradeoffs between reusability and granularity of the required domain knowledge. Separates out control and procedural knowledge. Domain Ontology Defines a domain’s set of terms and relations independent of any problem-solving method. Application Ontology Contains terms and relations unique to a particular problem-solving method. Ontology
46.
47.
48. Part II: Ontology Creation How to design and build a domain ontology.
49.
50.
51.
52.
53.
54. Part IV: SINFERS Example Lessons Learned from the Soil Inferencing System (SINFERS) Project
55.
56. SINFERS Design Task PTF Rulebase Working Memory PTF Database Jess Rule Engine Given an initial set, { P } of n soil properties p * rule compute-ptf-p* IF { q }: { q } { P } PTF({q}) THEN compute p * and add to working memory p 1 p 2 p ( n -1) p n
57. SINFERS in Protégé Script Tab Lets you drive the Protégé API via your favorite script engine Jess Tab Lets you write and test Jess rules based on your ontological instances Queries Tab Used to define queries for looking up all instances matching some pattern Instances Tab Used to browse and edit current instances Forms Tab Automatically generates forms for populating the knowledgebase with instances Slots Tab Used to define and edit all slots through out the ontology Class Tab Used to define abstract and concrete ontological classes
61. Famous Ontology Folks Many of their colleagues and students are also great sources of ontology literature. Tom Gruber Deb McGuinness Dieter Fensel
62.
63.
64.
65. The entire archive of ontology papers used in this presentation is available as a ZIP Please ask me or James Owen if you’d like a copy.
66. Thank you all for your kind attention!! 15 Minutes for Questions
Notes de l'éditeur
OPENING REMARKS ============= I’d like to thank James Owens for asking me to speak today – it is an honor and a privilege to present to all of you. Many of the topics that you all will be attending over these three days will be very specific, technical talks. Some will paint the future with a broad brush, others will detail the latest new thing. What I’m hoping that you will take away in the VERY short hour that I have with you is a sense of awareness and fundamental understanding of the most basic problem that you will face in building any kind of rule-based system. I am not pitching anything new or original – just a practical way to help alleviate that problem. Along the way, I will try to make the business case for this approach, but the talk will mostly be a high-level technical survey. At the risk of being cliché, it is true that people don’t plan to fail but rather they fail to plan. And we have all heard the statistics that some incredible percentage of software projects either fail outright or are at least challenged . While it is generally accepted that this is bad, I did see an article by Anthony Berglas on TheServerSide.com this month that argued that it was actually good for the economy. http://berglas.org/Articles/ImportantThatSoftwareFails/ImportantThatSoftwareFails.html In any case, for sake of argument, let’s grant that a disproportionately high percentage of software development projects fail outright. Common sense says that the more complex the project, the more opportunities there are for things to go wrong, hence the risk of failure is greater. Expert systems are arguably more complex than your average web app, therefore their risk of failure is commensurately higher. As developers and architects, we are approach this problem from the architectural and design perspectives. We’ll assume in our talk today that we have the authority to effect and enforce change at this level. So the questions is… how can you mitigate the risk of failure of your expert systems projects from an architectural and design perspective? Let’s move on…