TypeDB is often used for building knowledge graphs, digital twins, and ontological systems. A common question that comes up then is – how does TypeDB differ from semantic web technologies, such as OWL and RDF?

As the name suggests, OWL was built to be the Ontology Language for the (semantic) Web. Although TypeDB and OWL share the common goal of enabling machines to “understand” the data they store, they were designed for radically different environments – OWL was designed for the open web, whereas TypeDB was built for the closed domains of databases.

In the early days of TypeDB, Szymon Klarman wrote a foresightful article (Knowledge Graph Representation: TypeDB or OWL?) discussing how the difference in settings informs the design of either system, and motivates the decisions behind TypeDB’s data-model.

With TypeDB 3, we can now see these decisions manifest in the actual system. 

We start by reintroducing the two different settings these systems were built for, and provide examples illustrating the resulting difference in behaviour. We hope this helps OWL users evaluate TypeDB and how they may express their models in TypeQL.

Settings & Origins

OWL: An interchange format for the open web

The web is open, decentralized and constantly evolving. Using the standardised HTTP protocol, one can request content from anywhere on the internet. The challenge of the semantic web is similar – what would a standard language which enables two machines to understand and use each other’s data look like?

In such a semantic web, each page describes only a small part of the world. One cannot assume that the pages they have loaded contain complete information – Thus, OWL makes the Open World Assumption (OWA). Further, different pages may use different identifiers to refer to the same real-world entity, so OWL cannot make the Unique Name Assumption (UNA).

TypeDB – strong modelling for your domain

In contrast to OWL’s open world ontologies, TypeDB databases are meant to be a complete model of the user’s specific domain, with facilities for extensibility and easy refactoring. This means it can make the Closed World Assumption (CWA) – i.e. if something is not in the database, it is assumed to not exist (or, be ‘false’). In this setting, it’s possible to make the unique name assumption.

Data models

Schema & Type primitives

OWL uses subject-predicate-object triples to define an ontology in terms of classes and properties of these classes. 

### Classes
:Person rdf:type owl:Class .
:Company rdf:type owl:Class .

:FullName rdf:type owl:DatatypeProperty ;
    rdfs:domain :Person ;
    rdfs:range xsd:string .

:EmployedBy rdf:type owl:ObjectProperty ;
    rdfs:domain :Person ;
    rdfs:range :Company .

# A person must have exactly one FullName property
:Person rdfs:subClassOf [ 
    rdf:type owl:Restriction ;
    owl:onProperty :FullName ;
    owl:cardinality "1"^^xsd:nonNegativeInteger
 ] .

A TypeDB schema consists of constraints between  entity, relation and attribute types. 

define
attribute full-name, value string;
relation employed-by,
  relates employee,
  relates employer;

entity person,
  owns full-name @card(1), # A person must have exactly one full-name
  plays employed-by:employee; 

entity company,
  plays employed-by:employer;

Both TypeDB and OWL allow restricting the cardinality and the valid values a property can take – See Table 1.

Data

In OWL, data is described in terms of individuals, and properties which relate them to other individuals (or literal values).

:jane rdf:type :Person .

:john rdf:type :Person ;
    :FullName "John Doe"^^xsd:string ;
    :EmployedBy :jane .

TypeDB data is described in terms of entity & relation instances which own attribute instances or play roles in relation instances.

insert 
  $jane isa person;
  $john isa person, has full-name "John Doe";
  $_ isa employed-by, links (employer: $jane, employee: $john);

Similar structure, different outcomes

It’s easy to think the OWL & TypeQL above mean the same thing. However, the difference in assumptions of the two systems mean they are given slightly different semantics, leading to rather different behaviours.

To illustrate what this means practically: in the queries above, the OWL definition will succeed. Meanwhile, the TypeDB insert will fail because the data does not conform to the schema in two ways:

1. TypeDB rejects this because Jane is a person, but the employer role requires a company. OWL would infer Jane is both a person and a company. This is easily fixed by declaring :Person owl:disjointWith :Company, but it is illustrative of the difference between classes and types.
2. TypeDB requires Jane to own exactly one full-name. OWL assumes Jane has one – we simply don’t know about it.

To further illustrate the differences, suppose we had added a maximum cardinality=1 type restriction to a person’s EmployedBy , and the following lines to the data above.

# OWL
:john :EmployedBy :typedb .

# TypeDB
$_ isa employed-by, links (employer: $typedb, employee: $john);

We then see that:

1. TypeDB doesn’t allow $john to be the employee in more than one employment. OWL would assume :jane and :typedb (who are employing :john) are the same individual. 
2. TypeDB errors since the variable $typedb hasn’t been inserted. In contrast, OWL will fill in that :typedb must refer to some company in the world.

Experienced modellers would expect this behaviour in OWL, and model that :john and :jane are different persons (e.g. using hasKey). TypeDB simply returns a clear error message:

 [INF10] Typing information for the variable ‘typedb’ is not available. Ensure the variable is available from a previous stage or is inserted in this stage.

Of course, this is an example suited to (and written by someone familiar with) closed-world models. TypeDB would be similarly out of place in a truly open world. Fundamentally, we believe that the open and closed world assumptions are best used in different settings and for different purposes.

Reasoning: Class axioms & Functions

Let’s examine some of the other basic tenents of each system.

In OWL, individuals can be members of multiple classes, affording flexibility in modelling. Class axioms allow users to express relations between classes using operators like intersectionOf, unionOf, complementOf, disjointWith. This is the primary mechanism for reasoning 

In contrast, TypeDB views a type as something intrinsic to an instance. An instance has a single type, specified at insertion. Modelling flexibility comes from constructs familiar to programmers, such as subtyping & interface polymorphism. Reasoning is achieved through functions – all terminology and behaviour adjacent to programming languages rather than set theory.

