Introduction

Tawny-OWL is a fully programmatic environment for Ontology Development
Presents a different model of ontology development
Very powerful
Allows reuse of commodity tooling

Today

Taught material
Plenty of documented examples
Allow the audience to "follow-by-leader"
Plenty of time for questions
A flexible tail

Today

Attempted to make decoupled
Aware that people will come in and out
Probably not be entirely successful at this
Gets more programmatic as we go on
Will not explain all of the programming

Knowledge Pre-requisites

Required
- Basic knowledge of ontologies
- Basic knowledge of OWL
- Basic knowledge of amino acids
Not Required
- Knowledge of Clojure
- Knowledge of OWL API
- Knowledge of Tawny-OWL
- Be highly-experienced programmers
  - WOULD BENEFIT from some programming experience
- Familiarity with an IDE/Editor with Clojure support
  - WOULD BENEFIT if they followed instructions to run Clojure "hello world" program in their IDE of choice

Outcomes

Understand the motivation behind Tawny-OWL
Understand and use basic Clojure infrastructure
Build a basic ontology with Tawny-OWL
Understand pattern usage within Tawny-OWL
Implement a pattern, using Tawny-OWL
Understand the relationship to programmatic IDEs and related tools

Notes on Notes

All materials are available:
- http://homepages.cs.ncl.ac.uk/jennifer.warrender/swat4ls_2015/
These slides (2015_swat4ls.html)
As a book with lecture notes (2015_swat4ls_book.html)

Motivation

Tawny-OWL was initially an accidental tool
We did not start off writing a new environment
We discovered we needed while trying to build an ontology

Use Case (karyotypes)

Current, string representation comes from ISCN
Written in a book, no computational representation
The human karyotype is complex to describe

Use Case (karyotypes)

Alterations, even more so

46,XX
47,XXY (aka Klinefelter’s Syndrome)
46,Xc,+21
46,XY,+21c,-21
45,XY,-10,der(10)t(10;17)(q22;p12)
46,XY,der(7)t(2;7)(q21;q22)ins(7;?)(q22;?)
46,XX,der(8)t(8;17)(p23;q21)inv(8)(p22q13)t(8;22)(q22;q12)
46,XX,der(9)del(9)(p12)t(9;22)(q34;q11.2),der(9)t(9;12)(p13;q22)inv(9)(q13;q22)

An ontological representation seems like a nice idea

A partonomy?

What you see is what you get?
There are 24 chromosomes
Around 1000 bands, at different resolutions

Protege

Could do this in Protege
Technically, it scales well to an ontology of this size

Protege

But the user interface does not
Generating many similar classes is painful
Hard to know how an axiomatisation will perform at the start
Changing them afterwards even worse

Protege

We end up more like this

Can we do this programmatically?

Yes, but painfully
OWL API — used by many, including Protege 4
Java and the OWL API are long-winded
Compile-Code-Test cycle

// Create ontology
OWLOntologyManager m = create();
OWLOntology o = m.createOntology(example_iri);
// Add the OWL classes
OWLClass nucleus = df.getOWLClass(IRI.create(example_iri + "#Nucleus"));
OWLClass cell = df.getOWLClass(IRI.create(example_iri + "#Cell"));
// Add the OWL object property
OWLObjectProperty partOf = df.getOWLObjectProperty(IRI.create(example_iri + "#partOf"));
// Assert the axiom
// 1. Create the class expression
OWLClassExpression partOfSomecell = df.getOWLObjectSomeValuesFrom(partOf, cell);
// 2. Now create the axiom
OWLAxiom axiom = df.getOWLSubClassOfAxiom(nucleus, partOfSomeCell);
// 2. Add the axiom to the ontology
AddAxiom addAxiom = new AddAxiom(o, axiom);
// 3. We now use the manager to apply the change
m.applyChange(addAxiom);

Brain

Written by Samuel Croset, EBI
EL only
How does this script fit with Java’s OO design?
Compile-Run cycle

// Create ontology
Brain brain = new Brain();
// Add the OWL classes
brain.addClass("Nucleus");
brain.addClass("Cell");
// Add the OWL object property
brain.addObjectProperty("partOf");
// Assert the axiom
brain.subClassOf("Nucleus", "partOf some Cell");

The Paragon : R

R provides an interactive, exploratory environment for statistics
Command line shell, wrapped by several GUIs
Language is convenient to type and use

It’s not all good
The syntax can be bizarre
The language semantics are strange

Constraints

Simple to do (structurally) simple ontologies
OWL API — too much code to rewrite
Java (JVM) — because of the OWL API
Pre-existing development tooling

Karyotype Ontology

What have we achieved?
Around 1000 classes in the karyotype ontology
Similar numbers of tests, structural and reasoner based
Models 10 events, with patterns for downstream use
Multiple levels of ploidy
Performance tested axiomatisation

Tawny-OWL Key Features

Ontology building tool
Unprogrammatic syntax
Evaluative
Broadcasting
Patternised
Fully Extensible
Integrated Reasoning
Built on commodity language
Access to fully programming Toolchain

Ontology Building Tool

Tawny-OWL is an Ontology Building Tool
A "Textual User Interface"
Usable as an API
But not designed as an API
Built with the users in mind

Unprogrammatic Syntax

Both OWL API and Brain carry Java baggage
You can never forget you are programming
Tawny-OWL aimed to avoid this

(defontology o)

Unprogrammatic Syntax

Many OWL syntaxes to choose from
Functional, Concrete, XML, RDF
Manchester syntax (OMN) is designed for typing
Frame-based, rather than axiom-based
- i.e. all information about an entity is grouped
- Entity-Frame-Value

Class: o:A
    Annotations:
        rdfs:label "A"@en,
        rdfs:comment "A is a kind of thing."@en

Unprogrammatic Syntax

Tawny-OWL modelled on OMN
Modified to use Clojure/Lisp syntax

(defclass A
  :label "A"
  :comment "A is a kind of thing.")

Entities need parenthesis
No longer need commas
Blocks are explicit, so easier to parse

Unprogrammatic Syntax

Frame name usage i.e. :frame-name and not frame-name:
- Just for fit with Clojure
Some frame name changes e.g. :super rather that SubClassOf:
- More information at http://www.russet.org.uk/blog/2985
- Consistent with property i.e. :super not SubPropertyOf:
Some new "convenience" frames
- :label and :comment
- :sub meaning ontologies can be built bottom-up or top-down
Easy creation of new entities

