Meaning of Data

• If the computer system “understands” the data, it can handle much of the domain complexity for us
  • E.g. “Give me everyone related to Bob” vs. “Give me all mothers, fathers, brothers, etc… of Bob”
• E.g. if the computer understands/knows of the meaning of all family relationships, we can query for all ancestors even if the data only contains mother/father-statements
• However, the computer’s “understanding” is limited to bits/bytes and bitwise operations
• Everything else needs to be explicitly encoded using these low-level operations
• Luckily, we have a tower of abstractions to build upon
  • Databases already “understands” data in terms of tables, columns, types, constraints, queries, etc.
• Still a gap between a table Person and our understanding of the term “person”

How do we define meaning?

• Normally, we define the meaning of a term using other terms
• This forms a web of definitions
• E.g.:

Student: A person taking a course at a university.
Person: A being that has certain capacities or attributes.
University: An institution focused on teaching and research in a wide range of domains.

Sonk: A dingu bolating a prosendu at a silidong.
Dingu: A bokinus that has junikal sonadages or pilonki.
Silidong: An inku pokusada on veleren and sokina in a hinduna range of kalindis.

What is Semantics?

• Semantics is the meaning of statements or terms in a language
• A formal semantics for a language L is a mapping from constructs/sentences over L into some other well-known language/structure
• Typically a mathematical structure or language
  • E.g. set theory or first-order logic
• The mapping from things in L into the well-known language is known as interpretation
• Typically define the meaning/semantics for a given set of terms
• The meaning of the rest can then be understood from how they relate to the now meaningful terms
• In our world: We define meaning for meta-data, which then gives meaning to data

Syntactic Reasoning

• Computers cannot (directly) reason with (infinite) sets or other mathematical/logical structures like we humans do
• However, can do syntactic manipulation of terms
• Therefore, encode the semantics as syntactic manipulation (often called a calculus)
• That is, encode the semantics in a way so that programs can reason with it
• Further building on our tower of abstraction
• Important properties of syntactic calculi:
  • Soundness: Everything deriveable with the calculus is true according to the semantics
  • Completeness: Everything true according to the semantics can be derived with the calculus

Rules

• This syntactic manipulation is often encoded as rules
• (I.e. the logical rules we saw last week)
• Rules defined to correspond exactly with semantics
• Semantics-defining rules often called entailment rules
• A rule is often written in one of the following ways:

  type(x, y) .    subClassOf(y, z) .
_____________________________________

           type(x, z) .

type(x, y), subClassOf(y, z) -> type(x, z)

(?x rdf:type ?y) (?y rdfs:subClassOf ?z) -> (?x rdf:type ?z)

Reasoners and Rule Engines

• A reasoner is a program that can perform reasoning/entailment on data
• A reasoner using rules is often called a rule engine
• We will use three rule engines:
  • Lore
  • Triplelore (based on Lore)
  • Jena Rule Reasoner

Rules over RDBs (Lore)

• Can use (Lore’s) rules to define the semantics of relations
• E.g. “All mothers are parents”: mother(x, y) -> parent(x, y);
• Can make rules capturing the relationships between the terms/relations

Rules over RDBs (Lore): Problems

• However, the terms/relations we typically have in a relational database are composed/non-atomic
• A relation describing an entity consists of both the entity and all of its attributes
• E.g. we might have:
  • Student(uid, sname, student_id, level, born)
  • Person(pid, pname, birthdate)
• Impossible to just state: “All students are persons”
• Also impossible to just state: “snames are also pnames”
• Need to also make statements about how each attribute of students relate to attributes of person

Rules over RDBs (Lore): Solution

• Break up into binary/unary relations

-- Relations:
Student(uid)                    Person(pid)
student_name(uid, sname)        person_name(pid, pname)
student_id(uid, student_id)     person_birthdate(pid, birthdate)
student_level(uid, level)
student_born(uid, born)

-- Rules:
Student(uid) -> Person(uid); -- All students are persons
student_name(uid, sname) -> person_name(uid, sname); -- snames are pnames

RDF

• RDF takes this idea one step further by removing the separation between data and meta-data
• Any IRI can be the subject, predicate and object of a triple
• This makes it easier to define terms/IRIs using other terms/IRIs
• Given a predefined semantics of some terms allows us to define the others via triples
• Can e.g. give semantics to classes assuming we have a semantics for rdf:type and rdfs:subClassOf:
  • (?x rdf:type ?y) (?y rdfs:subClassOf ?z) -> (?x rdf:type ?z)