To a certain extent, TypeDB functions can emulate OWL class axioms. Appendix 1 contains an example which does this, and illustrates the difference in reasoning between OWL & TypeDB.

Although OWL’s class axioms are more expressive, evaluating them comes at a computation cost. OWL defines several “profiles” (DL, EL, RL, Lite) which trade expressivity for ease of computation.  Although less expressive, answering queries in TypeDB is far simpler than OWL DL, and closer to the complexity of OWL RL. In turn, this opens up optimization paths in TypeDB’s implementation.

Consistency of data

The cost of OWL’s expressivity is that ontologies may not be logically consistent, and requires a complex reasoning engine to check. On the other hand, TypeDB’s type-system & function-inference were designed to have a unique, consistent model by construction. Consistency of inserted data is easily guaranteed by validating all writes against the schema – a fast and deterministic check. These design differences reflect fundamentally different use cases.

Why it’s important to be different

Despite OWL’s expressive power, it has grown a variety of extensions and layers to handle its complexity. In some cases, users realise they don’t such extreme levels of expressiveness and settle for using solutions such as RDFS with extensions like SHACL (a constraint language), SWRL (rule inference) and SPARQL (a query language) which are easier to model in and compute.

TypeDB aims to be intuitive and performant out of the box, while being expressive enough to model your domain and encode its knowledge. Its pillars are:

1. An intuitive type-system based on ideas of polymorphism which are familiar to programmers and easy to type-check
2. Powerful schema constraints to ensure data integrity efficiently
3. Declarative functions to infer new facts about the data. Like horn-logic with a CWA, functions have an intuitive “unique” model which is easy to reason about
4. An expressive pattern-matching query language which is declarative and resembles functional programs.

In the computing world, the same ideas often show up in different places. Points 2,3 & 4, which are native features of TypeDB and TypeQL, correspond to extensions of semantic web technology SHACL, SWRL and SPARQL respectively (Appendix 2 elaborates). We believe TypeDB brings together these ideas into an intuitive language that is extremely expressive and perfect for building real-world database applications.

Appendix

Here we outline some details that arise when comparing OWL and TypeDB.

Appendix 1: Class axioms & reasoning 

The type of TypeDB instance must be specified when it is inserted into the database. Following the familiar subtyping rules, an instance of a subtype can be used in place of a supertype. An important restriction is that a TypeDB type can have at most one supertype.

On the other hand, an individual in OWL can be a member of any number of classes. Further, OWL allows users to express classes in terms of other classes using operators like intersectionOf, unionOf, complementOf, disjointWith. To a certain extent, these operations can be emulated with TypeDB functions:

# Using :Parent instead of a restriction on a :parentOf role for brevity
:Voter owl:equivalentClass owl:unionOf(
    :Citizen
    owl:intersectionOf(:Resident :TaxPayer)
).

fun voter() -> person:
match
  $p isa person; 
  { $_ isa citizenship (citizen: $p); }
  { $_ isa residency (resident: $p); $_ isa tax-return (payer: $p); };
return { $p };

A function isn’t logical-equivalence (neither is rule-based “when-then implication” from TypeDB 2). One cannot declare a person to be a voter and expect TypeDB to infer that they are either a citizen, or a resident-taxpayer. 

With logical implication, one could assert a person is NOT a voter, and expect the system to infer that the person is neither a citizen, nor a resident-taxpayer. This is not possible in TypeDB (2.x rules) as you cannot assert the negation (or absence of) a fact. In OWL, you should be able to express this with disjointWith or complementOf.

These are exactly the restrictions which define a horn-clause – no disjunctions or negated literals in the head of the rule. These restrictions take away from the reasoning power of TypeDB, but give rise to a unique model which is consistent by construction, easy to reason about and really efficient to evaluate.

Appendix 2: TypeQL = SHACL + SWRL + SPARQL for the closed world?

Data integrity: Schemas & SHACL

The Shapes Constraint Language was designed by the W3C to validate RDF graphs. These are similar to TypeDB schema in that it defines constraints the data MUST satisfy (rather than stating assertions about the open world)

Table 1: Restricting attribute values

Note that TypeDB @values applies only to attributes and cannot restrict which instances can play roles for a certain class. OWL can do this with allValuesFrom.

Inference: Functions & SWRL

OWL & TypeDB provide ways to derive new properties based on patterns in the data.

In OWL, this is done using property chains or the SWRL extension. 

The equivalent in TypeDB are functions, which replace the logic-programming like rules from TypeDB 2.x. Like SWRL, this is based on horn-logic, but works under TypeDB’s closed world assumption.

Querying: TypeQL & SPARQL

Users are usually interested in finding data which match certain conditions. In databases this is done by “querying” the data. OWL checks whether one ontology “entails” another. A standard way of doing this in OWL is using the SPARQL (which is again a query language).

TypeDB’s query language is called TypeQL. These have similar features, albeit they work in slightly different settings.

Both TypeQL and SPARQL match patterns in the database, finding values for each variable where the pattern matches the data. By default, they match conjunctions of “basic patterns” but also support negation, disjunction and optional patterns. 

The table compares some of the main features but is not exhaustive

As we can see, the primary feature that SPARQL has that TypeQL lacks is referencing entire subsets or subgraphs of data natively. SPARQL also supports federated queries (pulling in OWL data from remote databases), in line with its goal of supporting a “semantic web” that is decentralized.

In contrast, TypeQL is closer to a traditional database with data stored in a single database, and also requires a schema to operate. It also allows some more sophisticated structures:

• Hypergraph structures (relations with more than 2 participants), without “reification”
• Parallel relations: in SPARQL, you could not model “John married Jane” twice, whereas in TypeQL these are separate facts.