Presentation is loading. Please wait.

Presentation is loading. Please wait.

CSC 9010 Spring, 2006. Paula Matuszek 1 CS 9010: Semantic Web Inference and Rules Paula Matuszek Spring, 2006.

Similar presentations


Presentation on theme: "CSC 9010 Spring, 2006. Paula Matuszek 1 CS 9010: Semantic Web Inference and Rules Paula Matuszek Spring, 2006."— Presentation transcript:

1 CSC 9010 Spring, 2006. Paula Matuszek 1 CS 9010: Semantic Web Inference and Rules Paula Matuszek Spring, 2006

2 CSC 9010 Spring, 2006. Paula Matuszek 2 Beyond Ontologies With ontologies we can represent a lot of knowledge about the world: –Classes of objects –Instances of those classes –Properties of those classes, including –Relationships among those classes: Subclass (often called a specialization hierarchy) Components (often called an aggregation hierarchy) Any other binary relationships we care to define Is this enough?

3 CSC 9010 Spring, 2006. Paula Matuszek 3 The Restaurant Recommender Consider what happens when a friend says to you "We're trying to decide where to go for dinner tomorrow; any ideas?"

4 CSC 9010 Spring, 2006. Paula Matuszek 4 Relevant Ontologies There is a LOT of information available online about restaurants. Consider, for instance, zagat.com. If this were a semantic web page, what might the ontology include?zagat.com

5 CSC 9010 Spring, 2006. Paula Matuszek 5

6 6 Restaurant Ontology for Zagat: Classes Cuisine –Afghan –African –American –… Neighborhood –Abington –Ambler –… Feature –All you can eat –Boat Docking Facilities –… Properties described Décor Price Ratings Address Reservations? Parking? Dress Liquor license

7 CSC 9010 Spring, 2006. Paula Matuszek 7 Whats missing? This gives a lot of information, but its generally not what mostly went into where your friend should eat tomorrow. What else was there?

8 CSC 9010 Spring, 2006. Paula Matuszek 8 Other Possibly Relevant Facts These could all be expressed fairly readily in a description logic, with a little bit of creativity in what we consider an object. –Tomorrow is Valentine's Day. –Going to a nice restaurant is a special thing. –Restaurants have limited capacities. –Your friend hates waiting. –Your friend doesn't like Italian food. –Your friend lives in Cherry Hill –Your friend works in King of Prussia. Mostly not a restaurant ontology, but an ontology.

9 CSC 9010 Spring, 2006. Paula Matuszek 9 Now Is That All? How about: –Couples do special things on Valentine's Day. –If a restaurant serves mixed drinks it's a nice restaurant. –If the average cost of a meal for two people at a restaurant is >$50, its a nice restaurant. –If a site has a limited capacity and many people go there, it will be crowded. –Going to a crowded restaurant involves either making a reservation or waiting a long time.

10 CSC 9010 Spring, 2006. Paula Matuszek 10 We Need Rules! These are all general pieces of knowledge about eating at restaurants and about people, but they are hard to capture in the framework of a classes/properties structure. Several kinds here: –Rules that allow us to infer properties: Nice restaurant –Rules that give information about situations Waiting time, couples on Valentines Day

11 CSC 9010 Spring, 2006. Paula Matuszek 11 But Wait, Theres More! Now we have knowledge about restaurants and about your friend, but theres also knowledge about making recommendations, meta-knowledge about our process here –Recommend restaurants that don't involve too much travel. –Recommend restaurants that are new or have recently changed ownership/chef/style. –Recommend restaurants that your friend might not have thought of. –Recommend restaurants that you like.

12 CSC 9010 Spring, 2006. Paula Matuszek 12 So Where Are We? Our recommender clearly has several components: –Gather information about restaurants. Ideally we have a nicely tagged site where we can simply find it based on our restaurant ontology. –Gather information about the individuals preferences, based on another ontology. –Consult a generic common sense ontology for date-related information such as Feb 14 = Valentines Day.

13 CSC 9010 Spring, 2006. Paula Matuszek 13 And Then Magic Happens? And then what actually happens is inference. –If its Valentines Day, then couples will do special things. –If couples do special things, then they will go to nice restaurants. –If couples go to nice restaurants, then the restaurants will be crowded. –If a restaurant is crowded and it does not take reservations, the wait will be long. –If a restaurant is crowded and it does take reservations, the wait will not be long. –My friend should go to a nice restaurant which takes reservations or should not go to a nice restaurant.

14 CSC 9010 Spring, 2006. Paula Matuszek 14 Rule-Based Systems (RBS) The knowledge we have been using can be captured in rules. Rules in knowledge representation have a typical form of –IF left-hand-side or LHS or Premises or Body –THEN right-hand-side or RHS or Head The LHS has a condition or set of conditions to be met The RHS is the action to be taken if those conditions are met. In a subset of RBS the RHS is always an additional fact to be asserted. These are known as deductive systems; the rule can be interpreted as if the LHS is true, so is the RHS. (This is the subset mostly discussed in the text.)