(defclass B
  :super A
  :label "B")

Unprogrammatic Syntax

Two Comment syntaxes
Explicit creation of new entities
- Less error-prone
- Define before use optional
General Concept Inclusion (GCI) fully supported
Same syntax for patterns

Evaluative

Tawny-OWL is "evaluative"
Add new classes, new properties, new frames on-the-fly
Redefine patterns
Add new tests, and rerun
There is no compile cycle

Compiled

There is a compile cycle
But you won’t notice it
Tawny-OWL is performant
Tawnyised version of GO loads ~1 min

Broadcasting

An idea borrowed from R
R is very flexible with numbers and lists
Add number to list, adds the number of every element of the list

> c(1,2,3) + 4
[1] 5 6 7

Broadcasting

Tawny-OWL does something similar
owl-some expand to two existential restrictions

(defoproperty r)
(defclass C
  :super (owl-some r A B))

C some r A
C some r B

Class: o:C
    SubClassOf:
        o:r some o:B,
        o:r some o:A

Patternised

Tawny-OWL allows patterns
Broadcasting works naturally with patterns
some-only the most common

(defclass D
  :super (some-only r A B))

Expands into three (or n+2) axioms

Class: o:D

    SubClassOf:
        o:r some o:A,
        o:r some o:B,
        o:r only
            (o:A or o:B)

Single fully extensible syntax

Tawny-OWL is implemented in Clojure
Tawny-OWL patterns are implemented in Clojure
Tawny-OWL ontologies are written in Clojure
Therefore, adding new patterns is trivial
Here we introduce two new patterns and use them

(defn and-not [a b]
  (owl-and a (owl-not b)))

(defn some-and-not [r a b]
  (owl-some r (and-not a b)))

(defclass E
  :super (some-and-not r A B))

Which gives

Class: o:E
    SubClassOf:
        o:r some
            (o:A or (not (o:B)))

Reasoned Over

Tawny-OWL fully supports reasoning
In this case using HermiT
Based on all the examples given so far, F has three subclasses

(defclass F
   :equivalent (owl-some r (owl-or A B)))

;; #{}
(subclasses F)

(reasoner-factory :hermit)

;; #{C D E}
(isubclasses F)

Commodity Language

Built on Commodity Language
Full access to all APIs
- Serialisation
- Spreadsheet reading
- Database access
- Networking
- Logic Programming
- Test Library
- Statistics and Plotting
- Benchmarking

Commodity Toolchain

Editing
- IDEs: Eclipse, IntelliJ, Netbeans
- Power Editors: Emacs, Vim, Sublime
- Web Editors: Catnip, GorrilaRepl
- Novel: LightTable
Version Control: Any
Build and Dependency
- Lein, Maven or Boot
Testing
- Travis-CI, or any CI environment
Linters, Rewriters, Remote Evaluation (nREPL)

Tawny-OWL Tutorial

The source for these slides
All the sample code
git clone https://github.com/phillord/tawny-tutorial.git
Or download https://github.com/phillord/tawny-tutorial/releases

Other Technical Pre-Requisites

JVM
Leiningen
https://github.com/phillord/tawny-tutorial
Protege

Or: the alternative

Protege
All generated ontologies
http://homepages.cs.ncl.ac.uk/jennifer.warrender/swat4ls_2015/ontologies/

Task 1: Ontological Hello World

Build a Hello World Ontology

The namespace

Clojure has a namespace mechanism
The namespace is the same as the file name
But _ in file name is - in namespace
:use makes tawny.owl namespace available

(ns tawny.tutorial.onto-hello
  (:use [tawny.owl]))

The full code in these slides can be found in src/tawny/tutorial/onto_hello.clj

Define an Ontology

Using the defontology statement
hello is a new variable
Can be used to refer to the ontology
Becomes "default" for this namespace
All frames are optional
We see more later

(defontology hello
  :iri "http://www.w3id.org/ontolink/tutorial/hello")

Introduce a Class

Use a defclass statement
Statements are delineated with ()
Hello is also a variable
Hello and hello are different
Cannot use the same name twice
We use the "default" ontology

(defclass Hello)

Properties

Properties use defoproperty
o to distinguish annotation and datatype property
Both defclass and defoproperty take a number of frames
All are optional

(defoproperty hasObject)
(defclass World)

A complex class

Now we use a frame
:super says "everything that follows is a super class"
- Or, HelloWorld has a :super which is Hello
- http://www.russet.org.uk/blog/2985
owl-some is the existential operator
The default operator (or only) operator in many ontologies

(defclass HelloWorld
  :super Hello
  (owl-some hasObject World))

On the use of "owl" (a quick diversion)

It is owl-some rather than some
But it is only and not owl-only
This avoids a name clash with clojure.core
Have not gone the OWL API route

(owl-some hasObject World)
(only hasObject World)

On the use of "owl"

Full list of "owl" prefixed functions is
- owl-and
- owl-or
- owl-not
- owl-some
- owl-class
- owl-import
- owl-comment
And the variables
- owl-nothing
- owl-thing

On the use of "owl"

There are also some "short-cuts"
- &&, || and !
A "long-cut" (owl-only)
And consistent but clashing names in tawny.english namespace

Saving the Ontology

To save an ontology we use save-ontology
path/name of file is required
format is optional (default is :owl)

(save-ontology "o.omn" :omn)

More Frames

Can add new frames to existing definition with refine
Could also just change defclass form and re-evaluate
:label and :comment add annotations using OWL built-in
:annotation is general purpose frame

(refine HelloWorld
        :label "Hello World"
        :comment "Hello World is a kind of greeting directed generally at everything."
        :annotation (label "Aalreet world" "gb_ncl"))

Task 1: Conclusions

Tawny-OWL uses frames
It looks like Manchester syntax
But in a Lispy way
Easy to type, including short-cuts

Task 2: Defining a Tree

For the next section, we build an amino acid ontology
We do this in several ways
First, we start with a simple hierarchy

Amino Acids

Chemical Molecules
Central Carbon, with an amino and acid group
And a "side chain" or "R" group which defines the differences
Have a number of chemical properties
There are 20

A namespace

The name space declaration

(ns tawny.tutorial.amino-acid-tree
  (:use [tawny.owl]))

