The Problems with RDF/RDFS/OWL

Repetitious (same pattern repeated over and over)
- Lack of explicit structure/schema
Error-prone (typos, forgetting something, using wrong property, etc.)
- Adherence to an implicit structure/schema up to the user
Difficult to change (rename, change modelling, fix errors done, etc.)
Difficult to scale (make large datasets and ontologies, involve many people)
Difficult to involve domain experts

Tools to help: Data input

Mapping tools (more on this next week)
- Easier to scale by mapping large datasets into RDF
- Easier to change (change mappings)
- Single layer of abstraction (no reuse of patterns between mappings)
Programs generating data based on user input
- Less prone to error (data representation encoded once in the program)
- Easy to change, but only for future data input
- Structure of data now locked into program
Data might come from different sources (multiple programs, files, logs, reports, etc.)
- Need to make sure data is constructed consistently accross all these

Tools to help: Ontology input

Similar tools as with data
- But ontologies tend to be less structured than the data they describe
Ontology editors (e.g. Protégé)
- Visual editing of data and ontologies
- Less error-prone (e.g. detects typos)
- Easier to change certain things (via refactoring)
- Still repetitious
- No help for consistent modelling

General problems

Solutions above solve some problems in concrete cases
General problem: Lack a formal way to capture patterns and abstractions
This should be done at the language level
- All programs and mappings could refer/reuse the same patterns and abstractions

Assembly analogy

Assembly/Java bytecode:

0:   iconst_2
1:   istore_1
2:   iload_1
3:   sipush  1000
6:   if_icmpge       44
9:   iconst_2
10:  istore_2
11:  iload_2
12:  iload_1
13:  if_icmpge       31
16:  iload_1
17:  iload_2
18:  irem
19:  ifne    25
22:  goto    38
25:  iinc    2, 1
28:  goto    11
31:  getstatic       #84;
34:  iload_1
35:  invokevirtual   #85;
38:  iinc    1, 1
41:  goto    2
44:  return

Java:

outer:
for (int i = 2; i < 1000; i++) {
    for (int j = 2; j < i; j++) {
        if (i % j == 0)
            continue outer;
    }
    System.out.println (i);
}

RDF/RDFS/OWL:

exo:Planet  rdf:type     owl:Class ;
        rdfs:label       "Class of planets" ;
        rdfs:subClassOf  exo:AstronomicalObject .

exo:orbitsPlanet  rdf:type  owl:ObjectProperty ;
        rdfs:domain  exo:Moon ;
        rdfs:range   exo:Planet .

exd:earth  rdf:type       exo:Planet ;
        rdfs:label        "The Earth" ;
        exo:hasSattelite  exd:moon ;
        exo:orbitingStar  exd:sun .

exd:moon  rdf:type          exo:Moon ;
        rdfs:label          "The Moon" ;
        exo:orbitingPlanet  exd:earth .

exd:venus  rdf:type       exo:Planet ;
        rdfs:label        "Venus" ;
        exo:orbitingStar  exd:sun .

???

???

OTTR

OTTR (Reasonable Ontology Templates) is a framework aimed at fixing these problems
Introduces abstractions
OTTR provides a mechanism for capturing patterns with variables
A template is just a (named) pattern with variables
Patterns can be instantiated with varying values
Templates can be defined using other templates

Example: Patterns

exd:earth rdf:type exo:Planet ;
  rdfs:label "Earth" ;
  exo:orbitsStar ex:sun .
  
exd:mars rdf:type exo:Planet ;
  rdfs:label "Mars" ;
  exo:orbitsStar ex:sun .

exd:planet-b rdf:type exo:Planet ;
  rdfs:label "Proxima b" ;
  exo:orbitsStar ex:proxima .

Example: Patterns

exd:earth rdf:type exo:Planet ;
  rdfs:label "Earth" ;
  exo:orbitsStar ex:sun .
  
exd:mars rdf:type exo:Planet ;
  rdfs:label "Mars" ;
  exo:orbitsStar ex:sun .

exd:planet-b rdf:type exo:Planet ;
  rdfs:label "Proxima b" ;
  exo:orbitsStar ex:proxima .



  ?planet rdf:type exo:Planet ;
    rdfs:label ?name ;
    exo:orbitsStar ?sun .

Example: Templates

exd:earth rdf:type exo:Planet ;
  rdfs:label "Earth" ;
  exo:orbitsStar ex:sun .
  
exd:mars rdf:type exo:Planet ;
  rdfs:label "Mars" ;
  exo:orbitsStar ex:sun .

exd:planet-b rdf:type exo:Planet ;
  rdfs:label "Proxima b" ;
  exo:orbitsStar ex:proxima .

ast:Planet[ ?planet, ?name, ?sun ] :: {

  ?planet rdf:type exo:Planet ;
    rdfs:label ?name ;
    exo:orbitsStar ?sun .

} .