15 CSC 9010 Spring, 2006. Paula Matuszek 15 Messy, Messy What we are doing here is forward chaining: working forward from existing facts to new things we can assert until we get to the one we want. If we have many rules with similar LHS conditions, this is very inefficient. –If couples go to nice restaurants then they will spend a lot of money –If couples go to NRs then they will be well-dressed. –If couples go to NRs then they will spend at least two hours. –If couples go to NRs then they will have a good time. –If couples go to restaurants then they will eat. –If couples go to restaurants then they will spend money. –… Also known as data-driven inference

16 CSC 9010 Spring, 2006. Paula Matuszek 16 Start at the End Suppose we start at the other end? My friend doesnt like waiting –Restaurant takes reservations or isnt nice Restaurant takes reservations. This allows us to ignore all the things we know about eating at nice restaurants except the one that affects our current problem. This is backward chaining: We maintain a tree of possibilities until we can ground out a reasoning chain at a fact. Also known as goal-driven inference If there is more than one way to get to a conclusion (meaning usually that more than one rule has the same RHS) then we may do a lot of backtracking and its just as messy.

17 CSC 9010 Spring, 2006. Paula Matuszek 17 Efficiency, Please We can view our restaurant recommendation as an attempt to prove that a specific restaurant is a good recommendation. Much of the work in both defining OWL and defining rule languages which can sit on top of OWL has been focused on supporting efficient proof system Description Logics have (Owl DL and OWL Lite) have efficient proof systems.

18 CSC 9010 Spring, 2006. Paula Matuszek 18 Horn Logic Another subset of predicate logic with an efficient proof system is Horn Logic In a Horn system –The LHS is a series of facts connected by AND –The RHS is a single fact. You cannot say, for instance, that –If Person(X) Then Man(X) OR Woman(X) With this restriction we can do inference using a very efficient procedure called resolution. The basic idea of resolution is assert the negative of the RHS and try to derive a contradiction to what we know is true. If we can find one then the RHS must be true.

19 CSC 9010 Spring, 2006. Paula Matuszek 19 Rules and Reality Predicate Logic as a knowledge representation makes some assumptions: –The fact base (the collection of things we know to be true) is monotonic. Once something is asserted to be true it remains true. We never retract something. Once something is asserted to be true we cannot assert its contradiction. We cant have both A and Not(A) in the fact base. –Everything is either true or not true. We dont have a maybe. –We also dont have an unknown. If we cant prove it true, its false. This is known as the closed world assumption, and it gives us negation by failure.

20 CSC 9010 Spring, 2006. Paula Matuszek 20 Monotonic Reasoning Consider the rule: If the date is Feb 14 and a restaurant is expensive, then it is a suitable restaurant. –Date(Feb 14), RestaurantCost (X) >$50 Suitable(X). Rules have several ingredients: –Variables are placeholders for values: X –Constants denote fixed values: $50 –Predicates relate objects: RestaurantCost –Function symbols return a value for certain arguments: date.

21 CSC 9010 Spring, 2006. Paula Matuszek 21 Monotonic Rules 2 Date(Feb 14), RestaurantCost (X) >$50 Suitable(X). LHS has the form B 1, … B n A, where –B 1 – B n and A are atomic formulas –The commas are conjunctions: ANDs The rule applies to any instance which can match to X: it is implicitly universally quantified (ie, we assume for all X)

22 CSC 9010 Spring, 2006. Paula Matuszek 22 Rules Syntax 3 Facts are atomic formulas with no variables. RestaurantCost(McDonalds, $5) is a fact. Goals: what we are trying to make true or find out. Typically phrased as a query which we want to prove to be true. –Suitable(McDonalds): Prove that McDonalds is a suitable restaurant (or that it isnt) –Suitable(X). Prove that there exists a suitable restaurant. More usefully, instantiate X to a suitable restaurant (and tell us what it is!)

23 CSC 9010 Spring, 2006. Paula Matuszek 23 Inference in a Monotonic System Our inference engine will use a proof system (forward- chaining, backward-chaining, resolution…) to –Try possible instantiations of variables in the LHS based on what instances are in the knowledge base –Apply any relevant rules in the knowledge base –Assert additional facts with those instantiated variables Until –We find an instantiation that allows us to prove our goal or –We try all possible combinations of instantiations and fail.

24 CSC 9010 Spring, 2006. Paula Matuszek 24 Why Logic? Advantages of Logic as a knowledge representation include –High expressive power, well-known –Well-understood formal semantics –Proof systems exist for deriving sound and complete conclusions. Some are even efficient. Disadvantages include –The restrictions it imposes are hard to handle in the real world –While its well known and well-understood by logicians, its not a very natural representation for most human experts.

25 CSC 9010 Spring, 2006. Paula Matuszek 25 Other Rule Formulations There are a variety of other rule formulations which are less restrictive then predicate logic. Pattern is still –If LHS Then RHS. LHS may be clauses connected by OR instead of AND, may include tests or actions which interact with the environment instead of the fact base RHS may include actions which interact with the environment and may also include retractions as well as assertions. Generically called production systems or just rule- based systems.