The full code in these slides can be found in src/tawny/tutorial/amino_acid_tree.clj

Tree

So, we define our (flat) tree

(defontology aa)

(defclass AminoAcid)

(defclass Alanine
          :super AminoAcid)

(defclass Arginine
          :super AminoAcid)

(defclass Asparagine
          :super AminoAcid)

;; and the rest...

Disjoint

Let’s make everything disjoint
Asparagine is not the same as Alanine or Arginine
With three amino-acids, this is painful and error-prone
With twenty it would be almost impossible

(defclass Asparagine
    :super AminoAcid
    :disjoint Alanine Arginine)

Disjoint

But there is a more serious problem
Change Arginine to this
This will now crash (probably)

(defclass Arginine
    :super AminoAcid
    :disjoint Alanine Asparagine)

Explicit definition

Tawny uses explicit definition
Variables must be defined before use
This is deliberate
Can be avoided by using Strings
But that is error-prone

Simplifying the definition

We can use the as-subclasses form
Adds AminoAcid as super to all arguments
This syntax also protects against future additions.

(defclass AminoAcid)

(as-subclasses
  AminoAcid

  (defclass Alanine)
  (defclass Arginine)
  (defclass Asparagine)
  ;; and the rest...
  )

And disjoint!

This simplifies the disjoint behaviour also
We add :disjoint keyword

(defclass AminoAcid)

(as-subclasses
 AminoAcid
 :disjoint

 (defclass Alanine)
 (defclass Arginine)
 (defclass Asparagine)
 ;; and the rest...
 )

And, finally, covering

We might also want to say
These are the only amino-acids there are
To do this we use a "covering" axiom
Interesting ontology! Biologically true, chemically not.

And, finally, covering

This is also easy to implement
Here with all the amino-acids in full
Again, the source code grouping is useful!

(defclass AminoAcid)

(as-subclasses
 AminoAcid
 :disjoint :cover

 (defclass Alanine)
 (defclass Arginine)
 (defclass Asparagine)
 (defclass Aspartate)
 (defclass Cysteine)
 (defclass Glutamate)
 (defclass Glutamine)
 (defclass Glycine)
 (defclass Histidine)
 (defclass Isoleucine)
 (defclass Leucine)
 (defclass Lysine)
 (defclass Methionine)
 (defclass Phenylalanine)
 (defclass Proline)
 (defclass Serine)
 (defclass Threonine)
 (defclass Tryptophan)
 (defclass Tyrosine)
 (defclass Valine))

And, finally, covering

And, here is a subset of the equivalent OMN

Class: aa:AminoAcid
    EquivalentTo:
        aa:Alanine or aa:Arginine or aa:Asparagine
        or aa:Aspartate or aa:Cysteine or aa:Glutamate
        or aa:Glutamine or aa:Glycine or aa:Histidine
        or aa:Isoleucine or aa:Leucine or aa:Lysine
        or aa:Methionine or aa:Phenylalanine or aa:Proline
        or aa:Serine or aa:Threonine or aa:Tryptophan
        or aa:Tyrosine or aa:Valine

DisjointClasses:
    aa:Alanine, aa:Arginine, aa:Asparagine, aa:Aspartate,
    aa:Cysteine, aa:Glutamate, aa:Glutamine, aa:Glycine,
    aa:Histidine, aa:Isoleucine, aa:Leucine, aa:Lysine,
    aa:Methionine, aa:Phenylalanine, aa:Proline, aa:Serine,
    aa:Threonine, aa:Tryptophan, aa:Tyrosine, aa:Valine

Task 2: Conclusions

It is easy to build simple hierarchies
We can group parts of the tree
There is support for disjoints
There is support for covering axioms

Task 3: Defining some properties

A list of amino acids only gets us so far
Now we define some properties
First, we do this the long-hand way

Namespace

By now you should be familiar with the namespace definition
It is different
This :use clause means "use both tawny.owl and tawny.pattern"

(ns tawny.tutorial.amino-acid-props
  (:use [tawny owl pattern]))

The full code in these slides can be found in src/tawny/tutorial/amino_acid_props.clj

Starting our ontology

As before, we define (another) amino acid ontology

(defontology aa)

(defclass AminoAcid)

Amino Acid properties

Amino Acids have many properties
Most of these are continuous
Hard to model ontologically

The Value Partition

We introduce the "value partition"
We split a continuous range up into discrete chunks
Like the colours of the rainbow
First we define the partition itself
AminoAcid's have a size, and only one size!

(defclass Size)
(defoproperty hasSize
  :domain AminoAcid
  :range Size
  :characteristic :functional)

The Value Partition

Now we define the values
Three values, and only three values
All of which are different

(as-subclasses
 Size
 :disjoint :cover

 (defclass Tiny)
 (defclass Small)
 (defclass Large))

Using the values

We can now create our amino acids using these three sizes
We only create three amino acids here
More would be needed.


(as-subclasses
 AminoAcid
 :disjoint :cover

 (defclass Alanine
   :super (owl-some hasSize Tiny))

 (defclass Arginine
   :super (owl-some hasSize Large))

 (defclass Asparagine
   :super (owl-some hasSize Small)))

 ;;and the rest

Interim Summary

Defined the Size value partition
Used these values in our class definitions
Issues with these restriction declarations?
- Long-winded
- Duplication
- Error-prone
What can we do to overcome these?

Using Facets

Relatively new feature of Tawny-OWL
Call these "facets" after "faceted classification"
Useful when many values are associated with a property
For example value partition
First define Charge using the same pattern as Size

(defclass Charge)
(defoproperty hasCharge
  :domain AminoAcid
  :range Charge
  :characteristic :functional)

(as-subclasses
 Charge
 :disjoint :cover

 (defclass Positive)
 (defclass Neutral)
 (defclass Negative))

Facet

Now define the values as facet of hasCharge
facets are extra-logical
They do not change the semantics of ontology statements
They are visible in the ontology

(as-facet
 hasCharge

 Positive Neutral Negative)

Using the facet

Can now give just the class
Again, using refine although could just alter the code
(facet Neutral) rather than (owl-some hasCharge Neutral)
Saves us some typing


(refine Alanine
        :super (facet Neutral))

(refine Arginine
         :super (facet Positive))

(refine Asparagine
        :super (facet Neutral))