• Triplestores are tailored for this (lack of) structure

Semantics for RDF

• Simple in the sense that little can be derived from it
• Complex in the sense that the interpretation is complicated
• Of little practical utility
• Example entailment rule:

(?s ?p ?o) -> (?s ?p _:b)

RDFS

• Introduces a vocabulary with resources for
  • classes (rdfs:Class)
  • typing (rdf:type) and subclassing (rdfs:subClassOf)
  • properties (rdf:Property)
  • subproperties (rdfs:subPropertyOf)
  • and domain (rdfs:domain) and range (rdfs:range)
• Classes are (intuitively) sets of concrete things (e.g. people. cars, cats)
• Properties are (intuitively) relations between these things (e.g. knows, owns)
• Meaning of this vocabulary encoded via rules
• These terms can then be used to define and relate other terms

RDFS Example

Data:

ex:leifhka ex:lectures ex:in5800 .
ex:martingi ex:lectures ex:in3060 .

ex:ole ex:takesCourse ex:in5800, ex:in2090 .
ex:mary ex:takesCourse ex:in3060 .

Ontology:

ex:Student rdf:type rdfs:Class .
ex:Employee rdf:type rdfs:Class .
ex:Lecturer rdf:type rdfs:Class .
ex:Person rdf:type rdfs:Class .
ex:Course rdf:type rdfs:Class .

ex:Student rdfs:subClassOf ex:Person .
ex:Lecturer rdfs:subClassOf ex:Employee .
ex:Employee rdfs:subClassOf ex:Person .

ex:takesCourse rdf:type rdfs:Property .
ex:lectures rdf:type rdfs:Property .

ex:takesCourse rdfs:domain ex:Student .
ex:takesCourse rdfs:range ex:Course .

ex:lectures rdfs:domain ex:Lecturer .
ex:lectures rdfs:range ex:Course .

Rules for RDFS-reasoning

(?x rdfs:subClassOf ?y) (?y rdfs:subClassOf ?z) -> (?x rdfs:subClassOf ?z)
(?x rdf:type ?y) (?y rdfs:subClassOf ?z) -> (?x rdf:type ?z)

(?r rdfs:subPropertyOf ?p) (?p rdfs:subPropertyOf ?q) -> (?p rdfs:subPropertyOf ?q)
(?x ?r ?y) (?r rdfs:subPropertyOf ?p) -> (?x ?p ?y)

(?x ?r ?y) (?r rdfs:domain ?d) -> (?x rdf:type ?d)
(?x ?r ?y) (?r rdfs:range ?d) -> (?y rdf:type ?d)

Rules in Jena

• Jena supports reasoning via rules
• Supports both forward and backwards reasoning
• Syntax similar to Lore, but write triples directly
• Example rule:

[sc-prop: (?x rdf:type ?y) (?y rdfs:subClassOf ?z) -> (?x rdf:type ?z) ]

RDFS Rules in Jena

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> 
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> 

[sc-trans: (?x rdfs:subClassOf ?y) (?y rdfs:subClassOf ?z) -> (?x rdfs:subClassOf ?z) ]
[sc-prop: (?x rdf:type ?y) (?y rdfs:subClassOf ?z) -> (?x rdf:type ?z) ]

[sp-trans: (?r rdfs:subPropertyOf ?p) (?p rdfs:subPropertyOf ?q) -> (?p rdfs:subPropertyOf ?q) ]
[sp-prop: ?x ?r ?y) (?r rdfs:subPropertyOf ?p) -> (?x ?p ?y) ]

[domain: (?x ?r ?y) (?r rdfs:domain ?d) -> (?x rdf:type ?d) ]
[range: (?x ?r ?y) (?r rdfs:range ?d) -> (?y rdf:type ?d) ]

Could then apply these rules to the previous RDFS example with the JenaRuleReasoner.

OWL

• Similar to RDFS, reuses rdf:type, rdfs:subClassOf, rdfs:subPropertyOf, rdfs:domain and rdfs:range
• But allows more complex axioms
• Intersection, union and complement of classes
• Limited quantifiers (forall, exists)
• Complex property axioms (transitivity, functionality, reflexivity, etc.)
• Equality between resources
• Different profiles/sublanguages (e.g OWL2 QL, OWL 2 RL, OWL 2 DL)
• Typically not written in RDF (directly)
• Each complex axiom is encoded with multiple triples
• “Every student is a person and takes a course”:

