1 / 265

Using Type Inference and Induced Rules to Provide Intensional Answers

Using Type Inference and Induced Rules to Provide Intensional Answers. Wesley W. Chu Rei-Chi Lee Qiming Chen. What is Intensional Answer?. Intensional answer to a query provides the characteristics that describes the database values (the extensional answers ) that satisfy the query

shaw
Télécharger la présentation

Using Type Inference and Induced Rules to Provide Intensional Answers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Using Type Inference and Induced Rules to Provide Intensional Answers Wesley W. Chu Rei-Chi Lee Qiming Chen

  2. What is Intensional Answer? • Intensional answer to a query provides the characteristics that describes the database values (the extensional answers) that satisfy the query • Intensional answers provide the users with: • Summarized or approximate descriptions about the extensional answers • Additional insight into the nature of extensional answers

  3. An Example of Intensional Answer Consider a personnel database containing the relation: EMPLOYEE = (ID, Name, Position, Salary) To find the person whose annual salary is more than 100K, the query can be specified as Q = SELECT * FROM EMPLOYEE WHERE Salary >100K; A traditional answer would be: {“Smith”, “Jones”,...} An intensional answer would be: “All the managers.”

  4. Prior Work: • Constraint-based approach for intensional query answering (Motro 89) • Aggregate response using type hierarchy (Shum 88) Only limited form of intentional answers can be generated • New Approach: Use both type hierarchy and database intensional knowledge • Two Phases: • Knowledge Acquisition • Use rule induction to derive intensional knowledge from database content • Type Inference • Based on type hierarch, use the derived rules to generate the specific intensional answers

  5. Traditional Views of Type Hierarchy • In semantic or object-oriented data modeling, there are two traditional views of type hierarchy: 1. IS_A Hierarchy: A IS_A B means every member of type A is also a member of type B. 2. PART_OF Hierarchy: A is PART_OF B means A is a component of B. These two views are mainly used for data modeling which provides a language for: • describing and storing data • accessing and manipulating the data

  6. The Notion of Type Hierarchy Classes and Types: • Any of the entities being modeled that share some common characteristics are gathered into classes. • All elements of the class have the same class type. Type Hierarchy is a partial order for the set of types: • Types (referred to as super-types) at higher positions are more generalized than types at lower positions. • Types (referred to as sub-types) at lower positions are more specialized than types at higher positions.

  7. An IS_A Type Hierarchy Example

  8. Type Inference • Type Inference is a process if traversing the type hierarchy that is based on the query condition and the induced rules. • Traversing of the type hierarchy can be performed in two directions: • Forward Inference • Backward Inference

  9. Deriving Intensional Answers Using Forward Inference Forward Inference uses the known facts to derive more facts. That is, given a rule, “If X then Y” and a fact “X is true”, then we can conclude “Y is true”. We perform forward inference by traversing along the type hierarchies downward from the type that is involved in the query. As a result, • The search scope for answering the query can be reduced • The lowest (the most specific) type description satisfying the query condition are returned as the intensional answers

  10. id SSBN730 SSBN130 name Rhode Island Typhoon class 0101 1301 type SSBN SSBN A Forward Inference Example To find the submarine whose displacement is greater than 8000, the query can be specified as: Q = SELECT * FROM SUBMARINE WHERE Displacement > 8000. The extensional answer to the query is: Using forward inference with R4, we can derive the following intensional answer: “Ships are SSBN submarines.”

  11. Derive Intensional Answers Using Backward Inference • Backward Inference uses the known facts to infer what must be true according to the type hierarchies and induced rules • Using backward inference, we traverse upward along the type hierarchies to provide the set of with constraints as intensional answers.

  12. name Nathaniel Hale Daniel Boone Sam Rayburn Lewis and Clark Mariano G. Vallejo Rhode Island Typhoon class 0103 0103 0103 0102 0102 0101 1301 A Backward Inference Example To find the names and classes of the SSBN submarines, the query can be specified as: Q = SELECT Name, Class FROM SUBMARINE, CLASS WHERE Type = “SSBN”; The extensional answer to the query is: Using backward inference, we can derive the following intensional answer: “Some ships have classes in the range of 0101 to 0103.”

  13. Deriving Intensional Answers via Type Inference Using forward inference, the intensional answer gives a set of type descriptions that includes the answers. Using backward inference, the intensional answer gives only a description of partial answers. Therefore, • the intensional answers derived from forward inference characterize a set of instances containing the extensional answers, whereas • the intensional answers derived from backward inference characterize a set of answers contained in the extensional answers. Forward inference and backward inference can also be combined to derive more specific intensional answers.

  14. name Bonefish Seadragon Snook Robert E. Lee class 0215 0212 0209 0208 type SSN SSN SSN SSN A Forward and Backward Inference Example To find the names, classes, and types of the SUBMARINES equipped with sonar BQS-04, the query can be specified as: Q = SELECT SUBMARINE.Name, SUBMARINE.Class, CLASS.Type FROM SUBMARINE, CLASS, INSTALL WHERE SUBMARINE.Class = CLASS.Class AND SUBMARINE.Id = INSTALL.Ship AND INSTALL.Sonar = “BQS-04” The extensional answer to the query is: Using both forward inference and backward inference, we can derive the following intensional answer: “Ship type SSN with class in the range of 0208 to 0215 is equipped with sonar BQS-04.”

  15. Conclusions In this research, we have proposed an approach to provide intensional answers using type inference and induced rules: • Type Inference • Inference • Backward inference • Combine forward and backward inference • Type inference with multiple type hierarchies • Rule Induction • Model-based inductive learning technique derives rules form database contents. For databases with strong type hierarchy and semantic knowledge, type inference is more effective than integrity constraints to derive intensional answers

  16. Fault Tolerant DDBMS Via Data Inference • Network Partition • Causes: • Failures of: • Channels • Nodes • Effects: • Queries cannot be processed if the required data is inaccessible • Replicated files in different partitions may be inconsistent • Updates may only be allowed in one partition. • Transactions may be aborted

  17. Conventional Approach for Handling Network Partitioning • Based on syntax to serialize the operations • To assure data consistency • Not all queries can be processed • Based on data availability, determine which partition is allowed to perform database update POOR AVAILABILITY!!

  18. New Approach Exploit data and transaction semantics • Use Data Inference Approach • Assumption: Data are correlated • Examples • Salary and rank • Ship type and weapon • Infer in accessible data from the accessible data • Use semantic information to permit update under network partitioning

  19. Query Processing System with Data Inference • Consists of • DDBMS • Knowledge-Base (rule-based) • Inference Engine

  20. Information Module Query Input Database Fragments Allocation Availability Query Parser and Analyzer Inference System Inference Engine Rule Based Knowledge-Based System DDBMS Query Output DDBMS with Data Inference

  21. Fault Tolerant DDBMS with Inference Systems KB2 DB2 SF IE LA NY KB1 KB3 DB1 DB3 IE IE KB SHIP(SID)  INSTALL (TYPE) INSTALL(TYPE)  INSTALL(WEAPON)

  22. Architecture of Distributed Database with Inference

  23. Motivation of Open Data Inference • Correlated knowledge is incomplete • Incomplete rules • Incomplete objects

  24. Example of Incomplete Object Type -------> Weapon IF type in {CG, CGN} THEN weapon = SAM01 IF type = DDG THEN weapon = SAM02 TYPE WEAPON CG SAM01 CGN SAM01 DDG SAM02 SSGN ?? Result: Incomplete rules generate incomplete object.

  25. Merge of Incomplete Objects • Observation: • Relational join is not adequate for combining incomplete objects • Lose information • Questions: • What kind of algebraic tools do we need to combine incomplete objects without losing information? • Any correctness criteria to evaluate the incomplete results?

  26. Merge of Incomplete Objects TYPE ---> WEAPON and WEAPON --->WARFARE Type Weapon Weapon Warfare CG SAM01 SAM01 WF1C CGN SAM01 SAM03 WF1D DDG SAM02 SSGN ? Use relational join to combine the above two paths: Type Weapon Warfare CG SAM01 WF1C CGN SAM01 WFIC Other way to combine: TYPE WEAPON WARFARE CG SAM01 WF1C CGN SAM01 WF1C DDG SAM02 ? ? SAM03 WF1D SSGN ? ?

  27. New Algebraic Tools for Incomplete Objects • S-REDUCTION • Reduce redundant tuples in the object • OPEN S-UNION • Combine incomplete objects

  28. S-Reduction • Remove redundant tuples in the object • Object RR with key attribute A is reduced to R RR R A B C A B C a 1 aa a 1 aa b 2 _ b 2 bb c _ cc c _ cc a 1 aa b _ bb c _ _

  29. Open S-Union • Modify join operation to accommodate incomplete information • Used to combine closed/open objects R1 R2 ----> R sid type type weapon sid type weapon s101 DD DD SAM01 s101 DD SAM01 s102 DD CG - s102 DD SAM01 s103 CG s103 CG -

  30. Open S-Union and Toleration • Performing open union on two objects R1, R2 generates the third object which tolerates both R1 and R2. R1 U R2 ----> R sid type type weapon sid type weapon s101 DD DD SAM01 s101 DD SAM01 s102 DD CG - s102 DD SAM01 s103 CG s103 CG - • R tolerates R1 • R tolerates R2

  31. site LA: SHIP(sid,sname,class) site SF: INSTALL(sid,weapon) site NY: CLASS(class,type,tname) Query: Find the ship names that carry weapon ‘SAM01’ (assuming site SF is partitioned) SF INSTALL Network Partition LA SHIP NY CLASS Rule: If SHIP TYPE = DD, Then WEAPON = SAM01 Example of Open Inference

  32. Implementation Derive missing relations from accessible relations and correlated knowledge Three types of derivations: • View mechanism to derive new relations based on certain source relations • Valuations of incomplete relations based on correlated knowledge • Combine two intermediate results via open s-union operation

  33. Example of Open Inference DERIVATION 1: select sid, type from SHIP, CLASS DERIVATION 2: CLASS(type) --> INSTALL(weapon) R1 R2 ----> INSTALL_INF sid type type weapon sid type weapon s101 DD DD SAM01 s101 DD SAM01 s102 DD CG - s102 DD SAM01 s103 CG s103 CG - • INSTALL_INF can be used to replace missing relation INSTALL

  34. Fault Tolerant DDBMS via Inference Techniques • Query Processing Under Network Partitioning • Open Inference: Inference with incomplete information • Algebraic tools for manipulating incomplete objects • Toleration: weaker correctness criteria for evaluating incomplete information

  35. Conclusion Data Inference is an effective method for providing database fault tolerance during network partitioning.

  36. Intelligent Dictionary and Directory (IDD) • The role of the IDD and the emerging technology of Object-Oriented Database Systems • The integration of Artificial Intelligence and Database Management tools and techniques to explore new architectures for the IDD • The support of future applications: heterogeneous, distributed, cooperating data/knowledge systems guided by active, intelligent dictionaries and directories and managed by Data and Knowledge Administrators

  37. Object-Oriented Dictionary Modeling • Information Resource Dictionary System • Functional Specification of the IDD • Role of Machine Learning in IDD • Mining Knowledge from Data • Schema Evolution • System Optimization Issues • Support for Hypermedia

  38. The Knowledge/Data Model (KDM) • The KDM modeling primitives are: Generalization: Generalization provides the facility in the KDM to group similar objects into a more general object. This generalization hierarchy defines the inheritance structure. Classification: Classification provides a means whereby specific object instances can be considered as a higher-level object-type (an object-type is a collection of similar objects). This is done through the use of the “is-instance-of” relationship. Aggregation: Aggregation is an abstraction mechanism in which an object is related to its components via the “is-part-of” relationship. Membership: Membership is an abstraction mechanism that specifically supports the “is-a-member-of” relationship.

  39. The Knowledge/Data Model • Temporal: Temporal relationship primitives relate object-types by means of synchronous and asynchronous relationships. • Constraints: This primitive is used to place a constraint on some aspect of an object, operation, or relationship via the “is-constraint-on” relationship. • Heuristic: A heuristic can be associated with an object via the “is-heuristic-on” relationship. These are used to allow the specifications of rules and knowledge to be associated with an object. In this way, object properties can be inferred using appropriate heuristics.

  40. The KDL Template for Object-Type Specification object-type: OBJECT-TYPE-NAME has [attributes: {ATTRIBUTE-NAME: [set of/list of] VALUE-TYPE /*default is single-valued composed of [ATTRIBUTE-NAME,}] with constraints {predicate,}] with heuristics {RULE,}];}] [subtypes: {OBJECT-TYPE-NAME,}] [supertypes: {OBJECT-TYPE-NAME,}] [constraints: {predicate,}] [heuristics: {rule,}]

  41. The KDL Template for Object-Type Specification (Cont’d) /*successors predecessors, and concurrents are temporal primitives [successors: {OBJECT-TYPE-NAME,}] [predecessors: {OBJECT-TYPE-NAME,}] [concurrents: {OBJECT-TYPE-NAME,}] [members: {MEMBER-NAME: MEMBER-TYPE}] [instances: {INSTANCE,}] end-object-type

  42. Three Services Database Schemata

  43. Knowledge Source Schemata in the KDM Paradigm

  44. KDL Object Type Specification Template

  45. The THESAURUS_OBJECT Meta-Schema

  46. The THESAURUS_OBJECT Meta-Object-Type Specification

  47. The KNOWLEDGE_SOURCE_OBJECT Meta-Object-Type Specification

  48. Three-Level Specification – Local, FM, and Federation

  49. A sample export data/knowledge/task schema for a federation interface manager

More Related