And others

But we added the as-facet declaration
Now let’s add Hydrophobicity

(defclass Hydrophobicity)
(defoproperty hasHydrophobicity
  :domain AminoAcid
  :range Hydrophobicity
  :characteristic :functional)

(as-subclasses
 Hydrophobicity
 :disjoint :cover

 (defclass Hydrophobic)
 (defclass Hydrophilic))

(as-facet
 hasHydrophobicity

 Hydrophilic Hydrophobic)

Using Facets

And Polarity.

(defclass Polarity)
(defoproperty hasPolarity)

(as-subclasses
 Polarity
 :disjoint :cover

 (defclass Polar)
 (defclass NonPolar))

(as-facet
 hasPolarity

 Polar NonPolar)

Using Facets

facet broadcasts
We can apply two at once
A different property can be used for each
We could do all four value partitions at once

(refine
 Alanine
 :super (facet Hydrophobic NonPolar))

(refine
 Arginine
 :super (facet Hydrophilic Polar))

(refine
 Asparagine
 :super (facet Hydrophilic Polar))

Using Facets

And the output

Class: aa:Alanine

    SubClassOf:
        aa:hasCharge some aa:Neutral,
        aa:AminoAcid,
        aa:hasSize some aa:Tiny,
        aa:hasHydrophobicity some aa:Hydrophobic,
        aa:hasPolarity some aa:NonPolar

Task 3: Conclusions

Can use value partitions to split up numerical ranges
Can define facets to ease the use of object properties
Can apply several facets at once

Task 4: Patternising

Make full use of an existing pattern from Tawny-OWL

The problem

Used value partition to define our properties
Issues with defining the value partition:
- We still have a lot of typing
- The value partition has lots of parts
- Easy to get wrong (e.g. Polarity)
How can we simplify and ensure consistency?
Tawny-OWL supports this pattern directly

Namespace

The value partition pattern is found in tawny.pattern
We use it here

(ns tawny.tutorial.amino-acid-pattern
  (:use [tawny owl pattern]))

The full code in these slides can be found in src/tawny/tutorial/amino_acid_pattern.clj

And the preamble

This is the same as before

(defontology aa)

(defclass AminoAcid)

The `Size` value partition

This is a new form
Syntactically similar to what we seen before
defpartition defines that we will have a partition
[Tiny Small Large] are the values
hasSize is implicit — it will be created

(defpartition Size
  [Tiny Small Large]
  :domain AminoAcid)

The size value partition

And (some of) the OMN.

ObjectProperty: aa:hasSize
    Domain:
        aa:AminoAcid

    Range:
        aa:Size

    Characteristics:
        Functional

Class: aa:Size
    EquivalentTo:
        aa:Large or aa:Small or aa:Tiny

More value partitions

Adding partitions for all the properties is easy

(defpartition Charge
  [Positive Neutral Negative]
  :domain AminoAcid)

(defpartition Hydrophobicity
  [Hydrophobic Hydrophilic]
  :domain AminoAcid)

(defpartition Polarity
  [Polar NonPolar]
  :domain AminoAcid)

(defpartition SideChainStructure
  [Aromatic Aliphatic]
  :domain AminoAcid)

Using these partitions

defpartition also applies the as-facet function
So, we can use facet also
Syntactically, the ontology has simplified
Same semantics underneath

(as-subclasses
 AminoAcid

 (defclass Alanine
   :super (facet Neutral Hydrophobic NonPolar Aliphatic Tiny))

 (defclass Arginine
   :super (facet Positive Hydrophilic Polar Aliphatic Large))

 (defclass Asparagine
   :super (facet Neutral Hydrophilic Polar Aliphatic Small))

 ;; and the rest
 )

Task 4: Conclusions

Tawny-OWL directly supports the value partition
This integrates with facets
Together, can simply this (very common) form of ontology

Task 5: Understanding Names

Understand how Tawny-OWL uses IRIs and symbols to identify entities
See how to use them independently
Understand how they allow OBO ID support

Namespace

tawny.obo to support (OBO) numeric IDs
clojure.string is for string manipulation

(ns tawny.tutorial.whats-in-a-name
  (:use [tawny.owl])
  (:require [tawny.obo])
  (:require [clojure.string :as s]))

Background

Ontology entities need names
Tawny-OWL has different requirements for names
We need to support alternative workflows
So, Tawny-OWL is flexible
With "sensible" defaults

IRIs

Tawny-OWL is built on the OWL API
Underneath, therefore, it is part of the web
OWL uses IRIs (i.e. URIs or URLs) to identify entities
IRIs provide a single, shared global namespace
With a (social) mechanism for uniqueness

Symbols

Tawny-OWL uses symbols to identify entities
Core feature of Clojure
Easy to type (e.g. A rather than "A")
Allows you handle them directly
Provides define-before-use semantics
Supported in IDEs (e.g. syntax highlight and auto-complete)

Symbols and IRIs

What is the relationship between symbols and IRIs?
In Tawny-OWL, this is a per-ontology setting
By default the symbol forms the fragment of the IRI

(defontology o)

;; => #<OWLClassImpl <8d9d3120-d374-4ffb-99d8-ffd93a7d5fdd#o#A>>
(defclass A
  :ontology o)

Generates a random UUID
- Not good practice but supported by OWL API
We use the :ontology frame

Symbols and IRIs

We should identify our ontologies correctly
We use the :iri frame for our second ontology
Again, the class uses the symbol name as the fragment

(defontology i
   :iri "http://www.w3id.org/ontolink/example/i")

;; => #<OWLClassImpl <http://www.w3id.org/ontolink/example/i#B>>
(defclass B
  :ontology i)

Symbols and IRIs

The relationship is programmatically defined
We can change it to whatever we want
Using the :iri-gen frame to supply a function
Here we reverse the symbol name
We call the symbol name: "the tawny name"

(defontology r
  :iri "http://www.w3id.org/ontolink/example/r"
  :iri-gen (fn [ont name]
             (iri (str (as-iri ont)
                       "#"
                       (s/reverse name)))))

;; => #<OWLClassImpl <http://www.w3id.org/ontolink/example/r#EDC>>
(defclass CDE
  :ontology r)

OBO Identifiers

OBO identifiers present a challenge
Source code is the ultimate in WYSIWYG
Use the underlying identifiers and display something different to the user

