Suitability of a KR for OBDM

Transcription

1 Suitability of a KR for OBDM Last time We explored how a KR (like OWL) can support terminology development schema development form and query expansion debugging and integration Is OWL fit for these purposes? Terminology? Schema, query, etc? Shape? Values? How do we work with standard datatypes? 1

2 Ontology Based Data Access (ODBA) Ontology at run time? More, ontology for the end user!??! By end user, I mean, someone writing queries Familiar Controlled vocabulary Query by example New Better queries Integrated views of data

3 Person Better queries Student Employee Better how? Consider a simple schema What does the logical schema look like? Lots of variants Sane queries SELECT hasage FROM employee WHERE hassalary >= 50000; SELECT hasage FROM student WHERE hassalary >= 50000; What about Persons? hasage hassalary create table employee (id number(4) hasage number(3), hassalary number(6); create table student (id number(4) hasage number(3), hassalary number(5); Union query? Rather write SELECT hasage FROM Person WHERE hassalary >= 50000; no matter what kind of persons there are

4 What do we need? Richer query language! Need at least conjunctive queries I.e., patterns with explicit varibles Increases complexity! Ontology sensitive! The queries should respect the semantics Data access! ETL...populate an ABox from a Database Distributed Leave my database ALOOOOOONNNNNEE!!!!! Need mappings Good computation Some fragments of OWL tuned for this Cf OWL QL and OWL EL Polynomial; OWL QL has pure query expansion implementations

5 OWL and Data (Properties) Sebastian Brandt (Slides by Bijan Parsia,

6 OWL Has Two Worlds The world of logic Classes, individuals, (object) object properties Java analogue: Classes, instances, and object valued instance variables The world of data Datatypes, data values, data properties (well, these span worlds) Java analogue: Primitive types, primitive data values, primitively-valued instance vars 6

7 The World of Logic: Abstract Individuals are members of classes We know nothing about them except what the ontology says Individual: Bijan Types: Person. Individual: Sean Types: Person. Class: Instructor SubClassOf: Person What do we know about Bijan, Sean, Instructor, and Person? Individuals (etc.) are characterized entirely by the user axioms Ok, mostly. Tautologies: Bijan Types: owl:thing. What s left unsaid may or may not hold Open world assumption (and no unique name assumption) Think of the various models Remember: the interpretation domain is arbitrary 7

8 The World of Data: Concrete Just as with primitive types, we have predefined names: For individuals: 1, 2, 0, 1.0, I m a string!, "51"^^xsd:integer For sets of individuals (aka types) integer, xsd:string, xsd:nonnegativeinteger, xsd:decimal, etc. These names have a fixed interpretation! That is, ( 1 ^^xsd:integer) I is always the integer 1. xsd:integer is always the set of integers The atomic names (singular and plural) have built-in meaning On the abstract side, this is only true for owl:thing, owl:nothing, owl:topobjectproperty, owl:bottomobjectproperty, owl:topdataproperty, owl:bottomdataproperty, and the logical connectives The actual meanings for the tops vary with the interpretation domain 8

9 Fixed meaning! There is a lot we know about integers DataProperty: Height Characteristics: Functional Individual: Bijan Facts: height 6 ^^xsd:integer We know that my height cannot be equal to 2, 4, or 8 Bijan Facts: height 6, height 2» Inconsistent! We know that my height cannot be a xsd:string Compare with: ObjectProperty: Height Characteristics: Functional Individual: Bijan height Six, height Two What follows? We can replicate the inequality on the abstract side Just add Individual: Six DifferentFrom: Two For all integers (DifferentIndividuals helps only a little) Many more entailments to formalize... 9

10 What Can We Define? We have an expression language for data We can derive new types from our primitives integer[>= 0, <=150] This is a restriction on integer (a DataRestriction) The subset of integers between 0 and 150, inclusive <= and >= have built in meaning That the values respect, e.g., 1<=2 but not 2 <=1 We can name these expressions In a limited way Datatype: personage EquivalentTo: integer[>= 0, <=150] We can express boolean combinations of expressions not personage integer[>=0] or integer[<=150] facet (integer[>=0] or integer[<=150]) and not personage (And enumerations, e.g., {1, 2, 3}) 10

11 Between Two Worlds DataProperties Disjoint from ObjectProperties ObjectProperties are interpreted into the crossproduct of the (abstract) domain (i.e., Δ Δ) DataProperties are interpreted into the crossproduct of the abstract and data domains (i.e., Δ Δd) Δ and Δd are disjoint Δd is a (large) superset of the union of the value spaces DataProperty Axioms Most of the usual: Sub/Equivalent/Disjoint, etc. Restrictions on DataProperties In general no chaining : No transitive, inverse, reflexive, etc. Anything that would potentially merge the domains 11

12 Between Two Worlds different type or sort Bijan Facts: height 6 ^^xsd:integer I I I Δ I Δinteger a b Example interpretation I Fixed for any interpretation 12

13 Between Two Worlds object property Class: To3 EquivalentTo: P min 3 Thing Individual: Bijan Facts: P X, P Y, P Z (*) Δ Bijan I I P J Δ Bijan J e b d c I I I X Y Z J J J f b Interpretation I I (*) I Bijan :Types To3 Interpretation J J (*) J Bijan :Types To3 13

14 Between Two Worlds data property Class: To3 EquivalentTo: DP min 3 integer Individual: Bijan Facts: DP 1, DP 2, DP 3 (*) Bijan DP Δ I I I Δinteger a b Example interpretation I I (*) implies I Bijan :Types To3 for any interpretation I 14

15 Two World Philosophy OWL is for developing theories about the world Very blank slate We re cautious about what we conclude Pedantry is critical! We have excellent theories about integers And strings! As well as how to compute with them There s no point in trying to formalize integers Integers should be a standard part of our language Very hard to recognize a half baked integer theory As a theory of integers 15

16 The Standard Datatype Map: Types Maths Numbers String Misc owl:real owl:rational xsd:decimal xsd:integer xsd:nonnegativeinteger xsd:nonpositiveinteger xsd:positiveinteger xsd:negativeinteger xsd:long xsd:int xsd:short xsd:byte xsd:unsignedlong xsd:unsignedint xsd:unsignedshort xsd:unsignedbyte rdf:plainliteral xsd:iri xsd:string xsd:normalizedstring xsd:token xsd:language xsd:name xsd:ncname xsd:nmtoken Computer Numbers xsd:double xsd:float rdf:xmlliteral xsd:boolean Date and Time xsd:datetime xsd:datetimestamp Binary xsd:hexbinary xsd:hex64binary 16

17 The Standard Datatype Map: Facets Maths Numbers String Misc xsd:mininclusive xsd:maxincluse xsd:minexclusive xsd:maxexclusive integer[<= 0, >= 150] xsd:length xsd:minlength xsd:maxlength xsd:pattern (for rdf:plainliteral rdf:langrange) Computer Numbers xsd:mininclusive xsd:maxincluse xsd:minexclusive xsd:maxexclusive None Date and Time xsd:mininclusive xsd:maxincluse xsd:minexclusive xsd:maxexclusive Binary xsd:length xsd:minlength xsd:maxlength 17

18 The Standard Datatype Map Maths Numbers String Misc Everything derived from Everything derived Mutually Disjoint owl:real. Note that from rdf:plainliteral there area many except xsd:iri (which elements of owl:real is disjoint from the Date and Time which have no lexical rest) form. Mutually disjoint Computer Numbers Binary Mutually disjoint Disjoint from owl:real (and the other categories) and each other 18

19 Key Restrictions Restrictions on datatypes: admissible Support top predicate Closed under negation Satisfiability of conjunctions is decidable integer[<=0] and integer[>=10] is unsatisfiable We consider only unary predicates Benefits Admissible datatypes + OWL(DL) = decidable KR formalism Can be implemented using a datatype oracle Simply extend existing reasoner by solvers for datatypes No need to build new reasoner from scratch 19

20 Robustness of Datatypes Semantically robust Ontologies don t change when you add or remove non-used datatypes Computationally robust Very robust for decidability Complexity is a bit trickier Implementably robust Highly modular implementation Expressively limited Can t even say a square s height equals its width! Can t talk about the whole data domain We trade off expressivity for robustness 20

21 Two World Philosophy Benefits From a user perspective: + Integers "Just Work" So do strings, floats, decimals, etc. Powerful constructors + Normal syntax + Clean separation (data and objects; user theory and builtin theory) May be a - - Limits on user extensibility And transparency, explorability - Expressivity restrictions (no addition!) From a theory perspective: + Analyzable From an implementation perspective: + Modular implementation - Must extend implementation to accommodate new types, facets 21

22 Liberalization Our restrictions are overstrict Simple generalisation: Allow n-ary comparisons Not just age some integer[>=5] Compare values on different properties age only integer[<= height] (made up syntax!) Bijan Facts: age 42, height 6 Note that these still must be path free! No, Person that hascar hasage» only integer[= hashouse hasage] People whose cars are only as old as their houses We can liberalize this a bit further Allow for (linear) (in)equations as predicates EquivalentClasses(SafelyDosedPatient DataAllValuesFrom(tookDrugInAmount weight DataComparison(Arguments(totalDoseInMg weightinkg) leq(totaldoseinmg times(2, weightinkg))))) 22