Example: Triples

exd:earth rdf:type exo:Planet ;
  rdfs:label "Earth" ;
  exo:orbitsStar ex:sun .
  
exd:mars rdf:type exo:Planet ;
  rdfs:label "Mars" ;
  exo:orbitsStar ex:sun .

exd:planet-b rdf:type exo:Planet ;
  rdfs:label "Proxima b" ;
  exo:orbitsStar ex:proxima .

ast:Planet[ ?planet, ?name, ?sun ] :: {

  ottr:Triple(?planet, rdf:type, exo:Planet),
  ottr:Triple(?planet, rdfs:label, ?name),
  ottr:Triple(?planet, exo:orbitsStar, ?sun)

} .

Example: Instances

exd:earth rdf:type exo:Planet ;
  rdfs:label "Earth" ;
  exo:orbitsStar ex:sun .
  
exd:mars rdf:type exo:Planet ;
  rdfs:label "Mars" ;
  exo:orbitsStar ex:sun .

exd:planet-b rdf:type exo:Planet ;
  rdfs:label "Proxima b" ;
  exo:orbitsStar ex:proxima .

ast:Planet[ ?planet, ?name, ?sun ] :: {

  ottr:Triple(?planet, rdf:type, exo:Planet),
  ottr:Triple(?planet, rdfs:label, ?name),
  ottr:Triple(?planet, exo:orbitsStar, ?sun)

} .

ast:Planet(exd:earth, "Earth", exd:sun) .
ast:Planet(exd:mars, "Mars", exd:sun) .
ast:Planet(exd:planet-b, "Proxima b", exd:proxima) .

Example: Abstraction layers

ast:Planet[ ?planet, ?name, ?sun ] :: {

  ottr:Triple(?planet, rdf:type, exo:Planet),
  ottr:Triple(?planet, rdfs:label, ?name),
  ottr:Triple(?planet, exo:orbitsStar, ?sun)

} .

o-rdf:Type[ ?object, ?class ] :: {
  ottr:Triple(?object, rdf:type, ?class)
} .

o-rdfs:Label[ ?object, ?label ] :: {
  ottr:Triple(?object, rdfs:label, ?label)
} .

ast:Planet[ ?planet, ?name, ?sun ] :: {

  o-rdf:Type(?planet, exo:Planet),
  o-rdfs:Label(?planet, ?name),
  ottr:Triple(?planet, exo:orbitsStar, ?sun)

} .

ast:Planet(exd:earth, "Earth", exd:sun) .
ast:Planet(exd:mars, "Mars", exd:sun) .
ast:Planet(exd:planet-b, "Proxima b", exd:proxima) .

Other OTTR Features

Types
- ast:Planet[ ottr:IRI ?planet, xsd:string ?name, ottr:IRI ?sun ] :: {...}
Optional values and none
- ? xsd:string ?name
Default values
- ottr:IRI ?sun=exd:sun
Lists and expansion modes
- List<xsd:string> ?names
- cross | o-rdfs:Label(?planet, ++?names)
Different syntaxes/serializations
- stOTTR (human readable, used in this lecture)
- wOTTR (RDF syntax, for publishing templates online)
- tabOTTR (tabular/Excel for instances) (more next week)
- bOTTR (mappings for making instances) (more next week)
Template libraries (see e.g. our Standard Library)

Lutra

Lutra is an open source Java CLI-tool that supports:

Instance expansion
Checking correctness of libraries and instances
Read and write libraries and instances from/to different formats
Make documentation for libraries

Download here

Example: Astronomy, improved

Let’s model the Solar System and other systems
Here are the templates and instances from the example
The RDF-graph can be made with:

java -jar lutra.jar \
    -m expand \
    -I stottr \
    -L stottr \
    -O wottr \
    -f \
    -l astronomy.stottr
    -o astronomy-expanded.ttl
    astronomy-ins.stottr

Properties of templates

Templates makes the patterns in the data explicit
DRY: Do not need to repeat pattern
Know that all instances follow the same pattern and satisfy the constraints (types, non-blanks, etc.)
Can now change/update the template to make consistent updates to the data
Can use the template to document and explain the structure/content of the data
Same features for many other abstraction mechanisms in computer science (functions, classes, methods, macros, rules, actors, etc.)
- OTTR simply enables this for RDF

IN5800 – OTTR Templates

Motivating Example

The Problems with RDF/RDFS/OWL

Tools to help: Data input

Tools to help: Ontology input

General problems

Assembly analogy

OTTR

Example: Patterns

Example: Patterns

Example: Templates

Example: Triples

Example: Instances

Example: Abstraction layers

Other OTTR Features

Lutra

Example: Astronomy, improved

Properties of templates