(defclass GO:00004324
  :super (owl-some RO:0000013 GO:00003143)
  :annotation (annotation IAO:0504303 "Transporters are..."))

OBO Identifiers

Tawny-OWL provides an OBO style ID iri-gen function.
We set that here

(defontology obo
  :iri "http://www.w3id.org/ontolink/example/obo"
  :iri-gen tawny.obo/obo-iri-generate)

(tawny.obo/obo-restore-iri obo "./src/tawny/tutorial/whats_in_a_name.edn")

OBO Identifiers

Now we can evaluate these forms
Each gets a numeric identifier, OBO style
The identifier is stable

;; => #<OWLClassImpl <http://purl.obolibrary.org/obo/EXAM_000003>>
(defclass F
  :ontology obo)

;; => #<OWLClassImpl <http://purl.obolibrary.org/obo/EXAM_000002>>
(defclass G
  :ontology obo)

;; => #<OWLObjectPropertyImpl <http://purl.obolibrary.org/obo/EXAM_000001>>
(defoproperty ro
  :ontology obo)

Task 5: Conclusions

Can generate random UUID IRIs for ease
Mostly, we use the symbol (variable) name as fragment
Relationship is programmatic
OBO IDs are a pain in source
Tawny-OWL supports them

Task 6: Importing other Ontologies

Understand how to import and use another Tawny-OWL ontology

Importing

Many ontologies import from other ontologies
Allows cross-linking, and reuse of work
Tawny-OWL supports this
Involves two steps, use and import

The ontology to import

The ontology we wish to import

(ns tawny.tutorial.abc
  (:use [tawny.owl]))

(defontology abc
  :iri "http://www.w3id.org/ontolink/example/abc.owl")

(defclass A)
(defclass B)
(defclass C)

Namespace

We have seen use many times before
A namespace with an ontology can be used like any other
Here we use require
Helps to avoid name collisions

(ns tawny.tutorial.use-abc
  (:use [tawny.owl])
  (:require [tawny.tutorial.abc]))

Using

Normally, using is not enough
We also need to explicitly import the ontology
Only after owl-import will its axioms become available
Warning: Clojure has an import function and it does not do the same thing

(defontology myABC)

(owl-import tawny.tutorial.abc/abc)

Here, we define our new ontology and import the ontology axioms from the other abc ontology

Using

The require statement also allows us to use symbols
Here, we use an explicit name space tawny.tutorial.abc
And a symbol A
The symbolic approach protects against spelling mistakes

(defclass MyA
  :super tawny.tutorial.abc/A)

(defclass MyB
  :super tawny.tutorial.abc/B)

The resulting OMN

Class: myABC:MyA
    SubClassOf:
        abc:A

Class: myABC:MyB
    SubClassOf:
        abc:B

Task 6: Conclusions

require or use is a part of Clojure
Gives us access to symbols from another namespace
Ontologies still need to use owl-import

Task 7: Reading an Ontology

Understand what reading an ontology achieves
Use a simple example

The problem

We showed that we can import existing Tawny-OWL ontologies
By using and importing the relevant namespace
In order for this to work, we need the Tawny-OWL source code
What if we do not have it?
Or worse, what if it does not exist?
Tawny-OWL supports this

Namespace

As usual, we declare the namespace
It is different
Require the tawny.owl and tawny.read
Have access to the symbols but do not import them into the local namespace
Ensures that the namespace has nothing else in it
Avoids namespace collisions

(ns tawny.tutorial.read-abc
  (:require [tawny owl read]))

Reading

Tawny-OWL provides a solution called reading
Reading makes all entities available as symbols

(tawny.read/defread abc
  :iri "http://www.w3id.org/ontolink/example/abcother.owl"
  :location (tawny.owl/iri (clojure.java.io/resource "abcother.owl")))

In this case, a file abcother.owl has been saved locally
Can read from any URL
Highly configurable (e.g. filter and transform names)

Reading

Here, we define our new ontology and imports the ontology axioms from other abc ontology

(tawny.owl/defontology myABC)

(tawny.owl/owl-import abc)

Reading

And access it’s value by symbol
Symbols must be defined

(tawny.owl/defclass MyA
  :super A)

(tawny.owl/defclass MyB
  :super B)

Task 7: Conclusions

Tawny-OWL supports a read mechanism
Ontologies only available as OWL files can be used transparently

Task 8: Create New Syntax

Create new syntax describing the amino acids
Create all the defined classes
Use the reasoner

The Finale

This is rather more advanced
Generate a new syntax
But pulls together most of the tasks
Demonstrates the value of a programmatic environment
Possible to build ontologies without this
The biology is interesting also

The namespace

Lots of namespaces involved here
Tawny-OWL does have more namespaces
But not many

(ns tawny.tutorial.amino-acid-build
  (:use [tawny owl pattern reasoner util]))

The Upper Ontology

Nothing new here

(defontology aabuild)

(defclass AminoAcid)

(defclass PhysicoChemicalProperty)

(defpartition Size
  [Tiny Small Large]
  :domain AminoAcid
  :super PhysicoChemicalProperty)

(defpartition Charge
  [Positive Neutral Negative]
  :domain AminoAcid
  :super PhysicoChemicalProperty)

(defpartition Hydrophobicity
  [Hydrophobic Hydrophilic]
  :domain AminoAcid
  :super PhysicoChemicalProperty)

(defpartition Polarity
  [Polar NonPolar]
  :domain AminoAcid
  :super PhysicoChemicalProperty)

(defpartition SideChainStructure
  [Aromatic Aliphatic]
  :domain AminoAcid
  :super PhysicoChemicalProperty)

Defining our `amino-acid`

Done this before
It involves too much typing
Want new syntax
Ensure consistency across all class definitions

Defining our `amino-acid`

The function is relatively easy
defdontfn gives default ontology handling
Name of the function amino-acid
& properties is variadic or "one or more args".
owl-class function does not define a new symbol

(defdontfn amino-acid [o entity & properties]
  (owl-class o entity
     :super
     (facet properties)))

Defining lots of `amino-acids`

Let’s define all twenty amino-acid at once
Pass definitions as a list (of lists)
1. Call using map
2. The anonymous function destructures
3. ->Named packages name and entity together