26 CSC 9010 Spring, 2006. Paula Matuszek 26 Non-Monotonic Rules We said that in predicate logic the knowledge base is monotonic. –Once something is asserted to be true it remains true. We never retract something. –Once something is asserted to be true we cannot assert its contradiction. We cant have both A and Not(A) in the knowledge base. So there are two ways to have a non-monotonic system: –Allow retractions –Allow contradictory rules in the same knowledge base.

27 CSC 9010 Spring, 2006. Paula Matuszek 27 Non-Monotonic Inference: Retractions In a non-monotonic system a rule may retract a fact. Why? –Things change over the course of our inference. Restaurant has a special Valentines Day Reservations Only policy –Default reasoning Your friend is going out with coworkers This introduces a number of complications: –For a reasoning chain A B C if we assert A, then we can conclude B and then C. If we then retract A, we no longer have support for B or C. Handling this general situation is called truth maintenance. –In a monotonic system, the order in which we apply rules cant affect the outcome, only the efficiency. This is not true in a non-monotonic system; therefore the choice of which applicable rule to use becomes important. This is the issue of conflict resolution. It can be resolved by a general CR strategy (depth first, breadth first, most complex first…) or by explicit rule weights.

28 CSC 9010 Spring, 2006. Paula Matuszek 28 Non-Monotonic Rules: Contradictions We can also get non-monotonicity because we allow contradictory rules in the same knowledge base. –If a restaurant is >$50, dont recommend it to students. –If a restaurant is >$50, recommend it on special occasions. Often the contradiction is indirect, with two different paths of inference leading to contradictory conclusions. Can be very difficult to spot as you develop rules! Often indicates insufficiently well-defined rules, such as missing conditions. –If RestCost(X) > $50, CanAfford(Y, X) recommend(X). Also a conflict resolution issue. –Find a difference inference chain without contradiction –Priorities on rules

29 CSC 9010 Spring, 2006. Paula Matuszek 29 KB vs Inference There is a distinction in Rule-Based Systems between the knowledge being captured, or the knowledge base (KB), and the process of using those rules, or inference. The program which implements the latter is called an inference engine. Difference inference engines can be used over the same KB, and different KBs can be used with the same inference engine. Not all inference engines can be used with all KB formats; an engine that assumes monotonicity cannot be use with a KB which includes retractions, for instance.

30 CSC 9010 Spring, 2006. Paula Matuszek 30 Some Well-Known (and Available) Inference Engines CLIPS: Forward-chaining rule system originally developed for NASA, implemented in C. CLIPS supports non-monotonic rules, but assumes negation-by-failure. It uses an inference engine based on the Rete algorithm. JESS: Reimplementation of CLIPS in Java. Over the years it has acquired quite a few extensions over CLIPS.CLIPSRete JESS Prolog: a logic programming language; backward chaining, based on resolution as an inference engine, supports non-monotonic rules, also assumes negation-by- failure.Prologresolution There are plugins for all of these for Protégé. More inference plugins can be found at the Protégé wikis library of plugins by topic.library of plugins by topic

31 CSC 9010 Spring, 2006. Paula Matuszek 31 RuleML RuleML is an initiative to standardize rules for the semantic webRuleML Would allow inference about web pages to be shared just as content is Based on XML and RDF –XML format and emphasis on order of elements –RDF-like role tags in which order is irrelevant Includes support for non-monotonic rules which have a priority tag, such as Theres a protégé plugin for converting taxonomies into ruleML.protégé plugin

32 CSC 9010 Spring, 2006. Paula Matuszek 32 Backup Slides

33 CSC 9010 Spring, 2006. Paula Matuszek 33 Rules Syntax in Predicate Logic Consider the rule: If the date is Feb 14 and a restaurant is expensive, then it is a suitable restaurant. –Date(Feb 14), RestaurantCost (X) >$50 Suitable(X). Rules have several ingredients: –Variables are placeholders for values: X –Constants denote fixed values: $50 –Predicates relate objects: RestaurantCost –Function symbols return a value for certain arguments: date.

34 CSC 9010 Spring, 2006. Paula Matuszek 34 Rule Syntax 2 Date(Feb 14), RestaurantCost (X) >$50 Suitable(X). LHS has the form B 1, … B n A, where –B 1 – B n and A are atomic formulas –The commas are conjunctions: ANDs The rule applies to any instance which can match to X: it is implicitly universally quantified (ie, we assume for all X)

35 CSC 9010 Spring, 2006. Paula Matuszek 35 Rules Syntax 3 Facts are atomic formulas with no variables. RestaurantCost(McDonalds, $5) is a fact. Logic Programs are finite sets of facts and rules. If P is a set of facts and rules, pl(P) is the set of all predicate logic interpretations of these rules. Goals: what we are trying to make true or find out. Typically phrased as a query which we want to prove to be true.

36 CSC 9010 Spring, 2006. Paula Matuszek 36 Predicate Rules Semantics Domain: non-empty set of objects about which to make statements Elements of domain Concrete function on domain for every domain symbol Concrete relation on domain for every predicate Ground and parameterized witnesses


Download ppt "CSC 9010 Spring, 2006. Paula Matuszek 1 CS 9010: Semantic Web Inference and Rules Paula Matuszek Spring, 2006."

Similar presentations


Ads by Google