SQL Databases are a Moving Target Juan F. Sequeda – Syed Hamid Tirmizi – Daniel P. Miranker – Department of Computer Sciences The University of Texas at Austin

2 My favorite slide DATABASES SEMANTIC WEB

3 The Semantic Web Vision DB Local ontology DB Local ontology DB Local ontology Semantic Query Engine User Layer: Users and agents interact with this layer and query the ontologies Ontology Layer: defines the semantic representation of RDB. Inference Database Layer: Data that needs to accessed semantically

4 So what should be done? Make it easy for existing databases to generate Semantic Web content. Research Problem(s): Generate Ontologies from Database Content (many systems already make RDF from database data) Mapping database restrictions to OWL –People don’t live past 120 years old Mining database content for additional domain knowledge –Professors earn more than teaching assistants

5 Finally: Can the Semantic Web Work? DB Local ontology DB Local ontology DB Local ontology Semantic Query Engine We see a big problem: –Who builds this? –Who generates these mappings?

6 The Semantic Web Vision Local ontology Table Content DB Schema/ Metadata generate translate SQL-query RDF Semantic Web Query Engines

7 Our Position SQL has semantics –SQL has been evolving  it is a moving target! –SQL DDL can be used to generate local ontologies –A Greatest Common Denominator like OWL-DL can aid with data integration

8 Why are SQL Databases Moving Targets? In the beginning we had… Relational Model Student(Juan, 22) SQL86-89 came out with Table Definitions CREATE TABLE employee ( name VARCHAR(100), age INTEGER) SQL92 added data integrity Constraints CHECK, PRIMARY KEY, FOREIGN KEY, UNIQUE SQL99 added Triggers

9 SQL DDL to Ontologies Requirements –To create the ontology automatically, we need to compare the technologies –We need to identify constructs with similar semantics Analysis –Our analysis leads to a layer cake for SQL with corresponding layers in the Semantic Web stack Implementation –We express our transformations as FOL and use SQL BNF as a guideline for completeness.

10 Relational Model to RDF Relational Model –Employee(name, age) –T1: Employee (Juan, 21) RDF <rdf:RDF xmlns:rdf=" xmlns:ex=" Juan 21

11 Table Definition to RDFS Table Definition CREATE TABLE employee ( name VARCHAR(100), age INTEGER) RDFS

12 Table Definition to RDFS <rdf:RDF xmlns:rdf=" xmlns:rdfs=" Employee <rdfs:subClassOf rdf:resource=" ns#Resource"/> Name of Employee Age of Employee Table Name Attributes Data type

13 SQL to RDFS Tables  rdfs:Class Columns  rdf:Property –Table  rdfs:Domain –Datatype  rdfs:Range Foreign Keys  rdf:Property –Table  rdfs:Domain –Referencing Table  rdfs:Range

14 SQL to RDFS SQL BNFShared Semantics rdfs:Class ::= CREATE [ ] TABLE [ … ] Tables are equivalent to classes rdf:Property rdfs:domain rdfs:range ::= [NOT NULL] [...] Attributes become properties having the domain as the current table and the range as the datatype. rdf:Property rdfs:domain rdfs:range ::= FOREIGN KEY REFERENCES [...] Foreign Keys are relationships

15 SQL to OWL CREATE TABLE employee( employee_id INTEGER PRIMARY KEY, employee_ssn VARCHAR(11) UNIQUE, employee_name VARCHAR(100) NOT NULL, employee_salary INTEGER NOT NULL, employee_type CHAR(8) CHECK ( employee_type IN ('TEMP', 'FULLTIME', 'CONTRACT')) dept INTEGER FOREIGN KEY (dept) REFERENCES department (dept_id)) CREATE TABLE department( dept_id INTEGER PRIMARY KEY, dept_name VARCHAR(100) NOT NULL, manager INTEGER FOREIGN KEY (manager) REFERENCES employee (employee_id))

16 SQL to OWL Table Name Foreign Key Attribute Data type

17 SQL to OWL Temp Fulltime Contract Enumerated Check Constraint

18 SQL to OWL SQL BNFShared Semantics owl:Class owl:ObjectProperty ::= CREATE [ ] TABLE [...] A table can be an Object Property if acts like a binary relation, or else it is a Class owl:oneOf ::= CHECK ::= [ NOT ] IN The enumerated check constraint represents owl:oneOf owl:DatatypeProperty owl:FunctionalProperty owl:maxCardinality owl:cardinlity ::= [NOT NULL] [...] An attribute is equivalent to a Datatype Property with their domain and range. Depending if the attribute is NOT NULL or not, it can have owl:maxCardinality or owl:cardinality. owl:ObjectProperty rdfs:domain rdfs:range owl:FunctionalProperty ::= FOREIGN KEY REFERENCES [...] Foreign Keys connect to relations, therefore they act as Object Properties with their respective domain and range.

19 Rules: SQL to OWL Binary Relation: a relation that only has two foreign keys (single or composite) referencing two relations. Class: A relation that is not a binary relation is a class. Object Property –A binary relation is an object property –A foreign key that references another relation is an object property, whose domain is the current relation and range is the relation that the foreign key references

20 Rules: SQL to OWL Data type Property: If an attribute is not an object property, then it is a data type property. Its domain is the current relation and the range is the data type.

21 SQL to Rules Triggers are business rules and it can not be expressed in OWL Should think about how this could be mapped to the rule layer of the Semantic Web And the final layer cake…

22 SQL Layer Cake

23 Greatest Common Denominator for Data Integration All ontologies generated by SQL should have similar semantic power to facilitate better data integration –Use of different technologies may cause problems in data integration –The constructs we use has OWL-DL as GCD OWL-DL is what SW people like the most. –Reasoning and Inference –Decidability –Computational Completeness Therefore OWL-DL should be the target for SQL to Semantic Web transformations.

24

25 Summary SQL has semantics –SQL has been evolving  it is a moving target! –SQL DDL can be used to generate local ontologies –A Greatest Common Denominator like OWL-DL can aid with data integration

26 Thank You

27 Other Slides…

28 Discussion Topics Hierarchy and Inheritance –SQL DDL doesn’t have it –How do database people model it –Not clear how to get the semantics CHECK Constraint –Has more semantics that OWL can handle –CHECK (value >0 AND value < 360) OWL Constraints –allValuesFrom someValuesFrom URI

29 Discussion Topics: Hierarchy and Inheritance Hierarchy and Inheritance –Integrate information that is spread across several relations (vertical partitioning) and can be either Integrated in one concept Inheritance But how do you decide! –Key Equality and Data Inclusion: two relations that share the same primary key and the child relation’s primary key is also a foreign key PKPK, FK Project Software Project

30 Discussion Topics: Hierarchy and Inheritance How do you represent Hierarchy and Inheritance in database? –Hierarchy: Hand - Finger PK FK HandFinger –Inheritance: Person - Student PK PersonStudent PK, FK ?

31 Discussion Topics: someValuesFrom vs allValuesFrom A(id, x) B(id, y) C(A_id, B_id) Can we say that A and B are classes? Yes Can we say that C represents an object property? Yes Can we say that B can only be connected to A using the object property? ¿? Can we say anything about the cardinality of this relation? ¿?

32 Discussion Topics: CHECK Constraint Embodies semantics and rules at the same time Enumerated CHECK constraint  owl:one of But what about: –CHECK (value >0 AND value < 360)

33 Translation BNF: SQL to OWL ::= | ::= CREATE TABLE :: = ::= CREATE TABLE ::= ::= [ { <property}...] ::= |