(defdontfn amino-acids [o & definitions]
  (map
   (fn [[entity & properties]]
     ;; need the "Named" constructor here
     (->Named entity
              (amino-acid o entity properties)))
   definitions))

And make variables

We want to use symbols and define a new variable
Tawny-OWL has some support for this
Not going to explain in detail

(defmacro defaminoacids
  [& definitions]
  `(tawny.pattern/intern-owl-entities
    (apply amino-acids
     (tawny.util/name-tree ~definitions))))

Define the amino acids

Now we can define all twenty amino acids in one go
The syntactic regularity means we are unlikely to miss something
This makes the effort worth while
We also define subclasses, disjoints and covering
Pay attention to the :cover

(as-subclasses
 AminoAcid
 :disjoint :cover

 (defaminoacids
   [Alanine        Neutral  Hydrophobic NonPolar Aliphatic Tiny]
   [Arginine       Positive Hydrophilic Polar    Aliphatic Large]
   [Asparagine     Neutral  Hydrophilic Polar    Aliphatic Small]
   [Aspartate      Negative Hydrophilic Polar    Aliphatic Small]
   [Cysteine       Neutral  Hydrophobic Polar    Aliphatic Small]
   [Glutamate      Negative Hydrophilic Polar    Aliphatic Small]
   [Glutamine      Neutral  Hydrophilic Polar    Aliphatic Large]
   [Glycine        Neutral  Hydrophobic NonPolar Aliphatic Tiny]
   [Histidine      Positive Hydrophilic Polar    Aromatic  Large]
   [Isoleucine     Neutral  Hydrophobic NonPolar Aliphatic Large]
   [Leucine        Neutral  Hydrophobic NonPolar Aliphatic Large]
   [Lysine         Positive Hydrophilic Polar    Aliphatic Large]
   [Methionine     Neutral  Hydrophobic NonPolar Aliphatic Large]
   [Phenylalanine  Neutral  Hydrophobic NonPolar Aromatic  Large]
   [Proline        Neutral  Hydrophobic NonPolar Aliphatic Small]
   [Serine         Neutral  Hydrophilic Polar    Aliphatic Tiny]
   [Threonine      Neutral  Hydrophilic Polar    Aliphatic Tiny]
   [Tryptophan     Neutral  Hydrophobic NonPolar Aromatic  Large]
   [Tyrosine       Neutral  Hydrophobic Polar    Aromatic  Large]
   [Valine         Neutral  Hydrophobic NonPolar Aliphatic Small]))

Defined Classes

Next we define defined classes
Defined Classes can be reasoned over
Anything with a Small facet is a SmallAminoAcid

(defclass SmallAminoAcid
  :equivalent (facet Small))

And some more

There are lots of these
We can combine them in many ways

(defclass
  SmallPolarAminoAcid
  :equivalent (owl-and (facet Small Polar)))

(defclass LargeNonPolarAminoAcid
  :equivalent (owl-and (facet Large NonPolar)))

Where do we stop?

3? 10?
Why not do them all?
"Doing them all" actually means the Cartesian product
We are using a programmatic tool
How would we do this?

A defined class function

Similar to before
This does not create symbols

(defn amino-acid-def [partition-values]
  (owl-class
   (str
    (clojure.string/join
     (map
      #(.getFragment
        (.getIRI %))
      partition-values))
    "AminoAcid")
   :equivalent (owl-and (facet partition-values))))

Doing them all

Call the amino-acid-def function on the Cartesian product
This creates 431 defined classes

(doall
 (map
  amino-acid-def
  ;; kill the empty list
  (rest
   (map
    #(filter identity %)
    ;; combination of all of them
    (cart
     ;; list of values for each partitions plus nil
     ;; (so we get shorter versions also!)
     (map
      #(cons nil (seq (direct-subclasses %)))
      ;; all our partitions
      (seq (direct-subclasses PhysicoChemicalProperty))))))))

Reasoning

Finally, we reason over this
Here, we choose to use HermiT
And check consistency
This takes a second or two

(reasoner-factory :hermit)

;; => true
(consistent?)

Reasoning

When reasoning, working what happened can be tough
Especially when using a "Textual User Interface"
But, we can count numbers
We have reasoned many subclases of AminoAcid

;; => 20
(count (subclasses AminoAcid))

;; => 451
(count (isubclasses AminoAcid))

Reasoning

While we consistent, we are not coherent
In fact, we have many unsatisfiable classes
What is happening?

;; => false
(coherent?)

;; => 242
(count (unsatisfiable))

Visualising

Many ways to visualise our ontology
Saving it and opening in Protege is easiest

(save-ontology "aabuild.owl" :owl)

Visualising

Many defined classes are equivalent
Many are unsatifisable
Happens because there are 20 amino-acids
But 431 defined classes
Many defined classes have necessarily the same extent
Many can have no individuals (Negative and Hydrophobic)
Only happens with the covering axiom

As a query

Using defined classes as a query
Not that useful
Most of the inferred subclasses are defined

;; => 242
(count
 (isubclasses SmallAminoAcid))

As a query

We have a full programming language
So, we filter for only undefined classes

;; => 0
(count
 (filter
  #(not (.isDefined % aabuild))
  (isubclasses SmallAminoAcid)))

Task 8: Conclusions

We can use highly programmatic nature of Tawny
We can generate many defined classes
To do so is useful
In this case one axiom can have a large effect
Results depend on the choices we make in the modelling

Summary

Task 1 - Built a hello world ontology
Task 2 - Built the amino acid tree (classes only)
Task 3 - Introduced facets to define amino acid existential restrictions
Task 4 - Introduced patterns e.g. the value partition pattern to define our properties
Task 5 - How Tawny-OWL supports OBO Identifiers
Task 6 - Using other existing Tawny-OWL ontologies
Task 7 - Reading other existing ontologies into Tawny-OWL
Task 8 - Extending Tawny-OWL syntax to programmatically generate many amino acid classes and defined classes

Hiatus

Hope that I have shown basic and advanced functionality
Key feature of Tawny-OWL is extensibility
Reuse of existing tooling
Would welcome feedback

Questions and Answers

Remainder of tutorial will be audience-driven
Welcome to take any questions or help set-up Tawny-OWL
Also have set of potential questions with prepared answers
Can get full tutorial, with notes
Readable http://homepages.cs.ncl.ac.uk/jennifer.warrender/swat4ls_2015/
Source http://github.com/phillord/tawny-tutorial

Questions

Can I add annotations on axioms?
How does this affect ontology deployment?
How do you version your ontology?
How do you test your ontology?
How do you continuously integrate your ontology?
What about advanced documentation for ontologies?
How do I collaboratively develop my ontology?
Can I internationalise my ontology?
Can I scaffolding my ontology from existing sources?
What happens if the labels of read ontologies change?
How do you convert an existing ontology to Tawny-OWL?
How fast is Tawny-OWL?
Can I integrate more tightly with Protege?
How does Tawny-OWL affect dependency management with ontologies?
Can I link ontologies into software?
What’s this :super? why not :subclass?
How do we extend Tawny-OWL, so that it saves the ontology on every change?
How do OBO identifiers work?
Do I have to conform to the no-use-before-define rule?
How do we create a new symbol with the amino-acid function?

Can I add annotations on axioms?

OWL allows annotation of axioms, for provenance for example
Tawny provides a syntax for this
Annotates SubClassOf axiom between Man and Person with a comment.
http://www.russet.org.uk/blog/3028

(defclass Man
 :super
 (annotate Person
           (owl-comment "States that every man is a person")))

How does this affect ontology deployment

Potentially none — Tawny generates an OWL file
Potentially automatable
- In project source, or through leiningen plugin
Or can publish as a maven artefact
- Ontology can be downloaded as a software artefact
- Separates out ontology identifier and download location

How do you version your ontology?

Tawny-OWL uses a line-orientated syntax
You edit source code not a visualisation of an XML file
Like various OBO flat file syntaxes, it works well in git or any VCS
Leiningen supports release versioning, using Semantic Versioning

How do you test your ontology

Clojure supports one or more unit tests frameworks
We use the default (core.test) framework
Tawny-OWL provides some fixtures
Also use spreadsheet generated testing
- Paper – http://arxiv.org/abs/1505.04112
- Tawny-Karyotype – http://github.com/jaydchan/tawny-karyotype
- Plain English Summary - http://www.russet.org.uk/blog/3074

How do you continuously integrate your ontology?

We can test ontologies with standard frameworks
These can run directly from leiningen
This workflow allows the use of standard CI environment with no changes
We use github/travis-CI
Note, iff you import ontologies via URI, you may not get a repeatable build.

What about advanced documentation for Ontologies?

Tawny-OWL ontologies are readable text
It is possible to embed rich readable comments
Also can use literate programming tools
noweb, or org-mode use traditional approach
I have also developed "lentic" which integrates with editor

How do I collaborative develop by ontology?

The same was as all software
Version control for asynchronous, fork and merge with git
Collaborative chat use gerrit, or skype
Synchronous editing, try floobits, a web editor

Can I internationalise my ontology?

Can add internationalised labels

(label "Ciao" "it")

Can define internationalised function calls

(defn etichetta [l]
  (label l "it"))

Can use tawny.polyglot to use property bundles

Can I scaffold my ontology from existing source

Can "import" ontology terms from spreadsheet, XML or a database
Can work over existing source
Therefore can generate core of ontology
And expand it with manually annotated cross links
See ICBO 2015 paper - http://arxiv.org/abs/1505.04114
See Phillip Lord’s blog - http://www.russet.org.uk/blog/3076

What happens if the labels of read ontologies change

OBO ontologies use numeric IDs
These are unreadable, so we syntactically transform labels
If label changes (but ID remains the same) is a problem
Can use tawny.memorize to remember mappings
Which adds aliases to those now missing (with optional "deprecated" warnings)

How do you convert an existing ontology to Tawny-OWL

tawny.render can perform a syntactic transformation
Given OWL provides equivalent Clojure code
Used interactively to provide documentation
Can be used to port an ontology
Currently "patternising" ontology is manual
See Jennifer Warrender’s PhD thesis where she did this with SIO

How Fast is Tawny

For raw, un-patternised ontology tawny takes about 2x as reading OWL/XML
Tested by rendering and load GO
About 56Mb of lisp
Loads in about 1min
Most of excess time is in parsing, (Clojure also compiles)
Patternised ontology would involve less parsing

Can I integrate more tightly with Protege?

We have built a GUI shell into Protege
Can also use Protege to open a Clojure REPL via a socket
Protege then displays directly the state of Tawny
Good for demonstration
But a little flaky for normal use
Having Protege reload an OWL file easier

https://vimeo.com/79395370

How does Tawny affect dependency management with ontologies?

Clojure uses maven dependency management
We can now publish ontologies as maven artefacts
And specify dependencies, with versions, and tooling
Can publish on Maven central or Clojars (no infrastructure to maintain!)
Separates ID and download location — disobeys LOD principles
But fulfils, SLOD principles.

Can I link ontologies into software?

OWL API objects become first class entities in Clojure
Can refer to them directly
We integrated Overtone — a music generation system
Added in Tawny-OWL and the Music Ontology
We now have software that plays a tune
And provides OWL metadata about that tune
More to investigate here.

What’s this `:super`? why not `:subclass`?

Manchester syntax uses SubClassOf:
Tawny uses :super for the same purpose!
Confusing!
Manchester syntax is actually backward
In tawny, all frames are A has :frame B
In Manchester A is a SubClassOf: B
http://www.russet.org.uk/blog/2985

How do OBO identifiers work?

The mapping is stored in a file
The obo-restore-iri line above reads this file
If a symbol has no mapping, we use the "pre-iri" form.

How OBO Identifiers work

The mapping file is generated
Human readable, and line-orientated
Deterministically ordered
Will version!
Uses EDN format.

("ro"
 "http://purl.obolibrary.org/obo/EXAM_000001"
 "G"
 "http://purl.obolibrary.org/obo/EXAM_000002"
 "F"
 "http://purl.obolibrary.org/obo/EXAM_000003")

How OBO Identifiers work

Stable pre-iri’s
No need for a server such as URIgen

this stores any new IDs we have created
(comment
  (tawny.obo/obo-store-iri obo "./src/tawny/tutorial/whats_in_a_name.edn"))

How OBO Identifiers work

How to create permanent IDs
Needs to be co-ordinated, since IDs are incremental
Use version-control to co-ordinate
One person, or as part of a release process

this coins permanent IDS, in a controlled process!
(comment
  (tawny.obo/obo-generate-permanent-iri
   "./src/tawny/tutorial/whats_in_a_name.edn"
   "http://purl.obolibrary.org/obo/EXAM_"))

How OBO Identifiers work

I think having no server is nice
Reusing version control makes sense
It’s programmatic! You are free to disagree.

Do I have to conform to the no-use-before-define rule?

It is possible not to use symbols
The iri-gen function takes a string not a symbol!
This string is the tawny name
Consider the following

String building!
(defontology s)

(owl-class "J" :ontology s)
(object-property "r" :ontology s)
(owl-class "K"
           :ontology s
           :super (owl-some "r" "J"))

What are Tawny Names?

These forms do NOT define symbols
This WILL NOT work
Neither r nor J have been defined

(comment
  (owl-class "L"
             :ontology s
             :super (owl-some r J)))

Tawny Names

Danger!
Consider this statement.
But we did not define "L"
But we have used it.

(owl-class "M"
           :ontology s
           :super "L")

And so, it becomes defined

Class: s:M
    SubClassOf:
        s:L

Class: s:L

Why use strings?

Partly, there for implementation
But made public as string manipulation is easier
Most useful for development

How do we create a new symbol with the `amino-acid` syntax?

If we want to create a new symbol Tawny-OWL provides defentity
It does a few other things as well

(defentity defaminoacid
  "Defines a new amino acid."
  'amino-acid)

Programming an Autosave

Extend Tawny, so that it saves the ontology on every change

Extending Tawny

Tawny is implemented directly in Clojure
We can extend in the same syntax
Can extend in general and ontology specific ways

Namespace

The namespace definition here is a bit different
Require tawny.owl through an alias
Also import an OWL API interfaces

(ns tawny.tutorial.autosave
  (:require [tawny.owl :as o])
  (:import [org.semanticweb.owlapi.model.OWLOntologyChangeListener]))

Saving the Listener

We need a variable in which to save our listener
Clojure variables are immutable
Stores a atom and change that

(def auto-save-listener
  "The current listener for handling auto-saves or nil." (atom nil))

The auto-save function

OWL API has an listener for ontology changes
We address it directly here.

(defn auto-save
  "Autosave the current ontology everytime any change happens."
  ([o filename format]
   (let [listener (proxy [org.semanticweb.owlapi.model.OWLOntologyChangeListener]
               []
             (ontologiesChanged[l]
               (o/save-ontology o filename format)))]
     (reset! auto-save-listener listener)
     (.addOntologyChangeListener
      (o/owl-ontology-manager) listener)
     listener)))

auto-save in detail

Instantiate an object which implements OWLOntologyChangeListener
Implement a single method of this
Just save the ontology
proxy is a closure
o, filename, format are closed over

(proxy [org.semanticweb.owlapi.model.OWLOntologyChangeListener]
       []
   (ontologiesChanged[l]
      (o/save-ontology o filename format)))

auto-save in detail

save the listener
discarding any existing one!

   (reset! auto-save-listener listener)

auto-save in detail

The o/owl-ontology-manager function returns an OWLOntologyManager
Clojure uses the . syntax to call methods
So, call addOntologyChangeListener on the manager
With listener as an argument

(.addOntologyChangeListener
     (o/owl-ontology-manager) listener)

Remove the auto-save

And a function to reverse the process
@ dereferences the atom

(defn auto-save-off
  "Stop autosaving ontologies."
  []
  (when @auto-save-listener
    (.removeOntologyChangeListener
     (o/owl-ontology-manager)
     @auto-save-listener)))

auto-save

There is already an auto-save function in tawny.repl
And an on-change function

Conclusions

Clojure provides easy interop with Java
We can use this to extend Tawny-OWL capabilities

Conclusions

Hope the tutorial was worthwhile
Tawny-OWL can change the way you build ontologies
Will actively support use
Always interested in future collaborations

Lentic talk

Highly Literate Approach to Ontology Building
New lenticular environment for building and documenting ontologies
Literate programming principles
Tuesday 7th December, 2015 @ 15:50

http://www.swat4ls.org/wp-content/uploads/2015/10/SWAT4LS_2015_paper_9.pdf

UKON 2016 (#ukon2016)

The 5th UK Ontology Network Meeting
Newcastle University
Thursday 16th April, 2016

http://ukontology.org/

Acknowledgements

Phillip Lord, Tawny-OWL
Jennifer Warrender, Karyotype Ontology, Tawny-OWL
Anthony Moorman, Driving use case
Ignazzio Palmizziano, OWL API Support
Matt Horridge, Protege, OWL API Support
Robert Stevens, Amino Acid Ontology

Building Ontologies with Tawny-OWL

Introduction

Today

Today

Knowledge Pre-requisites

Outcomes

Notes on Notes

Motivation

Use Case (karyotypes)

Use Case (karyotypes)

A partonomy?

Protege

Protege

Protege

Can we do this programmatically?

Brain

The Paragon : R

Constraints

Karyotype Ontology

Tawny-OWL Key Features

Ontology Building Tool

Unprogrammatic Syntax

Unprogrammatic Syntax

Unprogrammatic Syntax

Unprogrammatic Syntax

Unprogrammatic Syntax

Evaluative

Compiled

Broadcasting

Broadcasting

Patternised

Single fully extensible syntax

Reasoned Over

Commodity Language

Commodity Toolchain

Tawny-OWL Tutorial

Other Technical Pre-Requisites

Or: the alternative

Task 1: Ontological Hello World

The namespace

Define an Ontology

Introduce a Class

Properties

A complex class

On the use of "owl" (a quick diversion)

On the use of "owl"

On the use of "owl"

Saving the Ontology

More Frames

Task 1: Conclusions

Task 2: Defining a Tree

Amino Acids

A namespace

Tree

Disjoint

Disjoint

Explicit definition

Simplifying the definition

And disjoint!

And, finally, covering

And, finally, covering

And, finally, covering

Task 2: Conclusions

Task 3: Defining some properties

Namespace

Starting our ontology

Amino Acid properties

The Value Partition

The Value Partition

Using the values

Interim Summary

Using Facets

Facet

Using the facet

And others

Using Facets

Using Facets

Using Facets

Task 3: Conclusions

Task 4: Patternising

The `Size` value partition

Defining our `amino-acid`

Defining our `amino-acid`

Defining lots of `amino-acids`