ex:Student rdfs:subClassOf
    [ a owl:Class ;
      owl:intersectionOf ( ex:Person
                           [ a owl:Restriction ;
                             owl:onProperty ex:takesCourse ;
                             owl:someValuesFrom ex:Course 
                           ]
                         )
    ] .

OWL and Structure

• A proper ontology in OWL gives much of the same type of structure as relational databases
• OWL makes a clear separation between
  • classes (relational: entity types),
  • individuals (relational: entites/rows)
  • data properties (relational: attributes),
  • object properties (relational: relationships/foreign keys)
• Thus, makes sense to call data augmented with a proper OWL ontology structured data
• However, structure decoupled from data
  • Can be added after capturing the data
  • Can be changed without changing the data

OWL 2 RL semantics (partial)

• Same as for RDFS: rdf:type, rdfs:subClassOf, rdfs:subPropertyOf, rdfs:domain and rdfs:range

TripleLore

• Triplelore is a program that can translate RDF and ontologies to Lore
• See Triplelore’s wikipage for more details
• Properties are translated into binary (Lore-) relations
• Classes are translated into unary (Lore-) relations
• Class and property axioms are rewritten to Lore-implications
• Can be downloaded here and source available here

Translating Ontologies

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ex: <http://example.org/> .

ex:Person a owl:Class .

ex:Student a owl:Class ;
    rdfs:subClassOf ex:Person .

ex:Employee a owl:Class ;
    rdfs:subClassOf ex:Person .

ex:parent a owl:ObjectProperty ;
    rdfs:range ex:Person ;
    rdfs:domain ex:Person .
    
ex:mother a owl:ObjectProperty ;
    rdfs:subPropertyOf ex:parent .

ex:name a owl:DatatypeProperty ;
    rdfs:domain ex:Person ;
    rdfs:range xsd:string .

ex:age a owl:DatatypeProperty ;
    rdfs:domain ex:Person ;
    rdfs:range xsd:integer .

ex:ola a ex:Student ;
    ex:name "Ola" .

ex:kari ex:mother ex:ola ;
    ex:age "35"^^xsd:integer .

IMPORT 'http://leifhka.org/lore/library/prefix.lore';

prefix('xsd', 'http://www.w3.org/2001/XMLSchema#');
CREATE SCHEMA IF NOT EXISTS xsd;
prefix('rdfs', 'http://www.w3.org/2000/01/rdf-schema#');
CREATE SCHEMA IF NOT EXISTS rdfs;
prefix('ex', 'http://example.org/');
CREATE SCHEMA IF NOT EXISTS ex;
prefix('rdf', 'http://www.w3.org/1999/02/22-rdf-syntax-ns#');
CREATE SCHEMA IF NOT EXISTS rdf;
prefix('owl', 'http://www.w3.org/2002/07/owl#');
CREATE SCHEMA IF NOT EXISTS owl;

CREATE RELATION owl.Class(individual text);
CREATE RELATION owl.DatatypeProperty(individual text);
CREATE RELATION owl.ObjectProperty(individual text);

CREATE RELATION ex.Employee(individual text);
CREATE RELATION ex.Person(individual text);
CREATE RELATION ex.Student(individual text);

CREATE RELATION ex.mother(subject text, object text);
CREATE RELATION ex.parent(subject text, object text);
CREATE RELATION ex.name(subject text, object text);
CREATE RELATION ex.age(subject text, object bigint);

ex.Employee(x) -> ex.Person(x);
ex.Student(x) -> ex.Person(x);

ex.mother(x, y) -> ex.parent(x, y);

ex.parent(x, y) -> ex.Person(y);
ex.parent(x, y) -> ex.Person(x);
ex.name(x, y) -> ex.Person(x);
ex.age(x, y) -> ex.Person(x);

owl.Class('http://example.org/Student');
owl.Class('http://example.org/Employee');
owl.Class('http://example.org/Person');
owl.DatatypeProperty('http://example.org/name');
owl.DatatypeProperty('http://example.org/age');
owl.ObjectProperty('http://example.org/mother');
owl.ObjectProperty('http://example.org/parent');

ex.Student('http://example.org/ola');
ex.name('http://example.org/ola', 'Ola');
ex.mother('http://example.org/kari', 'http://example.org/ola');
ex.age('http://example.org/kari', '35');

Triplelore: Schema

• Triplelore translates:
  • every class into a unary relation
  • every property into a binary relation
  • every statement x rdf:type A into A(x)
  • every (other) triple s p o into p(s, o)
• Each prefix is translated into a schema
  • E.g. ex:A can then be used as ex.A
  • Prefixes used are added to a special table (prefix)
  • URIs/IRIs within the classes and properties are written out in full
  • Can use qn('ex', 'ole') for ex:ole
• The semantics is translated into rules
  • E.g. ex:A rdfs:subClassOf ex:B becomes ex.A(x) -> ex.B(x)
  • Can specify whether should use forward or backwards chaining (-b flag)
  • Can also use own Lore-rules

Triplelore: Supported Semantics (Lore-OWL)

• Triplelore supports a subset of OWL 2 RL (everything except owl:sameAs, same as we showed above)
• Rewrites certain (sets of) semantic triples into Lore-rules
• See the Triplelore page for details
• Requirements:
  • All properties needs to be typed as either owl:ObjectProperty or owl:DatatypeProperty
  • All owl:DatatypePropertys needs to have an rdfs:range

Sparql

• Can generate (R2RML) mappings from the triplestore to RDF with -m r2rml together with all the common DB-flags
• To enable mapping generation aditional info is also stored in the DB
• E.g. these are the aditional statements added for the triples from previous example:

CREATE RELATION triplelore_class(cname text);
CREATE RELATION triplelore_property(pname text, range text);

triplelore_class('ex.Employee');
triplelore_class('owl.DatatypeProperty');
triplelore_class('owl.Class');
triplelore_class('ex.Person');
triplelore_class('ex.Student');
triplelore_class('owl.ObjectProperty');
triplelore_property('ex.mother', NULL);
triplelore_property('ex.parent', NULL);
triplelore_property('ex.name', 'http://www.w3.org/2001/XMLSchema#string');
triplelore_property('ex.age', 'http://www.w3.org/2001/XMLSchema#integer');

TripleLore and SPARQL

• The (R2RML) mappings are created witht the -m r2rml flag, e.g.:

java -jar triplelore.jar \
    -m r2rml \
    -h dbpg-ifi-kurs03 \
    -U leifhka \
    -d in5800 \
    -P pwd123 \
    -o mappings.ttl

ontop query \
    --db-driver=org.postgresql.Driver \
    --db-url=jdbc:postgresql://dbpg-ifi-kurs03.uio.no/in5800 \
    --db-user=leifhka \
    --db-password=pwd123 \
    -m mappings.ttl
    -q query.sparql

Example: Implicit information

Lets derive ancestor relationships from people.ttl via

1. Rules
2. OWL ontology

Example: Data Integration

Lets assume we are Bob (ex:bob) and want to know our ancestor’s occupations.

Bob managed to get a hold of:

1. A data set (people.ttl) describing his closest relatives and family
2. An ontology (people_ont.ttl) defining family relations
3. An incomplete data set decribing his more distant relatives
4. A list of people’s occupations
5. He then makes an ontology to integrate the data sets!

Semantics on Many Levels

1. Rules are used for encoding semantics of standardized vocabularies (OWL, RDFS)
2. These vocabularies can then be used to define other terms (e.g. ex:takesCouse)
3. These terms are used within a dataset to describe data (e.g. ex:in5800)

Ad-hoc or Homemade Semantics

• Define rules directly on your own terms/IRIs?
• Need definition of semantics (i.e. rules) together with the data for other’s to use
• However, often possible to redefine semantics to a higher “semantic level” (e.g. OWL)

(?x ex:hasAncestor ?y) (?y ex:hasAncestor ?z) -> (?x ex:hasAncestor ?z)

ex:hasAncestor rdf:type owl:TransitiveProperty .

Reasoning and Complexity

• Reasoning is expensive!
• Standard OWL reasoning is 2NEXPTIME-complete
• Trade-off between expressiveness and complexity
• For large datasets: Use a less epxressive language
• OWL has different profiles targeting different complexity classes
  • OWL 2 DL: General language with high expressivity/complexity
  • OWL 2 EL: Less expressive, tailored for reasoning on large ontologies
  • OWL 2 QL: Very limited expressiveness, tailored for reasoning on large datasets
  • OWL 2 RL: Limited expressivity, tailored for reasoning on large datasets encoded as rules